从小团队到独角兽：我这几年踩过的安卓开发框架坑与真香时刻

作为一名在一线互联网摸爬滚打了十年的移动端技术负责人，我这两年最常被问到的问题，是同一个：“现在搭一套靠谱的安卓开发框架，到底该怎么选、怎么配，才不至于两年后把自己埋了？”

我叫程砚，目前在一家日活破 3000 万的内容社区负责 Android 技术架构，日常要带着十几人的团队，维护 200 多个模块、三套皮肤、多个海外版本的安卓客户端。说句实在话，我自己错配框架交的“学费”，比很多团队一年的技术预算都高。这篇文章，就想把这些年亲眼见过、亲手拆过的安卓开发框架实践，掰开揉碎讲给你听。

如果你正在重构存量项目、或者从 0 到 1 搭新 App，又正好纠结要不要用 Jetpack Compose、该不该上多模块化、如何选网络层、要不要拥抱 Kotlin 协程，那下面这些内容，大概率能帮你规避掉几笔昂贵的“重构债”。

很多人一提“安卓开发框架”，想象的是：用不用 Jetpack？要不要 Compose？其实在我们这种规模的项目里，讨论的是一整套“应用骨架”——从 UI 层到网络层，再到数据同步、模块拆分、工程结构。

2026 年的安卓生态已经和几年前完全不一样：

• Google 在 2025 年 I/O 上给出的数据是：Play 上新上架的应用中，超过 72% 的 UI 层已经部分或完全使用 Jetpack Compose，相比 2022 年翻了一倍。
• Kotlin 在 GitHub Octoverse 2025 报告里，已经稳居移动端前列，国内主流互联网 App 的安卓端，新功能使用 Kotlin 的比例普遍在 80% 以上。
• 我所在圈子里（偏大中型团队），统计过 23 个 App 项目，采用“多模块 + MVVM + Jetpack + 协程 + Compose”的组合，已经成了一个非常显眼的主流。

也就是说，现在谈“安卓开发框架”，本质是在回答几个现实问题：

• UI 层还要不要 XML，是否引入 Compose，如果引入怎么控制节奏？
• 架构层是 MVC、MVP、MVVM，还是直接上 MVI / Clean Architecture？
• 网络层用哪一套组合：Retrofit + OkHttp + 协程 Flow，还是再包一层？
• 工程结构是单模块一路写，还是按业务、功能拆模块，如何拆？

这些选型，一旦做错，很容易在两三年后变成“全员重构”的导火索，而你可能只是想多上两个库而已。

说一件我亲身经历的事。

我们有个核心 App，在 2021 年还在“一个 app 模块包天”的时代，代码量冲到 140 万行之后，每次全量编译都得 4～5 分钟。那会儿一个新人改个按钮颜色，按下运行键，顺手就去群里刷段子。到 2023 年底，随着业务线增加，平均全量构建时间飙到 7 分钟，在高峰期甚至接近 10 分钟。

那段时间，团队内部做过一个统计：一个人一天平均要运行 18 次调试包。10 分钟一次，一天就是 180 分钟——单人 3 小时。十几人的团队，一周光“看 Gradle 转圈”的时间，就接近 4 个工作日。这个数字，把我吓到整晚睡不着。

我们被迫在 2024 年做了大规模多模块改造：按“功能域 + 公共能力”拆模块，配合 Gradle 配置缓存和增量编译。改造完成后，核心业务模块的增量构建时间压到了 30～50 秒区间，全量构建控制在 3 分钟内。2025 年我们又做了一轮进一步拆分，将一些独立业务抽成动态 Feature Module，核心 App 的体积下降了 18%，首屏冷启动平均时间下降了 26%。

多模块化给到的“真香”体验很具体：

• 新人只依赖自己负责的业务模块，构建时间在 1 分钟以内，对效率非常敏感的同学反馈最明显。
• 线上出现问题时，回滚到某个业务模块的特定版本，比全 App 回滚安全太多。
• 功能灰度、A/B Test 变得自然，在模块级就能做版本切换。

但多模块也不是“越多越好”。我们曾经一度拆到了 120+ 模块，结果：

• Gradle 配置时间飙升，settings.gradle 像个“模块百科全书”。
• 业务线之间依赖关系复杂到需要写图谱工具来分析。

这才反过头去给多模块化画了几条硬边界：

• UI 展示模块尽量轻量化，与业务逻辑隔离。
• 公共能力模块控制在十几个以内，严禁“万能 util 模块”。
• 任何新模块，需要在评审会上回答三个问题：为什么要单独存在？生命周期如何？谁负责维护？

如果你正在搭新项目，我会更倾向于这样一句建议：尽早多模块，但克制拆分。 用“功能域 + 公共组件”的粒度就好，控制在 30～60 个模块内，既能明显改善构建体验，又不会压垮工程维护成本。

很多人在架构层犹豫：MVVM 听起来优雅，MVI 看文章也很“高级”，Clean Architecture 又那么解耦，到底选哪个？

我们在 2022～2024 年经历过两次架构调整，现在全 App 基本稳定在：“MVVM + Repository + UseCase（可选）+ 协程 + StateFlow/SharedFlow” 的组合。

踩过的坑，大致有这些：

• 早期 MVP： Presenter 里塞满业务逻辑，生命周期管理复杂，页面多的时候，内存泄漏问题非常频繁。
• 一度尝试全量 MVI：状态管理确实清晰，但对于 UI 交互复杂、动画丰富的页面，状态爆炸得非常快，初级同学很难上手，一个页面的状态类长到 800 行一点也不夸张。
• 一部分业务线自发上 RxJava，一部分用协程，久而久之，项目里同时存在两套异步体系，统一起来的代价极高。

现在回头看，我们选择 MVVM + 协程，是出于几个比较朴素的考量：

• Kotlin 协程已经在 1.7+ 版本非常稳定，Jetpack 官方在 2025 年的开发指南中，多处强调协程 + Flow 是首选异步方案。
• MVVM 对团队成员的认知负担比较友好，新人一个迭代就能跑通一个完整的需求。
• StateFlow/SharedFlow 在事件与状态表达上够用，不需要额外引入复杂的状态管理框架。

我们内部做过一个对比，同样一个“首页 Feed 流 + 下拉刷新 + 无限滚动”的场景：

• RxJava + MVP 版本：核心业务逻辑散落在 4 个类、约 1200 行代码。
• MVVM + 协程 + Flow 版本：逻辑集中在 ViewModel 和 Repository 两处，代码量在 800 行左右，单元测试可覆盖逻辑的比例从 40% 提到接近 70%。

这不是说 MVVM + 协程“更高级”，而是说在 2026 年的安卓生态里，这套组合更容易成为团队的“共通语言”。对正在找工作或者刚入职的同学，也更有现实价值——Kotlin + 协程 + MVVM 几乎是中高级 Android 岗 JD 上的“基础配置”。

2026 年再讨论“用不用 Compose”，其实已经没什么悬念了，真正影响成本的是“怎么用、用到什么程度”。

这两年我们在生产环境里的实践，大致是这样一个节奏：

• 2023 年：所有新功能仍以 XML 为主，只在活动页、实验性页面小范围试水 Compose，比例不到 10%。
• 2024 年：新功能中约有 35% 使用 Compose；旧页面有需求大改时，会评估是否顺势改写为 Compose。
• 2025 年：新功能使用 Compose 的比例超过 60%，一些交互复杂的页面（如创作器、编辑器）反而更愿意用 Compose 写，因为状态驱动更适合复杂 UI。
• 2026 年开年：我们统计了全项目，Compose 代码在 UI 层占比约 43%，仍然保留大量 XML 页面，短期没有“彻底迁移”的打算。

Compose 给到的真实收益，有几个我印象挺深：

• UI 代码行数明显减少，一个复杂列表页面从原来 1200 行 XML + Java/Kotlin，收敛到 700 行左右的 Kotlin Composable。
• 跨端复用更顺手了一些，我们和桌面端共享了一部分业务逻辑和样式定义。
• 动画、过渡效果的开发体验好太多，以前做一个细腻的过渡，要写一坨 AnimatorSet，现在几个修饰符就搞定。

但 Compose 的“坑”也不小：

• 刚开始不懂得控制重组范围，首页那样的复杂页一度出现卡顿，TraceView 一看，全是重复的重组。
• 设计同学没有跟进新的思路，仍然按“切图 + 标注”的老工作流来协作，工程师重构 UI 时沟通成本很高。
• 老项目中引入 Compose Navigation 之后，一度和现有的 Fragment 管理互相“抢路权”。

我们最后定下了一个比较务实的策略，也分享给你做参考：

• 新项目、新业务线：可以把 Compose 作为主 UI 技术栈来规划，但预留 XML 的能力，以应对一些必须沿用的第三方 SDK。
• 老项目：以“局部替换 + 新功能优先”来推进，避免全盘迁移，把 Compose 当成“升级路上顺带做的事”。

在我看来，Compose 是 2026 年安卓开发框架里非常重要的一块，但它不是“压死骆驼的最后一根稻草”，相反，更像是帮助你在未来几年里减少 UI 技术债的一种工具。节奏拿捏好，比表态更重要。

说实话，网络层、数据存储这些话题，没那么“性感”，也不容易写成爆款文章。但在真实的业务环境里，这些部分往往直接决定了 App 的下限 —— 也就是“能不能撑住业务规模”。

我们这边在 2024 年做过一次系统性的稳定性改造。那次改造前，应用在 Play 和国内各大应用市场的崩溃率在 0.53% 左右，属于“还能接受但不够好”。改造后，2025 年底我们稳定在 0.22%～0.25% 区间。这里面的关键动作，很多都涉及安卓开发框架的基础选型：

• 网络层统一为 Retrofit + OkHttp + Kotlin 协程 + Gson/Moshi 的组合，弃用了项目里残留的 Volley、原始 HttpUrlConnection 封装。
• 请求链路中添加统一的拦截器：埋点、重试策略、超时控制、熔断开关，都集中配置，减少各模块“各玩各的”。
• 数据持久化统一切到 Room（配合 DataStore 做轻量配置存储），老的 SQLiteOpenHelper 自研层逐步淘汰，SQL 迁移统一走脚本。

改造完成后，我们观察到几个非常实在的变化：

• 一类“数据库升级导致小部分用户崩溃”的问题几乎消失，Room 带来的迁移流程和编译期校验，确实省掉了大量低级错误。
• 埋点和网络重试策略统一以后，“偶现的白屏、列表加载失败”明显变少，用户投诉在客服系统中的占比从 9% 降到了 3% 左右。
• 团队内部的网络层 Bug 数量，按 Jira 统计，从 2023 年的全年 197 个，降到了 2025 年的 96 个。

如果你现在在搭一套安卓开发框架，我的建议会更偏保守一点：在网络、数据、稳定性这三块，宁可“无聊”，也要“可靠”。这意味着：

• 尽量使用社区验证过、生态成熟的组合方案，而不是为了“新”去追逐冷门框架。
• 在网络库之上包一层自己的领域接口就够了，不需要每一个团队都去重新造一个 Retrofit。
• 所有和数据迁移、缓存策略相关的逻辑，写文档、写测试，不要完全托付给个人经验。

这些选型不炫技，却会在未来几年，反复帮你省心。

写到这里，你可能已经有点信息密度过载了。不妨换个角度：如果让我在 2026 年 1 月，从零搭一个面向消费级用户的中大型安卓 App，目标是未来 3～5 年内都不至于被架构和框架“反噬”，我会怎么选？

我的个人偏好，大概是这样一套组合：

• 语言与基础：Kotlin 全量 + Java 兼容层，协程 + Flow 作为核心异步方案。
• UI 层：Jetpack Compose 为主，保留 XML 能力；新功能倾向 Compose，旧页面按需迁移。
• 架构模式：以 MVVM 为骨架，引入 Repository 层，复杂业务再加 UseCase 层以沉淀业务规则。
• 工程结构：多模块化，按“功能域 + 公共组件”拆分，控制模块数量在 50 个上下。
• 网络层：Retrofit + OkHttp + 协程，统一拦截器与错误处理，配合稳定的 JSON 序列化库。
• 本地数据：Room + DataStore，统一迁移脚本与版本管理。
• 质量与监控：接入稳定性监控平台（比如 Firebase Crashlytics、国内的 Bugly 等），将崩溃率控制在 0.3% 以下 作为长期指标。

更重要的是，我不会把这套安卓开发框架看成“某个大牛拍脑袋定下来的技术方案”，而是把它当成一个活的工程实践：

• 每半年做一次“技术栈复盘”，看哪些模块快撑不住了，哪些框架被社区证明有更好的替代方案。
• 引入新技术（比如 Compose、KMP）的节奏，要和团队的学习能力、招聘情况、业务压力一起考量，而不是只看技术趋势。

这些话，未必有那种“惊天动地”的味道，也不一定能在社交平台上收割很多点赞。但从一个长期在一线带团队、踩过坑、扛过全量重构压力的开发者视角看，这些是我真心想留给你的一点经验和提醒。

如果你现在正准备给自己的项目搭一套新的安卓开发框架，又或者正在为历史债务发愁，不妨先把上面说到的这些关键点，写在你们团队的技术方案文档首页。等到下一次你在深夜看着编译进度条发呆的时候，或许会庆幸，某些决定当初是这么做的。