Android组件化

Android组件化的优缺点

组件化开发的优势：系统级的控制力度细化到组件级的控制力度。一个复杂系统的构建最后就是组件集成的结果。每一个组件都有本身独立的版本，能够独立的编译、测试、打包和部署。

产品组件化后可以实现完整意义上的按需求进行产品配置和销售，用户能够选择使用那些组件，组件之间能够灵活的组建。

配置管理、开发、测试、打包、发布彻底控制到组件层面。这样在一个组件小版本进行升级若是对外提供的接口没有发生任何变化，其余组件彻底不须要再进行测试。

组件化开发的缺点：组件化对开发人员和团队管理之提出了更高水平的要求。相对于传统的开发模式，要求开发人员对业务有更深层次上的理解，划分好每一个组件。

Android项目开发方式

简单开发模型

所谓简单开发模型是最基础的开发方式，工程中没有所谓的模块，没有规划，以下图

开发过程当中每每是在一个界面中存在着大量的业务逻辑，而业务逻辑中充斥这各类网络请求，数据操做等行为，整个项目中没有所谓的模块的概念，项目的基本组成单位不是模块，而是方法级的。

单工程开发模型

这种开发模型已经有了明确的模块划分，而且经过逻辑上的分红出现了较好的结构，这种模型一般用于早期产品的快速开发，团队规模较小的状况下。开发模型结构以下：

 

随着产品的迭代，业务愈来愈复杂，随之带来的是项目结构复杂度的极度增长，此时咱们面临着几个问题：

实际业务变化很是快，可是工程以前的业务模块耦合度过高，牵一发而动全身。

对工程所作的任何修改都必需要编译整个工程。

功能测试和系统测试每次都要全量测试。

团队协同开发存在较多的冲突，不得不花费更多的时间去沟通和协调，而且在开发过程当中，任何觉得成员没办法专一于本身的功能点，影响开发效率。

不能灵活的对工程进行配置和组装。

 面临以上问题，单线程开发模型已经不能知足团队须要了，咱们要使用新的开发模型。

主工程多组件开发模型

借助组件化这一思想，咱们在"单工程"模型的基础上，将业务中层中的各业务抽取出来，封装成相应的业务组件，将基础库中各部分抽取出来，封装组成基础组件，而主工程是一个可运行的app，做为各业务组件的入口（主工程也被称为壳程序）。这些组件或以jar形式呈现，或以aar的形式呈现。主工程经过以来的方式使用组件所提供的功能。

 

 

（须要注意的是在实际的项目中，业务组件之间会产生通讯，也会有依赖管理）

不管是jar仍是aar,本质上都是Library,他们不能脱离主工程而单独的运行.当团队中成员共同参与项目的开发时,每一个成员的开发设备中必须至少同时具有主工程和各自负责组件,不难看出经过对项目实行组件化,每一个成员能够专一本身所负责的业务,并不影响其余业务,同时借助稳定的基础组件,能够极大减小代码缺陷,于是整个团队能够以并行开发的方式高效的推动开发进度.

不但如此,组件化能够灵活的让咱们进行产品组装,要作的无非就是根据需求配置相应的组件,最后生产出咱们想要的产品.这有点像玩积木,经过不一样摆放,咱们就能获得本身想要的形状.

对测试同窗而言,能有效的减小测试的时间:原有的业务不须要再次进行功能测试,能够专一于发生变化的业务的测试,以及最终的集成测试便可.

到如今为止,咱们已经有效解决了”单工程开发模型”中一些问题,对于大部分团队来讲这种已经能够了,可是该模型仍然存在一些能够改进的点:每次修改依赖包,就须要从新编译生成lib或者aar.好比说小颜同窗接手了一个项目有40多个组件,在最后集成全部组件的时候,小颜同窗发现其中某组件存在问题,为了定位和修改该组件中的问题,小颜同窗不断这调试该组件.因为在该模型下,组件不能脱离主工程,那么意味着,每次修改后,小颜同窗都要在漫长的编译过程当中等待.更糟糕的是,如今离上线只有5小时了,每次编译10分钟,为改这个bug,编译了20次,恩….什么也不用干了,能够提交离职报告了

如何解决这种每次修改组件都要连同主工程一块儿编译的问题?下面咱们来看主工程多子工程开发模型是如何解决该问题的.

 

主工程多子工程开发模型

该种开发模型在”主工程多组件”开发模型的基础上作了改进,其结构图以下:

 

不难发现,该种开发模型在结构上和”主工程多组件”并没有不一样,惟一的区别在于:全部业务组件再也不是mouble而是做为一个子工程,基础组件可使moudle,也能够是子工程,该子工程和主工程不一样:Debug模式下下做为app,能够单独的开发,运行,调试;Release模式下做为Library,被主工程所依赖,向主工程提供服务.

 

在该种模型下,当小颜同窗发现某个业务组件存在缺陷,会如何作呢?好比是基础组件2出现问题,因为在Debug模式下,基础组件2做为app能够独立运行的,所以能够很容易地对该模块进行单独修改,调试.最后修改完后只须要从新编译一次整个项目便可.

 

不难发现该种开发模型有效的减小了全编译的次数,减小编译耗时的同时,方便开发者进行开发调试.

 

对测试同窗来讲,功能测试能够提早,而且可以及时的参与到开发环节中,将风险降到最低.