万表商城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组件化架构》
• 流利说开源