文末
不管怎么样，不论是什么样的大小面试，要想不被面试官虐的不要不要的，只有刷爆面试题题做好全面的准备，当然除了这个还需要在平时把自己的基础打扎实，这样不论面试官怎么样一个知识点里往死里凿，你也能应付如流啊
小编将自己6年以来的面试经验和学习笔记都整理成了一个**937页的PDF，**以及我学习进阶过程中看过的一些优质视频教程。
其实看到身边很多朋友抱怨自己的工资很低，包括笔者也是一样的，其原因是在面试过程中没有给面试官一个很好的答案。所以笔者会持续更新面试过程中遇到的问题，也希望大家和笔者一起进步，一起学习。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
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 工具来辅助分析性能。
-
该工具要非常灵活，可以不依赖 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 代码块进行全插桩;
写在最后
在技术领域内，没有任何一门课程可以让你学完后一劳永逸，再好的课程也只能是“师傅领进门，修行靠个人”。“学无止境”这句话，在任何技术领域，都不只是良好的习惯，更是程序员和工程师们不被时代淘汰、获得更好机会和发展的必要前提。
如果你觉得自己学习效率低，缺乏正确的指导，可以一起学习交流！
加入我们吧！群内有许多来自一线的技术大牛，也有在小厂或外包公司奋斗的码农，我们致力打造一个平等，高质量的Android交流圈子，不一定能短期就让每个人的技术突飞猛进，但从长远来说，眼光，格局，长远发展的方向才是最重要的。
35岁中年危机大多是因为被短期的利益牵着走，过早压榨掉了价值，如果能一开始就树立一个正确的长远的职业规划。35岁后的你只会比周围的人更值钱。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
能优化
在插桩阶段, 我们做了如下优化:
-
支持自定义插桩作用域, 减少 Trace 对于其他无关模块的运行损耗;
-
针对 Trace 数据出现不闭合的问题, 对 catch 代码块进行全插桩;
写在最后
在技术领域内，没有任何一门课程可以让你学完后一劳永逸，再好的课程也只能是“师傅领进门，修行靠个人”。“学无止境”这句话，在任何技术领域，都不只是良好的习惯，更是程序员和工程师们不被时代淘汰、获得更好机会和发展的必要前提。
如果你觉得自己学习效率低，缺乏正确的指导，可以一起学习交流！
加入我们吧！群内有许多来自一线的技术大牛，也有在小厂或外包公司奋斗的码农，我们致力打造一个平等，高质量的Android交流圈子，不一定能短期就让每个人的技术突飞猛进，但从长远来说，眼光，格局，长远发展的方向才是最重要的。
35岁中年危机大多是因为被短期的利益牵着走，过早压榨掉了价值，如果能一开始就树立一个正确的长远的职业规划。35岁后的你只会比周围的人更值钱。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
916
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
