APP流畅度优化做得再好，怎么防止同事在代码里面“下毒”再次劣化呢？(2)，Android开发社招面试经验

这部分内容比较多，主要是从源码层面解析一下整个过程，也是我们后面做流畅度监控与优化的基础

2、Debug阶段如何对实时帧率进行监控和显示

根据上面的原理，设计一个显示实时帧率的工具，可以有效的在开发阶段发现问题

3、如何实现流畅度自动化测试

实现一个流畅度UI自动化测试，在上线前跑一下UI自动化并生成流畅度报表邮件给相关人员

4、线上的用户流畅度的监控方案

实时反映真实用户的流畅度体验，线上庞大的数据可以敏感的反应出版本迭代间流畅度的变化

5、实现一个方便排查高耗时方法的工具

利用自定义gradle plugin+ASM插桩实现快速而准确的找出耗时的方法，进行针对性的优化

6、分享提升app流畅度的一些经验

分享一些成本小收益高的提升流畅度的方案

工欲善其事必先利其器，今天首先分享一下在优化页面流畅度过程中自己实现的一个方便快速排查高耗时方法的工具：MethodTraceMan，毕竟保持主流程流畅，避免在主流程执行高耗时方法永远是优化卡顿最直接的手段，只要我们能快速方便的排查到高耗时的方法，就可以做针对性优化

实现一个方便排查高耗时方法的工具

---

平常我们用来排查Android卡顿的比较熟悉的工具有TraceView、systrace等，一般分为两种模式：instrument和sample。

但是这些工具不管是哪种模式都有各自不足的地方，比如instruement模式，可以获得所有函数的调用过程，信息比较丰富，但是会带来极大的性能开销，导致统计的耗时与实际不符；而sample模式是通过采样的方式进行分析的，所以信息丰富度上就大打折扣，像systrace就属于sample型的，它只能监控一些系统调用的耗时情况。

除了上面说的工具，著名的JackWharton也实现了一个可以打印出出方法耗时的工具hugo,它是基于注解触发的，在一个方法上加上特定注解即可打印出该方法的耗时等信息，但是如果我们想排查高耗时方法，显然在所有方法上一个一个加注解太费劲了。

那么我们在做卡顿优化的过程中需要一个什么样的工具呢？

• 可以方便地统计所有方法的耗时

• 对性能影响微小，能准确统计出方法的精确耗时

• 支持耗时筛选、线程筛选、方法名搜索等功能，能快速发现主线程高耗时方法

要实现这样一个工具，首先想到的就是通过插桩技术来实现，在编译过程中对所有的方法进行插桩，在方法进入和方法结束的地方进行打点，就可以在对性能影响很小的方式下统计到每个方法的耗时。统计到每个方法的耗时数据后，我们再实现一个UI界面来展示这些数据，并实现耗时筛选、线程筛选、方法名搜索等功能，这样我们就可以快速的找到主线程高耗时的方法进行针对性的优化了。

1、效果预览

---

我们先来看下最终实现的效果预览：

输出所有的方法耗时，高耗时方法以红色预警，同时支持对耗时筛选，线程筛选，方法名搜索等，比如想筛出主线程耗时大于50ms的方法，就可以很方便的找出。

详细的集成以及使用文档详见：

MethodTraceMan

2、技术选型

---

插桩技术其实充斥在我们平常开发中的方方面面，可以帮助我们实现很多繁琐复杂的功能，还可以帮助我们提高功能的稳定性，比如ButterKnife、Protocol Buffers等都会在编译时期生成代码，当然插桩技术也分很多种，比如ButterKnife是利用APT在编译的开始阶段对java文件进行操作，而像AscpectJ、ASM等则是在java文件编译为字节码文件后，对字节码进行操作，当然还有一些可以在字节码文件被编译为dex文件后对dex进行操作的框架。

由于我们的需求是在编译期对所有的方法的进入和结束的地方插桩进行耗时统计，所以最终的技术选型锁定在对字节码文件的操作。那么我们来对比一下AspectJ和ASM两种字节码插桩的框架：

一、AspectJ

AspectJ是老牌的字节码处理框架了，其优点就是使用简单上手容易，不需要了解字节码相关知识也可以在项目中集成使用，只要指定简单的规则就可以完成