陶嘉恒移动端开发这几年变化不小。我最早做 Android 的时候，市场上要求的是“能独立开发 App”，会搭界面、会调接口基本就能找到工作；现在再看，Java、Kotlin、Swift、OC、React Native、Flutter、Web 端能力全部被揉进了同一条岗位描述里。很多准备面试的朋友问我：移动端到底还要不要深耕？我的答案一直很明确——能同时吃透 Android、iOS、React Native 和 Web 这条技术栈的人，价值不仅没有缩水，反而比前几年更稀缺。
这篇文章不是面试题答案汇总，更像是我过去几年在 Android、iOS、React Native 和 Web 项目里踩坑、复盘、面试别人也被别人面试之后，整理出来的一套系统化备考和成长框架。适合正在准备移动端岗位面试的同学，也适合入行一两年想梳理自己能力边界的人。内容尽量直接，把面试官关心的底层逻辑讲透，把容易忽略的工程细节翻出来。
1. 移动端工程师的能力坐标系：到底考什么
1.1 工程能力：不是“会写”，而是“能交付”
工程能力这个说法听起来很虚，但面试官一眼就能看出差距。初级候选人喜欢说“我负责 XX 模块开发”，高级候选人会聊“我们如何定代码规范、如何压启动耗时、如何设计降级方案”。两者之间差了一个关键词：交付闭环。
一个功能从需求拆解、技术方案设计、代码编写、自测、灰度发布、线上监控到异常回滚，你能不能完整走下来？这是面试里问到“你在项目里怎么排查线上问题”“如果重新设计这个模块你会怎么改”时，真正想考察的东西。
我习惯把工程能力拆成五个维度来做自测：需求理解能力、方案设计能力、代码实现质量、问题定位和自测效率、协作与交付意识。五个维度里，前三个决定你能不能把事做对，后两个决定你能不能把事做得持久。面试官问项目时，我会建议你主动把回答框架往这五个维度上靠。比如讲一个列表流畅度优化，不要只说我加了布局复用，而是往“问题怎么量化、方案怎么对比、上线后怎么验证、后续如何避免回归”整套去讲。这就是同一个项目，普通阐述和高质量阐述的区别。
1.2 系统与原理：面试深水区到底测什么
原生面试对原理的追问几乎是必然的。Android 喜欢问 Activity 启动流程、Binder 通信、Handler 消息机制、View 绘制流程；iOS 则爱考 ARC 内存管理、Runloop、消息发送机制、Block 循环引用。以前我也背过一轮标准答案就以为足够了，后来当了面试官才发现，这一层考察的目标根本不是标准答案，而是你有没有自己的理解路径。
从现象到原理、从 API 到源码，其实是在验证你面对未知问题的推演能力。API 是别人封装好的，看一眼文档谁都会用；原理决定了当出现一个新问题的时候，你脑子里的排查路线是清晰的还是盲目的。
学习原理我强烈建议用问题驱动的方式，而不是拿源码从头啃。比如 Android 的 View 绘制流程，你问自己“为什么自定义 View 里 onMeasure 总是先于 onLayout”“子 View 的点击区域是怎么被命中的”，每个问题都会引出一段源码，你在源码里找到答案，这个知识点才真正变成你的。iOS 的 Runloop 也一样，与其背 Sources、Timers、Observers 三个概念，不如先问“NSTimer 在滚动页面时为什么不准”“主线程卡顿监控怎么实现”，带着实际疑惑去看代码，效率会高很多。
1.3 跨端与全局视野：为什么现在没人只招纯原生
看近几年的岗位 JD 能明显感受到，纯原生岗位变少，混合技术栈岗位越来越多。很多业务包都变成了 Android + iOS 原生能力打底，再用 React Native 或 Flutter 做业务扩展，前端 Web 页面还要通过 WebView 融进 App 里。这种技术形态决定了一个移动端工程师不能只盯着一棵树。
我遇到过不少原生开发很强、但对 React Native 的理解停留在“会用”层面的候选人。一旦追问 Bridge 怎么通信、白屏怎么排查、JS 线程和 UI 线程是什么关系，就开始含糊。这种能力断层在高级岗位面试里非常吃亏，因为跨端问题本质上是原生能力和前端能力的结合，两边都懂一点才能做出正确的技术决策。
所以这篇文章把 Android、iOS、React Native、Web 四条主线串起来讲。它们不是四个互相独立的岗位方向，而是同一个“移动端交付能力”的不同侧面。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Android 与 iOS 技术栈：原生基本功的修炼路径
2.1 Android 主线：组件、进程、渲染与性能优化
Android 技术的核心框架可以用四个关键词概括：组件、进程、渲染、性能。四大组件（Activity、Service、BroadcastReceiver、ContentProvider）是应用和系统交互的入口，组件之间的通信靠 Intent，底层进程通信靠 Binder，界面变化靠 View 体系，性能问题集中在启动、渲染、内存、网络这几个维度。
这里说几个面试高频的细节。第一个是 Handler 机制。面试官特别喜欢借 Handler 问内存泄漏，原因链条其实很清楚：非静态内部类会持有外部类引用，MessageQueue 持有了 Message，Message 持有了 Handler，延迟消息期间 Handler 又间接持有 Activity，如果 Activity 已经销毁，就形成了泄漏链。回答时如果能说出“用静态内部类加弱引用，或者在 onDestroy 里 removeCallbacksAndMessages”这种完整解法，基本上就拿下了。
第二个是启动流程与启动优化。应用进程从创建到第一帧画面的时间怎么量化，常用的优化手段有启动事务拆分、异步初始化、延迟初始化、懒加载等等。这里特别要强调，优化不能只靠感觉，得用工具看数据。Android Studio 自带的 CPU Profiler 和 Memory Profiler 要会用，火焰图能帮你快速定位到耗时方法和高频调用，不会用这些工具，启动优化做起来就是盲人摸象。
第三个是分区存储和文件访问权限。我见过很多格式类似 content://com.baidu.searchbox.fileprovider/baiddpath 或者 content://com.ss.android.uri.key/external_root 的路径，这背后其实是 Android 的 FileProvider 机制和分区存储限制。从 Android 7 开始，App 之间共享文件不再允许直接传 file:// URI，必须用 content:// URI 配合 FileProvider；Android 10 以后分区存储进一步收紧了外部存储访问，很多旧代码直接把 /storage/emulated/0/Android/data/... 拼出来传给别的应用，很容易踩坑。遇到这种问题，正确做法是用系统提供的 MediaStore、SAF 文档树或者 FileProvider，而不是硬凑绝对路径。
xml复制<provider
android:name="androidx.core.content.FileProvider"
android:authorities="${applicationId}.fileprovider"
android:exported="false"
android:grantUriPermissions="true">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/file_paths"/>
</provider>
再补充一个容易忽略的小点：Android 的动态图标主题和 Material You 动态取色，已经成了不少业务需求的来源。适配动态图标时要注意图标尺寸、前景层与背景层分离、以及不同启动器桌面环境的兼容。虽然这类需求不像核心架构那么有技术含量，但在面试描述项目时能提到你做过系统级适配，也会是加分项。
至于 Gradle 和 AGP 版本匹配的问题，新版 Android Studio（比如 Hedgehog 等 2023 版本）默认支持 AGP 8 系列，如果你把低版本 AGP 塞进新版 IDE，大概率会报兼容错误。升级环境前先查官方兼容性表格，能省下大量折腾时间。
2.2 iOS 主线：内存管理、Runloop、UI 与签名发布
iOS 的核心主线跟 Android 不太一样，它更强调内存管理、运行循环、UI 层级的约束以及签名发布的工程细节。
内存管理这一块，ARC 虽然自动接管了 retain/release，但循环引用依然要靠开发者手动解决。Block 捕获 self、delegate 用 strong 修饰、NSTimer 的 target 持有，这三类都是循环引用典型场景。面试里回答“Block 里用 self 会不会泄漏”不能只背结论，要分情况讨论。如果是普通 Block，self 被 Block 持有、Block 又被 self 持有，会形成环；如果 Block 被系统短暂持有并在执行结束后释放，则不一定会泄漏。能把条件边界说清楚，面试官会眼前一亮。
Runloop 也是必考项。面试官会问“为什么主线程不会退出”“NSTimer 在列表滚动时为什么不准”。这背后本质上是 Runloop 对源、定时器和观测者之间的调度逻辑。你如果做过卡顿监控，会对这一点有更深理解：主线程 Runloop 的两个 observer 之间的时间差，就能算出一帧是否超时，这正是很多 APM 工具的底层实现思路。
UI 方面，Auto Layout、UIStackView、UICollectionView 适配都很常见。UIStackView 在多数场景里能极大简化约束，但它对隐藏元素、多行文本宽度变化的支持并不总是顺手，遇到复杂自适应布局还是要回到明确的约束关系。另外 iOS 分屏和 iPad 多任务适配是一个容易忽略的加分点。如果项目需要支持 iPad 分屏，你要考虑 SafeArea、自适应尺寸、约束优先级等细节，这些内容写在简历里，比单纯写“熟悉 UIKit”有说服力得多。
签名和打包也是实操和面试绕不开的环节。iOS 开发者证书分为 Development 和 Distribution 两类，签名时 App ID、证书、描述文件（Provisioning Profile）三者必须匹配。所谓“开发者 App 证书更新”，通常指的是证书到期后需要重新生成描述文件，或者新增设备后要更新开发描述文件。真机调试需要打开开发者模式（iOS 16 及以后更严格），测试包可以通过 Xcode 导出或用持续集成工具统一构建。即使你用的是 uniapp 这类跨端框架打 iOS 测试包，本质上也绕不开签名这一关，只是把流程脚本化了。如果这段流程你没完整跑过一遍，面试讲起来会明显底气不足。
2.3 原生面试的高频考点与答题思路
把两个平台的高频考点放一起看，会更有意思。下面这个表是我这些年面试他人时重点考察的方向：
| 考点 | 面试官实际想考察的能力 | 答题要点建议 |
|---|---|---|
| Android Handler 机制 | 对消息循环与内存泄漏的理解 | 讲清 MessageQueue/Message/Handler 协作，给到泄漏场景和解除方法 |
| Android Binder | 对跨进程通信设计思想的理解 | 从一次 IPC 调用出发，说清 copy-once、内核驱动、客户端-服务端模型 |
| Android 启动优化 | 性能分析与工具使用 | 指标量化、耗时拆分、异步/懒加载方案、用 Profiler 验证 |
| iOS ARC 与循环引用 | 内存管理掌握程度 | 列举 Block/Delegate/Timer 典型环，给出 weak/unowned 判断标准 |
| iOS Runloop | 对运行循环与 UI 性能的理解 | 讲出 MainRunloop 模型、Timer 不准确原因、卡顿监控思路 |
| 双端网络层设计 | 跨平台抽象能力 | 统一请求层、重试/缓存/降级、Mock 与线上监控 |
答题思路上，我建议遵循“上下文—问题—方案—验证—复盘”的框架。不管问题多简单，都不要跳步。比如“ANR 怎么排查”，正常回答是：ANR 分为输入无响应、广播超时、服务超时等类型，先看 logcat 里的 ANR 日志、主线程堆栈，再用 trace 文件定位到阻塞位置，结合业务场景判断是主线程 IO、锁竞争还是死锁。这个顺序本身就体现了你的排查套路，比只背一个“看 trace”有说服力得多。
3. React Native 与 Web 技术栈：跨端思维的工程化认知
3.1 React Native 原理：从 JS 到原生视图
React Native 不是把网页套个壳，它是一套用 JavaScript 描述界面、最终落到原生组件渲染的框架。传统架构里，JS 代码运行在独立的 JS 线程，通过 Bridge（JSBridge）把组件信息和事件请求发给原生侧，原生侧再调用真实的 View 渲染。这个过程中最容易被问到的问题就是 Bridge 为什么慢、RN 启动白屏的原因是什么。
RN 启动白屏，本质上是因为首帧渲染需要等待 JS Bundle 下载或加载、JS 引擎初始化、执行 React 渲染逻辑，再通过 Bridge 把组件树同步到原生层。如果 Bundle 在本地，初始化阶段耗时几百毫秒到一秒多都很常见；如果 Bundle 从网络下载，时间更长。优化方向大体是几个：Bundle 本地化和分包、启动时预加载、首屏渲染异步化、用原生页面做启动兜底。
新版架构（New Architecture）引入 Fabric 渲染器和 TurboModule，跨端通信方式从异步 JSON 消息改成了更直接的 JSI（JavaScript Interface），通信效率提升明显，但迁移成本也高，很多老项目还在旧架构上。面试里如果你能主动说“新旧架构在通信模型上的区别，以及我们项目为什么暂时没升级”，说明你是真在项目里做过技术选型，而不是临时看两篇介绍就上考场。
现在 React Native 也不再局限于手机平台，像 RN for OpenHarmony 这类适配方案已经出现，说明跨端框架正在走向更多系统生态。对工程师来说，理解框架的抽象边界，比背诵某个平台的单一 API 更有价值。
3.2 RN 项目实战：启动白屏、热更新与自定义组件
RN 项目实战里最常见的问题有三类：启动白屏、热更新管理、自定义复杂交互组件。
启动白屏的原理前面讲了。实际操作里还要加上启动页的过渡策略。我做过一个项目，把启动图和 RN 渲染完成的时机通过 Bridge 事件串起来，原生首帧先展示品牌页，JS 侧渲染完成后再通知原生切换，体验平滑很多。另一个思路是让首屏静态组件先用原生渲染，业务动态区域再交给 RN，这种混合渲染模式在做性能优化时很管用。
热更新是 RN 的优势场景，但容易踩坑。热更新框架（比如 CodePush 那一类方案）会把 JS Bundle 推送到客户端，发布前必须做好灰度策略和回滚能力。要特别小心原生模块和 JS Bundle 的版本耦合，如果原生代码改了接口或新增了方法，旧 Bundle 强制升级就可能白屏或崩溃。所以发布流程里一定要校验版本号，甚至做 Bundle 和原生包的兼容矩阵。
再说到自定义组件。有人问 React Native 怎么实现循环滚轮，这种高度定制化的列表组件，先别急着搜现成库。你可以先用 FlatList 或 ScrollView 做基础滚动，计算每一项的高度，通过滚动偏移量算出当前 index，最后切换时做一个对齐偏移处理。如果还要原生手感，就通过原生 UI 模块在 Android/iOS 各自实现一个滚动选择器，再封装成 RN 组件暴露给 JS。选型依据很明确：纯 JS 实现适合数据量小、交互简单；原生实现适合数据量大、手势要求高。能把这一套取舍讲清楚，胜过背一百个组件库名。
3.3 Web 技术栈：移动端工程师的隐藏底牌
Web 技术栈对移动端工程师来说很容易被忽略，但它恰恰是面试里能拉开差距的隐藏底牌。移动端 App 里有大量业务跑在 WebView 上面，从公众号 H5、小程序，到 App 内嵌的活动页面，底层都是 Web 技术。
WebView 的 JSBridge 设计是高频考点。举个具体例子，页面需要唤起 App 下载或打开原生页面，用到的是 URL Scheme（比如 myapp://open?page=xxx）或者 Universal Link / App Link。面试里如果让你设计一个 Web 唤起 App 的方案，你需要考虑：唤起失败的跳转策略（比如跳去应用商店）、WebView 内自动跳转拦截、外部浏览器与 App 内嵌 WebView 的差异处理。这些细节都处理过，才算真正完成过这个需求。
另外，Web 端性能和工程问题也要懂一点。Web 页面 PDF 打印、浏览器端实时视频播放，这些听起来和移动端不相关，但一旦 App 里需要展示 PDF、需要嵌入实时视频流，全都要靠 WebView 能力来解决。再往 Web 后端延伸，移动端工程师至少要知道一个 Web 项目是怎么部署的。Tomcat 部署 Java Web 项目、Nginx 托管前端静态资源、服务端进程和端口配置，这些基础概念能帮助你在联调和排查问题时少走弯路。还有 Web 服务器安全的基础点，比如 HTTPS 证书配置、CORS 跨域、接口鉴权、防注入，这些不要求你会写后端，但出了问题能和对方有效沟通，这本身就是工程能力的一部分。
4. 面试全流程实战：简历、Coding、项目深挖与反问
4.1 简历筛选的六个关键信号
作为面试官，