原文地址：https://neyoufan.github.io/2017/03/10/android/NAPM%20Android%20SDK/
NAPM 是网易的应用性能管理平台，采用非侵入的方式获取应用性能数据，可以实时展示多个维度的分析结果。本文主要给大家分享一下Android端SDK的实现原理。
前言
APM（Application Performance Management），应用性能管理，主要是为了解决应用上线之后，性能问题难以发现、难以定位的问题，通过接入APM，可以实时了解应用在运行过程中的性能表现，快速定位和修复问题。
目前国内外有不少的应用性能管理平台，例如国外的 New Relic、AppDynamics，国内的听云、OneAPM，国内各大公司也都有自己的性能监控体系。
我们也开发了自己的平台 NAPM 供公司内部的产品使用，移动端目前主要采集了网络性能、交互性能和数据（数据库、JSON、Image）处理性能数据，网络性能目前主要采集了Http请求过程中的一些性能指标，比如响应时间、首包时间、DNS时间等，同时再结合机型、版本、地理位置、运营商、网络环境等多个维度，就可以使用户方便地了解应用在各种状态下的性能表现，从而及时发现问题，做出适当的调整，达到优化用户体验的目的。
下图是NAPM平台某个应用的多维分析展示界面
Alt pic
接下来主要给大家分享一下网易NAPM Android端SDK的实现原理。
Android APM基本原理
简单来说，一个APM平台的工作流程大致如下：在各端（移动端、前端、后端）采集性能数据，然后上传到后端进行建模、存储，由平台进行分析、挖掘，最后通过可视化的方式展示给用户。
移动端SDK实际上只是一个数据采集系统，负责收集并上传终端上产生的性能数据，大致可以划分为三个模块，最底层是数据采集模块，负责采集各种性能数据，采集到的数据经过简单的处理之后存储在内存或者数据库中，最上层是数据的消费模块，通常会将采集到的数据上传到后台，供平台存储、分析和展示，同时我们也支持将采集到的性能数据交给用户处理，方便用户挖掘有用信息。
Alt pic
这里我们使用到了数据库，主要是因为存在一些情况，会导致采集到的数据不能实时发送至后台
- 当网络状态较差，上传失败
- 当前无可用网络连接，无法上传
- 当前网络状态不满足上传条件（用户可以设置，比如仅在wifi的状态下上传数据）
因此我们需要将数据进行存储，在合适的时机上传到后台，尽量保证数据的完整。
APM SDK的难点是数据的采集，手动埋点的方式无疑是行不通的，一方面代价太大且容易产生错误，另一方面对于没有源代码的第三方库我们无法直接修改，因而不能满足我们的需求。参考New Relic，我们选择在应用构建期间通过修改字节码的方式来进行代码插桩。
首先我们看一下应用构建的过程:
Alt pic
可以看到，应用中所有的class文件包括引用的第三方库中的class，都会经由dex过程，被转化为一个或者多个dex文件，正因为所有的class文件都会在dex这一步被处理，所以我们选择在这里进行字节码插桩。
javaagent + Instrumentation
dex的过程是在dx程序中进行，而dx程序是由java实现的，这里我们使用到了javaagent技术，它可以使我们在JVM加载class文件前对字节码作出修改，这里简单介绍一下用法，主要分为两步
- 实现一个javaagent
- 加载javaagent
实现javaagent
javaagent的形式是一个jar包，根据javaagent的不同加载方式，对它的实现也有不同的要求。
如果javaagent是在虚拟机启动之后加载的，我们需要在它的manifest文件中指定Agent-Class属性，它的值是javaagent的实现类，这个实现类需要实现一个agentmain方法
public static void agentmain(String agentArgs, Instrumentation instrumentation) {
//xxx
}
agentmain会成为javaagent的入口，它会在javaagent被加载时调用。
但是如果javaagent是在JVM启动时通过命令行参数加载的，情况会不太一样，需要在它的manifest文件中指定Premain-Class属性，它的值是javaagent的实现类，这个实现类需要实现一个premain方法。
public static void premain(String agentArgs, Instrumentation instrumentation) {
//xxx
}
我们知道，一个java程序的入口是main方法，而如果javaagent是在JVM启动时通过命令行参数加载的，虚拟机会在应用的main方法执行之前调用javaagent的premain方法，这应该也是premain方法名字的由来吧。
如果要支持两种加载方式，那么上述的条件需要同时满足。并且如果通过命令行参数在JVM启动时加载，agentmain方法不会再被调用。而在这个时候，应用中的类还没有被加载到虚拟机，所以给我们修改字节码带来了便利，因为一个类被加载之后，修改它的字节码会比较麻烦。
我们看到premain方法的第二个参数是一个Instrumentation的实例，Instrumentation接口有一个方法
void addTransformer(ClassFileTransformer transformer, boolean canRetransform)
它会在虚拟机中注册一个ClassFileTransformer，transformer会在类加载时对类进行处理，ClassFileTransformer接口只定义了一个方法
byte[] transform(ClassLoader loader,
String className,
Class classBeingRedefined,
ProtectionDomain protectionDomain,
byte[] classfileBuffer)
throws IllegalClassFormatException
而这个方法的作用就是修改一个类的字节码，className是这个类的名称，classfileBuffer是这个类原本的字节码，而返回值是修改过后的字节码，如果没有修改，可以直接返回null。
因此，如果我们想在程序运行前改变一个类的字节码，可以在javaagent的premain方法中调用Instrumentation的实例的addTransformer方法，添加一个自定义的ClassFileTransformer。伪代码如下：
//实现一个javaagent，注册自定义的ClassFileTransformer
public class MyJavaAgent {
public static void premain(String agentArgs， Instrumentation inst)
throws ClassNotFoundException， UnmodifiableClassException {
inst.addTransformer(new MyTransformer());
}
}
//实现一个 ClassFileTransformer，对xxx.xxx.xxx类的字节码进行修改
public class MyTransformer implements ClassFileTransformer {
public byte[] transform(ClassLoader classLoader, String className, Class clazz,
ProtectionDomain protectionDomain, byte[] bytes) throws IllegalClassFormatException {
if(name.equals("xxx.xxx.xxx")) {
return changeByteCode(bytes);
}
return null;
}
}
加载javaagent
前边已经提到了javaagent有两种加载方式
1) JVM启动时通过命令行参数加载javaagent
- manifest中需要指定Premain-Class属性
- 需要实现premain方法
- premain方法会在程序的main方法之前执行
-
agentmain方式不会被调用
通过命令行加载javaagent的形式如下：
-javaagent:jarpath[=options]一个示例如下：
java -javaagent:/path/to/myagent.jar -jar myapp.jar
2) JVM启动后动态加载javaagent
- manifest中需要指定Agent-Class属性
- 需要实现agentmain方法
-
agentmain方法会在javaagent被加载时执行
一般运行时加载agent的方法如下：
String nameOfRunningVM = ManagementFactory.getRuntimeMXBean().getName(); int p = nameOfRunningVM.indexOf('@'); String pid = nameOfRunningVM.substring(0, p); String jarFilePath = "/the/path/to/the/agent/jar"; try { VirtualMachine vm = VirtualMachine.attach(pid); vm.loadAgent(jarFilePath); vm.detach(); } catch (Exception e) { throw new RuntimeException(e); }
具体使用细节可参考VirtualMachine介绍http://docs.oracle.com/javase/7/docs/jdk/api/attach/spec/com/sun/tools/attach/VirtualMachine.html
借助javaagent，我们可以将代码插桩的工作分为两个步骤：首先是获取到应用中所有的字节码，然后是对应用的字节码进行修改。
获取应用字节码
首先从要解决的问题出发，上边提到我们会在dex的这一步去获取字节码，通过查看dx程序的代码，我们发现，在dex的过程中所有的class文件会经由com.android.dx.command.dexer.Main的processClass()方法进行处理,processClass()的代码如下：
/**
* Processes one classfile.
*
* @param name {@code non-null;} name of the file, clipped such that it
* should correspond to the name of the class it contains
* @param bytes {@code non-null;} contents of the file
* @return whether processing was successful
*/
private boolean processClass(String name, byte[] bytes) {
if (! args.coreLibrary) {
checkClassName(name);
}
try {
new DirectClassFileConsumer(name, bytes, null).call(
new ClassParserTask(name, bytes).call());
} catch(Exception ex) {
throw new RuntimeException("Exception parsing classes", ex);
}
return true;
}
第一个参数是应用中一个类的名字，第二个参数就是这个类的字节码了，应用中所有的类，都会经过这个函数进行处理。
所以我们打算修改com.android.dx.command.dexer.Main的processClass()方法，从而获取到应用中的字节码，那么现在的问题就变成了如何修改com.android.dx.command.dexer.Main的processClass()方法。
掌握了javaagent，想要修改dx程序中com.android.dx.command.dexer.Main的字节码就变得比较容易了，我们需要实现一个javaagent，在其中注册一个ClassFileTransformer，在ClassFileTransformer的transform()方法中对com.android.dx.command.dexer.Main的字节码进行修改，最后在dx程序启动时将这个javaagent加载进去就好了。
//实现一个 ClassFileTransformer，对com.android.dx.command.dexer.Main类的字节码进行修改
public class MainTransformer implements ClassFileTransformer {
public byte[] transform(ClassLoader classLoader, String className, Class clazz,
ProtectionDomain protectionDomain, byte[] bytes) throws IllegalClassFormatException {
if(name.equals("com/android/dx/command/dexer/Main")) {
return changeMainClassByteCode(bytes);
}
return null;
}
}
byte[] changeMainByteCode(byte[] bytes) {
//修改Main的 processClass() 方法
//返回修改后Main的字节码
}
如果你是通过命令行来手动构建应用的，到这里已经可以用上边的方式获取到应用中的字节码了，然而大多数人在开发Android的时候，并不会通过命令行去手动构建，而是通过使用一些构建工具，来完成自动化构建，而dx程序则是由构建工具启动的，所以我们面临的问题就是如何将javaagent加载到dx进程。
我们目前支持了ant构建和gradle构建，通过查看ant和gradle的代码，我们发现最终它们都会通过java.lang.ProcessBuilder的start()方法来启动dx进程。
通过查看java.lang.ProcessBuilder的代码，我们发现它有一个成员
private List command;
它是用来保存的是启动目标进程的命令和参数，我们需要做的就是在调用start()方法启动dx进程时，将加载javaagent的参数（-javaagent:jarpath[=options]）添加到command中。
这里我们仍然使用javaagent来完成这个工作，我们需要实现另外一个javaagent，在其中注册一个另一个ClassFileTransformer，在它的transform方法中对java.lang.ProcessBuilder的字节码进行修改。
//实现一个 ClassFileTransformer，对com.android.dx.command.dexer.Main类的字节码进行修改
public class ProcessBuilderTransformer implements ClassFileTransformer {
public byte[] transform(ClassLoader classLoader, String className, Class clazz,
ProtectionDomain protectionDomain, byte[] bytes) throws IllegalClassFormatException {
if(name.equals("java/lang/ProcessBuilder")) {
return changeProcessBuilderClassByteCode(bytes);
}
return null;
}
}
byte[] changeProcessBuilderClassByteCode(byte[] bytes) {
//修改ProcessBuilder的 start() 方法
//返回修改后ProcessBuilder的字节码
}
那么最终问题就变成了如何把这个javaagent加载到ant进程和gradle进程。
它们对应到了javaagent的两种加载方式
-
ant构建-JVM启动时加载
export ANT_OPTS="-javaagent:/path/to/agent.jar"（mac os环境，windows不太一样）在ant构建前进行上述配置，可以在启动ant时加载指定的javaagent，这里使用的是在JVM启动时通过命令行参数加载javaagent的方式。
-
gradle构建 -JVM启动后加载
我们会编写一个gradle插件来完成javaagent的加载，当我们的插件被加载时，gradle进程已经运行起来了，因此只能通过动态的方式加载javaagent。
因此，获取字节码的流程，大致如下图所示：
Alt pic
这个过程中主要使用了两个javaagent，一个用来修改ProcessBuilder类，另一个用来修改Main类，涉及到的进程是ant构建进程或者gradle构建进程，以及由它们启动的dx进程。
对于gradle构建方式，需要注意一点，gradle plugin 在2.1.0之后的版本，支持dx in-process，它使得dx的过程可以直接在当前的gradle进程中执行，而不需要额外启动一个dx进程，从而缩短应用构建的时间。如果你在使用Android Studio构建应用的时候看到To run dex in process, the Gradle daemon needs a larger heap. It currently has 910 MB这样的一句话，它就是指导用户通过配置gradle daemon进程的堆大小来开启dx in-process特性的。
而这个新的特性，会给我们设置javaagent带来麻烦，不启动dx进程使得我们无法对dx进程设置javaagent，而在gradle进程中动态加载javaagent时，com.android.dx.command.dexer.Main类早已经加载过了，所以通过javaagent方式来获取字节码会变得十分困难。
幸运的是，gradle plugin 在1.5.0之后，提供了一个Transform API，它允许第三方插件操作编译后的class文件，而修改的时机正是在将这些字节码转换为dex文件之前，这里就不在展开讲解了，感兴趣的同学可以参考下这篇文章http://blog.csdn.net/sbsujjbcy/article/details/50839263。
修改应用字节码
通过javaagent修改com.android.dx.command.dexer.Main和java.lang.ProcessBuilder，以及最终修改应用的字节码进行插桩，都需要对.class文件的格式以及java虚拟机有比较深入的了解，另外需要使用字节码操作工具来帮助我们对字节码进行改造，这里不详细讲解，只是推荐一些有用的的字节码操作框架和工具，后边可能会有同事做相关的分享。
-
ASM是一个 Java 字节码操控框架。它能被用来动态生成类或者增强既有类的功能。ASM 可以直接产生二进制 class 文件，也可以在类被加载入 Java 虚拟机之前动态改变类行为。
-
Javassist是一个开源的分析、编辑和创建Java字节码的类库,它提供了源码级别的API以及字节码级别的API，源码级别的API，直接使用java编码的形式，而不需要深入了解虚拟机指令，就能动态改变类的结构或者动态生成类。
-
Bytecode Outline plugin for Eclipse是一个非常有用的eclipse 插件，可以查看当前正在编辑的java文件或者class文件的字节码。
-
如果需要逆向APK，查看字节码修改的效果，除了dex2jar外，再给大家推荐一个google的逆向工具enjarify。
小结
本文重点介绍了使用javaagent在应用打包过程中修改com.android.dx.command.dexer.Main和java.lang.ProcessBuilder的字节码，从而获取到应用的字节码，进行插桩的基本原理，并没有涉及so hook相关的原理，以后有机会的话会再做一次分享。