安卓应用

🏦 场景与客户

一家连锁服务企业的员工端应用，覆盖两千多名一线员工，用来接收工单、打卡上报、查排班。此前的版本是三年前外包做的，装机后问题不断：新手机装不上、后台被杀收不到工单、有几个应用商店一直审核不过。

客户不加功能，只求「把现有的功能做稳、能上架、能推得动」。员工手机型号极杂，从千元机到旗舰机都有。

📅 实施节奏

• 第 1–2 周：梳理目标机型分布与系统版本，确定支持范围与最低版本
• 第 3–6 周：重构工单与消息模块，接入厂商推送通道
• 第 7 周：隐私合规自查，逐条核对权限与第三方组件清单
• 第 8 周起：分批上架各应用商店，先上审核最严的两家，把问题暴露在前面

🗝️ 方案要点

• 推送接厂商通道：国内系统对后台进程管得严，必须逐家接入厂商推送通道，靠单一长连接在部分机型上必然收不到
• 权限最小化且逐条说明：每项权限在申请时必须说明用途，且不能在首次启动前就索取，否则直接触发合规问题
• 第三方组件清单公示：所有引入的第三方组件要登记来源与采集范围，出问题能立刻定位到具体组件
• 不做无理由的自启动与关联启动：这类行为在合规检查里是高危项，宁可接受冷启动慢一点，也不去申请
• 机型适配靠真机：低端机与折叠屏各备几台真机，布局与性能问题在真机上暴露，不在模拟器上自欺

⚖️ 选型与权衡

🚧 实施难点与排查

• 上架被打回：隐私政策在首次启动前的同意环节缺失，用户未同意就能被采集设备标识。把同意动作前置，并延迟所有采集到同意之后
• 消息收不到：某品牌机型上工单推送长期丢失，根因是只接了通用通道、未接该厂商通道。补齐后恢复
• 低端机闪退：工单列表一次性加载过多图片导致内存溢出。改为分页与图片降采样后稳定
• 打卡定位偏移：室内定位精度不够，员工在写字楼里定不到位。改为允许人工补录并附现场照片，由主管确认

💵 成本与收益

• 成本结构：重构开发投入 + 真机采购 + 各商店的开发者认证费用（每家有年费）+ 持续的适配维护
• 收益侧：工单到达率提升后，一线响应速度有改善；应用能在主流商店稳定上架，新员工装机的阻力基本消失
• 省钱的关键：适配成本主要在真机与人力，把支持的系统版本范围定准，比无边界地兼容所有老机型更划算

🛡️ 风险与保障

• 合规：隐私政策、权限说明、第三方组件清单与实际行为保持一致；首次启动前不采集任何信息
• 安全：员工数据按角色分权，打卡与定位信息只用于考勤核对，不做其他用途
• 可用性：弱网环境下工单可本地暂存，恢复网络自动上传，避免一线在信号差的地方干不了活
• 发布：签名与渠道包统一管理，灰度发布，出问题可回滚到上一版本

♾️ 可复用与演进

• 「多厂商推送 + 合规前置 + 真机适配」这套做法可以复用到其他面向一线员工的应用
• 演进方向：按机型和系统版本分布决定支持策略，把适配资源投在真正的存量主力上
• 再往后：把工单数据与排班、考勤打通，让一线不用在多个应用之间来回切换