原文链接：https://www.gaodaima.com/xiangzh…

5、热点技术

（1）概念：

组件化：是将一个APP分成多个module，每个module都是一个组件，也能够是一个根底库供组件依赖，开发中能够独自调试局部组件，组件中不须要相互依赖然而能够互相调用，最终公布的时候所有组件以lib的模式被主APP工程依赖打包成一个apk。

（2）由来：

1. APP版本迭代，新性能一直减少，业务变得复杂，保护老本高
2. 业务耦合度高，代码臃肿，团队外部多人合作开发艰难
3. Android编译代码卡顿，繁多工程下代码耦合重大，批改一处须要从新编译打包，耗时耗力。
4. 不便单元测试，独自改一个业务模块，不须要着重关注其余模块。

（3）劣势：

1. 组件化将通用模块独立进去，对立治理，以进步复用，将页面拆分为粒度更小的组件，组件外部出了蕴含UI实现，还能够蕴含数据层和逻辑层
2. 每个组件度能够独立编译、放慢编译速度、独立打包。
3. 每个工程外部的批改，不会影响其余工程。
4. 业务库工程能够疾速拆分进去，集成到其余App中。
5. 迭代频繁的业务模块采纳组件形式，业务线研发能够互不烦扰、晋升合作效率，并管制产品质量，增强稳定性。
6. 并行开发，团队成员只关注本人的开发的小模块，升高耦合性，前期保护不便等。

（4）思考问题：
模式切换：如何使得APP在独自调试跟整体调试自在切换
组件化后的每一个业务的module都能够是一个独自的APP（isModuleRun=false）， release 包的时候各个业务module作为lib依赖，这里齐全由一个变量管制，在根我的项目 gradle.properties外面isModuleRun=true。isModuleRun状态不同，加载application和AndroidManifest都不一样，以此来辨别是独立的APK还是lib。

在build.grade外面配置：

资源抵触

当咱们创立了多个Module的时候，如何解决雷同资源文件名合并的抵触，业务Module和BaseModule资源文件名称反复会产生抵触，解决方案在于：

每个 module 都有 app_name，为了不让资源名重名，在每个组件的 build.gradle 中减少 resourcePrefix “xxx_强行查看资源名称前缀。固定每个组件的资源前缀。然而 resourcePrefix 这个值只能限定 xml 外面的资源，并不能限定图片资源。

依赖关系

多个Module之间如何援用一些独特的library以及工具类

组件通信

组件化之后，Module之间是互相隔离的，如何进行UI跳转以及办法调用，具体能够应用阿里巴巴ARouter或者美团的WMRouter等路由框架。

各业务Module之前不须要任何依赖能够通过路由跳转，完满解决业务之间耦合。

入口参数

咱们晓得组件之间是有分割的，所以在独自调试的时候如何拿到其它的Module传递过去的参数
Application

当组件独自运行的时候，每个Module自成一个APK，那么就意味着会有多个Application，很显然咱们不违心反复写这么多代码，所以咱们只须要定义一个BaseApplication即可，其它的Application间接继承此BaseApplication就OK了，BaseApplication外面还可定义专用的参数。

5.2、插件化

（1）概述

提到插件化，就不得不提起办法数超过65535的问题，咱们能够通过Dex分包来解决，同时也能够通过应用插件化开发来解决。插件化的概念就是由宿主APP去加载以及运行插件APP。

（2长处）

在一个大的我的项目外面，为了明确的分工，往往不同的团队负责不同的插件APP，这样分工更加明确。各个模块封装成不同的插件APK，不同模块能够独自编译，进步了开发效率。

解决了上述的办法数超过限度的问题。能够通过上线新的插件来解决线上的BUG，达到“热修复”的成果。

减小了宿主APK的体积。

（3毛病）

插件化开发的APP不能在Google Play上线，也就是没有海内市场。

喜欢 (0)赏

[搞代码]

分享 (0)