滴滴DoKit Android核心原理揭秘之函数耗时

技术背景

在日常的开发过程中，App的性能和用户体验一直是我们关注的重点，尤其是对于大公司来说每天的日活都是千万或者上亿的量级。操作过程中的不流畅和卡顿将严重影响用户的体验，甚至可能面临卸载导致用户流失。在拉新成本居高不下的现阶段，每一个用户的流失对于我们来说都是直接的损失。所以想要留住用户就必须提升用户体验，那么流畅顺滑操作过程无卡顿就是我们最基本也是重要的一环。但是随着现在移动端App的业务功能越来越复杂，随之带来的代码量剧增。在几十万行的代码中难免会出现效率低下或者不符合开发规范的代码存在，传统的代码Review需要消耗大量的人力物力而且也不能保证百分之百的能够发现问题，而google官方提供的IDE工具虽然功能强大，信息健全，但是操作复杂，同时还需要我们开发者连接IDE并且手动的去记录和截取这段时间内的代码运行片段进行完整的分析。很多初级开发者对于这样的操作很排斥，在实际的开发过程中使用的次数少之又少，甚至大部分同学根本就没用过这个功能。 正是基于开发过程中的种种痛点，DoKit利用AndroidStudio的官方插件功能加上ASM字节码操作框架，打造了一个开发者和用户都方便查看的函数耗时解决方案。这样，当我们在开发过程中只需要设置好相应的配置参数，在App运行过程中，符合配置要求的函数就会在控制台中被打印出来，函数的耗时和当前所在线程以及当前函数的调用栈都清晰明日，从而极大的提升了用户体验并且降低开发者的开发难度。

现有技术的缺点

现有解决方案的原理

现有方案的原理是基于Android SDK中提供的工具traceview和dmtracedump。其中traceview会生成.trace文件，该文件记录了函数调用顺序，函数耗时，函数调用次数等等有用的信息。而dmtracedump 工具就是基于trace文件生成报告的工具，具体用法不细说。dmtracedump 工具大家一般用的多的选项就是生成html报告，或者生成调用顺序图片（看起来很不直观）。首先说说为什么要用traceview，和dmtracedump来作为得到函数调用顺序的，因为这个工具既然能知道cpu执行时间和调用次数以及函数调用树（看出函数调用顺序很费劲）比如在Android Studio是这样呈现.trace文件的解析视图的:

 

 

 

或者是这样的:

 

 

 

（以上两张图片来源于网络）

通过以上两张图可以发现虽然官方提供的工具十分强大但是却有一个很严重的问题，那就是信息量太大，想要在这么繁杂的信息中找出你所需要的性能瓶颈点难度可想而知，一般的新手根本没有耐心和经验去操作，有时候甚至到懒得去使用这个工具。

DoKit的解决方案

想要提升用户的开发体验，必须满足以下两点:

简单的操作(傻瓜式操作)

直观的数据展示

(以上两点也是我们DoKit团队在规划新功能时的重要指标)

本人经过一系列的调研和尝试，发现市面上现有的解决方案多多少少都存在的一定的问题，比如通过AspectJ、Dexposed、Epic等AOP框架，虽然能够实现我们的需求，但是却存在一定的兼容性问题，对于DoKit这样一个已经在8000+ App项目中集成使用的稳定性研发工具来说，我们不能保证用户在他自己的项目中是否也集成过此类框架，由于两个AOP框架之间由于版本不一致可能会导致编译失败。(其实一开始DoKit也是通过集成AspectJ等第三方框架来作为AOP编程的，后面社区反馈兼容性不好，所以针对整个AOP方案进行了优化和升级)。

经过多次的Demo实验，最终决定采用Google官方的插件+ASM字节码框架作为DoKit的AOP解决方案。

DoKit解决方法的思路

Dokit提供了两个慢函数解决方案(通过插件可配置)

1、全量业务代码函数插装(代码量过大会导致编译时间过长)

2、指定入口函数并查找N级调用函数进行代码插装(默认方案)

（下文的分析主要针对第二种解决方案）

寻找指定的代码插桩节点

对于开发者说，我们的目的是为了在项目运行过程中第一时间发现有哪些函数耗时过长从而导致UI卡顿，然后对指定的慢函数进行耗时统计并给出友好的数据结构呈现。所以，既然要统计一个函数的耗时，我们就必须要在一个函数的开始和结束地方插入统计代码，最后相减即可得出一个函数方法的耗时时间。

举个例子：假如我们需要统计以下函数的耗时时间:

 public void sleepMethod() {
        Log.i(TAG, "我是耗时函数");
    }

其实原理很简单我们只需要在函数的执行前后添加如下代码:

public void sleepMethod() {
        long begin = System.currentTimeMillis();
        Log.i(TAG, "我是耗时函数");
        long costTime = System.currentTimeMillis() - begin;
    }

其中costTime即为当前函数的执行时间，我们只需要将costTime根据函数的类名+函数名作为key保存在Map中，然后再根据一定的算法在运行期间去绑定函数的上下级调用关系(上下级调用关系会在编译时通过字节码增加框架动态插入,下文会分析)。最终在入口函数执行结束的将结果在控制台中打印出来即可。

插入指定的Plugin Transform

Google对于Android的插件开发提供了一个完整的开发套件，它允许我们在Android代码的编译期间插入专属的Transform去读取编译后的class文件并搭配相应的字节码增加工具(ASM、Javassist)并回调相应的生命周期函数来让开发者在指定的生命周期(比如:开始读取一个函数以及函数读取结束等等)函数中去操作Java字节码。

由于AndroidStudio是基于Gradle作为编译脚本，所以我们先来了解一下什么是Gradle。

1、Gradle 是基于Groovy的一种领域专用语言(DSL/Domain Specific Launguage) 2、每个Gradle脚本文件编程生成的类除了继承自groovy.lang.script,同时还实现了接口org.gradle.api.script。 3、Gradle工程build时，会执行setting.gradle、build.gradle脚本；setting脚本的代理对象是Setting对象，build脚本的代理对象是Project对象。

以下为Gradle的生命周期图示:

 

 

我们顺便来看一下Transform的工作原理

 

 

很明显的一个链式结构。其中红色代表自定义的Transform，蓝色代表系统自带的Transform。 每个Transform都是一个Gradle的Task，Android编译其中的TaskManager会将每个Transform串联起来。前一个Transform的执行产物将传递给下一个Transform作为输入。所以我们只需要将自定义的Transform插入到链表的最前面，这样我们就可以拿到javac的编译产物并利用字节码框架(ASM)对javac产物做字节码修改。

插入耗时统计代码

Dokit选取了ASM作为Java字节码操作框架，因为ASM更偏向底层操作兼容性更好同时效率也更高。但是由于全量的字节码插装会导致用户的编译时间增加尤其对于大型项目来说，过长的编译时间会导致开发效率偏低。所以我们必须针对插桩节点进行取舍，以达到开发效率和满足功能需求的平衡点。 以下附上ASM的时序图:

 

 

 

既然我们需要在指定的入口函数中去查找调用的子函数，那么如何去确定这个入口函数呢？DoKit的选择是将Application的attachBaseContex和onCreate这个两个方法作为默认的入口函数，即大家最为关心的App启动耗时统计，当然做为一个成熟的框架，我们也开放了用户指定入口函数的配置，具体可以参考Android接入指南。

那么我们该如何找到用户自定义的Application呢？大家都知道我们的Application是需要在AndroidManifest.xml中注册才能使用的，而且AndroidManifest.xml中就包含了Application的全路径名。所以我们只要在编译时找到AndroidManifest.xml的文件路径，然后再针对xml文件进行解析就可以得到Application的全路径名。具体的示例代码如下:

appExtension.getApplicationVariants().all(applicationVariant -> {
            if (applicationVariant.getName().contains("debug")) {
                VariantScopeKt.getMergedManifests(BaseVariantKt.getScope(applicationVariant))
                        .forEach(file -> {
                            try {
                                String manifestPath = file.getPath() + "/AndroidManifest.xml";