万表商城Android架构演进

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_435559203/article/details/84729580

入职万表接近两年,从一入职就进行商城系统全新重构改版,经历过大半年的封闭式加班,到新商城的重构完成紧接着是新商城的业务完善与拓展。见证了开发团队一路走来的努力,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模式写法对比

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

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

组件化方案

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

图:常用组件化

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

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

总结

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

展望

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

参考资料:

猜你喜欢

转载自blog.csdn.net/qq_435559203/article/details/84729580