gradle/booster 在编译器处理资源文件
SPISPI 全称 Service Provider Interface，是 Java/Android 内置于标准库里的一个 服务发现 机制 ServiceLoader // 1）准备接口及相关实现 package work.dalvik.binder.myapplication interface ISimpleInterface { val name: String &#
Binder IPC 内存模型
指导思想进程 A 通过 binder_transaction 往进程 B 传输数据的过程，其中步骤 4、5、6 和 7 是一页一页地循环执行: 准备需要发送的数据, 数据存放在进程 A 的用户空间中 进程 A 通过系统调用进入 binder driver 的代码逻辑中 在 binder driver 代码中, 找到与所发送数据大小匹配的进程 B 的 binder_buffer, 该 buff
Binder IPC 线程调度模型
主线程与普通线程Binder 线程可以分为两类：主线程 和 普通线程，它们的区别是： 主线程名称为 Binder_1 or Binder:<pid>_1，普通线程则从 2 开始（ProcessState::makeBinderThreadName） 主线程在应用进程起来后立刻启动，且不会退出；普通线程由 BR_SPAWN_LOOPER 启动且会被 binder driver 命令
Binder IPC 过程中常用的对象和类
Summary client 端BpBinder client native proxy，客户端 native 层的 binder ipc 代理（IBinder），它最重要的是持有 server 端句柄 handle，handle == 0 表示 service manager，其他的需要通过 service manager 查询得到，参看 AMS的例子 // BpBindere 会直接用 s
深入 Binder 之 servicemanager 进程
主例程servicemanager 进程是由 init 进程通过 servicemanager.rc 配置文件启动的，其所在的可执行文件在 system/bin/servicemanager，对应的源文件是 /platform/frameworks/native/cmds/servicemanager/main.cpp service servicemanager /system/bin/serv
深入 Binder 之架构篇
学习 binder 我感觉得从上到下：先对 binder 架构/理论有个大概的认识、对 binder 里的数据结构有个印象，再深入代码细节；整个 binder 涉及到应用侧和驱动侧、app 侧和 framework 侧、java 层和 native 层，代码量巨大而且跨度很大，只有对整个 binder 架构有清晰的认识才不会迷失在细节里 Linux 设备 linux 系统将设备分为3类：字符设备、
深入 Binder 之 AIDL
应用层从 AIDL 说起，AIDL 全称 Android Interface Definition Language，是一个用以描述/定义 接口 的文本文件，有着与 java 类似的简单语法 下面是一个非常简单的 AIDL 文件，位于 {projectPath}/app/src/main/aidl/work/dalvik/binder/example/IAidlExampleI
MMKV - 高效的本地 Key-Value 存储
mmapmmap 在进程的虚拟地址空间开辟一块区域，这块区域映射文件在磁盘上的物理地址，是将内存地址空间映射到磁盘地址空间的一种方法 读/写操作访问虚拟地址空间这一段映射地址，通过查询页表发现这一段地址并不在物理页面上（因为目前只建立了地址映射，真正的硬盘数据还没有拷贝到内存中），因此引发缺页异常，内核发起请求调页过程。调页过程先在交换缓存空间（swap cache）中寻找需要访问的内存页，如果没