做Android系统层开发这些年我始终觉得有两个native守护进程是所有做Framework、做系统定制的人都绕不开的一个是负责存储卷管理的Vold另一个是负责电话通信的Rild。这本书第8章把这两个东西放到一起讲初看有点怪——Vold是管文件系统挂载的Rild是跟Modem打交道的完全不搭界。但真正把代码读透之后你会发现这两个进程的架构设计内核惊人地一致都是独立native进程、都通过socket向上层Java服务暴露命令接口、都是事件驱动、都是那套你发命令我来做有事广播给你的模式。搞懂其中一个另一个基本等于白送。这篇文章我打算换个思路不按原书的章节顺序念代码而是用我实际调试和二次开发时积累的经验来反推这两个进程的设计逻辑把Vold和Rild的启动、事件流、命令通路、加密处理这些核心机制一条线串下来中间穿插一些只有真正动手改过源码才会注意到的细节和坑。1. 先搞清楚这两个Daemon在整个系统里是什么地位1.1 存储链路上的Vold先说Vold。Vold其实是Volume Daemon的缩写翻译过来是“卷守护进程”。你在Android上插一张SD卡系统能弹出来“正在准备SD卡”、能在设置里看到存储空间变化、能把U盘挂载到某个路径下这些事情背后全是Vold在干活。它本质上是个管理员内核告诉它“有一个新设备出现了”它去检查分区、文件系统然后执行真正的mount动作把硬件设备变成一个用户可以访问的目录。Vold的顶层搭档是Java层的MountService。你说“存储”这个功能从用户界面到硬件中间要经过好几层比如设置里的“卸载SD卡”用户点一下Settings应用调用StorageManagerStorageManager调用MountService的unmount方法MountService再通过本地socket给Vold发一条命令。Vold收到命令去操作底层存储设备然后通过回调把结果一步步传回来。这条链路上Vold就是最底下那个真正干活的角色。Vold不只是管外部SD卡和U盘它还管整个data分区的挂载和加密。现在Android手机默认都开FBE基于文件的加密开机的时候系统需要先把data分区用临时密钥挂载一遍初始化完后再切换到完整密钥重新挂载这个切换动作也是Vold来协调的。你可以理解Vold负责两件大事对外管好外部存储的热插拔、挂载、格式化对内管好data分区的加密、解锁、恢复出厂设置。1.2 电话链路上的RildRild全称是Radio Interface Layer Daemon无线电接口层守护进程。它是Android所有电话功能的基层执行者。手机能打电话、能收发短信、能注册上移动网络每一件都依赖一个关键硬件——Modem基带处理器。而Rild就是连接Android系统上层和Modem之间的那座桥。这座桥的位置很有意思。它上面是Java层的Phone进程和Telephony框架RILJ之类下面是厂商的Modem。Rild本身不关心你用什么型号的Modem也不关心协议是AT命令还是QMI或者别的什么私有协议它只定义一套统一的接口把上层的电话请求翻译成Modem能听懂的语言再把Modem上报的事件翻译回成上层能处理的回应。这套设计带来的好处是上层Framework写一套所有手机都能通用厂商只需要把自己的协议实现塞到Rild底下那层就行了。所以你看Vold和Rild在上层视角里其实是两个非常对称的东西一个是存储功能的“执行末端”一个是电话功能的“执行末端”。虽然业务领域完全不同但架构上一脉相承。2. Vold的机制拆解从热插拔事件到挂载点2.1 uevent是怎么一步步变成挂载动作的Vold最核心的事件来源是内核的uevent。Linux内核在检测到硬件变化时会通过netlink socket往上抛uevent消息。比如你插入一张SD卡内核会依次发出几个事件检测到新的块设备sda、检测到分区sda1、块设备状态变化等。这些事件不是Vold直接收到的而是Vold里的NetlinkManager在listen。这里我建议第一次看Vold源码的人先把这条事件链捋清楚。内核发出uevent - NetlinkManager收到原始数据并解析成Uevent结构体 - 根据action分发给VolumeManager - VolumeManager找到对应的Volume对象并调用它的handleEvent方法。代码里关键的位置是NetlinkManager::processEvent和VolumeManager::handleBlockEvent。我看过不少刚入门的人直接去Volumes的mount方法里打断点结果发现事件根本没走到那儿就是因为没先把NetlinkManager这层通道搞明白。一个值得注意的细节是Vold的动态分区和多路径存储完全是靠这些uevent驱动的它自己不会主动去轮询设备。这个设计是刻意的内核比你更清楚硬件状态而且硬件变化比如用户突然拔出SD卡是异步的Vold不可能用轮询去捕捉这种瞬间事件只能被动接收内核的通知再处理。理解了这个你排查“为什么U盘插上没反应”这类问题时思路就清晰了先看dmesg里内核有没有发出事件如果内核都没动静那说明是硬件或驱动层面问题Vold根本接不到如果内核有事件但Vold没反应那才轮到怀疑Vold或者SELinux。2.2 NetlinkManager和VolumeManager的分工逻辑Vold内部并不是一个大而全的类包办所有事它把职责拆给了几个组件这个拆分方式是理解整个Vold架构的一把钥匙。NetlinkManager只负责一件事跟内核的netlink socket建立连接监听uevent然后把事件整理成系统内可以理解的数据结构。它不关心这些事件要干什么也不管存储设备是SD卡还是U盘还是别的什么它就是个信使。VolumeManager才是真正的决策者。它手里维护着一组VolumeBase的实例每个实例代表一个存储卷。当NetlinkManager把事件交过来时VolumeManager负责判断这个事件跟哪个卷有关系、该调用卷的哪个方法去处理。Volume对象本身负责具体执行负责挂载的、负责加密的、负责格式化的各有各的逻辑。为什么拆开我个人的理解是NetlinkManager负责“跟内核通信”这种全局性的、跟具体业务无关的事情VolumeManager负责“卷生命周期管理”这种跟存储领域强相关的事情而具体的Volume子类负责“某个卷本身怎么应对状态变化”。三层各守一摊将来增加新类型的存储设备时只需要添加新的Volume子类不用去动通信层。2.3 一个SD卡插入Vold到底做了什么我用一条完整的时间线来描述插入SD卡后Vold的行为这比单纯看代码要直观得多第一步硬件层完成识别内核创建出块设备节点发出action为add的uevent。第二步NetlinkManager收到事件解析出设备路径、分区号、设备类型这些信息。第三步VolumeManager从事件里发现这是公共卷PublicVolume也就是可移动外部存储于是创建Volume实例状态切到正在挂载。第四步Vold去检查分区表如果第一个分区是vfat/exfat等Android支持的文件系统就开始执行mount把设备挂载到/mnt/media_rw/XXXX这样的中间挂载点。第五步MountService通过回调得知挂载成功引导用户空间把这一层挂载到/storage/XXXX也就是你在文件管理器里看到的那个路径。第六步MediaProvider启动扫描媒体库开始索引新出现的文件。这中间如果文件系统格式不认识Vold会停下来并向上层广播“无法识别”这时系统会弹出“格式化SD卡”的提示。Format动作同样是Vold来做它拿到设备节点重新写入分区表和文件系统然后重新挂载。你如果在真机上调过这个流程应该深有体会——格式化或者挂载大容量U盘时有些机型的体验很卡顿瓶颈往往不在Vold本身而在底层文件系统驱动的性能上。3. Vold的代码脉络命令、分区、加密三件事3.1 CommandListener与MountService的socket协议事件处理是Vold的“被动模式”命令处理是它的“主动模式”。上层Java的MountService要通过socket给Vold发命令而这个socket的接收端就是CommandListener。这个监听器在main函数中被创建绑定到/dev/socket/vold这个本地socket上然后进入一个循环不停地读取客户端发过来的数据。命令协议的格式很简单一行字符串命令名加参数。比如volume mount 123、volume unmount 456。CommandListener解析命令名之后调用对应的处理函数处理完再把结果成功、失败、错误码写回socket。数据量大一点的例子是fstrim文件系统Trim操作Vold收到命令后会执行全盘trim这个动作耗时长所以协议里还考虑了异步返回。这里藏着一个非常值得学习的点CommandListener本身不写业务逻辑它只解析命令和回传结果。真正的挂载、卸载动作是调用VolumeManager的方法。而且这些方法往往要在独立的工作线程中执行因为mount操作可能很慢如果直接在socket的回调线程里执行会阻塞后续命令的读取造成上层MountService长时间无响应。我在某次调一个外置存储初始化慢的问题时就遇到过一个第三方App因为长时间等不到MountService回调而超时崩溃的情况最后追查下来反而发现是底层挂载路径被卡住了。3.2 存储加密与FBEVold责任最重的一件事Vold第二个躲不掉的重任是data分区的加密管理。Android 7.0之后默认是FBEFile Based Encryption即基于文件的加密不同用户的文件用不同密钥加密开机时先用临时密钥device encrypted简称DE挂载data分区把系统完全启动起来然后用户输入锁屏密码之后解锁用户密钥再把用户数据credential encrypted简称CE挂载成可访问状态。这套流程看起来简单实际实现非常绕因为Vold要在挂载过程中同时操作内核密钥环和加密策略。系统启动时有一个专门的动作叫vold trim、vold prepare之类Vold需要先探测data分区有没有加密、用的什么算法、密钥存放在哪、要不要生成新的临时密钥然后调用内核的fscrypt接口设置密钥最后才能把分区或子目录挂载好。我调这个功能时最深刻的体会是加密这块的错误信息对新手极不友好Vold日志里经常只给一个类似“Invalid key”的笼统报错看起来是密钥不对实际上可能前面任何一步出了问题都会走到同样的报错。排查思路只能是从上往下一步步验证先用dmesg确认内核有没有报错再确认fscrypt context是否设置成功再确认挂载参数是否正确最后才轮到怀疑是密钥本身的问题。而且一定要小心不要在系统已经启动完成后手动去改动加密状态这极可能触发强制恢复出厂设置用户数据直接没。3.3 格式化、分区、擦除这些操作里的实用细节除了正常挂载Vold还负责一堆跟存储生命周期相关的琐碎操作。格式化SD卡、创建分区、调整大小、擦除用户数据恢复出厂设置都是Vold的业务。格式化SD卡的实现路径在VolumeManager和fs目录下的那些文件系统封装类里。比如格式化vfat分区Vold会调用mkfs.vfat传入设备节点和参数格式化exFAT则调用mkfs.exfat。在执行格式化之前Vold会先卸载该卷、清掉分区表再用sgdisk重新创建分区表然后再格式化成目标文件系统。这个顺序一错轻则格式化失败重则分区表损坏。恢复出厂设置走的是另一条更暴力的路径。VolumeManager的wipe逻辑会直接对整个data分区做擦除先卸载然后写零或者直接重新格式化。这个操作是不可逆的所以我强烈建议任何做过系统定制的人在关键路径上保留日志不然用户误触了恢复出厂设置你连谁触发的和为什么触发都查不到。我在AOSP源码里见过不少厂商在真实设备上改这个流程的痕迹就是因为默认的擦除动作在某些A/B分区架构下需要额外处理。4. Rild拆解从Dialer到Modem的一条完整链路4.1 Android电话功能的模块划分讲到Rild就要先把Android电话功能的分层画出来不然很多东西对不上号。最上层是Dialer拨号应用再往下是TelephonyManager这个系统级Manager再往下是Phone进程里的各种Tracker比如GsmCdmaCallTracker、ServiceStateTracker再往下就是RILJ这是Java层跟Rild通信的末端。RILJ通过socket连接rild进程而rild进程内部又通过libril加载厂商的RIL实现厂商实现再通过串口、USB或者共享内存跟真实Modem通信。这条链路上每一层只做一件事。Dialer处理用户交互TelephonyManager提供APITracker维护通话状态、网络状态这些上层状态机RILJ把Java层的调用转成统一格式的RILRequest并通过socket发出rild负责把请求派发给底层厂商RIL库负责跟Modem翻译协议。4.2 RILJ、libril、rild三层协作方式RILJ是Java层的代码路径在frameworks/opt/telephony/.../RIL.java。它做的事情很单纯构造一个RILRequest塞进一个Parcel格式的缓冲区通过socket写给rild进程。rild收到这段字节流后由libril来解析取出请求编号request number和参数然后回调厂商RIL库注册的处理函数。厂商RIL库实现是通过RIL_register注册进来的。rild启动时读一个启动参数拿到厂商库的路径动态加载这个.so调用里面的RIL_Init这个函数会返回一组函数指针和回调信息。这组函数指针就是libril之后分发请求的入口。比如一个RIL_REQUEST_DIAL拨号请求到达libril取出对应的处理函数指针然后调过去厂商库把这个请求编码成AT命令“ATD号码”发给Modem。这段设计相当干净——Android框架完全不知道Modem是什么协议厂商库也完全不关心Android上层怎么管理状态中间的libril只是个邮递员。看代码的时候留意ril_commands.h和ril_unsol_commands.h这两张表它们列出了所有命令和回调事件的分发关系把这两张表看熟了Rild的基本盘就掌握了七七八八。4.3 电话呼叫在RIL层的真实过程用一个具体场景串一下。你在拨号盘输入号码、按下拨打键之后第一步GsmCdmaCallTracker构造一个Dial请求交给RILJ处理。第二步RILJ把请求封装成Parcel通过socket发到rild进程。这个socket在/dev/socket/rild和Vold的/dev/socket/vold是同一类机制。第三步libril的readerLoop线程读到这个请求查找命令表找到RIL_REQUEST_DIAL对应的处理函数。第四步处理函数被调用厂商RIL库把命令转换成类似ATD10086;的AT指令发给Modem。第五步Modem开始建立呼叫同时上报“呼叫状态变化”的主动事件unsolicited response。第六步rild把这个事件通过socket传回RILJRILJ把它解析成RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED通知给Tracker更新UI状态——拨号盘变成呼叫中界面。这个流程每一步都有对应的日志。排查电话问题时建议直接在logcat里过滤RILJ、RILC、RILD这几个Tag一层层看请求走到哪儿断了。最常见的定位方法就是看RILJ发出请求后有没有收到对应的response如果RILJ发出去了但libril一直没回复问题多半在底层Modem或者厂商库如果libril回复了但上层状态没变问题多半在Java层的状态机处理。5. Rild的事件驱动与数据通路5.1 RIL_REQUEST和RIL_UNSOLRild的消息模型值得单独拉出来讲因为它是理解整个RIL架构的钥匙。消息分两类一类是上层主动发起的请求叫RIL_REQUEST比如拨号、挂断、查询网络状态、设置数据连接另一类是Modem主动上报的事件叫RIL_UNSOLunsolicited主动上报比如来电提醒、网络信号变化、短信到达。这个“unsolicited”设计很关键。Modem什么时候收到来电、什么时候网络断了上层是控制不了的这些事件只能由Modem主动告诉Rild。Rild收到之后不分青红皂白地全部以主动消息的形式通过socket推给RILJRILJ再把它广播给上层的各种监听器。这种模式在实践中被验证得很成熟——它让上层Framework永远保持“被通知”的状态不需要轮询Modem状态省电而且实时性高。5.2 数据连接从拨号到上网的完整过程打电话和处理数据连接是Rild的两个完全不同的业务域。数据连接的流程比拨号复杂得多因为涉及APN配置、网络注册、IP地址分配等多个环节。用户或系统发起数据连接请求时上层DataConnection会要求RILJ发送RIL_REQUEST_SETUP_DATA_CALL参数里包含APN、用户名、密码、认证类型这些信息。Rild把请求转给厂商库厂商库向Modem发起“建立数据承载”的流程。Modem完成网络侧协商后返回一个包含CID连接标识、IP地址、网关、DNS等信息的响应。rild把响应传回RILJ再由框架把这些信息配置给网络接口Linux系统才真正获得可用的数据通路。但这里有个很常见的坑上层Framework拿到的IP地址信息只是Modem侧协商出来的结果但真正创建网络接口、配置路由、设置DNS这些动作发生在系统侧是由ConnectivityService和netd配合完成的。我第一次排查“数据连接建立成功但上不了网”的问题时一直盯着RIL日志看盯了很久发现网络接口根本没被创建才意识到要去看netd的日志。所以排查数据问题不要只盯Rild要全线看。5.3 多卡与网络注册的调度逻辑现在的手机基本都是双卡双待Rild层面是怎么支持多卡的呢答案是Rild可以启动多个实例。Android通过init.rc的配置让rild进程能够根据ro.telephony.ril_impl这些属性加载不同的RIL实现并且通过不同的socket名比如rild、rild2、rild3与上层通信每个实例对应一个SIM卡槽。每个实例独立跟各自的Modem通信各维护各的事件循环。上层Telephony框架根据SIM卡槽编号把请求发给对应的socket。这里经常出现的问题是如果厂商的Modem固件只支持单卡但你启用了双卡配置那么第二个rild实例会加载同样的厂商库而厂商库内部用的状态变量是全局的两个实例互相踩数据导致第二张卡死活注册不上网络。这个问题的排查思路是先确认两个socket都正常存在然后用logcat分别过滤两个实例的日志对比它们的行为差异。我遇到的几次双卡异常最后都定位在厂商RIL库的全局变量冲突上根本不是Rild框架的问题。做这个方向的人一定要有这个警觉多实例模式下RIL实现的线程安全性和状态隔离是真正的深水区。6. Vold和Rild放在一起看设计上是同一套思路6.1 共性socket通信、事件驱动、native守护进程Vold和Rild虽然业务完全不一样但架构的对称性已经非常明显了。二者都是在系统启动早期由init进程拉起的native守护进程二者都用本地socket/dev/socket/vold和/dev/socket/rild接收上层Java服务的命令二者都是事件驱动模型——Vold靠内核ueventRild靠Modem主动上报二者都维护一套状态机把底层的不确定性和复杂性封装在上层容易理解的接口后面二者都通过一套协议层来做字节流和结构化数据的转换。这种“native daemon socket 事件驱动”的模式是Android系统里最有代表性的底层组件架构。理解了Vold再去看Rild或者反过来都能很快上手因为你不需要重新学一套通信模型只需要学新领域的业务逻辑。6.2 差异一个面向内核一个面向硬件但两者也有一个本质差异它们的“下家”完全不同。Vold面对的是Linux内核netlink、文件系统、加密子系统这些都是Linux标准能力依赖的很多工具比如mkfs、sgdisk也是标准的Linux用户态工具。Rild面对的是Modem硬件它跟Linux内核的关系相对较弱虽然它通过串口或共享内存跟Modem通信但那不是标准抽象出来的东西而是高度厂商定制的。差异导致一个结果Vold做定制开发时更多是去理解Linux已有的机制然后按Android的方式组织起来Rild做定制开发时更多是去理解厂商基带的私有协议然后把它们一一映射到Android的标准接口上。前者是跟内核打交道后者是跟硬件谈判。实际工作中Rild方向的坑通常更隐蔽、更难复现因为Modem的行为很难在用户态看到全面日志。6.3 这种设计给了我们什么启发如果你要在一个新的嵌入式设备上接入新硬件完全可以参考Vold/Rild这套架构跑一个独立守护进程向上暴露socket接口向下对接硬件事件把状态机收敛在守护进程内部上层服务通过命令和回调来驱动它。我在做外设接入方案时曾经照着这个思路写过一个独立的SensorDaemon上层App通过socket发指令底层硬件中断驱动上报事件效果非常好代码维护起来也清晰。Android这层架构经受了这么多年这么多机型的考验照抄它的骨架通常是安全的。7. 实战经验调试Vold和Rild的套路与坑7.1 Vold问题排查从logcat到SELinuxVold出问题最常见的症状有三类存储设备插上之后没有任何反应、设备能识别但挂载失败、挂载成功但上层访问不到。针对这三类我的排查套路是先看logcat里有没有Vold的日志。Vold的关键日志会打到一个TAG为Vold的通道里此外不同子模块还有自己的TAG比如Vold/Netlink、Vold/VolumeManager这些。如果日志里能看到设备事件但没有后续的mount动作说明问题出在VolumeManager决策环节要看代码判断为什么拒绝挂载。如果mount动作已经执行但失败要去dmesg里看具体挂载错误码——是文件系统不识别还是设备忙还是I/O错误错误码能帮你快速缩小范围。如果mount成功了但上层看不到就要看fuse层或者MountService和StorageManagerService那一侧有没有异常。这中间一个非常容易被忽视的坑是SELinux。Android的SELinux策略对Vold有严格限制Vold要挂载设备时需要一系列allow规则比如vold对block_device的访问、对fuse文件系统的挂载等。如果策略里少了一条allow就会在logcat里出现avc: denied的Log而Vold本身的行为往往表现为“静默失败”——上层收到通知说准备挂载然后就没有然后了。为了这个问题我花费过很长时间排查最后发现在某次添加新文件系统支持的时候selinux的file_contexts配置漏掉了对应路径导致Vold根本没有权限创建挂载点的上下文。7.2 Rild问题排查从RILJ到Modem日志Rild问题的排查思路跟Vold有类似的地方但它多了一个难点Modem侧的日志。排查电话问题时标准流程是先复现问题然后立刻抓logcat过滤RILJ、RILC、RILD这些Tag判断问题出在Java通信层、libril分发层还是厂商RIL库层。如果RILJ到rild之间就断了检查socket是否存在、权限是否正确、rild进程是否活着。如果libril到厂商库之间断了大概率是厂商库初始化失败需要看rild进程的启动日志。如果厂商库已经把请求发给Modem了但没有响应问题就出在Modem内部需要抓Modem日志。Modem日志在多数平台上是独立的一套log系统要进入Modem的调试模式才能抓到。我遇到过一种很隐蔽的情况RILJ发了一个查询网络状态的请求libril等了很久超时于是发了一个排队的cancel请求最后上层的ServiceStateTracker状态错乱手机显示“无服务”。后来抓Modem日志才发现第一个请求Modem其实已经处理完了但响应在回传途中被厂商库的一个状态标志卡住了。这种问题如果只看logcat是永远解不出来的必须把Modem侧日志拉出来对比。7.3 我在项目中踩过的几个具体坑第一个坑是Vold卸载SD卡时返回“设备忙”。上层明明已经停止了所有访问Vold执行umount还是报EBUSY。查了很久发现是MediaProvider在后台的MediaScanner线程还占着文件句柄umount时那批句柄没有释放干净。这种情况Vold会先尝试lazy umount但lazy umount只是让新访问失败存量句柄依然会阻塞卸载完成。最后我只好在卸载流程里加了额外的等待逻辑确保所有线程终结之后才执行真正的unmount。第二个坑是Rild的异常重启跟系统属性拉锯。某次在开发板上做网络老化测试发现Rild每过一段时间就会重启一次但系统里其他进程都正常。翻了rild的启动脚本和libril源码定位到是某个线程收到一个特定的事件后抛了异常触发了进程退出。重新编译libril并加上日志后发现是一个底层socket读取超时处理不严谨超时后返回错误状态上层没做空值保护直接闪崩。所以读Rild代码时一定要留意那些调用返回值的空指针判断这里是最容易出问题的。第三个坑跟SELinux有关Rild需要的属性非常多尤其是厂商需要读写自己自定义的persist属性时经常会发现属性写进去了但读不出来或者写操作被SELinux拦截但日志级别开得不够高导致看不到avc信息。这时候最有效的做法是临时放宽对应domain的权限然后复现问题拿到完整日志确认是权限原因后再把策略精确收紧。记住改SELinux策略时要用增量方式尽量精确到具体type和class不要图省事直接放一个大范围的allow否则过不了安全审核不说还容易把其他模块搞挂。第四个坑是调试存储问题时不要在用户态进程里长时间阻塞。Vold事件处理线程如果被一个挂载操作阻塞了它会读不到新的uevent这个时候你再插入一个新U盘系统完全无反应。这个问题我见过不止一次很多人以为Vold挂死了其实不是挂死是它的工作线程被某个慢操作拖住了。解决思路是给Vold的关键操作加上超时机制让卡住的操作能及时返回错误而不是无限阻塞。7.4 建议掌握的几个调试命令说实话系统进程这块光靠看源码是不够的一定要养成抓现场的习惯。我这里列几个我平时最常用的命令查看当前挂载状态用dumpsys mount。这个命令会打印出所有已注册的卷、挂载路径、状态。排查存储问题时第一件事就是跑它。查看Vold相关的logcat用logcat -s Vold Vold.VolumeManager Vold.NetlinkManager只过滤Vold相关通道日志量会小很多。查看内核最近存储设备的识别情况用dmesg | grep -i sd或者dmesg | grep usb。看设备节点是否存在用ls -l /dev/block/sd*。排查电话问题时用logcat -s RILJ RILC RILD这是最基本的三个Tag。检查rild进程是否在运行用ps -A | grep rild。查看socket节点用ls -l /dev/socket/rild。这还只是最基本的一套。到了真正深挖的时候可能还需要配合systrace、strace、perf等工具去抓进程内部的行为。不管用什么工具核心思想永远是“跟着数据流走”看事件从哪来、命令转到哪去、结果有没有回来。只要这条链路你心里有数什么问题都是时间早晚的事。最后再说两句。这本书第8章我前后翻了好几遍每次翻都有新的体会。Vold和Rild这两个守护进程承载的是一个系统最底层的两条生命线——存储和通信。它们没有UI没有Activity平时存在感为零但一旦出问题体验是灾难性的。真正理解它们靠的不仅仅是读代码而是亲手动一动、改一改、踩一踩坑才能真正把架构设计的取舍和代码实现的细节装进脑子里。希望你看了这篇文章之后能少走一点我当年走过的弯路。