Android车机与PAD性能优化：八维指标、adb命令与回归表

简介面向Android系统与应用开发者的性能优化专题文档聚焦PAD与车机两类项目的实际调优场景围绕开机速度、响应速度、内存管理、系统稳定性、数据传输、数据流量、存储容量与模块功耗八个方向展开并补充adb常用命令在调试中的用法。压缩包仅含1个docx文件大小约10.32MB便于集中查阅与整理成个人优化清单。文档结合14类集成应用APK响应时间测试、冷热启动差异、内存泄露与ANR/Crash排查、Monkey与CTS兼容性测试等具体内容给出可落地的分析思路和检查项适合需要系统梳理Android性能优化框架、对照项目查漏补缺的开发者参考。已有687人学习下载。1. 车机冷启动 30 秒的痛靠八块拆解慢慢治车机项目刚接手那会儿最怕的不是功能做不出来而是每天早上冷车点火屏幕黑着等三十多秒。用户不会关心你 kernel 里链了多少驱动他只会说这台机器卡。Android 性能优化落到 PAD 和车机这两个形态上跟手机完全不是一套打法车机烧油不靠电池功耗可以让位给启动速度和稳定性PAD 的 BSP 是内嵌打包的 bin模块功耗基本无解只能在应用层做对比兜底。这份笔记把优化拆成开机速度、响应速度、内存管理、系统稳定性、数据传输、数据流量、存储容量、模块功耗八个方向每一块都配了判定指标和能直接跑的 adb 命令。它适合手上有一台真机、被 ANR 和开机时间追着跑、需要拿数据说话的 Android 系统工程师不适合想找现成框架直接套的人。2. 开机速度把一次冷启动切成四段逐段砍掉日志、驱动和预加载2.1 冷启动链路上谁在吃时间开机时间不是一个数字是一条链。从按下电源键到 Launcher 第一帧可见中间依次经过 bootloader、kernel 初始化、init 解析 rc 文件、zygote 孵化、SystemServer 起服务、PackageManager 扫描 APK、开机动画退出、Launcher 冷启动。任何一段出问题整体就慢而大多数人只盯着最后那段动画这就是典型的抓错对象。我一般先把这条链切成四段来记kernel 段从内核入口到 init 运行、init 段解析 rc、起 native service、SystemServer 段起 Java 服务、扫描包、App 段Launcher 首帧。车机还会多出 MCU 唤醒、倒车影像优先级抢占这些平台特性PAD 则常常败在预装 APK 太多、首次启动 dex2oat 编译上。分段的意义在于你后面做的每一次删减都能对应到具体的段里去而不是靠感觉说好像快了点。分段之后要定的就是判定标准。我的习惯是kernel 段不超过 3 秒init 段不超过 2 秒SystemServer 到开机动画退出不超过 12 秒Launcher 首帧在动画退出后 1.5 秒内出现。超过任何一条就进对应段里查。这套阈值不是标准答案但它让开机慢变成可追责的具体项。2.2 用 dmesg 时间戳和 logcat 把耗时落到具体阶段拿到机器第一件事不是改代码是抓基线。三条命令就能把大部分信息抓下来注意 dmesg 的时间戳是相对内核启动的秒数logcat 是墙钟时间两边要对齐得靠开机那一刻的BOOT_LOGO或者init打印。# 抓内核启动时间戳重点看 initcall 里谁最慢 adb shell dmesg | grep -E initcall|Freeing unused kernel memory|Run /init | tail -n 60 # 抓整条开机链的 logcatmain 之外一定要带 events 和 system adb logcat -b main,events,system -v threadtime boot_full.txt # 看当前内核命令行确认是否开了 initcall_debug adb shell cat /proc/cmdline第一条命令看的是 kernel 段。Freeing unused kernel memory那一行的时间戳近似就是内核初始化完成、准备跑 init 的时刻initcall那些行如果开了initcall_debug会逐个打印驱动初始化耗时谁在后面拖几百毫秒一目了然。第二条命令的关键在-b参数默认只抓 main 缓冲区会漏掉 events 里的boot_progress_*事件而这些事件恰恰是 Android 官方埋的开机打点从boot_progress_start到boot_progress_enable_screen一条不少。第三条命令确认initcall_debug有没有开这个参数只在调试版内核上开量产版开了会拖慢启动属于典型的为了测而测。logcat 抓下来之后按 tag 过滤出几个关键点BootAnim的启动和退出、ActivityManager的Displayed、PackageManager的扫描起止、SystemServer的总耗时。把这几条时间戳列成一张表哪一段超阈值就非常清楚了。# 从抓到的日志里抠关键打点按时间排序 grep -E boot_progress|Displayed|BootAnim|PackageManager.*scan boot_full.txt | sort -k1,2这里要注意sort的字段threadtime格式下前两列是日期和时间-k1,2才能按时间正序排。如果你的日志跨了零点得先把日期补全否则排序会乱——这个坑我在车机项目上踩过一次因为日志里时间戳没带年份跨年那次直接排反了。2.3 删日志、删驱动、删服务三处改动的边界第一刀砍日志收益立竿见影但要注意边界。kernel 侧的printk等级、Android 侧 logd 的缓冲区大小、init.rc 里的loglevel三处都能调。常见做法是把 kernel 的默认日志等级从 7 降到 4只保留 warning 以上然后关掉CONFIG_DEBUG_*那一批调试配置。这一刀下去 kernel 段通常能省 200 到 500 毫秒具体看平台。# 看 init.rc 和各个 .rc 里配的日志等级与服务状态 adb shell getprop | grep -E init.svc|log.level|persist.log # 运行时改日志等级验证收益重启后失效 adb shell setprop log.level 4init.svc.服务名这个属性族非常有用它直接告诉你某个 native service 当前是 running、stopped 还是 restarting。删服务之前先用它确认服务到底有没有被拉起别删了个从来没启动过的白高兴一场。persist.log.tag系列属性控制的是 Java 侧 log 开关逐个查一遍能发现不少遗留的调试开关。第二刀砍驱动风险最高。做法是在 defconfig 里把不用的CONFIG_*关掉比如没有 NFC 的 PAD 就关掉 NFC 子系统没有 FM 的关掉 FM。但驱动之间有依赖关一个可能连带关掉别的东西所以每次改完必须重新编译并对比vmlinux大小和 dmesg 里的 initcall 列表确认没有引入新的报错。# 先看当前 defconfig 里开了哪些外设相关配置 grep -E ^CONFIG_(NFC|FM|GPS|SENSOR|TOUCHSCREEN|CAMERA) arch/arm64/configs/target_defconfig # 编译后对比内核体积体积降了但启动没快说明这个驱动本来就没耗时 ls -l vmlinux第三刀砍服务主要动 init.rc 里的 service 和 SystemServer 里的startService。判断标准很简单这个服务在整机功能清单里有没有对应入口没有就停。改完用getprop | grep init.svc复查确认服务确实没起来而不是起来又挂了。2.4 预加载类和预装 APK 的减法以及首次启动为什么要单算preloaded-classes这个文件是开机时间的隐形大户。它决定了 zygote 预加载哪些类文件越大zygote 启动越慢但应用启动会快一些是个典型的权衡。很多团队的做法是手工删几行这是错的——这个文件是工具扫描生成的手删会破坏类之间的依赖顺序轻则预加载失败重则开机直接起不来。正确做法是用WritePreloadedClassFile重新跑一遍生成流程基于当前系统实际用到的类重新产出。预装 APK 的扫描耗时在 PackageManagerService 里每个 APK 都要解析 manifest、校验签名、建索引。PAD 项目上预装三四十个 APK 是常态扫描段轻松吃掉两三秒。减法思路是能放到/data下按需下载的就别塞进/system/app必须预装的合并成少数几个包减少 APK 数量本身比减小 APK 体积更有效。# 数一数开机到底扫了多少包和预装清单对一下 adb shell dumpsys package | grep -c Package \[ # 看 dexopt 状态首次启动的编译开销在这里 adb shell dumpsys package dexopt | head -n 40首次启动要单独算是因为它和二次启动完全是两码事。刷机后第一次起来/data要初始化、所有预装应用要跑 dex2oat 生成 oat 文件、数据库要建表。这一段慢是正常的但慢到不可接受就得优化常见做法是预置编译好的 oat或者把编译过滤器调成quicken而不是speed用一点运行时性能换开机时间。验证方法是连续重启五次第一次和后面四次的耗时分开记录差距超过一倍就说明首次启动没优化到位。3. 响应速度与内存14 个集成 APK 的冷热启动怎么量、内存怎么定位3.1 用高速摄像机和代码埋点测响应时间响应时间的测量有两套方法一套靠外部设备一套靠系统埋点两者要交叉验证。高速摄像机的作用是拿到用户真实感知的时间从手指按下屏幕到画面出现第一帧变化这中间包括了触摸上报、输入分发、应用处理、渲染合成、屏幕刷新任何一个环节都能被拍进去。我一般用 240fps 拍一帧约 4.2 毫秒精度足够。代码埋点拿到的则是应用内部的处理时间两者一减就知道慢在应用里还是慢在系统链路。需要重点测的是那批集成 APK桌面、电话、联系人、短信、相机、相册、云邮箱、音乐、视频、应用中心、安全精灵、主题中心、设置、文件浏览器。这十四个应用有个共同特征——都要做大数据的导入导出和频繁的数据交互联系人要读几千条记录、相册要扫缩略图、文件浏览器要遍历目录它们的响应时间最能反映系统的真实水平。闹钟、计算器、录音机、便签、日历、浏览器、输入法这些轻量应用不用单独测它们的开销已经包含在上面那批里了。# 用 am start -W 拿三个时间注意必须先 force-stop 制造冷启动 adb shell am force-stop com.demo.settings adb shell am start -W -n com.demo.settings/.Settingsam start -W会输出三个字段ThisTime是最后一个 Activity 的启动耗时TotalTime是整条启动链的总耗时WaitTime是 AMS 从发起到收到完成回调的总时间。判断标准看TotalTimeWaitTime明显大于TotalTime说明系统调度层有阻塞。这个命令的局限在于它只统计到 Activity 的onResume返回不含首帧渲染所以要和摄像机数据配合看。3.2 冷启动和热启动的差别以及锁屏解锁为什么要单独算冷启动和热启动的差距可以是三到五倍。冷启动时进程不存在要 fork zygote、加载类和资源、初始化 Application热启动时进程还在后台直接走onRestart到onResume。测量时必须严格控制变量冷启动用am force-stop杀进程热启动按 Home 键回桌面等三秒再拉起两次之间要留足间隔否则系统还没回收完资源。# 热启动测量先回桌面等进程稳定后再拉 adb shell input keyevent KEYCODE_HOME sleep 3 adb shell am start -W -n com.demo.settings/.Settings锁屏和解锁要单独算是因为这里有一堆容易被忽略的动作播放锁屏和解锁音效、加载和解除功耗锁、窗口转场动画、指纹或人脸识别的等待。测法是按下电源键到锁屏画面完全出现算一次点亮屏幕到解锁完成算一次各测二十次取中位数。如果发现解锁慢先用dumpsys power看 wakelock 的持有和释放时机很多时候是某个应用在解锁瞬间抢了功耗锁。# 看当前 wakelock 和窗口状态 adb shell dumpsys power | grep -E Wake Locks|mWakefulness adb shell dumpsys window | grep -E mCurrentFocus|mFocusedApp3.3 meminfo、procrank、showmap 三组数据怎么看内存这块最容易犯的错是只看一个数字。Android 的内存有四个口径VSS 是虚拟地址空间大小包含共享库RSS 是实际驻留物理内存也包含共享库PSS 是按比例分摊共享库之后的物理内存USS 是进程独占的物理内存。看内存泄漏要看 PSS 和 USS 的趋势看整体压力看 RSS看地址空间碎片才看 VSS。# 三组命令各有侧重别只跑一个 adb shell dumpsys meminfo com.demo.settings adb shell procrank -u adb shell showmap -w pid adb shell cat /proc/pid/smapsdumpsys meminfo给的是分项明细Dalvik Heap、Native Heap、Stack、Code、Private Dirty 都在里面适合定位是哪一类内存涨了。procrank -u按 USS 降序排列所有进程适合快速找出大户。showmap -w pid和/proc/pid/smaps给的是虚拟内存区域的逐段明细适合查大块映射和内存碎片。三组数据要落在同一个时间窗口里采否则交叉对比没有意义。我一般会写个小循环每五秒采一次dumpsys meminfo的 PSS 值连续跑十分钟画一条曲线。曲线单调上升就是泄漏波动但收敛就是正常缓存。这个方法笨但比任何工具都可靠因为它测的是真实的运行时行为。3.4 内存泄漏、空指针、ANR、Crash 的定位顺序这四类问题的定位顺序不能乱乱序会浪费大量时间。我的顺序是先 Crash 再 ANR先空指针再内存泄漏。因为 Crash 有明确的堆栈最快能定位ANR 有 traces 文件次之空指针往往是 Crash 的子集单独看是为了找出那些被 try-catch 吞掉的内存泄漏最难需要长时间采样放最后。# Crash 和 ANR 的现场都在 /data 下 adb shell ls -l /data/anr/ adb shell cat /data/anr/traces.txt adb logcat -b crash -v time adb shell ls -l /data/tombstones/ adb shell dumpsys dropbox --print system_app_anr-b crash这个缓冲区很多人不知道Android 会把FATAL EXCEPTION单独丢进去比在 main 里大海捞针高效得多。/data/anr/traces.txt在新版本上会拆成多个anr_*文件按时间戳取最新的那个。dumpsys dropbox里存的是系统级异常的历史记录需要 root 权限才能读全。内存泄漏的排查要结合代码和运行时数据。运行时看 PSS 曲线代码侧看静态引用Context 被静态变量持有、Handler 非静态内部类持有 Activity、Bitmap 用完没 recycle、Cursor 没 close这几类占了系统应用泄漏的绝大多数。空指针则集中在异步回调里——回调回来时 Activity 已经销毁getContext()返回 null这类问题在dumpsys meminfo里看不出来只能靠 logcat 里的NullPointerException堆栈定位。跑分工具BenchmarkPi、Linpack、softweg benchmark可以作为回归参考但不能当目标。它们的测试场景和真实使用差距很大分值涨了不代表用户觉得快。我的用法是每次版本迭代跑一遍分值掉超过 5% 就回头查最近的改动仅此而已。4. 稳定性与数据传输Monkey、CTS 达标线以及 WiFi、蓝牙、SD 卡测速4.1 Monkey 与 CTS 的达标线怎么定系统稳定性的第一道关是 Monkey。它不是随便跑跑就行参数、seed、包名、事件间隔都得固定下来否则两次结果没法比。-p指定被测包--throttle控制事件间隔-s固定随机种子保证可复现事件数按项目要求定车机项目我一般跑两万次起步。# 固定 seed 跑两万次事件间隔 300 毫秒 adb shell monkey -p com.demo.settings --throttle 300 -s 20240101 -v 20000 # 多包场景把 -p 重复写或者用 --pkg-whitelist-file adb shell monkey --pkg-whitelist-file /data/local/tmp/pkgs.txt -s 20240101 -v 20000判定标准要提前写死出现// NOT RESPONDING、// CRASH、** Monkey aborted due to error任何一条都算不通过。跑完之后从 logcat 里把ANR in和FATAL EXCEPTION抠出来逐条归因。这里有个细节-p只对主包生效多进程应用的其他进程不会被覆盖所以要么用白名单文件要么在跑之前确认清楚进程模型。CTS 是另一条线它测的是兼容性而不是稳定性。跑法是用cts-tradefed重点关注arm64-v8a架构下的失败项和CtsOsTestCases这类和系统行为强相关的模块。CTS 失败不一定是你的 bug但每一条失败都要有结论是平台配置问题、是缺少某个 feature、还是真的改坏了。系统的兼容性还包括第三方应用。这块没法穷举我的做法是维护一个二十个左右的高频第三方应用清单每个版本手动过一遍核心路径重点看拉起速度、页面切换、后台驻留这三项。清单不用大但要稳定每次都测同样的一批才能看出趋势。4.2 WiFi、蓝牙、SD 卡读写的测速方法数据传输的测速要区分连接速度和传输速度这是两件事。WiFi 的连接速度看的是关联和认证耗时传输速度看的是吞吐。AP 切换重连速度是车机上特别重要的指标因为车机经常在停车场里跨 AP 漫游。# WiFi 状态和吞吐iperf3 需要在主机端先跑 -s adb shell dumpsys wifi | grep -E mNetworkInfo|SSID|Link speed adb shell iperf3 -c 192.168.1.100 -t 30 -P 4 # 蓝牙配对和传输状态 adb shell dumpsys bluetooth_manager | grep -E state|bondediperf3的-t是测试时长-P是并发流数单流测不出真实带宽四流比较接近实际场景。WiFi 的Link speed是协商速率不是实际吞吐两者差三到五成很正常别拿协商速率当结论。测 AP 切换要写个脚本让设备在两个 AP 之间来回移动记录每次断开到重连的时间。SD 卡测速直接上dd注意块大小要选对太小测不出带宽太大容易受缓存影响。写测试用 1MB 块写 256MB读测试从同一个文件读回/dev/null。# 外置卡写入注意会占空间测完删掉 adb shell dd if/dev/zero of/sdcard/dd_test bs1M count256 # 读回去掉缓存影响可以换一个文件读 adb shell dd if/sdcard/dd_test of/dev/null bs1Mdd的输出里看的是最后那行bytes transferred in X secs直接算 MB/s。内置卡和外置卡的差距通常在两到三倍如果测出来差不多八成是路径没走对或者外置卡根本没挂载成功。云同步速度这块比较虚因为它依赖网络和服务端。我的做法是只测本地侧的耗时从触发同步到数据落盘不含网络往返。这样至少能把客户端的问题和服务端的问题分开。4.3 流量与存储防偷跑和冗余数据清理流量控制的核心是搞清楚谁在联网。Android 的流量统计有好几个来源/proc/net/dev是网卡级别的总量dumpsys netstats是按 UID 分的明细后者才是定位应用的关键。防偷跑流量不是把网全断了而是建立基线正常使用一天消耗多少超过基线就查。# 按 UID 看流量明细和 package 对起来 adb shell dumpsys netstats detail | grep -E uid|rxBytes|txBytes adb shell cat /proc/net/dev # 看某个应用的网络访问记录 adb shell dumpsys package com.demo.settings | grep -i permission应用访问网络的控制和释放重点看两处一是后台唤醒后有没有及时断开连接二是长连接有没有心跳保活导致的持续小流量。这两类问题在netstats里表现为流量不大但频次很高比大流量更难发现。PAD 项目很多不支持蜂窝只涉及 WiFi 流量但这不代表可以放松WiFi 后台偷跑一样耗电。存储容量的优化分两头内置存储靠定时清理冗余数据外置卡靠安全工具及时释放。清理策略要定规则而不是拍脑袋比如日志文件保留七天、缩略图缓存超过 500MB 清一次、崩溃日志上传后本地删除。规则写进代码里别指望用户手动清。# 看存储分布先定位是谁占的 adb shell df -h adb shell dumpsys diskstats adb shell du -sh /data/log/* 2/dev/null | sort -h | tail -n 20du那条命令在设备上跑会比较慢建议限定目录。dumpsys diskstats给的是分类统计能快速看出是应用数据、缓存还是系统占用。4.4 模块功耗在 PAD 上的可做与不可做功耗这块要先划边界。车机烧油功耗优化的优先级排在启动速度和稳定性之后PAD 的 BSP 是内嵌打包的 bin模块级功耗改不动只能做版本间的对比验证。这个现实要认不然会浪费大量时间在改不了的地方。能做的部分集中在应用层音视频编解码的参数选择硬解优先于软解、分辨率匹配屏幕、背光曲线的调整、LCD 和触摸屏的刷新频率、灭屏后的后台限制。音视频这块的收益最明显一个 4K 软解能把整机功耗拉高两三瓦换成硬解加降分辨率能省一半。# 看功耗相关的系统状态 adb shell dumpsys battery adb shell dumpsys power | grep -E mWakefulness|Display Power adb shell dumpsys alarm | grep -c RTC_WAKEUPdumpsys alarm里数一下RTC_WAKEUP类型的闹钟数量太多说明有应用在频繁唤醒系统这是待机功耗的常见元凶。dumpsys battery在 PAD 上能看到放电电流配合固定场景比如播放视频一小时能做出可对比的数据。车机没有电池这个命令的输出意义不大得靠外部功率计。BSP 版本对比的做法是同一场景、同一亮度、同一后台刷两个版本的 BSP各测一小时看电流曲线。差异超过 5% 就值得深挖但能不能改得动是另一回事很多时候只能记录在案等 BSP 供应商下一版解决。5. 避坑排查adb 与日志分析里最容易翻车的五个地方5.1 现象procrank 每次跑出来的排序都不一样现象很直观同一台机器连着跑三次procrank占用最高的进程每次不同数字也飘忽。第一反应会怀疑是不是有进程在偷偷涨内存然后开始到处加日志。原因是 Android 的内存本身就是动态的页缓存、共享库的引用计数、后台进程的回收都在实时变化而且procrank采样的是瞬时值没有固定窗口。你在 A 时刻采到的 PSS和 B 时刻的 PSS 本来就不该一样拿两个不同时刻的数字做对比是无效的。解决办法是固定采样条件先am force-stop掉无关应用等三十秒让系统稳定然后连续采十次取中位数而不是取单次值。对比两个版本时采样脚本、采样次数、间隔、后台应用清单必须完全一致。我后来干脆写了个脚本把这一整套固化下来人只负责看结果。5.2 现象设置里显示的可用内存和 /proc/meminfo 对不上cat /proc/meminfo看到 MemFree 加 Cached 有 1.2GB进设置的应用管理页面一看只剩 900MB差了好几百兆。新手会以为哪里漏算了。原因是设置里的可用内存不是简单的 MemFree 加 Cached它还减掉了一项预留内存SECONDARY_SERVER_MEM这部分是留给二级服务应急用的不参与常规统计。这个计算逻辑在设置应用的源码里getFreeSize() getCachedSize() - SECONDARY_SERVER_MEM就是全部。解决办法是明确口径做性能分析时统一用/proc/meminfo的原始值报告里写清楚是哪个口径别把设置页面的数字和 meminfo 混着用。对外汇报用设置页面的数字用户能对上对内分析用 meminfo能看到细节两套数字各自成立但不能交叉引用。5.3 现象tombstone 里全是十六进制地址看不出是哪个函数打开/data/tombstones/下的崩溃文件调用栈长这样#00 pc 00012345 /system/lib/libxxx.so。地址有了so 也有了但完全不知道对应哪行代码。原因是 native 崩溃的栈里只有相对地址符号信息在编译时生成的符号表里设备上跑的 so 是 strip 过的。要把地址翻译成函数名必须拿带符号的 so 做离线解析而且 so 的版本必须和崩溃时设备上的完全一致差一个编译选项地址就对不上。解决分三步先用addr2line把地址翻成文件和行号再用nm导出符号表做交叉验证最后用objdump反汇编看具体指令。# 三个工具都在 prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin 下 arm-eabi-addr2line -e libxxx.so 0x00012345 # 导出完整符号表-l 带行号 -C 做 C 反修饰 -n 按地址排序 -S 显示大小 arm-eabi-nm -l -C -n -S libdvm.so dvm.symbols # 反汇编-C 反修饰 -d 只反汇编代码段 arm-eabi-objdump -C -d libc.so libc.disaddr2line的-e指定 so 路径后面跟地址输出就是文件名和行号。这里有个前提so 必须是带调试信息的版本strip 过的不行所以每次发版都要把符号文件归档否则线上崩溃只能干瞪眼。nm的-C参数对 C 特别重要不加的话看到的全是修饰过的名字。5.4 现象抓 /proc/kmsg 抓出一个空文件或者命令卡住不动写了个批处理脚本里面有一行adb shell cat /proc/kmsg kmsg.txt跑完发现文件是空的有时候命令直接卡死在那儿。原因有两个层面。第一重定向的位置错了是在主机端生效的但adb shell后面的整条命令是在设备端执行的这个写法实际上是把设备端的输出重定向到了设备端的某个路径主机这边只收到一个空流。第二/proc/kmsg是阻塞读读完当前缓冲区之后不会退出会一直等新日志脚本就卡住了。解决办法是改用dmesgadb shell dmesg kmsg.txtdmesg读完就退出不会阻塞。如果确实需要实时看内核日志用adb shell cat /proc/kmsg不加任何重定向让输出直接打到终端再在主机侧用tee保存。抓上一次重启前的内核日志则读/proc/last_kmsg这个文件是只读快照不会阻塞。5.5 现象adb root 成功但 remount 失败改不了系统分区敲adb root返回restarting adbd as root看着成功了接着adb remount报remount failed: Operation not permitted。换成adb shell进去mount -o rw,remount /system也一样失败。原因是 user 版本的系统默认关闭了 adbd 的 root 能力adb root只是重启了 adbd 进程并没有真的提权。另外 Android 高版本引入了动态分区和 verity 校验/system是只读挂载的不关掉校验根本改不了。解决办法分情况调试版直接adb root adb disable-verity adb reboot重启后再adb remountuser 版本得先刷 eng 或 userdebug 镜像如果只是临时改个文件用adb push到/data/local/tmp再adb shell su -c cp ...绕开系统分区的只读限制。这一条的血泪经验是别在量产机上折腾 remount浪费时间还容易把机器搞成砖。6. 把八块指标收成一张回归表一次抓齐日志并做版本对比做到最后会发现单点优化不难难的是不让已经优化过的东西退回去。我的做法是把八个方向压成一张回归表每个版本刷完机跑一遍指标掉出阈值就拦住。表的结构很简单行是维度列是本次值、上版本值、阈值、结论。维度指标采集命令阈值开机速度Launcher 首帧耗时logcat -b events | grep boot_progress小于 18s响应速度设置冷启动 TotalTimeam start -W小于 800ms内存管理桌面 PSS 十分钟增幅dumpsys meminfo循环采样小于 15MB系统稳定性Monkey 两万次无 CRASH/ANRmonkey -s 固定seed零异常数据传输WiFi 四流吞吐iperf3 -P 4大于 80Mbps数据流量待机八小时后台流量dumpsys netstats detail小于 5MB存储容量/data 剩余空间df -h /data大于 2GB模块功耗视频播放一小时电流dumpsys battery或功率计小于基线 5%采集侧我写了一个批处理插上设备一条命令把现场全抓下来省得每次都手敲。echo off REM 一次抓齐开机后的关键现场输出到以时间戳命名的目录 set STAMP%date:~0,4%%date:~5,2%%date:~8,2%_%time:~0,2%%time:~3,2% set OUTperf_%STAMP:\% mkdir %OUT% adb wait-for-device adb shell dmesg %OUT%\kernel.log adb logcat -b main,events,system -d -v threadtime %OUT%\logcat.txt adb shell dumpsys meminfo %OUT%\meminfo.txt adb shell dumpsys cpuinfo %OUT%\cpuinfo.txt adb shell procrank -u %OUT%\procrank.txt adb shell df -h %OUT%\disk.txt adb shell dumpsys netstats detail %OUT%\netstats.txt adb shell ps %OUT%\ps.txt adb pull /data/anr/ %OUT%\anr\ 2nul adb pull /data/tombstones/ %OUT%\tombstones\ 2nul adb shell screencap /sdcard/shot.png adb pull /sdcard/shot.png %OUT%\shot.png pause这段脚本的关键在-d参数它让 logcat 打完当前缓冲区就退出不会挂住2nul是为了在目录不存在时不报错打断流程。wait-for-device放在最前面保证设备还没枚举完时脚本会等而不是直接抓空。时间戳那一行在中文 Windows 上会带空格所以我做了:\的替换避免路径非法。真正让这张表发挥作用的是对比方式。对比必须满足三个固定固定采样窗口都是开机后静置五分钟再采、固定环境同一亮度、同一温度、同一后台清单、固定脚本版本。少一个条件数据就没有可比性。我吃过一次亏两个版本的测试间隔了一周中间换了测试机结果所有指标都变好了查了半天才发现是硬件差异。从那以后我每次发版前都强制走一遍这张表脚本从版本库拉不用本地改过的版本采集环境写进报告里。慢是慢了点但至少不会再出现上个版本明明优化过这个版本又退回去这种没法交代的情况。希望帮到你。本文还有配套的精品资源点击获取