要深入理解 Zygote 到底给每个 App “遗传”了什么,我们需要从内存的物理分布和代码的预加载逻辑来看。
Zygote 就像一个预先搭建好的“精装房”,App 搬进去时,家具(系统类、资源)都已经摆好了。
1. Zygote 预加载的“重量级”资源
在 Android 源码的 ZygoteInit.java 中,有两个核心方法定义了共享内容:
A. 预加载类 (Preloaded Classes)
Zygote 会加载约 3000~5000 个核心 Java 类。
- 内容:包括 java.lang.*、android.app.*、android.view.*、android.widget.* 等。
- 存储:这些类被加载进内存后,其对应的映射关系存在于 线性分配区 (LinearAlloc)。
- 共享效果:当你新建一个 TextView 时,系统不需要去磁盘找 TextView.class,它已经在内存里等着你了。
B. 预加载资源 (Preloaded Resources)
- 内容:系统级别的图片(如 Checkbox 的勾选框、ProgressBar 的转圈动画)、布局文件以及系统颜色定义(framework-res.apk 中的内容)。
- 共享效果:所有 App 使用的系统原生图标,在物理内存中其实只有一份。
2. 内存视图:物理内存 vs 虚拟内存
理解资源共享的关键在于 内存页(Memory Pages)。
- Clean Pages (干净页):Zygote 加载的只读代码段(.text)和预加载资源。这些页在所有 App 进程中完全共享,不占额外的物理内存。
- Dirty Pages (脏页):App 运行后自己创建的对象(如你的全局变量、Bitmap)。这些是每个进程私有的。
3. 如何通过工具观察这种“共享”?
如果你有 root 权限,可以在终端通过 procrank 命令查看一个进程的内存占用,你会发现三个关键指标:
- VSS (Virtual Set Size):虚拟耗用内存(包含共享库占用的全部内存,数值最大,参考意义小)。
- RSS (Resident Set Size):实际使用物理内存(包含共享库占用的全部内存,会被重复计算)。
- PSS (Proportional Set Size):比例分配内存(最科学指标)。
- 原理:如果有 10 个进程共享 Zygote 的 100MB 资源,那么每个 App 的 PSS 只会计算其中的 10MB。
4. UID/GID 权限的“遗传”与隔离
在 fork 的瞬间,子进程继承了 Zygote 的所有权限,但紧接着 Zygote 会执行 NativeSpecializeAppProcess:
- 身份切换:调用 Linux 系统调用 setresuid(uid, uid, uid)。
- 能力封印 (Capabilities):清除不必要的 Root 能力,只保留该 UID 对应的权限。
- SELinux 赋能:根据 App 的包名分配 SELinux 标签(如 u:r:untrusted_app:s0),即使 UID 逃逸,SELinux 也会在内核层限制其访问系统文件。
5. 总结:这种架构的优缺点
|
维度
|
优势
|
劣势
|
|
性能
|
秒级启动,省去了 JVM 初始化和类加载时间。
|
Zygote 进程如果崩溃,整个 Android 用户界面都会重启。
|
|
内存
|
极大地提高了多任务并行的能力,节省约 30% 以上内存。
|
预加载列表过长会导致系统开机变慢。
|
|
安全
|
严格的 UID 隔离,确保 App 互不干扰。
|
如果 Zygote 存在漏洞,所有子进程都可能受到威胁。
|
498

被折叠的 条评论
为什么被折叠?



