本文算是一篇漫谈，谈一谈关于android开发中工程初始化的时候如何在初期我们就能搭建一个好的架构。
关于android架构，因为手机的限制，目前我觉得也确实没什么大谈特谈的，但是从开发的角度，看到整齐的代码，优美的分层总是一种舒服的享受的。
从艺术的角度看，其实我们是在追求一种美。
本文先分析几个当今比较流行的android软件包，最后我们汲取其中觉得优秀的部分，搭建我们自己的通用android工程模板。
1. 微盘
2.网易新闻
1.微盘
微盘的架构比较简单，我把最基本，最主干的画了出来：
第一层：com.sina.VDisk：com.sina(公司域名)+app(应用程序名称) 。
第二层：各模块名称（主模块VDiskClient和实体模块entities）
第三层：各模块下具体子包，实现类。
从图中我们能得出上述分析中一个最简单最经典的结构，一般在应用程序包下放一些全局的包或者类，如果有多个大的模块，可以分成多个包，其中包括一个主模块。
在主模块中定义基类，比如BaseActivity等，如果主模块下还有子模块，可以在主模块下建立子模块相应的包。说明一点，有的时候如果只有一个主模块，我们完全可以省略掉模块这一层，就是BaseActivity.java及其子模块直接提至第二层。
在实体模块中，本应该定义且只定义相应的实体类，供全局调用(然而实际情况可能不是这样，后面会说到)。在微盘应用中，几乎所有的实体类是以xxx+info命名的，这种命名也是我赞成的一种命名，从语义上我觉得xxxModel.java这种命名更生动更真实，xxxModel给我一种太机械太死板的感觉，这点完全是个人观点，具体操作中以个人习惯为主。还有一点，在具体的xxxInfo,java中有很多实体类中是没有get/set的方法，而是直接使用public的字段名。这一点，我是推荐这种方式的，特别是在移动开发中，get/set方法很多时候是完全没有必要的，而且是有性能消耗的。当然如果需要对字段设置一定的控制，get/set方法也是可以酌情使用的。
2.网易新闻
网易新闻确实做的不错，从应用的角度看，是我最欣赏的应用之一。它的工程结构是怎么样的呢？
网易新闻的工程结构和前面2各app又有很多的不同，它并没有按照模块来分，而是主要按照组件的类型来分的，然后把此类型所有的类全部放在其下。那么这种把所有activity全部放在activity包下的分法的确在android开发中比较普遍。
1).第一层被分成了两层，可以看出来，这里肯定是采用了公用包jar，如此说来，我们开发公用包的时候也应该按照"公司域名+公用模块名称"组合方式来命名比较好。
2).第三层(绿色层)中activity和service包下都是存放所有的activity组件和service组件，其实这里面包含了一种代码习惯。往往activity相关的类如监听器，线程，适配器等非常多的类，这些不好直接丢在activity包下，而是直接写在相应的activity中以匿名或者内部类形式定义，否则activity包和service包看上去会比较杂乱。
因为android的app很可能不是很大，activity或者service包也不会杂乱，所以网易新闻的这种方式也是很有参考借鉴价值的。
关于第一种方案进阶：
我们先来看下目前大部分app的单一项目结构原型。大致如下图所示： 
一眼望去这结构不是挺清晰的么？每个业务都放在单独的包名下，网络库、图片加载库等第三方库与上层业务都完美的剥离了，我们再来看下他们的直接的依赖关系图： 
虽然上面的依赖关系举例有点太过于极端，但是真实场景中是存在的。各个业务之间代码互相引用，所以这种结构也是架构整改的根本动机，也是当务之急应该考虑的事情。为了更好的满足各个业务的迭代而彼此不受影响，更好的解决上面这种让人头疼的依赖关系，开始着手app架构整改。
从上面的分析我们可以得出适合业务组件化的几种情况：
(1)业务较多、而且复杂
(2)业务之间的依赖需要解耦
(3)团队成员较多，需要各自开发相对独立的业务
业务组件化方向：
APP业务组件化架构整改的方向就是告别结构臃肿的时代，让各个业务变得相对独立。模块工程和类库工程之间遵循向下依赖关系，各个模块之间的遵循平级依赖关系。先看下整改后的各个独立业务模块与类库工程之间的向下依赖关系图： 
整改的方向由一个项目工程拆分成若干个模块工程，由app壳工程提供统一的入口，每个业务独立的模块module共享项目的依赖库。由壳工程集成需要引入的业务模块，至于各个独立的业务模块之间的调用依赖关系，我们借助一个中间层充当路由功能，这个路由我们放在各个业务模块共同引用的依赖库那一层。由路由统一调度他们之间的依赖关系，路由调度解决平级依赖问题示意图： 
通过APP壳工程提供的路由功能，各个模块之间调用不再采用传统的显示调用，而是采用隐式调用的方式。从而使各个模块之间不再存在依赖关系。
APP业务组件化架构整改技术方案：
业务组件化大致需要解决以下几个问题。
1.）业务组件的生命周期
按照理想状态的来看待的话，各个业务组件之间没有任何依赖关系，这时我们可以把每个独立的业务组件看成一个可运行的app，所以业务组件的生命周期和应与独立的app保持一致。
2.）业务组件之间通信
在各个单独业务组件内，基本上保持原来的调用方式，组件之间通信采用URL Schema方式实现页面跳转，格式为 schema://host/action?param1=value1¶m2=value2 。关于schema映射表维护由上面提到的Router（路由）这么一个角色来维护，
schema解析由系统Framework来维护。其中schema映射表可以做成后台配置文件形式。也可以代码维护，不过组件需要预先注册。以上说的对于传递基本参数是没啥问题的。如果要传递对象的话，转成Json 字符串就可以了。
关于schema可以参考我的这篇博客：Android业务组件化之URL Schema使用
APP 业务组件化架构整改带来的好处：
如此规模大的架构整改需要付出更高的成本，还会涉及一些潜在的风险，那么整改后的架构能够带来哪些好处呢？
(1)加快迭代速度，各个业务模块组件更加独立，不再因为业务耦合情况，在发版时候，由于互相等待而迟迟不能发布版本。
(2)稳定的公共模块采用依赖库方式，提供给各个业务线使用，减少重复开发和维护工作量。
(3)迭代频繁的业务模块采用组件方式，各业务线研发可以互不干扰、提升协作效率，并控制产品质量。
(4)为新业务随时集成提供了基础，所有业务可上可下，灵活多变。
(5)降低团队成员熟悉项目的成本，降低项目的维护难度。
(6)加快编译速度，提高开发效率
总结：
本篇主要来分析为何要实现业务组件化、组件化的方向、组件化的技术方案简单探讨、组件化带来的好处，由于目前还处于实施初期，很多观点有可能是错误的，很多技术坑还没涉及，后续会跟进更多相关实现方案。