Surface 是一块内存吗？从 Java 层的使用方式看，lockCanvas 像是直接锁定一块画布。底层对象关系却显示，Surface 并不对应一块固定内存。它持有 IGraphicBufferProducer（下文简称 IGBP），也就是 GraphicBuffer 生产者的远程 Binder 对象。 App 进程里的 Surface、Canvas 和 SkBitmap 负责申请缓冲区并

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

在 onDraw 里画完的东西不会立刻出现在屏幕上。这不是 Android 故意拖慢刷新，而是因为“画进内存”和“显示到屏幕”本来就是两件事：App 先把像素写进一块 Buffer，再把它交出去；SurfaceFlinger 等到合适的刷新时刻，合成各个窗口的 Buffer，最后才把结果送给显示硬件。 这条链路真正的节拍器是 Vsync，即垂直同步信号。对 60Hz 屏幕来说，它约每 16.6

本文整理自 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