App 组件化/模块化开发架构思路
随着业务的发展 App 开发技术也越来越成熟，对开发者来说 App 代码量也迅速地增长到一个数量级。对于如何架构 App 已经每个开发者面临的实际问题。好的架构可以提高开发者的效率，降低维护成本。
由于业务增长引起项目中代码量激增，以及历史遗留问题和结构混乱，作为一个有代码洁癖的程序员，很早就开始思考如何组织 App 架构的问题了。目前遇到的主要有以下几点问题：
-
代码量激增引起结构混乱
-
各个模块相互引用且耦合度高
-
无法独立开发或者调试组件代码
-
无法应对组件插拔的需求（例如：产品经理今天把这个功能加上，第二天又去掉，第三天又加回来T_T）
App 架构图
在阅读了大量的文档之后，根据实际项目开发遇到的问题，我总结了以下架构。由于水平有限，有不合理的欢迎拍砖
自下而上将 App 分为：
内核层
业务层
应用层
内核层
内核层是包含了为 App 提供公共服务的的一些库。例如：公共资源、网络库、日志工具、数据库、图片加载等核心库。这些是整个 App 基础库。
业务层
我认为这一层是整个 App 架构的关键。因为根据实际业务需求，这一层会分离出许多独立组件（其实就是对应于项目的Module），但这些组件可以独立运行，相当于一个小应用（组件如何独立运行将在应用层中会详细解析）。并且这些组件不再像传统的方式进行相互引用，而是采用了组件路由进行各个组件的通信。
SDK 编码思维
业务层要实现比较好组件分离，对程序猿现在编码思维要转换一下，要切换到 SDK 思维。
那什么是 SDK 思维呢？
想想项目中引用他人编写的库的接口使用方式，就不难理解了。即站在使用者的角度上思考：如何使用接口才是最方便的？例如公司现有好几个 App 产品，每个 App 都需要使用同样的授权登录。那么这个授权登录模块就可以独立成一个组件。
应用层
顾名思义，这一层是对整个 App 的整合，也是 App 的入口。这里有 Main 和 Dev。其中 Main 是对各个业务组件的整合，是最终打包的产品的上层应用。而组件入口是独立运行和调试各个组件的子应用。
