一帧画面为什么要等 VSync？requestLayout 发起布局请求后，App 如何申请下一个信号，SurfaceFlinger 又如何把它送回 App 主线程？这条链路横跨 Java、JNI、Binder、Unix socket 与 Looper。 一、VSync 要解决的问题：为什么不能想画就画 1.1 一次 requestLayout 到一次真正上屏 requestLayout

InputDispatcher 已经选中目标窗口，并把触摸事件写进对应的 socket。应用进程此时没有主动向系统轮询，它怎么及时接住事件，又怎么把一个 native 消息送到 Java 的 View 树？另一个常见疑问是：上层窗口没有消费事件，系统能否把同一事件继续交给下层窗口？ 应用侧的完整链路由注册、监听、读取和分发组成。ViewRootImpl.setView 通过 WindowSessi

Q：一次手指触摸屏幕，产生的 MotionEvent 怎样从内核输入设备文件到达 View.dispatchTouchEvent？应用在原窗口上覆盖一个全屏窗口，能否由上层窗口接收触摸，再把事件交给下面的窗口？ A：输入链路是一条由系统侧控制的单向流水线。EventHub 从 /dev/input 读取原始事件，InputReader 将其解释成设备无关的 NotifyMotionArgs，Inp

本文整理自 corpus 仓库中的以下三集课程： 本文源码基准为 AOSP android-6.0.0_r1。一次 ContentResolver.insert 看上去是普通的方法调用，开始数据操作前，客户端却要先取得一个 IContentProvider。这个接口可能指向本进程对象，也可能是另一个进程中 ContentProvider 的 Binder 代理。 代理的取得过程由客户端两级缓存

一次广播从应用发出后，系统怎样找到接收者，又怎样把调用送回 onReceive？动态注册和 manifest 静态声明使用不同的收集路径，却会在 AMS 的分发阶段汇合。本文沿注册、入队、投递与完成回调追踪对象和状态的变化，并说明静态接收者为何依赖目标进程的创建与 attach。全文源码以 AOSP android-6.0.0_r1 为基准。 一、一次广播的两个入口：注册与发送 1.1 示例里的三

一次 bindService 会跨过客户端、systemserver 和 Service 进程。Java 层传出的对象先写成传输结构，Binder 驱动再为目标进程建立引用。客户端提交的是 BINDERTYPEBINDER，其中保存对象地址与 cookie；驱动为目标进程建立 binderref、分配 handle，接收方此后凭 handle 发起调用。回调返回原进程时，cookie 保存的本进程

startService 和 bindService 表面上对应两套 API，进入 Framework 后却共享了大半条启动链。两者都从调用方进程进入 ContextImpl，经 Binder 到达 system_server 中的 ActivityManagerService（下文简称 AMS），由 ActiveServices 查找或创建 ServiceRecord，再把生命周期调用投

本文依据 corpus 仓库中的四段录屏整理，内容覆盖桌面入口、前一个 Activity 的暂停、目标进程判定，以及新 Activity 的创建与显示。 上一篇《Android-Framework（十五）-进程的 fork 创建过程》已经分析 startSpecificActivityLocked 到 Zygote fork、ActivityThread.main 、attachApplic