万表商城Android架构演进

入职万表接近两年，从一入职就进行商城系统全新重构改版，经历过大半年的封闭式加班，到新商城的重构完成紧接着是新商城的业务完善与拓展。见证了开发团队一路走来的努力，Android团队也在自己的想法中向前迈进。

前言

在公司的发展方向上，从以前单一的万表商城App,延伸到服务类的万表名匠App、资讯类的万表世界App等多个还在孵化的项目，让我察觉到了万表商城App作为主流量入口，将来一定程度上会集合万表名匠、万表世界到主项目中，所以组件化必然是正确的演进方向。在项目gradle升级到3.x后，依赖隔离的新特性更是帮助我对组件化的推进工作。另外不得不吐槽自己对项目的gradle3.x的更新经历，虽然gradle3.x的升级布满着深坑，但是自己竟然在从2.3.3升到3.1.4足足花了4个多月的时间，一方面项目需求任务繁重，每次升级都是在发包后到新一个开发任务的夹缝中进行，然后在gradle3.0.x泥潭上无法自拔，再到gradle3.1.4的release包启动闪退问题提示一直无法准确定位，终于自己在不断试错下在External Libraries翻源码发现是某一个第三方的源码引起的问题，当成功升级解决问题后，发现自己几度放弃的问题答案，原来一直躺在转弯处，心疼自己。

组件化优点

在现在的大环境下组件化的优点相信大家都比较熟悉。

• 高内聚，低耦合，代码边界清晰，每一个组件都可以拆分出来独立运行
• 功能集中，每一个组件负责属于自己组件的工作，不受其他组件影响也不影响其他组件功能
• 提高开发效率，每个组件可单独调试，保证代码质量
• 减少重复造轮子和维护工作量
• 加快编译速度，最理想的情况是，App工程仅仅是一个空壳，用于加载各个组件

竞品对比

对于一个商城项目，我们经常会对竞品进行研究。下面我们来看看竞品的首页项目结构。

毕竟这里只是是首页的package结构，我们不好推测，但是我们还是能看出不少东西来的。

现状

在以前的代码风格是喜欢封装一个工具类库，将非业务性的代码放在单独的库中管理维护，我司也一样，同样有一个内部维护的toolkit库，但是这种方式不再适用于不断拓展业务线、创建公司生态圈的，如上面所述，我们的服务类App、资讯类App并不适用商城App所封装的工具类库，因此组件化能帮助我们将业务Module与工具Library不断细化，从而达到我们复用的目的。

另外现在很多项目都是流行MVP模式，我司也一样。MVP的封装方向在一定程度上都存在着不少的差异性。下面我们来看看样例。

我们可以看到旧的MVP写法是将所有的Activity.class都放在同一个package，这种写法是因为思想从MVC转变到MVP中，以前MVC我们或多或少都是这样干过，而在不断的实践中改进，右边的MVP模式更为适合我们，我们将用功能模块作为粒度，将每一个模块分开，这就是我们所说的模块化，现在我司项目就是完全按照模块化来开发，每一个功能模块都十分清晰，但是带来的弊端就是代码量会较大。

可能有部分同学对组件化和模块化的理解还是比较模糊。我们通过比喻来理解比较容易区分。组件化它们相互独立，每一个组件都能单独抽出来进行运行，而模块化是按照功能模块的搭建，模块化间都存在一定的关系和联系。如商城首页模块和文章模块都有视频播放的功能，这时的视频播放就出现来耦合情况，此时组件化就很好处理，我们将视频播放单独处理成一个组件，让首页模块与文章模块来调用同一个视频播放组件。所以说组件化比模块化的粒度更小。

组件化方案

现在GitHub上面流行着各大家公司开源的路由库，他们基本采用组件化的方案是

这个是比较通用组件化的一个方式，当然不同厂有着会根据自己的实际情况进行改造流程，但是基本大同小异，我们五花八门讨论得最多的是不同业务组件的路由通讯协议封装，我们将一个个业务组件细化拆分，不可能最后是互相直接依赖使用导致各种混乱和耦合，我们此时需要的是路由，它帮我们管理各业务组件间有序地通讯，路由重点划一下:事件分发和动态拦截。

在参考前面的竞品，结合公司的组织架构，对自己商城App分析定制。我第一期组件化的工作方向是功能模块化与业务组件化相结合。这是因为我们项目是一直遵循着模块化，对功能的整理比较好，我这边不对每一个业务进行拆分组件化，也就是不采用现很热门的路由通讯方式，因为如果我将项目弄成完全组件化，是过度封装了，导致开发成本不协调，然而目前我们首要处理的问题是业务组件复用问题，所以避免我们另外两款App重复造轮子，我们先将咨询组件、支付组件、定位组件、网络请求组件、推送组件进行分离，同时优化封装图片加载库、普通工具库、Banner工具库、友盟第三方库、图片选择库、JSBridge库等非业务性的基础库。

总结

组件化的推进工作，从简单的分离代码，里面帮助我们更好地梳理了陈旧代码，及时整理好wiki。到享受面向过程、面向对象、面向接口、面向切面的编程乐趣。

展望

到了最后，这次商城组件化构架演进，只是一个开始，就如一开始所说的，将来会有一天多款App会进行整合，我个人推荐的是通过插件化的方式加载对应的业务模块，在前段时间官方所推出的动态化框架Android App Bundles更适合未来的发展。另外在未来大前端完全介入商城日常开发，架构还会继续进行调整。以上是我的简单总结和对模块化的一些尝试，不足之处还望大家交流指正。

参考资料：

• 苍王的《Android组件化架构》
• 流利说开源