面试篇：跨端客户端岗位的面试复盘与考点拆解

这篇记录我用两个真实项目准备跨端客户端岗位面试的复盘：面试官会问什么、追问的颗粒度到哪一层、怎么把自己的工作讲成”可验证的证据链”。AI 可以作为实现工具，但不能替代对方案和结果的理解。

一句话定位

面试准备的核心不是”背答案”，而是把做过的事整理成面试官能往下钻的证据链：项目目标、负责范围、具体数字、踩过的坑、验证方式和上线结果。

面试时可以先说：

我负责 ERP App 的客户端架构与持续交付，以及 Android PDA 仓储系统的从 0 到 1 落地。前者涉及 RN 新架构迁移、OTA 热更新与异常监控，后者涉及 Kotlin + Jetpack Compose、多厂商扫码适配和仓储业务一致性。

面试官怎么评估候选人

复盘时我按三条原则理解面试官的思路：

不可背答案：追问会一路钻到”你当时怎么定位根因""改的是哪一行""复现时看了什么日志”。
强制取舍：在两个都”正确”的方案里选一个，看的是判断标准，不是正确答案。
细节颗粒度：能说到”哪个厂商的广播 action""校验在下载前还是下载后”，才说明真的做过。

考点一：OTA 热更新体系

面试官可能问

OTA 更新的是 JS bundle 还是包含原生代码？
runtimeVersion 和 bundleVersion 有什么区别？为什么 runtime 不匹配就拒绝更新？
SHA-256 校验失败怎么处理？重试还是回滚？
灰度是服务端控制比例还是客户端逻辑？
更新包安装失败或启动崩溃，客户端怎么自愈回滚？
内嵌 bundle 和已安装 bundle 双轨设计解决了什么问题？

我的答案框架

OTA 更新的是 JS bundle，原生能力必须随商店版本走，所以存在”原生版本”和”业务 bundle 版本”两个维度。runtimeVersion 描述原生运行时的兼容基线，bundleVersion 描述业务包版本：原生不匹配时更新必须被拒绝，否则新 bundle 可能调用不存在的原生模块。

决策链是：manifest 启用开关 → 平台配置 → runtime 匹配 → bundle 版本比较 → 是否允许更新。校验在下载后、安装前进行，SHA-256 不一致直接拒绝并保留旧包。灰度由服务端下发比例或版本范围控制，客户端只负责”要不要更新、更新到哪个版本”的决策。安装失败时保留上一版可用 bundle，启动时如果新 bundle 反复崩溃，回退到内嵌的稳定版本。

考点二：React Native 架构迁移（850 页面）

面试官可能问

为什么从 0.72 迁到 0.86？跨这么多版本的风险在哪？
850 个页面迁移怎么拆解？AI 做了什么、你做了什么？
怎么判断一个第三方依赖”要不要搬”？
新架构下哪些老库不兼容？具体现象和根因是什么？
迁移后怎么验证 846 个页面没有回归？

我的答案框架

迁移顺序是：先建 0.86 空工程 → 跑通热更新等核心链路 → 按依赖兼容性逐个接入 → 再按业务模块搬页面。先解决最不确定的风险，再做机械工作量，避免搬完 850 页发现核心链路不通。

组件化是迁移能收敛的关键前提：页面是”公共组件 + 业务组件 + 传参”的组合，迁移时改一处、处处生效，所以大部分页面几乎不用改。AI 负责执行搬运，我负责策略和验收。

依赖兼容分三类：可直接升级的、需自研适配的、没有新架构支持需替换的。典型问题：第三方下拉刷新组件在 Fabric 下失效（Android 改官方能力、iOS 重写样式）、图片组件 loading 效果在新架构下异常、React Navigation 升级后页面可用高度测量变化导致布局挤压。不兼容的旧依赖用兼容层封装隔离，不把老项目的补丁债带进新架构。

考点三：Android PDA 多厂商扫码适配

面试官可能问

支持哪几种扫码通道？广播扫码和相机扫码怎么共存？
不同厂商（Honeywell/Symbol/Zebra/优博讯/Urovo 等）的广播怎么统一？
相机扫码（CameraX + ML Kit）和广播扫码的结果怎么分发成一套接口？
遇到没见过的 PDA 品牌，第一件事做什么？

我的答案框架

两层抽象：通道层负责采集（广播扫码监听多个厂商的 action 和 extra key，按优先级提取条码；相机扫码用 CameraX + ML Kit 作为无广播设备的兜底），分发层统一成 onScanResult(String) 回调给业务层，业务不感知硬件差异。新设备接入只需在 action 列表加一个广播，不改业务代码。

考点四：APK 在线升级闭环

面试官可能问

更新清单为什么强制 HTTPS？
SHA-256 校验在下载前还是下载后做？
FileProvider 解决什么问题？
安装权限被拒怎么引导？下载中断怎么处理？

我的答案框架

更新清单强制 HTTPS 是为了防中间人篡改（被篡改的清单可能指向恶意 APK）。SHA-256 在下载完成后、安装前校验，避免校验通过后才下载的时序问题。Android 7.0 以上通过 FileProvider 暴露 APK 文件给安装器，否则会触发 FileUriExposedException。安装权限被拒时引导用户到系统设置开启”允许安装未知来源应用”。

考点五：仓储业务一致性

面试官可能问

重复扫码怎么防？
两个 PDA 同时操作同一箱货怎么办？
二维码状态流转在客户端做还是服务端做？为什么？
离线时扫码操作怎么办？

我的答案框架

重复提交和并发冲突的最终裁决在服务端：客户端做前置校验（按钮禁用、本地状态流转），服务端做幂等和状态校验，两者结合才能保证一致性。二维码状态流转以服务端为准，客户端只做乐观展示和错误回显。核心逻辑用单元测试覆盖（转账/容器/标签复核等），保证仓储规则不被 UI 改动破坏。

面试里我怎么证明”深度”

用数字和对比建立证据链，而不是形容词：

迁移：850 页面、1 个月、接口协议不变、Crash 率稳定在 0.5% 以下。
发布：OTA 让业务发布从商店审核的数天缩短到分钟级。
工程化：新架构甩掉 17 个老补丁，回归测试覆盖 197 个接口。

面试官要的不是”我做过”，而是”我有可验证的结果”。

复盘总结

诚实标注边界：哪些是 AI 做的、哪些是我判断的，主动说清楚，比被问穿强。
失败经验同样值钱：鸿蒙三端统一方案失败后放弃跨端抽象、改为 ArkTS 重写——能讲清失败原因和后续判断准则，比完美的履历更可信。
主动澄清需求：被问到”三个月交付”时先问”交付什么”——明确交付边界再排计划，是负责人思维。