去年我接了一个机顶盒定制项目系统是安卓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 TreeDT在嵌入式场景里是绕不开的尤其是跑安卓的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.nobootanimation1临时关闭开机动画方便观察真实启动进度。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 zramsize536870912,algorithmlz4其次是调整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/...这样的临时命令也值得记。因为性能优化往往是反复试错的过程有了记录才有对比有了对比才能判断改动到底是正向还是负向。这套方法不一定多么高科技但长期坚持下来比任何花哨的工具都管用。
安卓系统定制与性能优化实战：设备树、内存与启动提速
去年我接了一个机顶盒定制项目系统是安卓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 TreeDT在嵌入式场景里是绕不开的尤其是跑安卓的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.nobootanimation1临时关闭开机动画方便观察真实启动进度。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 zramsize536870912,algorithmlz4其次是调整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/...这样的临时命令也值得记。因为性能优化往往是反复试错的过程有了记录才有对比有了对比才能判断改动到底是正向还是负向。这套方法不一定多么高科技但长期坚持下来比任何花哨的工具都管用。
