目录一.背景二.Perfetto使用流程阶段一抓取 Perfetto Trace 文件1. 指令核心解析2. 数据源功能详解 (这些是抓取的“维度”)3. 该指令的作用场景阶段二导入并认识 Perfetto UI 面板1. 致命异常Duration: (Did not end)2. 定位到的业务范围1. 核心异常CPU 4 被 dnsmasq 进程占满2. 线程唤醒关系system_server 在“垂死挣扎”3. 渲染线程 (RenderThread) 的反常表现综合诊断结果三.结合日志排查1. 核心含义dnsmasq 疯了CPU 占用接近 100%2. 为什么会导致 Settings ANR3. dnsmasq 是干什么的TetherOffload HAL 与 dnsmasq1. 技术背景为什么需要 TetherOffload2. TetherOffload 的作用3. 两者的具体协作与区别协作流程4. 总结它们是互补的四.修复TetherOffload 相关内容后一.背景测试提了一个问题Settings中打开热点后直接卡死然后anr之前我一般都是通过日志和AndroidStudio Profile进行分析的需要看我之前分析流程的可以参考如下资料https://blog.csdn.net/gongjdde/article/details/134859886本次使用Perfetto结合日志进行排查二.Perfetto使用流程阶段一抓取 Perfetto Trace 文件抓取数据主要有两种方式对于排查系统层面的服务死锁和底层阻塞强烈推荐使用命令行方式因为你可以精确配置需要监控的数据源。1. 命令行方式推荐通过adb连接你的测试设备在终端输入以下命令。这个命令会抓取 CPU 调度、系统调用、Binder 通信以及核心系统服务的状态。adb shell perfetto -o /data/misc/perfetto-traces/trace_file.perfetto-trace -t 15s sched freqs idle am wm gfx view binder_driver hal dalvik res-t 15s表示持续抓取 15 秒。你可以先敲下回车开始录制然后在手机上迅速复现那个“打开网络设置导致卡顿”的操作。以下是对该指令各部分的详细拆解1. 指令核心解析adb shell: 通过 ADB 在 Android 设备内部执行命令。perfetto: 调用系统中的性能跟踪程序。-o /data/misc/perfetto-traces/trace_file.perfetto-trace:指定输出文件的存储路径。路径通常位于/data/misc/perfetto-traces/因为该目录具有合适的读写权限抓取完毕后可以用adb pull将文件传回电脑进行分析。-t 15s: 指定跟踪时长为 15 秒。执行后系统会立即开始记录15 秒后自动停止并保存文件。[数据源列表]: 紧跟在末尾的参数sched freqs idle am wm gfx view binder_driver hal dalvik res是数据源Data Sources用于指定需要记录哪些内核和应用层的事件。2. 数据源功能详解 (这些是抓取的“维度”)这些参数决定了 Trace 文件中包含哪些信息sched:调度器事件。记录 CPU 线程的调度信息Task 切换、唤醒、休眠。这是分析“卡顿”最核心的数据。freqs:频率信息。记录 CPU 频率CPU Freq的变化。用于分析是否存在 CPU 降频导致性能不足。idle:空闲状态。记录 CPU 进入 Idle 状态的时间点分析功耗问题。am(Activity Manager): 记录 Android 系统的 Activity 启动、生命周期事件。wm(Window Manager): 记录窗口管理器的相关事件比如窗口的显示、隐藏、Layer 的刷新。gfx(Graphics):图形相关。记录 SurfaceFlinger、Vsync、渲染帧等关键信息分析掉帧Jank必备。view:View 系统事件。记录 Android UI 控件的 Measure、Layout、Draw 流程。binder_driver:Binder 驱动事件。记录进程间通信IPC的详细耗时分析是哪个服务调用导致了阻塞。hal:HAL 层事件。记录硬件抽象层如 Camera、传感器、音频 HAL的调用分析硬件驱动层的延迟。dalvik:虚拟机事件。记录 GC垃圾回收、JIT 编译等事件。res:资源加载。记录一些资源加载、系统属性的变化。3. 该指令的作用场景这个指令通常用于排查性能卡顿Jank/Lag或功耗异常。场景 1分析 UI 卡顿通过gfx和view可以看到 UI 刷新是否掉帧。通过sched和binder_driver可以分析是否因为某个线程一直抢占 CPU 或被某个 Binder 调用阻塞导致界面无法及时响应。场景 2分析应用启动慢通过am和wm可以看到 Activity 启动的完整过程配合binder_driver找出在哪个通信环节耗时过长。场景 3分析功耗或发热通过freqs和idle结合sched查看 CPU 是否一直保持高频或者频繁进行不必要的线程唤醒。完成后将生成的 Trace 文件 pull 到电脑上adb pull /data/misc/perfetto-traces/trace_file.perfetto-trace .阶段二导入并认识 Perfetto UI 面板拿到 Trace 文件后我们需要使用 Google 提供的网页端工具来可视化分析。1. 打开网页加载数据在浏览器推荐 Chrome 或 Edge中打开官方分析工具ui.perfetto.dev 将刚才导出的.perfetto-trace文件直接拖拽进网页中央。2. 核心操作快捷键必记Perfetto 的界面信息量极其庞大单纯依靠鼠标拖拽效率很低熟练使用以下快捷键是必备技能W / S放大 / 缩小时间轴Zoom In / Out。这在精确定位毫秒级耗时时非常有用。A / D向左 / 向右平移时间轴。M高亮选中一段区域。鼠标框选一段时间后按 M可以固定高亮用于查看这段时间内的系统整体负载。如下是将trace文件导入到网页后的界面1. 致命异常Duration: (Did not end)这是最核心的发现。含义performCreate这个方法一直没有执行完。分析在 Perfetto 录制的这段时间里甚至直到录制结束主线程都卡在这个方法内部。按照 Android 机制主线程被阻塞超过 5 秒就会触发 ANR。你这里的阻塞长度已经贯穿了整个 Trace 视图说明主线程彻底“死”在了SubSettings的创建过程中。2. 定位到的业务范围Name:performCreate:com.android.settings.SubSettings分析这说明点击设置项大概率是网络相关的二级菜单后系统尝试初始化SubSettings页面。所有该页面的Fragment初始化、onCreate生命周期逻辑、以及各种Preference状态的获取都在这个方法里同步执行。然后我们继续看上面有没有什么异常1. 核心异常CPU 4 被dnsmasq进程占满在第二张图的CPU 4 Scheduling轨道上你可以看到大段的橙黄色块上面标注着进程名为dnsmasq [5252]。现象dnsmasq在 CPU 4 上几乎是持续运行的这意味着它在进行高强度的任务。关联性dnsmasq通常与热点Tethering和 DNS 转发相关。结合你之前日志里提到的tetheroffload报错这说明在你打开设置页面的那一刻热点相关的网络后台进程正在发生严重的异常可能是死循环或大量的网络包处理。2. 线程唤醒关系system_server在“垂死挣扎”查看右下角的Scheduling Latency面板Wakeup信息显示RenderThread 4589是被system_server [1926]里的binder:1926_5唤醒的。分析这证实了system_server一直在试图与Settings进程通信。但由于dnsmasq占用了大量资源或者dnsmasq阻塞了某种系统级的网络锁Mutex导致通信效率极低。3. 渲染线程 (RenderThread) 的反常表现现象第一张图显示main thread卡死在performCreate紫色长条但下方的RenderThread却有密集的绿条和prepareAndDraw。解释这说明Settings的 UI 逻辑层主线程已经彻底瘫痪了但渲染层RenderThread还在尝试刷新画面比如显示一个进度条或者处理上一次的绘制请求。这种“主线程死锁渲染线程还在跑”的现象是典型的同步逻辑阻塞。综合诊断结果这是一个由网络子系统dnsmasq/Tethering引起的系统级阻塞导致的 ANR。根源dnsmasq进程异常占用了核心 CPU 资源。连锁反应当你进入SubSettings网络设置页面时主线程发起了一个同步请求去获取热点或网络配置。死锁由于dnsmasq处于异常状态或者它持有了某个底层的硬件访问锁导致Settings发出的请求永远得不到回应。结果主线程在performCreate阶段永久等待5 秒后触发 ANR。上述是整个Perfetto的排查流程它排查出可能是网络子系统dnsmasq/Tethering引起的系统级阻塞导致的 ANR。然后我们继续结合日志进行后续排查三.结合日志排查首先抓取dnsmasq日志 执行adb logcat | grep dnsmasq看看有没有timeout或failed to bind之类的报错。这几行日志是ANR应用无响应调查的“冒烟证据”。它解释了为什么你的Settings进程会卡死系统资源被耗尽了。具体分析如下1. 核心含义dnsmasq疯了CPU 占用接近 100%日志显示dnsmasq进程号 5252持续占用了95% - 98%的 CPU 资源。User (用户态)vsKernel (内核态)在00:00:47之后的记录中dnsmasq的Kernel 占用高达 85% 左右。这说明dnsmasq并不是在做复杂的计算而是陷入了某种严重的内核级阻塞或死循环。它可能在不停地尝试读写一个损坏的网卡接口、处理海量的恶意网络包或者在不停地申请/释放内核锁。2. 为什么会导致SettingsANR结合你之前的 Perfetto 图表逻辑链条现在闭合了抢占资源dnsmasq几乎吃光了 CPU 资源尤其是你截图里看到的 CPU 4。Binder 响应超时当你在Settings里打开网络设置时主线程需要通过 Binder 去问system_server现在的网络状态。由于 CPU 被dnsmasq占满加上可能存在的内核锁竞争这个 Binder 请求发不出去或者回不来。主线程挂起主线程在performCreate阶段等不到数据直接卡死。3.dnsmasq是干什么的在 Android 中dnsmasq主要负责热点Tethering为连接到你手机热点的设备分配 IP 地址DHCP和解析域名DNS。如果你当时开启了热点或者有设备正在频繁尝试连接你的热点可能触发了它的 Bug。然后我们看下logcat中关键的日志如下日志是一直反复出现2025-09-10 14:20:31.719 3214-3251 HidlServiceManagement com.android.networkstack.process W Waited one second for android.hardware.tetheroffload.config1.0::IOffloadConfig/default 2025-09-10 14:20:31.719 692-692 hwservicemanager hwservicemanager I Since android.hardware.tetheroffload.config1.0::IOffloadConfig/default is not registered, trying to start it as a lazy HAL (if its not configured to be a lazy HAL, it may be stuck starting or still starting). 2025-09-10 14:20:31.720 3214-3251 HidlServiceManagement com.android.networkstack.process I getService: Trying again for android.hardware.tetheroffload.config1.0::IOffloadConfig/default... 2025-09-10 14:20:31.720 1929-6233 system_server system_server I libdebuggerd_client: started dumping process 1529 2025-09-10 14:20:31.721 692-6363 libc hwservicemanager W Unable to set property ctl.interface_start to android.hardware.tetheroffload.config1.0::IOffloadConfig/default: error code: 0x20 2025-09-10 14:20:31.722 692-6363 hwservicemanager hwservicemanager I Tried to start android.hardware.tetheroffload.config1.0::IOffloadConfig/default as a lazy service, but was unable to. Usually this happens when a service is not installed, but if the service is intended to be used as a lazy service, then it may be configured incorrectly.日志中提到android.hardware.tetheroffload.config服务启动失败虽不一定是直接原因但这类驱动或 HAL 层的异常往往会导致system_server挂起进而引发连锁反应导致应用 ANR。然后我们找一下TetherOffload HAL与dnsmasq的关系TetherOffload HAL与dnsmasq1. 技术背景为什么需要 TetherOffload在传统的 Android 热点共享模式下数据包的转发路径是客户端 - 手机 Wi-Fi 网卡 - 内核网络协议栈 - 用户空间的 dnsmasq/netd - 内核协议栈 - 移动网络 (LTE/5G)问题所在数据包需要在“内核态”和“用户态”之间来回切换Context Switching。如果手机开启热点且连接设备较多CPU 需要处理大量中断和数据拷贝导致耗电增加、发热严重、带宽受限。2. TetherOffload 的作用TetherOffload全称 Tethering Offload HAL旨在将这些繁重的“数据转发”任务从 CPU 卸载到硬件如基带芯片、网络加速引擎或专门的 SoC 卸载模块上处理。它的核心逻辑只要连接状态和路由规则稳定后续的数据包就不再经过用户空间的软件栈直接由硬件电路在 Wi-Fi 网卡和蜂窝数据网卡之间进行“物理转发”。3. 两者的具体协作与区别特性dnsmasqTetherOffload HAL定位控制平面(Control Plane)数据平面(Data Plane)职责负责 DHCP 分配、DNS 缓存、路由表维护负责实际的数据报文转发、NAT 映射运行层级用户空间 (User Space)内核空间 (Kernel) 硬件驱动存在意义告诉网络“谁是谁去哪儿”告诉硬件“怎么飞速传输数据”协作流程启动阶段dnsmasq或 Android 现在的netd方案首先运行处理 DHCP 请求为连接的设备分配 IP并设置防火墙规则iptables/nftables。配置阶段Android 系统将这些连接信息和转发规则通过TetherOffload HAL下发给底层的硬件驱动。运行阶段一旦连接稳定TetherOffload 激活。此时绝大部分数据流绕过用户空间的 dnsmasq由硬件直接处理只有极少数控制指令或不符合卸载规则的流量才会回退到软件栈处理。4. 总结它们是互补的dnsmasq 是“大脑”负责处理逻辑复杂但频率不高的网络控制任务比如刚连上热点时 IP 怎么发、域名怎么解析。TetherOffload 是“肌肉”负责处理极其枯燥、耗费资源的纯数据流转发任务。简而言之在现代 Android 系统中TetherOffload 极大地降低了对 dnsmasq 处理高并发数据流的依赖。现在的 Android 倾向于让 dnsmasq 只负责轻量级的 IP 分配而将沉重的流量处理交给 TetherOffload 以提升系统性能。如果你的设备关闭了 TetherOffload例如在某些深度定制的系统或极客修改环境下你会明显感觉到热点速度下降且手机发热加剧因为所有的流量压力都回到了 CPU 和软件进程上。可以看出来TetherOffload异常可能就会导致dnsmasq异常四.修复TetherOffload相关内容后由于TetherOffload这块是hal层逻辑所以是其他同事修复的然后我们就看修复后的变化有没有解决问题首先点击界面没有anr看了然后我们看看Perfetto界面的变化如下是修复后的Perfetto界面可以看出来Settings的performCreate:com.android.settings.SubSettings耗时56ms时间大大缩短了不会导致anr然后继续看可以看出来几乎没有dnsmasq进程占用cpu了所以综合分析是TetherOffload异常导致dnsmasq进程一直在疯狂吃cpu导致Settings没法响应了