最后
写到这里也结束了，在文章最后放上一个小小的福利，以下为小编自己在学习过程中整理出的一个学习思路及方向，从事互联网开发，最主要的是要学好技术，而学习技术是一条慢长而艰苦的道路，不能靠一时激情，也不是熬几天几夜就能学好的，必须养成平时努力学习的习惯，更加需要准确的学习方向达到有效的学习效果。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
另一方面，通过简单定制 Trace 的获取函数耗时相较于 Systrace，虽然有显著的性能提升，和更高的灵活性，但数据只包含基本的耗时信息，在部分复杂场景（如持有锁引起的耗时），数据仍存在局限。
如上工具都均已无法完全满足抖音的启动、首刷以及低端机等核心场景的性能优化工作，我们需要重新设计和规划功能更加强大的动态一体化 Trace 工具来辅助分析性能。
-
该工具要非常灵活，可以不依赖 PC 端的抓取脚本，同时支持线上线下，能够在应用任何想要抓取数据的时候运行，作为一个平台性工具，Rhea 还需要支持动态扩展，支持多种场景的配置和动态开关，可以将任意需要的信息进行采集。
-
该工具抓取的 Trace 信息要全面，能够采集和追踪包括 ATrace 插桩、等锁信息、I/O 信息以及 Binder 耗时等在内的多种信息。
-
要支持可视化，统一的格式进行输出和格式化，最终以兼容 Systrace 的结果进行前端展示和使用，尽量不要改变使用者习惯。
-
性能损耗要低，以免带偏性能优化方向。
因此，我们重新设计了新一代 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 参数来打开，但是作为普通应用我们没有办法通过这种方式来打开，所以需要用非常规手段在运行时动态打开：
-
首先确认从 Android7.x 开始，这个结构的大小、成员顺序是否有发生变化；
-
如果没有变化，则可以自己定义一个相同的结构，因为里面都是原始的 bool 类型变量，不会引入其他依赖；
-
如果有变化，但是向前兼容，我们想要访问的成员位置没有变化，只是往后追加了成员，也同样可以自己定义相同的结构；
-
通过 dlsym 找到虚拟机的全局符号
gLogVerbosity； -
将其类型转换为预先定义的结构体类型；
-
访问
systrace_lock_logging成员并赋值为 true； -
轻锁的 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 耗时问题。
static void log_binder(int64_t start, int64_t end, int64_t flags) {
JNIEnv *env = context.env;
env->CallStaticVoidMethod(context.javaRef, context.logBinder, start, end, flags);
}
status_t proxy_transact(void *pIPCThreadState, int32_t handle, uint32_t code,
const void *data, void *reply, uint32_t flags) {
// todo: add more informations
nsecs_t start = systemTime();
status_t status = BYTEHOOK_CALL_PREV(proxy_transact, pIPCThreadState, handle, code, data, reply,
flags);
nsecs_t end = systemTime();
nsecs_t cost_us = ns2us(end - start);
if (is_main_thread() && cost_us > 10000) {
log_binder(ns2us(start), ns2us(end), flags);
nsecs_t end_ = systemTime();
}
return status;
}
trace 效果如图所示：
4. 支持后续增加更多数据源
当然，仅仅支持上述这些信息不可能完全覆盖我们性能优化过程中未来还可能遇到的其他问题，因此，我们支持了动态配置的功能，后续仅需要在现有框架下，简单添加对应配置项及其功能即可快速方便收集到我们所需要的信息。
enum TraceConfigKey {
kIO = 0,
kBinder,
kThinLock,
kStopTraceUnhook,
kLockStack,
kKeyEnd,
};
5. 不限层级插桩获取函数耗时
限制插桩的层级固然可以提升运行时性能，但是限制层级后面临两个问题:
-
函数调用数据采集不全面;
-
难以定位深层的耗时调用;
因此在用户态，为了获取 App 更多的 Trace 信息，便于性能优化。我们采用不限制层级的插桩方案。开发了在编译阶段不限制层级插桩的插件，通过静态代码插桩方式，在 App 调用方法的起始和结束位置分别插入 Trace.beginSection 和 Trace.endSection 。效果如下：
三、优化降低性能损耗
1. 插桩性能优化
在插桩阶段, 我们做了如下优化:
-
支持自定义插桩作用域, 减少 Trace 对于其他无关模块的运行损耗;
-
针对 Trace 数据出现不闭合的问题, 对 catch 代码块进行全插桩;
-
针对高频调用函数, 可以选择性的添加到黑名单中, 提升运行时性能;
-
为支持生产环境使用，我们采用在 proguard 后进行插桩，由于函数内联等优化, 相较于混淆前插桩插桩数量可以减少 2.6%。对于线上模式，直接插入方法 ID，收集 Trace 后需在主机端或服务端对方法 id 重新映射成方法名，但又考虑到线下用户的易用性，在线下模式打包阶段直接插入方法名；
-
在编译阶段通过分析字节码信息，过滤掉不耗时函数的插桩。
2. 优化 App 侧启停 Trace 性能
由于 App 侧抓取 Trace 的实现要依赖于 hook，我们参考了 Facebook Profilo 的实现，但其实现存在动态库过大、启停 Trace 耗时问题，因此我们进一步优化了 App 本地获取 atrace 依赖的动态库大小和性能。如下所示：
3. 优化 Trace 写入性能
由于在 App 方法中插入大量 Trace 信息，在开启 atrace 后，所有线程会将所有的 trace 都写入到 trace_marker 文件，会带来 IO 损耗剧增，会掩盖真实性能问题，原因是所有线程都在短时间向 trace_marker 文件进行写入操作，同时竞争内核态 pos 锁，导致获取到的 trace 文件无法真实反映性能问题，如下图所示：
因此，我们将原本直接写入内核态文件的 Trace 在用户态进行拦截，缓存起来，再以异步 IO 的方式转储。既避免了大量用户态与内核态切换带来的上下文损耗，又避免了直接 IO 带来的 IO 损耗。效果如下所示：
四、可视化
由于我们将用户态 atrace 和内核态 ftrace 分别存储在对应空间下的 ringbuffer 中，原生的 systrace 只能分别进行可视化，因此我们开发了统一整合 trace 的脚本工具，将多个 trace 信息将成为单个的 html 文件，当浏览 trace 信息时，可在 Chrome（chrome://tracing 访问）中可视化显示。
未来规划
====
目前，Rhea 对 Native 的支持还不够全；性能优化还不够极致，特别在用于分析卡顿问题时需要定位几毫秒甚至更细粒度耗时的情况下，性能损耗仍然会有些偏大，在一定程度上会带偏优化方向；目前 Trace 工具更多的还是在线下使用，由于插桩过多影响了包大小，使得我们线上部分只能对小规模的用户群体定向打开，没法全量上线定位线上大规模用户的性能问题。未来我们会重点解决如上问题，将 Trace 工具打造到极致。
小结
==
目前新一代 Trace 分析工具 Rhea 其主要优势如下:
最后
现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水！
为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀，而你是不是还在满足于现状内心在窃喜！
Android架构师之路很漫长，一起共勉吧！
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
几毫秒甚至更细粒度耗时的情况下，性能损耗仍然会有些偏大，在一定程度上会带偏优化方向；目前 Trace 工具更多的还是在线下使用，由于插桩过多影响了包大小，使得我们线上部分只能对小规模的用户群体定向打开，没法全量上线定位线上大规模用户的性能问题。未来我们会重点解决如上问题，将 Trace 工具打造到极致。
小结
==
目前新一代 Trace 分析工具 Rhea 其主要优势如下:
最后
现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水！
为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀，而你是不是还在满足于现状内心在窃喜！
Android架构师之路很漫长，一起共勉吧！
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
扫一扫
1644
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
