抖音 Android 性能优化系列：新一代全能型性能分析工具 Rhea(1)

随着 Rhea 1.0 功能的深入使用，在带来极大便利的同时，功能本身的不足也逐渐暴露出来。在采集数据过程中，其本身的性能损耗会导致在一些实际性能优化过程中会带偏方向。经我们严格测试，其性能损耗有 11.5%左右，如下所示：

在实际使用过程中发现，在开启 Systrace 之后，对应 Sleep 耗时占比在极端情况下会超过 40%以上。一方面是 APP 锁带来的 Sleep 耗时。例如，在抖音启动路径上 SharedPreference 优化过程中，在开启 Rhea 1.0 的 Systrace 功能后，发现 SP 调用存在明显的锁耗时，当时针对 SP 进行了一番锁的优化后，上线发现效果并不明显，后续经过一系列排查，发现锁的耗时是由于开启 Systrace 功能后导致。另一方面是 IO 带来的 Uninterrupt Sleep 耗时。例如，我们在一次性能优化过程中看到了很多__fdget_pos 操作，对_fdget_pos 操作相对 Uninterruptible Sleep 的占比统计了下，至少占了 Uninterruptible Sleep 总耗时的 60%左右。我们花了比较长时间，额外加了很多 IO 的信息，最终定位原因是在开启 Systrace 后，由于所有线程的 trace 都会写入同一个文件，所有线程会同步竞争内核态的文件 pos 锁导致。工具本身的性能问题误导了我们的排查方向，同时也暴露了在排查这种 IO Wait 问题的时候由于 IO 信息不全导致排查效率不高的问题。

• 限制层级导致的调用缺失

Systrace 的原理决定了当我们在应用层插入更多函数插桩以定位应用层耗时问题的时候，会导致非常严重的性能问题，所以我们在线下使用该工具会通过限制插桩层级的方式以减少运行时性能损耗。但是层级的限制使得超过既定层级的函数调用数据缺失，在分析调用层级较深的函数耗时的时候，无法定位到准确的耗时点。

• 使用场景限制

由于 Systrace 在采集数据的过程中，需要依赖 PC，对于一些需要脱离 PC 采集数据的场景，Systrace 就无法满足需求了。比如我们产品运营同学经常会在线下场景实地测试抖音的使用性能，例如地铁、餐馆、咖啡厅等，这些实际使用场景下的性能数据，systrace 就无法支持到了。

• 低端机无法正常使用

我们在针对低端机进行耗时优化时，发现诸如三星、oppo 等一些早期的低端机型，systrace 也不能支持其数据抓取。

针对以上问题，我们对工具进行了深入的探索和优化。于是，工具的开发进入了第二阶段。

第二阶段：高性能全场景的 Trace 抓取工具

---

1.  功能升级

为了弥补第一阶段功能短板，进一步提高性能，同时能满足更多使用场景，我们找到了新的解决方案：在 Java 层，通过记录方法首末位置时间戳、所在线程等信息，过滤出大于指定耗时阈值的函数后，将数据异步记录到文件。数据采集结束后，将输出文件转换成指定格式后，便可通过 SDK 提供的 Systrace 工具转化成方便查看的 Html 格式，从而实现和 Systrace 相同的可视化效果。

2.  实现原理

Rhea 2.0 如何采集数据并生成和 Systrace 相同可视化效果的 html 呢？SDK 中 Systrace 工具的–from-file 命令可将原始的.trace 格式数据转成 html 格式，分析.trace 数据内部格式：

多次尝试后得出结论，可被 SDK Systrace 工具解析的 .trace 文件需满足如下格式：

格式说明：

• ：线程名，若为主线程，可指定为包名。

• ：线程 ID。

• ：方法开始或者结束的时间，单位 s。

• <B|E>：标记该条记录为方法开始(B)还是结束(E)。

• ：所在进程 ID。

• ：方法标记，字符长度不可超过 127。

由此可知，Mtrace 采集的数据至少需要包含以上内容。

以下则是对应 Trace 格式：

depth,methodID,inTime,outTime,threadName,threadID

相较于 Rhea 1.0 的 Systrace，Rhea 2.0 的 Method Trace 性能损耗有了显著的降低，性能损耗也由 11.5%下降至 3%，效果如下所示：

3.  最佳实践

• 功能使用

MTrace 相较于 Systrace，提供了更丰富的线下功能，其中包括：解决针对真实用户点对点的卡顿耗时问题反馈功能，解决产品、运营、QA 同学外出走查场景的问题反馈功能。

总之，不管你在哪，性能反馈都一触即达！如图为完整操作流程。

• 线上案例

一个真实的案例：抖音灰度版本线上用户反馈卡顿，通过 MTrace 功能包实现远程卡顿问题分析排查！以下则是通过用户配合回传的真实卡顿数据，经过解析即可发现耗时调用点：

4.  存在的问题

由于这个阶段采集的只有 Java 方法层的数据，在抖音启动 IO 耗时优化工作中，Method Trace 无法提供哪些函数进行了 IO 操作，以及 IO 操作读取/写入了哪些文件，给优化工作带来了较大的难度。另外在一些复杂场景中，Method Trace 只记录函数执行时长，但是不能准确定位是由于多线程同步等锁或者系统 IO 导致的执行时间变长。

针对上面的问题，我们意识到一套优秀的 Trace 工具还需要融合更多的系统事件，于是工具进入了第三阶段的打磨。

第三阶段：动态一体化 Trace 工具规划

---

Rhea 1.0 和 2.0 在抖音早期的性能优化工作中成绩显著，但随着优化工作的深入同时也暴漏诸多局限与不便。

一方面，使用常规的 Systrace 工具做性能优化，本身有诸多局限性。一是 Trace 信息少，在默认情况下，只包含系统预置的耗时打点信息，并不足以支持常规的耗时分析需要在 App 侧手动调用  Trace.beginSection 和 Trace.endSection  方法才能获取更多函数耗时信息，为避免影响线上包大小，使用完以后又需手动移除，一上一下事倍而功半。二是 Systrace 本身性能损耗大，特别是应用通过插桩的方式对业务代码进行大量的打点时，极端情况性能损耗会超过 50%。三是 Systrace 完全依赖 PC 端工具抓取，不够灵活。尤其是需要能够稳定复现性能问题的场景，对于一些特定区域或者特定用户群体才能复现的问题无法获直接高效的取到有效信息，依赖研发或者测试走查，甚至用户反馈的部分概率问题即使走查也无法通过 Systrace 获取到对应的信息，从而导致优化效率低。

另一方面，通过简单定制 Trace 的获取函数耗时相较于 Systrace，虽然有显著的性能提升，和更高的灵活性，但数据只包含基本的耗时信息，在部分复杂场景（如持有锁引起的耗时），数据仍存在局限。

如上工具都均已无法完全满足抖音的启动、首刷以及低端机等核心场景的性能优化工作，我们需要重新设计和规划功能更加强大的动态一体化 Trace 工具来辅助分析性能。

1. 该工具要非常灵活，可以不依赖 PC 端的抓取脚本，同时支持线上线下，能够在应用任何想要抓取数据的时候运行，作为一个平台性工具，Rhea 还需要支持动态扩展，支持多种场景的配置和动态开关，可以将任意需要的信息进行采集。

2. 该工具抓取的 Trace 信息要全面，能够采集和追踪包括 ATrace 插桩、等锁信息、I/O 信息以及 Binder 耗时等在内的多种信息。

3. 要支持可视化，统一的格式进行输出和格式化，最终以兼容 Systrace 的结果进行前端展示和使用，尽量不要改变使用者习惯。

4. 性能损耗要低，以免带偏性能优化方向。

因此，我们重新设计了新一代 Trace 分析工具：

整体上，App 通过集成 Rhea SDK 在打包时不限层级插入函数耗时桩方法，在运行时插入 IO、Binder、Lock 等相关 Trace 信息，支持动态配置，统一 Trace 格式为 atrace，同时支持获取系统级别的 Linux ftrace、Android Framework atrace 和 App 插入的 atrace 信息，能够不依赖 PC 抓取，最终提供可视化显示。具体实现如下：

一、不依赖 PC 抓取 Trace

为了实现不依赖 PC 抓取 Trace，我们有必要先了解下 Android atrace 的实现机制。首先，是 atrace 包括的数据源包括：

其中，用户空间的数据包括了应用层的自定义 Trace、系统层的 gfx 渲染相关 Trace、系统层打的锁相关的 Trace 信息等，其最终都是通过调用 Android SDK 提供的Trace.beginSection或者 ATRACE_BEGIN 记录到同一个文件点/sys/kernel/debug/tracing/trace_marker 中的。此节点允许用户层写入字符串，ftrace 会记录该写入操作时的时间戳，当用户在上层调用不同函数时，写入不同的调用信息，比如函数进入和退出分别写入，那么 ftrace 就可以记录跟踪函数的运行时间。atrace 在处理用户层的多种 trace 类别时，只是激活不同的 TAG，如选择了 Graphics，则激活 ATRACE_TAG_GRAPHICS，将渲染事件记录到 trace_marker。

而内核空间的数据主要是一些补充的分析数据 freq、sched、binder 等，常用的比如 CPU 调度的相关信息包括：

• CPU 频率变化情况

• 任务执行情况

• 大小核的调度情况

• CPU Boost 调度情况

这些信息是 App 可以通过直接读取/sys/devices/system/cpu 节点下相关信息获得，而另外一部分标识线程状态的信息则只能通过系统或者 adb 才能获取，且这些信息不是统一的一个节点控制，其需要激活各自对应的事件节点，让 ftrace 记录下不同事件的 tracepoint。内核在运行时，根据节点的使能状态，会往 ftrace 缓冲中打点记录事件。例如，激活线程调度状态信息记录，需要激活类似如下相关节点：

events/sched/sched_switch/enable

events/sched/sched_wakeup/enable

激活后，则可以获取到线程调度状态相关的信息，比如：

• Running: 线程在正常执行代码逻辑

• Runnable: 可执行状态，等待调度，如果长时间调度不到，说明 CPU 繁忙

• Sleeping: 休眠，一般是在等待事件驱动

• Uninterruptible Sleep: 不可中断的休眠，需要看 Args 的描述来确定当时的状态

• Uninterruptible Sleep - Block I/O: IO 阻塞

最终，上述两大类事件记录都汇集到内核态的同一缓冲中，PC 端上 Systrace 工具脚本是通过指定抓取 trace 的类别等参数，然后触发手机端的/system/bin/atrace 开启对应文件节点的信息，接着 atrace 会读取 ftrace 的缓存，生成只包含 ftrace 信息的 atrace_raw 信息，最终通过脚本转换成可视化 HTML 文件。大致流程如下：

因此，我们基于 Android atrace 的实现原理，我们同步参考了 Facebook 的 profilo 用于在 APP 侧直接获取 atrace 的方案，实现了不依赖 PC 抓取 Trace 的方法。

我们通过 dlopen 获取 libcutils.so 对应句柄，通过对应 symbol 从中找到 atrace_enabled_tags 和 atrace_marker_fd 对应指针，从而设置 atrace_enabled_tags 用以打开 atrace 开关，具体实现如下：

std::string lib_name(“libcutils.so”);

std::string enabled_tags_sym(“atrace_enabled_tags”);

std::string marker_fd_sym(“atrace_marker_fd”);

if (sdk < 18) {

lib_name = “libutils.so”;

// android::Tracer::sEnabledTags

enabled_tags_sym = “_ZN7android6Tracer12sEnabledTagsE”;

// android::Tracer::sTraceFD

marker_fd_sym = “_ZN7android6Tracer8sTraceFDE”;

}

if (sdk < 21) {

handle = dlopen(lib_name.c_str(), RTLD_LOCAL);

} else {

handle = dlopen(nullptr, RTLD_GLOBAL);

}

// safe check the handle

if (handle == nullptr) {

ALOGE(“atrace_handle is null”);

return false;

}

atrace_enabled_tags_ = reinterpret_cast<std::atomic<uint64_t> *>(

dlsym(handle, enabled_tags_sym.c_str()));

if (atrace_enabled_tags_ == nullptr) {

ALOGE(“atrace_enabled_tags not defined”);

goto fail;

}

atrace_marker_fd_ = reinterpret_cast<int*>(

dlsym(handle, marker_fd_sym.c_str()));

接下来，我们通过 hook libcutils 动态库中的 write、write_chk 方法通过判定 atrace_marker_fd 来将对应 atrace 信息拦截下来转储到到本地或上传到云端分析。实现如下所示：

ssize_t proxy_write_chk(int fd, const void* buf, size_t count, size_t buf_size) {

BYTEHOOK_STACK_SCOPE();

if (Atrace::Get().IsAtrace(fd, count)) {

Atrace::Get().LogTrace(buf, count);

return count;

}

ATRACE_BEGIN_VALUE(“__write_chk:”, FileInfo(fd, count).c_str());

size_t ret = BYTEHOOK_CALL_PREV(proxy_write_chk, fd, buf, count, buf_size);

ATRACE_END();

return ret;

}

二、提供更加全面 Trace 信息

1.  锁耗时

Java 层的锁，无论是同步方法还是同步块，最终都会走到虚拟机的 MonitorEnter 和 MonitorExit，在 MonitorEnter 中实现了多种锁状态的切换，包括从无锁到轻锁，轻锁中的偏向和重入，出现竞争并超过自旋的次数之后升级成重锁分配 monitor 对象，其中 art 现在的自旋不是真的自旋，而是用 sched_yield 主动让出 CPU 等待下次调度。

而我们需要首先关注的就是出现锁竞争升级成重锁后的等待耗时信息，这个信息从 Android 6.x 开始会通过 ATrace 的方式输出到 trace_marker 中。

但是想要轻锁的信息还需要做一些额外的工作，因为是否输出轻锁的 ATrace 信息除了 ATRACE_ENABLE 条件之外，还有另外一个 systrace_lock_logging 的开关变量控制，这个变量是虚拟机中一个全局变量的成员，这个成员变量的值正常情况下是由虚拟机启动的时候确定，默认是 false，可以通过启动虚拟机的时候传递-verbose:sys-locks 参数来打开，但是作为普通应用我们没有办法通过这种方式来打开，所以需要用非常规手段在运行时动态打开：

1. 首先确认从 Android7.x 开始，这个结构的大小、成员顺序是否有发生变化；

2. 如果没有变化，则可以自己定义一个相同的结构，因为里面都是原始的 bool 类型变量，不会引入其他依赖；

3. 如果有变化，但是向前兼容，我们想要访问的成员位置没有变化，只是往后追加了成员，也同样可以自己定义相同的结构；

4. 通过 dlsym 找到虚拟机的全局符号 gLogVerbosity；

5. 将其类型转换为预先定义的结构体类型；

6. 访问 systrace_lock_logging 成员并赋值为 true；

7. 轻锁的 ATrace 信息即可正常输出；

std::string lib_name(“libart.so”);

// art::gLogVerbosity

std::string log_verbosity_sym(“_ZN3art13gLogVerbosityE”);

void *handle = nullptr;

handle = npth_dlopen_full(lib_name.c_str());

if (handle == nullptr) {

ALOGE(“libart handle is null”);

return false;

}

log_verbosity_ = reinterpret_cast<LogVerbosity*>(

npth_dlsym(handle, log_verbosity_sym.c_str()));

if (log_verbosity_ == nullptr) {

ALOGE(“gLogVerbosity not defined”);

npth_dlclose(handle);

return false;

}

npth_dlclose(handle);

2.  IO 耗时

在做抖音在启动路径上性能优化时，我们统计了冷启动的耗时，其中占比最长的是进程处于 D 状态（不可中断睡眠态，Uninterruptible Sleep ，通常我们用 PS 查看进程状态显示 D，因此俗称 D 状态）的时间，这部分耗时占比占总启动耗时的 40%左右，进程为什么会被置于 D 状态呢？处于 uninterruptible sleep 状态的进程通常是在等待 IO，比如磁盘 IO，其他外设 IO，正是因为得不到 IO 的响应，进程才进入了 uninterruptible sleep 状态，所以要想使进程从 uninterruptible sleep 状态恢复，就得使进程等待的 IO 恢复。类似如下：

但我们在使用 Systrace 进行优化时仅能得到如上内核态的调用状态，却无法得知具体的 IO 操作是什么。因此，我们专门设计了一套获取 IO 耗时信息的方案，其包括用户空间和内核空间两部分。

一是在用户空间，为了采集到需要的 I/O 耗时信息，我们通过 Hook I/O 操作时标准的关键函数族，包括 open，write，read，fsync，fdatasync 等，插入对应的 trace 埋点用于统计对应的 IO 耗时。以 fsync 为例：

int proxy_fsync(int fd) {

BYTEHOOK_STACK_SCOPE();

ATRACE_BEGIN_VALUE(“fsync:”, FileInfo(fd).c_str());

int ret = BYTEHOOK_CALL_PREV(proxy_fsync, fd);

ATRACE_END();

return ret;

}

二是在内核空间，除了可由 systrace 或 atrace 直接支持启用的功能之外，ftrace 还提供了其他功能，并且包含一些对调试性能问题至关重要的高级功能（这些功能需要 root 访问权限，通常可能也需要新的内核）。因此，我们基于此添加了显示定制 IO 信息等功能。在线下模式，我们开启了/sys/kernel/debug/tracing/events/android_fs 节点下 ftrace 信息，用于收集 IO 相关的信息，

这时候，我们追本溯源，先找到 Systrace 之母，Google Android 和 Chrome 团队的所有开源项目 Catapult 。正是 Catapult 生成了 Systrace 及其解析器的工具，在 Catapult 中，采用 javascript 实现了一个跨平台的 trace 解析工具，我们在此基础上开发了 Rhea 工具脚本将转换成 systrace 可显示化的格式，用于快速诊断发现 IO 性能瓶颈。

例如，我们线上监控发现我们某个 View 方法调用 setText 方法会导致 ANR，线下通过 Systrace 抓取 Trace 如下：

此时，看到主线程处于 D 状态，却束手无策，而通过我们的 Rhea 工具，获取 Trace 如下：

我们很容易就定位到此时是由于读取对应字体带来的 IO 耗时导致的问题。

3.  Binder 耗时

在抖音启动性能性能优化过程中，我们通常还会遇到 Sleep 带来的耗时问题，这部分耗时通常占据总耗时的 30%左右，处在这种睡眠状态，进程通常是在等锁或是 Binder 调用耗时导致，通常在线下，我们可以通过开启 tracing/events/binder 节点获取到，但是在线上由于权限问题我们很难获取到这部分信息。因此，我们通过 Hook libbinder.so 对应的 android_os_BinderProxy_transact 方法来统计对应 binder 调用耗时。

if (TraceProvider::Get().isEnableBinder()) {

// static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobject obj,jint code, jobject dataObj, jobject replyObj, jint flags)

bytehook_stub_t stub = bytehook_hook_single(

“libbinder.so”,

NULL,

“_ZN7android14IPCThreadState8transactEijRKNS_6ParcelEPS1_j”,

reinterpret_cast<void*>(proxy_transact),

NULL,

NULL);

stubs.push_back(stub);

}

之后，统计对应 binder 耗时，如果耗时超过指定阈值，则将对应堆栈打印出来用于辅助分析 Sleep 耗时问题。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

写在最后

很多人在刚接触这个行业的时候或者是在遇到瓶颈期的时候，总会遇到一些问题，比如学了一段时间感觉没有方向感，不知道该从哪里入手去学习，对此我整理了一些资料

如果你熟练掌握以下列出的知识点，相信将会大大增加你通过前两轮技术面试的几率！这些内容都供大家参考，互相学习。

①「Android面试真题解析大全」PDF完整高清版+②「Android面试知识体系」学习思维导图压缩包，最后觉得有帮助、有需要的朋友可以点个赞

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！**

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

写在最后

很多人在刚接触这个行业的时候或者是在遇到瓶颈期的时候，总会遇到一些问题，比如学了一段时间感觉没有方向感，不知道该从哪里入手去学习，对此我整理了一些资料

如果你熟练掌握以下列出的知识点，相信将会大大增加你通过前两轮技术面试的几率！这些内容都供大家参考，互相学习。

①「Android面试真题解析大全」PDF完整高清版+②「Android面试知识体系」学习思维导图压缩包，最后觉得有帮助、有需要的朋友可以点个赞

[外链图片转存中…(img-2z3ATu2N-1711989141770)]

[外链图片转存中…(img-ZbI9DYvA-1711989141771)]

[外链图片转存中…(img-GLPwAIOB-1711989141771)]

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！