Android 11 SystemServer源码解析：开机启动与服务管理

拿到Android 11的SystemServer源码，说实话第一感觉不是“哇，好大一个类”，而是“这玩意儿到底在开机的时候干了多少事”。SystemServer是Android系统里进程优先级极高、职责也极重的常驻进程，它承载了几乎所有框架层核心服务：ActivityManagerService、PackageManagerService、WindowManagerService、InputManagerService，还有电源、网络、存储、账户、通知，加起来几十上百个服务。读这个进程的启动逻辑，本质上就是在回答一个问题：一部手机从内核启动、孵化出 zygote 之后，系统是怎么一步一步变成你能解锁、能装应用、能刷短视频的那个状态的。

这篇文章不是把源码逐行翻译一遍，而是带着“为什么要这样设计”的视角，把SystemServer的入口逻辑、服务分类、启动时序、线程模型、常见坑位梳理清楚。目标是让刚接触framework层的人能顺着代码找到自己的路，也让有一定经验的人重新审视那些“平时没细想”的细节。如果你打算做系统定制、性能优化、开机耗时分析，或者只是想把AOSP源码啃得更深入一点，这篇文章值得耐心读一遍。

1. SystemServer在整个启动链路中的定位与设计理念

1.1 它到底处在什么位置

Android系统的启动，粗线条讲是这么一条链路：bootloader加载Linux内核，内核拉起第一个用户态进程init，init解析init.rc，把zygote进程启动起来，zygote再fork出SystemServer进程。注意这个fork时机很关键，zygote在启动Java运行环境之后、开始接收应用进程创建请求之前，就先把SystemServer给“生”出来了。也就是说，SystemServer不是像普通应用一样通过AMS去创建，而是由zygote直接用fork的方式孵化，所以它天然继承了zygote预加载好的所有系统类库和资源，启动速度特别快，同时它也拿到了一个非常特殊的身份——系统的第一个Java进程，也是所有后续应用进程的“老大哥”。

在Android 11里，SystemServer进程的名字就叫system_server，UID是System，进程号通常是1号用户态进程里靠前的那个。它的地位不仅体现在权限上，更体现在系统对它“绝不能死”的这个隐含要求上。一旦system_server进程崩溃或者被Watchdog杀掉，整个系统会进入重启流程，而且往往不是简单重启一个进程，而是要从zygote层面重新拉起整套用户空间，现象就是用户看到手机直接重启，或者是停留在开机动画很久。

1.2 为什么所有服务都塞进一个进程

不少刚开始读源码的人会问：为什么Android不把每个系统服务都做成独立进程，服务之间互相隔离，某个服务挂了也不影响别人？这个问题背后其实是一个架构取舍。SystemServer选择“进程内多服务”的核心原因是Binder跨进程通信的成本太高，如果AMS、PMS、WMS各自一个进程，每次调用都要做一次完整Binder事务，包括数据序列化、内存拷贝、线程调度，那系统响应根本扛不住。把这些高频服务集中在同一个进程里，服务之间可以直接调用Java方法，共享内存和对象引用，性能上非常划算。

代价就是SystemServer内部必须严格管理线程和锁，任何一处死锁或者长时间阻塞，都可能拖垮整个系统。为了方便理解，你可以把SystemServer想象成一个大型物业公司，所有岗位都在同一栋办公楼里办公，客服（AMS）处理住户请求，工程部（PMS）管理每家每户的设备档案，保安（WMS）管制门禁。他们之间沟通走内部对讲机，秒回；但哪天有个岗位堵住了，整栋楼的协作都要遭殃。

1.3 Android 11在这条路上的演进

Android 11延续了“集中管理”的大方向，但同时也做了不少细化。比如系统服务的启动被划分成更明确的阶段，引入了一些按需启动和分区启动的机制，有些非关键服务不再非得在开机阶段死等完成。说白了，Google也在尝试解决“SystemServer启动太重、开机太慢”这个老大难问题。

这里有一个很重要的设计思路值得提：SystemServer里所有服务的启动顺序并非随意排列，而是有严格的依赖关系。这种依赖被组织成几个大的启动阶段（Boot Phase），每个阶段之间通过SystemServiceManager来调度服务回调。服务在注册时声明自己关心哪些阶段，SystemServiceManager在对应阶段回调它的onBootPhase方法。你在读代码时如果只看单个类的启动逻辑，很容易迷路，正确的方式是先掌握阶段的划分，再看每个服务在哪个阶段被拉起来。

2. 入口分析与启动时序拆解：从main到run

2.1 main方法为什么长成那个样子

SystemServer的入口是一个public static void main方法，看起来非常简短，但里面每一步都是有讲究的。先设置系统属性，比如处理加密状态下vold相关的标记，然后调用System.loadLibrary("android_servers")加载native层库，这里面包含了一些JNI方法，用于在Java层和Native层之间建立桥梁。紧接着创建SystemServer对象并调用run方法。

代码里还会做一件事：把当前线程名字改成“system_server”，这一点看着不起眼，实际影响很大。Android的日志系统会显示线程名，如果你不做这个设置，后续很多system_server内部的日志看起来会很混乱。你可以打开logcat，按TAG过滤“SystemServer”，就能看到这个线程里输出的启动日志，包括“StartService”和“Ready”的标记。还有一个小细节：main方法里会检查系统属性ro.crypto.state，根据加密状态决定某些服务的启动策略，这是一个容易被人忽略但又真实影响开机流程的分支。

2.2 run方法里的四段式启动

SystemServer.run方法内部的启动逻辑，大致可以归纳成四个部分：准备阶段、启动Bootstrap服务、启动Core服务、启动Other服务。准备阶段会先创建SystemServiceManager，这是整个服务的“大管家”，后面所有服务的注册和启动都通过它完成。同时会创建Looper和Handler，保证SystemServer主线程的消息循环已经就绪。

Bootstrap服务是最基础、没有任何依赖前置的服务，典型代表有Installer、ActivityTaskManagerService、PackageManagerService等。你可能觉得PackageManagerService是个很重的服务，为什么不放到后面？因为其他所有服务可能都会通过PackageManager查包、解析Intent，所以PMS必须在早期起床，然后慢慢扫描系统里的APK。而像JobScheduler、BatteryStatsService这类服务，会被划分到Core服务，它们依赖PMS等基础服务准备好才能跑起来。最后启动的Other服务最庞大，包括WMS、InputManagerService、NotificationManagerService等系统UI和用户交互相关的服务。

2.3 Boot Phase机制：为什么服务不是一次性全部启动

如果所有服务都是在SystemServer.run里一口气调完，启动耗时会被拉得非常难看。所以Android引入了Boot Phase机制，把启动过程切成了多个阶段，每个阶段结束后，SystemServiceManager都会通知所有已注册的服务，让它们知道“现在系统已经走到哪一步了”。比如PHASE_WAIT_FOR_DEFAULT_DISPLAY、PHASE_SYSTEM_SERVICES_READY、PHASE_ACTIVITY_MANAGER_READY、PHASE_BOOT_COMPLETED等。

这个机制对排查开机问题特别有用。你在看系统启动日志的时候，如果能找到“BootPhase”相关的输出，就能把问题锁定在具体阶段。比如某个服务在PHASE_BOOT_COMPLETED阶段才去注册一个动态广播，如果这个阶段迟迟不结束，那一定是有服务阻塞在它前面的阶段。我实际排查某类开机慢问题时的经验是，先抓日志里的时间戳，确认问题是在PMS扫描阶段，还是AMS准备阶段，又或者是WMS画第一帧界面阶段，再往下钻具体代码。

2.4 并行与线程：SystemServerInitThreadPool的妙用

SystemServer里有一个很不起眼但作用巨大的类：SystemServerInitThreadPool。它负责把一些可以并行的启动任务丢到后台线程去执行，从而压缩整体启动时间。比如说扫描某些目录、预加载某些资源这类没有顺序要求的任务，就可以放进这个线程池。

但要特别注意：SystemServer里的线程池和普通应用不一样，它的任务在系统启动完成后会被shutdown，所以你不能拿它来执行长期后台任务。Android 11里这个机制使用得更加充分，很多非关键服务已经不再阻塞主线程启动，而是提交到InitThreadPool去异步执行，稍后再通过回调注册到ServiceManager。这样设计之后，SystemServer主线程能够更早地走到“系统UI可用”这个状态，用户在开机动画阶段看到的等待时间就变短了。

3. 三个重量级服务的启动细节：AMS、PMS与WMS

3.1 ActivityManagerService：为什么它是启动最慢的瓶颈之一

ActivityManagerService（AMS）在SystemServer里的启动顺序非常早，但它要做的事情也特别多。创建AMS实例的时候，会同时创建ActivityTaskManagerService（ATMS），这个在Android 10之后已经从AMS中拆出来，专门负责Activity Task栈相关的工作。AMS还会创建ProcessRecord相关的管理结构，启动Persistent应用，注册各种系统广播，初始化BatteryStats、UsageStats等统计组件。

在Android 11里，AMS的系统就绪过程尤其值得关注。它要等待PMS扫描完成，拿到已安装应用列表，然后才能开始启动那些persistent属性为true的应用。同时AMS还要处理第三方应用“可以被启动”的信号——注意这个信号不是一开始就发出的，而是要等所有系统服务基本就绪、系统进入PHASE_BOOT_COMPLETED阶段之后，才允许启动普通应用。这个“先让系统服务全部健康，再放应用进程进场”的设计，是防止应用一启动就遇到“依赖的服务还没准备好”这类诡异问题的核心保障。

读AMS启动源码的时候，我的建议是先画出它的启动时序图。这里画不了图，我可以给你列几条主线：构造函数里的组件创建顺序、systemReady方法里的调用链、以及各BootPhase回调里做了什么。这三条主线交叉着看，就能明白它为什么启动慢：因为AMS是“服务中的服务”，它要做的事情一半是为自己，另一半是为了支撑所有应用进程。

3.2 PackageManagerService：开机时间杀手

PackageManagerService（PMS）大概是SystemServer中最拖慢开机时间的服务了。它的任务是扫描系统里的所有APK，解析AndroidManifest.xml，建立包、Activity、Service、Receiver的索引，为其他服务提供查询能力。SystemServer启动流程里，PMS被归为Bootstrap服务，也就是说它必须提供基础能力后才能让其他服务干正事。

Android 11的PMS扫描策略相比以前更强调增量更新。系统启动时，PMS不是全量重扫所有包，而是根据之前的缓存结果做增量比对，只有新增或变更的包才需要重新解析。这里有一个非常有用的调试点：开机慢的时候，日志里往往会有PMS的“scanning...”输出，耗时大头通常出在首次开机或者OTA升级后那次全量扫描。你可以通过统计logcat里PackageManager和PackageParser相关的日志耗时，精确找出是哪一步拉长了开机时间。

我个人的实测感受是，PMS扫描APK的耗时和设备存储速度强相关。当年某项目里，在UFS2.1和UFS3.0两台设备上比较同样版本的系统，开机扫描时间差能到30%以上。所以排查开机慢，先不要怀疑代码逻辑，先看IO瓶颈是不是出现在PMS的扫描目录阶段。

3.3 WindowManagerService：界面真正出现的功臣

很多人会忽视WindowManagerService（WMS）的启动逻辑，觉得它不就是管窗口的吗？但在SystemServer的链条里，WMS要等到SystemUI启动后，用户才可能看到锁屏和桌面，而WMS本身启动的时候，还要依赖InputManagerService、DisplayManagerService、SensorService等一批输入和显示相关的服务先起床。

WMS启动的一个关键动作是初始化窗口管理策略，比如状态栏位置、导航栏行为，以及多窗口能力的边界条件。这些策略参数部分来自资源文件，部分来自系统属性，还有一部分在WMS代码里直接写死。由于这些策略直接影响用户交互的第一印象，WMS启动阶段如果出现问题，表象是开机动画结束后黑屏或桌面无法显示。而这类问题光看SystemServer日志往往不够，还需要把SurfaceFlinger的日志一起拉出来对照。

这也是SystemServer分析里特别有意思的一个点：它是Java层服务的大集合，但它面向的是底层渲染、输入、电源等Native服务。WMS每次创建窗口、Surface的分配、帧的合成，都要通过Binder调用SurfaceFlinger，这条链路上的任何一环迟缓，都会表现为UI上的卡顿或掉帧。所以读SystemServer，不能只看Java代码，偶尔要跳出这个进程，去看看它依赖了哪些Native服务。

4. 服务间的依赖关系和线程模型：排序背后的隐藏逻辑

4.1 依赖关系是分层的，不是平铺的

SystemServer里服务的启动顺序没有想象中那么简单。看起来是Bootstrap、Core、Other三个批次依次执行，但每一批次内部还有精细的依赖顺序。比如在Bootstrap服务组里，PMS排在AMS前面，是因为AMS在systemReady时会出现那个最重要的“第三方应用可以启动”信号，而这个信号需要拿到PMS的包信息。反过来PMS又可能需要用到Installer服务去创建应用数据目录，所以Installer必须排在最前面。

这种做法在工程上其实非常常见，先构建最底层的无依赖组件，再逐层向上填充。你可以把SystemServer启动过程想象成盖楼，Installer是地基，PackageManager是承重墙，ActivityManager是内部装修，WindowManager是外墙和门窗，最后一个BootCompleted广播就是交付钥匙的仪式。我们排查系统启动问题时，用的方法论和这个分层结构是严格对应的：往每一层看日志，哪一层没盖完，后面所有的装饰都白搭。

4.2 线程优先级：主线程、UiThread、IoThread各司其职

SystemServer进程启动后，会创建一系列带有特殊线程名的线程，它们各自承担不同的任务。主线程就是执行SystemServer.run的线程，几乎所有生命周期回调都在这个线程里跑。UiThread和IoThread则负责一些耗时或者UI相关的任务，它们的Handler Looper是独立创建的。

还有一个容易被忽略的点是Binder线程池。SystemServer作为系统服务的托管者，要接收来自其他进程大量的Binder调用，系统默认的Binder线程池数量是16，但在SystemServer里，这个池子会根据需要被调整到更大的数目。因为如果一个Binder调用在SystemServer里阻塞了，池子里的线程不够用，新的调用只能排队，外在表现就是整个系统“卡住”。我亲眼见过某定制ROM把system_server的Binder线程池配置调小后，频繁出现系统无响应的问题，最后查原因就是并发过来的Binder事务把线程池占满，逻辑没死锁但活活被等死了。

理解这个线程模型对定位问题非常关键。当你收到“system_server not responding”的投诉时，第一件事不是把怀疑对象放到某个业务服务上，而是去抓system_server所有线程的栈，看是哪条线程上发生了阻塞，阻塞的锁被谁持有，持有锁的线程又在等什么。这种排查思路本质上是把进程当做一个并发系统来看，而不是去猜某个功能点。

4.3 Watchdog：SystemServer为什么不能“死”，但又必须“敢死”

SystemServer里有个线程叫Watchdog，它的存在堪称“用暴力维持秩序”。Watchdog定期检查系统里的主要线程是否在规定时间内处理完消息，比如主线程、UiThread、IoThread、DisplayThread等。如果某个线程长时间卡死，Watchdog会把所有线程的栈dump出来，然后将system_server进程直接杀掉，让整个系统重启。

你可能会问，为什么不能温柔一点，只恢复出问题的服务？原因在于SystemServer内部的耦合度太高，很难在不重启的情况下把某个服务单独重置到健康状态。与其让系统带着病继续运行，不如快速重启，换一个干净的状态重新汇聚。这也从反面告诉我们，在SystemServer里做定制开发时，最忌讳的就是写那种“长时间占用主线程”的代码。哪怕你的功能再正确，只要阻塞了主线程消息循环，就可能触发Watchdog，被它判定为系统无响应，最终连累整机重启。

我自己在SystemServer里加过一些调试性质的轮询逻辑，原本想着task放后台线程应该没什么问题，结果在线程优先级和处理时机上没控制好，导致某个低优先级任务和主线程的同步屏障冲突，最后Watchdog直接介入。那次教训让我彻底明白了：在SystemServer里，任何细微的线程调度失误，都会被放大成系统级异常。

5. 阅读源码的实用路径与调试手段

5.1 从哪里下嘴最友好

面对SystemServer这种大而全的入口类，最容易犯的错是试图从头到尾顺序读代码。我的建议是分三步走。

第一步，先跑一个模拟器或者用真机抓一份开机日志，只看TAG为“SystemServer”的信息，感受一下服务启动的大致节奏和时间分布。这一步能让你在还没细读代码前，就对“哪些服务最耗时”建立直觉。

第二步，打开SystemServer源码，找到run方法，数一下里面所有StartService调用，把它们按Bootstrap、Core、Other三个列表归类。这一步不需要深究每个服务内部实现，只要搞清楚启动顺序和分组的边界即可。

第三步，挑两三个你最关心的服务去精读，推荐从ActivityManagerService和PackageManagerService入手。因为这两个服务的启动逻辑链条足够长，会牵涉到SystemServiceManager、SystemServerInitThreadPool、BootPhase回调等多个系统级机制，读透它们，SystemServer的整体套路就基本掌握了。

在工具方面，我不建议用网页版源码站一点点翻，效率太低。把AOSP代码下载下来，用支持跳转的IDE或者源码阅读工具打开，尤其是像Android Studio配合相关插件，对于跳转Java代码的帮助非常明显。但要注意，SystemServer里很多类是隐藏API，IDE的静态索引可能不全，这时候设断点不如直接加日志来得都快。

5.2 日志和系统属性：最常用的两把扳手

抓SystemServer日志的过滤方法很简单：adb logcat -b system，或者带特定TAG过滤。但更有用的一个技巧是打开debug属性来拉长日志细节，比如设置persist.sys.log.tag.SystemServer=DEBUG，有时候能看到更多内部输出。不过很多ROM会裁剪日志，所以要提前确认系统版本有没有保留framework层日志。

写日志的时候，你要掌握一个度。SystemServer是高频进程，如果在里面随意加Log.d，尤其是加在Binder调用频繁的路径上，产生的日志量会非常大，甚至影响性能。正确做法是在关键状态切换点打日志，比如服务启动完成、BootPhase变更、systemReady触发这些节点。这些节点的日志量和定位价值成反比，越少越珍贵。

从源码阅读角度看，Java层的SystemServer相对好读，真正难啃的是它和Native层的边界。遇到JNI调用时，你要去查对应native函数的实现在哪个cpp文件里，比如libandroid_servers库里的方法。这一步会耗费不少时间，但一旦打通Java和Native这条线索，你对系统整体运行机制的理解会上一个台阶。

5.3 与性能工具结合：systrace和bootchart

读SystemServer的时候，手边最好准备一套性能分析工具。抓开机过程systrace，能看到SystemServer进程各个线程的运行区间，哪些线程繁忙、哪些线程在等待锁、CPU频率变化如何，一目了然。开机阶段问题里，最常见的是某个服务把主线程占满，导致后续服务排队，systrace里会表现为system_server主线程的等待时间特别长。

bootchart则更适合分析从启动到用户可用的整体时间分布。你可以通过它先确定系统要花多长时间才能完成开机动画到桌面的转换，再结合SystemServer日志倒推耗时最长的服务。这个方法和纯读代码完全互补：代码告诉你机制，性能工具告诉你现实世界中的瓶颈到底在哪。

我在实际项目里有个习惯，拿到一台启动异常的设备，第一件事不是接logcat看报错，而是先开systrace抓30秒开机过程。因为很多SystemServer的问题并不会立刻抛异常，而是反映成某个阶段迟迟走不完，这种“卡住”型问题用日志排查远不如用trace直观。

6. 常见问题与排查技巧实录

6.1 开机慢：从SystemServer日志里找出元凶

开机慢问题在SystemServer的调试中占比最高。定位思路是先把开机时间切成三段：内核启动时间、zygote到SystemServer启动完成时间、SystemServer到用户可操作时间。SystemServer相关的问题大多集中在后两段。

我常用的一条命令是把开机过程中所有标记过时间戳的日志抓出来，然后找相邻两条日志之间的时间间隙。间隙最大的地方，往往就是瓶颈所在。有一次排查某款定制设备开机慢，发现日志里AMS的systemReady和WMS的systemReady之间隔了将近8秒，追进去一看，是系统里预装了大量persistent应用，AMS在逐一启动这些应用时占了主导时间。定位到这一步之后，接下来是优化预装应用数量、调整persistent应用启动顺序还是做延迟启动，就是产品策略问题了。

如果日志里找不到明显大间隔，可以试试看是否存在IO竞争。SystemServer启动阶段，PMS在扫描APK，zygote在预加载class，如果存储本身性能不稳定，随机读慢到离谱，整个启动就被IO拖住了。这种情况换到代码层面去优化是没用的，重点应该是页缓存管理或者存储策略。

6.2 SystemServer反复重启：先查Watchdog和历史堆栈

system_server进程异常重启，用户侧表现是手机突然重启或者卡在开机动画循环。这种问题最有效的排查入口不是漫无目的地抓日志，而是去看系统重启后留下的历史记录。Android里dropbox有很多记录系统级事件的条目，可以查最近的system_server_crash或者system_server_watchdog日志，里面往往有崩溃时的线程栈。

Watchdog触发的日志尤其关键，因为那里面直接列出了哪个线程长时间没处理消息，以及该线程当时停留的代码路径。比如有一回看到主线程栈停在一个文件锁等待上，往前追，发现有另一个线程持有同一把锁去跑了网络请求，网络又没配置好，一直等不到回应，最后把主线程活活抢死。这个案例让我意识到，SystemServer里的网络相关调用一定要设计超时，不能盲目等待，否则一次网络异常就能拖垮整机。

排查这类问题的时候，不要忘了看一下Kernel日志（dmesg），因为有时候是底层内存严重不足，导致system_server被杀，而不是自身代码出错。Android 11里内存压力大时，系统的lowmemorykiller优先杀非关键进程，但极端情况下，system_server自己也可能因为关键内存分配失败而崩溃。这两种情形一个要修用户态逻辑，一个要优化内核和内存策略，方向完全相反。

6.3 服务启动超时与“启动顺序依赖”陷阱

SystemServer启动过程中，某些服务会设置超时时间，如果超时未完成启动，可能触发异常流程。在定制开发时，往SystemServer里加新服务的代价想清楚了再动手。新服务放进启动列表意味着它要占用启动时间，如果又依赖其他服务，可能打乱整条时间线。

我见过一个比较典型的翻车案例：某团队把一个新的账号同步服务放进了Bootstrap服务组，但这个服务实际需要网络功能，而网络服务是在Other服务组才启动的。结果这个新服务启动时尝试绑定网络服务，绑定不到就直接抛了异常，SystemServer整体启动失败。根因就是没搞懂服务分组的语义，Bootstrap组表示“不依赖任何其他服务”，放了需要外部依赖的服务进去，等于自己给自己挖坑。

所以，对于新增系统服务，第一原则是：尽可能放到Other服务组的后面阶段去启动，并且不要在构造函数里做需要等待其他服务的事。如果真的要做业务初始化，放到该服务的onBootPhase回调里，因为那个时机其他服务已经基本就绪。这条原则，我在多少个项目里看着别人踩坑，自己也跟着踩过。

6.4 死锁和ANR：在SystemServer里可能更隐蔽

普通应用的ANR，系统会直接弹对话框，但SystemServer的“ANR”往往不弹窗，而是以Watchdog的方式重启。所以处理SystemServer问题时要特别留意锁的使用顺序。

Java层的synchronized在SystemServer里到处都是，如果A线程持有锁1请求锁2，而B线程持有锁2请求锁1，就死锁了。由于SystemServer线程众多，锁竞争路径复杂，这种死锁很难靠裸眼看代码找出来。建议做法是修改系统代码时，始终遵守“全局固定加锁顺序”。比如大类锁先行，细粒度锁后行，这样即使并发路径复杂，也能把死锁概率降到最低。

再补充一个隐蔽问题：SystemServer里有些Handler消息是带同步屏障的，比如SurfaceFlinger的帧提交相关逻辑。如果主线程被一个同步屏障卡住，原本排在屏障后面的非异步消息全部不执行，外在表现是某个界面操作无响应，但线程栈看起来并没有死锁，而是在正常工作。这种情况要用systrace来拉消息队列活动，直接看handler的dispatch时间。

6.5 调试技巧速查表

为了方便你快速上手，我把上述经验整理成一张简表。

整理到这一步，你会发现SystemServer源码分析最核心的价值不在于“读懂了某个类”，而在于建立一套从机制到现象的推理链。看到启动慢，你能想到PMS扫描和IO关联；看到异常重启，你能想到Watchdog线程栈；看到服务启动失败，你能自动检索依赖顺序是否合理。这套推理能力，才是读SystemServer源码真正沉淀下来的功夫。

回到开头那个问题：SystemServer到底做了什么？它做的事就是在一场极度快节奏的接力赛中，把由init递过来的棒子，依次传给包管理、活动管理、窗口管理……最后传到正在滑动手势解锁的你的手指尖。而每个棒子交接的节奏、顺序、异常处理，全都浓缩在那几千行SystemServer代码里。读的时候耐住性子，先看框架再钻细节，你会发现这个进程虽然庞大，但每一块的摆放位置都有充分的理由。