一、Android 系统架构

谷歌 Android 官方链接

1. APP层：系统应用和其它APP
2. Framework层：提供服务和API，开发者调用交互。

• 包括四大组件 Activity（用户界面交互）、Service（后台操作）、Content Provider（应用间数据共享）、Broadcast Receiver​​（响应系统或应用广播的消息）
• 一系列系统服务管理器如 ActivityManager（管理应用生命周期和任务栈）、PackageManager（管理应用安装和权限）、WindowManager、LocationManager、NotificationManager等

3. Native层：提供核心的c库和java运行环境。

• 本地库如 OpenGL图形渲染、SQLite数据库、Webkit浏览器内核
• ServiceManager、libc
• ART虚拟机：孵化进程

4. HAL硬件抽象层：提供硬件驱动（相机/传感器）的标准接口
5. Kernel层：硬件驱动（相机/蓝牙/音频）和核心服务（进程/内存管理/网络现协议）

• 系统服务和应用组件通过Binder IPC实现跨进程通信。

二、Android 系统启动原理

启动流程：

1. Bootloader阶段：设备启动时运行的第一个程序，初始化硬件设备、设置内存、加载内核镜像等。加载 Linux 内核。

2. Linux内核启动：内核初始化进程管理、内存管理、设备驱动等核心功能。挂载根文件系统（rootfs），并启动 Init 进程。

3. Init进程启动：Android 系统中第一个用户空间进程，负责启动其他系统服务，如Zygote进程。

4. Zygote进程启动：Android 系统启动时创建的第一个 Java 进程，负责预加载常用类和应用资源​​。启动后会监听 Socket 请求，当需要启动新应用时，它会通过 fork 自身来创建新的应用进程。启动 System Server 进程。

5. System Server进程启动：Android 系统的核心服务进程。负责启动和管理所有系统服务，如ActivityManagerService、PackageManagerService、WindowManagerService。通过 Binder机制向 APP 提供系统服务接口，如通过context.getSystemService() 调用获取。

6. Launcher进程启动：SystemServer启动完成后，会通知AMS启动桌面应用 Launcher（用户与设备交互的入口，负责显示应用图标和管理用户界面）。

7. APP进程启动：当用户点击应用图标时，Launcher会向AMS发送启动请求。AMS会检查应用进程是否存在，如果不存在则通过zygote创建新进程。新进程会加载应用代码和资源，最终显示用户界面。

核心脚本文件

1. init.rc：定义系统服务的启动顺序和依赖关系。
2. zygote.rc：配置zygote进程的启动参数。
3. SystemServer.java：包含System Server的核心逻辑。
4. ActivityManagerService.java：管理应用生命周期和任务栈，处理系统广播。

三、APP 启动原理

1. 点击 APP 图标：Launcher（桌面应用）通过startActivity()发起启动请求。该请求通过 Binder 传递到 AMS
2. AMS 收到启动请求：检查目标应用的 AndroidManifest.xml，验证Activity是否存在以及权限等（依赖PMS的包信息查询）。若应用未运行，AMS 通过 socket 通信通知 Zygote。
3. Zygote 进程孵化新应用进程：通过fork()快速创建新进程。新进程继承Zygote 的虚拟机实例，加载目标应用的 APK 和 DEX 文件。
4. APP 进程初始化：新进程创建后，执行ActivityThread.main()作为入口点：
   1. 初始化主线程 Looper，绑定 ApplicationThread（Binder接口）与 AMS 通信。
   2. 调用 attachApplication() 通知 AMS 进程已就绪，AMS 发送bindApplication 指令，触发应用级初始化（创建Application对象，执行onCreate()；加载ContentProvider并初始化）
5. Activity 创建与显示：AMS 通过 Binder 发送 scheduleLaunchActivity 到应用进程，主线程处理消息并执行：
   1. 创建目标 Activity 实例，调用onCreate()、onStart() 和 onResume()。
   2. WMS 接管界面渲染（创建DecorView并添加到Window；触发ViewRootImpl执行测量、布局、绘制，通过SurfaceFlinger合成显示）

四、进程数量关系

• Binder驱动：1个（内核模块）
  • SystemServer与AMS/PMS/WMS之间通过Binder进行线程间通信
  • 应用进程与系统服务通过Binder IPC交互
  • ServiceManager通过Binder维护服务注册表
• ServiceManager进程：1个（独立守护进程）。作为Binder机制的"DNS服务器"，记录所有系统服务的Binder引用，但本身不参与业务逻辑处理。
• Init进程：1个（PID=1）
• Zygote进程：1-2个（主Zygote + 可选Zygote_64）
• SystemServer进程：1个（由主Zygote孵化）
• 核心服务：多个（作为SystemServer线程运行）
  • AMS负责四大组件生命周期管理
  • PMS处理应用安装与权限管理
  • WMS管理窗口层级与输入事件

五、AIDL 通信原理

AIDL（Android Interface Definition Language）是Android中用于跨进程通信（IPC）的接口定义语言。
它允许不同进程间的对象通过Binder机制进行交互，核心作用是将接口定义转化为可跨进程调用的代码。
编译AIDL文件时，编译器会自动生成Java代码，包含以下关键类：

• Stub类：继承Binder并实现AIDL接口，作为服务端的基类。
• Proxy类：客户端代理，封装跨进程调用逻辑，通过transact()方法向服务端发送数据。

// 自动生成的Stub类（服务端）  
public static abstract class Stub extends Binder implements IMyService {  
    @Override  
    public boolean onTransact(int code, Parcel data, Parcel reply, int flags) {  
        // 解析请求并调用实际方法  
    }  
}  

// 自动生成的Proxy类（客户端）  
private static class Proxy implements IMyService {  
    private IBinder mRemote;  
    @Override  
    public void doAction() {  
        Parcel data = Parcel.obtain();  
        mRemote.transact(TRANSACTION_doAction, data, null, FLAG_ONEWAY);  
    }  
}