浅谈项目架构重构之路——概述

忙了一个多月，一直没时间写文章。终于把项目重构完了，借此机会浅谈一下对Android架构的见解。笔者将会把重构分为三个部分讲解。本文为概述篇，主要提及一些前提和想法。

[笔者仍为Android初学者。如有解释错误的地方，欢迎评论区指正探讨]

---

为什么需要重构

笔者接手的这个项目已经有三年多的历史，项目架构也从第一代一直延续至今，可想而知，随着业务需求的迭代，项目也暴露了很多问题。由于业务繁杂，代码结构混乱、层次不清，各业务技术方案不统一，冗余代码充斥项目的各个角落。

早期架构

项目诞生之时，由于业务量不多，采取也是最清晰的分层式结构，如图：

早期架构

嘿嘿，这种分层结构很常见吧？确实对于早期项目而言，业务量不多，这样的结构十分清晰，各个层次各司其职，不过随着业务的增长，单是一个 activity包里就有三十四十个，想想都头皮发麻，这对于项目的 拓展，维护，交接都十分困难，往往每次找一个 activity对应的 fragment或 adapter都要找半天。
在接手之后这个项目后虽然我们也整理一下原先的分包结构，看上去比原来优雅一些：

微调之后的架构

可以看到，将原来全部挤在一起的各个类都重新按模块划分开，各个模块内部依旧保持原来的分层结构。其实这样还是指标不治本，潜在的问题依旧存在。

存在的问题

1. 代码量大，没有严格按照规范，各有各的风格，不利于交接
2. 模块边界定义不清，耦合问题严重
3. Activity和Fragment同时承担了Controller和View的职责，导致他们变得极其臃肿且难以维护
4. 部分模块过分使用继承，导致拓展性极差
5. Common通用模块类膨胀
6. 部门模块因为赶工，使用大量接口回调，内存泄漏严重
7. 业务代码与通用代码混合，修改一处代码可能会牵一发而动其身
8. 第三方依赖添加时没有严格审核，存在重复功能的依赖
9. 业务组件无法实现复用，单独编译

思考

为了解决上述的问题，笔者参考了许多资料，网上对于目前安卓架构这方面的文章层出不穷，从早年提及的MVC，到最近火热的MVP，MVVM，还有一些黑科技，插件化，组件化，模块化等等。
也参考了一些大公司提出的方案：
携程插件化架构
手淘插件化架构
饿了么WebApp架构
微信模块化架构
安居客MVP架构
android-architecture
由于笔者负责的这个项目，在业务需求上与微信相似，核心业务固定，业务一旦成型，变动不大，首页也不像手淘一样多变，所以类似插件化，热修复，WebApp这样的黑科技并不适用，强行引入只会增加开发难度，难以维护。
在综合考虑对于目前项目的业务需求，未来的拓展性，衡量重构所花费的时间与收获价值后，笔者指定了如下方案。

解决方案

在笔者指定方案的时候，还有个小插曲，导师提出打算做影子App的需求，希望能做到提取项目中部分模块快速集成一个新的app，这样的需求对于当时的App根本不可能实现，这也更促使笔者确定重构刻不容缓。
整个方案分为三部分：

• 全局架构——模块化
• 局部架构——mvp+组件化
• 整理第三方库

先放几张图，看一下重构前后的变化：

全局架构变化.png

局部架构变化.png

系统架构设计.png

由于做图时软件出了问题，图片里部分文字会出现错位。将就着看看哈。

对于这三部分，笔者准备以三篇文章来叙述：
模块化
mvp+组件化架构
[第三方库的选择]