Systrace 之 binder 锁竞争

最新推荐文章于 2024-06-07 09:46:18 发布
转载 最新推荐文章于 2024-06-07 09:46:18 发布 · 914 阅读 · 7 ·
CC 4.0 BY-SA版权
原文链接：https://www.androidperformance.com/2019/12/06/Android-Systrace-Binder/#Binder-%E6%A6%82%E8%BF%B0

本文通过Systrace深入解析Android中Binder通信的锁信息，探讨锁竞争导致的卡顿问题，重点讲解了Binder调用图例、活动暂停与焦点栈阻塞案例，以及如何通过源码理解并优化。
和你一起终身学习，这里是程序员 Android

经典好文推荐，通过阅读本文，您将收获以下知识点:

一、Binder 概述
二、Binder 调用图例
三、Systrace 显示的锁的信息
四、总结

一、Binder 概述

Android 的大部分进程间通信都使用 Binder，这里对 Binder 不做过多的解释，想对 Binder 的实现有一个比较深入的了解的话，推荐你阅读下面三篇文章

  1. 理解Android Binder机制1/3：驱动篇
  2. 理解Android Binder机制2/3：C++层
  3. 理解Android Binder机制3/3：Java层

之所以要单独讲 Systrace 中的 Binder 和锁，是因为很多卡顿问题和响应速度的问题，是因为跨进程 binder 通信的时候，锁竞争导致 binder 通信事件变长，影响了调用端。最常见的就是应用渲染线程 dequeueBuffer 的时候 SurfaceFlinger 主线程阻塞导致 dequeueBuffer 耗时，从而导致应用渲染出现卡顿; 或者 SystemServer 中的 AMS 或者 WMS 持锁方法等待太多, 导致应用调用的时候等待时间比较长导致主线程卡顿

这里放一张文章里面的 Binder 架构图 ， 本文主要是以 Systrace 为主，所以会讲 Systrace 中的 Binder 表现，不涉及 Binder 的实现

image

二、Binder 调用图例

Binder 主要是用来跨进程进行通信，可以看下面这张图，简单显示了在 Systrace 中 ，Binder 通信是如何显示的

image

图中主要是 SystemServer 进程和 高通的 perf 进程通信，Systrace 中右上角 ViewOption 里面勾选 Flow Events 就可以看到 Binder 的信息

image

点击 Binder 可以查看其详细信息，其中有的信息在分析问题的时候可以用到，这里不做过多的描述

image

对于 Binder，这里主要介绍如何在 Systrace 中查看 Binder 锁信息和锁等待这两个部分，很多卡顿和响应问题的分析，都离不开这两部分信息的解读，不过最后还是要回归代码，找到问题后，要读源码来理顺其代码逻辑，以方便做相应的优化工作

三、Systrace 显示的锁的信息

image

monitor contention with owner Binder:1605_B (4667) at void com.android.server.wm.ActivityTaskManagerService.activityPaused(android.os.IBinder)(ActivityTaskManagerService.java:1733) waiters=2 blocking from android.app.ActivityManager$StackInfo com.android.server.wm.ActivityTaskManagerService.getFocusedStackInfo()(ActivityTaskManagerService.java:2064)

上面的话分两段来看，以 blocking 为分界线

3.1 第一段信息解读

monitor contention with owner Binder:1605_B (4667) at void com.android.server.wm.ActivityTaskManagerService.activityPaused(android.os.IBinder)(ActivityTaskManagerService.java:1733) waiters=2

Monitor 指的是当前锁对象的池，在 Java 中，每个对象都有两个池，锁(monitor)池和等待池：

锁池（同步队列 SynchronizedQueue ）：假设线程 A 已经拥有了某个对象(注意:不是类 )的锁，而其它的线程想要调用这个对象的某个 synchronized 方法(或者 synchronized 块)，由于这些线程在进入对象的 synchronized 方法之前必须先获得该对象的锁的拥有权，但是该对象的锁目前正被线程 A 拥有，所以这些线程就进入了该对象的锁池中。

这里用了争夺(contention)这个词，意思是这里由于在和目前对象的锁正被其他对象（Owner）所持有，所以没法得到该对象的锁的拥有权，所以进入该对象的锁池

Owner : 指的是当前拥有这个对象的锁的对象。这里是 Binder:1605_B，4667 是其线程 ID。

at 后面跟的是拥有这个对象的锁的对象正在做什么。这里是在执行 void com.android.server.wm.ActivityTaskManagerService.activityPaused 这个方法，其代码位置是 ：ActivityTaskManagerService.java:1733 其对应的代码如下：

com/android/server/wm/ActivityTaskManagerService.java

@Override
public final void activityPaused(IBinder token) {
    final long origId = Binder.clearCallingIdentity();
    synchronized (mGlobalLock) { // 1733 是这一行
        ActivityStack stack = ActivityRecord.getStackLocked(token);
        if (stack != null) {
            stack.activityPausedLocked(token, false);
        }
    }
    Binder.restoreCallingIdentity(origId);
}

可以看到这里 synchronized (mGlobalLock) ，获取了 mGlobalLock 锁的拥有权，在他释放这个对象的锁之前，任何其他的调用 synchronized (mGlobalLock) 的地方都得在锁池中等待

waiters 值得是锁池里面正在等待锁的操作的个数；这里 waiters=2 表示目前锁池里面已经有一个操作在等待这个对象的锁释放了，加上这个的话就是 3 个了

3.2 第二段信息解读

blocking from android.app.ActivityManager$StackInfo com.android.server.wm.ActivityTaskManagerService.getFocusedStackInfo()(ActivityTaskManagerService.java:2064)

第二段信息相对来说简单一些，就是标识了当前被阻塞等锁的方法 ， 这里是 ActivityManager 的 getFocusedStackInfo 被阻塞，其对应的代码

com/android/server/wm/ActivityTaskManagerService.java

@Override
public ActivityManager.StackInfo getFocusedStackInfo() throws RemoteException {
    enforceCallerIsRecentsOrHasPermission(MANAGE_ACTIVITY_STACKS, "getStackInfo()");
    long ident = Binder.clearCallingIdentity();
    try {
        synchronized (mGlobalLock) { // 2064 是这一行 
            ActivityStack focusedStack = getTopDisplayFocusedStack();
            if (focusedStack != null) {
                return mRootActivityContainer.getStackInfo(focusedStack.mStackId);
            }
            return null;
        }
    } finally {
        Binder.restoreCallingIdentity(ident);
    }
}

可以看到这里也是调用了 synchronized (ActivityManagerService.this) ，从而需要等待获取 ams 对象的锁拥有权

四、总结

上面这段话翻译过来就是

ActivityTaskManagerService 的 getFocusedStackInfo 方法在执行过程中被阻塞，原因是因为执行同步方法块的时候，没有拿到同步对象的锁的拥有权；需要等待拥有同步对象的锁拥有权的另外一个方法 ActivityTaskManagerService.activityPaused 执行完成后，才能拿到同步对象的锁的拥有权，然后继续执行

可以对照原文看上面的翻译

monitor contention with owner Binder:1605_B (4667)
at void com.android.server.wm.ActivityTaskManagerService.activityPaused(android.os.IBinder)(ActivityTaskManagerService.java:1733)
waiters=2
blocking from android.app.ActivityManager$StackInfo com.android.server.wm.ActivityTaskManagerService.getFocusedStackInfo()(ActivityTaskManagerService.java:2064)

等锁分析

还是上面那个 Systrace，Binder 信息里面显示 waiters=2，意味着前面还有两个操作在等锁释放，也就是说总共有三个操作都在等待 Binder:1605_B (4667) 释放锁，我们来看一下 Binder:1605_B 的执行情况

image

从上图可以看到，Binder:1605_B 正在执行 activityPaused，中间也有一些其他的 Binder 操作，最终 activityPaused 执行完成后，释放锁

下面我们就把这个逻辑里面的执行顺序理顺，包括两个 waiters

锁等待

image

上图中可以看到 mGlobalLock 这个对象锁的争夺情况

  1. Binder_1605_B 首先开始执行 activityPaused，这个方法中是要获取 mGlobalLock 对象锁的，由于此时 mGlobalLock 没有竞争，所以 activityPaused 获取对象锁之后开始执行
  2. android.display 线程开始执行 checkVisibility 方法，这个方法也是要获取 mGlobalLock 对象锁的，但是此时 Binder_1605_B 的 activityPaused 持有 mGlobalLock 对象锁 ，所以这里 android.display 的 checkVisibility 开始等待，进入 sleep 状态
  3. android.anim 线程开始执行 relayoutWindow 方法，这个方法也是要获取 mGlobalLock 对象锁的，但是此时 Binder_1605_B 的 activityPaused 持有 mGlobalLock 对象锁 ，所以这里 android.display 的 checkVisibility 开始等待，进入 sleep 状态
  4. android.bg 线程开始执行 getFocusedStackInfo 方法，这个方法也是要获取 mGlobalLock 对象锁的，但是此时 Binder_1605_B 的 activityPaused 持有 mGlobalLock 对象锁 ，所以这里 android.display 的 checkVisibility 开始等待，进入 sleep 状态

经过上面四步，就形成了 Binder_1605_B 线程在运行，其他三个争夺 mGlobalLock 对象锁失败的线程分别进入 sleep 状态，等待 Binder_1605_B 执行结束后释放 mGlobalLock 对象锁

锁释放

image

上图可以看到 mGlobalLock 锁的释放和后续的流程

  1. Binder_1605_B 线程的 activityPaused 执行结束，mGlobalLock 对象锁释放
  2. 第一个进入等待的 android.display 线程开始执行 checkVisibility 方法 ，这里从 android.display 线程的唤醒信息可以看到，是被 Binder_1605_B(4667) 唤醒的
  3. android.display 线程的 checkVisibility 执行结束，mGlobalLock 对象锁释放
  4. 第二个进入等待的 android.anim 线程开始执行 relayoutWindow 方法 ，这里从 android.anim 线程的唤醒信息可以看到，是被 android.display(1683) 唤醒的
  5. android.anim 线程的 relayoutWindow 执行结束，mGlobalLock 对象锁释放
  6. 第三个进入等待的 android.bg 线程开始执行 getFocusedStackInfo 方法 ，这里从 android.bg 线程的唤醒信息可以看到，是被 android.anim(1684) 唤醒的

经过上面 6 步，这一轮由于 mGlobalLock 对象锁引起的等锁现象结束。这里只是一个简单的例子，在实际情况下，SystemServer 中的 BInder 等锁情况会非常严重，经常 waiter 会到达 7 - 10 个，非常恐怖，比如下面这种：

image

这也就可以解释为什么 Android 手机 App 安装多了、用的久了之后，系统就会卡的一个原因；另外重启后也会有短暂的时候出现这种情况

如果不知道怎么查看唤醒信息，可以查看： Systrace中查看进程信息唤醒 这篇文章

相关代码

Monitor 信息

art/runtime/monitor.cc

std::string Monitor::PrettyContentionInfo(const std::string& owner_name,
                                          pid_t owner_tid,
                                          ArtMethod* owners_method,
                                          uint32_t owners_dex_pc,
                                          size_t num_waiters) {
  Locks::mutator_lock_->AssertSharedHeld(Thread::Current());
  const char* owners_filename;
  int32_t owners_line_number = 0;
  if (owners_method != nullptr) {
    TranslateLocation(owners_method, owners_dex_pc, &owners_filename, &owners_line_number);
  }
  std::ostringstream oss;
  oss << "monitor contention with owner " << owner_name << " (" << owner_tid << ")";
  if (owners_method != nullptr) {
    oss << " at " << owners_method->PrettyMethod();
    oss << "(" << owners_filename << ":" << owners_line_number << ")";
  }
  oss << " waiters=" << num_waiters;
  return oss.str();
}

Block 信息

art/runtime/monitor.cc

if (ATRACE_ENABLED()) {
  if (owner_ != nullptr) {  // Did the owner_ give the lock up?
    std::ostringstream oss;
    std::string name;
    owner_->GetThreadName(name);
    oss << PrettyContentionInfo(name,
                                owner_->GetTid(),
                                owners_method,
                                owners_dex_pc,
                                num_waiters);
    // Add info for contending thread.
    uint32_t pc;
    ArtMethod* m = self->GetCurrentMethod(&pc);
    const char* filename;
    int32_t line_number;
    TranslateLocation(m, pc, &filename, &line_number);
    oss << " blocking from "
        << ArtMethod::PrettyMethod(m) << "(" << (filename != nullptr ? filename : "null")
        << ":" << line_number << ")";
    ATRACE_BEGIN(oss.str().c_str());
    started_trace = true;
  }
}

原文链接：https://www.androidperformance.com/2019/12/06/Android-Systrace-Binder/#Binder-%E6%A6%82%E8%BF%B0

至此，本篇已结束。转载网络的文章，小编觉得很优秀，欢迎点击阅读原文，支持原创作者，如有侵权，恳请联系小编删除，欢迎您的建议与指正。同时期待您的关注，感谢您的阅读，谢谢！

Systrace系列10 —— Binder 和锁竞争解读
tectrol的专栏
05-27 1350
Android 的大部分进程间通信都使用 Binder，这里对 Binder 不做过多的解释，想对 Binder 的实现有一个比较深入的了解的话，推荐你阅读下面三篇文章理解Android Binder机制1/3：驱动篇理解Android Binder机制2/3：C++层理解Android Binder机制3/3：Java层。
Android Systrace 基础知识(10) - Binder 和锁竞争解读
Gracker的专栏
06-08 1631
本文是 Systrace 系列文章的第十篇，主要是对 Systrace 中的 Binder 和锁信息进行简单介绍，简单介绍了 Binder 的情况，介绍了 Systrace 中 Binder 通信的表现形式，以及 Binder 信息查看，SystemServer 锁竞争分析等 本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚
Systrace 基础知识 - 锁竞争解读
marshal_zsx的博客
12-15 4198
参考连接：https://www.androidperformance.com/2019/12/06/Android-Systrace-Binder/ 1.Systrace 显示的锁的信息 monitor contention with owner Binder:1605_B (4667) at void com.android.server.wm.ActivityTaskManagerServ...
利用systrace中跟踪binder通信过程
kill150的专栏
06-16 1874
从trace中可以看到，1546 InputReader线程通过binder向surfaceflinger(501)的线程发送了消息，请求requestNextVsync.systrace抓取到的trace日志中会记录android系统的很多通信过程，其中也包括了binder的通信细节。红框：现场名字及线程号，这里是截图所以没有体现出来，这个线程是system_server中的1102 1546 InputReader线程。点击绿色横条，可以看到这个thread是运行在CPU5上。
Binder子系统之调试分析(一)
omnispace的博客
10-04 3760
一. 概述 在博客以前有写过关于binder系列，大概写了10篇关于binder的文章，从binder驱动，到native层，再到framework，一路写到app层的使用。有兴趣的可以看看 Binder系列—开篇。 二.Binder驱动调试 看过Binder系列文章的同学，会发现Binder IPC过程最终都交给Binder Driver来完成，这是真正干跨进程通信活的地方，
Systrace 学习笔记
程序员Android
08-12 1590
和你一起终身学习，这里是程序员Android经典好文推荐，通过阅读本文，您将收获以下知识点:一、Systrace 简介二、Systrace 预备知识三、Why 60 fps四、System...
卡顿掉帧问题分析之工具篇
chuyouyinghe的专栏
07-18 2696
从上面的分析可以看到，谷歌原生在Android系统的很多系统关键流程上都添加了相关的，以观察这些流程执行的耗时情况。但是这些信息覆盖的范围毕竟是有限的，有时候并不能满足我们的分析需求。比如我们开发者想观察自己的一些代码逻辑执行的耗时情况，就需要自己定义一些去度量，这个Systrace机制本身是支持的。如何在代码中添加自定义的信息呢？本着知其然、知其所以然的态度，本小节中我们来简单分析一下系统Systrace机制的原理，看看一份Systrace文件到底是怎么生成的？我们知道Android系统底层是基于。
systrace binder打印函数
03-15
还需要考虑性能分析的部分，比如Binder调用的耗时和锁竞争情况，引用[5]指出Systrace中显示的锁信息对于分析卡顿问题很重要。因此，回答中需要指导用户如何利用systrace中的这些信息，并结合代码进行优化。 总结...
（3） Android中Binder调用流程 --- 相关类介绍
china0851的专栏
02-20 675
       在具体讲解Binder调用流程之前，有必要先把调用流程中和数据相关的类介绍下，通过前面两节介绍，我们知道Binder对象分为本地和远程，在远程调用进行数据系列化时对这两种对象处理也是有区别的，下面是Binder调用流程中和数据直接相关的类。        JAVA端        BinderProxy：远程服务在本地的代理；        Binder：实现IBinder接...
Android trace文件分析小技巧
jackzhouyu的专栏
10-24 3994
网上有很多trace文件分析博客，但是都是解释anr发生得原因，没有指导anr文件如何着手分析？本篇文章就是讲trace文件怎么切入？
探索Android Binder通信的利器：Binder Trace
gitblog_00057的博客
06-07 674
探索Android Binder通信的利器：Binder Trace binder-traceBinder Trace is a tool for intercepting and parsing Android Binder messages. Think of it as "Wireshark for Binder".项目地址:https://gitcode.com/gh_mirrors/b...
【安卓源码】Binder机制3 -- Binder线程池
mike_jun的博客
04-26 3220
Binder本身是C/S架构，就可能存在多个Client会同时访问Server的情况。在这种情况下，如果Server只有一个线程处理响应，就会导致客户端的请求可能需要排队而导致响应过慢的现象发生。解决这个问题的方法就是引入多线程。【多个客户端不同线程去请求，服务端需要使用多线程机制，binder线程池，创建多个线程去回复多个客户端的请求】Binder机制的设计从最底层–驱动层，就考虑到了对于多线程的支持。
Android Systrace 基础知识(4) - SystemServer 解读
Gracker的专栏
05-22 1862
本文是 Systrace 系列文章的第四篇，主要是对 SystemServer 进行简单介绍，介绍了 SystemServer 中几个比较重要的线程，由于 Input 和 Binder 比较重要，所以单独拿出来讲，在这里就没有再涉及到。 本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace
Android 性能优化系列 - 02 理解 systrace
Dream It Possible
11-02 725
在上篇文章中已经介绍过了，systrace 本质上是对其他工具的封装，包括 PC 端的 atrace 和设备端的 ftrace，ftrace 是 Linux 内核中的主要跟踪机制。systrace 使用 atrace 开启追踪，然后读取 ftrace 的缓存，并且把它重新转换成HTML格式。
trace android,Android atrace使用说明(Android sdk中的systrace)
weixin_32046225的博客
05-27 1406
1. 普通使用atrace -a com.jeoe.ebox gfx wm am sched view app res ss1atrace-acom.jeoe.eboxgfxwmamschedviewappresss这样会把结果输出到控制台，对分析没什么意义，可以用于测试这个命令2. 抓trace并保存到文件atrace -a com.jeoe.ebox gfx wm am sched view ...
Systrace 解析
热门推荐
pwl999的博客
10-29 1万+
上图基本就能说清systrace的整个框架： 1、systrace调用atrace抓取目标机的trace数据； 2、systrace把trace数据和’prefix.html’、‘suffix.html’、'systrace_trace_viewer.html’合成一个’trace.html’文件； 3、使用chrome浏览器打开’trace.html’就可以非常方便的以图形化的形式来查看和分...
trace中的binder transaction和binder reply是什么
最新发布
06-18
<think>我们正在讨论Perfetto中关于bindertransaction和binderreply的含义，以及如何通过SQL搜索关键字并避免手动标记（即通过键盘操作实现高亮）。根据用户的问题，我们需要解释两个概念：1.bindertransaction和binderreply在trace中的定义。2.在Perfetto中使用SQL搜索关键字时，如何避免使用鼠标标记关键字（即使用键盘操作进行高亮）。首先，关于bindertransaction和binderreply：在Android系统中，Binder是一种进程间通信（IPC）机制。在Perfettotrace中，我们可以捕获Binder事务（transaction）和回复（reply）的事件。-bindertransaction：表示一个进程向另一个进程发送请求（即事务）。在trace中，通常表现为一个进程（客户端）向服务端发送一个事务请求。-binderreply：表示服务端处理完事务后，向客户端发送回复。这些事件在trace中通常通过特定的slice（片段）来记录，这些slice的名称可能包含如“bindertransaction”或“binderreply”等关键字，或者通过特定的参数来标识。其次，关于在Perfetto中避免手动标记关键字的方法：如前所述，我们可以使用浏览器的查找功能（Ctrl+F或Command+F）来高亮关键字，而无需鼠标。但这里用户可能希望直接在SQL查询结果中自动标记关键字，然而PerfettoUI本身并不支持在SQL查询结果中自动高亮关键字（它只提供基本的表格展示）。因此，我们有两种思路：1.通过SQL查询直接过滤出包含关键字的行（这样结果中自然就只显示这些行，相当于“标记”了）。2.在查询结果页面使用浏览器的查找功能高亮关键字（适用于结果已经显示在网页上）。但是，用户的问题中提到了“自动标记”，可能是指不需要手动在页面上进行查找操作，而是希望执行SQL后结果自动高亮。遗憾的是，PerfettoUI目前没有这样的内置功能。因此，我们只能通过浏览器功能来实现高亮，或者通过编写更精确的SQL来缩小结果范围。下面，我们结合用户提供的引用内容（虽然引用内容主要是关于Binder内部机制和trace宏的，但我们可以从中提取一些关键信息）来构建SQL查询：引用[1]提到：根据binderthread的sysTid在SYS_BINDER_INFO/SWT_JBT_TRACES/kernel_log中查找binder通信对端，关键字“outgoingtransaction”。这提示我们，在trace中，bindertransaction事件可能包含“outgoingtransaction”这样的描述。引用[2]详细描述了binder_transaction函数的处理过程，但并没有直接给出在trace中如何识别这些事件。不过，我们可以推测，在trace中，这些事件可能会记录在slice表或类似的表中。引用[3]提到了ATRACE宏，这通常用于在trace中标记应用层的片段，但Binder事件通常在内核层记录。因此，我们可以尝试在Perfetto中使用SQL查询bindertransaction和reply事件。常见的表是`slice`表，但Binder事件也可能记录在`binder_transaction`或`binder_transaction_slice`等表中（具体表名可能因Perfetto版本和跟踪配置而异）。以下是一个示例查询：```sqlSELECTts,dur,name,tid,pid,arg_set_idFROMsliceWHEREnameGLOB'*bindertransaction*'ORnameGLOB'*binderreply*'```但是，更精确的做法可能是结合参数（args）来查询，因为Binder事务和回复通常会有特定的参数。例如，我们可以通过`args`表来查找具有特定参数的事件：```sqlSELECTslice.ts,slice.dur,slice.name,thread.tidASthread_tid,process.pidASprocess_pid,args.string_valueAStransaction_infoFROMsliceJOINthread_trackONslice.track_id=thread_track.idJOINthreadUSING(utid)JOINprocessUSING(upid)JOINargsONslice.arg_set_id=args.arg_set_idWHERE(slice.nameGLOB'*bindertransaction*'ORslice.nameGLOB'*binderreply*')ANDargs.key='transaction'```注意：上述查询中的表名和字段名可能需要调整，具体取决于跟踪数据中实际可用的表和字段。关于自动标记：如果用户希望查询结果自动高亮某个关键字（比如“outgoingtransaction”），PerfettoUI本身不支持。但是，我们可以通过浏览器的查找功能（Ctrl+F）来高亮。另外，如果用户希望将结果导出，然后在其他支持高亮的工具中查看，可以考虑导出为文本，然后使用命令行工具（如grep）进行高亮。因此，总结回答：1.**bindertransaction和binderreply的含义**：它们是BinderIPC中的请求和响应事件。2.**在Perfetto中使用SQL搜索关键字时避免手动标记**：使用浏览器内置的查找功能（Ctrl+F）来高亮关键字，或者通过编写SQL条件精确过滤出包含关键字的行（这样结果中只显示这些行）。如果用户希望更自动化，可能需要编写脚本处理导出的数据（Perfetto支持将查询结果导出为JSON或CSV）。下面，我们按照用户要求的结构化方式回答：</think>### Binder Transaction 和 Binder Reply 在 Trace 中的定义 在 Android 系统跟踪中，Binder 是进程间通信(IPC)的核心机制： 1. **Binder Transaction** - 表示进程间通信请求，包含以下关键特征： - 发送方进程向接收方发起请求 - 在 trace 中标记为 `binder_transaction` 事件 - 包含参数：`target.handle`(目标句柄), `code`(操作码), `data_size`(数据大小) - 日志关键字：`outgoing transaction` [^1] - **SQL 识别特征**： ```sql SELECT * FROM slice WHERE name = 'binder_transaction' AND EXISTS (SELECT 1 FROM args WHERE args.arg_set_id = slice.arg_set_id AND key = 'transaction_code') ``` 2. **Binder Reply** - 表示对 Binder 请求的响应： - 接收方处理完请求后返回结果 - 在 trace 中标记为 `binder_reply` 事件 - 包含参数：`reply_to`(回复目标), `status`(状态码) - **SQL 识别特征**： ```sql SELECT * FROM slice WHERE name = 'binder_reply' AND EXISTS (SELECT 1 FROM args WHERE args.arg_set_id = slice.arg_set_id AND key = 'reply_status') ``` ### Perfetto 中自动标记关键字的 SQL 方案 通过 SQL 查询实现自动标记（无需手动高亮）： #### 方法 1：精确过滤法 直接通过 `WHERE` 子句过滤目标事件： ```sql SELECT ts, dur, name, args.string_value AS transaction_info FROM slice JOIN args USING (arg_set_id) WHERE name IN ('binder_transaction', 'binder_reply') AND args.key = 'transaction_code' AND args.string_value LIKE '%RowParallelLinear%' -- 替换目标关键字 ORDER BY ts; ``` **效果**：结果集仅包含匹配项，天然"标记" [^2] #### 方法 2：参数关联法 通过 `args` 表关联特定参数实现自动标记： ```sql SELECT s.ts, s.dur, s.name AS event_type, a_trans.value AS transaction_data, a_reply.value AS reply_status FROM slice s LEFT JOIN args a_trans ON s.arg_set_id = a_trans.arg_set_id AND a_trans.key = 'transaction_data' LEFT JOIN args a_reply ON s.arg_set_id = a_reply.arg_set_id AND a_reply.key = 'reply_status' WHERE (a_trans.value LIKE '%RowParallelLinear%' OR a_reply.value LIKE '%RowParallelLinear%') -- 自动标记关键字 AND s.ts BETWEEN [start_ts] AND [end_ts]; -- 限定时间范围 ``` #### 方法 3：跨线程追踪法 追踪完整 Binder 事务链路： ```sql WITH target_trans AS ( SELECT * FROM slice WHERE name = 'binder_transaction' AND EXISTS ( SELECT 1 FROM args WHERE args.arg_set_id = slice.arg_set_id AND args.string_value LIKE '%RowParallelLinear%' ) ) SELECT trans.ts AS req_start, reply.ts AS resp_start, trans.dur AS req_duration, reply.dur AS resp_duration, args_trans.string_value AS request, args_reply.string_value AS response FROM target_trans trans JOIN slice reply ON reply.name = 'binder_reply' AND reply.parent_id = trans.id -- 通过父子关系关联 JOIN args args_trans ON trans.arg_set_id = args_trans.arg_set_id JOIN args args_reply ON reply.arg_set_id = args_reply.arg_set_id; ``` ### 键盘操作增强技巧 1. **快速执行查询** - `Ctrl + Enter` (Windows/Linux) / `⌘ + Enter` (Mac) 直接运行 SQL 2. **结果集导航** - 表格内跳转：`Tab` 键横向切换单元格，`↑/↓` 纵向浏览行 3. **导出后处理** 导出为 CSV 后用命令行工具自动高亮： ```bash cat results.csv | grep --color=always "RowParallelLinear" ``` > **关键优势**：通过 SQL 精确过滤，从根本上避免手动标记需求。结合 `args` 表可深度解析 Binder 事务参数 [^1][^2]，使用 `JOIN` 可实现跨事件关联分析 [^3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值