Android应用架构的发展和实践

前言

架构是咱们组织程序，各个项目组件的一种机制。好的架构兼顾了易用性，灵活性，扩展性和复用性。现代Andorid架构已经不限于单体或者单Module了，逐渐在向着多Module和插件化动态化进行发展。

这里主要围绕项目单体应用时的架构，单Module到多Module的演变，以及插件化的将来来讲。

单体应用架构

单体应用架构是指咱们的项目在单Module时的架构，此时项目通常会划分一些层级，好比UI层，网络层，逻辑层。这些层级怎么进行组织呢？

最开始，你们刚接触Android开发，通通是MVC。MVC的问题是布局文件做为View层，没法承担任何业务逻辑；UI的逻辑和业务逻辑都写在Activity层，在项目体量不大的时候这样彻底没有问题。但是当每一个页面的业务逻辑变成以前的2倍的时候，代码量也会增加一倍，这大大下降了项目的扩展性和维护性。这个时候可能你会经过抽取重构的方式来缓解这种局面，但是随着业务增多，不久又会陷入这种局面。

慢慢的咱们发现，将Activity层的全部业务逻辑抽出去，只剩下UI相关逻辑。这样既清晰，又能解决上面的问题，因此MVP出现了。在MVP中，Activity充当UI层，Presenter充当业务逻辑；UI层和逻辑层交互，逻辑层和数据层交互。采用接口回调，或者EventBus的方式让UI层和逻辑层进行通讯。

客户端开发主要是和UI打交道，最好的必定是MVVM。使用databind，或者LiveData能够替代接口回调和EventBus。关于上面这些内容，我在另外一篇文章中有更详细的说明：juejin.cn/post/684490…

MVVM架构下的单体应用项目，应该有这样几个层级：

• 数据层，专门负责数据的存取，方式不限（网络数据，File数据或者KV存储）
• VM层，专门负责执行业务逻辑和数据的处理，与数据层有交互
• UI层，负责显示每一个界面，弹窗等，与VM层有交互

以下图示：

单Module到多Module演变

这个演变很是像后台应用的单体架构到微服务架构的演变，适用于公司内部有多个产品须要同时迭代的场景。随着单体应用向多Module的演变，原先的各个组件都独立到不一样的Module中去了。

大概有两个阶段：

1. 单一入口Module + 公共类库Module
2. 多入口Module + 多公共业务Module + 公共类库Module

第一个阶段很好理解，也是一个天然而然的演变。由于项目中不少公共的模块，好比日志模块，网络模块，数据模块。这些模块与逻辑无关，能够给任何项目使用，因此单独开一个Module或者传到maven库。若是要开发新的项目，那也只是将公共类库Module移植过去便可。

因此，第一阶段的项目Module结构大概是这样：

• App Module，负责提供项目入口，完成各个业务逻辑功能
• Library Module，负责提供项目公共组件，好比日志组件，网络组件，存储组件
• 其余三方库Module

以抖音App为例：

上面的阶段能作到功能模块的重用，可是没有涉及到业务逻辑的重用。新项目也有登陆注册功能，难道要从新写一遍么？

你可能担忧两个项目的登陆注册逻辑能同样么，界面也不可能同样啊。界面确定是不同的，可是登陆注册逻辑大部分是同样的。这就说明咱们其实能够对一些公共业务划分Module，对于不同的地方，彻底能够动态化。可是公共业务不能划入类库Module中，由于通用性不够；还要注意业务Module的抽离本着只抽业务，不抽UI的原则。

当业务Module和类库Module抽离以后，不一样的项目咱们能够添加不一样的入口Module，入口Module更可能是完成入口功能，和UI定制化功能，以及完成一部分差别化的实在不能共用的业务逻辑。

因此，第二阶段的项目Module结构大概是这样：

• App1 Module，负责提供App1的入口，完成App1的全部UI逻辑和部分不能共用的业务逻辑
• App2 Module，负责提供App2的入口，完成App1的全部UI逻辑和部分不能共用的业务逻辑
• Login Module，负责提供登陆注册功能
• Video Module，负责提供视频相关功能
• Library Module，负责提供公共模块功能
• 其余三方Module

客户端开发中，UI的变数最大，上面的Module划分尽可能将变化少的东西复用，将变化大的东西剥离出来。

他们之间的调用关系应该符合这样的规则：

• App入口Module能够调用业务Module和Library Module；
• 业务Module能够调用Library Module，业务Module之间不能相互调用，也但不能调用App入口Module，目的是保持单向调用流程
• Library Module只能被调用。

以抖音App为例：

若是你发现业务Module须要调用App入口Module，或者其余状况，可能你的Module架构设计有问题。

Module间通讯

其实上面的架构不存在Module之间的通讯，也不须要。

假设这样一个场景： 在App1中的登陆界面，调用的Login模块的登陆逻辑，登陆完成后须要跳转用户信息界面。

上面的场景只需直接调用Login模块的逻辑便可，即使发生了不一样UI跳转，也不须要Module通讯，由于全部的UI都写在App1中了。

若是当初将登陆相关的UI也抽到Login模块中，看起来封装度更高，其实有不少不方便。在上面的场景中，须要从Login模块的UI调用其余模块的UI，这样调用流程变得复杂，并且必需要ARouter这样的通讯工具；问题是Login的UI在各个App中不太可能同样，若是同样，那么则能够抽进去。

插件化和热修复

不少大厂的App功能实在是太多，若是一开始就将全部功能都归入App中，体积下不来，问题是有一些功能不少人历来也不用。

因此从使用程度和重要性程度能够划分等级，对于那些次要的功能和模块进行动态化。一开始App只提供部分重要和必须的功能，而且提供一个class运行容器。当用户须要哪些功能是就进行下载，下载下来的无非是一些class和资源，经过定制的类加载器来加载，并作好生命周期管理和资源与Context的统一，这就是大部分插件化框架的原理。

插件化对于大部分中小公司是不须要的，能够根据须要采纳。

热修复是指将新功能或者Fixed Bug快速更新到用户的App中，而不用从新下载App。大体原理是先计算出含有新功能的Apk和旧Apk之间的差别，获得一个diff包，通常很小。而后用户直接下载diff包，App中预先内置了class动态替换的框架，将diff包加载进来就实现了动态热修复。目前热修复存在一些兼容性问题。

不管是插件化仍是热修复，不建议自研，大厂有过丰富的经验和实践，可直接使用目前成熟的类库。

App Bundle

通常来讲，咱们开发的App，里面包含了各类dpi的资源，兼容各类CPU架构的so库，这大大增长了Apk的体积。可用户事实上只须要匹配他手机的一种dpi和一种so库就足够，其余的对于用户来讲都是冗余，上面讲的插件化解决了在功能方面的冗余问题。

能不能将全部的资源，so库等也按需下载安装呢？谷歌在AS3.2中提供的App Bundle功能就是干这个的。以前用户须要下载全部的资源，下载只会下载和本身设备匹配的资源，大大提升了产品的交付速度和交付质量，但是目前只支持Google Play。

App Bundle会将咱们Apk的全部东西打为压缩包上传到Google Play。而Google Play会在用户下载的时候，根据设备特性生成优化过的Apk给用户安装。

App Bundle也支持动态apk，支持将暂时不须要的功能配置为动态功能，在用户须要的时候下载，也就是上面的插件化的功能。

App Bundle应该是插件化和动态化的将来，从工程建设的角度帮开发者完成了产品的动态交付。也许，在不久的未来国内商店也会支持这种功能。

最后

每种架构都用本身的优缺点，不能盲目采用多体的架构，也不能偷懒就永远不升级架构；最终采用什么样的架构要根据本身项目体量和发展来判断。

根据个人经验，对于大部分公司来讲，多体架构的初级阶段就彻底够用了。对于同一个团队须要同时迭代多个项目的场景，可能须要发展到多体架构的第二阶段。对于海量功能的App，可能须要插件化。

这些只是我我的的看法和经验，但愿你们踊跃讨论，交流一下大家的宝贵经验，互相提升下！