Framework on zed的博客

Android Handler 深入：同步屏障与 Choreographer 调度机制

Mon, 10 Aug 2026 00:00:00 +0800

这篇是 Handler 消息机制的进阶笔记，重点把 MessageQueue.next()、同步屏障、异步消息、IdleHandler、Printer 和 Choreographer 串成一条线。

核心结论

同步屏障本质是一条没有 target 的特殊消息。
同步屏障存在时，普通同步消息会被挡住，异步消息可以优先执行。
Choreographer 借助异步消息和 VSYNC，把输入、动画、布局绘制组织到一帧内。
IdleHandler 发生在队列空闲或下一条消息尚未到期时，适合做低优先级任务。
Printer 能观察消息分发前后，但不能覆盖消息等待阶段。

一、Handler总体流程

Looper 每执行一轮，到底如何决定“下一步做什么”？

基础 Handler 机制只解释了正常路径：

MessageQueue.next()
↓
取出 Message
↓
Handler.dispatchMessage()
↓
再次 next()

而进阶机制，本质上是在这个循环的不同位置插入特殊能力：

MessageQueue.next()
├─ 普通消息调度
├─ SyncBarrier / Async Message
├─ IdleHandler
└─ nativePollOnce()
Looper.loopOnce()
├─ Printer
├─ Observer
├─ Trace / Slow dispatch
└─ Handler.dispatchMessage()
更上层：
Choreographer
└─ 借助异步消息 + VSYNC 构建帧调度

下面我们从源码把它们串起来讲：

二、先重新看一次Looper.loopOnce()

for (;;) {
 Message msg = queue.next();

 msg.target.dispatchMessage(msg);

 msg.recycleUnchecked();
}

但实际上 AOSP 的loopOnce()在dispatchMessage()前后做了不少事情。

其中有一段：

final Printer logging = me.mLogging;

if (logging != null) {
 logging.println(
 ">>>>> Dispatching to "
 + msg.target + " "
 + msg.callback + ": "
 + msg.what
 );
}

msg.target.dispatchMessage(msg);

if (logging != null) {
 logging.println(
 "<<<<< Finished to "
 + msg.target + " "
 + msg.callback
 );
}

也就是说，一条 Message 的执行过程实际上类似：

MessageQueue.next()
↓
Printer：Dispatching
↓
Observer / Trace 等监控开始
↓
Handler.dispatchMessage()
↓
Observer / Trace 等结束
↓
Printer：Finished
↓
Message.recycle()

当前 AOSP 的Looper.setMessageLogging()明确就是在每条消息 dispatch 开始和结束时调用 Printer。

三、Printer：Looper 天然提供的消息监控点

API:

Looper.getMainLooper().setMessageLogging(printer);

例如：

Looper.getMainLooper().setMessageLogging { text ->
 Log.d("LooperMonitor", text)
}

实际上Printer只有：

void println(String x);

Looper会在消息执行前打印类似：

>>>>> Dispatching to Handler ... : 0

执行结束后：

<<<<< Finished to Handler ...

源码就是在dispatchMessage()前后进行这两次回调。

因此你可以记录时间：

Looper.getMainLooper().setMessageLogging { line ->

 if (line.startsWith(">>>>>")) {
 start = SystemClock.uptimeMillis()
 }

 if (line.startsWith("<<<<<")) {
 val cost =
 SystemClock.uptimeMillis() - start

 if (cost > 100) {
 Log.w(
 "BlockMonitor",
 "Main thread blocked ${cost}ms"
 )
 }
 }
}

这就是很多早期卡顿监控方案的基本思想：

Dispatching
↓
记录开始时间
↓
Message 执行
↓
Finished
↓
计算耗时

所以Printer并不是普通意义上的日志 API。

它实际暴露了一个非常重要的 Hook：

Looper 每条消息执行的边界。

四、Printer能检测什么，不能检测什么

假设：

handler.post {
 Thread.sleep(1000)
}

Printer 可以非常容易发现：

Dispatching
↓
1000ms
↓
Finished

所以它能检测:

单条 Looper Message 执行时间过长。

但要注意，它测量的是：

dispatchMessage 开始
↓
dispatchMessage 结束

而不是：

消息进入队列
↓
消息真正执行

所以如果：

Message B
已经在队列等待 3 秒

Printer 本身并不能直接告诉你：

B 在队列里等了 3 秒。

它更适合检测：

当前正在执行的 Message 是否太慢

而不是完整的 Message 排队延迟。

这也是为什么现代性能工作还需要 Trace、Prefetto 等更完整的调度信息。

五、IdleHandler：MessageQueue 空闲时还能做什么

Printer位于：

Looper.dispatchMessage()

附近。

IdleHandler 则完全不同。

它直接位于:

MessageQueue.next()

内部。

接口非常简单：

public interface IdleHandler {
 boolean queueIdle();
}

AOSP 注释对它的描述是：

当消息队列已经没有当前可以执行的消息、准备等待更多消息时调用。

而且即使队列中还有 Message，只要这些 Message 都是未来才执行的延迟消息，仍然可以视作 idle。

这一点很重要。

所谓：

MessageQueue idle

不是：

MessageQueue 完全为空

而是：

当前没有可以立即执行的 Message

例如：

当前时间：1000ms
MessageQueue：
A when=5000ms
B when=8000ms

虽然队列不为空，但现在没有任何 Message 能执行。

因此：

MessageQueue 扔然处于 idle 状态。

六、IdleHandler 在 next() 的哪个位置执行

简化MessageQueue.next()

for (;;) {

 nativePollOnce(...);

 synchronized (this) {

 Message msg = 找下一条消息;

 if (msg 已经到期) {
 return msg;
 }

 // 当前没有立即可执行 Message

 if (pendingIdleHandlerCount < 0
 && isIdle()) {

 pendingIdleHandlerCount =
 mIdleHandlers.size();
 }
 }

 // 执行 IdleHandler

 for (...) {

 boolean keep =
 idler.queueIdle();

 if (!keep) {
 removeIdleHandler(idler);
 }
 }

 ...
}

当前 AOSP 中仍然是这个基本流程：确认 queue idle 后复制IdleHandler列表，然后依次调用queueIdle()；返回false的 handler 会被移除。

所以：

MessageQueue.next()
↓
发现没有当前可执行 Message
↓
有没有 IdleHandler？
↓
有
↓
queueIdle()
↓
然后继续 next()
↓
最终 nativePollOnce()

七、同步屏障其实也发生在MessageQueue.next()

现在进入另一个特殊分支。

普通 Message：

msg.target != null

因为 Handler 入队时会：

msg.target = this;

但同步屏障是一个非常特殊的 Message：

msg.target == null

当前MessageQueue源码也明确要求普通enqueueMessage()的 Message 必须有target；而屏障节点则用target == null来区分。

假设队列：

Barrier
↓
Message A(sync)
↓
Message B(sync)
↓
Message C(async)

next()中有这样的核心逻辑：

if (msg != null && msg.target == null) {

 // 被 barrier 挡住

 do {
 prevMsg = msg;
 msg = msg.next;

 } while (
 msg != null
 && !msg.isAsynchronous()
 );
}

当前源码就是：

发现队首是 Barrier
↓
不断向后找
↓
直到发现 asynchronous Message

因此：

Barrier
↓
Sync A 跳过
↓
Sync B 跳过
↓
Async C 返回

八、同步屏障到底是什么作用

同步屏障之后的同步消息会暂停执行，直到调用removeBarrier()；异步消息不受barrier影响。并且barrier必须成对移除，否则消息队列可能无法恢复正常运行。

所以：

Sync Barrier

其实就是：

MessageQueue 临时改变自己的消息选择规则。

平时：

选择最早到期 Message

Barrier 存在：

选择最早到期 Async Message

一般开发者不应该，也基本不能直接调用同步屏障的添加/移除接口。postSyncBarrier()和removeSyncBarrier()虽然在源码里是 public 的，但同时也标记了@hide，属于隐藏 API。因此这套机制主要是给Framework 自己使用的调度能力，典型就是 View 绘制链路。

例如ViewRootImpl.scheduleTraversals()的经典设计就是：

UI 请求 layout / draw
↓
ViewRootImpl.scheduleTraversals()
↓
postSyncBarrier()
↓
普通同步 Message 暂时被挡住
↓
Choreographer 的异步帧消息可以穿过去
↓
VSYNC
↓
doFrame()
↓
Traversal
↓
doTraversal()
↓
removeSyncBarrier(token)

所以你可以把 SyncBarrier 看成：

Framework为了控制主线程消息调度顺序而保留的一种“内部交通管制能力”。

而不是开发者通用的：

“提高我的 Message优先级"工具。

不过开发者可以合法使用和它相关的另一半机制：异步 Handler。

Android 提供公开 API：

val handler = Handler.createAsync(Looper.getMainLooper())

这种 Handler 发出的消息会被标记为异步消息，因此如果队列里存在同步屏障，它们不会被屏障阻塞。

九、Choreographer 和 Handler连接起来的地方

Choreographer 源码开头直接说明了自己的职责：

协调 animation、input、drawing 的时间
接收来自显示系统的 timing pulse，例如 VSYNC
然后安排下一帧工作

而且每个Looper 线程可以拥有自己的 Choreographer，回调最终运行在那个 Choreographer 所绑定的 Looper 线程。

注意 Choreographer 内部字段：

private final Looper mLooper;
private final FrameHandler mHandler;

private final FrameDisplayEventReceiver
 mDisplayEventReceiver;

private final CallbackQueue[]
 mCallbackQueues;

构造：

mLooper = looper;
mHandler = new FrameHandler(looper);

mDisplayEventReceiver =
 new FrameDisplayEventReceiver(
 looper,
 vsyncSource,
 layerHandle
 );

也就是说：

Choreographer
├─ Looper
├─ Handler
├─ DisplayEventReceiver
└─ 自己的 CallbackQueue

这里一个非常重要的结论出现了：

Choreographer 自己还有一套 CallbackQueue，但它最终仍依托 Looper/Handler 驱动。

十、Choreographer 为什么还需要自己的CallbackQueue

Handler的MessageQueue管：

整个线程的所有 Message

Choreographer 自己则需要进一步区分：

INPUT
ANIMATION
INSETS_ANIMATION
TRAVERSAL
COMMIT

当前源码定义的 callback 顺序就是：

CALLBACK_INPUT = 0
CALLBACK_ANIMATION = 1
CALLBACK_INSETS_ANIMATION = 2
CALLBACK_TRAVERSAL = 3
CALLBACK_COMMIT = 4

其中源码注释明确指出 Traversal 负责 layout 和 draw。

所以可以理解成两级调度：

一级调度
MessageQueue
负责线程所有任务
↓
二级调度
Choreographer.CallbackQueue
负责一帧内部的不同阶段

这跟我们前面说的：

target → Handler
what → Handler 内部分类

其实是类似的设计思想：

不同层级分别负责自己的任务分类和调度。

十一、一次Choreographer回调是怎么样开始的

比如：

postCalback(
 CALLBACK_TRAVERSAL,
 runnable,
 token
);

内部：

final long now =
 SystemClock.uptimeMillis();

final long dueTime =
 now + delayMillis;

mCallbackQueues[callbackType]
 .addCallbackLocked(
 dueTime,
 action,
 token
 );

然后：

if (dueTime <= now) {
 scheduleFrameLocked(now);
}

否则：

Message msg =
 mHandler.obtainMessage(
 MSG_DO_SCHEDULE_CALLBACK,
 action
 );

msg.arg1 = callbackType;

msg.setAsynchronous(true);

mHandler.sendMessageAtTime(
 msg,
 dueTime
);

注意这里非常关键的一行：

msg.setAsynchronous(true);

当前 Choreographer 源码确实将这类调度 Message 标记为异步。

现在 Handler 与 Choreographer 就真正连起来了。

十二、VSYNC 到底怎么进入Java世界

Choreographer里面还有：

FrameDisplayEventReceiver
 extends DisplayEventReceiver

当显示系统产生 VSYNC 时，会进入：

FrameDisplayEventReceiver.onVsync();

然后源码会创建一个 Message：

Message msg =
 Message.obtain(
 mHandler,
 this
 );

msg.setAsynchronous(true);

mHandler.sendMessageAtTime(
 msg,
 timestamp
);

之后 Runnable：

@Override
public void run() {
 mHavePendingVsync = false;

 doFrame(
 mTimestampNanos,
 mFrame,
 mLastVsyncEventData
 );
}

当前 Choreographer 的FrameDisplayEventReceiver就是这样把 VSYNC 转换成异步 Message，再最终调用doFrame()。

因此完整链：

Display subsystem
↓
VSYNC
↓
DisplayEventReceiver
↓
FrameDisplayEventReceiver
↓
创建 Async Message
↓
Main MessageQueue
↓
MainLooper
↓
FrameDisplayEventReceiver.run()
↓
Choreographer.doFrame()

这一步非常重要。

Choreographer 并不是：

一个独立线程不停轮询 VSYNC

而是：

VSYNC 最终被转换成 Looper 可以处理的任务，并在 Choreographer 所绑定线程上执行

十三、doFrame() 才是一帧真正执行的地方

进入：

Choreographer.doFrame()

后，源码最终按照顺序调用：

doCallbacks(CALLBACK_INPUT);

doCallbacks(CALLBACK_ANIMATION);

doCallbacks(
 CALLBACK_INSETS_ANIMATION
);

doCallbacks(CALLBACK_TRAVERSAL);

doCallbacks(CALLBACK_COMMIT);

于是整个主线程的结构变得很有意思：

Looper
│
└─ 一次 doFrame Message
↓
Choreographer
↓
INPUT
↓
ANIMATION
↓
TRAVERSAL
↓
COMMIT

也就是说：

对 Looper 来说，一帧可能只是它正在 dispatch 的一个任务；但这个任务内部，Choreographer 又实现了一套完整的帧阶段调度。

十四、那ViewRootImpl 又是怎么进来的

ViewRootImpl的：

scheduleTraversals()

会安排：

TraversalRunnable

进入：

Choreographer.CALLBACK_TRAVERSAL

最后在：

Choreographer.doFrame()

执行：

doCallbacks(
 CALLBACK_TRAVERSAL
);

Traversal 的语义在当前 Choreographer 源码里就明确负责 layout 和 draw。

随后 ViewRootImpl 的：

TraversalRunnable.run()
↓
doTraversal()
↓
performTraversals()

进一步进入 View 树的：

messasure
layout
draw

所以：

Handler

一路往上最终可以连接到：

View 绘制

MessageQueue 解决的是整个主线程下一事情执行什么

Choreographer 解决的是既然现在要处理这一帧，那么这一帧内部各类任务以什么顺序执行

Android Handler 消息机制：Looper、MessageQueue 与 Handler

Sun, 02 Aug 2026 00:00:00 +0800

序言

在 Android 开发中，我们经常会写出这样的代码：

val mainHandler = Handler(Looper.getMainLooper())

Thread {
 val result = loadData()

 mainHandler.post {
 textView.text = result
 }
}.start()

这段代码看起来非常普通：子线程完成耗时任务，然后通过Handler回到主线程更新 UI。

但在面试中，面试官真正关心的通常不是你会不会调用post()，而是下面这些问题：

Handler为什么可以完成线程切换？
Runnable最终保存在哪里？
MessageQueue是所有线程共享的吗？
Looper.loop()是无限循环，为什么不会占满 CPU？
延迟消息是怎样实现的？
一个线程可以有几个 Looper？
为什么同一个 Looper 可以对应多个 Handler？
Handler.postDelayed()为什么不一定准时？
Java 层的消息队列为什么还需要 native 层的poll?

核心结论

Handler 不会真正“切换线程”，它只是把任务投递到目标 Looper 的 MessageQueue。
一个线程最多一个 Looper，一个 Looper 持有一个 MessageQueue，但可以对应多个 Handler。
MessageQueue 是按执行时间排序的队列，不是简单 FIFO。
Looper.loop() 不会占满 CPU，关键在于 MessageQueue.next() 里的 native poll 阻塞等待。
延迟消息不保证准时，只保证不早于目标时间执行。

一、Handler 并没有真正"切换线程"

先从一个最容易产生误解的说法开始：

Handler 可以把代码切换到主线程。

这句话在日常交流中没有问题，但从底层原理来看并不准确。

Handler 本身不会创建线程，也不会暂停当前线程并把执行线程迁移到另一个线程。它真正做的事情是：

将一个任务放入目标线程的消息队列，等待目标线程主动取出并执行。

以前面的代码为例：

mainHandler.post {
 textView.text = result
}

调用 post()的是工作线程，但执行 Lambda 的是主线程。

整个过程可以拆分成两个阶段：

工作线程：
Handler.post()
↓
将任务封装成 Message
↓
插入主线程 MessageQueue
主线程：
Looper 从 MessageQueue 取出 Message
↓
Handler 分发 Message
↓
执行 Runnable.run()

因此，Handler 消息机制本质上是一个典型的生产者-消费者模型：

调用post()或sendMessage()的线程是生产者；
MessageQueue 是任务缓冲区；
Looper 所在线程是唯一的消费者。

Android 官方文档也明确指出：Handler 会把 Message 和 Runnable 交给其绑定 Looper 的 MessageQueue，并最终在该 Looper 所在的线程执行。

理解这一点后，“线程切换”的本质就变得清晰了：

不是当前代码被转移到了其他线程，而是当前线程提交了一个新任务，由另一个线程在未来执行。

二、Thread、Looper、MessageQueue 和 Handler到底是什么关系

Android消息机制中最重要的四个角色以及它们之间的关系是：

一个 Thread 最多拥有一个 Looper
一个 Looper 固定拥有一个 MessageQueue
一个 Looper 可以绑定多个 Handler
一个 Handler 只绑定一个 Looper

画成对象关系大致如下：

MainThread
│
└── MainLooper
│
├── MessageQueue
│
├── Handler A
├── Handler B
└── Handler C

需要注意，Handler 并不是 Looper 的子对象。更准确地说，是多个 Handler 保存了同一个 Looper 和 MessageQueue 的引用。

MessageQueue是所有线程共享的吗

不同Looper拥有不同的MessageQueue：

主线程
└── MainLooper
└── MainMessageQueue
工作线程 A
└── Looper A
└── MessageQueue A
工作线程 B
└── Looper B
└── MessageQueue B

但是，一个 MessageQueue 可以被多个线程并发访问。

例如主线程的 MessageQueue：

网络线程 ──────┐
Binder 线程 ───┤
工作线程 ──────┼── enqueue ──→ 主线程 MessageQueue
主线程自身 ────┘ │
│ next
▼
主线程

所以应当区分两个概念：

归属关系：一个 MessageQueue 只属于一个 Looper；
访问关系：多个线程可以向同一个 MessageQueue 投递消息。

它是一种典型的：

多生产者、单消费者队列。

消息入队可能发生在任意线程，而消息出队和执行只发生在 Looper 所属线程。

三、Looper.prepare()：为当前线程创建消息环境

普通 Java 线程创建后，并不会自动拥有消息循环。

下面这个线程执行完代码后就会退出：

Thread {
 println("执行任务")
}.start()

如果希望它像 Android 主线程一样长期存活、持续接收任务，就需要为它创建 Looper：

Looper.prepare();
Looper.loop();

其中，prepare()负责初始化，loop()负责启动循环。

3.1 ThreadLocal如何保证一个线程一个Looper

Looper 中最关键的静态字段之一是：

static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<>();

ThreadLocal可以理解为一个以线程为作用域的变量。

虽然所有线程访问的是同一个sThreadLocal对象，但每个线程看到的值不同：

主线程读取 sThreadLocal → MainLooper
线程 A 读取 sThreadLocal → Looper A
线程 B 读取 sThreadLocal → Looper B
普通线程读取 sThreadLocal → null

Looper.prepare()的核心逻辑可以简化为：

private static void prepare(boolean quitAllowed) {
 if (sThreadLocal.get != null) {
 throw new RuntimeException(
 "Only one Looper may be created per thread"
 );
 }
 sThreadLocal.set(new Looper(quitAllowed));
}

这里完成了两件事：

检查当前线程是否已经存在 Looper；
创建一个 Looper，并保存到当前线程的 ThreadLocal 中。

因此：

Looper.myLooper()

本质上就是：

sThreadLocal.get()

它获取的是调用该方法的当前线程所绑定的 Looper。

3.2 为什么一个线程只能有一个Looper

因为线程只有一条执行流，而Looper.loop()是一个持续运行的循环。

假设一个线程允许创建两个 Looper：

looperA.loop();
looperB.loop();

第一个loop()不退出，第二个就永远得不到执行机会。

因此，一个线程设置多个独立消息循环既没有实际意义，也会造成消息队列归属混乱。Android 直接在prepare()阶段禁止这种情况。

3.3 Looper创建时也会创建MessageQueue

Looper的构造逻辑可以简化为：

private Looper(boolean quitAllowed) {
 mQueue = new MessageQueue(quitAllowed);
 mThread = Thread.currentThread();
}

所以真正的初始化链路是：

线程调用 Looper.prepare()
↓
创建 Looper
↓
创建 MessageQueue
↓
记录 Thread.currentThread()
↓
将 Looper 保存到 ThreadLocal

这也解释了为什么 Looper 和 MessageQueue 是一一对应关系。

四、Handler创建时到底绑定了什么

现在来看：

val handler = Handler(Looper.getMainLooper())

Handler 构造函数的核心逻辑可以简化为：

public Handler(
 Looper looper,
 Callback callback,
 boolean async
) {
 mLooper = looper;
 mQueue = looper.mQueue;
 mCallback = callback;
 mAsynchronous = async;
}

Handler 会保存两个关键引用：

mLooper → 目标 Looper
mQueue → 目标 Looper 对应的 MessageQueue

所以所谓的：

Handler 绑定主线程。

准确含义是：

Handler
↓
MainLooper
↓
MainThread

Handler 自己并不决定代码在哪个线程执行，真正决定执行线程的是它所绑定的 Looper。

五、消息发送：从 sendMessage 到 enqueueMessage

假设调用：

handler.sendMessage(message);

它依次经过：

sendMessage()
 ↓
sendMessageDelayed(message, 0)
 ↓
sendMessageAtTime(message, uptimeMillis)
 ↓
enqueueMessage(queue, message, uptimeMillis)

延迟发送的逻辑大致为：

public final boolean sendMessageDelayed(
 Message msg,
 long delayMills
) {
 if (delayMills < 0) {
 delayMills = 0
 }

 return sendMessageAtTime(
 msg,
 SystemClock.uptimeMills() + delayMills
 );
}

需要注意的是，MessageQueue 保存的不是“延迟多少毫秒”，而是一个绝对执行时间：

when = 当前 uptimeMills + delayMills

例如：

当前 uptimeMillis = 10,000
delayMillis = 2,000
message.when = 12,000

这条消息的含义是：

当系统运行时间达到 12,000ms 后，该消息具备执行资格。

Handler 使用的时间基准是 SystemClock.uptimeMillis()。设备进入深度休眠时，该时钟不会继续增长，因此深度休眠可能造成延迟任务比预期更晚执行。

六、message.target: Looper 怎么知道该交给哪个 Handler

消息真正入队前，会经过 Handler 的 enqueueMessage() :

private boolean enqueueMessage(
 MessageQueue queue,
 Message msg,
 long uptimeMills
) {
 msg.target = this;

 if (mAsynchronous) {
 msg.setAsynchronous(true);
 }

 return queue.enqueueMessage(msg, uptimeMillis);
}

其中最关键的一句是：

msg.target = this;

这里的this 就是当前的 Handler。

为什么Message必须保存 target？

因为同一个 MessageQueue 中可能存在多个 Handler 发送的消息：

MessageQueue
├── Message A → Handler A
├── Message B → Handler B
├── Message C → Handler A
└── Message D → Handler C

Looper 只负责从队列里中取消息，它不知道每条消息对应什么业务逻辑。

所以 Message 需要自己携带接收方：

Message.target → 负责处理该消息的 Handler

随后 Looper 只需要调用：

msg.target.dispatchMessage(msg);

就能将消息交回正确的 Handler。

七、MessageQueue 不是简单的先进先出队列

很多人看到MessageQueue，回自然认为它是普通的 FIFO 队列。

实际上，它更接近一个按照执行时间排序的单链表。

Message 中有两个重要字段：

long when;
Message next;

队列结构可以理解为：

mMessages
↓
Message A
when = 100
next ─────→ Message B
when = 300
next ─────→ Message C
when = 800

队头始终是最早应该执行的消息。

假设当前队列是：

A(100) → B(300) → C(800)

现在插入一条：

D(500)

MessageQueue会从队头开始遍历，找到正确位置：

A(100) → B(300) → D(500) → C(800)

因此，消息的执行顺序首先取决于 when，而不是单纯取决于发送顺序。

例如：

handler.postDelayed(taskA, 3000)
handler.postDelayed(taskB, 1000)
handler.post(taskC)

理论上的队列顺序是：

taskC → taskB → taskA

即使 taskA 最先发送，它依然最后执行。

为什么入队需要同步

MessageQueue 可能被多个线程同时写入：

线程 A 正在插入消息 A
线程 B 同时插入消息 B
Looper 线程可能正在读取队头

如果没有同步保护，可能出现：

next 指针被覆盖；
链表结构断裂；
消息丢失；
消息顺序错误；
同一条消息被重复处理。

因此经典 MessageQueue实现会在操作链表时使用同步保护：

synchronized (this) {
 // 检查退出状态
 // 设置 message.when
 // 按执行时间插入链表
 // 判断是否需要唤醒 Looper
}

这里也再次证明：MessageQueue 虽然只被一个 Looper 线程消费，却可能被多个发送线程并发写入。

八、为什么插入消息后有时要唤醒 Looper

假设主线程当前没有立即执行的任务，队头消息需要 10 秒后执行。

于是主线程进入等待：

Message A：10 秒后执行
Looper：准备休眠 10 秒

这时工作线程插入一条立即执行的消息：

Message B：立即执行

队列变成：

Message B → Message A

如果只是修改链表，却不唤醒 Looper，那么 Looper 仍可能继续休眠10 秒，导致 B 无法及时执行。

因此，当新消息改变了队列下一次应该唤醒的时间时，需要调用 native 层的唤醒机制。

可以概括为：

新消息成为新的有效队头
+
Looper 当前正在阻塞
↓
唤醒 Looper

但并不是每次入队都需要唤醒。

假设Looper原本会在 100ms 后醒来，新插入的消息要 5 秒后执行：

原队头：100ms 后执行
新消息：5000ms 后执行

新消息并没有改变下一次唤醒时间，所以没有必要额外唤醒线程。

这是一种重要的性能优化：

只有新消息会影响当前等待状态时，才进行 native wake

九、Looper.loop(): 消息循环真正开始

Looper.prepare() 只是创建环境，真正开始处理消息的是：

Looper.loop();

其核心逻辑可以压缩为：

public static void loop() {
 Looper me = myLooper();

 if (me == null) {
 throw new RuntimeException(
 "No Looper; Looper.prepare() wasn't called"
 );
 }

 for (;;) {
 if (!loopOnce(me)) {
 return;
 }
 }
}

单次循环的核心又可以简化为：

private static boolean loopOnce(Looper me) {
 Message msg = me.mQueue.next();

 if (msg == null) {
 return false;
 }

 msg.target.dispatchMessage(msg);
 msg.recycleUnchecked();

 return true;
}

忽略日志、Trace、慢消息检测和 Observer 等工程代码，Looper 每轮只做三件事：

从 MessageQueue 获取下一条消息
↓
交给 message.target 分发
↓
回收 Message

这里真正复杂的部分不在Looper.loop(), 而在：

MessageQueue.next();

因为next() 必须回答一个问题：

当前是否存在可以立即执行的消息？如果没有，线程应该等待多久？

十、MessageQueue.next()：为什么无限循环不占满CPU

MessageQueue.next()的经典逻辑可以简化为：

Message next() {
 int nextPollTimeoutMills = 0;

 for(;;) {
 nativePollOnce(
 mPtr,
 nextPollTimeoutMills
 );

 synchronized(this) {
 long now =
 SystemClock.uptimeMillis();

 Message msg = mMessage;

 if (msg != null) {
 if (now < msg.when) {
 nextPollTimeoutMillis =
 (int) Math.min(
 msg.when - now,
 Integer.MAX_VALUE
 );
 } else {
 mMessages = msg.next;
 msg.next = null;
 return msg;
 }
 } else {
 nextPollTimeoutMillis = -1;
 }

 if (mQuiting) {
 return null;
 }
 }
 }
}

虽然源码细节会随 Android 版本演进，但基本判断可以分为三种情况。

情况一：队头消息已经到期

假设：

now = 1000
msg.when = 800

此时满足：

now >= msg.when

MessageQueue 会:

从链表摘除队头
清除 msg.next
返回该 Message

Looper 随后执行：

msg.target.dispatchMessage(msg);

情况二：队头消息尚未到期

假设：

now = 1000
msg.when = 1500

还需要等待：

1500 - 1000 = 500ms

于是下一轮 native poll 最多阻塞约 500ms：

nativePollOnce(mPtr, 500);

如果期间没有新事件，线程会在超时后自动醒来。

如果期间插入了一条更早的消息，其他线程会唤醒 Looper，让它重新计算等待时间。

情况三：队列为空

如果队列中完全没有消息:

nextPollTimeoutMillis = -1;

通常表示无限等待，直到：

有新消息入队；
native 文件描述符事件到达；
队列退出；
其他唤醒事件发生。

无限循环为什么不会占满CPU

Looper.loop() 确实是一个无限循环：

for(;;) {
 messageQueue.next();
}

但无限循环不等于忙循环。

忙循环是：

while (true) {
 // 不断执行，没有阻塞点
}

这种循环会持续消耗 CPU。

Looper 的循环则是：

while (true) {
 val messsage = blockingNext()
}

当没有可执行消息时，线程会在 native poll 中阻塞休眠，因此不会持续占用 CPU。

所以真正应该记住的是：

是否耗 CPU，不取决于有没有无限循环，而取决于循环内部有没有阻塞等待机制。

十一、为什么 Android 使用 nativePollOnce，而不是Object.wait

纯 Java 消息循环完全可以使用：

synchronized (queue) {
 queue.wait(timeout);
}

但 Android 主线程等待的不只是 Java 层的 Handler 消息。

它还需要统一处理：

输入事件；
native 层回调；
文件描述符事件；
UI 系统事件；
某些系统服务通信；
Handler 消息。

因此 Android 在 native 层使用 Looper 和 poll/epoll 类机制统一等待多种事件。

Java 层主要暴露两个关键入口：

nativePollOnce(mPtr, timeoutMillis);
nativeWake(mPtr);

可以近似理解为：

MessageQueue.next()
↓
nativePollOnce()
↓
Native Looper
↓
poll / epoll 等待
↓
消息到达、FD 可读、超时或被唤醒
↓
返回 Java 层继续处理

这说明 Android 的主线程 Looper 并不只是一个普通 Java 阻塞队列。

它本质上是应用进程中的一个完整事件循环，同时协调 Java 消息和 native 事件。

十二、dispatchMessage(): 最终执行 Runnable 还是handleMessage

Looper取出消息后，会调用：

msg.target.dispatchMessage(msg);

Handler 的分发逻辑可以简化为：

public void dispatchMessage(Message msg) {
 if (msg.callback != null) {
 handleCallback(msg);
 } else {
 if (mCallback != null
 && mCallback.handleMessage(msg)) {
 return;
 }

 handleMessage(msg);
 }
}

它的优先级是：

1. Message.callback
2. Handler.Callback
3. Handler.handleMessage()

第一优先级：Message.callback

来源通常是：

handler.post {
 updateUi()
}

因为 Runnable 被保存到了：

message.callback

所以最终执行：

message.callback.run();

第二优先级：Handler.Callback

创建 Handler 时可以传入 Callback：

val handler = Handler(
 Looper.getMainLooper()
) { message ->
 true
}

Callback 返回 true 表示消息已被消费，不再继续调用 handleMessage()。

返回 false 则继续向下分发。

第三优先级：handleMessage()

传统用法是继承 Handler：

val handler = object :
 Handler(Looper.getMainLooper()) {

 override fun handleMessage(msg: Message) {
 when (msg.what) {
 1 -> handleResult(msg.obj)
 }
 }
}

只有 Message 没有 callback，并且 Handler.Callback 没有消费时，才会进入 handleMessage()。

因此面试中可以这样回答：

Handler.post() 和 sendMessage() 最终都会生成 Message。post 的 Runnable 保存在 Message.callback 中，sendMessage 通常依赖 what、obj 等字段。Looper 取出 Message 后调用 Handler.dispatchMessage，优先执行 Message.callback，其次 Handler.Callback，最后才是 handleMessage。

十三、重新理解“Handler 为什么能切换线程”

现在把整条链路连起来。

假设工作线程调用：

mainHandler.post {
 updateUi()
}

实际过程是：

工作线程执行 Handler.post()
↓
创建 Message
↓
Runnable 保存到 Message.callback
↓
Message.target 指向 mainHandler
↓
工作线程把 Message 插入主线程 MessageQueue
↓
必要时唤醒主线程
↓
主线程 Looper 从 MessageQueue 取出 Message
↓
主线程调用 mainHandler.dispatchMessage()
↓
主线程调用 Runnable.run()

因此代码最终在哪个线程执行，取决于：

哪个线程正在运行目标 Looper.loop()

不是取决于：

哪个线程调用 Handler.post()

可以把它总结为一句面试回答：

Handler 不负责真正的线程切换。发送线程只负责把 Message 放入 Handler 所绑定的 Looper 的 MessageQueue，目标 Looper 所在线程负责从队列取出并执行，所以任务最终运行在目标 Looper 的线程中。

十四、postDelayed 为什么不保证准时

假设：

handler.postDelayed(taskB, 1000)

很多人会把它理解为：

taskB 一定会在 1000ms 后执行。

实际上它只能保证：

taskB 不会早于指定时间进入可执行状态。

假设主线程正在执行一个耗时 5 秒的任务：

0ms：
主线程开始执行任务 A
1000ms：
任务 B 已经到期
5000ms：
任务 A 执行结束
5000ms 之后：
Looper 才有机会取出任务 B

虽然 B 在 1000ms 时已经到期，但 Looper 所在线程当时正在执行 A，无法同时处理另一条消息。

因此 Handler 的延迟调度不是实际调度。

影响实际执行时间的因素包括：

前面消息的执行耗时；
队列中更早消息的数量；
线程调度；
设备深度休眠；
同步屏障等特殊机制。

所以面试中应当回答：

postDelayed() 只保证消息最早执行时间，不保证精确执行时间。消息到期后仍需等待 Looper 完成当前任务，并处理排在它前面的消息。

十五、主线程为什么会卡顿

Android 主线程只有一个Looper，同一时间只能处理一条消息。

执行过程天然串行:

Message A 开始
Message A 结束
Message B 开始
Message B 结束
Message C 开始

如果 Message A 执行时间过长：

Message A 耗时 3 秒
↓
后续输入事件无法及时处理
↓
绘制任务无法及时执行
↓
生命周期回调继续排队
↓
出现掉帧、卡顿，严重时触发 ANR

所以“不能在主线程执行耗时任务”并不是一句抽象规范。

它直接来自 Looper 的单线程串行消费模型:

当消息不执行结束，Looper 就无法调用下一次 MessageQueue.next()

十六、Message 为什么需要对象池

Looper 完成消息分发后，会执行类似：

msg.recycleUnchecked();

Message是 Android 中非常高频的对象：

Handler通信；
UI 绘制；
输入事件；
生命周期；
动画；
系统组件回调；

如果每次发生消息都创建新对象，会增加对象分配和垃圾回收压力。

因此 Android 为 Message 维护了一个静态对象池：

Message.obtain()
↓
优先从对象池取出旧 Message
消息执行结束
↓
清除字段
↓
放回对象池

这也是为什么推荐：

Message.obtain()

或者：

handler.obtainMessage()

而不是频繁直接：

new Message()

消息入队后还会被标记为正在使用，避免同一个 Message 被重复发送或者重复插入队列。

对象池并不是 Handler 机制成立的基础，而是一项针对高频消息分配的性能优化。

十七、Handler 消息机制的线程安全边界

Handler 经常用于跨线程传递数据：

val result = calculateResult();

mainHandler.post {
 showResult(result)
}

消息入队和出队过程具有必要的同步机制，因此发送之前完成的状态可以安全发布给处理线程。

但是，这并不意味着 Message 中携带的所有对象都会变成线程安全对象。

例如：

val list = mutableListOf<String>()

handler.post {
 println(list)
}

list.add("new item")

这里传递的是同一个可变对象引用。

消息发送后，其他线程仍然修改list ，就可能产生竞态或不可预测结果。

更安全的做法是发送不可改变快照：

val snapshot = list.toList()

handler.post {
 println(snapshot)
}

所以应当区分：

消息队列本身是线程安全的；
消息中引用的业务对象不一定线程安全。

十八、面试高频问题总结

1. 一个线程可以有几个Looper

最多一个。

Looper 通过 ThreadLocal 与线程绑定，prepare() 会检查当前线程是否存在 Looper。

2. 一个Looper可以对应一个Handler

可以对应多个。

多个Handler可以绑定同一个 Looper，并向同一个 MessageQueue 发送消息。Message 通过target区分最终交给哪个 Handler。

3. MessageQueue是所有线程共享的吗

不是全局共享。

一个Looper对应一个MessageQueue，但多个线程可以并发向该MessageQueue投递消息，只有Looper所在线程负责消费。

4. Handler 如何完成线程切换

发送线程把Message 放进目标 Looper 的 MessageQueue，目标线程的Looper取出并执行。Handler 本身不创建线程，也不迁移执行栈。

5、Looper.loop() 为什么不会占满CPU

因为MessageQueue.next() 在没有可执行消息时会通过 native poll 阻塞线程。它是阻塞循环，不是忙循环。

6、Handler.post() 和 sendMessage() 有什么区别

两者最终都会发送 Message。

post() 将 Runnable 保存在 Message.callback；sendMessage() 通常使用 what、arg1、arg2 和 obj。

7. postDelayed 为什么不一定准时

延迟消息只决定消息最早可执行时间。Looper 当前任务耗时、前序消息拥堵、线程调度和深度休眠都会造成进一步延迟。

8. 为什么 MessageQueue 要按照时间排序

因为它同时支持立即消息和延迟消息。按when排序后，队头始终是最早应执行消息，Looper 才能正确计算下一次阻塞时间。

9. 为什么Message需要target

同一个 MessageQueue 中可能存在多个 Handler 的消息。Looper 通过 message.target.dispatchMessage(message) 将消息交回正确的 Handler。

10. 主线程为什么不能执行耗时任务

主线程 Looper 串行处理消息。当前消息不结束，后续输入、绘制和生命周期消息都无法执行，从而产生卡顿甚至 ANR。

十九、用一段伪代码概括整个机制

最后，可以把一条 Handler.post() 调用压缩成下面这段伪代码：

// 工作线程执行

Message msg = Message.obtain();
msg.callback = runnable;
msg.target = mainHandler;
msg.when = SystemClock.uptimeMillis();

mainMessageQueue.enqueueMessage(msg);

// 必要时唤醒主线程
nativeWake();

主线程则一直运行：

while (true) {
 Message msg = mainMessageQueue.next();

 if (msg == null) {
 return;
 }

 msg.target.dispatchMessage(msg);
 msg.recycleUnchecked();
}

而 Handler 分发消息：

void dispatchMessage(Message msg) {
 if (msg.callback != null) {
 msg.callback.run();
 } else if (
 callback != null
 && callback.handleMessage(msg)
 ) {
 return;
 } else {
 handleMessage(msg);
 }
}

至此，完整链路形成闭环：

Handler 决定消息投递到哪个 Looper
 ↓
Message 保存执行时间、任务和目标 Handler
 ↓
MessageQueue 按时间保存和调度消息
 ↓
Looper 阻塞等待并不断取出消息
 ↓
Handler 在 Looper 所在线程完成消息分发
 ↓
Thread 真正执行 Runnable 或 handleMessage

结语

Handler、Looper 和 MessageQueue 并不是三个孤立的类，而是一套完整的线程事件循环系统。

理解这套机制后，很多 Android 问题都会得到统一解释：

Handler 为什么能跨线程提交任务；
主线程为什么必须保持消息循环；
为什么主线程不能执行耗时任务；
为什么延迟任务可能晚执行；
HandlerThread 为什么能串行处理后台任务；
Dispatchers.Main 为什么最终仍要回到主线程事件循环；
Choreographer、VSYNC 和 UI 绘制为什么都离不开主线程消息队列。

真正值得记住的不是某几行源码，而是下面这套模型：

发送线程只负责入队
目标线程负责出队与执行

一个线程最多一个 Looper
一个 Looper 对应一个 MessageQueue
一个 Looper 可以绑定多个 Handler

MessageQueue 多线程生产
Looper 线程单线程消费

当能够从 Handler.post() 一直讲到 MessageQueue.next()、nativePollOnce() 和 dispatchMessage() 时，Handler 消息机制就不再是一组需要背诵的面试题，而是一套可以自然推导的底层模型。

Android App 启动流程：Launcher、AMS、Zygote 与 ActivityThread

Mon, 09 Feb 2026 10:10:12 +0800

从点击图标到页面显示

App 冷启动可以拆成三个关键角色：Launcher 发起请求，System Server 中的 AMS 负责调度，Zygote 负责 fork 新进程。

核心结论

Launcher 不能直接创建目标 App 进程，它通过 Binder 请求 AMS 启动 Activity。
AMS 如果发现目标进程不存在，会通过 Socket 请求 Zygote fork 新进程。
Zygote 使用 fork 和 Copy-on-Write 复用预加载类与资源。
新进程入口是 ActivityThread.main()，这里会启动主线程 Looper。
AMS 通过 IApplicationThread 通知新进程绑定 Application 并启动 Activity。

第一阶段：请求与孵化（The Request & The Fork）

Launcher 自己不能创建目标 App 进程，它必须把启动请求交给 AMS。

1. Launcher -> AMS (Binder 通信)

动作：当你点击桌面图标，Launcher 进程调用startActivity。
底层： Launcher(Client)通过 Binder 告诉 AMS（Server）：“我要启动某某 App 的 MainActivity”。
知识点：这里发生了一次 Binder IPC。

2. AMS的决策

AMS 检查这个 App 的进程是否已经存在。
如果存在（热启动）：直接通过 Binder 通知该进程onResume,速度很快。
如果不存在（冷启动）：AMS 必须创建一个新进程。

3. AMS -> Zygote（Socket通信 – 高频）

动作：AMS 发现需要新进程，它不是自己去创建，而是通知 Zygote 进程。
底层：AMS 通过LocalSocket发送请求给 Zygote。
必须知道：为什么这里不用 Binder 而用 Socket？
- 死锁风险：Zygote 的主要工作是fork()。在 Linux 中，fork()只会拷贝当前线程，而不会拷贝其他线程。如果 Zygote 使用 Binder（它是多线程的），且fork()时某个 Binder 锁被其他线程持有，新进程里这个锁就永远处于被锁住的状态（不会被释放？因为持有线程的锁没有被拷贝过来），导致新进程一启动就死锁。
- Socket 优势：Socket 是单线程、顺序执行的，对于fork这种敏感操作更安全。

4. Zygote -> 新进程（Fork）

动作：Zygote 收到请求，执行fork()系统调用，复制自身，生成一个新的 App 进程。
底层：利用**Copy-on-Write(写时复制)**技术。新进程共享 Zygote 的资源库（系统类、资源），只有当新进程需要修改数据时，才会真正拷贝物理内存。这就是 Android 应用启动快，省内存的秘诀。

第二阶段：初始化与绑定（Init & Attach）

新进程刚出生时是一张白纸，它不知道自己是谁，也不知道要干嘛。

5. 新进程启动（ActivityThread.main）

动作：新进程开始执行入口函数ActivityThread.main()。
底层：这里会初始化我们熟悉的Looper.prepareMainLooper() 和 Looper.loop() – 主线程的消息循环从此开始运转。

6. 新进程 – AMS（Binder 通信）

动作：新进程（现在它是 Client）通过 Binder 告诉 AMS（Server）：“大佬，我启动好了，请把 Application 信息发给我。”
方法名： attachApplication。
知识点：这是新进程主动发起的第一次 Binder 调用。

第三阶段：生命周期回调（LifeCycle）

AMS 确认“人”到了，开始派活。

7. AMS -> 新进程（Binder通信）

动作： AMS 通过 Binder 接口（IApplicationThread）发回指令。
指令 1：bindApplication – 触发Application.onCreate()。
指令 2：scheduleLaunchActivity – 触发 Activity.onCreate()。

8. 主线程处理（Handler）

动作: 新进程的 Binder 线程池收到 AMS 指令后，通过Handler把消息抛给主线程(H类)。
执行：主线程 Looper 收到消息后，执行handleBindApplication和handleLaunchActivity。
结果：在屏幕上终于显示出了界面。

核心图谱：Android 进程启动三部曲

我们要搞清楚三个角色的出场顺序：Init 进程 -> Zygote进程 -> System Server 进程。

第一阶段：Init 进程（PID = 1）

角色： Linux 系统的第一个用户级进程，所有进程的老祖宗。
动作：
1. 电源键按下，Bootloader 引导 kernel 启动。
2. Kernel 启动完毕后，查找并执行/init文件。
3. Init 进程读取init.rc配置文件。
4. 关键指令：在配置文件里写着一行service zygote ...，Init 也就是在这里把 Zygote启动了起来。

第二阶段：Zygote 进程

角色：Android Java 世界的孵化器。所有的 App 进程（包括 System Server）都是它的子孙。
动作（ZygoteInit.main）:
1. 启动虚拟机（ART/Dalvik）：这是 Java 代码运行的基础。
2. 预加载资源（Preload）：（面试必考）Zygote 会把常用的系统类（String, Activity等）和资源（drawable, styles）加载到自己的内存里。
  - 为什么要这样做？因为后面 fork 出的新进程会继承这些内存（Copy-on-Write）。大家共享这些资源，既省内存，启动又快。
3. 启动 System Server：Zygote 会 fork 出 System Server 进程。
4. 建立 Socket 服务端: 任务完成，Zygote 建立一个LocalSocket服务端，进入死循环，等待 System Server 发号施令。

第三阶段：System Server 进程

角色： Android 系统的“CEO”。它虽然是 Zygote 生成的，但它掌管着 Zygote 的接单权。
动作（SystemServer.main）:
1. 启动 Binder 线程池：（关键差异） Zygote 为了防死锁不用 Binder，但 System Server 是大管家，必须处理海量并发请求，所以它第一件事就是初始化 Binder。
2. 启动系统服务：它一口气启动了 80+ 个服务，包括我们熟悉的：
  - AMS (Activity Manager Service) : 统管四大组件。
  - WMS（Window Manager Service）：统管窗口。
  - PMS （Package Manager Service）：统管安装包。
3. 进入 Looper 循环：这里的 Looper 就在等着处理各种 Binder 也就是 App 发来的请求了。

夺命连环问

1. 为什么System Server 要被Zygote Fork出来，而不是有Init直接启动？

这个问题考察对**Copy-on-Write(COW)**的理解。

回答要点：
- 资源共享：System Server 本质上也是一个 Java 进程，它也需要运行环境和系统类。
- 继承红利：如果 Init 直接启动，System Server 就得自己重新加载一遍虚拟机和资源，既慢有浪费内存。让 Zygote fork 它，它就能直接继承 Zygote 预加载好的所有资源（类、图片、各种 drawable），落地即满级。

2. Zygote 和System Server是怎么配合工作的？

这个问题考察你对 IPC 架构的理解。

回答要点：
- 父子关系：Zygote fork 了 System Server。
- C/S 关系（Socket）：
  - System Server（里的 AMS）充当 Client。
  - Zygote 充当 Socket Server。
  - 当 AMS 需要启动新 App 时，它通过 Socket 发消息给 Zygote：“给我 fork 个新进程”。
- C/S 关系（Binder）：
  - App 启动后（Client），会通过 Binder 找 AMS 注册自己。

3. 如果System Server挂了（Crash）会发生什么？

这个问题考察你对 Android 系统稳定性的认知

回答要点：
- 手机重启（Soft Reboot）。
- Zygote 会监听他的子进程。如果 System Server 挂了，Zygote 会"自杀"（因为大管家没了，系统没法运行了）。
- Init 进程发现 Zygote 挂了，会重启 Zygote。
- Zygote 重启后，又会再次启动 System Server。
- 这就是为什么有时候手机卡死黑屏后，会显示开机动画重新进入系统。

4. 为什么zygote不直接当System Server呢

一句话就是 各司其职。具体来说，是因为 内存洁癖、生死隔离、并发死锁 和 权限安全这四大硬性约束。

我们来逐一拆解：

1. 内存洁癖：Zygote必须是"纯净的母体"

这是最核心的原因。

Zygote的角色：它是一个模板(Template) 。他的内存里应该只包含所有 App 公用的、只读的基础资源（比如String类、View类、drawable资源）。
System Server 的角色：它是一个管理员。它的内存里塞满了 动态的、脏的运行时数据（比如当前运行了哪些 App、窗口的位置、电池电量、用户的锁屏密码等）。

如果 Zygote 直接当 System Server：Zygote 的内存里就会包含上述的脏数据。当 Zygote fork 一个新的 App（比如微信）时，根据Copy-on-Write机制，微信会继承 Zygote 的所有内存数据。

后果：微信一启动，内存里就莫名其妙多了"当前所有 App 的列表"、“电池电量记录”等它根本不需要、甚至不该知道的数据。这不仅浪费内存，还可能导致数据泄露。

所以：Zygote 必须保持“纯洁”和“静态”，只包含通用的代码和资源。一旦 fork 出 System Server，System Server 就可以尽情地在自己的进程里搞脏自己的内存，而不会影响后续孵化出来的 App。

2. 生死隔离： Zygote不能死

Zygote 的使命：它是 Android 世界的女娲。只要它活着，App 挂了可以重开，System Server 挂了可以重启。
System Server 的风险：它运行着 80+ 个系统服务，逻辑极其复杂，代码量巨大，还要处理各种第三方 App 的奇怪请求。它崩溃的概率远高于 Zygote。

如果 Zygote 直接当 System Server：一旦 AMS 或 WMS 因为某个 Bug 崩溃了，整个 Zygote 进程就会挂掉。

后果： Android 系统彻底死透了。因为孵化器没了，没人能重建系统，也没人能孵化新 App，只能等待 Linux 内核（Init 进程）重启手机。

现在的架构：System Server 挂了 -> Zygote 还在 -> Zygote 监听到子进程死亡 -> Zygote 重启 System Server -> 手机"软重启"（Soft reboot，只闪一下开机动画，不用重新引导内核）。

3. 并发死锁：Binder与Fork的天生互斥

我们在前面提到过，Zygote 为什么用 Socket 而不用 Binder?因为 Binder 是多线程的，而fork()在多线程环境下即易死锁。

System Server: 必须高度依赖 Binder（它是系统的大管家，要处理成千上万的并发请求）。所以 System Server 里有密密麻麻的 Binder 线程池。
Zygote ：必须保持单线程（或者极简的线程模型）、才能安全地执行fork()。

如果 Zygote 直接当 System Server：它既要运行 Binder 线程池来处理系统服务，又要执行fork()来孵化 App。

后果：当 zygote 正在处理一个 Binder 请求（锁住了某个资源）时，突然来了一个孵化请求执行fork()。新生成的 App 进程里，那个"锁"是被锁住的，但持有锁的线程没被拷贝过来 – 死锁发生了，新 App 永远卡死在启动界面。

4. 权限安全：Root vs System

Zygote: 必须拥有 Root 权限。因为它要操作底层资源，要setuid(给新 App 分配独立的用户 ID)，这都是特权操作。
System Server: 只需要 System 权限（uid=1000）。它虽然权力大，但不能拥有 Root 权限，以防被黑客利用攻破整个系统内核。

现在的架构：Zygote(Root) -> fork() -> 新进程 -> 降权（Drop Permission） -> 变成了 System Server （System User）或者 App（App User）。这样最安全，权限最小化。

5. 为什么Binder 被锁阻塞的线程拷贝过来就永远是锁住的呢？

简单的答案是：因为fork()只有复制当前执行fork()的那个线程，而不会复制其他线程。但是，它却复制了所有线程持有锁的状态。

假设 Zygote 进程里有两个线程：

线程 A（Binder 线程）：正在准备处理一个系统请求，它拿了一把锁（Mutex），准备写日志。
线程 B（主线程）：准备执行fork()来孵化新进程（比如启动微信）。

第一步：Zygote正常运行

线程 A 运行到一半，执行了lock.acquire()（加锁）。
此时，锁（Mutex）的状态在内存里变成了"Locked"。
线程 A 还没来的及释放锁，CPU 时间片到了，切到了线程 B。

第二步：执行Fork

线程 B 执行 fork
关键点：Linux 的 fork（）规定，只复制调用 fork 的那个线程（也就是线程 B）。
后果：新生成的进程（微信进程）里，只有线程 B 的克隆体，没有线程 A

第三步：遗产继承（灾难开始）

虽然线程 A 没过来，但是 Zygote 进程里的所有内存数据都被复制过来了（通过 Copy-on-Write）。
重点：那把锁（Mutex）是内存里的一个对象。在 Zygote 里，它是"Locked"状态，所以，在新进程里，这把锁也依然是 Locked 状态。

第四步：新进程启动

新进程（微信）开始初始化。
微信的初始化代码里，也需要写日志（或者使用 Binder）。
微信的主线程尝试执行lock.accquire()。

第五步：死锁（DeadLock）

微信的主线程发现：咦？这把锁已经被锁住了
于是微信主线程挂起，等待锁被释放
但是！真正持有这把锁的人 – Zygote 里的线程 A – 根本没有被拷贝到微信进程里来
结局：微信进程流永远没有任何人能去执行lock.release()。这把锁成了“幽灵锁”，微信进程一出生就卡死在初始化阶段，永远等待一个不存在的线程来解锁。

什么是Copy-on-Write

这是操作系统偷懒的内存管理策略。

简单一句话总结：只有在真正修改数据时，才去复制一份；如果只是读取，那就大家共用一份。

1. 核心原理：能不复制，就不复制

为了彻底理解，我们还是用 Zygote 和新 App 的例子。

假设 Zygote 进程内存里有一张 100MB 的资源地图（里面有 String 类，Drawable 图片，系统主题等）。

第一阶段：Fork发生时（假装复制）

当 Zygote 执行fork()孵化新App 时：

操作系统不做的事：它不会傻乎乎的把这 100MB 物理内存 Copy 一份给新 App。那太慢了
操作系统做的事：他只是把 Zygote 的“页表”（Page Table，也就是内存地址映射关系）复制了一份给新 App。
结果： Zygote 和新 App 的虚拟地址虽然是独立的，但它们指向的物理内存是完全同一块。
标记：操作系统会把这块共享的内存区域标记为只读（Read-Only）。

第二阶段：大家只读不写（和平共处）

只要新 App 和 Zygote 都只是读取这些数据（比如读取一个 String，或者加载一张系统图标），它们就一直共用这块物理内存。
收益：内存占用极低，因为没有产生新的副本。

第三阶段：有人要搞事了（触发写时复制）

动作：突然，新 App 想要修改某个变量（比如把一个静态变量sConfig ="default" 改为custom）。
冲突：也就是写操作。
异常：因为这块内存被标记为“只读”，CPU 会立即抛出一个** 缺页异常（Page Fault）**,告诉操作系统有人想要只读数据
处理：操作系统介入。它会说：好吧，既然你要改，那这页数据就不能共享了。 1. 操作系统把 **这一页（通常是 4KB）**数据复制一份，生成一个新的物理内存页。 1. 把新 App 的页表指向这个新的物理页 1. 把新页的权限改为可读写。
结果：现在，新 App 可以随意修改这份新的数据了，而 Zygote 手里的那份依然是旧的。它们从此在这一页数据上分道扬镳。

Android 四大组件：Activity、Service、BroadcastReceiver 与 ContentProvider

Tue, 21 Oct 2025 00:05:46 +0800

四大组件是 Android 应用与系统交互的基础。它们不是四个孤立 API，而是系统调度应用入口、后台任务、跨进程通信和数据共享的核心抽象。

核心结论

Activity 负责用户可见界面和任务栈。
Service 负责无界面任务，但现代 Android 对后台服务限制越来越严格。
BroadcastReceiver 适合接收系统或应用广播，不适合长时间工作。
ContentProvider 主要解决跨进程结构化数据访问。
组件使用时要同时考虑生命周期、进程、权限和系统限制。

Activity

生命周期

┌──────────────┐
│ Activity │
│ Created │
└──────────────┘
↓
onCreate() ← 创建，初始化变量、加载布局
↓
onStart() ← 可见但不可交互
↓
onResume() ← 可见且可交互（前台）
↓
[运行中]
↓
onPause() ← 部分可见（被遮挡，如对话框）
↓
onStop() ← 完全不可见（切到后台）
↓
onDestroy() ← 销毁，释放资源
↓
[结束]

状态保存与恢复

为什么需要保存状态？

用户正在填写表单
↓
突然来电话 → Activity 被销毁
↓
电话结束返回 → Activity 重新创建
↓
表单内容丢失了！❌

保存状态

class FormActivity : AppCompatActivity() {
 private var userName: String = ""
 private var age: Int = 0

 // 保存状态（系统杀死 Activity 前调用）
 override fun onSaveInstanceState(outState: Bundle) {
 super.onSaveInstanceState(outState)

 outState.putString("userName", userName)
 outState.putInt("age", age)

 Log.d("State", "状态已保存")
 }

 // 恢复状态
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContentView(R.layout.activity_form)

 // 方式 1: 在 onCreate 中恢复
 if (savedInstanceState != null) {
 userName = savedInstanceState.getString("userName", "")
 age = savedInstanceState.getInt("age", 0)
 Log.d("State", "状态已恢复: $userName, $age")
 }
 }

 // 方式 2: 在 onRestoreInstanceState 中恢复
 override fun onRestoreInstanceState(savedInstanceState: Bundle) {
 super.onRestoreInstanceState(savedInstanceState)

 userName = savedInstanceState.getString("userName", "")
 age = savedInstanceState.getInt("age", 0)
 }
}

启动模式

4种启动模式

<!-- AndroidManifest.xml -->
<activity
 android:name=".MainActivity"
 android:launchMode="standard" />

1. standard

每次启动都创建新实例
MainActivity → MainActivity → MainActivity
↑ ↑ ↑
实例 1 实例 2 实例 3
返回栈: [实例3, 实例2, 实例1]

2. singleTop

如果在栈顶，复用；否则创建新实例
场景 1: MainActivity 在栈顶
MainActivity (栈顶) → 启动 MainActivity
↓
调用 onNewIntent() 复用，不创建新实例
场景 2: MainActivity 不在栈顶
MainActivity → DetailActivity → 启动 MainActivity
↓
创建新实例: [MainActivity(新), DetailActivity, MainActivity(旧)]

用途：通知栏点击、搜索结果页

class SearchActivity : AppCompatActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 handleIntent(intent)
 }

 // singleTop 模式下，再次启动时调用
 override fun onNewIntent(intent: Intent) {
 super.onNewIntent(intent)
 setIntent(intent) // 更新 intent
 handleIntent(intent)
 }

 private fun handleIntent(intent: Intent) {
 val query = intent.getStringExtra("query")
 // 搜索...
 }
}

3. singleTask

整个任务栈中只有一个实例
场景 1: 不存在
TaskA: [DetailActivity, MainActivity]
启动 ProfileActivity (singleTask)
↓
TaskA: [ProfileActivity, DetailActivity, MainActivity]
场景 2: 已存在
TaskA: [DetailActivity, ProfileActivity, MainActivity]
启动 ProfileActivity
↓
清除其上所有 Activity，ProfileActivity 移到栈顶
TaskA: [ProfileActivity, MainActivity]
DetailActivity 被销毁！

用途：主页、登录页

4. singleInstance

独占一个任务栈，整个系统中只有一个实例
TaskA: [DetailActivity, MainActivity]
启动 VideoActivity (singleInstance)
↓
TaskA: [DetailActivity, MainActivity]
TaskB: [VideoActivity] ← 独立的任务栈
从 VideoActivity 启动其他 Activity
↓
TaskA: [OtherActivity, DetailActivity, MainActivity]
TaskB: [VideoActivity] ← 仍然独占

用途：视频通话、闹钟

Intent Flags

// FLAG_ACTIVITY_NEW_TASK: 新任务栈
val intent = Intent(this, MainActivity::class.java)
intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK
startActivity(intent)

// FLAG_ACTIVITY_CLEAR_TOP: 清除其上所有 Activity
// 常用于"返回主页"
val intent = Intent(this, MainActivity::class.java)
intent.flags = Intent.FLAG_ACTIVITY_CLEAR_TOP
startActivity(intent)

// FLAG_ACTIVITY_SINGLE_TOP: 等同于 singleTop 模式
intent.flags = Intent.FLAG_ACTIVITY_SINGLE_TOP

// 组合使用（清除栈并启动）
intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK

Service

什么是Service？

Service = 在后台执行长时间运行操作的组件，没有用户界面

前台 Activity: 用户正在浏览商品
后台 Service: 同时下载文件、播放音乐、同步数据

Service的三种类型

1. 前台服务（Foreground Service）

必须显示通知，用户可见

┌─────────────────┐
│ 🔔 通知栏 │
│ 正在播放音乐... │ ← 前台服务的通知
├─────────────────┤
│ 应用界面 │
└─────────────────┘

用途：音乐播放、导航、文件下载

2. 后台服务（Background Service）

用户不可见，但会被系统限制；Android 8.0+严格限制后台服务

用途：数据同步，日志上传（但推荐用WorkManager）

3. 绑定服务（Bound Service）

与组件绑定，提供客户端-服务器接口

Activity ←───绑定───→ Service
↓ ↓
调用方法 提供方法

用途：进程间通信（IPC）、音乐播放器控制

Service生命周期

启动服务（Started Service）

startService()
↓
onCreate() ← 首次创建时调用（只调用一次）
↓
onStartCommand() ← 每次 startService() 都调用
↓
[运行中]
↓
onDestroy() ← 服务销毁

绑定服务（Bound Service）

bindService()
↓
onCreate() ← 首次创建时调用
↓
onBind() ← 返回 IBinder 对象
↓
[绑定中]
↓
unbindService()
↓
onUnbind() ← 所有客户端解绑后调用
↓
onDestroy()

混合模式（既启动又绑定）

startService() + bindService()
↓
onCreate()
↓
onStartCommand() + onBind()
↓
[运行并绑定]
↓
unbindService() ← 解绑后仍然运行
↓
stopService() or stopSelf()
↓
onDestroy()

启动服务（Started Service）

基本实现

// MyService.kt
class MyService : Service() {

 private val TAG = "MyService"

 // 1. 创建时调用（只调用一次）
 override fun onCreate() {
 super.onCreate()
 Log.d(TAG, "Service 创建")
 }

 // 2. 每次 startService() 都调用
 override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
 Log.d(TAG, "Service 启动")

 // 获取传递的数据
 val data = intent?.getStringExtra("data")

 // 执行后台任务
 doWork()

 // 返回值决定系统杀死服务后的行为
 return START_STICKY
 }

 // 3. 销毁时调用
 override fun onDestroy() {
 super.onDestroy()
 Log.d(TAG, "Service 销毁")
 }

 // 必须实现，但启动服务不需要绑定
 override fun onBind(intent: Intent?): IBinder? = null

 private fun doWork() {
 // ⚠️ 不要在主线程做耗时操作
 Thread {
 // 执行后台任务
 Thread.sleep(5000)
 Log.d(TAG, "任务完成")
 stopSelf() // 任务完成后停止服务
 }.start()
 }
}

启动和停止服务

// MainActivity.kt
class MainActivity : AppCompatActivity() {

 // 启动服务
 fun startMyService() {
 val intent = Intent(this, MyService::class.java)
 intent.putExtra("data", "Hello Service")

 // Android 8.0+ 如果是前台服务，使用 startForegroundService
 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
 startForegroundService(intent)
 } else {
 startService(intent)
 }
 }

 // 停止服务
 fun stopMyService() {
 val intent = Intent(this, MyService::class.java)
 stopService(intent)
 }
}

onStartCommand返回值

override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {

 return when {
 // START_STICKY: 系统杀死后重启服务，但 intent 为 null
 // 适用：音乐播放器
 true -> START_STICKY

 // START_NOT_STICKY: 系统杀死后不重启
 // 适用：一次性任务
 false -> START_NOT_STICKY

 // START_REDELIVER_INTENT: 系统杀死后重启，重新传递 intent
 // 适用：需要保证任务完成（如下载）
 else -> START_REDELIVER_INTENT
 }
}

前台服务

Android 8.0+严格限制后台服务：

应用进入后台几分钟后，系统会停止后台服务
前台服务不会被限制，但必须显示通知

实现前台服务

class MusicService : Service() {

 private val CHANNEL_ID = "music_channel"
 private val NOTIFICATION_ID = 1

 override fun onCreate() {
 super.onCreate()
 createNotificationChannel()
 }

 override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
 // 创建通知
 val notification = createNotification()

 // ⚠️ 必须在 5 秒内调用 startForeground，否则 ANR
 startForeground(NOTIFICATION_ID, notification)

 // 播放音乐...
 playMusic()

 return START_STICKY
 }

 private fun createNotificationChannel() {
 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
 val channel = NotificationChannel(
 CHANNEL_ID,
 "音乐播放",
 NotificationManager.IMPORTANCE_LOW
 ).apply {
 description = "音乐播放服务"
 }

 val manager = getSystemService(NotificationManager::class.java)
 manager.createNotificationChannel(channel)
 }
 }

 private fun createNotification(): Notification {
 // 点击通知打开 Activity
 val intent = Intent(this, MainActivity::class.java)
 val pendingIntent = PendingIntent.getActivity(
 this,
 0,
 intent,
 PendingIntent.FLAG_IMMUTABLE
 )

 return NotificationCompat.Builder(this, CHANNEL_ID)
 .setContentTitle("正在播放")
 .setContentText("歌曲名称 - 艺术家")
 .setSmallIcon(R.drawable.ic_music)
 .setContentIntent(pendingIntent)
 .setOngoing(true) // 不可滑动删除
 .addAction(R.drawable.ic_pause, "暂停", createPauseIntent())
 .addAction(R.drawable.ic_next, "下一首", createNextIntent())
 .build()
 }

 private fun createPauseIntent(): PendingIntent {
 val intent = Intent(this, MusicService::class.java).apply {
 action = "ACTION_PAUSE"
 }
 return PendingIntent.getService(
 this,
 0,
 intent,
 PendingIntent.FLAG_IMMUTABLE
 )
 }

 private fun createNextIntent(): PendingIntent {
 val intent = Intent(this, MusicService::class.java).apply {
 action = "ACTION_NEXT"
 }
 return PendingIntent.getService(
 this,
 0,
 intent,
 PendingIntent.FLAG_IMMUTABLE
 )
 }

 private fun playMusic() {
 // 播放逻辑...
 }

 override fun onBind(intent: Intent?): IBinder? = null
}

前台服务类型（Android 14+）

<!-- AndroidManifest.xml -->
<manifest>
 <!-- 声明前台服务类型 -->
 <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
 <uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK" />

 <application>
 <service
 android:name=".MusicService"
 android:foregroundServiceType="mediaPlayback" />
 </application>
</manifest>

前台服务类型

camera - 相机
connectedDevice - 连接设备
dataSync - 数据同步
location - 位置
mediaPlayback - 媒体播放
mediaProjection - 屏幕录制
microphone - 麦克风
phoneCall - 电话
remoteMessaging - 远程消息
shortService - 短时服务
specialUse - 特殊用途

绑定服务

使用场景

Activity 需要：
- 调用 Service 的方法
- 获取 Service 的数据
- 监听 Service 的状态
Example: 音乐播放器控制
Activity: 播放/暂停/切歌
Service: 执行实际操作

实现绑定服务

// MusicPlayerService.kt
class MusicPlayerService : Service() {

 // 1. 定义 Binder（本地服务）
 inner class MusicBinder : Binder() {
 fun getService(): MusicPlayerService = this@MusicPlayerService
 }

 private val binder = MusicBinder()

 // 2. 返回 Binder
 override fun onBind(intent: Intent?): IBinder = binder

 // 3. 提供公共方法供客户端调用
 fun play() {
 Log.d("Music", "播放音乐")
 }

 fun pause() {
 Log.d("Music", "暂停音乐")
 }

 fun getCurrentPosition(): Int {
 return 0 // 返回当前播放位置
 }
}

绑定服务

// MainActivity.kt
class MainActivity : AppCompatActivity() {

 private var musicService: MusicPlayerService? = null
 private var isBound = false

 // 1. 定义 ServiceConnection
 private val connection = object : ServiceConnection {
 override fun onServiceConnected(name: ComponentName?, service: IBinder?) {
 // 服务连接成功
 val binder = service as MusicPlayerService.MusicBinder
 musicService = binder.getService()
 isBound = true

 Log.d("Bind", "服务已连接")
 }

 override fun onServiceDisconnected(name: ComponentName?) {
 // 服务意外断开（如崩溃）
 musicService = null
 isBound = false

 Log.d("Bind", "服务已断开")
 }
 }

 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContentView(R.layout.activity_main)

 // 2. 绑定服务
 val intent = Intent(this, MusicPlayerService::class.java)
 bindService(intent, connection, Context.BIND_AUTO_CREATE)
 }

 // 3. 调用服务方法
 fun onPlayClick() {
 if (isBound) {
 musicService?.play()
 }
 }

 fun onPauseClick() {
 if (isBound) {
 musicService?.pause()
 }
 }

 override fun onDestroy() {
 super.onDestroy()
 // 4. 解绑服务
 if (isBound) {
 unbindService(connection)
 isBound = false
 }
 }
}

AIDL(跨进程通信)

用于不同应用之间的通信

// IMusicService.aidl
package com.example.myapp;
interface IMusicService {
void play();
void pause();
int getCurrentPosition();
}

// MusicPlayerService.kt
class MusicPlayerService : Service() {

 // 实现 AIDL 接口
 private val binder = object : IMusicService.Stub() {
 override fun play() {
 // 播放逻辑
 }

 override fun pause() {
 // 暂停逻辑
 }

 override fun getCurrentPosition(): Int {
 return 0
 }
 }

 override fun onBind(intent: Intent?): IBinder = binder
}

// 客户端 Activity
class MainActivity : AppCompatActivity() {

 private var musicService: IMusicService? = null

 private val connection = object : ServiceConnection {
 override fun onServiceConnected(name: ComponentName?, service: IBinder?) {
 musicService = IMusicService.Stub.asInterface(service)
 }

 override fun onServiceDisconnected(name: ComponentName?) {
 musicService = null
 }
 }

 fun onPlayClick() {
 musicService?.play()
 }
}

Service的限制（Android 8.0+）

后台执行限制

应用进入后台几分钟后：
- stopService() 后台服务被停止
- WorkManager 继续执行（推荐）

解决方案

1. 使用前台服务

// 音乐播放、导航、下载
startForegroundService(intent)
service.startForeground(NOTIFICATION_ID, notification)

2. 使用workManger

// 数据同步、日志上传
val workRequest = OneTimeWorkRequestBuilder<MyWorker>().build()
WorkManager.getInstance(context).enqueue(workRequest)

BroadcastReceiver

BroadcastReceiver = 接收系统或应用发出的广播消息

发送者 (Sender) 接收者 (Receiver)
↓ ↓
发送广播 → [Android System] → BroadcastReceiver
(Intent) (onReceive)

广播的类型

1. 系统广播（System Broadcast）

系统发出的广播

// 常见系统广播
Intent.ACTION_BOOT_COMPLETED // 开机完成
Intent.ACTION_BATTERY_LOW // 电量低
Intent.ACTION_POWER_CONNECTED // 充电器连接
Intent.ACTION_SCREEN_ON // 屏幕开启
Intent.ACTION_SCREEN_OFF // 屏幕关闭
Intent.ACTION_TIMEZONE_CHANGED // 时区改变
Intent.ACTION_LOCALE_CHANGED // 语言改变

应用内广播（Local Broadcast）

只在应用内传递，更安全

// 使用 LocalBroadcastManager（已废弃）
// 推荐使用 LiveData 或事件总线

3. 自定义广播（Custom Broadcast）

应用自己定义的广播

const val ACTION_CUSTOM = "com.example.ACTION_CUSTOM"

注册广播接收器

方式1: 静态注册（Manifest）

应用未运行时也能接收广播

<!-- AndroidManifest.xml -->
<manifest>
 <!-- 需要的权限 -->
 <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

 <application>
 <!-- 注册接收器 -->
 <receiver
 android:name=".BootReceiver"
 android:enabled="true"
 android:exported="false">

 <!-- 声明要接收的广播 -->
 <intent-filter>
 <action android:name="android.intent.action.BOOT_COMPLETED" />
 </intent-filter>
 </receiver>
 </application>
</manifest>

// BootReceiver.kt
class BootReceiver : BroadcastReceiver() {
 override fun onReceive(context: Context, intent: Intent) {
 when (intent.action) {
 Intent.ACTION_BOOT_COMPLETED -> {
 Log.d("Boot", "设备启动完成")
 // 启动服务或执行初始化
 }
 }
 }
}

**Android 8.0+**限制：

大部分系统广播不能静态注册
只有少数例外（如BOOT_COMPLETED、LOCALE_CHANGED）

方式2:动态注册

应用运行时注册，更灵活

class MainActivity : AppCompatActivity() {

 // 1. 创建接收器
 private val batteryReceiver = object : BroadcastReceiver() {
 override fun onReceive(context: Context, intent: Intent) {
 when (intent.action) {
 Intent.ACTION_BATTERY_LOW -> {
 Toast.makeText(context, "电量低", Toast.LENGTH_SHORT).show()
 }
 Intent.ACTION_BATTERY_OKAY -> {
 Toast.makeText(context, "电量恢复", Toast.LENGTH_SHORT).show()
 }
 }
 }
 }

 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContentView(R.layout.activity_main)

 // 2. 注册接收器
 val filter = IntentFilter().apply {
 addAction(Intent.ACTION_BATTERY_LOW)
 addAction(Intent.ACTION_BATTERY_OKAY)
 }
 registerReceiver(batteryReceiver, filter)
 }

 override fun onDestroy() {
 super.onDestroy()
 // 3. 必须取消注册，避免内存泄漏
 unregisterReceiver(batteryReceiver)
 }
}

**Android13+**动态注册

// Android 13+ 需要在运行时请求权限
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
 registerReceiver(
 receiver,
 filter,
 Context.RECEIVER_NOT_EXPORTED // 或 RECEIVER_EXPORTED
 )
} else {
 registerReceiver(receiver, filter)
}

发送广播

1. 标准广播（Normal Broadcast）

所有接收器几乎同时收到

// 发送广播
val intent = Intent("com.example.ACTION_CUSTOM")
intent.putExtra("data", "Hello Broadcast")
sendBroadcast(intent)

// 接收广播
class MyReceiver : BroadcastReceiver() {
 override fun onReceive(context: Context, intent: Intent) {
 val data = intent.getStringExtra("data")
 Log.d("Receiver", "收到: $data")
 }
}

2. 有序广播（Ordered Broadcast）

按优先级一次传递，可拦截

// 发送有序广播
val intent = Intent("com.example.ACTION_ORDERED")
sendOrderedBroadcast(intent, null)

<!-- 设置优先级 -->
<receiver android:name=".HighPriorityReceiver">
 <intent-filter android:priority="1000">
 <action android:name="com.example.ACTION_ORDERED" />

ContentProvider

ContentProvider = 跨应用共享数据的标准接口

应用 A (数据提供者) 应用 B (数据使用者)
↓ ↓
ContentProvider ←─────URI────→ ContentResolver
↓
数据库/文件/网络

ContentProvider的作用

1. 跨应用数据共享

联系人应用 → ContentProvider → 其他应用读取联系人
相册应用 → ContentProvider → 其他应用读取图片

2. 统一数据访问接口

不管数据存在哪里（数据库/文件/网络）
都通过统一的 URI 访问
content://com.example.provider/users/1
content://com.android.contacts/contacts/1

3. 数据安全控制

可以控制：
- 哪些应用可以访问
- 哪些数据可以访问（读/写权限）
- 数据访问的粒度

ContentProvider架构

URI结构

content://authority/path/id
↑ ↑ ↑ ↑
协议 标识符 路径 ID
示例：
content://com.example.provider/users
content://com.example.provider/users/123
content://com.android.contacts/contacts
content://media/external/images/media

组件关系

应用 A 应用 B
↓ ↓
ContentProvider ContentResolver
↓ ↓
query() query()
insert() insert()
update() update()
delete() delete()
↓
实际数据存储 (SQLite/文件等)

创建ContentProvider

步骤1:定义数据模型

// Contract 类（定义 URI 和列名）
object UserContract {
 const val AUTHORITY = "com.example.provider"
 val CONTENT_URI: Uri = Uri.parse("content://$AUTHORITY/users")

 object Columns {
 const val ID = "_id"
 const val NAME = "name"
 const val EMAIL = "email"
 const val AGE = "age"
 }
}

步骤2：创建数据库Helper(可选)

class DatabaseHelper(context: Context) : SQLiteOpenHelper(
 context,
 "users.db",
 null,
 1
) {
 override fun onCreate(db: SQLiteDatabase) {
 db.execSQL("""
 CREATE TABLE users (
 _id INTEGER PRIMARY KEY AUTOINCREMENT,
 name TEXT NOT NULL,
 email TEXT,
 age INTEGER
 )
 """)
 }

 override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) {
 db.execSQL("DROP TABLE IF EXISTS users")
 onCreate(db)
 }
}

实现ContentProvider

class UserProvider : ContentProvider() {

 private lateinit var dbHelper: DatabaseHelper
 private val uriMatcher = UriMatcher(UriMatcher.NO_MATCH).apply {
 addURI(UserContract.AUTHORITY, "users", USERS)
 addURI(UserContract.AUTHORITY, "users/#", USER_ID)
 }

 companion object {
 private const val USERS = 1
 private const val USER_ID = 2
 }

 // 1. 初始化（在应用启动时调用）
 override fun onCreate(): Boolean {
 dbHelper = DatabaseHelper(context!!)
 return true
 }

 // 2. 查询数据
 override fun query(
 uri: Uri,
 projection: Array<String>?,
 selection: String?,
 selectionArgs: Array<String>?,
 sortOrder: String?
 ): Cursor? {
 val db = dbHelper.readableDatabase

 return when (uriMatcher.match(uri)) {
 USERS -> {
 // 查询所有用户
 db.query(
 "users",
 projection,
 selection,
 selectionArgs,
 null,
 null,
 sortOrder
 )
 }
 USER_ID -> {
 // 查询指定 ID 的用户
 val id = uri.lastPathSegment
 db.query(
 "users",
 projection,
 "${UserContract.Columns.ID} = ?",
 arrayOf(id),
 null,
 null,
 sortOrder
 )
 }
 else -> throw IllegalArgumentException("Unknown URI: $uri")
 }
 }

 // 3. 插入数据
 override fun insert(uri: Uri, values: ContentValues?): Uri? {
 val db = dbHelper.writableDatabase

 return when (uriMatcher.match(uri)) {
 USERS -> {
 val id = db.insert("users", null, values)
 if (id > 0) {
 val newUri = ContentUris.withAppendedId(UserContract.CONTENT_URI, id)
 // 通知数据变化
 context?.contentResolver?.notifyChange(newUri, null)
 newUri
 } else {
 null
 }
 }
 else -> throw IllegalArgumentException("Unknown URI: $uri")
 }
 }

 // 4. 更新数据
 override fun update(
 uri: Uri,
 values: ContentValues?,
 selection: String?,
 selectionArgs: Array<String>?
 ): Int {
 val db = dbHelper.writableDatabase

 val count = when (uriMatcher.match(uri)) {
 USERS -> {
 db.update("users", values, selection, selectionArgs)
 }
 USER_ID -> {
 val id = uri.lastPathSegment
 db.update(
 "users",
 values,
 "${UserContract.Columns.ID} = ?",
 arrayOf(id)
 )
 }
 else -> throw IllegalArgumentException("Unknown URI: $uri")
 }

 if (count > 0) {
 context?.contentResolver?.notifyChange(uri, null)
 }

 return count
 }

 // 5. 删除数据
 override fun delete(
 uri: Uri,
 selection: String?,
 selectionArgs: Array<String>?
 ): Int {
 val db = dbHelper.writableDatabase

 val count = when (uriMatcher.match(uri)) {
 USERS -> {
 db.delete("users", selection, selectionArgs)
 }
 USER_ID -> {
 val id = uri.lastPathSegment
 db.delete(
 "users",
 "${UserContract.Columns.ID} = ?",
 arrayOf(id)
 )
 }
 else -> throw IllegalArgumentException("Unknown URI: $uri")
 }

 if (count > 0) {
 context?.contentResolver?.notifyChange(uri, null)
 }

 return count
 }

 // 6. 返回 MIME 类型
 override fun getType(uri: Uri): String? {
 return when (uriMatcher.match(uri)) {
 USERS -> "vnd.android.cursor.dir/vnd.com.example.provider.users"
 USER_ID -> "vnd.android.cursor.item/vnd.com.example.provider.users"
 else -> throw IllegalArgumentException("Unknown URI: $uri")
 }
 }
}

步骤4:注册Provider

<!-- AndroidManifest.xml -->
<manifest>
 <application>
 <provider
 android:name=".UserProvider"
 android:authorities="com.example.provider"
 android:exported="true"
 android:permission="com.example.READ_USERS">

 <!-- 授予其他应用读写权限 -->
 <grant-uri-permission android:pathPattern="/users/.*" />
 </provider>
 </application>

 <!-- 定义权限 -->
 <permission
 android:name="com.example.READ_USERS"
 android:protectionLevel="normal" />
 <permission
 android:name="com.example.WRITE_USERS"
 android:protectionLevel="normal" />
</manifest>

使用ContentProvider

查询数据

class MainActivity : AppCompatActivity() {

 fun queryUsers() {
 // 1. 获取 ContentResolver
 val resolver = contentResolver

 // 2. 构建查询
 val uri = Uri.parse("content://com.example.provider/users")
 val projection = arrayOf(
 UserContract.Columns.ID,
 UserContract.Columns.NAME,
 UserContract.Columns.EMAIL
 )
 val selection = "${UserContract.Columns.AGE} > ?"
 val selectionArgs = arrayOf("18")
 val sortOrder = "${UserContract.Columns.NAME} ASC"

 // 3. 执行查询
 val cursor = resolver.query(
 uri,
 projection,
 selection,
 selectionArgs,
 sortOrder
 )

 // 4. 处理结果
 cursor?.use {
 while (it.moveToNext()) {
 val id = it.getLong(it.getColumnIndexOrThrow(UserContract.Columns.ID))
 val name = it.getString(it.getColumnIndexOrThrow(UserContract.Columns.NAME))
 val email = it.getString(it.getColumnIndexOrThrow(UserContract.Columns.EMAIL))

 Log.d("User", "ID: $id, Name: $name, Email: $email")
 }
 }
 }
}

插入数据

fun insertUser() {
 val resolver = contentResolver
 val uri = Uri.parse("content://com.example.provider/users")

 val values = ContentValues().apply {
 put(UserContract.Columns.NAME, "Alice")
 put(UserContract.Columns.EMAIL, "alice@example.com")
 put(UserContract.Columns.AGE, 25)
 }

 val newUri = resolver.insert(uri, values)
 Log.d("Insert", "新用户 URI: $newUri")
}

更新数据

fun updateUser(userId: Long) {
 val resolver = contentResolver
 val uri = ContentUris.withAppendedId(
 Uri.parse("content://com.example.provider/users"),
 userId
 )

 val values = ContentValues().apply {
 put(UserContract.Columns.EMAIL, "newemail@example.com")
 }

 val count = resolver.update(uri, values, null, null)
 Log.d("Update", "更新了 $count 条记录")
}

删除数据

fun deleteUser(userId: Long) {
 val resolver = contentResolver
 val uri = ContentUris.withAppendedId(
 Uri.parse("content://com.example.provider/users"),
 userId
 )

 val count = resolver.delete(uri, null, null)
 Log.d("Delete", "删除了 $count 条记录")
}

监听数据变化

ContentObserver

class MainActivity : AppCompatActivity() {

 private val userObserver = object : ContentObserver(Handler(Looper.getMainLooper())) {
 override fun onChange(selfChange: Boolean, uri: Uri?) {
 super.onChange(selfChange, uri)
 Log.d("Observer", "数据变化: $uri")
 // 重新查询数据
 queryUsers()
 }
 }

 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)

 // 注册观察者
 contentResolver.registerContentObserver(
 Uri.parse("content://com.example.provider/users"),
 true, // 监听所有子 URI
 userObserver
 )
 }

 override fun onDestroy() {
 super.onDestroy()
 // 取消注册
 contentResolver.unregisterContentObserver(userObserver)
 }
}

权限控制

定义权限

<!-- AndroidManifest.xml -->
<manifest>
 <!-- 定义权限 -->
 <permission
 android:name="com.example.READ_USERS"
 android:label="读取用户数据"
 android:description="允许读取用户数据"
 android:protectionLevel="normal" />

 <permission
 android:name="com.example.WRITE_USERS"
 android:label="写入用户数据"
 android:protectionLevel="normal" />

 <application>
 <provider
 android:name=".UserProvider"
 android:authorities="com.example.provider"
 android:exported="true"
 android:readPermission="com.example.READ_USERS"
 android:writePermission="com.example.WRITE_USERS" />
 </application>
</manifest>

请求权限

<!-- 其他应用的 Manifest -->
<manifest>
 <uses-permission android:name="com.example.READ_USERS" />
 <uses-permission android:name="com.example.WRITE_USERS" />
</manifest>

临时授权(URI权限)

// 授予其他应用临时访问权限
val intent = Intent(Intent.ACTION_VIEW)
intent.data = Uri.parse("content://com.example.provider/users/1")
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)
startActivity(intent)

Android Surface 体系：设计概念、Compose Surface 与底层缓冲

Sun, 19 Oct 2025 13:50:30 +0800

Surface 这个词在 Android 里有多层含义：设计系统里的视觉表面、Compose 的 Surface 组件、传统 View 的容器感，以及底层图形系统中的缓冲区。混在一起看会很乱，分层理解会清晰很多。

核心结论

Material/Compose 的 Surface 是视觉语义，强调背景、形状、阴影和内容承载。
底层 Surface 是图形缓冲生产者和消费者之间的连接点。
SurfaceView 有独立 Surface，适合视频、相机、游戏等高性能画面。
TextureView 更容易参与 View 层变换，但通常比 SurfaceView 成本更高。
Compose 中嵌入 SurfaceView 时，要特别关注生命周期和层级关系。

什么是surface？

通俗理解

Surface = 一块用于绘制内容的“画布”

Android有多层含义的 Surface 概念，容易混淆：

底层图形系统的Surface（本质）
Material Design的Surface （设计概念）
Compose的Surface组件（UI组件）
SurfaceView和TextureView（特殊视图）

层次架构

应用层
↓
Material Surface (设计概念：背景、卡片、对话框)
↓
UI 组件 (Compose Surface / View / SurfaceView)
↓
Android View System / Compose Runtime
↓
底层 Surface (实际的渲染目标)
↓
SurfaceFlinger (系统合成器)
↓
屏幕显示

1. Material Design 中的Surface

什么是Surface（设计概念）？

在Material Design中，Surface是承载内容的容器:

┌─────────────────────────────┐
│ 应用背景 (Background) │
│ ┌─────────────────────┐ │
│ │ Surface (卡片) │ │ ← 有阴影、圆角
│ │ [内容] │ │
│ └─────────────────────┘ │
│ │
│ ┌─────────────────────┐ │
│ │ Surface (对话框) │ │
│ └─────────────────────┘ │
└─────────────────────────────┘

2. Compose中的Surface组件

Surface的作用

Compose的Surface是一个容器组件，提供：

背景色
形状（圆角、切角）
边框
阴影/高度
点击效果

基础用法

import androidx.compose.material3.Surface
import androidx.compose.material3.MaterialTheme

@Composable
fun BasicSurface() {
 // 最简单的 Surface
 Surface {
 Text("Hello World")
 }

 // 自定义属性
 Surface(
 modifier = Modifier
 .fillMaxWidth()
 .padding(16.dp),
 color = MaterialTheme.colorScheme.primaryContainer, // 背景色
 contentColor = MaterialTheme.colorScheme.onPrimaryContainer, // 内容色
 tonalElevation = 2.dp, // 高度（影响颜色深浅）
 shadowElevation = 4.dp, // 阴影高度
 shape = RoundedCornerShape(12.dp), // 形状
 border = BorderStroke(1.dp, Color.Gray) // 边框
 ) {
 Column(modifier = Modifier.padding(16.dp)) {
 Text("标题", style = MaterialTheme.typography.titleLarge)
 Text("内容", style = MaterialTheme.typography.bodyMedium)
 }
 }
}

Surface vs Box vs Card

// Box：纯布局容器，无样式
Box(
 modifier = Modifier
 .background(Color.White) // 手动设置背景
 .padding(16.dp)
) {
 Text("Content")
}

// Surface：有背景、形状、高度的容器
Surface(
 color = MaterialTheme.colorScheme.surface,
 tonalElevation = 2.dp,
 shape = RoundedCornerShape(8.dp)
) {
 Text("Content")
}

// Card：预配置的 Surface（自带 padding、圆角、阴影）
Card(
 modifier = Modifier.fillMaxWidth()
) {
 Text("Content", modifier = Modifier.padding(16.dp))
}

选择建议

需要自定义形状/阴影 → Surface
卡片样式 → Card（本质是预设好的Surface）
纯布局 → Box

实战：卡片列表

@Composable
fun ProductCard(product: Product) {
 Surface(
 modifier = Modifier
 .fillMaxWidth()
 .padding(horizontal = 16.dp, vertical = 8.dp),
 shape = RoundedCornerShape(16.dp),
 color = MaterialTheme.colorScheme.surface,
 tonalElevation = 2.dp,
 shadowElevation = 4.dp
 ) {
 Row(
 modifier = Modifier.padding(16.dp),
 horizontalArrangement = Arrangement.spacedBy(16.dp)
 ) {
 // 产品图片
 Surface(
 shape = RoundedCornerShape(8.dp),
 modifier = Modifier.size(80.dp)
 ) {
 AsyncImage(
 model = product.imageUrl,
 contentDescription = null
 )
 }

 // 产品信息
 Column(modifier = Modifier.weight(1f)) {
 Text(
 text = product.name,
 style = MaterialTheme.typography.titleMedium
 )
 Text(
 text = product.description,
 style = MaterialTheme.typography.bodySmall,
 color = MaterialTheme.colorScheme.onSurfaceVariant
 )
 Text(
 text = "$${product.price}",
 style = MaterialTheme.typography.titleLarge,
 color = MaterialTheme.colorScheme.primary
 )
 }
 }
 }
}

3. 传统View中的Surface

MaterialCardView(常用)

<!-- res/layout/item_card.xml -->
<com.google.android.material.card.MaterialCardView
 android:layout_width="match_parent"
 android:layout_height="wrap_content"
 app:cardBackgroundColor="?attr/colorSurface"
 app:cardElevation="4dp"
 app:cardCornerRadius="12dp"
 app:strokeColor="?attr/colorOutline"
 app:strokeWidth="1dp">

 <LinearLayout
 android:layout_width="match_parent"
 android:layout_height="wrap_content"
 android:orientation="vertical"
 android:padding="16dp">

 <TextView
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:text="标题"
 android:textColor="?attr/colorOnSurface"
 android:textAppearance="?attr/textAppearanceTitleMedium" />

 <TextView
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:layout_marginTop="8dp"
 android:text="内容"
 android:textColor="?attr/colorOnSurfaceVariant"
 android:textAppearance="?attr/textAppearanceBodyMedium" />
 </LinearLayout>
</com.google.android.material.card.MaterialCardView>

对话框（DialogFragment）

class MyDialogFragment : DialogFragment() {
 override fun onCreateDialog(savedInstanceState: Bundle?): Dialog {
 return MaterialAlertDialogBuilder(requireContext())
 .setTitle("标题")
 .setMessage("消息内容")
 .setPositiveButton("确定") { _, _ -> }
 .setNegativeButton("取消") { _, _ -> }
 .create()
 }
}
// 对话框自动使用 ?attr/colorSurface 作为背景

4. 底层Surface（SurfaceView / TextureView）

什么时候用

View
- 普通UI
- 性能一般
- 主线程绘制
SurfaceView
- 视频播放、相机预览
- 性能高
- 独立Surface，后台线程绘制
TextureView
- 需要动画/变换的视频
- 性能中等
- 可以做动画，但性能较低

SurfaceView示例

class VideoPlayerActivity : AppCompatActivity() {
 private lateinit var surfaceView: SurfaceView
 private var mediaPlayer: MediaPlayer? = null

 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)

 surfaceView = SurfaceView(this).apply {
 layoutParams = ViewGroup.LayoutParams(
 ViewGroup.LayoutParams.MATCH_PARENT,
 ViewGroup.LayoutParams.MATCH_PARENT
 )
 }
 setContentView(surfaceView)

 // 监听 Surface 创建
 surfaceView.holder.addCallback(object : SurfaceHolder.Callback {
 override fun surfaceCreated(holder: SurfaceHolder) {
 // Surface 准备好了，开始播放
 mediaPlayer = MediaPlayer().apply {
 setDataSource("https://example.com/video.mp4")
 setDisplay(holder)
 prepareAsync()
 setOnPreparedListener { start() }
 }
 }

 override fun surfaceChanged(holder: SurfaceHolder, format: Int, width: Int, height: Int) {
 // Surface 大小改变
 }

 override fun surfaceDestroyed(holder: SurfaceHolder) {
 // Surface 销毁，释放资源
 mediaPlayer?.release()
 mediaPlayer = null
 }
 })
 }
}

SurfaceView vs TextureView

// SurfaceView：性能最好，但不能做动画
val surfaceView = SurfaceView(context)
// ✅ 适合：视频播放、相机预览、游戏
// ❌ 不适合：需要透明度、旋转、缩放动画

// TextureView：可以做动画，但性能较低
val textureView = TextureView(context)
textureView.alpha = 0.5f // ✅ 可以设置透明度
textureView.rotation = 45f // ✅ 可以旋转
// ✅ 适合：需要动画效果的视频
// ❌ 不适合：追求极致性能的场景

Compose中使用SurfaceView

@Composable
fun VideoPlayer(videoUrl: String) {
 AndroidView(
 factory = { context ->
 SurfaceView(context).apply {
 holder.addCallback(object : SurfaceHolder.Callback {
 override fun surfaceCreated(holder: SurfaceHolder) {
 // 初始化视频播放器
 }
 override fun surfaceChanged(holder: SurfaceHolder, format: Int, width: Int, height: Int) {}
 override fun surfaceDestroyed(holder: SurfaceHolder) {
 // 清理资源
 }
 })
 }
 },
 modifier = Modifier.fillMaxSize()
 )
}

5. 底层Surface工作原理

Surface的本质

应用进程 系统进程
↓ ↓
Canvas.draw() SurfaceFlinger
↓ ↓
Surface ←─────共享内存───────→ Surface
↓ ↓
写入像素数据 读取像素数据
↓
合成到屏幕

Surface = {
SharedBuffer (共享内存)
+ 元数据 (宽度、高度、格式、Z-order)
}

关键点：

每个Window有一个Surface
SurfaceView会创建独立的Surface（不在主Window上）
SurfaceFlinger负责合成所有Surface
Surface通过共享内存传递数据，避免拷贝

为什么SurfaceView性能高？

普通 View：
主线程绘制 → 等待 VSync → 显示
 ↑ 阻塞主线程

SurfaceView：
后台线程绘制 → 直接提交给 SurfaceFlinger → 显示
主线程继续处理 UI

SurfaceFlinger: 系统合成器，合成所有应用的画面
Surface：共享内存，应用写入，系统读取
Window：窗口抽象，管理Surface和输入事件
Canvas：绘制API，提供画图方法

Window Insets 指南：系统栏、键盘与 Edge-to-Edge

Fri, 17 Oct 2025 12:07:34 +0800

Window Insets 描述的是系统窗口占用或保留的区域，例如状态栏、导航栏、刘海、软键盘和手势区域。做沉浸式和 Edge-to-Edge 时，Insets 是必须理解的基础。

核心结论

Insets 不是“状态栏高度”，而是一组系统窗口边界信息。
默认布局通常由系统处理 Insets，Edge-to-Edge 后需要自己消费和分发。
IME Insets 用来处理键盘弹出后的内容避让。
Compose 和 View 都有 Insets API，但不要重复消费。
适配目标是内容可见、交互安全、视觉连续。

什么是Window Insets？

Window Insets = 系统UI占用的屏幕区域信息

想象你的应用是一张画布，但有些区域被系统UI“侵占”了：

顶部的状态栏(时间、电量、信号)
底部的导航栏(返回、Home、多任务)
刘海屏的凹口(notch)
折叠屏的折痕(hinge)
软键盘(IME)弹出时

Window Insets就是告诉你这些区域的位置和大小，让你决定如何处理

系统默认处理

// 默认情况（大多数应用）
setContentView(R.layout.activity_main)

// 系统自动做了这些：
// 1. 内容自动避开状态栏
// 2. 内容自动避开导航栏
// 3. 感觉不到 Insets 的存在

什么时候必须关心Insets？

全屏沉浸式体验
- 内容延伸到状态栏/导航栏下方（如视频播放器）
- 透明状态栏/导航栏
自定义边距处理
- FAB按钮要避开导航栏
- 底部导航栏要贴合屏幕底部
- 内容要避开刘海屏凹口
键盘处理
- 聊天界面，输入框跟随键盘上移
- 登录表单，避免被键盘遮挡
特殊设备适配
- 折叠屏、刘海屏、挖孔屏

Insets的类型

1. System Bars Insets (系统栏)

┌─────────────────────┐
│ 状态栏 (24dp) │ ← Status Bar
├─────────────────────┤
│ │
│ │
│ 你的内容区域 │
│ │
│ │
├─────────────────────┤
│ 导航栏 (48dp) │ ← Navigation Bar
└─────────────────────┘

2. Display Cutout Insets (刘海/挖孔)

 ┌──┐ 刘海
┌───┘ └─────────┐
│ │
│ 内容区域 │
│ │
└────────────────┘

3. IME Insets(软键盘)

┌────────────────┐
│ 内容区域 │
├────────────────┤
│ [输入框] │
├────────────────┤
│ 软键盘 │ ← IME (Input Method Editor)
└────────────────┘

4. System Gestures Insets (手势区域)

┌────────────────┐
│ ← 边缘滑动手势 │ ← 左边缘
│ │
│ │
│ 边缘滑动手势 → │ ← 右边缘
└────────────────┘

实战场景

场景1: 默认情况（不需要处理Insets）

// activity_main.xml
<LinearLayout
 android:layout_width="match_parent"
 android:layout_height="match_parent">

 <TextView
 android:text="Hello World"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content" />
</LinearLayout>

// MainActivity.kt
class MainActivity : AppCompatActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContentView(R.layout.activity_main)
 // 系统自动处理，内容避开系统栏 ✅
 }
}

结果：

┌─────────────────┐
│ 状态栏 (自动避开) │
├─────────────────┤
│ Hello World │ ← 内容从这里开始
│ │
├─────────────────┤
│ 导航栏 (自动避开) │
└─────────────────┘

场景2: 全屏沉浸式（透明状态栏）

需求：状态栏透明，内容延伸到状态栏下方

// MainActivity.kt
class MainActivity : AppCompatActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)

 // 1. 启用 Edge-to-Edge（内容延伸到边缘）
 WindowCompat.setDecorFitsSystemWindows(window, false)

 setContentView(R.layout.activity_main)

 // 2. 设置透明状态栏
 window.statusBarColor = Color.TRANSPARENT
 window.navigationBarColor = Color.TRANSPARENT

 // 3. 手动处理 Insets
 ViewCompat.setOnApplyWindowInsetsListener(findViewById(R.id.root)) { view, insets ->
 val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())

 // 给根布局添加 padding，避开系统栏
 view.updatePadding(
 top = systemBars.top,
 bottom = systemBars.bottom
 )

 insets
 }
 }
}

<!-- activity_main.xml -->
<LinearLayout
 android:id="@+id/root"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:background="@drawable/gradient_background">
 <!-- 内容会延伸到状态栏下方，但有 padding 避开 -->
 <TextView
 android:text="Hello World"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content" />
</LinearLayout>

结果：

┌─────────────────┐
│ [透明状态栏] │ ← 背景色透过状态栏可见
│ Hello World │ ← padding 避开了状态栏
│ │
│ │
└─────────────────┘

场景3: 底部按钮贴合导航栏

需求：FAB按钮要在导航栏上方，不被遮挡

<!-- activity_main.xml -->
<androidx.coordinatorlayout.widget.CoordinatorLayout
 android:id="@+id/root"
 android:layout_width="match_parent"
 android:layout_height="match_parent">

 <com.google.android.material.floatingactionbutton.FloatingActionButton
 android:id="@+id/fab"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:layout_gravity="bottom|end"
 android:layout_margin="16dp" />
</androidx.coordinatorlayout.widget.CoordinatorLayout>

class MainActivity : AppCompatActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 WindowCompat.setDecorFitsSystemWindows(window, false)
 setContentView(R.layout.activity_main)

 val fab = findViewById<FloatingActionButton>(R.id.fab)

 ViewCompat.setOnApplyWindowInsetsListener(fab) { view, insets ->
 val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())

 // FAB 的 bottom margin 要加上导航栏高度
 val layoutParams = view.layoutParams as ViewGroup.MarginLayoutParams
 layoutParams.bottomMargin = 16.dp + systemBars.bottom
 view.layoutParams = layoutParams

 insets
 }
 }
}

结果：

┌─────────────────┐
│ │
│ │
│ │
│ [FAB]│ ← 自动避开导航栏
├─────────────────┤
│ 导航栏 │
└─────────────────┘

场景4: 聊天界面跟随键盘

需求：输入框跟随键盘上移，不被遮挡

<!-- activity_chat.xml -->
<androidx.constraintlayout.widget.ConstraintLayout
 android:id="@+id/root"
 android:layout_width="match_parent"
 android:layout_height="match_parent">

 <androidx.recyclerview.widget.RecyclerView
 android:id="@+id/messages"
 android:layout_width="match_parent"
 android:layout_height="0dp"
 app:layout_constraintTop_toTopOf="parent"
 app:layout_constraintBottom_toTopOf="@id/input_layout" />

 <LinearLayout
 android:id="@+id/input_layout"
 android:layout_width="match_parent"
 android:layout_height="wrap_content"
 android:background="@color/surface"
 app:layout_constraintBottom_toBottomOf="parent">

 <EditText
 android:id="@+id/input"
 android:layout_width="0dp"
 android:layout_weight="1"
 android:layout_height="wrap_content"
 android:hint="输入消息..." />

 <ImageButton
 android:id="@+id/send"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:src="@drawable/ic_send" />
 </LinearLayout>
</androidx.constraintlayout.widget.ConstraintLayout>

class ChatActivity : AppCompatActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)

 // 关键：让窗口不自动调整大小
 WindowCompat.setDecorFitsSystemWindows(window, false)

 setContentView(R.layout.activity_chat)

 val inputLayout = findViewById<LinearLayout>(R.id.input_layout)

 // 监听 IME（键盘）Insets
 ViewCompat.setOnApplyWindowInsetsListener(inputLayout) { view, insets ->
 val imeInsets = insets.getInsets(WindowInsetsCompat.Type.ime())
 val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())

 // 输入框跟随键盘上移
 view.updatePadding(bottom = imeInsets.bottom.coerceAtLeast(systemBars.bottom))

 insets
 }
 }
}

结果（键盘弹出时）：

┌─────────────────┐
│ 消息列表 │
│ 自动滚动 │
├─────────────────┤
│ [输入框] [发送] │ ← 跟随键盘上移
├─────────────────┤
│ 软键盘 │
└─────────────────┘

Compose中的Insets

Compose提供了更简单的API：

// build.gradle.kts
implementation("androidx.compose.foundation:foundation:1.7.5")

// MainActivity.kt
class MainActivity : ComponentActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)

 // 启用 Edge-to-Edge
 WindowCompat.setDecorFitsSystemWindows(window, false)

 setContent {
 MyAppTheme {
 ChatScreen()
 }
 }
 }
}

@Composable
fun ChatScreen() {
 Scaffold(
 // 自动处理 Insets
 contentWindowInsets = WindowInsets.systemBars
 ) { paddingValues ->
 Column(
 modifier = Modifier
 .fillMaxSize()
 .padding(paddingValues) // 自动避开系统栏
 ) {
 MessageList(modifier = Modifier.weight(1f))

 InputBar(
 modifier = Modifier
 // 自动跟随键盘
 .imePadding()
 )
 }
 }
}

@Composable
fun InputBar(modifier: Modifier = Modifier) {
 Row(
 modifier = modifier
 .fillMaxWidth()
 .background(MaterialTheme.colorScheme.surface)
 .padding(8.dp)
 ) {
 TextField(
 value = "",
 onValueChange = {},
 modifier = Modifier.weight(1f)
 )
 IconButton(onClick = {}) {
 Icon(Icons.Default.Send, contentDescription = "发送")
 }
 }
}

Compose Insets 常用Modifier

// 1. 避开系统栏
Modifier.systemBarsPadding()

// 2. 只避开状态栏
Modifier.statusBarsPadding()

// 3. 只避开导航栏
Modifier.navigationBarsPadding()

// 4. 跟随键盘
Modifier.imePadding()

// 5. 避开刘海屏
Modifier.displayCutoutPadding()

// 6. 组合使用
Modifier
 .statusBarsPadding()
 .navigationBarsPadding()
 .imePadding()

常见问题

1. 为什么我的内容被状态栏遮挡了？

// ❌ 错误：启用了 Edge-to-Edge 但没处理 Insets
WindowCompat.setDecorFitsSystemWindows(window, false)
// 内容会延伸到状态栏下方，但没有 padding

// ✅ 正确：必须手动添加 padding
ViewCompat.setOnApplyWindowInsetsListener(view) { v, insets ->
 val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
 v.updatePadding(top = systemBars.top)
 insets
}

2. 为什么键盘弹出后界面没反应？

// ❌ 错误：没有监听 IME Insets
// 或者 AndroidManifest.xml 中设置了：
android:windowSoftInputMode="adjustResize" // 过时的是代码常量 SOFT_INPUT_ADJUST_RESIZE

// ✅ 正确：
WindowCompat.setDecorFitsSystemWindows(window, false)
ViewCompat.setOnApplyWindowInsetsListener(view) { v, insets ->
 val ime = insets.getInsets(WindowInsetsCompat.Type.ime())
 v.updatePadding(bottom = ime.bottom)
 insets
}

3. 我需要在每个View上设置Insets Listener吗？

// ❌ 不需要！Insets 会自动分发给子 View

// ✅ 通常只在根布局设置一次
ViewCompat.setOnApplyWindowInsetsListener(rootView) { view, insets ->
 // 处理 Insets
 insets // 返回 insets，让子 View 也能收到
}

设备适配示例

刘海屏适配

// 获取刘海区域
val cutout = insets.getInsets(WindowInsetsCompat.Type.displayCutout())

// 头部 Banner 避开刘海
headerView.updatePadding(
 left = cutout.left,
 top = cutout.top,
 right = cutout.right
)

折叠屏适配

// 获取铰链区域（需要 Jetpack WindowManager）
implementation("androidx.window:window:1.3.0")

WindowInfoTracker.getOrCreate(this)
 .windowLayoutInfo(this)
 .collect { layoutInfo ->
 layoutInfo.displayFeatures.forEach { feature ->
 if (feature is FoldingFeature) {
 // 处理折叠屏逻辑
 }
 }
 }

关键API速查

// 启用 Edge-to-Edge
WindowCompat.setDecorFitsSystemWindows(window, false)

// 监听 Insets
ViewCompat.setOnApplyWindowInsetsListener(view) { v, insets ->
 val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
 val ime = insets.getInsets(WindowInsetsCompat.Type.ime())
 // 处理...
 insets
}

// Compose
Modifier.systemBarsPadding()
Modifier.imePadding()

Android 主题系统：Material 3、Dynamic Color 与深色模式

Fri, 17 Oct 2025 11:24:19 +0800

主题系统的价值是把颜色、字体、形状和组件默认样式集中管理。Material 3 之后，颜色不再只是主色和强调色，而是一组有语义的 Color Scheme。

核心结论

主题系统解决的是全局视觉一致性，不是单个控件样式。
Material 3 用语义化色彩角色描述 UI，而不是直接到处写颜色值。
Dynamic Color 基于系统壁纸生成色板，适合 Android 12+。
Compose 使用 MaterialTheme，传统 View 使用 XML theme，两者可以共存但要统一设计令牌。
深色模式要关注对比度、语义色和图片资源，不只是反转颜色。

Material Design3(Material You)

核心概念

Material Design3 (MD3)是Google在Android 12+引入的设计系统，核心特性：

Dynamic Color：根据壁纸自动生成主题色
更圆润的组件：更大的圆角半径
色彩角色系统：40+个语义化颜色槽位
个性化：让每个用户的应用看起来独一无二

版本要求

// Material 3
implementation("com.google.android.material:material:1.12.0")

// Compose Material 3
implementation("androidx.compose.material3:material3:1.3.1")

主题系统架构

三层结构

Material Theme (Material 3)
↓
Application Theme (你的应用主题)
↓
Component Styles (组件样式)

色彩角色系统

Material 3 定义了5大色彩组：

1. Primary（主色）

<!-- 最重要的品牌色，用于主要操作 -->
<attr name="colorPrimary" /> <!-- 主色 -->
<attr name="colorOnPrimary" /> <!-- 主色上的文字/图标 -->
<attr name="colorPrimaryContainer" /> <!-- 主色容器 -->
<attr name="colorOnPrimaryContainer" /> <!-- 容器上的内容 -->

2. Secondary(次要色)

<!-- 次要操作，辅助主色 -->
<attr name="colorSecondary" />
<attr name="colorOnSecondary" />
<attr name="colorSecondaryContainer" />
<attr name="colorOnSecondaryContainer" />

3. Tertiary(第三色)

<!-- 用于强调或对比 -->
<attr name="colorTertiary" />
<attr name="colorOnTertiary" />
<attr name="colorTertiaryContainer" />
<attr name="colorOnTertiaryContainer" />

4. Error（错误色）

<!-- 错误状态 -->
<attr name="colorError" />
<attr name="colorOnError" />
<attr name="colorErrorContainer" />
<attr name="colorOnErrorContainer" />

5. Surface & Background(表面和背景)

<!-- 背景和表面 -->
<attr name="colorSurface" /> <!-- 卡片、对话框背景 -->
<attr name="colorOnSurface" /> <!-- 表面上的文字 -->
<attr name="colorSurfaceVariant" /> <!-- 表面变体 -->
<attr name="colorOnSurfaceVariant" /> <!-- 次要文字 -->
<attr name="colorBackground" /> <!-- 应用背景 -->
<attr name="colorOnBackground" /> <!-- 背景上的内容 -->

6. Outline & Other

<!-- 边框和其他 -->
<attr name="colorOutline" /> <!-- 分割线、边框 -->
<attr name="colorOutlineVariant" /> <!-- 更弱的边框 -->
<attr name="colorSurfaceTint" /> <!-- 表面着色（高度感） -->

Dynamic Color (动态配色)

所谓Dynamic Color：Android 12+系统会从用户壁纸提取颜色，生成整套主题色，实现”千人千面“。

实现方式

方式一：使用系统提供的主题

<!-- res/values/themes.xml -->
<resources>
 <!-- Android 12+ 会自动应用 Dynamic Color -->
 <style name="Theme.MyApp" parent="Theme.Material3.DayNight">
 <!-- 可选：覆盖特定颜色 -->
 <item name="colorPrimary">@color/custom_primary</item>
 </style>
</resources>

<!-- res/values-v31/themes.xml (Android 12+ 专用) -->
<resources>
 <!-- 使用 DynamicColors 主题 -->
 <style name="Theme.MyApp" parent="Theme.Material3.DayNight.NoActionBar">
 <!-- 系统自动应用壁纸颜色，无需定义 colorPrimary 等 -->
 </style>
</resources>

方式二：代码启用（更灵活）

// Application 或 Activity
class MyApplication : Application() {
 override fun onCreate() {
 super.onCreate()

 // 全局启用 Dynamic Color
 DynamicColors.applyToActivitiesIfAvailable(this)
 }
}

// 单个 Activity 启用
class MainActivity : AppCompatActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)

 // 只在此 Activity 启用
 DynamicColors.applyIfAvailable(this)
 }
}

方式三：提供回退方案

// 支持用户选择是否启用
class MyApplication : Application() {
 override fun onCreate() {
 super.onCreate()

 if (supportsDynamicColor() && userPrefersDynamicColor()) {
 DynamicColors.applyToActivitiesIfAvailable(this)
 }
 }

 private fun supportsDynamicColor(): Boolean {
 return Build.VERSION.SDK_INT >= Build.VERSION_CODES.S // Android 12+
 }
}

自定义Dynamic Color

<!-- 即使启用 Dynamic Color，也可覆盖特定颜色 -->
<style name="Theme.MyApp" parent="Theme.Material3.DayNight">
 <!-- 强制使用品牌色作为 Primary -->
 <item name="colorPrimary">@color/brand_color</item>
 <!-- 其他颜色让系统自动生成 -->
</style>

传统View主题

完整主题配置

<!-- res/values/colors.xml -->
<resources>
 <!-- Light Mode Colors -->
 <color name="md_theme_light_primary">#6750A4</color>
 <color name="md_theme_light_onPrimary">#FFFFFF</color>
 <color name="md_theme_light_primaryContainer">#EADDFF</color>
 <color name="md_theme_light_onPrimaryContainer">#21005D</color>

 <color name="md_theme_light_secondary">#625B71</color>
 <color name="md_theme_light_onSecondary">#FFFFFF</color>
 <color name="md_theme_light_secondaryContainer">#E8DEF8</color>
 <color name="md_theme_light_onSecondaryContainer">#1D192B</color>

 <color name="md_theme_light_surface">#FFFBFE</color>
 <color name="md_theme_light_onSurface">#1C1B1F</color>
 <color name="md_theme_light_background">#FFFBFE</color>

 <!-- Dark Mode Colors -->
 <color name="md_theme_dark_primary">#D0BCFF</color>
 <color name="md_theme_dark_onPrimary">#381E72</color>
 <!-- ... 其他深色模式颜色 -->
</resources>

<!-- res/values/themes.xml -->
<resources>
 <style name="Theme.MyApp" parent="Theme.Material3.DayNight.NoActionBar">
 <!-- Primary -->
 <item name="colorPrimary">@color/md_theme_light_primary</item>
 <item name="colorOnPrimary">@color/md_theme_light_onPrimary</item>
 <item name="colorPrimaryContainer">@color/md_theme_light_primaryContainer</item>
 <item name="colorOnPrimaryContainer">@color/md_theme_light_onPrimaryContainer</item>

 <!-- Secondary -->
 <item name="colorSecondary">@color/md_theme_light_secondary</item>
 <item name="colorOnSecondary">@color/md_theme_light_onSecondary</item>
 <item name="colorSecondaryContainer">@color/md_theme_light_secondaryContainer</item>
 <item name="colorOnSecondaryContainer">@color/md_theme_light_onSecondaryContainer</item>

 <!-- Surface & Background -->
 <item name="colorSurface">@color/md_theme_light_surface</item>
 <item name="colorOnSurface">@color/md_theme_light_onSurface</item>
 <item name="android:colorBackground">@color/md_theme_light_background</item>

 <!-- 状态栏和导航栏 -->
 <item name="android:statusBarColor">@android:color/transparent</item>
 <item name="android:navigationBarColor">@color/md_theme_light_surface</item>
 <item name="android:windowLightStatusBar">true</item>
 <item name="android:windowLightNavigationBar">true</item>

 <!-- 形状（圆角） -->
 <item name="shapeAppearanceSmallComponent">@style/ShapeAppearance.MyApp.SmallComponent</item>
 <item name="shapeAppearanceMediumComponent">@style/ShapeAppearance.MyApp.MediumComponent</item>
 <item name="shapeAppearanceLargeComponent">@style/ShapeAppearance.MyApp.LargeComponent</item>
 </style>

 <!-- 自定义形状 -->
 <style name="ShapeAppearance.MyApp.SmallComponent" parent="ShapeAppearance.Material3.SmallComponent">
 <item name="cornerFamily">rounded</item>
 <item name="cornerSize">8dp</item>
 </style>

 <style name="ShapeAppearance.MyApp.MediumComponent" parent="ShapeAppearance.Material3.MediumComponent">
 <item name="cornerSize">12dp</item>
 </style>

 <style name="ShapeAppearance.MyApp.LargeComponent" parent="ShapeAppearance.Material3.LargeComponent">
 <item name="cornerSize">16dp</item>
 </style>
</resources>

<!-- res/values-night/colors.xml -->
<resources>
 <!-- 深色模式的颜色会自动被使用 -->
 <color name="md_theme_light_primary">@color/md_theme_dark_primary</color>
 <color name="md_theme_light_onPrimary">@color/md_theme_dark_onPrimary</color>
 <!-- ... -->
</resources>

在布局中使用

<!-- res/layout/activity_main.xml -->
<LinearLayout
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:background="?attr/colorBackground">

 <!-- 使用主题颜色 -->
 <com.google.android.material.button.MaterialButton
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:text="Primary Button"
 android:backgroundTint="?attr/colorPrimary"
 android:textColor="?attr/colorOnPrimary" />

 <!-- 次要按钮 -->
 <com.google.android.material.button.MaterialButton
 style="@style/Widget.Material3.Button.TonalButton"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:text="Secondary Button" />

 <!-- 卡片使用 Surface 色 -->
 <com.google.android.material.card.MaterialCardView
 android:layout_width="match_parent"
 android:layout_height="wrap_content"
 app:cardBackgroundColor="?attr/colorSurface"
 app:cardElevation="2dp">

 <TextView
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:text="Card Content"
 android:textColor="?attr/colorOnSurface" />
 </com.google.android.material.card.MaterialCardView>
</LinearLayout>

Compose主题

完整Compose主题实现

// ui/theme/Color.kt
package com.example.myapp.ui.theme

import androidx.compose.ui.graphics.Color

// Light Theme Colors
val md_theme_light_primary = Color(0xFF6750A4)
val md_theme_light_onPrimary = Color(0xFFFFFFFF)
val md_theme_light_primaryContainer = Color(0xFFEADDFF)
val md_theme_light_onPrimaryContainer = Color(0xFF21005D)

val md_theme_light_secondary = Color(0xFF625B71)
val md_theme_light_onSecondary = Color(0xFFFFFFFF)
val md_theme_light_secondaryContainer = Color(0xFFE8DEF8)
val md_theme_light_onSecondaryContainer = Color(0xFF1D192B)

val md_theme_light_surface = Color(0xFFFFFBFE)
val md_theme_light_onSurface = Color(0xFF1C1B1F)
val md_theme_light_background = Color(0xFFFFFBFE)

// Dark Theme Colors
val md_theme_dark_primary = Color(0xFFD0BCFF)
val md_theme_dark_onPrimary = Color(0xFF381E72)
val md_theme_dark_primaryContainer = Color(0xFF4F378B)
val md_theme_dark_onPrimaryContainer = Color(0xFFEADDFF)

val md_theme_dark_secondary = Color(0xFFCCC2DC)
val md_theme_dark_onSecondary = Color(0xFF332D41)
val md_theme_dark_surface = Color(0xFF1C1B1F)
val md_theme_dark_onSurface = Color(0xFFE6E1E5)
val md_theme_dark_background = Color(0xFF1C1B1F)


// ui/theme/Theme.kt
package com.example.myapp.ui.theme

import android.app.Activity
import android.os.Build
import androidx.compose.foundation.isSystemInDarkTheme
import androidx.compose.material3.*
import androidx.compose.runtime.Composable
import androidx.compose.runtime.SideEffect
import androidx.compose.ui.graphics.toArgb
import androidx.compose.ui.platform.LocalContext
import androidx.compose.ui.platform.LocalView
import androidx.core.view.WindowCompat

private val LightColorScheme = lightColorScheme(
 primary = md_theme_light_primary,
 onPrimary = md_theme_light_onPrimary,
 primaryContainer = md_theme_light_primaryContainer,
 onPrimaryContainer = md_theme_light_onPrimaryContainer,

 secondary = md_theme_light_secondary,
 onSecondary = md_theme_light_onSecondary,
 secondaryContainer = md_theme_light_secondaryContainer,
 onSecondaryContainer = md_theme_light_onSecondaryContainer,

 surface = md_theme_light_surface,
 onSurface = md_theme_light_onSurface,
 background = md_theme_light_background
)

private val DarkColorScheme = darkColorScheme(
 primary = md_theme_dark_primary,
 onPrimary = md_theme_dark_onPrimary,
 primaryContainer = md_theme_dark_primaryContainer,
 onPrimaryContainer = md_theme_dark_onPrimaryContainer,

 secondary = md_theme_dark_secondary,
 onSecondary = md_theme_dark_onSecondary,
 surface = md_theme_dark_surface,
 onSurface = md_theme_dark_onSurface,
 background = md_theme_dark_background
)

@Composable
fun MyAppTheme(
 darkTheme: Boolean = isSystemInDarkTheme(),
 // 启用 Dynamic Color（Android 12+）
 dynamicColor: Boolean = true,
 content: @Composable () -> Unit
) {
 val colorScheme = when {
 // Android 12+ 支持 Dynamic Color
 dynamicColor && Build.VERSION.SDK_INT >= Build.VERSION_CODES.S -> {
 val context = LocalContext.current
 if (darkTheme) dynamicDarkColorScheme(context)
 else dynamicLightColorScheme(context)
 }
 // 回退到静态主题
 darkTheme -> DarkColorScheme
 else -> LightColorScheme
 }

 // 设置状态栏颜色
 val view = LocalView.current
 if (!view.isInEditMode) {
 SideEffect {
 val window = (view.context as Activity).window
 window.statusBarColor = colorScheme.primary.toArgb()
 WindowCompat.getInsetsController(window, view).isAppearanceLightStatusBars = !darkTheme
 }
 }

 MaterialTheme(
 colorScheme = colorScheme,
 typography = Typography,
 content = content
 )
}


// ui/theme/Type.kt
package com.example.myapp.ui.theme

import androidx.compose.material3.Typography
import androidx.compose.ui.text.TextStyle
import androidx.compose.ui.text.font.FontFamily
import androidx.compose.ui.text.font.FontWeight
import androidx.compose.ui.unit.sp

val Typography = Typography(
 bodyLarge = TextStyle(
 fontFamily = FontFamily.Default,
 fontWeight = FontWeight.Normal,
 fontSize = 16.sp,
 lineHeight = 24.sp,
 letterSpacing = 0.5.sp
 ),
 titleLarge = TextStyle(
 fontFamily = FontFamily.Default,
 fontWeight = FontWeight.Normal,
 fontSize = 22.sp,
 lineHeight = 28.sp,
 letterSpacing = 0.sp
 ),
 labelSmall = TextStyle(
 fontFamily = FontFamily.Default,
 fontWeight = FontWeight.Medium,
 fontSize = 11.sp,
 lineHeight = 16.sp,
 letterSpacing = 0.5.sp
 )
)


// MainActivity.kt
class MainActivity : ComponentActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContent {
 MyAppTheme {
 Surface(
 modifier = Modifier.fillMaxSize(),
 color = MaterialTheme.colorScheme.background
 ) {
 AppContent()
 }
 }
 }
 }
}

@Composable
fun AppContent() {
 Column(
 modifier = Modifier
 .fillMaxSize()
 .padding(16.dp)
 ) {
 // 使用主题颜色
 Button(
 onClick = { },
 colors = ButtonDefaults.buttonColors(
 containerColor = MaterialTheme.colorScheme.primary,
 contentColor = MaterialTheme.colorScheme.onPrimary
 )
 ) {
 Text("Primary Button")
 }

 // 使用 Surface 卡片
 Card(
 modifier = Modifier
 .fillMaxWidth()
 .padding(top = 16.dp),
 colors = CardDefaults.cardColors(
 containerColor = MaterialTheme.colorScheme.surfaceVariant
 )
 ) {
 Text(
 text = "Card Content",
 style = MaterialTheme.typography.bodyLarge,
 color = MaterialTheme.colorScheme.onSurfaceVariant,
 modifier = Modifier.padding(16.dp)
 )
 }
 }
}

深色模式

完整实现方法

1.系统跟随

// 使用 DayNight 主题
<style name="Theme.MyApp" parent="Theme.Material3.DayNight">
 <!-- 自动根据系统设置切换 -->
</style>

2. 手动切换

// 提供用户选择
class SettingsActivity : AppCompatActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)

 // 获取当前模式
 val currentMode = AppCompatDelegate.getDefaultNightMode()

 // 切换模式
 when (userSelection) {
 "light" -> AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_NO)
 "dark" -> AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_YES)
 "system" -> AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_FOLLOW_SYSTEM)
 }
 }
}

// Compose 中切换
@Composable
fun ThemeSettings() {
 var darkMode by remember { mutableStateOf(false) }

 MyAppTheme(darkTheme = darkMode) {
 Switch(
 checked = darkMode,
 onCheckedChange = { darkMode = it }
 )
 }
}

3. 深色模式注意事项

<!-- 为深色模式提供专用资源 -->
<!-- res/values-night/colors.xml -->
<color name="window_background">#121212</color>

<!-- res/drawable-night/ic_logo.xml -->
<!-- 深色模式下使用不同的图标 -->

<!-- res/values-night/themes.xml -->
<style name="Theme.MyApp" parent="Theme.Material3.DayNight">
 <item name="android:windowLightStatusBar">false</item>
</style>

最佳实践

1. 使用Material 3

// ✅ 使用 M3
 implementation("com.google.android.material:material:1.12.0")
 parent="Theme.Material3.DayNight"

 // ❌ 不要用旧版本
 parent="Theme.MaterialComponents.DayNight"

2. 启用Dynamic Color

// ✅ 让应用更个性化
 DynamicColors.applyToActivitiesIfAvailable(this)

3. 使用语义化颜色

// ✅ 使用主题属性
 android:textColor="?attr/colorOnSurface"

 // ❌ 不要硬编码
 android:textColor="#000000"

4. 提供深色模式

// ✅ 支持系统深色模式
 parent="Theme.Material3.DayNight"

 // ❌ 只支持亮色
 parent="Theme.Material3.Light"

Android 事件分发机制：Activity、ViewGroup 与 View

Tue, 02 Sep 2025 21:41:39 +0800

事件分发的核心问题是：一次触摸事件从系统进入应用后，最终由哪个 View 消费。理解这条链路后，点击冲突、滑动冲突和自定义 View 触摸问题会更容易定位。

核心结论

事件从 Activity 开始，沿 View 树向下分发。
ViewGroup 可以通过 onInterceptTouchEvent() 决定是否拦截。
View 通过 onTouchEvent() 决定是否消费。
ACTION_DOWN 的处理结果会影响后续 MOVE/UP 是否继续分发。
滑动冲突本质是父子 View 对同一事件序列的消费权竞争。

1. 事件分发的基本流程

1.1 事件传递顺序

事件从Activity开始，按照一下顺序传递：

Activity -> Window -> DecorView -> ViewGroup -> View

1.2 核心方法

dispatchTouchEvent
- 负责事件的分发
- 返回true表示事件被消费，false表示未消费
onInterceptTouchEvent
- 只有ViewGroup才有的方法
- 用于拦截事件，返回true表示拦截事件
onTouchEvent
- 处理点击事件
- 返回true表示事件被消费

2. 源码分析

2.1 Activity的dispatchTouchEvent

public boolean dispatchTouchEvent(MotionEvent ev) {
 if (ev.getAction() == MotionEvent.ACTION_DOWN) {
 onUserInteraction(); // 空方法，可以重写
 }
 if (getWindow().superDispatchTouchEvent(ev)) {
 return true; // 事件被消费
 }
 return onTouchEvent(ev); // 如果所有View都没有处理，则调用Activity的onTouchEvent
}

2.2 ViewGroup的dispatchTouchEvent

public boolean dispatchTouchEvent(MotionEvent ev) {
 // 1. 检查是否拦截
 final boolean intercepted;
 if (actionMasked == MotionEvent.ACTION_DOWN || mFirstTouchTarget != null) {
 final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
 if (!disallowIntercept) {
 intercepted = onInterceptTouchEvent(ev);
 ev.setAction(action); // 恢复action，防止被修改
 } else {
 intercepted = false;
 }
 } else {
 // 没有目标处理该事件，也不拦截
 intercepted = true;
 }

 // 2. 如果不拦截，则寻找可以处理事件的子View
 if (!canceled && !intercepted) {
 // 遍历子View，寻找可以处理事件的View
 for (int i = childrenCount - 1; i >= 0; i--) {
 final View child = children[i];
 if (child.dispatchTouchEvent(ev)) {
 // 找到可以处理事件的子View
 mFirstTouchTarget = addTouchTarget(child, idBitsToAssign);
 break;
 }
 }
 }

 // 3. 分发事件
 if (mFirstTouchTarget == null) {
 // 没有子View处理事件，调用父类的dispatchTouchEvent
 handled = super.dispatchTouchEvent(ev);
 } else {
 // 将事件分发给目标View
 TouchTarget target = mFirstTouchTarget;
 while (target != null) {
 final View child = target.child;
 if (child.dispatchTouchEvent(ev)) {
 handled = true;
 }
 target = target.next;
 }
 }
 return handled;
}

实际执行流程

DOWN事件:
- mFirstTouchTarget == null，进入寻找目标View的循环
- 调用child.dispatchTouchEvent(ev)（第一次）
- 如果某个子View返回true，设置mFirstTouchTarget
MOVE/UP事件:
- mFirstTouchTarget != null，直接进入分发流程
- 调用target.child.dispatchTouchEvent(ev)（第二次）
- 不会再次进入寻找目标View的循环
TouchTarget
- TouchTarget是链表结构主要目的是为了支持多点触控
- 从 mFirstTouchTarget 开始遍历链表
- 检查每个 TouchTarget 的 pointerIdBits 是否与当前事件的 desiredPointerIdBits 匹配
- 如果找到匹配的 TouchTarget，则将事件分发给对应的子View
- 如果没有找到匹配的 TouchTarget，则返回false

为什么这样设计

性能优化：避免每次事件都遍历所有子View
事件一致性：确保同一事件序列由同一View处理
正确性：防止事件序列被拆分到不同View处理

2.3 View的dispatchTouchEvent

public boolean dispatchTouchEvent(MotionEvent event) {
 // 1. 首先检查OnTouchListener
 ListenerInfo li = mListenerInfo;
 if (li != null && li.mOnTouchListener != null
 && (mViewFlags & ENABLED_MASK) == ENABLED
 && li.mOnTouchListener.onTouch(this, event)) {
 return true;
 }

 // 2. 然后调用onTouchEvent
 if (onTouchEvent(event)) {
 return true;
 }

 return false;
}

3. 事件分发的关键点

事件序列：从ACTION_DOWN开始，到ACTION_UP或ACTION_CANCEL结束的一些列事件
事件拦截：ViewGroup可以通过onIterceptTouchEvent拦截事件
事件消费：View可以通过onTouchEvent或OnTouchListener消费事件
事件传递：默认情况下，事件会从上到下传递，直到被消费

4. 常见面试题

4.1 事件分发的流程是怎样的

从Activity的dispatchTouchEvent开始
经过Window、DecorView、ViewGroup
最终到达具体的View
如果没有任何View消费事件，事件会回传到Activity的onTouchEvent

4.2 onTouch和onTouchEvent的区别

onTouch是View.OnTouchListener接口中的方法
onTouchEvent是View的方法
onTouch的优先级高于onTouchEvent
如果onTouch返回true，事件已被消费，后续通常不会再调用该 View 的onTouchEvent()

4.3 如何解决滑动冲突

外部拦截法：重写父容器的onInterceptTouchEvent方法
内部拦截法：重写子元素的dispatchTouchEvent方法，结合requestDisallowInterceptTouchEvent方法

5. 实际应用示例

// 自定义ViewGroup，处理左右滑动冲突
public class CustomViewPager extends ViewGroup {
 private float mLastX;
 private float mLastY;

 @Override
 public boolean onInterceptTouchEvent(MotionEvent ev) {
 boolean intercepted = false;
 float x = ev.getX();
 float y = ev.getY();

 switch (ev.getAction()) {
 case MotionEvent.ACTION_DOWN:
 mLastX = x;
 mLastY = y;
 intercepted = false;
 break;
 case MotionEvent.ACTION_MOVE:
 float deltaX = Math.abs(x - mLastX);
 float deltaY = Math.abs(y - mLastY);
 // 横向滑动距离大于纵向滑动距离时拦截事件
 if (deltaX > deltaY) {
 intercepted = true;
 } else {
 intercepted = false;
 }
 break;
 case MotionEvent.ACTION_UP:
 intercepted = false;
 break;
 }

 mLastX = x;
 mLastY = y;
 return intercepted;
 }
}

Choreographer 类解析：VSYNC 与一帧调度

Mon, 16 Jun 2025 06:49:21 +0800

Choreographer 是 Android 应用侧的一帧调度器。它把输入、动画、Insets 动画、View 树遍历和提交阶段组织到同一个 VSYNC 节奏下执行。

核心结论

Choreographer 通过 VSYNC 信号驱动一帧开始。
每类回调都有独立 CallbackQueue，并按固定顺序执行。
doFrame() 是应用侧处理一帧的核心入口。
ViewRootImpl 会通过 Choreographer 安排 traversal。
掉帧本质是某一帧内任务超过了刷新周期预算。

一、核心作用

Choreographer是Android系统协调动画、输入和绘制操作的核心调度器。它通过VSYNC信号确保帧的渲染与屏幕刷新率同步，避免画面撕裂和卡顿。

二、关键概念

VSYNC：垂直同步信号，表示屏幕开始刷新新的一帧
Frame Callbacks：注册的回调函数，在下一帧的特定阶段执行
Callback Types（按执行顺序排序）
- CALLBACK_INPUT
- CALLBACK_ANIMATION
- CALLBACK_INSETS_ANIMATION
- CALLBACK_TRAVERSAL
- CALLBACK_COMMIT

public final class Choreographer {
 // 五种回调类型
 public static final int CALLBACK_INPUT = 0;
 public static final int CALLBACK_ANIMATION = 1;
 public static final int CALLBACK_INSETS_ANIMATION = 2;
 public static final int CALLBACK_TRAVERSAL = 3;
 public static final int CALLBACK_COMMIT = 4;
 public static final int CALLBACK_LAST = CALLBACK_COMMIT; // 最后一种类型

 // 单例模式实现
 private static final ThreadLocal<Choreographer> sThreadInstance =
 new ThreadLocal<Choreographer>() {
 @Override
 protected Choreographer initialValue() {
 Looper looper = Looper.myLooper();
 return new Choreographer(looper, VSYNC_SOURCE_APP);
 }
 };

 // 回调队列数组
 private final CallbackQueue[] mCallbackQueues;

 // VSYNC 接收器
 private final FrameDisplayEventReceiver mDisplayEventReceiver;

 // 处理消息的Handler
 private final FrameHandler mHandler;
}

三、核心架构图解

┌───────────────────────┐ ┌───────────────────────┐
│ VSYNC 信号源 │──────>│ FrameDisplayEventReceiver │
└───────────────────────┘ │ (接收硬件VSYNC信号) │
 └───────────┬───────────┘
 │
 ▼
┌───────────────────────┐ ┌───────────────────────┐
│ FrameHandler │<──────│ onVsync() │
│ (处理3类消息) │──────>│ scheduleVsync() │
└───────────┬───────────┘ └───────────────────────┘
 │
 ▼
┌───────────────────────┐
│ doFrame() │
│ (帧处理核心方法) │
└───────────┬───────────┘
 │
 ▼
┌───────────────────────┐
│ CallbackQueue[] │
│ (5种类型回调链表) │
└───────────────────────┘

四、回调添加入口

1. 添加回调入口

public void postCallback(int callbackType, Runnable action, Object token) {
 postCallbackDelayed(callbackType, action, token, 0);
}

public void postCallbackDelayed(int callbackType, Runnable action, long delayMillis) {
 postCallbackDelayedInternal(callbackType, action, token, delayMillis);
}

2. 内部添加实现

private void postCallbackDelayedInternal(int callbackType,
 Object action, Object token, long delayMillis) {

 synchronized (mLock) {
 final long now = SystemClock.uptimeMillis();
 final long dueTime = now + delayMillis;

 // 1. 添加到对应的回调队列
 mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);

 // 2. 调度帧处理
 if (dueTime <= now) {
 // 立即调度
 scheduleFrameLocked(now);
 } else {
 // 延迟调度
 Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
 msg.arg1 = callbackType;
 msg.setAsynchronous(true);
 mHandler.sendMessageAtTime(msg, dueTime);
 }
 }
}

3. 回调链表结构

private static final class CallbackQueue {
 private CallbackRecord mHead;

 public void addCallbackLocked(long dueTime, Object action, Object token) {
 CallbackRecord callback = obtainCallbackLocked(dueTime, action, token);

 if (mHead == null) {
 mHead = callback;
 return;
 }

 // 链表按照执行时间排序（小到大）
 if (dueTime < mHead.dueTime) {
 callback.next = mHead;
 mHead = callback;
 return;
 }

 CallbackRecord entry = mHead;
 while (entry.next != null) {
 if (dueTime < entry.next.dueTime) {
 callback.next = entry.next;
 entry.next = callback;
 return;
 }
 entry = entry.next;
 }
 entry.next = callback;
 }
}

// 链表节点定义
private static final class CallbackRecord {
 public CallbackRecord next;
 public long dueTime;
 public Object action; // Runnable 或 FrameCallback
 public Object token;
}

五、VSYNC同步机制

1、 VSYNC请求

private void scheduleFrameLocked(long now) {
 if (!mFrameScheduled) {
 mFrameScheduled = true;

 if (USE_VSYNC) {
 // 通过 FrameDisplayEventReceiver 请求 VSYNC
 if (isRunningOnLooperThreadLocked()) {
 //注册
 scheduleVsyncLocked();
 } else {
 // 非UI线程发送消息到UI线程
 Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
 msg.setAsynchronous(true);
 mHandler.sendMessageAtFrontOfQueue(msg);
 }
 } else {
 // 无VSYNC直接安排帧
 final long nextFrameTime = ...;
 Message msg = mHandler.obtainMessage(MSG_DO_FRAME);
 msg.setAsynchronous(true);
 mHandler.sendMessageAtTime(msg, nextFrameTime);
 }
 }
}

private void scheduleVsyncLocked() {
 mDisplayEventReceiver.scheduleVsync();
}

2. VSYNC接收与处理

private final class FrameDisplayEventReceiver extends DisplayEventReceiver {
 @Override
 public void onVsync(long timestampNanos, long physicalDisplayId, int frame) {
 // 1. 计算正确的帧时间
 long now = System.nanoTime();
 long intendedFrameTimeNanos = ...;

 // 2. 发送MSG_DO_FRAME消息
 Message msg = Message.obtain(mHandler, MSG_DO_FRAME);
 msg.setAsynchronous(true);
 mHandler.sendMessageAtTime(msg, intendedFrameTimeNanos / NANOS_PER_MS);
 }
}

3. 帧处理核心 - doFrame()

void doFrame(long frameTimeNanos, int frame) {
 final long startNanos;
 synchronized (mLock) {
 // 检查帧调度状态
 if (!mFrameScheduled) return;

 // 计算跳帧情况
 long jitterNanos = startNanos - frameTimeNanos;
 if (jitterNanos >= mFrameIntervalNanos) {
 final long skippedFrames = jitterNanos / mFrameIntervalNanos;
 // 超过阈值打印警告日志
 if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
 Log.i(TAG, "Skipped " + skippedFrames + " frames!");
 }
 frameTimeNanos = ...; // 调整帧时间
 }

 mLastFrameTimeNanos = frameTimeNanos;
 mFrameScheduled = false;
 }

 try {
 // 按优先级顺序执行回调
 mFrameInfo.markInputHandlingStart();
 doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);

 mFrameInfo.markAnimationsStart();
 doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);

 mFrameInfo.markPerformTraversalsStart();
 doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);

 doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);
 } finally {
 // 清理工作
 }
}

六、回调执行处理

1. 执行回调核心逻辑

void doCallbacks(int callbackType, long frameTimeNanos) {
 CallbackRecord callbacks;
 synchronized (mLock) {
 // 提取所有到期的回调
 final long now = frameTimeNanos / NANOS_PER_MS;
 callbacks = mCallbackQueues[callbackType].extractDueCallbacksLocked(now);
 if (callbacks == null) return;
 mCallbacksRunning = true;
 }

 try {
 // 执行链表中的所有回调
 for (CallbackRecord c = callbacks; c != null; c = c.next) {
 // 执行回调
 if (c.action instanceof Runnable) {
 ((Runnable) c.action).run();
 } else {
 ((FrameCallback) c.action).doFrame(frameTimeNanos);
 }
 }
 } finally {
 synchronized (mLock) {
 // 回收CallbackRecord对象
 recycleCallbackRecordsLocked(callbacks);
 mCallbacksRunning = false;
 }
 }
}

2.到期回调提取算法

CallbackRecord extractDueCallbacksLocked(long now) {
 CallbackRecord callbacks = null;
 CallbackRecord next = mHead;

 // 遍历链表，找出所有dueTime<=now的节点
 while (next != null && next.dueTime <= now) {
 CallbackRecord temp = next;
 next = next.next;
 temp.next = callbacks; // 新节点插入链表头部
 callbacks = temp; // 新链表头
 }

 // 更新原链表
 mHead = next;

 // 返回的是倒序链表（最近加入的先执行）
 return callbacks;
}

完整流程

[1] postCallback()
↓
[2] scheduleFrameLocked()
↓
[3] scheduleVsyncLocked()
↓
[4] mDisplayEventReceiver.scheduleVsync() (请求 Vsync)
↓
... 等待硬件 Vsync 信号 ...
↓
[5] onVsync() (native 线程回调)
↓
[6] Message msg = obtainMessage(MSG_DO_FRAME)
↓
[7] mHandler.sendMessageAtTime(msg, ...) (发送到主线程)
↓
[8] FrameHandler.handleMessage() (主线程)
↓
[9] doFrame() (主线程执行)
↓
[10] doCallbacks() (执行所有 Callback)

七、Choreographer的其他作用

1. 帧率监控

开发者可以通过postFrameCallback实现帧率监控：

public void startMonitoring() {
 Choreographer.getInstance().postFrameCallback(new FrameCallback() {
 long lastFrameTime = 0;

 @Override
 public void doFrame(long frameTimeNanos) {
 if (lastFrameTime != 0) {
 long frameInterval = (frameTimeNanos - lastFrameTime) / 1000000;
 if (frameInterval > 16) {
 // 记录掉帧情况
 }
 }
 lastFrameTime = frameTimeNanos;
 Choreographer.getInstance().postFrameCallback(this);
 }
 });
}

八、总结

Choreographer 是 Android 渲染系统的核心协调器，其工作原理可以概括为：

任务管理：通过 5 个链表队列管理不同优先级的回调任务
- 输入 > 动画 > 插入动画 > 视图遍历 > 提交

VSYNC 同步：

scheduleVsync() → DisplayEventReceiver → onVsync() → doFrame()

帧生命周期：

doFrame() →
doCallbacks(INPUT) →
doCallbacks(ANIMATION) →
doCallbacks(TRAVERSAL) →
doCallbacks(COMMIT)

性能监控：内置跳帧检测和警告机制
系统协调：作为动画系统、UI 系统、输入系统的同步中枢

整个设计体现了 Android 系统对以下关键目标的平衡：

精确性：通过 VSYNC 精准同步
高效性：链表结构和对象复用
优先级：严格的分级回调顺序
扩展性：支持多种回调类型
监控能力：内置性能检测机制

scheduleVsync() 的唯一目的就是在 VSYNC 到来时触发 doFrame()，而整个 Choreographer 的核心任务就是确保所有帧处理操作完美对齐 VSYNC 时间序列。