一个移动 App 开发到 90% 进度这个节点往往比从 0 到 60% 更考验人。功能做得差不多Demo 能跑界面看着完整但越接近收尾越容易发现真正难的不是没实现的功能而是已经实现的功能在各种条件下到底稳不稳。Hermes Studio App 今天走到 90%按实际开发节奏看这个阶段做的事情已经不全是“写新功能”而是把之前快速推进时埋下的隐患一个个排掉把测试、构建、数据兼容、状态恢复这些问题补成闭环。这篇内容适合正在做移动端项目收尾的开发者看也适合独立开发者和前端转客户端的同学参考。我不会只盘点功能列表而是把 90% 阶段最该盯住的几个方面拆开讲怎么判断进度是不是真的到 90%、哪些问题在这个阶段集中暴露、收尾时的排查顺序是什么、最后 10% 到底花在哪里。不管你的项目叫 Hermes Studio 还是其他代号只要你处在功能开发基本完成、准备往稳定版本推进的阶段这篇内容应该能帮你减少一些盲目的“冲刺”。1. 先搞清楚“开发进度 90%”是真进度还是功能清单进度项目进行到后期最容易出现一个错觉界面上能点的按钮都点了开发计划里的功能项都打上勾了看起来就是 90%。但真正的进度应该等于“功能完成度 稳定性完成度 发布准备度”的加权结果。如果只是功能列表走完而崩溃、异常分支、数据兼容、构建发布还没有验证那这个 90% 只是做题做到第 9 题不是考试及格。1.1 用任务完成率算进度会高估真实状态很多开发团队用任务看板决定进度比如创建了 50 个 Task完成 45 个就算 90%。这种方式在功能开发期很好用因为新功能基本是从无到有完成标准相对清楚。到了收尾期就不是这样了。一个 Task 写着“登录流程完成”实际可能只覆盖了密码登录成功路径验证码登录失败、Token 过期、账号被禁用、弱网请求重试都没有处理。我在做移动端收尾时通常换一种统计方式把 Task 拆成三类功能路径类正常操作从入口到结果的完整流程。异常分支类每个功能在失败、超时、无数据、无权限时的表现。状态恢复类切后台、被杀进程、重启 App、断网恢复后的页面状态和数据状态。Hermes Studio App 如果在计划表上显示 90%我建议先别急着庆祝而是拿这三类清单重新盘一遍。你会发现功能路径类可能确实完成了 90% 以上但异常分支类和状态恢复类往往只有 40% 到 60%。这个差距就是后面所有“突发问题”的来源。1.2 真正的 90% 应该具备哪些表现按我自己的收尾经验一个独立 App 能做到下面这些表现再谈 90% 才比较踏实第一核心路径在真实设备上连续操作不会崩。这里说的真实设备不是模拟器而是至少一台中低端 Android 或一台旧款 iPhone。很多崩溃和卡顿只在真机的内存限制、系统调度、屏幕适配下才会暴露。第二业务的失败分支有明确反馈。比如网络断开时点击提交不能无响应也不能直接闪退而是进入可重试或可保存草稿的状态。第三数据不会因为版本升级丢失。开发期大多用测试账号和测试数据随便清缓存都没关系。接近发布时就要认真测本地数据库迁移、服务端字段兼容、旧版本缓存读取。第四关键操作有日志和埋点。出了问题能通过日志定位到页面、接口、参数和错误码而不是靠用户截图猜。如果你盘点下来发现这些还缺我建议把标题里的 90% 改成“功能开发 90%稳定化刚刚开始”。这是为了后期少返工不是扫兴。2. Hermes Studio App 到 90% 阶段最先暴露的是三类资源问题开发进度一到后期大家往往会集中精力调 UI、补动画、修细节。但真实场景里App 跑到这个阶段最先暴露的通常不是样式问题而是资源占用问题。特别是你这个项目叫 Studio大概率会涉及编辑器、画布、素材库或文件处理类功能这类 App 的内存和存储消耗比普通内容阅读类 App 要高得多。2.1 内存占用不稳定多发生在页面栈和编辑器历史记录Studio 类应用最常见的崩溃原因就是内存持续增长。用户新建项目、打开模板、反复撤销重做、切换素材库每一步都可能把对象保留在内存里。如果只有当前页面被释放而历史记录里的数据一直堆积用不了太久就会触发系统回收或直接 OOM。排查时不要只看内存平均值要看峰值波动连续打开 20 个页面再返回内存是否能回落到初始水平。编辑器中反复执行撤销和重做 50 次内存是否只增不减。图片、音频、视频等素材预览后缩略图缓存和原图引用是否及时释放。如果 Hermes Studio App 做的是内容创作方向我建议在 90% 阶段专门加一个长时压力测试不杀进程连续使用 30 分钟观察内存曲线。真正有问题的不是刚开始的 5 分钟而是 15 分钟后的持续上涨。2.2 本地文件越多越要处理缓存淘汰和磁盘占满内容类或创作类 App 很容易产生大量本地文件。素材缩略图、导出草稿、日志文件、下载的模板资源都会占用磁盘。开发期设备空间充足问题不明显用户设备上如果同时装了微信、游戏和视频软件存储空间就可能紧张。我建议在发布前把磁盘存储的几个边界想清楚单个文件最大允许多大。项目占用的本地目录是否按项目隔离。缓存达到多少时自动清理清理时是否影响未保存内容。App 卸载重装后哪些数据应该通过云备份恢复哪些可以重建。这个环节不必写很复杂的代码关键是先在设置页加一个“存储空间管理”入口让用户能看到缓存大小和清理按钮。别等商店评论里出现“用几天就占了好几个 G”再补。2.3 启动速度和冷启动路径决定用户第一印象90% 阶段的启动速度往往比开发早期慢不少原因是初始化逻辑越加越多。第三方 SDK 启动、数据库连接、用户状态恢复、本地配置读取都堆在启动阶段看起来每一步都很快合在一起就可能让用户盯着启动页超过 3 秒。处理思路是拆分启动任务首屏必须依赖的初始化按优先级同步执行。非关键任务比如广告配置拉取、素材推荐、日志上报都放到首屏渲染之后异步执行。首页如果依赖远程配置需要设置合理的本地缓存兜底不能等服务端返回后才显示内容。如果一个项目计划表显示 90%启动流程还没梳理过我会建议把这个优先级提到新增功能之前。启动速度影响的是所有用户而新功能影响的是部分用户这个取舍很明确。3. 功能收尾阶段最容易被忽略的是依赖闭环功能开发到后半段很多页面看起来能打开流程看起来能走通但只测了“自己到自己”的路径。比如列表页能进详情页但详情页返回后列表数据没有刷新编辑页能保存但保存成功后项目列表里看不到状态变化设置页修改了一个参数但实际业务没有读取这个参数。这些问题统称为依赖闭环缺失。3.1 页面跳转和数据回传要成对验证一个比较常见的场景用户从项目列表进入编辑页编辑完成后返回列表列表需要刷新以展示最新缩略图和修改时间。很多开发只验证了编辑页内部能正常改动数据没有验证返回后列表页是否重新拉取或从本地数据库读取了最新记录。收尾阶段我通常会把两两相邻的场景都过一遍列表到详情详情返回列表。列表到编辑编辑保存后返回列表。设置页修改配置返回上一级后立即执行一次依赖新配置的操作。从通知栏或外部链接跳转到指定页面返回后回到正确的上层页面。这类问题不好通过常规功能测试发现因为它不是“功能坏了”而是“数据没同步”。如果 Hermes Studio App 里有项目管理、素材管理或模板库这种多级页面结构这个环节值得专门安排一天来做。3.2 服务端接口的字段变化要在客户端做兼容处理开发期前后端接口通常同时改版本客户端今天按字段 A 解析明天服务端改成字段 B只要联调时一起部署就不会暴露问题。但真正发布后服务端和客户端版本不可能永远同步更新。老版本客户端遇到新字段时不能崩溃新版本客户端遇到服务端临时下线的字段时也不能白屏。接口兼容处理有几个常见做法解析字段前先判断类型和是否为空。列表接口使用增量更新时保留上次本地数据的兜底展示。返回码增加新错误类型时客户端要有统一 fallback 文案。很多客户端崩溃不是主流程代码写错而是服务端返回了预期之外的结构。所以我在 90% 阶段会专门做一轮接口异常注入测试服务端把某一字段改成 null、把数组改成空数组、把数字改成字符串、把整个 data 节点去掉客户端逐个观察是否出现崩溃、白屏或无限 loading。这轮测试不需要很复杂的工具用抓包工具修改响应或者让后端同学在测试环境模拟一两种异常即可。关键是把常见异常情况形成清单而不是今天改一个明天又踩一个。3.3 深链路操作要加“断点恢复”不能只靠用户重来内容创作类场景最怕的就是用户做了很久的内容因为一次中断而消失。90% 阶段如果还没有自动保存或草稿恢复机制一定要补上。这个功能不是加分项而是基础体验。用户清掉后台任务、手机电量耗尽自动关机、App 在后台被系统回收这些都应该能恢复到接近中断前的位置。实现断点恢复的基本思路定时自动保存编辑内容变化后在本地数据库或文件中保存草稿。恢复提示启动时发现未完成项目提示用户“是否继续上次编辑”。保存内容要包含页面状态参数不只是业务数据否则恢复后不知道用户在哪个 Tab、选中了哪个素材。Hermes Studio 如果定位是创作工具类 App这一点不要拖到最后几天再想。自动保存的逻辑和页面数据结构耦合很深越晚接入改造范围越大。4. 数据治理和状态恢复是收尾阶段最有价值的投入接近 90% 的时候很多开发者的注意力都在“还能加什么功能”但用户对稳定版本最直接的需求是我的数据不要丢我的状态不要乱。4.1 本地数据存储要设计好版本迁移路径移动 App 的本地数据库一旦发布后续升级时就不能随便改表结构。如果开发期还在随便删表加字段那无所谓因为用户都是测试数据。但接近发布时就必须把数据库版本管理建立起来。需要做三件事每张表带版本号表结构变更时执行 ALTER TABLE而不是 DROP TABLE。新字段要设置默认值不能假设老数据一定会写入新字段。升级代码要保留旧数据副本或者至少保证迁移失败时 App 可以进入安全模式而不是无限崩溃。我见过不少项目在功能开发期很顺利一上架发布就被用户反馈“升级后我的项目不见了”。排查一圈往往就是数据库 onUpgrade 里执行了一条 DROP TABLE或者本来应该执行迁移的代码被条件判断挡住了。收尾阶段一定要专门测升级路径先装老版本创建一批数据再装新版本覆盖安装看数据是否完整。4.2 多账号场景和登录态恢复比想象中更容易出问题如果你的 App 有账号体系接近收尾时要重点测这些场景切后台一段时间后 Token 过期用户操作时是静默刷新还是跳回登录页。用户在系统设置里清空了 App 数据下次启动是否能正常进入重新登录流程。服务端把某个用户的账号禁用后客户端还能不能正常退出到登录页。如果支持多账号切换切换后本地缓存的数据是否完全隔离开不能让 A 账号看到 B 账号的草稿或项目列表。这些场景在开发期很难触发因为测试时总是刚登录不久Token 没过期本地缓存也不会有前一个账号的数据。但真实用户的使用周期长、行为杂状态恢复做不好就是差评来源。4.3 日志和埋点不要等出了线上问题再补开发期排查问题可以直接看 Xcode 日志或 Android Studio 的 Logcat因为设备在自己手里。发布之后就没有这么方便了线上用户报问题时往往只说了一句“点了没反应”如果客户端没有日志上报、没有页面留存记录、没有接口错误信息你基本只能靠猜。Hermes Studio App 到 90% 阶段我建议至少完成这样的日志体系每次页面进入和退出记录当前页面名称和时间。关键操作新建、打开、保存、删除、导出记录操作类型和结果。网络请求记录接口路径、耗时、状态码和错误信息。崩溃日志记录设备型号、系统版本、App 版本、崩溃堆栈和用户操作路径。更实用的做法是让日志列表能在设置页显示方便测试人员直接截图反馈。不要只看崩溃率一个指标很多体验问题不是崩溃而是某个操作在特定机型上没有反应或结果不符合预期有了页面操作日志才能还原现场。5. 构建发布准备进入最后 10% 前先把工程细节处理好当功能、稳定性和数据路径都处理得差不多的时候才真正可以打开发布清单。这个阶段不需要再写很多新代码而是要反复检查构建配置、签名、依赖、包体积和审核材料确保交出去的版本和测试版本行为一致。5.1 多环境配置要严格隔离避免测试环境发布上线移动 App 开发到后期一般会有 debug、test、release 几套配置对应不同接口地址、不同 App 图标、不同日志级别。90% 阶段经常出现的问题是测试环境一切正常但 release 包要么接口连不上测试服务、要么日志太多影响性能、要么把测试入口暴露给了真实用户。我习惯在打正式包前检查这些项接口 baseUrl 是否正确切换到正式环境。第三方 SDK 的 key 是否从测试 key 换成了正式 key。日志框架在 release 下是否关闭或降级。网络请求的调试工具、本地 Mock、开发菜单是否已经关闭。混淆规则是否覆盖了所有第三方库release 包启动后是否报“ClassNotFound”或“方法找不到”。这些问题在开发期不会出现因为开发时一直用的 debug 配置真正踩坑是在第一次打 release 包上 testflight 或内测平台时才集中暴露。90% 阶段先做一次完整 release 包的内测比最后一天打正式包时再发现配置错误要省心很多。5.2 包体积和应用启动项始终不能放弃治理现在应用市场对包体积越来越敏感用户下载前会看到应用大小下载后也会因为占用空间而卸载。构建产物从几十 MB 涨到一两百 MB 很容易功能越多、依赖越多、资源文件越多体积就涨得越快。比较有效的几个手段用资源混淆和移除无用资源去掉那些已经没有引用的图片和字符串。按需引入第三方库而不是为了某一个方法就引入整个 SDK。大图尽量压缩或用 WebP 格式替代 PNG。架构拆分时注意原生库的包含范围armeabi-v7a、arm64-v8a、x86 按需保留。对于 Studio 类 App还要额外留意内置模板、字体、示例素材的体积。如果项目本身需要下载大量内容尽量放服务端按需下载不要全部打进安装包。5.3 升级策略和灰度发布不是大公司才需要的机制有些独立开发者觉得用户量少不用做更新提示用户要升级自然会在商店里搜。但实际情况下用户不升级就会遇到老版本客户端与服务端不兼容的问题。你修了一个严重崩溃如果用户不更新到新版本这个修复对他来说完全无效。发布准备阶段至少要配置一个简单的版本检查接口包含三个字段最低支持版本号低于这个版本的客户端可以提示更新避免用户停留在有严重问题的旧版本。最新版本号用于和当前版本对比提示用户去更新。更新说明让用户知道这个版本修复了什么、新增了什么。如果条件允许再做一层灰度发布先放出 5% 到 10% 的用户作为观察组确认崩溃率和关键接口错误率正常后再放全量。即使你的 App 是通过应用市场直接发版也可以先选少量渠道比较稳定的用户观察一段时间。6. 最后 10% 到底花在哪里以及我的收尾节奏建议很多人说的“最后 10%”其实不是剩余工作量的 10%而是从“基本功能可用”到“可以放心交给用户”之间那段大量重复验证、修复、回归的时间。按真实项目经验这个阶段耗时可能占整个项目的三分之一。6.1 从 90% 到 100% 的常见工作分配我一般会把最后的收尾时间分成下面几块第一回归测试占最大块。每次修复一个 Bug都要重新验证它相邻的流程是否被破坏。比如修了编辑页的保存按钮至少要重新检查项目列表的展示、详情页的数据、自动保存的触发时间、退出编辑的状态提示。没有完整回归会出现“修好一个旧 Bug引入一个新 Bug”的循环。第二真机和兼容性测试占第二块。重点不只在新款旗舰机还包括 5% 到 10% 用户还在用的旧机型。中低端 Android 设备的性能问题比如列表加载缓慢、图片缩放卡顿、长时间停留后内存上涨在旗舰机上往往很难复现。真要判断兼容性建议至少找一台内存 4GB 左右的 Android 和一些两三年前的机型来跑。第三版本发布材料整理占第三块。包括应用商店截图、功能描述、隐私政策链接、权限说明。Studio 类 App 如果涉及用户上传或云端存储还要提前确认隐私合规和数据存储方式的说明。这些材料看似不写代码但缺少任何一个上架审核就可能被驳回。6.2 如果只剩两周时间我会怎么排优先级假如 Hermes Studio App 还差最后两个星期就要发布下面这个优先级顺序可以参考先处理会造成数据丢失或无法启动的问题比如本地数据库迁移失败、启动闪退、自动保存数据损坏。这类问题影响范围最大不管多小概率只要触发就是严重事故。再处理核心流程不可用和明显卡顿比如新建项目、打开素材、保存导出这些路径。不要让用户完成第一次核心操作就遇到失败。之后处理兼容性问题和界面细节比如个别机型输入框被键盘遮挡、深色模式下文字看不清、返回手势冲突等。最后如果时间还有剩余再去加一些体验优化和“锦上添花”的功能。如果时间不够砍功能不是可耻的决定带着明显不稳定的功能上架才是更大的风险。我个人的建议是在这个阶段把每天的开发任务分成“修复类”和“优化类”先把修复类清掉再排队做优化类。更具体地每天下班前跑一遍核心路径冒烟测试确保当天改动没有破坏主流程。连续三天核心路径通过率 100%再讨论“把进度从 90% 更新到 95%”也不迟。6.3 最后一轮自测清单可以按这个顺序过一遍开发进度到 90% 时我建议你已经有一套自己的自测清单而不是临时靠记忆来检查。一个移动 App 在收尾阶段的检查顺序通常按从底层到上层的顺序来安装启动全新安装、覆盖安装、卸载重装。账号状态首次启动、登录态有效、登录态过期、退出再登录。首页加载有网、无网、弱网、服务端超时。核心操作创建、编辑、保存、删除、导出。数据一致性列表刷新、详情刷新、本地和服务端数据同步。异常处理网络中断、后台回收、存储空间不足、相机或相册权限被拒绝。设置与反馈修改设置后立即生效、提交反馈后能看到结果。日志检查关键操作有日志错误信息可读。这套顺序的核心逻辑是先保证用户能走到核心流程再保证核心流程在异常条件下不会崩溃最后保证出了问题能查。如果把顺序反过来先调动画效果再做网络容错后面返工的概率会很高。如果你把 Hermes Studio 的最终版本定义为“功能做得比对手多”那今天的进度就不够。如果你把最终版本定义为“用户能稳定完成核心任务升级不丢数据崩溃能查清原因”那 90% 确实是一个非常关键的时间点——它离完成还有几步但它已经不是做加法的主场而是做减法、做清理、做修复的战场。我自己在项目到这个阶段时最常说的一句话是别急最后这段路的每一步都值得慢慢走。
移动App开发到90%阶段：稳定性收尾与数据治理实战指南
一个移动 App 开发到 90% 进度这个节点往往比从 0 到 60% 更考验人。功能做得差不多Demo 能跑界面看着完整但越接近收尾越容易发现真正难的不是没实现的功能而是已经实现的功能在各种条件下到底稳不稳。Hermes Studio App 今天走到 90%按实际开发节奏看这个阶段做的事情已经不全是“写新功能”而是把之前快速推进时埋下的隐患一个个排掉把测试、构建、数据兼容、状态恢复这些问题补成闭环。这篇内容适合正在做移动端项目收尾的开发者看也适合独立开发者和前端转客户端的同学参考。我不会只盘点功能列表而是把 90% 阶段最该盯住的几个方面拆开讲怎么判断进度是不是真的到 90%、哪些问题在这个阶段集中暴露、收尾时的排查顺序是什么、最后 10% 到底花在哪里。不管你的项目叫 Hermes Studio 还是其他代号只要你处在功能开发基本完成、准备往稳定版本推进的阶段这篇内容应该能帮你减少一些盲目的“冲刺”。1. 先搞清楚“开发进度 90%”是真进度还是功能清单进度项目进行到后期最容易出现一个错觉界面上能点的按钮都点了开发计划里的功能项都打上勾了看起来就是 90%。但真正的进度应该等于“功能完成度 稳定性完成度 发布准备度”的加权结果。如果只是功能列表走完而崩溃、异常分支、数据兼容、构建发布还没有验证那这个 90% 只是做题做到第 9 题不是考试及格。1.1 用任务完成率算进度会高估真实状态很多开发团队用任务看板决定进度比如创建了 50 个 Task完成 45 个就算 90%。这种方式在功能开发期很好用因为新功能基本是从无到有完成标准相对清楚。到了收尾期就不是这样了。一个 Task 写着“登录流程完成”实际可能只覆盖了密码登录成功路径验证码登录失败、Token 过期、账号被禁用、弱网请求重试都没有处理。我在做移动端收尾时通常换一种统计方式把 Task 拆成三类功能路径类正常操作从入口到结果的完整流程。异常分支类每个功能在失败、超时、无数据、无权限时的表现。状态恢复类切后台、被杀进程、重启 App、断网恢复后的页面状态和数据状态。Hermes Studio App 如果在计划表上显示 90%我建议先别急着庆祝而是拿这三类清单重新盘一遍。你会发现功能路径类可能确实完成了 90% 以上但异常分支类和状态恢复类往往只有 40% 到 60%。这个差距就是后面所有“突发问题”的来源。1.2 真正的 90% 应该具备哪些表现按我自己的收尾经验一个独立 App 能做到下面这些表现再谈 90% 才比较踏实第一核心路径在真实设备上连续操作不会崩。这里说的真实设备不是模拟器而是至少一台中低端 Android 或一台旧款 iPhone。很多崩溃和卡顿只在真机的内存限制、系统调度、屏幕适配下才会暴露。第二业务的失败分支有明确反馈。比如网络断开时点击提交不能无响应也不能直接闪退而是进入可重试或可保存草稿的状态。第三数据不会因为版本升级丢失。开发期大多用测试账号和测试数据随便清缓存都没关系。接近发布时就要认真测本地数据库迁移、服务端字段兼容、旧版本缓存读取。第四关键操作有日志和埋点。出了问题能通过日志定位到页面、接口、参数和错误码而不是靠用户截图猜。如果你盘点下来发现这些还缺我建议把标题里的 90% 改成“功能开发 90%稳定化刚刚开始”。这是为了后期少返工不是扫兴。2. Hermes Studio App 到 90% 阶段最先暴露的是三类资源问题开发进度一到后期大家往往会集中精力调 UI、补动画、修细节。但真实场景里App 跑到这个阶段最先暴露的通常不是样式问题而是资源占用问题。特别是你这个项目叫 Studio大概率会涉及编辑器、画布、素材库或文件处理类功能这类 App 的内存和存储消耗比普通内容阅读类 App 要高得多。2.1 内存占用不稳定多发生在页面栈和编辑器历史记录Studio 类应用最常见的崩溃原因就是内存持续增长。用户新建项目、打开模板、反复撤销重做、切换素材库每一步都可能把对象保留在内存里。如果只有当前页面被释放而历史记录里的数据一直堆积用不了太久就会触发系统回收或直接 OOM。排查时不要只看内存平均值要看峰值波动连续打开 20 个页面再返回内存是否能回落到初始水平。编辑器中反复执行撤销和重做 50 次内存是否只增不减。图片、音频、视频等素材预览后缩略图缓存和原图引用是否及时释放。如果 Hermes Studio App 做的是内容创作方向我建议在 90% 阶段专门加一个长时压力测试不杀进程连续使用 30 分钟观察内存曲线。真正有问题的不是刚开始的 5 分钟而是 15 分钟后的持续上涨。2.2 本地文件越多越要处理缓存淘汰和磁盘占满内容类或创作类 App 很容易产生大量本地文件。素材缩略图、导出草稿、日志文件、下载的模板资源都会占用磁盘。开发期设备空间充足问题不明显用户设备上如果同时装了微信、游戏和视频软件存储空间就可能紧张。我建议在发布前把磁盘存储的几个边界想清楚单个文件最大允许多大。项目占用的本地目录是否按项目隔离。缓存达到多少时自动清理清理时是否影响未保存内容。App 卸载重装后哪些数据应该通过云备份恢复哪些可以重建。这个环节不必写很复杂的代码关键是先在设置页加一个“存储空间管理”入口让用户能看到缓存大小和清理按钮。别等商店评论里出现“用几天就占了好几个 G”再补。2.3 启动速度和冷启动路径决定用户第一印象90% 阶段的启动速度往往比开发早期慢不少原因是初始化逻辑越加越多。第三方 SDK 启动、数据库连接、用户状态恢复、本地配置读取都堆在启动阶段看起来每一步都很快合在一起就可能让用户盯着启动页超过 3 秒。处理思路是拆分启动任务首屏必须依赖的初始化按优先级同步执行。非关键任务比如广告配置拉取、素材推荐、日志上报都放到首屏渲染之后异步执行。首页如果依赖远程配置需要设置合理的本地缓存兜底不能等服务端返回后才显示内容。如果一个项目计划表显示 90%启动流程还没梳理过我会建议把这个优先级提到新增功能之前。启动速度影响的是所有用户而新功能影响的是部分用户这个取舍很明确。3. 功能收尾阶段最容易被忽略的是依赖闭环功能开发到后半段很多页面看起来能打开流程看起来能走通但只测了“自己到自己”的路径。比如列表页能进详情页但详情页返回后列表数据没有刷新编辑页能保存但保存成功后项目列表里看不到状态变化设置页修改了一个参数但实际业务没有读取这个参数。这些问题统称为依赖闭环缺失。3.1 页面跳转和数据回传要成对验证一个比较常见的场景用户从项目列表进入编辑页编辑完成后返回列表列表需要刷新以展示最新缩略图和修改时间。很多开发只验证了编辑页内部能正常改动数据没有验证返回后列表页是否重新拉取或从本地数据库读取了最新记录。收尾阶段我通常会把两两相邻的场景都过一遍列表到详情详情返回列表。列表到编辑编辑保存后返回列表。设置页修改配置返回上一级后立即执行一次依赖新配置的操作。从通知栏或外部链接跳转到指定页面返回后回到正确的上层页面。这类问题不好通过常规功能测试发现因为它不是“功能坏了”而是“数据没同步”。如果 Hermes Studio App 里有项目管理、素材管理或模板库这种多级页面结构这个环节值得专门安排一天来做。3.2 服务端接口的字段变化要在客户端做兼容处理开发期前后端接口通常同时改版本客户端今天按字段 A 解析明天服务端改成字段 B只要联调时一起部署就不会暴露问题。但真正发布后服务端和客户端版本不可能永远同步更新。老版本客户端遇到新字段时不能崩溃新版本客户端遇到服务端临时下线的字段时也不能白屏。接口兼容处理有几个常见做法解析字段前先判断类型和是否为空。列表接口使用增量更新时保留上次本地数据的兜底展示。返回码增加新错误类型时客户端要有统一 fallback 文案。很多客户端崩溃不是主流程代码写错而是服务端返回了预期之外的结构。所以我在 90% 阶段会专门做一轮接口异常注入测试服务端把某一字段改成 null、把数组改成空数组、把数字改成字符串、把整个 data 节点去掉客户端逐个观察是否出现崩溃、白屏或无限 loading。这轮测试不需要很复杂的工具用抓包工具修改响应或者让后端同学在测试环境模拟一两种异常即可。关键是把常见异常情况形成清单而不是今天改一个明天又踩一个。3.3 深链路操作要加“断点恢复”不能只靠用户重来内容创作类场景最怕的就是用户做了很久的内容因为一次中断而消失。90% 阶段如果还没有自动保存或草稿恢复机制一定要补上。这个功能不是加分项而是基础体验。用户清掉后台任务、手机电量耗尽自动关机、App 在后台被系统回收这些都应该能恢复到接近中断前的位置。实现断点恢复的基本思路定时自动保存编辑内容变化后在本地数据库或文件中保存草稿。恢复提示启动时发现未完成项目提示用户“是否继续上次编辑”。保存内容要包含页面状态参数不只是业务数据否则恢复后不知道用户在哪个 Tab、选中了哪个素材。Hermes Studio 如果定位是创作工具类 App这一点不要拖到最后几天再想。自动保存的逻辑和页面数据结构耦合很深越晚接入改造范围越大。4. 数据治理和状态恢复是收尾阶段最有价值的投入接近 90% 的时候很多开发者的注意力都在“还能加什么功能”但用户对稳定版本最直接的需求是我的数据不要丢我的状态不要乱。4.1 本地数据存储要设计好版本迁移路径移动 App 的本地数据库一旦发布后续升级时就不能随便改表结构。如果开发期还在随便删表加字段那无所谓因为用户都是测试数据。但接近发布时就必须把数据库版本管理建立起来。需要做三件事每张表带版本号表结构变更时执行 ALTER TABLE而不是 DROP TABLE。新字段要设置默认值不能假设老数据一定会写入新字段。升级代码要保留旧数据副本或者至少保证迁移失败时 App 可以进入安全模式而不是无限崩溃。我见过不少项目在功能开发期很顺利一上架发布就被用户反馈“升级后我的项目不见了”。排查一圈往往就是数据库 onUpgrade 里执行了一条 DROP TABLE或者本来应该执行迁移的代码被条件判断挡住了。收尾阶段一定要专门测升级路径先装老版本创建一批数据再装新版本覆盖安装看数据是否完整。4.2 多账号场景和登录态恢复比想象中更容易出问题如果你的 App 有账号体系接近收尾时要重点测这些场景切后台一段时间后 Token 过期用户操作时是静默刷新还是跳回登录页。用户在系统设置里清空了 App 数据下次启动是否能正常进入重新登录流程。服务端把某个用户的账号禁用后客户端还能不能正常退出到登录页。如果支持多账号切换切换后本地缓存的数据是否完全隔离开不能让 A 账号看到 B 账号的草稿或项目列表。这些场景在开发期很难触发因为测试时总是刚登录不久Token 没过期本地缓存也不会有前一个账号的数据。但真实用户的使用周期长、行为杂状态恢复做不好就是差评来源。4.3 日志和埋点不要等出了线上问题再补开发期排查问题可以直接看 Xcode 日志或 Android Studio 的 Logcat因为设备在自己手里。发布之后就没有这么方便了线上用户报问题时往往只说了一句“点了没反应”如果客户端没有日志上报、没有页面留存记录、没有接口错误信息你基本只能靠猜。Hermes Studio App 到 90% 阶段我建议至少完成这样的日志体系每次页面进入和退出记录当前页面名称和时间。关键操作新建、打开、保存、删除、导出记录操作类型和结果。网络请求记录接口路径、耗时、状态码和错误信息。崩溃日志记录设备型号、系统版本、App 版本、崩溃堆栈和用户操作路径。更实用的做法是让日志列表能在设置页显示方便测试人员直接截图反馈。不要只看崩溃率一个指标很多体验问题不是崩溃而是某个操作在特定机型上没有反应或结果不符合预期有了页面操作日志才能还原现场。5. 构建发布准备进入最后 10% 前先把工程细节处理好当功能、稳定性和数据路径都处理得差不多的时候才真正可以打开发布清单。这个阶段不需要再写很多新代码而是要反复检查构建配置、签名、依赖、包体积和审核材料确保交出去的版本和测试版本行为一致。5.1 多环境配置要严格隔离避免测试环境发布上线移动 App 开发到后期一般会有 debug、test、release 几套配置对应不同接口地址、不同 App 图标、不同日志级别。90% 阶段经常出现的问题是测试环境一切正常但 release 包要么接口连不上测试服务、要么日志太多影响性能、要么把测试入口暴露给了真实用户。我习惯在打正式包前检查这些项接口 baseUrl 是否正确切换到正式环境。第三方 SDK 的 key 是否从测试 key 换成了正式 key。日志框架在 release 下是否关闭或降级。网络请求的调试工具、本地 Mock、开发菜单是否已经关闭。混淆规则是否覆盖了所有第三方库release 包启动后是否报“ClassNotFound”或“方法找不到”。这些问题在开发期不会出现因为开发时一直用的 debug 配置真正踩坑是在第一次打 release 包上 testflight 或内测平台时才集中暴露。90% 阶段先做一次完整 release 包的内测比最后一天打正式包时再发现配置错误要省心很多。5.2 包体积和应用启动项始终不能放弃治理现在应用市场对包体积越来越敏感用户下载前会看到应用大小下载后也会因为占用空间而卸载。构建产物从几十 MB 涨到一两百 MB 很容易功能越多、依赖越多、资源文件越多体积就涨得越快。比较有效的几个手段用资源混淆和移除无用资源去掉那些已经没有引用的图片和字符串。按需引入第三方库而不是为了某一个方法就引入整个 SDK。大图尽量压缩或用 WebP 格式替代 PNG。架构拆分时注意原生库的包含范围armeabi-v7a、arm64-v8a、x86 按需保留。对于 Studio 类 App还要额外留意内置模板、字体、示例素材的体积。如果项目本身需要下载大量内容尽量放服务端按需下载不要全部打进安装包。5.3 升级策略和灰度发布不是大公司才需要的机制有些独立开发者觉得用户量少不用做更新提示用户要升级自然会在商店里搜。但实际情况下用户不升级就会遇到老版本客户端与服务端不兼容的问题。你修了一个严重崩溃如果用户不更新到新版本这个修复对他来说完全无效。发布准备阶段至少要配置一个简单的版本检查接口包含三个字段最低支持版本号低于这个版本的客户端可以提示更新避免用户停留在有严重问题的旧版本。最新版本号用于和当前版本对比提示用户去更新。更新说明让用户知道这个版本修复了什么、新增了什么。如果条件允许再做一层灰度发布先放出 5% 到 10% 的用户作为观察组确认崩溃率和关键接口错误率正常后再放全量。即使你的 App 是通过应用市场直接发版也可以先选少量渠道比较稳定的用户观察一段时间。6. 最后 10% 到底花在哪里以及我的收尾节奏建议很多人说的“最后 10%”其实不是剩余工作量的 10%而是从“基本功能可用”到“可以放心交给用户”之间那段大量重复验证、修复、回归的时间。按真实项目经验这个阶段耗时可能占整个项目的三分之一。6.1 从 90% 到 100% 的常见工作分配我一般会把最后的收尾时间分成下面几块第一回归测试占最大块。每次修复一个 Bug都要重新验证它相邻的流程是否被破坏。比如修了编辑页的保存按钮至少要重新检查项目列表的展示、详情页的数据、自动保存的触发时间、退出编辑的状态提示。没有完整回归会出现“修好一个旧 Bug引入一个新 Bug”的循环。第二真机和兼容性测试占第二块。重点不只在新款旗舰机还包括 5% 到 10% 用户还在用的旧机型。中低端 Android 设备的性能问题比如列表加载缓慢、图片缩放卡顿、长时间停留后内存上涨在旗舰机上往往很难复现。真要判断兼容性建议至少找一台内存 4GB 左右的 Android 和一些两三年前的机型来跑。第三版本发布材料整理占第三块。包括应用商店截图、功能描述、隐私政策链接、权限说明。Studio 类 App 如果涉及用户上传或云端存储还要提前确认隐私合规和数据存储方式的说明。这些材料看似不写代码但缺少任何一个上架审核就可能被驳回。6.2 如果只剩两周时间我会怎么排优先级假如 Hermes Studio App 还差最后两个星期就要发布下面这个优先级顺序可以参考先处理会造成数据丢失或无法启动的问题比如本地数据库迁移失败、启动闪退、自动保存数据损坏。这类问题影响范围最大不管多小概率只要触发就是严重事故。再处理核心流程不可用和明显卡顿比如新建项目、打开素材、保存导出这些路径。不要让用户完成第一次核心操作就遇到失败。之后处理兼容性问题和界面细节比如个别机型输入框被键盘遮挡、深色模式下文字看不清、返回手势冲突等。最后如果时间还有剩余再去加一些体验优化和“锦上添花”的功能。如果时间不够砍功能不是可耻的决定带着明显不稳定的功能上架才是更大的风险。我个人的建议是在这个阶段把每天的开发任务分成“修复类”和“优化类”先把修复类清掉再排队做优化类。更具体地每天下班前跑一遍核心路径冒烟测试确保当天改动没有破坏主流程。连续三天核心路径通过率 100%再讨论“把进度从 90% 更新到 95%”也不迟。6.3 最后一轮自测清单可以按这个顺序过一遍开发进度到 90% 时我建议你已经有一套自己的自测清单而不是临时靠记忆来检查。一个移动 App 在收尾阶段的检查顺序通常按从底层到上层的顺序来安装启动全新安装、覆盖安装、卸载重装。账号状态首次启动、登录态有效、登录态过期、退出再登录。首页加载有网、无网、弱网、服务端超时。核心操作创建、编辑、保存、删除、导出。数据一致性列表刷新、详情刷新、本地和服务端数据同步。异常处理网络中断、后台回收、存储空间不足、相机或相册权限被拒绝。设置与反馈修改设置后立即生效、提交反馈后能看到结果。日志检查关键操作有日志错误信息可读。这套顺序的核心逻辑是先保证用户能走到核心流程再保证核心流程在异常条件下不会崩溃最后保证出了问题能查。如果把顺序反过来先调动画效果再做网络容错后面返工的概率会很高。如果你把 Hermes Studio 的最终版本定义为“功能做得比对手多”那今天的进度就不够。如果你把最终版本定义为“用户能稳定完成核心任务升级不丢数据崩溃能查清原因”那 90% 确实是一个非常关键的时间点——它离完成还有几步但它已经不是做加法的主场而是做减法、做清理、做修复的战场。我自己在项目到这个阶段时最常说的一句话是别急最后这段路的每一步都值得慢慢走。