去年我接了一个机顶盒定制项目，系统是安卓9，硬件配置只有1GB内存和8GB存储，预装应用稍微多一点就开始杀后台，桌面切换卡成PPT。经过一轮系统裁剪加性能优化，启动时间从23秒压到12秒，应用冷启动平均快了40%，老设备又活了过来。这类需求在安卓开发里非常典型——系统定制的尽头一定是性能优化，而性能优化到一定深度，又不可避免地要动系统层面的东西。
这篇内容就是围绕这两个关键词展开，面向做系统定制、固件开发、移动端性能优化的工程师，也适合想深入了解安卓底层原理的应用层开发。我会把项目里实际用到的思路、步骤、参数和踩过的坑整理出来，基本是可复现的经验，不是那种泛泛而谈的概念科普。
1. 系统定制：到底在定制什么
1.1 三个定制层级：框架层、内核层、应用层
很多刚接触系统定制的人会以为“定制”就是改改壁纸、换换桌面、加几个预置App，其实这只是最表面的应用层定制。真正深入的系统定制，至少可以拆成三个层级。
第一个层级是内核层，主要涉及设备树配置、内核裁剪、驱动适配、内存调节参数调整。比如你拿到一块新硬件板子，要让它能跑安卓，最先要解决的就是内核能不能识别CPU、内存、存储、触摸屏、显示面板这些基础硬件。设备树（Device Tree，简称DT）就是内核描述硬件信息的文件，很多启动崩溃、外设不工作的问题，最后都能追溯到设备树配置错误。
第二个层级是框架层，比如修改WindowManager来改变窗口行为，修改ActivityManagerService来调整任务栈策略，修改SystemUI来实现状态栏导航栏的动态显隐，还有权限管理、电源管理、闹钟对齐等逻辑都在这一层。框架层的改动影响面最大，改一处可能影响所有应用，所以一般会用源码定制或运行时Hook两种方式来做，源码定制适合固件开发，运行时Hook适合在原生系统上做轻量改造。
第三个层级是应用层，包括预置应用、系统默认设置、桌面布局、开机动画、默认Launcher替换等。这一层最灵活，改动风险最低，也是大多数定制需求集中爆发的地方。
1.2 定制前必须想清楚的三件事
动手改系统之前，先确认三件事，否则后面会反复返工。
其一是目标硬件配置。内存多大、存储多大、CPU几核，这直接决定你能不能保留完整的GMS服务，能不能预装大型应用。低配置设备的首要任务是瘦身，而不是堆功能。
其二是应用兼容边界。定制系统时最怕的是底层改完，某个老版本App不能用了。所以在定方案之前，要整理一份目标应用清单，标明它们要求的SDK版本、需要的系统权限、有没有用到隐藏API。这个清单也是后面做兼容性测试的用例来源。
其三是升级维护路径。系统定制不是一次性交付，后续OTA升级、安全补丁、默认配置变更都需要一条顺畅的维护渠道。如果没有源码管理和版本发布机制，定制的系统很快就变成没人敢碰的黑盒。
提示：如果只是给特定硬件做一个垂直场景的系统（如广告机、收银机、电视盒子），尽量少改框架层，优先用配置文件加应用层方案解决，这样升级系统版本时不容易被合代码冲突拖死。
2. 核心定制环节：从设备树到系统裁剪
2.1 设备树配置：硬件与系统的桥梁
设备树（Device Tree，DT）在嵌入式场景里是绕不开的，尤其是跑安卓的ARM设备。它用dts（设备树源文件）和dtsi（设备树包含文件）描述硬件拓扑，编译后生成dtb文件，内核启动时通过它来匹配驱动。换了一块屏幕、改了一颗触摸IC、调整了内存分区，都要在设备树里同步修改。
我之前调过一块投影仪主板，现象是安卓系统起来后显示花屏。排查了半天，最后发现是显示节点的timing参数里，porch值跟实际屏幕规格书不一致，导致像素时钟和行场同步时序对不上。类似的坑还有：GPIO配置错了导致背光点不亮、I2C总线号对不上导致触摸无响应、中断号冲突导致传感器概率性失效。
设备树配置这一块，经验是拿到一块新板子，先把厂商提供的内核基线跑起来，确认基本功能和串口日志正常之后，再一项一项加外设。一次性把全部外设节点都打开，出了问题往往不知道该查哪里。
系统裁剪的基本思路分四步：
- 建立底包：拿Google原始AOSP对应的版本或厂商BSP包，先把系统完整编一遍，确保基础工具链没问题。
- 按需裁剪模块：用makefile或build配置移除不需要的模块，严格来说先从
PRODUCT_PACKAGES里删，而不是直接删文件。 - 精简预装应用：只保留系统UI、设置、输入法、桌面等必需应用，其余全部下沉到可卸载分区或做成可恢复出厂默认的列表。
- 压缩空间：去掉不必要的语言包、字体、铃声、动态壁纸，将APK做资源混淆和so库裁剪，再用zipalign对齐优化。
在实际项目里，裁剪清单可以用一个简单的表格维护：
| 模块类别 | 保留范围 | 裁剪策略 |
|---|---|---|
| 系统核心 | framework、systemui、settings | 必须保留，但要精简资源 |
| 系统扩展 | wallpaper、livepicker、printspooler | 按需求决定，缺省建议去掉 |
| 输入法 | 中文输入法、语音输入 | 只保留一个默认输入法 |
| 搜索引擎组件 | 不需要则删除全部 | 避免后台联网和推送 |
| 厂商预置云服务 | 全部移除或改为可禁用 | 减少系统负载和隐私风险 |
2.3 定制系统的安全配置提醒
这里必须提一句，定制系统最容易踩的合规坑是默认凭据问题。很多厂商的定制固件为了调试方便，会保留一个默认的ADB调试开关，或者板子上的串口登录账号密码不修改。这种默认配置一旦留到量产阶段，被扫描到就是严重的安全事件。
项目上统一执行的规则是：所有测试账号、调试开关、隐藏后门入口，在发布版本里必须全部移除或改成随机强密码。ADB默认关闭，需要远程调试时通过认证机制临时开启。系统里如果监听了网络端口，全部走白名单策略。
注意：这里的默认凭据指的是你自己定制系统时生成的测试账号密码，不是要去破解任何第三方设备的默认账户。做定制开发时始终要守住一个底线——你是在优化自己手上的设备，不是去动别人的系统。
3. 性能优化：先有数据，再做优化
3.1 性能问题的定级与指标采集
性能优化最忌“凭感觉”。很多开发者发现机器卡，第一反应是“把动画关掉”“把后台清掉”，这种操作偶尔能解决表象问题，却往往掩盖了真正的瓶颈。标准做法是先定级，再定量，最后再定位。
根据项目经验，我把安卓性能问题分成五级：
- 冷启动速度。开机到Launcher完全可交互的时间。
- 应用启动速度。点击图标到首帧完全绘制的时间。
- 流畅度。以掉帧率、卡顿次数、FrameMissed等指标为主。
- 资源占用。CPU、内存、IO、网络占用是否异常。
- 发热功耗。长时间运行下电池温度、功耗是否超标。
每个级别的优化手段完全不同，先从最明显的定量指标入手，再逐层深入。
3.2 常用性能工具链解析
工具方面，最常用的还是Android Studio自带的性能分析器，它集成了CPU、内存、网络、能耗四个监控面板，适合应用层开发做初步分析。但要深入系统层，Systrace（现在推荐Perfetto）是刚需。
Perfetto可以抓取系统全局的trace，包含CPU调度、GPU渲染、Binder事务、锁竞争等数据。抓一次trace，就能看到卡顿发生的那个时间点里，主线程在等什么、CPU是不是在大小核之间来回迁移、哪个Binder调用阻塞了关键路径。
再往下沉，是内核层的ftrace和perf。当问题复杂到需要看内核态行为时，可以用ftrace跟踪特定函数调用，比如看某个驱动的中断处理耗时，或者用perf采集性能计数器的热点。
还有一类工具是做专项性能检测的，比如DroidRender可以看渲染管线中每一步的耗时，Video Transcoder这类工具适合处理视频编解码的性能基准测试。选工具不建议贪多，每个专项选一两个最顺手的就行，关键是能稳定复现问题场景。
3.3 性能优化的常见靶子：CPU调度、内存、IO、渲染
从系统定制的角度看性能优化，我认为核心靶子就四个。
CPU调度层面，安卓使用内核的CFS调度器，配合大小核架构时，调度策略直接影响应用响应。项目里常用的优化方向是调整cpu governor参数、配置cpufreq的调频策略、用cpuset把前台应用固定在大核上跑、把后台任务限制在小核上。这套参数在init.rc或device.mk里可以配置，但不同SoC平台的调法完全不同，建议以平台原厂配置为基线去做梯度调整。
内存层面，首先要关注低内存杀进程（LMK）的参数。低内存设备上，LMK阈值设置不合理会导致频繁杀应用或杀不干净。其次要调整ZRAM大小和压缩算法。对于1GB内存的设备，ZRAM设置到512MB左右会有明显改善，但压缩算法选lz4还是zstd，要在压缩比和CPU开销之间做平衡。
IO层面，文件系统挂载参数、I/O调度器、预读窗口大小都会影响应用安装和启动速度。像f2fs这类专为闪存设计的文件系统，随机读写性能比ext4有明显提升，但要注意和内核版本的兼容性。
渲染层面，SurfaceFlinger和HWUI是两大关键。系统定制时要注意GPU合成、硬件Overlay层的分配，尽量减少GPU合成数量和GPU等待时间。应用层则要注意Overdraw，减少重复绘制。
4. 移动端性能优化的实操路径
4.1 启动速度优化：从开机到桌面
开机时间优化的核心思想是“能并行不要串行，能懒加载不要提前加载”。
定制系统里，开机启动的应用很多都是被动的：开机广播接收器、开机自启服务、预置应用冷启动。优化的第一步，是把开机广播接收器全部拉出来过一遍。能用ACTION_BOOT_COMPLETED之外的触发方式就尽量改掉，比如用户首次使用某功能再触发初始化。有些系统应用是必须开机启动的，比如电话、短信（在手机上），但在盒子和广告机场景里完全可以禁掉。
第二步是优化SystemServer的启动流程。SystemServer是安卓系统启动的核心服务进程，里面按顺序启动了几十个服务。这部分逻辑一般不会大改，但可以通过忽略不必要的服务、延迟非关键服务到系统空闲时启动来优化。调试时还可以用debug.sf.nobootanimation=1临时关闭开机动画，方便观察真实启动进度。
4.2 渲染与掉帧优化：垂直同步之外的秘密
说到掉帧，绝大多数人第一反应是“卡在了垂直同步”。但实际分析下来，掉帧的原因远不止这一种。
在Perfetto的trace里，一个流畅的帧应该是这样的：应用进程先做测量、布局、绘制，生成DisplayList，然后通过Binder交给SurfaceFlinger合成，最后在下一个VSync信号来临时提交到屏幕。任何一个环节超时，都会导致本次VSync错过，出现掉帧。
常见原因包括：
- 主线程有耗时操作，比如JSON解析、IO读写、共享Preferences提交。
- 布局层级过深，导致测量和布局阶段耗时过长。
- GPU负载过高，导致渲染管线反压。
- 渲染线程锁竞争，比如频繁访问同一个线程安全的对象。
项目里排查掉帧问题时，一般流程是：先用Perfetto抓trace，看是App线程耗时还是SurfaceFlinger耗时，再到对应的工具里去定位具体函数。如果是App线程耗时，就回到代码层面优化；如果是SurfaceFlinger耗时，可能是GPU负载或合成策略问题。
4.3 内存与线程：低内存设备上的生存之道
内存优化是最能体现系统定制价值的领域。老设备上跑新版本安卓，最大的瓶颈往往不是CPU，而是内存不足以支撑新系统默认配置。
项目里的做法，首先是改ZRAM参数：
# init.rc或fstab中设置ZRAM大小与算法 /dev/block/zram0 none swap defaults zramsize=536870912,algorithm=lz4其次是调整LMK阈值。安卓的lmkd通过在内存压力达到一定阈值时杀死低优先级进程来释放内存，阈值配置存在于/sys/class/lowmemorykiller/或lmkd的守护进程配置中。这里要根据系统的实际使用场景来调：如果是单一App的专用设备，可以大幅度降低杀进程的积极性；如果是通用设备，就要平衡前后台应用的存活率。
线程优化方面，排查思路是看两个极端：线程太少导致串行化，线程太多导致频繁上下文切换和锁竞争。可以通过Thread.getAllStackTraces()快速打印线程状态，分析是否有线程长时间处于WAITING或BLOCKED状态。
5. 系统定制与性能优化的联动实践
5.1 动态系统栏与刘海屏适配实例
Android 15开始，动态显示和隐藏状态栏、导航栏成为系统厂商很关注的能力，尤其是在全面屏和折叠屏设备上。系统定制的需求通常是这样：用户在看视频、玩游戏时自动隐藏系统栏，全屏沉浸；退出时再恢复显示。
框架层实现上，核心是SystemUI的WindowManager逻辑。系统栏的显隐由WindowManagerPolicy和SystemUI的StatusBar、NavigationBar控制。系统定制时，一般通过监听应用窗口的layoutParams.systemUiVisibility或WindowInsets变化来判断是否进入全屏模式，再配合WindowManager.LayoutParams.LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES处理刘海屏区域的避让。
这里最容易踩的坑是：系统栏动态隐藏时，应用的布局来不及重新计算，导致顶部内容被状态栏遮盖。定位方法是分别在显示和隐藏状态下抓取应用的窗口insets值，确认应用是否完整处理了窗口Insets变化。
5.2 流媒体低延迟播放的缓存设计
流媒体场景下，系统定制和性能优化的结合点非常典型。拿RTSP协议做视频监控预览来说，如果直接按默认策略缓存数据，画面会有好几秒延迟；如果完全不缓存，网络抖动又会造成花屏和拖影。
我在项目中采用的方案是：动态调整接收缓冲区大小。在弱网下，把缓冲区加大，用延迟换流畅度；在强网下，把缓冲区压到最小，用流畅度换低延迟。这套逻辑既要改底层播放器的接收环节，又要定义上层的策略切换标准，算是系统定制和业务优化的典型案例。
具体实现上，可以用一个动态调整的环形缓冲区，根据帧间隔抖动、接收速率和丢包率三个指标计算缓冲深度。每收到一帧，判断当前网络等级，按比例增大或缩小缓冲容量，同时限制变化频率，避免缓冲深度频繁抖动导致画面忽快忽慢。
5.3 模拟器与虚拟机工具怎么选
做系统定制时，经常需要在不同ROM之间快速切换测试。我自己的习惯是：搞开发调试用Android Studio自带的模拟器，因为和IDE集成度最高，能直接抓取CPU、内存等指标；做游戏ROM兼容性测试用VMOS这类安卓虚拟机，因为能在不需要重新刷机的情况下快速切换系统环境；跑老游戏平台则用FBneo这样的模拟器，因为它更专注于特定硬件平台的兼容性和性能还原。
选工具没有绝对标准，关键是看你要验证的目标是什么。模拟器再真实，也无法完全替代真机上的温度、续航、IO性能表现，所以最终验收一定要回到真机上做。
6. 常见性能问题排查与避坑清单
6.1 性能问题速查表
下面这个表格是我整理的问题排查清单，按照“现象 → 可能原因 → 排查工具 → 解决方向”来组织，实际工作中可以直接照抄：
| 现象 | 可能原因 | 排查工具 | 解决方向 |
|---|---|---|---|
| 开机慢 | 开机自启应用多、SystemServer启动慢 | Perfetto开机trace、logcat | 精简BOOT_COMPLETED接收器、延迟非关键服务 |
| 应用启动白屏 | 冷启动初始化耗时、启动页布局复杂 | Android Studio Profiler、Perfetto | 减少首帧前初始化、异步加载、启动页合理分流 |
| 掉帧卡顿 | 主线程耗时、过度绘制、GC频繁 | Perfetto、GPU渲染模式分析 | 优化主线程任务、减少overdraw、优化内存分配 |
| 内存不足被频繁杀后台 | LMK阈值不合理、ZRAM不足 | dumpsys meminfo、lmkd日志 | 调整LMK阈值、增大ZRAM、压缩预装应用内存 |
| 发热严重 | CPU调频策略激进、唤醒频繁 | perf、powerstats | 调整调频梯度、合并唤醒源、优化后台任务 |
| IO读写慢 | 文件系统碎片、磁盘满 | iostat、df、f2fs状态 | 清理空间、调整IO调度器、日志落盘尺寸缩小 |
提示：排查问题时尽量一次只改一个变量，不要同时动LMK、ZRAM、CPU调频多个参数。混合改动后如果问题变好，你不知道是哪一个起了作用；如果问题变坏，你也不知道该还原哪一个。
6.2 那些文档里不会写的独家经验
最后分享几条干私活总结出来的经验。
第一，定制系统前先做“减法”再做“加法”。很多优化问题其实在需求阶段就已经埋下了，比如系统里预装了太多不必要的东西。先删到不能再删，再一层层加回必须的功能，这样才知道哪些功能是性能的真正负担。
第二，不要在低端设备上直接套用高端默认配置。不同配置的设备，ZRAM大小、LMK阈值、cpuset策略都应该不一样。我做过一个对比：同样一台1GB内存设备，默认配置下同时打开8个App，第6个开始杀后台；优化配置后可以稳定保留10个App。差别非常明显。
第三，性能优化要有回归测试机制。同一个系统参数在A版本上有效，在B版本上可能就会引入新问题。项目里最好维护一个自动化测试集合，每次改动后自动跑一遍关键场景，至少覆盖应用冷启动、页面滑动、多任务切换、长时间待机这几个核心场景。
第四，日志别乱打，也要定期清理。很多系统卡顿其实是日志系统撑爆的。应用层代码里如果有高频日志打印，即使级别是debug，在长时间运行下也可能导致IO持续占用。定制系统时，建议默认关闭所有非必要日志输出，需要调试时再按模块开启。
结尾
这批项目结束后，我最大的体会是：系统定制和性能优化本质上是一件事——让软件和硬件处于最舒服的配合状态。系统定制不只是给ROM做美容，性能优化也不只是把代码改快一点，两者交叉的部分才是真正体现经验价值的地方。
最后再分享一个实际工作中的小技巧：手动改系统参数调试时，尽量把每次改动记录下来，包括改了什么、在哪个文件、当前版本效果如何。哪怕只是一个echo 100 > /sys/...这样的临时命令，也值得记。因为性能优化往往是反复试错的过程，有了记录才有对比，有了对比才能判断改动到底是正向还是负向。这套方法不一定多么高科技，但长期坚持下来，比任何花哨的工具都管用。
