获课：shanxueit.com/12446/

Android架构开发避坑指南：移动项目高频问题全记录

2026年的Android开发，早已不是"能跑起来就行"的时代。从单体应用到模块化拆分，从MVC到MVI，架构演进了好几轮，但奇怪的是——每个新项目依然在踩同样的坑。最近一次移动架构实战班的复盘会上，十几位来自不同团队的Android工程师把各自项目中踩过的坑摆到台面上，发现高频问题高度重合。以下就是这份内部避坑清单的核心内容。

一、架构选型：别为了"时髦"而选

翻车现场： 一个初创团队选了当时最火的MVI架构，因为"谷歌官方示例都在用"。结果三个月后，项目复杂度飙升，State密封类膨胀到几十个子类，每次UI变更要写一整套Redux式的Reducer，开发效率反而比之前更低了。

避坑指南： 架构没有银弹。MVI适合状态复杂、交互频繁的场景（如音视频编辑器），但对大部分表单类应用来说，成熟的MVVM已经足够。选架构的黄金法则是：业务复杂度决定架构复杂度，而不是反过来。同时，务必让团队至少有两人熟悉选型方案，否则遇到疑难杂症时连问的人都没有。

二、生命周期与状态管理：Activity销毁后还在干活

翻车现场： 用户反馈App频繁崩溃，排查后发现是ViewModel里协程在Activity销毁后仍然执行网络请求，回调时尝试更新已销毁的View。另一个更隐蔽的问题是：Fragment重建后，SavedStateHandle恢复的数据与内存数据不一致，导致界面显示错乱。

避坑指南： 所有UI相关的异步操作必须绑定到ViewLifecycleOwner，确保界面销毁时自动取消。使用StateFlow/SharedFlow时，注意区分StateFlow（状态持有） 和SharedFlow（事件触发） ——前者适合UI状态，后者适合单次事件如导航、弹窗。生命周期是Android开发的第一道防线，防线破了，任何架构都是空中楼阁。

三、依赖注入：Dagger/Hilt的"隐形成本"

翻车现场： 项目引入Hilt后，编译时间从2分钟飙升到8分钟，CI流水线频频超时。更棘手的是，某个跨模块的依赖无法编译通过，排查发现是模块间的Component依赖链存在循环引用。

避坑指南： 依赖注入解决的是解耦问题，但带来的编译开销和学习曲线必须计入项目成本。模块化项目中，建议采用组件级Component而非全局单例，避免单例膨胀。如果是中小型项目，手动构造依赖配合ViewModelFactory往往比引入重量级DI框架更高效——前提是你真的需要DI，而不是"大家都在用"。

四、模块化：拆分的艺术与陷阱

翻车现场： 一个电商项目按"功能"拆分成十几个模块，结果模块间依赖关系错综复杂，改一个地方要编译四五个模块。最要命的是：模块A的接口变更忘了同步更新模块B的mock数据，导致测试用例大面积失败。

避坑指南： 模块化的核心是依赖方向向内——业务层依赖基础层，而不是反过来。建议按业务边界（如支付、订单、用户）而非技术分层拆分。每个模块暴露清晰的API模块（含接口定义），其他模块只依赖API而不依赖实现。最关键的是：路由和接口设计在拆分前完成，不要边拆边设计，否则最后会变成一团乱麻。

五、多线程与并发：Kotlin协程不是万能药

翻车现场： 一位开发者用协程的GlobalScope.launch发网络请求，结果Activity关闭后协程还在运行，回调时持有已销毁的Context导致内存泄漏。另一个经典问题是：多个协程同时修改MutableStateFlow，因为未使用update原子操作导致状态更新丢失。

避坑指南： 协程的生命周期必须绑定到ViewModel或LifecycleOwner，永远不要使用GlobalScope。对于共享可变状态，使用StateFlow.update{}或Mutex来保证原子性。并行请求的场景，用async批量启动后awaitAll()，统一处理异常和超时，不要每个请求单独处理失败逻辑。协程让异步编程变简单了，但并发问题仍然需要设计，而不是"靠运气"。

六、测试：不写测试的借口越来越站不住脚

翻车现场： 一个两年历史的项目，测试覆盖率不足5%。每次发版都靠手动回归，最终在一次重构中漏测了一个边界条件，导致支付流程崩溃，线上事故损失惨重。事后追责时发现：如果写了对应的单元测试，这个问题在CI阶段就能发现。

避坑指南： UI层测试用Robolectric和Espresso，业务逻辑层用JUnit+MockK，数据层用TestDoubles（假实现）替代真实网络和数据库。目标是让CI流水线跑一次全量测试不超过10分钟。从今天起，给每个新功能至少写一个覆盖核心路径的测试用例——这不是可选项，而是App稳定性的底线。

七、性能与内存：看不见的债务最危险

翻车现场： 列表滑动掉帧，排查发现是RecyclerView的ViewHolder里每次绑定数据时都重新创建了昂贵对象；另一个问题是图片库加载大图未做采样压缩，导致内存占用飙升。

避坑指南： 性能优化从测量开始——用Android Studio的Profiler、Systrace、LeakCanary定位瓶颈，不要凭感觉优化。列表场景务必启用DiffUtil增量更新，减少不必要的刷新。图片加载使用Coil或Glide的缩放和缓存策略，避免在UI线程做解码。内存泄漏的工具化检测必须集成到CI中，让内存问题在开发阶段就被发现。

写在最后

结课那天，讲师问了大家一个问题："你们觉得Android架构开发里什么最难？"答案五花八门。但最后一位资深工程师说了一句让全场沉默的话："最难的不是技术，是明知道这些问题有标准解法，依然选择'先上线再说'。"

每一个坑，本质上都不是技术问题——生命周期管理、模块化拆分、并发控制、测试覆盖，这些都有成熟的最佳实践。真正的问题在于"轻视"——总觉得这次不会踩坑，结果每个项目都在交重复的学费。

这份避坑清单的意义，不是让你背下来，而是让你在下一次项目启动时，愿意多花一天时间做设计评审，愿意多写几个测试用例，愿意把架构文档补全。架构开发的本质，是用前期的克制换取后期的从容。 这道理，放之四海而皆准。