关于app组件化的一点记录

前言

   

        在平常开发过程中，我习惯性会把一个模块的功能放在一个包下（所有的功能和业务都在一个moudle下），但是随着业务的不断增加，

工程的结构越来越复杂，代码的耦合性也来越高，编译速度慢，代码调试路径较深（不易调试），后期维护太费劲，因此对项目进行重构势

在必行，那么接下来来讲如何进行大型项目的重构。

重构的方向

      目前对于大型项目重构。其实就是优化大型项目架构， 便于开发，降低耦合性，易于扩展，易于调试，项目结构清晰，后期维护方便的优点。

那么什么样的App架构能有如上那么多的有点呢？目前网络上对于冗余繁杂的大型app的结构都倾向于插件化。主流的插件化框架方案（并且推广到市场）如下：

（moudle主要是指各个业务模块）

插件化方案比较

框架名称	altas（淘宝）	DynamicLoadApk（途牛app）	DroidPlugin（360团队）	DynamicAPK（携程）
版本支持	Androd 2.2以上系统	Androd 2.x以上系统	Androd 2.3以上系统	Androd 2.3以上系统
rom大小	较小	较小	一般	一般
moudle间资源调用	支持	支持	不支持	支持
moudle间方法调用	支持	支持	不支持	支持
moudle单独调试	支持	支持	支持	不支持
moudle间解耦度	很高	一般	很高	一般
重构复杂度	较高	很高（所有的组件必须继承该库的组件，并且目前还不支持services和broadcast）	傻瓜式（apk的完全隔离）	一般
编译速度	高	一般	高	一般
hot fix	支持	支持	支持	支持
稳定性	好	一般	较好	一般

       对于app的插件化往往都伴随着热修复的功能，解决及时修复线上bug的方案

下面是阿里巴巴做出的总结如下（可作了解）

热修复方案比较

平台	Sophix	hotfix	Tinker（微信团队）	QZone
即时生效	yes	yes	no	no
性能损耗	较小	较小	较大	较大
侵入式打包	无侵入式打包	无侵入式打包	依赖侵入式打包	依赖侵入式打包
Rom体积	较小	较小	较大	较小
接入复杂度	傻瓜式接入	比较简单	复杂	比较简单
补丁包大小	较小	较小	较小	较大
全平台支持	yes	yes	yes	yes
类替换	yes	yes	yes	yes
so替换	yes	no	yes	no
资源替换	yes	no	yes	yes

如何做重构

对于上面的插件化方案，普遍存在一些问题，
   1.大部分插件化方案是通过hook底层方法实现，存在机型兼容性问题。
   2.目前插件化技术方案不完善导致在生产环境下会遇到各种坑。

也就是上面的插件化技术方案都不能百分百保证适用于所有的项目，在各个项目中可能会遇到各种各样的问题，但是却有这一定的借鉴意义，

综合上面的方案、我们晓助手的特点和目前情况做如下架构拆分

、

如上图所示，项目结构清晰，按照上面的架构图已完成的如下部分:

1.抽离的底层的utils库，规范重要的依赖。

2.抽离大部分的Framework的作为独立的moudle，并且优化和处理framework的代码

3.抽离了业务层的代码层。