generalsの学习笔记

Appearance

系统原理 / Binder / Handler / 启动流程 — 面试题篇 ​

更新: 5/15/2026 字数: 0 字 时长: 0 分钟

Q1: Binder 的原理？为什么 Android 选择 Binder？ ​

考察点：IPC 机制理解

完整回答：

Binder 是 Android 特有的 IPC 机制，基于 C/S 架构。

选择 Binder 的原因：

  1. 性能：只需一次数据拷贝。发送方通过 copy_from_user 将数据拷贝到内核缓冲区，接收方的用户空间通过 mmap 映射到同一块物理内存，直接访问。而 Socket 需要两次拷贝（发送方→内核→接收方）。
  2. 安全：Binder 驱动在内核层面记录调用方的 UID/PID，不可伪造。其他 IPC（如 Socket）的身份信息由用户空间填写，可以伪造。
  3. 易用：面向对象的调用方式，AIDL 自动生成代理代码，调用远程方法就像调用本地方法。

追问：一次拷贝是怎么实现的？

接收进程在 Binder 驱动中通过 mmap 将一块内核缓冲区映射到自己的用户空间。发送进程的数据通过 copy_from_user 拷贝到这块内核缓冲区后，接收进程可以直接在用户空间访问，不需要再 copy_to_user。

追问：AIDL 生成的 Stub 和 Proxy 分别是什么？

  • Stub（服务端）：继承 Binder，实现接口方法。onTransact 中根据方法编号反序列化参数，调用真正的实现
  • Proxy（客户端）：持有远程 Binder 引用。调用方法时将参数序列化到 Parcel，通过 transact 发送给 Binder 驱动

asInterface 方法会判断是否同进程：同进程直接返回 Stub（本地调用），跨进程返回 Proxy。

Q2: Handler 机制的原理？为什么主线程 Looper.loop() 不会 ANR？ ​

考察点：消息机制

完整回答：

Handler 机制由四部分组成：

  • Handler：发送和处理消息
  • Message：消息载体
  • MessageQueue：按时间排序的消息队列（单链表）
  • Looper：死循环从 MessageQueue 取消息并分发

流程：Handler.sendMessage → MessageQueue.enqueueMessage（按 when 插入链表）→ Looper.loop 中 queue.next() 取出消息 → Handler.dispatchMessage 处理

为什么 loop() 不会 ANR？

ANR 是指应用在规定时间内没有处理完系统事件（如触摸事件 5 秒）。Looper.loop() 的死循环恰恰是在处理这些事件——触摸事件、Activity 生命周期回调、UI 绘制都是通过 Handler 消息驱动的。

当没有消息时，MessageQueue.next() 内部调用 nativePollOnce（底层 epoll_wait）阻塞，线程休眠不消耗 CPU。有新消息时通过 eventfd 唤醒。

ANR 发生在某个消息处理时间过长，导致后续的输入事件消息无法及时处理。

追问：同步屏障是什么？

同步屏障是 target 为 null 的特殊 Message。插入后，MessageQueue.next() 会跳过所有同步消息，优先处理异步消息。ViewRootImpl 在 scheduleTraversals 时使用同步屏障，确保 UI 绘制消息优先执行。

追问：IdleHandler 是什么？

MessageQueue 空闲时（无消息或下一条消息还没到时间）执行的回调。适合做延迟初始化、GC 等不紧急的任务。返回 false 执行一次后移除，返回 true 保持。

Q3: App 的启动流程？从点击图标到 Activity 显示？ ​

考察点：系统启动流程

完整回答：

  1. Launcher 调用 startActivity，通过 Binder 发送给 AMS
  2. AMS 检查目标 Activity 的进程是否存在
  3. 进程不存在 → AMS 通过 Socket 请求 Zygote fork 新进程
  4. Zygote fork 后，新进程执行 ActivityThread.main()
  5. main() 中创建主线程 Looper 并 Looper.loop()
  6. 创建 ActivityThread 实例，通过 Binder 向 AMS 注册（attachApplication）
  7. AMS 回调 bindApplication：创建 Application → attachBaseContext → ContentProvider.onCreate → Application.onCreate
  8. AMS 回调 scheduleLaunchActivity：创建 Activity → attach → onCreate → onStart → onResume
  9. ViewRootImpl.performTraversals 执行首帧绘制
  10. 用户看到内容

追问：Zygote 为什么用 fork 而不是新建进程？

fork 是 COW（Copy-On-Write），子进程共享父进程的内存页，只在写入时才复制。Zygote 预加载了 Framework 类和资源，fork 后子进程直接共享这些内容，不需要重新加载，大幅加快启动速度。

追问：为什么 Zygote 用 Socket 而不是 Binder？

fork 时如果有多线程，子进程只会保留调用 fork 的线程，其他线程消失。如果 Zygote 使用 Binder（Binder 有线程池），fork 后 Binder 线程消失会导致死锁。所以 Zygote 使用单线程的 Socket 通信。

Q4: Activity 的启动流程？涉及哪些系统组件？ ​

考察点：Activity 启动源码

完整回答：

  1. 调用方 startActivity → Instrumentation.execStartActivity
  2. 通过 Binder 调用 AMS 的 startActivity
  3. AMS 中：
    • ActivityStarter：解析 Intent，确定启动模式
    • 查找或创建 TaskRecord（Task 栈）
    • 创建 ActivityRecord
    • 暂停当前 Activity（回调 onPause）
  4. 如果目标进程不存在，通知 Zygote fork
  5. 目标进程就绪后，AMS 通过 Binder 回调 ActivityThread
  6. ActivityThread.handleLaunchActivity：
    • 通过反射创建 Activity 实例
    • 调用 activity.attach（创建 PhoneWindow）
    • 调用 onCreate（setContentView 创建 View 树）
    • 调用 onStart、onResume
  7. WindowManager.addView → 创建 ViewRootImpl → performTraversals

追问：为什么 A.onPause 先于 B.onCreate？

AMS 的调度逻辑：先暂停当前 Activity（确保它保存状态），再启动新 Activity。这是为了保证数据安全——如果先启动 B 再暂停 A，A 可能来不及保存状态就被系统回收。

Q5: 多进程有什么问题？怎么通信？ ​

考察点：多进程架构

完整回答：

多进程的问题：

  1. 静态变量/单例失效：每个进程有独立的虚拟机和内存空间
  2. SharedPreferences 不可靠：多进程同时读写会数据丢失
  3. 文件并发访问：需要文件锁
  4. Application 多次创建：每个进程都会创建 Application

通信方式：

  1. AIDL/Binder：最常用，支持方法调用，类型安全
  2. Messenger：基于 Handler 的轻量级方案，串行处理
  3. ContentProvider：适合数据共享
  4. BroadcastReceiver：适合一对多通知
  5. Socket：灵活但开发成本高
  6. MMKV：多进程安全的键值存储

追问：什么场景需要多进程？

  • WebView 独立进程：隔离 WebView 的内存泄漏和崩溃
  • 推送服务独立进程：保活
  • 大内存操作独立进程：如图片处理、视频编辑
  • 插件化：插件运行在独立进程

Q6: Handler 怎么实现延迟消息的？postDelayed 的原理？ ​

考察点：Handler 细节

完整回答：

postDelayed(runnable, delayMillis) 内部调用 sendMessageDelayed，将 delay 转换为绝对时间 when = SystemClock.uptimeMillis() + delayMillis，然后插入 MessageQueue。

MessageQueue 是按 when 排序的单链表。next() 方法取出头部消息时，如果 now < msg.when，计算需要等待的时间，传给 nativePollOnce(timeout) 让线程休眠指定时间。

时间到后 epoll_wait 返回，取出消息执行。如果在等待期间有新消息插入且 when 更早，enqueueMessage 会调用 nativeWake 唤醒线程重新计算等待时间。

追问：postDelayed 准确吗？

不完全准确。如果主线程正在处理一个耗时消息，延迟消息即使到了时间也要等当前消息处理完。所以实际延迟 ≥ 指定延迟。对于精确定时需求，应该用 Choreographer 或 ValueAnimator。

加分点：提到 SystemClock.uptimeMillis() 不包含深度睡眠时间，而 System.currentTimeMillis() 可能被用户修改。Handler 使用 uptimeMillis 更可靠。

Q7: Binder 传输数据有大小限制吗？怎么传大数据？ ​

考察点：Binder 限制

完整回答：

Binder 传输缓冲区大小约 1MB（准确说是 1016KB），这个限制是所有正在进行的 Binder 事务共享的。超过限制会抛 TransactionTooLargeException。

常见触发场景：

  • Intent 传递大 Bundle（如大 Bitmap、大列表）
  • onSaveInstanceState 保存过多数据
  • ContentProvider 返回大量数据

传大数据的方案：

  1. 文件：写入文件，传递文件路径
  2. ContentProvider：通过 URI 访问数据
  3. ParcelFileDescriptor：传递文件描述符（Binder 只传 fd，数据通过文件系统传输）
  4. 共享内存（MemoryFile/SharedMemory）：mmap 共享内存，Binder 只传引用
  5. Socket：大量数据通过 Socket 传输

追问：为什么 Intent 传 Bitmap 容易崩溃？

Bitmap 序列化后可能很大（1920×1080×4 = 8MB），远超 Binder 1MB 限制。应该传 URI 或文件路径，接收方自己加载。

Q8: Android 的 Parcelable 和 Serializable 的区别？ ​

考察点：序列化

完整回答：

维度ParcelableSerializable
实现手动实现（或 @Parcelize）实现接口即可
性能快（直接内存操作）慢（反射 + IO 流）
内存少（无临时对象）多（创建大量临时对象）
持久化不适合（格式可能变化）适合
使用场景Android 组件间传递（Intent/Bundle）持久化存储、网络传输

Kotlin 中推荐用 @Parcelize：

kotlin
@Parcelize
data class User(val name: String, val age: Int) : Parcelable
// 编译器自动生成 writeToParcel 和 CREATOR

追问：Parcelable 为什么比 Serializable 快？

Serializable 使用 ObjectOutputStream，通过反射遍历对象的所有字段，创建大量临时对象。Parcelable 直接将数据写入 Parcel（连续内存块），无反射，无临时对象。

Q9: HandlerThread 和 IntentService 是什么？ ​

考察点：线程工具

完整回答：

HandlerThread：自带 Looper 的线程，可以在子线程中使用 Handler 处理消息：

kotlin
val handlerThread = HandlerThread("worker")
handlerThread.start()
val handler = Handler(handlerThread.looper)
handler.post { /* 在子线程执行 */ }

适用场景：需要在子线程中串行处理任务（如数据库操作、文件 IO）。

IntentService（已废弃，推荐 WorkManager）：

  • 内部使用 HandlerThread
  • 每次 startService 的 Intent 在子线程中串行处理
  • 所有 Intent 处理完后自动 stopSelf

Q10: 热修复的原理？Tinker 是怎么工作的？ ​

考察点：热修复机制

完整回答：

热修复的核心原理是利用类加载机制：

Android 的 ClassLoader 通过 DexPathList 中的 dexElements 数组查找类。查找时按数组顺序遍历，找到就返回。

Tinker 的方案：

  1. 生成补丁 dex（包含修复后的类）
  2. 将补丁 dex 插入到 dexElements 数组的最前面
  3. 下次加载类时，先找到补丁 dex 中的修复类，原始 dex 中的 bug 类不会被加载
java
// 简化原理
Field pathListField = BaseDexClassLoader.class.getDeclaredField("pathList");
Object pathList = pathListField.get(classLoader);
Field dexElementsField = pathList.getClass().getDeclaredField("dexElements");
Object[] oldElements = (Object[]) dexElementsField.get(pathList);
// 将补丁 dex 的 Element 插入到数组最前面
Object[] newElements = concat(patchElements, oldElements);
dexElementsField.set(pathList, newElements);

其他热修复方案：

  • Sophix（阿里）：类修复 + 资源修复 + so 修复，底层替换方案
  • Robust（美团）：编译时插桩，每个方法前插入 if 判断是否有补丁
  • AndFix：Native 层替换方法指针（ArtMethod），即时生效但兼容性差

实习面试补充：系统原理保底问题 ​

Binder、启动流程这些内容对实习生通常是加分项。目标是先讲清主线，不需要背完整源码调用链。

Q11: Handler、Looper、MessageQueue 分别是什么？ ​

考察点：消息机制主线

完整回答：

  • MessageQueue：消息队列，保存待处理的 Message/Runnable。
  • Looper：消息循环，不断从 MessageQueue 中取消息。
  • Handler：发送消息，并在对应线程处理消息。

主线程启动时系统已经创建了 Looper，所以可以直接使用主线程 Handler。普通子线程默认没有 Looper，如果要使用 Handler，需要手动创建消息循环。

追问：Handler 内存泄漏怎么产生？

非静态内部类 Handler 会隐式持有外部 Activity。如果消息队列中还有延迟消息，Activity 退出后仍可能被 Handler 持有，导致泄漏。可以使用静态内部类、弱引用，或在销毁时移除消息。

Q12: Binder 是用来解决什么问题的？ ​

考察点：IPC 基础

完整回答：

Binder 是 Android 主要的跨进程通信机制。不同进程有独立内存空间，不能直接调用对方对象，Binder 提供了一套让客户端像调用本地接口一样调用远程服务的机制。

常见场景包括：

  • App 调用系统服务，比如 ActivityManagerService、PackageManagerService。
  • AIDL 跨进程通信。
  • Service 的跨进程绑定。

加分点：Binder 相比传统 Socket 更适合 Android 系统服务调用，支持身份校验和对象引用语义。

Q13: App 启动大致经过哪些步骤？ ​

考察点：启动流程主线

完整回答：

冷启动大致流程：

  1. 用户点击图标，Launcher 通过 Binder 请求系统启动目标 Activity。
  2. 系统进程中的 AMS 判断目标应用进程是否存在。
  3. 如果进程不存在，通过 Zygote fork 出应用进程。
  4. 应用进程启动 ActivityThread，创建主线程 Looper。
  5. ActivityThread 创建 Application 和 Activity。
  6. 依次执行 Activity 的 onCreate、onStart、onResume，完成首帧绘制。

实习面试中能讲清这条主线即可，源码细节可以作为加分展开。