从 0 到 90%Hermes Studio App 开发进度复盘以及最后 10% 到底要做什么很多移动端团队都会遇到同一个场面产品经理在群里问“进度到多少了”你看着功能列表里只剩几个小项顺手回一句“大概 90%”。结果这句话说完接下来的两周可能是整个项目最煎熬的阶段——不是没有功能可写而是关于“算不算完成”的标准开始分叉。如果你也在开发一款 App恰好走到 90% 这个节点你会发现一个尴尬事实90% 不是一个量化的完成度它更像是一个责任交接点。技术上功能基本闭环但是稳定性、兼容性、发布流程、异常兜底、包体大小、数据埋点……这些藏在功能背后的东西开始集中向你讨债。本文以 Hermes Studio App 的阶段性开发为背景讲清楚三件事第一项目走到 90% 时工程上到底处于什么状态第二为什么最后 10% 经常消耗掉前面 50% 的时间第三如何用一套可执行的检查清单和验证方法把“我估计 90%”变成“我确认 90%”。1. 90% 进度的真实含义功能完成不等于发布就绪先说一个基本判断在一个商业 App 项目里进度到 90% 意味着“代码完成度”接近尾声但“工程完成度”刚刚进入最关键的收敛期。为什么这么讲因为软件项目的常规节奏是需求分析阶段进度增长平缓编码阶段进度会快速上涨等核心页面和接口都通完你自然会在任务管理工具里看到接近满格的进度条。但从测试、灰度、回归到上架发布这两周里需求变动很少代码提交也变少了背后做的事情却几乎不可见。Hermes Studio App 走到 90%从任务拆解角度差不多是这样一个状态主要页面完成、后端接口联调通过、核心链路能跑通、验收测试环境部署成功。但与此同时问题清单里可能还躺着几类无法用“功能开发”去概括的隐患弱网和异常中断场景没有完整覆盖低端机型的内存占用和启动耗时没有专项治理不同 Android 厂商 ROM 的兼容性只做了少量抽样UI 细节在全面屏、折叠屏上的适配还没完全验收日志、埋点、崩溃上报是否收敛还没有人给结论。发现没有这些问题都不会让你的功能列表变红却都会影响“可发布”这个最终结论。到 90% 的时候如果团队还习惯用“功能任务是否关闭”来衡量进度就很容易出现虚假的乐观。真正专业的做法是把进度口径拆成两套进度口径代表含义判断标准风险功能进度需求是否被编码实现任务状态是否为已完成容易被“demo 能跑”误导发布进度版本是否可以交付用户回归、兼容、性能、合规是否通过接近尾声时会暴露大量隐性债务如果一个项目组说“进度 90%”但问不出下面几个问题的答案那这个数字大概率只是估算值剩余未关闭的 Bug 按严重级别如何分布崩溃率、卡顿率、冷启动耗时是否有基线数据是否在最低配置测试机上完整跑过一遍核心路径回归测试用例的覆盖率到达了什么水平未完成项里有没有“会导致不能上架”的高优先级风险所以这篇文章的第二个判断是90% 是一次盘点机会不是一句进度汇报。盘点清楚最后 10% 是确定性冲刺盘点不清楚最后 10% 会成为无限趋近于 1 的极限题。2. 从时间账看“最后 10%”的特殊性开发过 App 的读者应该都有体感一个版本从 30% 到 70% 可能只需要一两周但从 90% 到真正的 100%经常又需要一两周。这不是团队效率变低了而是剩余工作的性质发生了根本变化。前中期开发是“顺水推舟”。页面按设计稿写接口按文档联调数据模型在本地和远端保持一致做完一个模块就清理一个模块。即便遇到阻塞通常也是局部性的换个实现方案就能绕过去。最后 10% 则是“逆水行舟”。它处理的不再是“新增能力”而是“消除不确定性”。比如视频或大图资源在弱网下的加载表现只有真机限制带宽才能暴露问题推送消息在国产 ROM 上的到达率必须逐台机型验证页面在 iOS 不同版本上的键盘避让、手势冲突需要在验收阶段反复回归后端联调时“偶尔正常、偶尔报错”的幽灵问题可能需要抓包配合日志链路分析。从时间分配看项目越靠近尾声越是会遇到“二八定律”的极端版本剩下 10% 的工作量由 80% 的不确定因素混合而成。我倾向于把最后阶段的工作分成两类类型典型任务时间预估特点确定性任务文案修改、图标替换、接口字段补齐可预估消耗时间平稳不确定性任务兼容性适配、性能优化、难复现 Bug不可预估可能反复试探对于 Hermes Studio App 这种工具属性较强的应用来说第二阶段的不确定性任务占更高比例是正常现象。用户拿着它处理工作室素材、预览作品、同步工程文件任何一次异常退出带来的损失都比普通资讯类 App 更严重。因此当团队某天在产品看板上贴出“90%”标签时正确的下一动作不是写代码加功能而是做一轮“完成度审计”把所有未验证项、未决策项、未闭环项全部摆到桌面上然后用最后的时间和资源逐一收敛。3. 阶段复盘从 0 到 90% 哪些环节最容易返工进度能走到 90%说明大方向没有跑偏。复盘不是为了否定前面的工作而是把返工成本高的环节挑出来为下一阶段的冲刺和后续版本沉淀经验。在本次 Hermes Studio App 开发复盘里有几个环节特别容易被低估值得展开说一下。3.1 接口文档与字段变更的连锁成本移动端开发最怕的不是接口少而是接口字段“悄悄变”。某个列表接口的返回结构里增加了一个嵌套对象后端认为这是向后兼容的增量变更但前端如果直接使用旧的模型类去解析轻则字段取不到值重则整个页面渲染崩溃。更隐蔽的情况是分页参数变化。早期联调时使用 page/pageSize后来网关标准调整为 offset/limit如果前端没有统一封装请求层就会在多个页面里散落着两套分页逻辑。等到 90% 阶段做全量测试才在某个二级列表页里发现分页数据重复。复盘结论接口请求层必须统一收口参数名、嵌套对象、错误码定义都不允许在各个业务模块里自行发挥。移动端要定义一个统一的 API Response 包装模型所有接口返回先经过该模型解析再分发到业务层。// 文件路径core/network/src/main/java/com/hermes/studio/network/model/ApiResponse.kt sealed class ApiResultout T { data class SuccessT(val data: T) : ApiResultT() data class Error( val code: Int, val message: String, val serverTime: Long 0L ) : ApiResultNothing() }这样设计的价值不在写代码的当下而在 90% 之后的回归阶段。当接口结构出现变化时统一模型层能更快定位是哪一段链路出现了字段不匹配。3.2 图片与资源处理“能跑”与“能用”的差距Hermes Studio App 的核心使用场景必然涉及图片、视频、工程文件等大体积资源。资源类需求在开发阶段很容易呈现出“能跑”的状态图片能显示、视频能播放、文件能上传大家就认为功能完成了。但到了真机验证阶段问题浮出水面高清大图没有采样压缩列表页内存暴涨视频封面加载没有占位图和重试机制弱网下黑屏图片加载库只配置了内存缓存磁盘缓存被忽略导致反复请求上传任务缺少断点续传一次网络波动就让用户重新选择文件。这类问题不会在功能演示时暴露因为演示环境通常是稳定的 Wi-Fi。可是在真实用户环境里地铁、电梯、地下车库都可能成为“压死骆驼的最后一根稻草”。从工程复盘角度看资源类需求应当从第一天就把“加载状态机”设计清楚加载中、成功、失败、重试、空数据、弱网降级。每个状态都要有对应的 UI 表现。以图片加载为例至少需要做三件事第一使用合适的图片加载库并在 Application 初始化时配置统一的磁盘缓存策略和内存缓存策略第二所有网络图片都必须配置占位图和错误图第三列表页的图片控件尺寸要提前确定避免因宽高未定导致的重复测量与跳动。// 文件路径core/ui/src/main/java/com/hermes/studio/ui/widget/RemoteImageView.kt class RemoteImageView JvmOverloads constructor( context: Context, attrs: AttributeSet? null, defStyleAttr: Int 0 ) : AppCompatImageView(context, attrs, defStyleAttr) { fun load(url: String?, placeholder: Int 0) { if (url.isNullOrBlank()) { if (placeholder ! 0) setImageResource(placeholder) return } // 实际项目可替换为 Glide / Coil / Fresco 的 load 扩展。 // 关键点是统一入口不要让业务层直接依赖具体图片库 API。 ImageLoader.load(this, url, placeholder) } }回头看如果 0 到 90% 的开发过程中能把资源加载状态机完整落地返工量至少能减少一半。3.3 真实设备适配远比模拟器复杂Android 开发中有一个屡试不爽的经验模拟器上一切正常上真机就会翻车。Hermes Studio App 在中期开发时部分页面只在模拟器和主力真机上验证到准备提测时才发现一些中低端机器的表现与预期差距很大。典型的适配问题集中在几个方面系统返回手势和页面内自定义手势冲突不同分辨率下 SafeArea 计算不正确输入法弹出后布局被顶起或遮挡桌面图标、通知栏权限、自启动权限在不同 ROM 上表现不一致折叠屏展开态与折叠态的布局切换。适配没有银弹最可靠的手段是提前准备一份“机型覆盖矩阵”按照屏幕尺寸、系统版本、厂商 ROM、内存档位来组织测试计划。90% 阶段做这件事虽然不如 40% 阶段从容但只要执行到位仍然能避免带着明显兼容问题发版。4. 进度 90% 时应交付的三份“工程资产”到了 90% 这个节点除了功能代码本身团队手中还应该有至少三份工程资产。如果这三样东西拿不出来那“90%”就值得打个问号。4.1 完整可复现的构建与打包流程App 开发到后期最怕出现“本地能跑、打包就挂”“A 同事构建成功、B 同事构建失败”这类环境依赖问题。任何走到 90% 的移动端项目都应该已经把构建流程固化到 CI 上。工程上需要保证代码仓库可以基于一条明确的 release 分支打出提测包构建脚本不依赖开发者本机的私密配置签名文件、密钥信息从环境变量或独立的密钥管理系统中读取每一次提测包都能追溯到对应的 commit。以 Android 项目为例可以在模块的 build.gradle 中把构建类型和签名配置做清晰拆分// 文件路径app/build.gradle android { signingConfigs { release { storeFile file(System.getenv(KEYSTORE_FILE) ?: release.keystore) storePassword System.getenv(KEYSTORE_PASSWORD) keyAlias System.getenv(KEY_ALIAS) keyPassword System.getenv(KEY_PASSWORD) } } buildTypes { debug { applicationIdSuffix .debug versionNameSuffix -debug } release { minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile(proguard-android-optimize.txt), proguard-rules.pro signingConfig signingConfigs.release } } }这样做的好处是任何一位新同事拉下代码后都能用统一的命令得到可预期的构建产物而不是靠某台电脑里残存的旧配置。4.2 可执行的回归用例清单功能测试往往会陷入“测得太宽”或“测得太窄”两个极端。90% 阶段真正有价值的是按照业务优先级整理的回归清单而不是一份又长又没有重点的执行文档。回归清单至少要覆盖核心链路启动、登录、权限申请、首页数据加载、详情页跳转、关键操作提交异常链路断网重试、弱网加载、接口超时、重复点击、进程被杀后恢复边界链路空数据、超长文本、特殊字符、最大长度限制、横竖屏切换数据安全链路本地缓存清理、离线数据恢复、退出登录后缓存清理。回归用例不应只存在测试人员本地的 Excel 里至少要沉淀为可复用的线上用例为后续自动化测试提供基础。4.3 发布前检查清单Release Checklist发布前检查清单就是软件工程里的“起飞检查单”。无论团队规模大小只要产品需要上架这份清单都值得写。它可以简单到用 Markdown 维护在仓库 docs 目录下。# Hermes Studio App Release Checklist ## 构建与产物 - [ ] release 分支基于最新 main 合并完成 - [ ] CI 构建通过 - [ ] 产物版本号与版本名正确 - [ ] 混淆产物中没有缺失类 ## 功能回归 - [ ] 核心链路全部走通 - [ ] 弱网场景基本覆盖 - [ ] 登录与权限流程通过 ## 兼容与性能 - [ ] Android 最低支持版本真机通过 - [ ] iOS 最低支持版本真机通过 - [ ] 冷启动时间在阈值范围内 - [ ] 核心页面内存占用无异常增长 ## 安全与合规 - [ ] 隐私政策弹窗正常展示 - [ ] 权限申请引导文案准确 - [ ] 敏感日志已脱敏 - [ ] 依赖库无高危漏洞 ## 数据监控 - [ ] 崩溃上报 SDK 正常工作 - [ ] 关键埋点验证通过 - [ ] 自定义上报字段符合规范这份清单还可以作为 90% 进度检查的自我审计工具。清单一项项能打勾才说明“可交付”。5. 最后 10% 的具体冲刺方案收口、排序与冻结假设一个团队已经在任务管理工具中点掉了大多数需求功能看板已经接近全绿此时需要做的不再是“填满进度条”而是“收口”。收口策略可以拆成六个部分。5.1 先做发布阻断项排查所谓发布阻断项指的是会让版本无法按预期上架的问题。比如启动崩溃、首屏无法加载、核心功能无法使用、合规要求不满足等。这类问题需要在最后阶段被单独列出来优先级高于任何优化项。建议由技术负责人牵头对照 release checklist 逐条确认。不要默认“应该没问题”所有结论都要求在真实版本、真实环境下验证后再回复。5.2 新需求一律冻结或转入下个版本90% 之后再临时加需求是进度失控的最常见原因。产品经理看到页面后想调整文案设计同学发现某个图标风格不统一这些需求虽然是合理的但它们不应该出现在当前版本中。更好的处理方式是把这些改动记录在需求池中打上“下期优化”的标签。真正的例外场景只有两类第一线上有安全漏洞必须立刻修复第二当前版本存在阻断发布的功能缺陷且没有替代方案。其余新想法一律延后。5.3 回归测试分层次进行如果不做分层最后阶段的回归往往会变成“全员点来点去”看起来测了很多实际上遗漏率很高。建议把回归测试拆成三层第一层是自动化冒烟测试。选择最重要的核心链路写成 UI 自动化用例每次出包后先自动跑一遍。这样做成本较高但它能快速发现是否有人在最后一刻合入了破坏性改动。第二层是业务模块手工回归。由各模块负责同学按清单执行重点覆盖业务规则和状态流转。第三层是交叉体验测试。换一个身份、换一台设备、换一个网络环境模拟用户真实使用路径往往能发现“本地测得好好的换台手机就翻车”的问题。5.4 性能与稳定性专项到 90% 阶段不要等到用户反馈再来做性能优化。至少选择一款主流中端机型执行完整的专项测试冷启动耗时、页面切换流畅度、内存占用、后台切换恢复、长时间使用后的响应速度。专项测试中常见的结论示例启动速度慢多是因为初始化了太多非必要 SDK页面卡顿多是因为主线程存在耗时操作或列表没有复用内存持续增长多是因为资源没有释放或存在静态 Context 引用。以启动速度为例可以通过一个简单的耗时统计来定位问题// 文件路径app/src/main/java/com/hermes/studio/core/StartupMonitor.kt object StartupMonitor { private val record mutableListOfPairString, Long() fun mark(tag: String) { record.add(tag to System.currentTimeMillis()) } fun printSummary() { var lastTime 0L val sb StringBuilder(Startup Trace:\n) record.forEach { (tag, time) - val cost if (lastTime 0L) 0L else time - lastTime sb.append(tag).append( ).append(cost).append(ms\n) lastTime time } Log.d(StartupMonitor, sb.toString()) } }在 Application 的各个初始化节点调用 mark就能用一条日志快速看出时间消耗在哪个环节。完成这一轮专项优化后把结论回填到 release checklist才算真正完成了质量收口。5.5 灰度与监控预案如果发布条件允许不要直接全量发布。无论内部测试做得多充分真实用户的环境组合总是超出预期。灰度发布能兜底一部分风险。灰度前需要确认崩溃上报服务是否稳定是否具备远程日志开关核心埋点是否齐全是否有快速下架或强制升级的方案。尤其要确认崩溃率监控的实时性。如果崩溃率上报延迟超过半小时发现严重问题后能做的止损动作就会变得非常被动。5.6 倒排时间表与最终验收最后阶段的排期建议按照“上架截止日”倒排。先留出应用市场审核时间、灰度观察时间、正式发布时间剩下的时间才是修正问题的时间。如果修正问题的空间只剩两天那么所有任务都要按“两天内能否完成”来卡优先级。不能在两天内解决的问题要么降级处理要么阻断发版。如果认为“也许用户不会遇到”那也要转化成明确的已知风险由产品和技术负责人共同签字确认而不是在代码里默默留着一个不确定项。6. 如何判断开发进度“真正”到了 90%一个项目到底是不是真的到了 90%有一个很朴素的判断方法随便找一位不熟悉代码的测试人员让他在一台新设备上按用户文档完成一轮核心流程操作。如果他能不向你问任何问题地走通而且中途没有遇到崩溃、白屏、数据错乱那这个 90% 就具备基本可信度。除此之外还有几个可以量化的观测维度。功能维度方面看的是「完成定义」是否统一。每一项功能不能以“代码写完”为完成标准而应定义成开发自测通过、代码评审完成、测试用例关联、联调通过。只要这四个动作都完成了功能才可以从看板移动至“已完成”。这一条执行得越严格进度数字的水分越少。质量维度方面要关注三个数字未关闭 Bug 数、严重 Bug 数、回归通过率。如果严重 Bug 一直保持在个位数以下且核心链路回归通过率接近满值说明当前版本具备提测条件。如果严重 Bug 超过两位数那 90% 只能解释为“功能编码完成 90%”离可发布版本还很远。稳定性维度方面一个基本门槛是测试期间没有高频崩溃。内部测试阶段如果都无法保持连续数小时稳定运行发布后的问题大概率只多不少。工程维度方面要求项目可以在干净环境下一键构建。代码仓库中应该具备一份标记清晰的 README包含环境配置、模块说明、联调入口、构建命令和常见问题。不要在只有一位核心开发能构建成功的情况下进入发行阶段。数据维度方面关键链路必须埋点完整。没有数据90% 之后的所有优化决策都是拍脑袋。7. 面对“90% 困局”的三个实操建议如果读者正负责类似的移动端项目或者马上要接手一个进度条显示为 90% 的版本下面的实操建议可以直接复制到自己的项目中。7.1 重新梳理任务优先级不要盲信任务工具里留下的排序。在最后阶段应当由技术负责人重新审视所有未完成任务把它们按照“发布阻断、质量优化、体验优化、后续版本”四个等级重新排队。一个可复用的规则是凡是影响核心链路稳定性的问题必须处理凡是不影响核心链路且无法在本版本验证完的问题放进下期凡是纯体验优化类问题除非改动极小且经过设计确认否则不进入当前版本。7.2 减少并行集中攻单点越到后期并行任务越多出问题。多个分支同时改到最后合入时可能出现代码冲突、依赖不一致、回归范围失控等问题。建议在最后两周内团队成员按模块边界认领自己负责的部分每天集中合并一次每次合并前先跑冒烟用例再合入主干。这里提一句工程上的做法尽量保持主干可发布。任何分支上的改动都应该在当天内合回主干并经过构建验证。这样不管遇到什么问题手里始终有一个“当前最高质量”的版本而不是等所有分支收齐再集成。7.3 明确 Owner 和决策权限最后阶段会有大量的取舍问题比如某个兼容性问题要不要修、某个文案是否要改、某个资源是否要压缩。如果每个问题都需要拉一群人开会进度一定会失控。建议在冲刺启动时明确三类 Owner技术 Owner负责判断技术可行性、评估改动风险产品 Owner负责判断需求优先级确认哪些内容可以延后质量 Owner负责最终发布验收拥有对版本质量的否决权。有了决策权限边界的约束团队才会在遇到分歧时快速收敛而不是反复讨论。8. 从 90% 到 100%最后拼的是确定性回到文章标题Hermes Studio App 今日开发进度 90%。如果只看任务工具这或许是个让人高兴的数字。但从工程视角看这更像是一个要求团队切换工作方式的信号。前 90% 拼的是功能实现能力考验的是把设计稿和接口文档转化为可用代码的速度。后 10% 拼的是交付控制能力考验的是在时间窗口内找到未知风险、验证功能边界、落实发布准备的程度。一个恰当的 90% 状态至少应该满足没有隐藏的、有争议的、悬而未决的接口问题各端负责人对“剩余工作为何延后”有明确解释核心链路已经过完整验证发布清单逐项落实团队没有继续堆积技术债而不记录。哪怕只剩一条不满足这个 90% 都只是乐观估计。与其继续在功能上补丁式改动不如把时间投入到验证接口、设备和流程的确定性上。这最后一段路真正拼的不是写码速度而是少出意外。如果项目正处在类似节点我建议把本文提到的 release checklist 复制到自己的仓库里逐项打勾再决定要不要宣布“完成了 90%”。毕竟测试环境里点通一条流程和生产环境中上千种机型里保持稳定是两个完全不同的 100%。