主页 > 案例 > Android学习 > JavaScript教程 Android学习 ASP.NET JAVA

沪江学习安卓端重构实践

辰乐科技 | 发布时间: 2018-04-07 22:59

对于大的架构重构,其实我们一直很谨慎的。我们的原则是将重构融合在每次迭代中,逐步优化代码的结构。这次针对整个应用的架构的调整的背景是公司移动开发部门的人数和项目越来越多,当初设计的移动端的架构让项目的依赖关系越来越复杂,维护成本也越来越高。刚好赶上公司产品的特别需求,我们决定梳理并优化一下整个项目解构。在实施过程中,我们依然坚持将整个重构的过程融合在每个迭代中,逐步完成一次大的架构升级。

目标

如图所示,这次重构围绕一个老生常谈的概念「解耦」展开,设定几个目标:

清晰划分各模块的角色

明确架构层级及各个模块所在的层级

提高整个架构横向扩展的能力

提高编译效率,由于我们项目大量使用 Kotlin 开发和 AOP 技术,在编译上面个比较耗时,期望在架构调整后,在整个项目的编译效率上又一次大的提升

各模块独立开发,面向接口和协议编程

提高可维护性

现状

相关厂商内容

用Kafka Streams搭建实时的广告消费系统 OpenResty十年开源的历程和思考 阿里巴巴Blink流计算平台介绍与实践 Apache Kafka的过去,现在,和未来 实力操盘中奖JBL,了解一下?

相关赞助商

在重构之前,我们的应用架构可以大致分为两层,应用层和 Library 层。一些通用的 Library 主要由专门的部门的同事维护,各业务线也会有一些自己维护的依赖库,也属于 Library 层。各业务线的主应用通过直接依赖的方式使用所需要 Library 提供的功能。

各个 Library 之间的依赖关系也是通过直接依赖的方式,由于没有一个明确的层级划分,随着 Library 数量的不断增加,他们之间的依赖关系变得越来越复杂,大致是这样一个状态。

(点击放大图像)

这样的应用架构在一个相对小的团队中,可以很好的满足需求,将单独的功能模块和业务模块直接抽离成依赖库的方式去维护,可以降低模块之间的耦合性,又能保证不同应用能够使用统一的公共服务(Library)。但当开发团队发展到一定规模,由于模块数据的增加,模块之间的依赖关系错综复杂,各业务线的业务需求千差万别,这样简单的架构就会显得捉襟见肘了。下面的情况常常让人很头疼。

依赖库之间的强依赖。其中一个最为突出的问题,就是库与库之间的强依赖关系。比如我用了一个库 A,A 使用 B 库来实现网络访问,但是在我的主项目中 C 来实现的网络请求。这种情况就会导致在主项目中同时依赖了两个网络请求库。

未知调用潜在风险大,版本升级成本高。由于没有明确的接口约定,往往会发生修改某个看似不会被外面调用到的方法,却导致某个项目的崩溃。同时由于依赖关系的复杂性,当一个项目发生升级以后,需要花很大的精力去确定到具体影响到哪些项目。

模块方案发生变化,上层修改成本大。由于是直接依赖的方式,在使用依赖库的时候,大家常常是直接使用库里面提供的接口,这样当某个功能需要切换实现方案的时候往往会导致上层代码的大量修改。

依赖库之间的版本冲突。主项目依赖的某库的版本和依赖库里面所依赖的同样的库的版本发生冲突。

功能模块兼容性导致维护成本大。在层次关系不够清晰、只有模块划分的时候,各业务线对公共模块需求有所差异,导致库的兼容代码越来越多,不易维护。甚至当某个模块为了满足某个业务线的特殊需求而影响到其他业务的正常使用。

上面的这些问题,如果在规模相对小的团队中,也许表现的不是特别突出,但是当团队规模到达一定程度,存在多条主开发团队在开发不同的业务,同时又想共用许多公共模块的时候,就会经常困扰开发团队。我们可用通过一些规范或约定来规范大家的行为减少这些问题发生,也可以通过构建一些辅助工具或平台帮助我们将一些问题提前暴露出来而不至于影响到线上应用,但这终究是治标不治本。

重构方案

相关热门文章

服务热线