[Android]如何做一个崩溃率少于千分之三噶应用app（33）-AAB插件化架构

Android组件化架构

近来建立了两个小专栏，将会其中发布现在的区块链通讯项目所应用到的技术，以及进程化技术，有兴趣可以关注一下（不一定需订阅，推广期价钱也便宜）。

[Android IM技术指南] 里面介绍的是加密IM的技术应用和指南

[Android 进程化架构] 里面介绍的是进程化的方案。

在上一节中介绍了一些Android App Bundle的特性和需要注意的地方，属于组件化开发技术，这节要介绍的是AAB插件化技术。

这是未来的倾向，很可能将会国内大厂提供这样的服务来引导插件升级流程。
对比一下普通组件化架构和AAB的架构。

普通组件化架构.png

AAB组件化架构.png

可以看出，AAB的架构比普通组件化架构少了应用层，原来在应用层的逻辑被转移到基础层中了。
在基础层做dex加载，res加载，lib加载，以及Activity启动跳转分发等功能。

之前我们说过AAB的架构非常适合做热修复热补丁的功能，是因为其包体细小，并且功能单一，并且google已经规划了升级流程了。

那么有没办法使用AAB做热更新的功能呢？
画黑板的时间到了。
上一节中提及到如果模块数量变更以及四大组件有变更的时候将需要重新将大版本更新到google市场。
其实正确的说是，模块数量变化，以及AndroidMainfest有变更的时候（四大组件，权限申请变更）需要重新更新到google市场。
而我们的目标是不需要重新更新整个包体到google市场，要求用户强制升级整个包体，而是做到部分静默升级（这才是热更新）。
为了规避这些限制，那么就建立module的时候规范规则。

AAB架构.png

1.尽量保持Base模块作为最基础的资源保持不变，尽量放一些大的so库，和范用性的第三方库，例如rxjava，glide，retrofit，okhttp，视频和直播流等框架。
Application module，基础状态一般发布后一般都不需要修改，也不能变更。如果变更了，相当于国内发布出去的插件化包壳，发布出去就无法变更了。而且无法使用热修复（求google爸爸放过），想修复只能重新发版了。

2.Common层，有一个到两个module应该就足够了，放一些公用资源和View，小型的so文件，公用信息类和通信框架，应该是足够的。

3.一个module只有一个Activity或以Fragment为基础，不再新增Activity页面，如果新增Activity相当于新增一个module的业务。
如果一个业务有多个页面，那就选用Fragment显示，很早以前就有大神提出单Activity多Fragment方案（Fragmentation），google今年发布新的组件Navigattion组件，这个亲测能用，但是fragment一定要声明全路径（包名+类名），还不是正式版，所以大家懂的。也可以选用单Activity多View架构（Conductor）

4.权限的声明，基础组件的权限还是放到Common层中申请和处理。但是添加权限声明，相当于更改AndroidManifest，那么将需要重新发版，如果埋点的时候请慎重。

5.dynamic module和 application module的包名请使用同一个，不然会出现类引用不到的问题（估计是有验证）

6.请尽量在Application初始化的时候使用SplitInstallManagerFactory加载dynamic module，如果页面中有使用Activity或者View没在初始化的状态会因为引用不到而奔溃的。请一定要保证加载dynamic module，再去跳转，加载module后有success的回调的。

7.主页当然是放到Application module中，保证一定能加载主页显示。资源使用反射，activity、service跳转前请一定要使用判空，因为一旦跳转不到就会崩溃。

8.dynamic module生成的apk，请尽量保证在10M一下，升级可以做到静默升级，超过10M，需要提示下载。dynamic module是支持应用内移除和添加的，应用跳转前可以加入loading，保持友好的响应。

9.如果使用ARouter，应该可以正常跳转，但是移除跳转类，那么将会出现ARouter的toast提示。

10.dynamic module，只是延迟下载。如何配置动态加载，那么就需要通过修改common中的配置了，你可以使用json脚本配置，也能使用SharePreference来记录开关状态来完成。

11.可以提前建立多个module作为埋点，只要使用一样的架构来填充业务代码就可以运行。当然代码更改，请尽量有效的控制，一般的交互尽量控制在一两个module中，这样更新量将会减少，不然静默升级将不稳定。

12.需不需要每个module都申请Service呢？其实这里可以折中的方法，先使用common module中预先埋一两个service，必要时作为代码填写处理。然后发新版的时候，再将代码转移到对应的业务中。contentProvider也如此。

13.还有一个需要考究的问题，就是混淆保持的问题。
群1已满，可以进群2学习组件化

组件化架构2群