说明以 AOSP 为准类名与流程以 Android 1014 为主线。不同版本、不同厂商 ROM 会有差异例如 Android 10 起 Activity 管理从 AMS 拆分到 ATMSAndroid 8 引入 TrebleAndroid 12 起推行 GKI文中会在关键处标注版本。一、整体分层┌──────────────────────────────────────────────────────────────────┐ │ 应用层 系统应用Launcher、SystemUI、Settings 第三方应用 │ ├──────────────────────────────────────────────────────────────────┤ │ Java Framework android.* API │ │ ActivityThread / View / Handler运行在应用进程 │ │ AMS / ATMS / WMS / PMS / IMS …运行在 system_server│ ├──────────────────────────────────────────────────────────────────┤ │ Native 层 ART 运行时 · Bionic libc · libbinder · libgui · HWUI │ │ 原生守护进程surfaceflinger、audioserver、 │ │ cameraserver、servicemanager、lmkd、logd … │ ├──────────────────────────────────────────────────────────────────┤ │ HAL 层 Audio / Camera / Graphics / Sensors / Power … │ │ HIDL810→ AIDL HAL11 起逐步替代 │ ├──────────────────────────────────────────────────────────────────┤ │ Linux 内核 进程调度 · 内存管理 · 文件系统 · 驱动 │ │ Android 特有Binder、lmkd 配合的 PSI、ION/DMA-BUF、 │ │ wakelock、SELinux │ └──────────────────────────────────────────────────────────────────┘层运行在哪里主要职责应用层每个应用一个进程一个 UID业务逻辑、UIJava Framework应用进程客户端部分 system_server服务端部分四大组件管理、窗口、包、输入、权限Native 层各原生守护进程 所有进程共享的库渲染合成、音视频、运行时HAL独立的 HAL 服务进程Treble 之后屏蔽硬件差异向上提供稳定接口内核内核态资源管理、驱动、IPC 基础设施理解 Android 架构的关键在于大多数“系统功能”并不在应用进程内完成而是在 system_server 和各原生服务进程中完成应用通过 Binder 去调用它们。二、Linux 内核层Android 在通用 Linux 上加了什么机制作用说明Binder 驱动进程间通信/dev/binder框架与应用、/dev/hwbinderHIDL、/dev/vndbindervendor 内部内存回收内存紧张时杀进程早期内核 lowmemorykillerAndroid 10 起改为用户态lmkd依据 PSI内存压力和进程的oom_score_adj选择牺牲者共享内存跨进程传大块数据早期 ashmem新版本以 memfd 为主图形缓冲用 ION → DMA-BUF heapsWakelock / Suspend控制设备休眠应用层PowerManager.WakeLock最终落到内核的唤醒源SELinux强制访问控制Android 5 起全面 enforcing每个进程、文件都有安全上下文cgroups / 调度前后台资源分配前台、后台、top-app 等分组控制 CPU 与内存GKIAndroid 12 起通用内核镜像内核核心由 Google 统一维护厂商驱动以可加载模块形式提供三、HAL 层与 TrebleAndroid 8 之前Framework 直接加载厂商提供的.sohw_get_module系统升级必须等厂商重新适配。Treble 把它们拆开Android 7 及以前 Android 8 起Treble ┌───────────────┐ ┌───────────────┐ system 分区Google / 系统 │ Framework 进程 │ │ Framework 进程 │ │ dlopen 厂商 so │ └──────┬────────┘ └───────────────┘ │ HIDL / AIDL经 Binder ┌──────▼────────┐ vendor 分区芯片厂、OEM │ HAL 服务进程 │ └───────────────┘演进内容Legacy HALhw_module_t结构体 动态库同进程调用HIDLAndroid 8接口定义语言HAL 运行在独立进程通过 hwbinder 通信AIDL HALAndroid 11 起统一使用 Stable AIDL逐步替代 HIDLVINTFsystem 与 vendor 双方声明接口版本manifest / compatibility matrix保证兼容分区随之划分system、system_ext、product系统侧与vendor、odm厂商侧Android 10 起使用动态分区super。四、Native 层组件职责BionicAndroid 自己的 libc体积小、针对移动设备ARTJava/Kotlin 运行时解释执行 JIT AOTdex2oatAndroid 7 起基于 Profile 的混合编译并发复制 GClibbinderBinder 的用户态封装BpBinder代理、BBinder本地、IPCThreadState、ProcessStatelibgui / BufferQueue图形缓冲在生产者应用与消费者SurfaceFlinger之间流转HWUI应用的硬件加速渲染基于 Skia运行在应用的 RenderThread原生服务进程surfaceflinger合成、audioserver、cameraserver、mediaserver系列、servicemanager、lmkd、logd、installd、vold、netd五、启动流程从上电到桌面Boot ROM → Bootloader校验 boot 分区AVB 验证启动 → Linux Kernel初始化驱动、挂载 ramdisk → initPID 1 → Zygote → system_server → Launcher1. init阶段工作First Stage挂载基础文件系统、挂载 system / vendor 等分区SELinux Setup加载 SELinux 策略切换到正确的安全上下文Second Stage启动属性服务property_service解析init.rc及各分区下的*.rcinit.rc中声明并按触发器启动的关键服务ueventd 设备节点管理 servicemanager Binder 服务注册中心handle 0 hwservicemanager HIDL 服务注册中心 logd / lmkd / vold / netd / installd surfaceflinger zygote 由 app_process 启动64 位与 32 位可各有一个2. Zygoteapp_process → AndroidRuntime::start 创建 ART 虚拟机注册 JNI → ZygoteInit.main进入 Java 世界 preload()预加载常用类、资源、共享库 forkSystemServer()fork 出 system_server runSelectLoop()监听 /dev/socket/zygote等待创建应用进程的请求所有应用进程都由 Zygote fork 而来共享预加载的类与资源写时复制因此应用启动快、内存占用低。3. system_serverSystemServer.run() ├─ startBootstrapServices() ATMS、AMS、PowerManagerService、PackageManagerService … ├─ startCoreServices() BatteryService、UsageStatsService … ├─ startOtherServices() WindowManagerService、InputManagerService … └─ AMS.systemReady() → 启动 SystemUI → ATMS 启动 HOME ActivityLauncher各服务启动后通过ServiceManager.addService()注册应用之后通过getSystemService()拿到的就是这些服务的 Binder 代理。六、Binder贯穿全系统的 IPC1. 调用链应用进程 system_server Proxy.method() Stub.onTransact() → Parcel 序列化参数 → 反序列化参数 → BinderProxy.transact() → 执行服务方法 → IPCThreadState::transact() → 写回 reply → ioctl(BINDER_WRITE_READ) ──── 内核 Binder 驱动 ────→ 唤醒目标进程的 Binder 线程2. 设计要点要点说明一次拷贝驱动把数据从发送方拷贝到接收方通过mmap映射的缓冲区接收方直接读取身份可信驱动在每次调用中附带调用方 UID / PIDBinder.getCallingUid()权限检查以此为依据服务发现servicemanager固定为 handle 0其他服务都在这里按名字注册与查询线程池每个进程有 Binder 线程池应用默认上限约 15 个 主线程加入服务端方法在 Binder 线程中执行oneway异步调用不等待返回事务缓冲限制每进程约 1MBoneway 更少超出抛TransactionTooLargeException大数据应用共享内存传递死亡通知linkToDeath对端进程死亡时收到回调AIDL 是生成 Proxy / Stub 代码的工具HIDL / AIDL HAL 也基于同一套驱动只是使用不同的设备节点。七、应用进程内部结构应用进程由 Zygote fork ├─ 主线程ActivityThread.main() │ Looper.prepareMainLooper() → MessageQueue → Handler内部类 H 分发生命周期消息 │ 负责组件生命周期回调、View 测量/布局/绘制、输入事件分发 ├─ RenderThreadHWUI 把绘制指令转为 GPU 命令提交图形缓冲 ├─ Binder 线程池接收 system_server 的回调ApplicationThread └─ 其他GC 线程、JIT 线程、业务线程关键对象作用ActivityThread应用进程的“主控”管理所有组件ApplicationThread应用暴露给系统的 Binder 接口system_server 通过它下发指令Instrumentation组件创建与生命周期调用的统一入口ContextImplContext 的真正实现getSystemService等由它完成八、Activity 启动流程冷启动① Launcher 点击图标 Activity.startActivity → Instrumentation.execStartActivity → ATMS.startActivityBinder ② system_serverATMS ActivityStarter解析 Intent、检查权限、确定任务栈 发现目标进程不存在 → AMS.startProcessLocked ③ 创建进程 ZygoteProcess 通过 socket 向 Zygote 发送请求 → Zygote fork → 新进程执行 ActivityThread.main() ④ 应用进程向系统报到 ActivityThread.attach → AMS.attachApplication(ApplicationThread) ⑤ 系统回调应用 ApplicationThread.bindApplication → 创建 Application调用 onCreate ATMS 下发 ClientTransactionLaunchActivityItem ResumeActivityItem ⑥ 应用执行生命周期 performLaunchActivity反射创建 Activity → attach创建 PhoneWindow→ onCreate → onStart handleResumeActivityonResume → WindowManager.addView(DecorView) ⑦ 添加窗口并首帧绘制 ViewRootImpl.setView → WMS.addWindow获得 Surface Choreographer 收到 VSYNC → measure / layout / draw RenderThread 提交缓冲 → SurfaceFlinger 合成 → 屏幕显示热启动时进程已存在跳过 ③⑤直接从 ATMS 下发 Transaction 开始。九、显示链路一帧如何上屏应用进程 SurfaceFlinger 硬件 VSYNC-app 信号 → Choreographer.doFrame 输入 → 动画 → measure/layout/draw主线程生成 DisplayList → RenderThread 同步 DisplayList → Skia/GPU 绘制 dequeueBuffer / queueBuffer ──→ BufferQueue VSYNC-sf 信号 收集各图层最新缓冲 交给 HWC 决定合成方式 ──→ HWC硬件叠加 必要时用 GPU 合成 / GPU 合成 → Display 扫描输出角色职责WMS管理窗口的层级、尺寸、可见性、焦点“窗口应该在哪里”SurfaceFlinger把所有图层合成为最终画面“画面如何拼起来”HWC HAL硬件合成器尽量用叠加层代替 GPU 合成以省电BufferQueue生产者-消费者缓冲队列通常为三缓冲主线程或 RenderThread 在一个 VSYNC 周期内未完成工作就会掉帧。十、输入链路一次触摸如何到达 View触摸屏驱动 → /dev/input/eventX → system_serverInputReader读取、加工原始事件 → InputDispatcher根据 WMS 提供的窗口信息找到目标窗口 → InputChannelsocket pair发送到应用进程 → ViewRootImpl 的 InputEventReceiver → DecorView → Activity.dispatchTouchEvent → ViewGroup → View.onTouchEvent → 处理完成后回执 InputDispatcherInputDispatcher 等待回执超过约 5 秒触发输入 ANR。十一、进程管理与内存机制说明进程优先级AMS 根据组件状态计算oom_score_adj前台 Activity 可见 前台服务 服务 缓存进程回收lmkd 监测内存压力从优先级最低数值最大的进程开始杀ANR主线程在规定时间内未响应输入约 5s、前台广播约 10s、前台服务约 20s后台限制Android 8 起限制后台服务后续版本增加待机分桶App Standby Buckets、前台服务类型声明等十二、安全模型层面机制进程隔离每个应用独立 UID私有目录/data/data/包名仅本 UID 可访问强制访问控制SELinux即使是 root 进程也只能做策略允许的事系统调用过滤seccomp 限制应用可用的系统调用权限安装时权限 运行时权限Android 6 起服务端用checkCallingPermission基于 Binder 调用方 UID 校验存储分区存储Android 10/11 起限制应用访问共享存储启动安全AVB 验证启动 dm-verity保证系统分区未被篡改可更新组件Project MainlineAndroid 10 起部分系统模块以 APEX / APK 形式独立更新十三、问题定位现象对应到哪一层现象主要涉及的层与组件启动慢Zygote fork、Application.onCreate、ATMS 调度、首帧绘制卡顿掉帧主线程 / RenderThread、Choreographer、SurfaceFlingerANR主线程阻塞、Binder 调用等待 system_server、InputDispatcher 超时后台被杀AMS 优先级计算、lmkdTransactionTooLargeExceptionBinder 事务缓冲硬件功能异常HAL 服务进程、vendor 驱动权限拒绝Framework 权限检查、SELinuxavc: denied日志常用工具adb shell dumpsysactivity / window / meminfo / gfxinfo、Perfetto / Systrace、logcat、ps -A、service list。总结Android 是一个以 Binder 为骨架的多进程系统内核提供调度、内存、驱动并加入 Binder、lmkd、SELinux 等移动端机制HAL通过 Treble 与系统解耦以独立进程提供硬件能力init → Zygote → system_server完成启动Zygote 孵化所有应用进程system_server 承载 AMS、WMS、PMS 等核心服务应用进程以主线程消息循环驱动生命周期与 UI通过 Binder 请求系统服务通过 BufferQueue 把画面交给 SurfaceFlinger 合成上屏。掌握“启动链、Binder 调用链、Activity 启动链、显示链、输入链”这五条路径就能把绝大多数系统行为和问题定位到具体的进程与组件。
说明以 AOSP 为准类名与流程以 Android 1014 为主线。不同版本、不同厂商 ROM 会有差异例如 Android 10 起 Activity 管理从 AMS 拆分到 ATMSAndroid 8 引入 TrebleAndroid 12 起推行 GKI文中会在关键处标注版本。一、整体分层┌──────────────────────────────────────────────────────────────────┐ │ 应用层 系统应用Launcher、SystemUI、Settings 第三方应用 │ ├──────────────────────────────────────────────────────────────────┤ │ Java Framework android.* API │ │ ActivityThread / View / Handler运行在应用进程 │ │ AMS / ATMS / WMS / PMS / IMS …运行在 system_server│ ├──────────────────────────────────────────────────────────────────┤ │ Native 层 ART 运行时 · Bionic libc · libbinder · libgui · HWUI │ │ 原生守护进程surfaceflinger、audioserver、 │ │ cameraserver、servicemanager、lmkd、logd … │ ├──────────────────────────────────────────────────────────────────┤ │ HAL 层 Audio / Camera / Graphics / Sensors / Power … │ │ HIDL810→ AIDL HAL11 起逐步替代 │ ├──────────────────────────────────────────────────────────────────┤ │ Linux 内核 进程调度 · 内存管理 · 文件系统 · 驱动 │ │ Android 特有Binder、lmkd 配合的 PSI、ION/DMA-BUF、 │ │ wakelock、SELinux │ └──────────────────────────────────────────────────────────────────┘层运行在哪里主要职责应用层每个应用一个进程一个 UID业务逻辑、UIJava Framework应用进程客户端部分 system_server服务端部分四大组件管理、窗口、包、输入、权限Native 层各原生守护进程 所有进程共享的库渲染合成、音视频、运行时HAL独立的 HAL 服务进程Treble 之后屏蔽硬件差异向上提供稳定接口内核内核态资源管理、驱动、IPC 基础设施理解 Android 架构的关键在于大多数“系统功能”并不在应用进程内完成而是在 system_server 和各原生服务进程中完成应用通过 Binder 去调用它们。二、Linux 内核层Android 在通用 Linux 上加了什么机制作用说明Binder 驱动进程间通信/dev/binder框架与应用、/dev/hwbinderHIDL、/dev/vndbindervendor 内部内存回收内存紧张时杀进程早期内核 lowmemorykillerAndroid 10 起改为用户态lmkd依据 PSI内存压力和进程的oom_score_adj选择牺牲者共享内存跨进程传大块数据早期 ashmem新版本以 memfd 为主图形缓冲用 ION → DMA-BUF heapsWakelock / Suspend控制设备休眠应用层PowerManager.WakeLock最终落到内核的唤醒源SELinux强制访问控制Android 5 起全面 enforcing每个进程、文件都有安全上下文cgroups / 调度前后台资源分配前台、后台、top-app 等分组控制 CPU 与内存GKIAndroid 12 起通用内核镜像内核核心由 Google 统一维护厂商驱动以可加载模块形式提供三、HAL 层与 TrebleAndroid 8 之前Framework 直接加载厂商提供的.sohw_get_module系统升级必须等厂商重新适配。Treble 把它们拆开Android 7 及以前 Android 8 起Treble ┌───────────────┐ ┌───────────────┐ system 分区Google / 系统 │ Framework 进程 │ │ Framework 进程 │ │ dlopen 厂商 so │ └──────┬────────┘ └───────────────┘ │ HIDL / AIDL经 Binder ┌──────▼────────┐ vendor 分区芯片厂、OEM │ HAL 服务进程 │ └───────────────┘演进内容Legacy HALhw_module_t结构体 动态库同进程调用HIDLAndroid 8接口定义语言HAL 运行在独立进程通过 hwbinder 通信AIDL HALAndroid 11 起统一使用 Stable AIDL逐步替代 HIDLVINTFsystem 与 vendor 双方声明接口版本manifest / compatibility matrix保证兼容分区随之划分system、system_ext、product系统侧与vendor、odm厂商侧Android 10 起使用动态分区super。四、Native 层组件职责BionicAndroid 自己的 libc体积小、针对移动设备ARTJava/Kotlin 运行时解释执行 JIT AOTdex2oatAndroid 7 起基于 Profile 的混合编译并发复制 GClibbinderBinder 的用户态封装BpBinder代理、BBinder本地、IPCThreadState、ProcessStatelibgui / BufferQueue图形缓冲在生产者应用与消费者SurfaceFlinger之间流转HWUI应用的硬件加速渲染基于 Skia运行在应用的 RenderThread原生服务进程surfaceflinger合成、audioserver、cameraserver、mediaserver系列、servicemanager、lmkd、logd、installd、vold、netd五、启动流程从上电到桌面Boot ROM → Bootloader校验 boot 分区AVB 验证启动 → Linux Kernel初始化驱动、挂载 ramdisk → initPID 1 → Zygote → system_server → Launcher1. init阶段工作First Stage挂载基础文件系统、挂载 system / vendor 等分区SELinux Setup加载 SELinux 策略切换到正确的安全上下文Second Stage启动属性服务property_service解析init.rc及各分区下的*.rcinit.rc中声明并按触发器启动的关键服务ueventd 设备节点管理 servicemanager Binder 服务注册中心handle 0 hwservicemanager HIDL 服务注册中心 logd / lmkd / vold / netd / installd surfaceflinger zygote 由 app_process 启动64 位与 32 位可各有一个2. Zygoteapp_process → AndroidRuntime::start 创建 ART 虚拟机注册 JNI → ZygoteInit.main进入 Java 世界 preload()预加载常用类、资源、共享库 forkSystemServer()fork 出 system_server runSelectLoop()监听 /dev/socket/zygote等待创建应用进程的请求所有应用进程都由 Zygote fork 而来共享预加载的类与资源写时复制因此应用启动快、内存占用低。3. system_serverSystemServer.run() ├─ startBootstrapServices() ATMS、AMS、PowerManagerService、PackageManagerService … ├─ startCoreServices() BatteryService、UsageStatsService … ├─ startOtherServices() WindowManagerService、InputManagerService … └─ AMS.systemReady() → 启动 SystemUI → ATMS 启动 HOME ActivityLauncher各服务启动后通过ServiceManager.addService()注册应用之后通过getSystemService()拿到的就是这些服务的 Binder 代理。六、Binder贯穿全系统的 IPC1. 调用链应用进程 system_server Proxy.method() Stub.onTransact() → Parcel 序列化参数 → 反序列化参数 → BinderProxy.transact() → 执行服务方法 → IPCThreadState::transact() → 写回 reply → ioctl(BINDER_WRITE_READ) ──── 内核 Binder 驱动 ────→ 唤醒目标进程的 Binder 线程2. 设计要点要点说明一次拷贝驱动把数据从发送方拷贝到接收方通过mmap映射的缓冲区接收方直接读取身份可信驱动在每次调用中附带调用方 UID / PIDBinder.getCallingUid()权限检查以此为依据服务发现servicemanager固定为 handle 0其他服务都在这里按名字注册与查询线程池每个进程有 Binder 线程池应用默认上限约 15 个 主线程加入服务端方法在 Binder 线程中执行oneway异步调用不等待返回事务缓冲限制每进程约 1MBoneway 更少超出抛TransactionTooLargeException大数据应用共享内存传递死亡通知linkToDeath对端进程死亡时收到回调AIDL 是生成 Proxy / Stub 代码的工具HIDL / AIDL HAL 也基于同一套驱动只是使用不同的设备节点。七、应用进程内部结构应用进程由 Zygote fork ├─ 主线程ActivityThread.main() │ Looper.prepareMainLooper() → MessageQueue → Handler内部类 H 分发生命周期消息 │ 负责组件生命周期回调、View 测量/布局/绘制、输入事件分发 ├─ RenderThreadHWUI 把绘制指令转为 GPU 命令提交图形缓冲 ├─ Binder 线程池接收 system_server 的回调ApplicationThread └─ 其他GC 线程、JIT 线程、业务线程关键对象作用ActivityThread应用进程的“主控”管理所有组件ApplicationThread应用暴露给系统的 Binder 接口system_server 通过它下发指令Instrumentation组件创建与生命周期调用的统一入口ContextImplContext 的真正实现getSystemService等由它完成八、Activity 启动流程冷启动① Launcher 点击图标 Activity.startActivity → Instrumentation.execStartActivity → ATMS.startActivityBinder ② system_serverATMS ActivityStarter解析 Intent、检查权限、确定任务栈 发现目标进程不存在 → AMS.startProcessLocked ③ 创建进程 ZygoteProcess 通过 socket 向 Zygote 发送请求 → Zygote fork → 新进程执行 ActivityThread.main() ④ 应用进程向系统报到 ActivityThread.attach → AMS.attachApplication(ApplicationThread) ⑤ 系统回调应用 ApplicationThread.bindApplication → 创建 Application调用 onCreate ATMS 下发 ClientTransactionLaunchActivityItem ResumeActivityItem ⑥ 应用执行生命周期 performLaunchActivity反射创建 Activity → attach创建 PhoneWindow→ onCreate → onStart handleResumeActivityonResume → WindowManager.addView(DecorView) ⑦ 添加窗口并首帧绘制 ViewRootImpl.setView → WMS.addWindow获得 Surface Choreographer 收到 VSYNC → measure / layout / draw RenderThread 提交缓冲 → SurfaceFlinger 合成 → 屏幕显示热启动时进程已存在跳过 ③⑤直接从 ATMS 下发 Transaction 开始。九、显示链路一帧如何上屏应用进程 SurfaceFlinger 硬件 VSYNC-app 信号 → Choreographer.doFrame 输入 → 动画 → measure/layout/draw主线程生成 DisplayList → RenderThread 同步 DisplayList → Skia/GPU 绘制 dequeueBuffer / queueBuffer ──→ BufferQueue VSYNC-sf 信号 收集各图层最新缓冲 交给 HWC 决定合成方式 ──→ HWC硬件叠加 必要时用 GPU 合成 / GPU 合成 → Display 扫描输出角色职责WMS管理窗口的层级、尺寸、可见性、焦点“窗口应该在哪里”SurfaceFlinger把所有图层合成为最终画面“画面如何拼起来”HWC HAL硬件合成器尽量用叠加层代替 GPU 合成以省电BufferQueue生产者-消费者缓冲队列通常为三缓冲主线程或 RenderThread 在一个 VSYNC 周期内未完成工作就会掉帧。十、输入链路一次触摸如何到达 View触摸屏驱动 → /dev/input/eventX → system_serverInputReader读取、加工原始事件 → InputDispatcher根据 WMS 提供的窗口信息找到目标窗口 → InputChannelsocket pair发送到应用进程 → ViewRootImpl 的 InputEventReceiver → DecorView → Activity.dispatchTouchEvent → ViewGroup → View.onTouchEvent → 处理完成后回执 InputDispatcherInputDispatcher 等待回执超过约 5 秒触发输入 ANR。十一、进程管理与内存机制说明进程优先级AMS 根据组件状态计算oom_score_adj前台 Activity 可见 前台服务 服务 缓存进程回收lmkd 监测内存压力从优先级最低数值最大的进程开始杀ANR主线程在规定时间内未响应输入约 5s、前台广播约 10s、前台服务约 20s后台限制Android 8 起限制后台服务后续版本增加待机分桶App Standby Buckets、前台服务类型声明等十二、安全模型层面机制进程隔离每个应用独立 UID私有目录/data/data/包名仅本 UID 可访问强制访问控制SELinux即使是 root 进程也只能做策略允许的事系统调用过滤seccomp 限制应用可用的系统调用权限安装时权限 运行时权限Android 6 起服务端用checkCallingPermission基于 Binder 调用方 UID 校验存储分区存储Android 10/11 起限制应用访问共享存储启动安全AVB 验证启动 dm-verity保证系统分区未被篡改可更新组件Project MainlineAndroid 10 起部分系统模块以 APEX / APK 形式独立更新十三、问题定位现象对应到哪一层现象主要涉及的层与组件启动慢Zygote fork、Application.onCreate、ATMS 调度、首帧绘制卡顿掉帧主线程 / RenderThread、Choreographer、SurfaceFlingerANR主线程阻塞、Binder 调用等待 system_server、InputDispatcher 超时后台被杀AMS 优先级计算、lmkdTransactionTooLargeExceptionBinder 事务缓冲硬件功能异常HAL 服务进程、vendor 驱动权限拒绝Framework 权限检查、SELinuxavc: denied日志常用工具adb shell dumpsysactivity / window / meminfo / gfxinfo、Perfetto / Systrace、logcat、ps -A、service list。总结Android 是一个以 Binder 为骨架的多进程系统内核提供调度、内存、驱动并加入 Binder、lmkd、SELinux 等移动端机制HAL通过 Treble 与系统解耦以独立进程提供硬件能力init → Zygote → system_server完成启动Zygote 孵化所有应用进程system_server 承载 AMS、WMS、PMS 等核心服务应用进程以主线程消息循环驱动生命周期与 UI通过 Binder 请求系统服务通过 BufferQueue 把画面交给 SurfaceFlinger 合成上屏。掌握“启动链、Binder 调用链、Activity 启动链、显示链、输入链”这五条路径就能把绝大多数系统行为和问题定位到具体的进程与组件。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
