Android框架开发这事儿，很多人一听就觉得高不可攀，觉得这是系统工程师的专属领域。但我在这个圈子里摸爬滚打了这么多年，说实话，框架开发的门槛并没有想象中那么高，关键在于你得先弄明白框架到底在解决什么问题，又是怎么把上层应用和底层硬件串起来的。这篇文章我就用自己实际踩过的坑、趟过的路，把Android框架开发这个事儿从头到尾捋一遍，希望能给正准备入坑或者已经在坑边徘徊的朋友一些实打实的参考。
1. 项目概述：框架层到底在做什么
1.1 核心需求解析
先说说框架开发是干嘛的。Android系统从上到下大致分这么几层：应用层、框架层（Framework）、系统运行库层（包括ART虚拟机、各种native库）、Linux内核层。我们平时写App，用的那些API——Activity、Service、ContentProvider、View体系、WindowManager、PackageManager，全部是框架层暴露给应用层的接口。框架层本质上是应用和系统底层之间的“翻译官”和“调度中心”，它把内核的复杂能力封装成一个个清晰的对象和接口，让应用开发者不必直接面对Binder驱动、Socket、内存映射这些底层细节。
所以框架开发的核心需求其实就两块：一是扩展系统能力，比如你要在系统里加一个别人没有的服务，或者给某个已有服务增加新功能；二是打通软硬件通道，比如你的设备有一个特殊的传感器，厂商就得在框架层写代码把硬件数据变成上层能识别的SensorEvent。这两块看似简单，实际做起来涉及的东西非常多，从Binder通信机制、AIDL接口定义，到系统服务的管理方式、权限模型，再到SELinux策略配置，任何一个环节不熟，都会被卡得死死的。
我见过不少开发者，应用层写得很溜，但一看框架层的源码就头大，原因很简单：应用层开发是“你给我什么我用什么”，而框架开发是“我说了算，我定义规则”。思维模式的转换，是入门框架开发的第一道坎。
1.2 这类项目适合什么人
如果你满足下面任意一条，这篇文章就是写给你的：
- 已经有一年以上Android应用开发经验，对
Activity、Service、BroadcastReceiver这些组件的工作原理不再满足于“会用”，想知道它们背后是怎么被系统管理的。 - 在从事系统定制、行业终端、车机系统、电视盒子这类软硬一体项目的开发，经常需要修改或扩展系统能力。
- 对公司自研的ROM或者内部平台方案感兴趣，想搞清楚系统服务、权限、资源管理的来龙去脉。
如果你还完全不会写Android代码，那建议先去把应用层基础打牢，直接上框架层会非常痛苦，因为框架开发涉及的知识深度和广度都远超普通应用开发，没有一定的代码阅读能力、内存模型理解能力和多线程功底，很容易被源码“淹死”。
2. 项目整体设计与技术选型思路
2.1 方案选型背后的考量
做框架开发，动手写代码之前必须先搞清楚一件事：你要在系统哪个层次动手。同一个需求，放在不同层次实现，工作量、稳定性、后续维护难度天差地别。
举个例子，假设产品要做一个“应用启动加速”的功能。这个功能可以有三个实现层次：
- 第一层：纯应用层方案。写一个后台服务，监听应用启动事件，提前预热某些页面。好处是简单灵活，跟着系统OTA走，坏处是受限多，能做的事情有限。
- 第二层：框架层方案。修改
ActivityTaskManager或ActivityManager里应用启动流程的代码，在合适的节点做并行初始化或资源预加载。能力强很多，但需要改系统代码，编译进ROM，风险也大。 - 第三层：底层方案。在ART虚拟机层面做启动加速，或者修改内核的进程调度策略。效果最直接，但可维护性最差，厂商一般不轻易动这一层。
我做框架选型时有一条经验原则：能用上层解决的绝不往下沉，能往应用层靠的绝不做系统级修改。别看框架开发听起来高大上，真正的高手都在克制自己改底层的欲望，因为每往下沉一层，引入的不确定性就指数级增长。系统服务的崩溃可不比App的崩溃，一个SystemServer崩了，整个系统重启的节奏。
2.2 开发模式与分工策略
框架开发和普通应用开发的协作模式是完全不同的。应用开发一般一个人或者一个小团队负责一个模块就行，框架开发不行，它天然要求你与硬件适配、稳定性、安全、性能各个方向的团队协同。
我自己参与过的典型项目里，框架开发的工作流大致是这样的：
- 由架构师或技术经理明确需求落点，确定要修改的模块和层次。
- 负责该模块的框架开发工程师出详细设计文档，这个文档必须包含：涉及的系统服务、
Binder接口改动、权限方案、SELinux策略变更点、资源文件定义、兼容性影响面。 - 评审通过后开始开发，开发过程中要同步维护HAL（硬件抽象层）接口的兼容性，因为框架层和HAL层经常是强耦合的。
- 完成后接入CTS/VTS兼容性测试，以及内部稳定性压测，这里重点看
SystemServer的存活时间、ANR率、进程内存水位。 - 最后才能集成进系统版本。
这套流程看起来繁琐，但能帮你挡掉大量的低级问题和后期返工。我见过有人直接在主线代码上闷头改，结果改完发现和SELinux策略冲突，服务起不来，又花了一整周排查，这种情况真的没必要。
3. 核心技术基础与环境准备
3.1 AOSP源码环境搭建踩坑实录
做框架开发，源码编译环境是最基本也最容易出问题的一环。网上教程一抓一大把，但多是照搬官方文档，实际操作起来坑非常多。我把自己常用的一套环境配置说下，仅供参考。
操作系统我用的Ubuntu 22.04 LTS（64位），内存不低于32GB，磁盘建议预留500GB以上。AOSP全量编译对CPU核心数很敏感，建议16核起步，少了编译时间会让人崩溃。JDK版本要按照你编译的Android版本来选：Android 12及以上用OpenJDK 11（某些版本用17），Android 8到11用OpenJDK 8。这一步搞错，编译到一半直接报版本错误，非常浪费时间。如果你的机器内存不够，建议手动设置swap分区，我一般分40GB左右的swap空间，实测能显著降低OOM导致的编译失败概率。
初始化仓库时，repo这个工具得用对。很多新手镜像源配不好，拉源码拉到怀疑人生。我这里说一个通用做法，从清华或者中科大镜像源拉取主线代码：
mkdir aosp cd aosp repo init -u https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b android-13.0.0_r1 repo sync -c -j16这里有个小技巧，-c参数只拉当前分支，不带历史标签和分支信息，能省不少带宽和时间。如果中途因为网络中断，repo sync续传即可，不用重新拉。拉完源码后用repo status确认当前分支的完整性，再检查有没有未同步完成的异常状态。
编译前要先把环境变量和lunch选好：
source build/envsetup.sh lunch aosp_arm64-userdebug make -j16这个-j16不是越大越好，如果你有32核，可以试试make -j32，但要注意内存。我见过一台128G内存的机器开-j64直接内存溢出的情况。实际经验是make线程数控制在“CPU核心数+2”以内比较稳。
3.2 调试工具链与真机调试经验
框架开发不像应用开发，不能随时在身上插个Android Studio就跑。最常见的做法是刷入userdebug版本的ROM，因为它保留了adb root权限、remount系统分区等调试能力。注意userdebug和eng版本的区别，eng版本有更多调试工具但稳定性差，不适合日常使用。
真机调试框架代码时，最关键的三个工具：
adb logcat -b system：系统服务日志单独拿一个buffer维护，刷Subsystem相关崩溃时，这个命令比全量logcat要清晰得多。adb shell dumpsys：用于查看系统服务的内部状态、内存占用、进程信息。框架服务出了问题，dumpsys的输出往往能直接定位问题模块。adb shell kill -3 <pid>：向SystemServer进程发送SIGQUIT信号，让它打印所有线程的trace信息。遇到系统服务无响应（ANR）时，这是定位卡点最直接的手段。
还有一个我自己很常用的做法：修改框架层的Java代码后，不一定非得整体编译出ROM再刷机，可以单独编译修改的模块。
source build/envsetup.sh mmm frameworks/base/services/core或者用make加模块名，生成的services.jar会输出到out/target/product/xxx/system/framework/下，然后你用adb remount把它推到真机上，重启即可。这套“模块级编译+单独push”的流程能节省大量时间，不用每次都烧整个镜像。我踩过最大的坑就是推完services.jar后忘记adb shell stop&&adb shell start重启zygote和SystemServer，导致改了半天发现跑的还是旧代码。实际上，推完系统框架jar后，要么直接重启设备，要么用adb shell stop && adb shell start热重启Android运行时。
提示：改native层（C++代码）时不能只推jar，因为涉及
.so动态库的更新，最稳妥的做法是重新生成system.img并刷机，或者单独mmm对应的库后adb push到/system/lib64目录并同步刷入，否则极容易出现版本不对导致的加载失败。
4. 核心开发场景深度拆解
4.1 新增一个系统服务的基本套路
框架开发最典型的入门任务，就是新增一个系统服务。比如公司要做一套设备管理能力，需要在系统里新增一个服务，向应用层提供设备注册、状态上报、远程指令接收的接口。这个任务几乎覆盖了框架开发的所有核心知识点，我拿它当例子拆解一遍。
先理解系统服务的整体结构。Android的系统服务都集中在SystemServer进程里，SystemServer启动时会实例化一个个服务，服务实例化之后要注册到ServiceManager（实际是servicemanager这个native进程）中，才能被应用层通过Context.getSystemService()拿引用。
一个标准的新增服务，需要动这几个地方：
第一步定义AIDL接口。框架层服务与应用层通信靠Binder，而AIDL就是Binder接口的描述方式。建议在frameworks/base/core/java/xxx/下新建AIDL文件，声明你的方法，同步编译生成Java接口。
// IDeviceControlService.aidl package com.example.framework; interface IDeviceControlService { boolean registerDevice(String deviceId); String getDeviceStatus(String deviceId); void sendCommand(String deviceId, String command); }第二步实现服务类。新建一个继承IDeviceControlService.Stub的类，放进frameworks/base/services/core/java/com/android/server/目录的合适位置。注意，SystemServer加载服务时要用SystemService这个基类的方式来管理生命周期，这样能自动处理启动顺序、Binder注册、开机阶段调度。
public class DeviceControlService extends SystemService { private final Context mContext; private final DeviceControlServiceImpl mImpl; public DeviceControlService(Context context) { super(context); mContext = context; mImpl = new DeviceControlServiceImpl(context); } @Override public void onStart() { publishBinderService("device_control", mImpl); } @Override public void onBootPhase(int phase) { if (phase == PHASE_BOOT_COMPLETED) { // 开机完成后执行初始化工作 } } private final class DeviceControlServiceImpl extends IDeviceControlService.Stub { // 具体实现 } }第三步在SystemServer中注册。找到SystemServer.java，在startOtherServices()方法里找到合适的启动节点，新增一行mSystemServiceManager.startService(DeviceControlService.class);。为什么用SystemServiceManager而不是手动实例化？因为它能统一管理服务的启动、崩溃重启策略、阶段回调，这是官方推荐的注册方式。
第四步配置权限。新增的新服务如果要对应用层开放，必须声明保护级别。系统服务的权限定义在frameworks/base/core/res/AndroidManifest.xml中，比如：
<permission android:name="com.example.permission.EXECUTE_DEVICE_COMMAND" android:protectionLevel="signature" />第五步处理SELinux。这是新人最容易忘的一步，也是我最想强调的一步。即使你的权限声明好了，SELinux策略不匹配，应用调用服务时照样会收到PermissionDenied或Binder无法建立连接的错误。需要在system/sepolicy/下为你的服务定义service_contexts（或者新版本的service_contexts合并到service_contexts列表），以及对应的te文件。
// service_contexts device_control u:object_r:device_control_service:s0// device_control_service.te type device_control_service, app_api_service, system_server_service, service_manager_type;到这里，一个新服务的基本框架才算搭完。整个流程知识点密度很高，任何一个环节不对都可能导致服务注册失败或者权限不通。
4.2 Binder通信：框架的命脉
Binder是Android系统进程间通信（IPC）的基石，几乎所有框架功能都建立在它之上。你要想在框架开发中游刃有余，Binder的工作原理必须吃透。
用生活里的例子解释，Binder就像酒店的前台。住客（上层应用）需要某个服务（比如洗衣、送餐），不用直接去找洗衣房或者厨房，只需要打前台电话（ServiceManager/Binder驱动），前台会帮你转接到相应的部门。关键点在于：住客拿到的是一个“虚拟号码”（Binder引用），通过这个号码，实际请求会被Binder驱动路由到真正的服务进程。
Binder通信涉及几层内容：
- Binder驱动：位于Linux内核，负责进程间数据传输、内存映射（
mmap）、线程池管理。 - Binder协议：包括
BC_TRANSACTION这些命令字，以及Parcel数据的打包解析。 - Binder对象模型：
BnInterface（服务端Stub）和BpInterface（客户端Proxy），Android源码里自动生成的Stub和Stub.Proxy就分别对应这两者。 - Binder线程池：每个进程默认的Binder线程数量是有限的（默认16个），如果服务端的某个接口方法执行耗时较长，会占用Binder线程，而其他调用者就会排队或者超时。
框架开发中，Binder相关的坑主要集中在这几个方向：
主线程被阻塞导致ANR。如果一个Binder方法里做了耗时的网络请求或者文件IO，且它是在系统服务的主线程中执行，那么其他服务调用（包括系统自带的）都会卡住。正确做法是把耗时操作放到服务端的独立工作线程里执行，或者用
AsyncTask/Executor作为执行载体，Binder方法本身立即返回。Binder对象过大。一次Binder传输的数据量默认上限是1MB（跨进程map和large transaction另有限制），如果你试图在Binder里传个几兆的Bitmap，会直接报
TransactionTooLargeException。所以框架层的接口设计尽可能传递轻量级的数据结构，比如传文件路径而非文件内容。oneway调用。如果你的接口不需要等待服务端返回结果，可以声明
oneway关键字，这样客户端调用后立即返回，不阻塞Binder线程。对于命令下发类的操作非常合适，但要注意：oneway模式下服务端的处理是串行的，如果你希望每个命令都独立处理，还是得在服务端开线程。Binder死亡通知。客户端绑定了远程服务，如果服务端进程挂掉，客户端的Binder就变成了“死引用”。框架服务的死亡监听非常重要，
ServiceManager会在服务进程死亡时清理它的注册信息。自己写服务时，也用linkToDeath来做好联系人管理，避免死连接泄漏。
Binder这块没有捷径，我建议每个想做框架开发的人至少读一遍官方文档里的Binder架构介绍和AIDL源码生成过程，再自己用android.os.Debug跟踪一次transact()的调用栈，心里那个模型就建立了。
4.3 自定义View与UI框架的扩展
框架开发里，UI方向的扩展和系统服务方向完全是另一种风景。很多时候产品需要一套特定的交互控件，而这些控件放在应用层做太重、放在framework里反而能做成公共能力，比如一个支持复杂手势的车载桌面应用或者一套统一设计的系统级弹窗，都要在View层面做文章。
UI框架扩展最核心的技术点在于理解View的测量（measure）、布局（layout）、绘制（draw）三大流程，以及ViewGroup的事件分发机制。框架层开发的自定义View，通常会用系统签名级别的API，避免上层的种种限制。但这不代表你可以为所欲为，你写的类一旦放进frameworks/base/core/java/android/view/并被系统引用，就等于成了系统的一部分，代码质量和兼容性要求随之暴涨。
我做过一个被业务方反复要求的自定义ViewGroup：一个环形扇形菜单控件。它要支持外部旋转和中心按钮点击，还要动态适配不同屏幕尺寸。如果在应用层做，问题不大，因为你可以针对自己App的屏幕环境测试调优。但在框架层做，就必须考虑多窗口、分屏、横竖屏切换各种形态，还需要处理Configuration变化。
在做这个控件的onLayout时，我一直卡在嵌套布局的不规范上，后来索性先在一张纸上画出手势到控件状态的映射关系图，再动手写代码。这个过程虽然繁琐，但能帮你理解为什么框架层的View代码看起来比应用层的复杂得多：因为它的边界条件和状态组合数量呈指数级上升。
UI框架扩展还有一个很有用的场景：系统级别的侧边栏、状态栏定制、悬浮窗方案。这些都要跟WindowManagerService打交道，涉及窗口层级、焦点处理、输入事件分发等框架核心模块。想做这块，建议先研究系统自带StatusBar的代码，Android的StatusBar本身是一个SystemUI的独立应用，通过WindowManagerService将窗口添加到指定层级，是理解“窗口管理和应用层解耦”的最佳学习材料。
4.4 硬件对接与HAL层交互
框架开发绕不开硬件对接。Android的硬件访问路径是这样的：最上层是应用框架API——接着是SystemServer里相应服务的Java代码——然后通过JNI调用native层——再往下是HAL Interface（比如hardware/libhardware中的hw_get_module）——最后是具体厂商的.so实现——最底层是内核驱动。
公司要做一功能模块，比如一台上报体温的设备，框架层就要打通从传感器到应用层的整条链路。这里面的难点不在Java部分，而在JNI和HAL接口的对接上。JNI层要用C++写一个中间层，把HAL拿到的数据转换成Java可以调用的jobject，或者反过来。这个过程很容易出内存泄漏和类型转换错误，尤其是传byte数组时，要注意JNI引用的释放。
HAL层写接口时通常要定义一组标准的回调函数，比如：
typedef struct temper_device { struct hw_device_t common; int (*init)(struct temper_device_t* dev); int (*get_temperature)(struct temper_device_t* dev, float* value); } temper_device_t;然后上层JNI通过hw_get_module(TEMP_HARDWARE_MODULE_ID)拿到这个结构体，调用对应的函数指针。每次硬件数据变化，底层主动回调到JNI，再通过JNI调用Java层接口把值更新上去。这个链路里任何一环超时或者崩了，后台日志都是碎片化的，排查很痛苦。我的经验是各层多打可追踪的log，并且给每一步都设定超时和异常兜底。
4.5 资源与包管理框架的常用修改
框架开发里PackageManager（PMS，包管理服务）和ResourcesManager（资源管理）是绕不开的两个大头。它们的代码复杂度在Android系统里数一数二，动不动就上千行的方法，修改时需要特别小心。
PMS负责所有APK的安装、卸载、权限授予、组件查询。框架开发中常见的需求有：
- 预置应用：把内部开发的APK预置到
/system/app或/vendor/overlay目录，刷机后自动安装且不可卸载。 - 系统级权限白名单：调整
signature级权限的授予范围，让特定应用能访问系统API。 - 禁止安装第三方应用：在
installPackageAsUser方法里加拦截逻辑，判断包名或签名后直接拒绝。 - 应用启动管控：限制后台应用的数量或白名单之外的应用不允许自启。
ResourcesManager涉及的则是资源查找与主题切换。系统默认主题或者字体等，都可以在ResourcesManager或AssetManager层做全局拦截和替换。常见的全局换字体方案，就是在AssetManager的addAssetPath环节偷偷替换system_fonts.xml指向的资源。
做这些修改时，最要注意的依然是PMS的稳定性。你改的是所有应用的基础设施，一个空指针就可能让整个开机流程崩掉。所以改PMS前要把所有系统包名列表和时间点记录好；改动后要确保package_manager服务能快速恢复，不能因为你的代码阻塞住ActivityManager的启动。
5. 整个项目的实操过程记录
5.1 从需求到上线完整流程
作为一个已经跑完多个框架开发项目的老人，给大家梳理下标准流程应该怎么走。
首先，不要一上来就看代码。先从需求文档中提取出“要改哪个层次”和“涉及哪个模块”，然后去翻阅相关模块的系统架构图。可以把Android源码官网的架构浏览器当成地图，先看清楚整个ActivityManager/WindowManager/SystemServer的模块路径。心中有地图，代码才不会跑偏。
其次，搭建可复现的开发环境。我强烈建议在项目初期就维护一份“源码编译环境笔记”，记录你的JDK版本、Python版本、repo分支、内存配置、编译时间、常见报错与排查记录。第一次编译全量系统可能需要2~4小时甚至更久，环境的坑不及时记录，后面重装系统时就等着哭。
再次，小步快跑。框架开发最忌讳一次改动几百行。哪怕你的目标功能需要写很多代码，也建议先搭一个最小可运行骨架，验证链路通了，再逐步加逻辑。比如新增服务，先让客户端能拿到服务引用，能调用一个空的接口方法返回true，然后再去实现具体功能。链路不通，一切白搭。
最后，善用系统自带的测试工具。Android系统源码里每个服务模块都有对应的单元测试和instrumentation测试框架，比如frameworks/base/services/tests目录下的测试几乎覆盖了所有系统服务。不是必须跑全部，但至少你改动模块的子集要能通过。
5.2 编译与构建细节补充
来说说我个人在编译上踩过的一些具体坑。
一是切换分支时缓存混乱。如果你从android-12切到android-13，一定要make clean，或者干脆删除out目录重新建立。我因为在切换版本后直接增量编译，跑完发现代码不生效，最后不得不整个重编。这个时间成本太高了。
二是jack-server（历史版本）的内存问题。Android 8之前的版本用jack编译器，经常报out of memory，要改~/.jack目录下的配置。Android 10开始换成R8/D8等新链后这种问题少了，但如果你编译旧版本源码，还是要先查一下对应版本的编译工具链说明。
三是模块编译路径混乱。单独修改一个模块时，尽量在make和mmm之间保持清晰。比如你改了framework/base/core下的Java代码，会生成多个jar产物（framework.jar、framework2.jar等），推入设备时经常出现新旧混合的情况，导致界面无响应。我的习惯是：每次mmm编译完后，用adb shell md5sum /system/framework/framework.jar对比本机产物和设备上文件的md5，确认一致再继续调试。
四是磁盘空间。out目录占用极大，经常50GB打底。如果是AOSP全量源码，最终体积会在100GB以上。务必提前清理多余的增量备份和中间文件。
5.3 框架模块的单元测试与集成验证
单元测试在框架开发中的地位被很多人低估了。应用开发可以不写测试，反正线上有各种兜底，但在框架层，一个无意的修改可能影响千万台设备，必须有完善的回归测试方案。
Android框架的测试分为几个层级：
- 本地单元测试：用
LocalUnitTests在开发机上跑，不依赖设备，适合测试服务里的纯逻辑部分。 - 设备端测试：通过
adb部署到测试设备上跑，需要Android系统的Instrumentation支持。 - CTS/VTS测试：Google提供的兼容性测试套件，强制要求通过才能通过认证。你的框架改动如果不通过CTS，等于这个ROM不合法，很多系统应用和服务都会出问题。
我参与项目时的测试流程是：先写服务层单元测试，验证服务实例化和接口数据正确；再写设备端测试，验证Binder调用链路和权限控制；最后跑对应模块的CTS集中用例。CTS很耗时，但跑一次能换来上线的底气。
6. 常见问题与排查经验
6.1 编译与启动流程高发问题
这几类问题是我在实际项目里遇到频率最高的，整理个速查表方便大家快速定位：
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 编译报JDK版本错误 | 本机JAVA_HOME指到了错误的JDK | 确认目标Android版本对应的JDK版本，调整JAVA_HOME并重新source envsetup.sh |
| SystemServer启动崩溃 | 服务初始化抛异常，通常NullPointerException或ServiceNotFoundException | 查logcat中的SystemServer崩溃栈，确认是哪个服务启动失败，排查其onStart()实现 |
Binder调用返回DeadObjectException | 对端服务被杀或Binder连接失效 | 确认服务进程是否存活，dumpsys activity services查看，必要时重启框架服务 |
| 权限验证失败 | SELinux策略未配置或权限保护级别过严 | 检查dumpsys package和dumpsys service输出，确认进程上下文与te文件的对应关系 |
dumpsys输出为空 | 服务未成功注册到ServiceManager | 确认publishBinderService是否调用，servicemanager里能否查到该服务 |
这些问题的排查逻辑其实是有通法的：先看logcat，再查dumpsys，最后看SELinux的avc日志。SELinux的日志通常出现在dmesg或者logcat的avc段，不要一上来就瞎猜。
6.2 运行时崩溃与性能瓶颈定位
框架层崩溃的定位比应用层难得多，但有几个通用工具能大幅提速。
- Debuggerd：当native进程崩溃时，
debuggerd会生成tombstone，记录包括寄存器、调用栈、内存映射在内的崩溃信息。通过adb shell ls /data/tombstones能看到所有tombstone文件，取最新的分析即可。 - Java堆栈：如果进程还没挂，通过
kill -3或am dumpheap抓取hprof文件，用Android Studio的Memory Profiler来分析内存泄漏和对象分配。 - Systrace：解决UI卡顿和系统服务耗时问题时，
systrace是看事件时间线的好工具。直接运行python systrace.py --time=10 -a SystemServer，能抓出系统服务里哪个方法耗时最长。
我还遇到过一种很隐蔽的坑：系统服务里用了单例，而单例在多线程环境下初始化时线程不安全，导致服务时好时坏。定位这种难题，光靠代码review不够，要在onStart里加好同步锁，必要时用CountDownLatch来做初始化屏障。
6.3 兼容性测试失败的处理思路
CTS失败不能只看单个case，要看它是不是由你修改的模块引起的连锁反应。我遇到过CTS的Signature权限用例失败，追根溯源发现是自己在PMS里错误地修改了getPackageInfo的flags判断，导致曝光了本不该曝光的系统组件。
处理CTS失败的通用步骤：
- 获取完整的CTS失败报告和分析日志。
- 在本机上重现失败的case，如果无法在模拟器复现，就在测试设备上手动跑对应模块。
- 用
binary search的方式逐渐注释掉自己的修改，定位是哪一处改动触发了失败。 - 针对性修复后，回归同类用例至少通过90%以上再上报。
这里要特别提醒：CTS报告的失败有时候是环境或设备引起的，未必是你改的代码。先排除设备存储空间、系统时区、网络连接这些干扰因素，再怀疑自己的修改。
7. 个人实操中的几点总结分享
文章写到这儿，核心内容讲得差不多了。最后再说几句我在实际项目中有体会的话。
框架开发不是“改完代码编译刷机”就结束的，它其实是一个系统工程。你要有耐心读几万行源码，要习惯日志里找不到明确报错，要接受改一行代码可能影响几十个模块。但这些东西想通了之后会非常“上瘾”，因为你看待Android系统的眼光会彻底改变。每次系统更新，你不再只关心界面变了什么API，而是开始分析它底层的调度、内存、Binder策略发生了哪些调整。
对于刚入门的同学，我建议从阅读源码开始，不要急于上手改代码。可以先跟着ActivityTaskManager的应用启动路径，把startActivity到ActivityRecord创建的过程读一遍，再对照官方架构图，找到各个模块的对应关系。把这块啃下来，后面开发基本就顺了。
另外，团队协作时一定要有“系统全局观”。框架层的很多服务相互依赖，你在A服务里加的一个延迟任务，可能让B服务在某个时间点收到晚到的通知，进而触发一个谁都没料到的状态。动框架代码之前，建议先画一张改动影响的时序图，把跨服务的调用链梳理清楚。
框架开发的门槛不低，但正因如此，它带来的成长也是普通应用开发不太容易比拟的。你会从“调API的人”变成“定义API的人”，这种角色的转换，是整个职业生涯很值得体会的经历。
