前言
从本篇起将展开一个组件化开发的系列，如果你打算在实际项目中使用组件化开发或者有志于向架构师方向发展，希望本系列能对你有所帮助。欢迎加入学习小组QQ群: 193765960，我会不定期的给大家推荐优质的文章和话题。
版权归作者所有，如有转发，请注明文章出处：https://xiaodanchen.github.io/archives/
相关文章：
APP组件化开发之分层设计2
组件化概述
为什么需要组件化：
随着时间的推移又或者历史的原因，APP端的业务必然而然的会变得异常复杂，代码之间耦合严重，正所谓牵一发而动全身。再如果出现复杂业务多团队协作的要求，那么APP组件化架构和开发势在必行。
历史上，APP的架构大致经历了几个过程：MVC(简单业务) --> MVP/MVVM(单一业务视图、业务、数据解耦) --> 组件化/插件化（复杂业务系统，业务解耦）/跨平台架构。
什么是组件化：
由于我本人对组件化的理解也不深，我只能以一种形而下的语句来描述一下我所理解的组件化。其实针对组件化和插件化，我们确实没太有必要纠结于精准的描述和定义，不论什么样的架构和技术，其目的无非都是为了适应复杂业务系统的解耦和快速迭代的需要，更重要的是这种深度解耦、快速迭代、简单维护的理念。
就Android项目，良好的组件化框架允许将不同的业务或者功能单独抽离封装成独立的sdk或liberary工程提供给其他的代码使用，常见的jar包、AAR或者第三个的源码库等都是如此，均可以划分为组件的范畴。由一个打包工程（宿主app或叫壳工程）来统一集成各个业务和底层库并进行打包发布。
组件化相对于MVC/MVP/MVVM等时整体与部分的关系。组件化是对APP层面的一个横向功能纵向业务的拆解。MVC/MVP/MVVM等则是针对单独业务中各个视图界面的视图、逻辑和数据的处理方案。
组件化方案
架构设计
以上为大致的一个组件化app结构，common library提供最基础的app开发环境，即host只依赖common library的话就可以开始开发。common library大致提供如下的能力：
如何快速构建组件化框架
构建一个合格的组件化开发系统要考虑以下因素：
1，公共资源的复用：避免重复的打包和资源注入。
2，组件之间相互解耦
3，统一的业务组件开发框架
4，给自己留有退路，即如何快速的从组件化开发回退到单一工程的开发框架。
在此给大家推荐一下阿里手淘的组件化解决方案：atlas。
1，官方文档：http://atlas.taobao.org/docs/principle-intro/Project_architectured.html
2，名词解释：
- bundle：类似于OSGI框架规范中的bundle：组件
- awb: 阿里手淘发明的一种文件格式; 类似于AAR，区别在于每个awb都有一个对应的packageID
- host: 宿主app
- tpatch: 增量更新的补丁包
3，构建过程：
工程目录示例：
总结
纸上得来终觉浅，绝知此事要躬行。再好的理论也要实践才有意义，听上去再牛逼的架构也要适合自己才有价值。希望此文能起到抛砖引玉的作用，给大家的下一步工作敲开一点点缝隙。
由于实际的因素，文中无法对一些细节展开更详细的描述，有兴趣的同学可以加入学习小组QQ群: 193765960做进一步的讨论。
分享知识，传递价值，收获快乐，与诸君共勉。
