一次 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

一、启动 Activity 时，进程不存在会发生什么 ActivityStackSupervisor.startSpecificActivityLocked 以进程名和 uid 查询 ProcessRecord。记录存在且 app.thread 已绑定时，AMS 可以直接调用 realStartActivityLocked ,其余情况会进入 startProcessLocked 。 源码位

一、AMS.systemReady 桌面启动请求由 AMS 在 systemReady 里发出( frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java 第 11810 行附近)： startHomeActivityLocked 做的事分三件： 拼home intent、让 PMS 解

本章节目标： 用循环控制重复执行的流程 用数组或 vector 连续存放数据 用位运算拆分和重组二进制位。 三者合在一起，完成一个可运行的 Base16 编码与解码程序。 一、批量任务：用 for 驱动确定次数 1.1 初始化、条件与迭代 for 适合循环次数已知，或需要沿着下标、迭代器逐项访问数据的任务。它的括号内有三个部分：初始化只在进入循环时执行一次；条件在每轮开始前判断；迭代在循环体完成后

变量、作用域和运算符解决了“数据怎样存、表达式怎样算”，程序仍会默认按语句顺序执行。要让同一段程序面对不同数据时选择不同路径，需要能转换成 bool 的条件，也需要 if、switch 这样的控制结构。 上一章的 YUV 转换算完之后，越界的结果需要钳回 0 到 255，当时缺的正是判断。这一章从条件分支和它依赖的数据表示讲起，最后落在一个按级别过滤的日志模块上；后一个任务还会用到 std::st

C++ 里的变量不只是一个名字和一个值。它占用一段内存，类型决定这段内存的大小、其中二进制数据的含义以及可以执行的运算。它还受作用域限制，并在某个明确的时刻创建、释放。 C++ 没有垃圾回收，内存的申请和释放由代码控制，所以类型、数值、运算规则和生命周期需要放在一起理解。 一、变量定义介绍 1.1 从变量值“可改变”说起 变量用来保存程序运行期间会改变的数值。程序由数据结构和算法两部分组成，变量对