移动端面试高频：启动流程、内存管理与 ANR/OOM 排查

移动端面试有两类问题最能区分水平：一类是能不能讲清系统启动的完整链路（说明你理解平台），另一类是遇到线上崩溃/卡死能否给出排查路径（说明你真的做过项目）。

本文把这两块的高频真题整理成可背诵、可延伸的答题框架。

一、启动流程：两张流程图

Android 启动链路

1. 点击图标 → Launcher 通过 Binder 通知 ActivityManagerService（AMS）；
2. AMS 检查目标进程是否存在，不存在则通过 Zygote fork 出新进程（Zygote 预加载了框架类与资源，这是 fork 快的原因）；
3. 新进程创建 ActivityThread，执行 main()，初始化 Looper 与主线程消息循环；
4. AMS 通知进程创建 Application，回调 onCreate()；
5. 启动首屏 Activity：依次回调 onCreate → onStart → onResume；
6. View 树完成测量、布局、绘制后，首帧上屏，冷启动结束。

追问：“为什么要有 Zygote？”
因为 fork 时子进程继承父进程的内存。Zygote 预加载了系统框架类与常用资源，fork 出的应用进程直接共享这些内容（写时复制），省去重复加载的时间与内存。这是 Android 启动优化的基础设计。

iOS 启动链路

1. exec() 加载 Mach-O 可执行文件；
2. dyld 加载动态库（dylib），完成符号绑定与 rebase/bind；
3. 运行 Objective-C/Swift 运行时初始化（注册类、分类、+load）；
4. 调用 main() → UIApplicationMain，建立主 RunLoop；
5. AppDelegate 回调系列方法，最终渲染首屏。

Q：冷启动、温启动、热启动的区别？
冷启动是进程完全不存在，需要完整创建；温启动是进程存在但 Activity 需重建；热启动是应用已在后台，直接切回前台。优化目标通常指冷启动。

二、内存管理：必考的核心机制

Q：Android 与 iOS 的内存管理机制有何不同？

Q：Android 内存泄漏最常见的原因？

• 静态变量持有 Activity 或 View；
• 内部类/匿名类持有外部 Activity 引用（Handler 延迟消息是最经典场景）；
• 未注销的监听器（广播、回调、EventBus）；
• 资源对象未关闭（Cursor、文件流、Bitmap 未回收）。

// 典型泄漏：Handler 隐式持有 Activity，延迟消息未处理完则 Activity 无法回收
class MyActivity : Activity() {
    private val handler = Handler(Looper.getMainLooper())
    override fun onCreate(b: Bundle?) {
        handler.postDelayed({ /* ... */ }, 60_000)
    }
}
// 修复：静态内部类 + WeakReference，并在 onDestroy 移除所有回调

Q：iOS 的循环引用怎么产生？怎么破？
对象 A 强引用 B、B 又强引用 A，引用计数永不归零。闭包捕获 self 是最常见场景。解法：用 weak / unowned 打破环（Swift 中常写 [weak self]）；delegate 一律用 weak 修饰。

三、ANR 与 OOM：线上问题排查

Q：ANR 是怎么触发的？怎么排查？
Android 中主线程在规定时间内未响应即触发 ANR：输入事件 5 秒内未处理完、BroadcastReceiver 10 秒、Service 生命周期 20 秒。

排查路径：

1. 导出 /data/anr/traces.txt，查看主线程的堆栈；
2. 看主线程是在做耗时任务（大量计算、I/O），还是阻塞在锁或 Binder 调用上；
3. 结合 CPU 使用率判断：CPU 高说明在忙，CPU 低却 ANR 说明被阻塞；
4. 线上接入 ANR 监控（WatchDog 或官方 API）采集堆栈。

Q：OOM 有哪些类型？怎么优化？

• Java 堆 OOM：对象太多或泄漏，用 Profiler 抓堆转储分析；
• 内存抖动：短时间频繁创建销毁对象，触发频繁 GC，表现为卡顿；
• 大图 OOM：图片未按显示尺寸采样（inSampleSize）、未及时回收；
• 线程 OOM：线程数超上限，每个线程都占栈内存，需用线程池收敛；
• 文件描述符耗尽：流未关闭，表现为 Too many open files。

四、卡顿排查的通用方法论

Q：线上卡顿怎么定位？ 一个通用四步法：

1. 监控采集：用 Choreographer 帧回调或 CADisplayLink 计算掉帧率，超过阈值时采样主线程堆栈；
2. 聚合归因：把大量堆栈按栈顶聚合，找出高频耗时函数（而不是看单次样本）；
3. 工具深挖：Android 用 Perfetto/System Trace，iOS 用 Instruments Time Profiler；
4. 解法归类：主线程耗时 → 异步化或延迟；布局复杂 → 扁平化；频繁创建对象 → 复用池；锁竞争 → 缩小锁粒度。

加分答法：提到”监控要有采样率控制，否则监控本身会造成卡顿”，以及”先看聚合后的 Top 问题，不要陷入单次调用栈“。这两点说明你有线上经验。

五、小结

移动端面试的启动、内存、卡顿三块，共同的答题结构是：讲清系统机制 → 指出常见成因 → 给出排查路径 → 落到具体工具与代码。

最有效的备考方式：拿自己的项目跑一遍 Profiler / Instruments，找一个真实的性能问题并解决掉。面试官问细节时，这段经历会让你的回答立刻变得可信。

参考：Android 性能官方文档、Apple 性能调优文档。版本与工具行为以官方文档为准。