Android组件化实践2——经典组件化项目架构

Android组件化实践2——经典组件化项目架构

京东的采用aab( Android App bundles)之后的架构图

安居客项目架构演化

参考：https://zhuanlan.zhihu.com/p/25420181

安居客在业务上完成了三网合并（新房、二手房、好租和商业地产多个平台的合并），冗余代码充斥项目的各个角落，于是梳理了整个项目的结构。同时开发了自己的UI组件库UIComponent、基础工具库CommonUtils、基于第三方地图封装的MapSDK、即时聊天模块ChatLibrary等等。

安居客有是三个业务团队：安居客用户app、经纪人app、集客家app。为了提供更多的、职能单一、性能更优的功能提供给不同团队使用，采用了组件化的方式，将这些组件分为：基础组件和业务组件。

最终在采用mvp和组件化之后的安居客app整体设计：

 

饿了吗项目项目架构演化

饿了么移动对于组件有两种定义：公有组件和业务组件。

对于公有组件，饿了么移动采取了版本化的管理方式。

对于业务的组件化，我们采取了业务模块注册机制来达到解耦合的目的。每个业务模块对外提供相应的业务接口，同时在系统启动的时候向Excalibur系统注册自己模块的Scheme（Excalibur是饿了么移动用来保存Scheme与模块之间映射的系统，同时能根据Scheme进行Class反射返回），从Excalibur系统中获取相关实例，并调用相应接口来实现调用，从而实现了业务模块之间的解耦目的。

根据80%的用户访问20%页面这一80/20原则，保证这20%访问最频繁的页面的稳定性就是保证了80%的APP的稳定性。因此，饿了么移动对于部分访问最频繁的模块进行了React-Native备份。当这部分页面出现问题时，APP可以通过服务器的配置，自动切换成React-Native的备份页面。而与此同时开发人员开发一个小而精的Hot Patch来修复出现的问题。当Hot Patch完成修补后，再切换回Native APP的原生功能。

架构更新为：

 

微信Android架构

参考：https://blog.csdn.net/seu_calvin/article/details/77149750

最初的微信架构：

但是由于代码膨胀，基础工程出现了中心化问题，导致许多业务存储类被附着在一个核心类上于是组件结构出现了问题：

 

膨胀的来源很多来自业务相关代码。因为不同模块有共用的数据结构类，不得不把类进行下沉，这就造成了基础工程的臃肿。同时还伴有模块边界破坏、基础工程中心化，都是代码持续劣化的帮凶。

解决方案是

• 改变通信方式：EventBus需要知道确切的baen格式，所以采用协议通信的方式，绕开让不同的功能耦合不必要的对象。

• 重新设计模块

• 约束代码边界：消灭代码经常下沉的“三不管区域”——基础工程。这意味着原来的模块要把之前下沉的代码重新认领回去。然后再遍以上进行隔离(没弄过，不知道流程)。

最后的架构：

反思：

目前Android端App整体架设计上，主要有几个分支：

• App“大前端”化

• 插件化/应用沙盒（可以参考如atlas、small、DroidPlugin、DynamicApk等等方案）

不难发现让模块最终具备动态性是它们最核心的能力。

插件化/应用沙盒：好处是它具备很强的隔离性，有些方案可以彻底隔离代码和资源，边界限制性极强，效果很好。此外，多数方案也都具备动态更新能力、补丁能力，动态性基本成为标配。但是沙盒隔离容易导致代码复用困难和相互调用麻烦，对于开发除了造成开发效率减慢，同时也会因为复用不了功能，从而造成代码臃肿。所以，没有绝对的好框架，只有合适自己项目的框架！

我的正在实践施工的项目地址：

https://github.com/huhanghao/MvpModuleFramework