获课：shanxueit.com/12446/

重构之路：一个Android项目的架构蜕变手记

去年春天，我接手了一个让人头疼的Android项目。这是一个上线三年的O2O电商App，日活稳定在五十万左右，但代码库已经成了名副其实的"屎山"——六个开发人员在里面并行作业，每次发版都像拆弹，改一行代码能崩三个模块，紧急修复补丁几乎成了每个版本的标配。用户的差评集中在"卡顿""闪退""加载慢"，业务方每天都在催新功能，但现有架构已经连修Bug都吃力。老板丢给我一句话："三个月，把架构理清楚。"

这不是一个可以纸上谈兵的任务。我需要在不停止业务迭代的前提下，完成一次心脏搭桥手术。

诊断：先搞清楚"病"在哪儿

动手之前，我花了整整两周做诊断，不写一行代码。用Android Studio自带的Profiler跑性能数据，用Lint做静态代码扫描，用依赖分析工具梳理模块间的调用关系。结果触目惊心：一个原本应该干净的"订单模块"，竟然直接依赖了"支付""用户""消息""物流"四个其他模块，形成了蛛网状的循环依赖。任何一个模块改个字段，牵连的编译错误能达到两位数。

更深层的问题是分层混乱。业务逻辑和网络请求混在Activity里，数据缓存和UI渲染杂糅在一起，没有人能说清楚"这个数据到底在哪里存的、从哪里来的"。新人入职第一个月基本在踩坑，而不是在产出。代码的可维护性指数已经跌破了红线。

诊断报告出来那天，我画了一张"依赖关系图"，密密麻麻的线条连成一片，像一张蜘蛛网。我把它投在会议室的大屏上，团队成员沉默了整整一分钟。然后有人说："原来我们一直在这种代码上工作。"这一刻，所有人都明白了——架构重构不是锦上添花，是生存问题。

方案：分层、模块化、单向依赖

核心策略很明确：建立清晰的分层架构，强制单向依赖。我们把整个App拆成三层：底层是基础组件层（网络、数据库、日志、图片加载），中间是业务组件层（订单、支付、用户、消息等独立模块），最上层是展示层（Activity和Fragment，只负责UI渲染和用户交互，不包含任何业务逻辑）。

三条硬性规则从第一天就开始执行：

• 上层只能依赖下层，同层之间不允许互相依赖

• 业务组件之间通过接口和事件总线通信，禁止直接持有对方实例

• 每一个模块必须有明确的边界，对外暴露的最小接口要经过评审

这个方案不花哨，甚至有点朴素。但正是这种"朴素"保证了它能够被执行、被理解、被遵守。我们不是在造一座水晶宫，是在给一座正在运行的工厂重新布线，一切要以稳定为前提。

执行：从边缘向核心推进

重构最怕的是"大爆炸式"——停掉所有业务，花几个月重写，然后一次性切换。这种做法在理论上是干净的，在实战中几乎是自杀。我们的策略是从边缘模块开始，逐步替换。

第一个被改造的是"消息通知"模块。它相对独立，对其他模块的依赖最少，像一个"可以安全手术的器官"。我们把消息的拉取、存储、展示从Activity里剥离出来，封装成独立组件，内部用MVVM模式重新实现，对外提供清晰的接口。改造后模块的代码行数从三千行缩减到一千两百行，单测覆盖率从0%提升到76%。重要的是，这个模块后续两个月再也没有因为其他模块的改动而"无辜躺枪"。

尝到甜头后，第二个是"搜索"模块，然后是"购物车"、"个人中心"……每改一个模块就上线验证，灰度一周确认无问题再推进下一个。这个过程持续了两个多月，期间业务需求照常迭代，但每次新需求进来，我们都会优先在"已重构"的模块里实现，逐步扩大健康代码的版图。

最艰难的是"订单"核心模块的重构。它几乎被所有其他模块依赖，牵一发而动全身。我们做了两轮预研，先在分支上完整实现了一套新方案，然后用A/B测试的方式让部分用户走新逻辑、部分用户走旧逻辑，对比稳定性数据。确认新方案在所有指标上都不逊于旧方案后，才全量切换。整个过程从设计到上线用了三周，没有发生一次线上事故。

沉淀：架构不是一次性工程

重构完成后，很多人以为"事儿完了"。但真正让我觉得项目成功的，不是新架构跑起来了，而是团队开始主动维护架构了。

我们建立了"架构评审"流程，任何涉及跨模块调用的改动都必须经过评审，确认不破坏分层原则才能合入。每周的代码审查里，"这个依赖方向对吗？"成了高频问题。新入职的工程师按着分层文档和模块接口说明，一周就能独立开发，再也不用花一个月去理解代码在哪。

那个曾经做架构诊断时沉默的团队，现在能自己画模块依赖图、自己发现循环引用、自己提重构提案。这才是架构重构真正想要的效果——不是造一个完美的系统，是造一个能让团队持续进化的系统。