鸿蒙应用

🏦 场景与客户

一家做企业移动办公的软件团队，产品此前是安卓应用，靠兼容方式在鸿蒙手机上运行。随着新版本系统不再支持直接安装安卓包，用户群里开始出现「装不上」的反馈，公司内部也有设备在陆续换代。

客户要的不是简单打包，而是「一次开发、多端部署」的原生版本：手机、折叠屏、平板都要能正常用，并且借这次重写把几处历史包袱清掉。难点在于生态还在早期，很多第三方能力没有对应的原生版本。

📅 实施节奏

• 第 1–3 周：清点依赖，逐个确认是否有对应的原生能力，没有的列出替代方案
• 第 4–9 周：重写主体界面与业务逻辑，先跑通登录、审批、消息三条主链路
• 第 10–11 周：做多设备形态适配（折叠屏展开态、平板分栏），并补齐隐私清单与权限说明
• 第 12 周：提交应用市场审核，同步准备内测分发

🗝️ 方案要点

• 先清点依赖再动工：把每个第三方能力按「有原生替代 / 需自研 / 只能降级」三类标注，避免写到一半才发现某块做不了
• 声明式界面重写：界面结构与旧版完全不同，等于重做一遍 UI，但换来的是多设备形态的自适应能力
• 权限申请要有理由：每一项敏感权限在申请时必须给出与功能对应的说明，随包提交的隐私清单要与实际行为一致
• 一次开发多端部署：把布局的断点做成配置，折叠屏展开、平板横屏各有一套排布，而不是三套代码

⚖️ 选型与权衡

🚧 实施难点与排查

• 旧接口调用方式全部作废：底层消息与存储的用法与原来完全不同，等于重学一遍。团队先花一周集中做技术验证，把八个关键场景跑通再全面开工
• 缺少对应的推送能力：原本依赖的第三方推送没有原生版本，改用系统级推送通道，同时保活策略需要重新设计
• 审核被打回：隐私清单里少声明了一个实际会读取的设备信息。补齐并按实际行为逐条核对后通过
• 折叠屏展开态布局错乱：列表在展开后仍按单列渲染，右侧大片留白。为宽度变化加了断点，展开时切成分栏布局

💵 成本与收益

• 成本结构：人力是大头（重写接近一次新产品开发）+ 测试设备采购（折叠屏与平板必须真机验证）
• 收益侧：解决了新系统装不上的问题，保住了正在流失的用户；多端适配一次做完，后续上平板与折叠屏不再重复投入
• 省钱的关键：先做技术验证再全面开工，能避免把人力砸在走不通的路线上

🛡️ 风险与保障

• 生态早期风险：部分能力与工具链还在演进，关键路径保留降级方案，不把产品体验绑死在单一新特性上
• 合规：隐私清单、权限说明与实际采集行为三方一致，逐条自查
• 质量：真机矩阵覆盖手机、折叠屏、平板三类形态，不做「模拟器通过即上线」
• 回退：并行期内保留旧版本可用，新版出现严重问题时用户可以退回

♾️ 可复用与演进

• 这次沉淀的多端断点方案与降级策略，可以直接用于后续的新功能开发
• 演进方向：把跨设备接续等系统特性用到真正的效率场景上，例如手机上审批到一半、平板上继续
• 再往后：随着生态补齐第三方能力，把自研的替代模块逐步换回标准能力，降低维护负担