★ FEATURED ARTICLE 做移动端开发这些年我见过太多团队在架构这件事上反复折腾今天引入 MVVM明天换成 MVI后天又嫌麻烦退回 MVC。其实架构本身没有绝对的对错问题通常出在选型时没想清楚自己的业务形态和团队规模。这篇避坑指南就是想把我在移动端架构设计、性能优化、前后端协同这些环节踩过的坑、修过的车都摊开来讲一讲。适合那些正在做 App 架构选型、或者已经在线上环境里被性能问题追着跑的开发者参考。1. 架构选型先想清楚你要解决什么问题1.1 MVC、MVP、MVVM、MVI 到底怎么选很多团队在架构选型上有一个通病盯着技术名词选型而不是盯着问题选型。今天看到别人说 MVI 好明天看到 Redux 社区活跃就想把整个项目推翻重来。我见过一个做工具类 App 的小团队业务逻辑就是几个计算页面非要用 MVI Flow 单向数据流结果状态事件写了一大堆改一个按钮的交互要动四个文件交付效率反而不如之前的三层结构。这里我给出一个比较务实的判断标准你可以直接对照自己的业务场景来选架构模式适合场景常见风险我推荐的适用门槛MVC页面简单、逻辑少、团队小Controller 容易膨胀Activity/Fragment 内逻辑超过300行就该考虑升级MVP业务逻辑多、需要单元测试View 接口爆炸有 3 个以上页面做同样的数据转换逻辑时MVVM数据和视图绑定频繁、中大型项目DataBinding 排错难页面内超过 5 个以上的数据-视图绑定点MVI状态复杂、需要可追溯样板代码多、思维负担重需要回放用户操作轨迹的金融、电商类页面你说一个表单页面用户填完姓名、手机号、验证码点提交等结果这本质上就是输入 - 处理 - 输出拿 MVC 三层就够了。但你如果做一个复杂的视频剪辑 App时间线上的每一个操作都要可撤销、可重放那确实应该上 MVI因为你需要把每一次状态变更都作为不可变对象记录下来这样才能支撑撤销栈和远程同步。1.2 从架构洁癖到工程妥协状态管理的尺度架构圈有一种风气特别追求理论上的完美。六边形架构、Clean Architecture、依赖倒置听起来都很高级但落到移动端这种资源受限、包体积有上限、启动时间要卡秒的环境里很多东西是要打折的。我举个具体的例子。按 Clean Architecture 的标准Domain 层不应该依赖任何框架UseCase 要一个用例一个文件。你写一个用户登录功能可能需要新建 LoginUseCase、UserRepository 接口、UserRepositoryImpl、UserRemoteDataSource、UserLocalDataSource、UserMapper 这一堆文件。如果是 100 个业务功能那就是 500 个文件起步。这时候你还要保证每一层之间的映射正确否则光是 DTO 转 Entity 再转 Model 的样板代码就能吃掉你 20% 的开发时间。我的实际建议是如果你在做一个生命周期预期 2 年以内的产品型 App别用超过三层的抽象。ViewModel 这一层足够承载大部分业务逻辑Repository 做数据来源的隔离就已经覆盖了 80% 的需求变化场景。真正的架构是在未来可能怎么变和今天怎么能跑起来之间找到一个合理的折中点。1.3 数据层与网络层的边界问题聊完状态管理再说一个特别容易被忽略的地方数据层怎么设计才不会被后端接口拖着走。很多团队的数据层就是简单地对齐后端接口后端返回什么字段前端 Model 就定义什么字段。这样做在初期没什么问题但后端接口是会演进的。我遇到过这样一个场景后端同事在订单接口里新增了一个必填字段 deliveryType直接返回了一个整型枚举而老版本 App 的 Model 里根本没有这个字段。结果客户端侧的反序列化框架在遇到未知字段时默认忽略了但之后提交订单时后端开始校验这个字段导致线上老版本用户全部下单失败。正规的做法是移动端的数据层必须有自己独立的 Model 体系而不能直接把后端 DTO 当 UI Model 用。Response - Domain Model - UI Model 这一层转换不能省。哪怕你现在觉得麻烦也要在 Repository 层做一道映射这样后端突然加字段、改类型的时候你只需要在 Repository 层兜底处理而不是全局搜索替换。另外一个非常重要的动作是App 包版本要跟后端 API 版本做绑定管理每次发版前把接口字段清单对一遍新增必填项的老版本客户端要做降级处理这也是我在移动端表单必填项这个关键词相关的问题里踩坑之后才补上的机制。2. 性能优化别等线上报警才想起查指标2.1 冷启动优化的落地方法冷启动时间是用户对 App 的第一印象也是移动端性能优化里最不能糊弄的指标。很多人只知道盯着启动页看以为闪屏时间短就代表启动快其实真正的冷启动是从用户点击图标开始到首页第一帧真正绘制完成的总时长。具体的测量方法是这样的Android 端可以通过系统自带的 ActivityManager 日志来统计冷启动耗时或者直接使用 Android Studio 自带的 Profiler 工具里的 CPU Profiler 看启动线程的调度情况iOS 端则依赖 Instruments 里的 App Launch 模板它会把动态链接库加载、Objective-C 类初始化、静态初始化器都分成段给你展示。我实测过的一个典型案例有一个项目启动时在 Application 的 onCreate 里初始化了一个大而全的 SDK 列表包括推送、地图、IM、埋点、热修复等等十几个 SDK。整个初始化的耗时加在一起差不多占了冷启动总时间的 45%。后来我们做了一轮启动优化把 SDK 的初始化分成了三类必须在 Application 里同步初始化的比如崩溃收集可以放到第一个页面空闲时再初始化的比如 IM 连接以及可以放到工作线程池里异步初始化的比如埋点。就这么拆分冷启动时间从 2.8 秒降到了 1.6 秒体感上差别非常明显。我还想提醒一个容易被忽略的坑很多第三方 SDK 提供所谓异步初始化接口但底层其实还是有同步的锁等待或者主线程回调用。判断一个初始化是不是真的异步你不能只看文档得用 Profiler 去实际抓一遍主线程的执行记录。凡是出现在主线程执行区域里的初始化代码不管文档怎么写都算阻塞启动的。2.2 CPU 与内存的隐形犯罪现场移动端 CPU 天梯图这类东西偶尔看看是有用的它能帮你在测试阶段就确认你的 App 在低端机比如三四年前的入门芯片上会不会卡成幻灯片。但更重要的事情是你要养成主动排查 CPU 和内存问题的习惯而不是等用户骂了再修。先说 CPU。我处理过最头疼的一类问题叫高 CPU 占用但看不出明显卡顿通常发生在图片加载、列表滑动这些场景。排查方法是用 Profiler 的 CPU 录制功能抓一段 10 秒的采样记录然后看哪些方法的 Self Time 占比最高而且这个方法可能会把图片解码内存复制序列化/反序列化这类底层操作暴露出来。很多情况下你会发现罪魁祸首不是业务代码里的死循环而是某一行格式化的字符串拼接或者一个频繁创建的临时对象。再说内存。移动端内存抖动最典型的表现是列表快速滑动时帧率掉到个位数而且界面有明显的卡一下、顿一下的感觉。这个时候你用 Memory Profiler 去录制内存分配大概率会看到堆内存像锯齿一样上下跳动这是因为列表项的复用机制没有做好每一项都创建了大量新的对象。常见的修复方案是使用 RecyclerView 的 ViewHolder 复用、图片库开启内存缓存、避免在 getView 里做字符串相加或者 JSON 解析。JSON 解析这个坑我想单独拎出来说列表滑动过程中如果每一帧都去解析一整个 JSON 数据源那性能一定好不了正确做法是提前把数据解析成强类型对象并缓存住。2.3 系统级定制与多版本适配的兼容之痛热词里有一个android 12 systemui 架构这确实是很多定制系统开发团队的痛点。大量做系统级 ROM、做企业定制设备的团队都需要直接修改 SystemUI 这个进程的架构。SystemUI 在 Android 12 里做了大幅重构引入了 NotificationShadeWindowController 之类的模块化设计对不同版本的适配要求很高。这里我不展开 SystemUI 的具体源码细节只说一个做定制的通用避坑经验千万别在你的 App 里依赖任何系统进程的系统 API 字段因为厂商 ROM 往往会修改这些字段。我在一次企业项目交付中遇到的情况是状态栏的某个系统字段在 Android 12 上返回的是 Int 类型到了 Android 13 上被厂商改成了一个封装类结果客户端直接崩溃。从那以后我们团队定了一个规矩所有需要访问系统级参数的代码必须集中在同一个 SystemInfoBridge 类里由这个类做抽象和降级。只要系统字段的解析逻辑变了影响范围也局限在一个文件里而不是散落在整个项目的几十处调用点。3. 前后端协同微服务化之后移动端的日子反而更难了3.1 当后端拆了 30 个微服务移动端该怎么活移动端架构避坑坑通常不只在移动端这一侧前后端的协作方式才是最大的变量。这几年很多公司都在搞微服务架构后端一个订单服务一个用户服务一个支付服务边界划分得很干净。但这对移动端来说未必是好事因为移动端的一个页面往往需要同时调用三到五个服务的接口才能拼装出完整的数据。我见过一个很极端的项目首页设计稿只需要展示用户信息、订单列表、推荐商品三个模块按理说一个接口就能搞定的事后端拆完微服务后变成了三个接口而且三个接口的响应速度还不一样。移动端只能并行发起三个请求再做数据合并还要处理其中某个请求失败之后的局部刷新逻辑。首页首屏从原来的 800 毫秒变成了 1.8 秒用户流失率明显上升。这个问题在行业内有一个相对成熟的解法叫 BFF 层Backend For Frontend也就是在后端和移动端之间增加一个聚合层由服务端来拼装移动端需要的聚合数据。如果你所在的团队有能力推动 BFF 层的建设我建议你优先推动接口聚合而不是在移动端做大量的请求编排。如果在你的决策范围内没法新增 BFF移动端也要在架构上做配合用协程或者 RxJava 把多个并发请求的返回结果用状态机管理起来定义好 Loading、Partial Success、All Success、All Failed 这四种状态不能只处理全部成功这一条路径。3.2 分布式环境下的容错与降级要怎么做微服务化之后网络请求的出包率会明显上升。以前一个接口一个请求失败的概率相对低现在要合并五个接口只要其中有一个不稳定页面的整体体验就会被拖垮。移动端作为调用链路的末端必须建立自己的容错和降级机制。我建议你在网络层至少做几件事第一全局超时时间要分级。纯数据接口 5 秒超时图片类接口 10 秒超时上传文件接口 30 秒超时不能一刀切。第二要区分失败和降级。比如用户详情接口挂了第二次请求直接用本地缓存展示上次的数据同时在界面上提示数据可能不是最新这是降级而首页首屏接口挂了直接展示错误页让用户点重试这是失败。降级能明显提升用户的忍耐度。第三每个请求都要能识别当前 App 的版本号和用户 ID。后端做灰度发布和问题定位的时候这两个字段能帮你省下大量和运维扯皮的时间。幂等性这个点也值得展开。移动端在弱网环境下很容易出现请求超时但服务端已经处理成功的情况这时候客户端一般会提示用户重试但重试本身如果没有幂等机制就可能造成重复下单、重复支付。架构上比较标准的做法是客户端在发送关键请求支付、下单、领取权益时生成一个全局唯一的 requestId服务端用这个 requestId 做去重。你别把这个当成后端的事移动端架构师要在接口设计阶段就把这个参数约定好否则后面出问题用户骂的是你的 App 不稳定。3.3 离线缓存与增量同步的权衡移动端的网络环境远不如桌面端稳定地铁里、电梯里、地下车库随时都可能断网。如果你的 App 不做离线缓存那用户一旦处于弱网状态体验就是一落千丈。但离线缓存也不能无脑做缓存策略的设计要和你业务数据的实时性要求匹配。我的经验是分三类来处理。第一类配置类数据比如 App 的功能开关、活动页配置用启动时拉取 本地持久化 过期自动刷新的模型一般来说配置数据可以接受半小时到一小时的延迟。第二类用户私有数据比如收藏列表、购物车优先从本地读取同时在后台做增量同步增量同步时要注意冲突处理。第三类实时性要求极高的数据比如 IM 消息、实时价格不能依赖缓存只能通过网络层做长连接或者轮询。4. 跨端与硬件差异一套代码走天下的幻想4.1 ARM 架构下的 ABI 适配问题移动端圈子这些年一直在讨论跨平台方案React Native、Flutter、Kotlin Multiplatform、Compose Multiplatform吵得不可开交。但有个很现实的事情是不管哪种方案跑在手机上最终都要在 ARM 架构的 CPU 上执行指令。这就涉及到 ABIApplication Binary Interface的适配问题。Android 设备现在的 ABI 主要有 armeabi-v7a、arm64-v8a 和 x86_64一般只用于模拟器。如果你的 App 用了原生库那发布时至少要带上 arm64-v8a 这个 ABI因为现在市面上的新机型基本都是 64 位的。如果你为了包体积把 x86_64 的 so 移除掉那测试团队在模拟器上跑自动化测试时就会直接崩溃。我们踩过的坑是曾经为了减少 APK 体积在 release 构建里只保留 arm64-v8a 的 so结果线上有少量还在用 32 位旧设备的用户反馈打开 App 就黑屏后来不得不重新上一个多 ABI 的包。跨平台框架并不能免除你理解硬件差异的责任。比如 Flutter 现在的默认构建产物就同时包含 ARM32 和 ARM64 的引擎在打包发布时建议剥离不需要的而一些基于 WebView 的跨平台方案在低端 ARM 芯片上的 JS 引擎执行效率会明显下降。所以做架构选型之前先明确自己的用户群体用的是哪些机型再反推技术方案而不是先选技术方案再适配用户。4.2 跨平台方案选择的三个隐性成本很多团队选择跨平台方案的原因是一套代码跑两端节省人力但我要提醒你一点这个账很容易算错。第一平台差异适配的成本。你以为写一套代码就完事了但 Android 和 iOS 在导航、返回手势、键盘、权限弹窗这些交互细节上就有几十个差异化点这些差异最终都要靠条件判断写出来每一个条件判断都是一笔维护成本。第二原生模块桥接的成本。任何跨平台方案都逃不掉桥接原生能力这个环节比如你要做个扫一扫、做个本地推送、调个相机都要写原生代码并且要保证两端的原生代码和业务代码的生命周期一致如果原生代码在后台被回收了业务代码可能就会拿不到回调通知。第三性能天花板。跨平台框架在普通业务页面下体验差别不大但在列表高度复杂、动画频繁、或者需要高帧率绘制的场景下性能和原生方案还是有差距。如果你做的是一个电商 App核心路径就是商品列表和商品详情那这些问题就是你做架构选型时无法回避的坎。5. 高频问题排查与避坑速查5.1 表单必填项校验的三类典型错误移动端表单必填项这个词能上热词榜说明大家在实际开发里遇到的问题真不少。我盘点了一下在表单这件事上典型的坑有三类。第一类是只在客户端做必填校验后端不做兜底。用户通过某些手段绕过客户端直接调接口把空字段提交上来后端一旦没有校验脏数据就进库了。解决方案是前后端做双重校验而且后端要把校验不通过的错误码定义得足够细方便客户端区分字段缺失和字段格式错误。第二类是键盘遮挡问题。用户在页面底部填写必填项时软键盘弹出来把输入框盖住用户根本看不到自己输入的内容体验很差。这个问题在 Android 的 adjustResize 和 adjustPan 两个模式选择上非常容易踩坑。如果你用的是 ScrollView 底部固定按钮这种布局必须把滚动和键盘模式都测试到。第三类是必填项的联动逻辑。比如用户选了企业用户身份那么公司名称和税号就变成必填项而选了个人用户则不需要。这种动态必填逻辑在架构上要从配置文件或者规则引擎里读取而不是把 if-else 写死在页面里否则后台上线新规则时你就得发版。5.2 内存抖动与泄漏的定位方法运营同学反馈 App 用久了越来越卡这是很多团队都接过的工单。这类问题 90% 以上都是内存泄漏或者内存抖动造成的。排查的第一步不是猜代码而是拿证据。用 Memory Profiler 抓一段 heap dump把对象列表按 Shallow Size 排序优先看那些数量异常多且不该长期存活的类比如 Activity、Fragment、ViewModel。如果发现 MainActivity 存在好几个实例那基本可以确定有内存泄漏常见的元凶就是静态变量持有 Activity 引用、非静态内部类创建了 Handler 或者 Runnable 延后执行、单例里存了 View 或者 Context。定位到泄漏点之后修复方案通常比较直接。除了常规的释放引用、用 WeakReference、取消订阅之外还有一个细节容易被忽略生命周期比较长的组件比如 Application、仓库层缓存的回调里注册了监听器但忘了在 onDestroy 的时候反注册特别是用 LiveData 观察数据库变化之后没有 removeObserver这个问题在 MVVM 架构里非常隐蔽因为你只有在反复进入退出页面几十次之后才会触发 OOM。5.3 我被线上用户教做人的几次经历这里分享一个我自己的真实教训。有一年我们上线了一个新版本把一个原本列表页用 RecyclerView 的模块换成了用 Compose 重写的版本理由是新的架构更先进。结果灰度到 5% 的时候后台监控显示低端机上的崩溃率从 0.2% 直接飙到了 6%。查了半天才发现问题出在 Compose 首次组合时的高昂初始化开销以及在某些系统 WebView 页面上互相抢占资源导致的 ANR。那次之后我们团队定了一条架构上的铁律技术栈升级不能直接替换核心业务路径必须采用双实现并行 渐进迁移的策略。新架构先做成一个可独立运行的模块在后台配置开关只对部分用户生效等性能和稳定性数据都稳定之后再逐步放量替换。没有 AB 开关和灰度环境的验证任何架构升级都是拿线上用户做实验。还有一个让我记忆很深的坑是我们团队某个成员在写页面时把一个需要执行 200 多次 JSON 解析的循环放在了 RecyclerView 的 onBindViewHolder 里。单个页面看起来不卡但当用户快速滑动列表时CPU 占用瞬间爆表。当时我们用了各种手段去排查最后是在 CPU Profiler 里看到 JSON 解析方法被调用了几千次才定位到的。所以排查移动端性能问题不要太相信经验一切以 Profiler 的采样数据为准先定位再修复比拍脑袋改代码高效得多。6. 一些沉淀下来的原则与工作习惯做到最后我想分享几条沉淀下来的原则。这些不是某个架构模式教条的产物而是踩过无数个坑之后总结出来的工作习惯。第一架构是服务于交付效率和线上稳定性的不是服务于简历和分享的。每一次架构选型都先回答三个问题解决什么问题、引入什么成本、如何回退。回答不上来就别动手。第二移动端的架构必须与后端架构联动规划。微服务化、分布式改造不是只影响后端它一定会传导到客户端的接口设计、容错机制和缓存策略上。移动端架构师要主动参与后端接口评审而不是被动接接口文档哪怕只是问一句这个字段在弱网环境下会不会有超时都可能避免一次线上故障。第三永远要为性能和稳定性留出独立的优化窗口。不要指望在开发功能迭代的间隙顺手把性能做好性能问题是需要专项投入的。我建议每个月都安排一次性能巡检日用统一的工具把冷启动、FPS、内存水位、崩溃率导成报表做横向对比。维持在健康水位就不要动一旦出现劣化趋势立刻定位是哪个版本的功能引入的。第四不要迷信热词也不要完全无视热词。像移动端性能优化分布式架构微服务架构这些热门概念它们背后对应的是一批真实存在的共性问题和有效解法但每一套方案都要在自己的业务场景里做验证。别人的解药也可能是你的毒药。做移动端架构这件事本质上不是技术竞赛而是风险管理。把这句话想明白了很多纠结自然就解开了。
阅读完成 · 觉得有帮助？
