百度App性能优化工具篇 - Thor原理及实践
01 背景
App开发过程中，如果遇到一些疑难问题或者性能问题（如低端机卡顿），由于没法拿到更多系统的有效信息很难有效定位。这时，Hook不失为一种好的解决方案，Hook技术是在程序运行的过程中，动态的修改代码，植入自己的代码逻辑，修改原有程序执行流程的技术。Hook技术有如下几点能力：
【耗时监控】在代码前后动态插入Trace打点，统计耗时；
【性能监控】IO监控、内存监控、View绘制监控、大图检测等；
【安全审查】Hook敏感API（例如定位），用以安全评审；
【逆向和脱壳】对病毒样本进行逆向和脱壳分析；
Hook技术由来已久，目前业界Java和Native Hook都有不少优秀的开源框架，但是如果我们需要将Hook能力使用到线上，都或多或少有些问题，例如兼容性、稳定性、动态性等等。鉴于此，我们开发了一套Thor容器框架，提供标准的Hook接口，降低学习成本，同时将开源框架按照接口适配成插件动态下发按需安装，保证Hook能力的完备和轻量性，并且后续出现更加优秀以及自研的框架的可以无缝的接入和Hook能力拓展，并且不需要上层业务代码和插件进行适配，保证兼容性。
02 现状
Android系统的编程语言主要分为Java和C/C++，Hook方向也主要分为Native和Java Hook两种，其中Native Hook原理也主要分为PLT / Inline Hook两大类，然后Java Hook也分为替换入口点Hook（Replace Entrypoint Hook）和类Inline Hook两大类。Native 方法执行流程大概如下：
GOT（Global Offset Table）：全局偏移表用于记录在 ELF 文件中所用到的共享库中符号的绝对地址。PLT（Procedure Linkage Table）：过程链接表的作用是将位置无关的符号转移到绝对地址。当一个外部符号被调用时，PLT 去引用 GOT 中的其符号对应的绝对地址，然后转入并执行。
Java 方法执行流程大概如下：
丨 2.1 常见Native Hook框架
丨 2.1.1 xHook框架
xHook框架通过PLT Hook方案来实现的，PLT Hook是通过直接修改GOT表，使得在调用该共享库的函数时跳转到的是用户自定义的Hook功能代码。流程如下：
- 由于修改的是GOT表中的数据，因此修改后，所有对该函数进行调用的地方就都会被Hook到。这个效果的影响范围是该PLT和GOT所处的整个so库。
- PLT与GOT表中仅仅包含本ELF需要调用的共享库函数项目，因此不在PLT表中的函数无法Hook到（比如非export导出函数就无法Hook到）。
丨 2.1.1 Andorid-Inline-Hook框架
Inline Hook的原理则是直接修改函数在.text实际执行的机器码来实现Hook，不仅对所有SO生效，还能Hook非export导出函数，补齐了PLT Hook方法的不足。流程如下：
丨 2.2 常见Java Hook框架
丨 2.2.1 Dexposed框架
Dexposed框架只支持Dalvik虚拟机，此虚拟机通过Method结构体中accessFlags字段来判断当前方法是字节码还是机器码。该框架通过修改accessFlags字段为ACC_NATIVE，将Java原方法注册为Native方法，调用时会先调用Native Hook方法，再反射调用Java原方法来实现Hook的目的，流程图如下所示：
丨 2.2.2 Epic框架
Epic框架则是在Dexposed的基础上，增加了对ART虚拟机Hook的能力。由于ART虚拟机的复杂性（AOT和JIT），Java代码执行的入口可能随时都在变化，如果通过ArtMethod中的entry_point_from_quick_compiled_code_字段入口进行Hook，可能会发生不可预期的崩溃。Epic则是在 Wißfeld, Marvin 的论文ArtHook: Callee-side Method Hook Injection on the New Android Runtime ART基础上做了实现，大概思路是把entry_point_from_quick_compiled_code_指向的机器码地址（未编译的字节码也会强制编译成机器码，类似于Inline Hook）进行修改，跳转到跳板代码，然后通过跳转代码进行分发，调用Hook方法之后再调用原方法，来达到Hook的目的。流程图如下：
丨 2.3 常见框架对比
- Hook能力不完备：无法同时满足所有的Hook场景（Java Hook和Native Hook）；
- 兼容性问题：由于现有框架可能存在各种各样的稳定性问题，导致如果后续替换Hook框架，则所有的业务Hook逻辑都要修改存在兼容性问题；
- 不支持动态Hook：只能将代码内置到主包中，没法动态下发安装实现动态Hook；
- 没有容错机制：大部分框架都有稳定性问题且没有容灾机制，如果导致应用崩溃，会导致灾难性的后果。
03 方案选型
从现有状况来看，如果同时需要Java/Native Hook的能力，那么至少需要集成两个框架，业务代码也只能在主包中编写，增加包体积。其次如果替换使用更加优秀或者自研的框架时，所有的业务代码也要跟着修改，学习和适配兼容的成本巨大。最后Hook框架导致的崩溃，因为没有动态能力和容灾机制也只能重新发布应用和铺渠道，影响用户体验。
虽然每个框架都有各自的一些问题，但是要求我们从头开始开发一款同时支持Java和Native Hook的框架，没有稳定性问题并且兼容所有安卓版本、轻量且容灾的框架，重复造轮子并且ROI太低，所以我们要开发自己的一套容器框架，取长处补短板，充分利用好已有的框架来实现目标。百度App作为超级App，本身就是一个航空母舰，容器框架要在其上线至少需要达到以下几点要求：
- 完备性：需要支持所有的Hook能力（Java和Native Hook），能够覆盖所有代码范围；
- 兼容性：插件保证向后兼容，即使替换底层Hook框架，业务完全无感知，不需要重新学习和适配新的Hook框架；
- 轻量动态性：体积要尽量保证轻量，这对于手百尤为重要，并且支持通过云控下发的方式动态安装运行；
- 容灾性：发生连续启动崩溃时可以自关闭恢复，不会持续影响线上用户。
04 Thor揭秘
为了满足上述要求，我们开发了Thor容器框架，提供标准的Hook接口，包含Java和Native Hook接口，业务方不需要关心底层实现逻辑（如同虚拟文件系统VFS），只需要了解如何使用这些接口即可，极大的降低学习接入成本。同时将稳定的开源框架按照接口适配成插件，将这些Hook能力进行抽象，按需动态的安装加载，保证Hook能力的完备性和轻量性。并且后续出现更加优秀以及自研的框架的可以无缝的接入，对上层也是无感知的，不需要上层业务代码和插件进行适配，很好的保证了兼容性。
丨 4.1 Thor整体结构
丨 4.1.1 Thor架构图
- 支撑业务：支撑了低端机、隐私合规、OOM和流水线等多个业务；
- Thor抽象层：主要包含Java / Native Hook和Thor Module的业务模块等抽象层接口；
- 应用层插件：包含了SP、IO、线程、内存等基础插件或者业务相关插件，其适配实现了Thor Module的业务模块接口；
- 实现层插件：Epic（Java Hook）、xHook(PLT Hook)、Android-Inline-Hook(Inline Hook)或者自研等插件，其适配实现了Java / Native Hook接口；
- Thor框架
- 插件模块：支持自主开发插件，支持插件热插拔，可以通过内置或云控动态下发，即时生效；维护和调度插件的生命周期；
- 沙盒模块：支持在沙盒进程安装插件，不影响主进程，重启生效；
- 校验模块：支持对插件进行安全校验，保证插件来源安全性；
- 插件管理界面：支持对已有插件动态安装和卸载的控制管理界面。
Thor实现层插件和Thor应用层插件都是apk的形式存在，但是也可以以组件源码的形式集成打包到宿主中。
丨 4.2 Thor核心优势
丨 4.2.1 易用性
Thor只开发抽象层接口，底层实现对业务是不可见的，不需要反复学习，这样最大程度的保证了易用性。Java/Native Hook都提供了标准的接口供业务方使用，接口如下：
- Java Hook接口 （Thor提供Java Hook能力的接口）
public interface IHookEntity {
......
/**
* Hook指定的方法
*
* @param hookedMethod 待Hook的方法Method对象
* @param hookCallback Hook回调{@link IHookCallback}
*/
void hookMethod(Member hookedMethod, IHookCallback hookCallback);
......
}如果是Java Hook使用方只需要直接使用该接口的能力即可；如果是能力提供方，则需要将Java Hook能力注入到Thor抽象层的Java Hook接口实现中。
- Native Hook接口（Thor提供Native Hook能力的接口，包含PLT Hook和Inline Hook）
struct thor_abstract {
// 函数定义：PLT Hook实现框架的函数指针
// lib_name 被Hook的so库的名称
// symbol 被Hook的函数名
// hook_func Hook方法
// backup_func 原方法备份（函数指针）
int (*thor_plt_hook)(const char *lib_name, const char *symbol, void *hook_func, void **backup_func);
// 函数定义：Inline Hook实现框架的函数指针
// target_func 原方法
// hook_func Hook方法
// backup_func 原方法备份（函数指针）
int (*thor_inline_hook)(void *target_func, void *hook_func, void **backup_func);
// PLT Hook二期（新增接口，支持批量plt hook）
struct thor_plt_ext *plt_ext;
};如果是Nava Hook使用方只需要直接使用该接口的能力即可；如果是能力提供方，则需要将Nava Hook能力注入到Thor抽象层的Native Hook接口实现中。
- Thor Module接口 （Thor提供的业务模块接口）
public abstract class ThorModule implements IThorModule {
/**
* 调度插件的加载生命周期
*/
public abstract void handleLoadModule();
/**
* 宿主通知和更新插件配置信息生命周期
*/
public void onPluginFuncControl(PluginFuncInfo pluginFuncInfo) {
}
}主要提供给业务模块使用，如果需要使用Hook能力，直接在handleLoadModule子类实现中调用Thor的各个Hook能力即可（不是必须使用的，Thor作为容器框架只是额外提供了Hook的能力而已）。
丨4.2.2 完备性
该框架同时支持Java / Native Hook的能力，具有完备的Hook能力。上小节讲解了提供给业务方的Java/Native Hook和 Thor Module业务模块等抽象层接口，底层实现则根据接口进行适配之后，通过静态代码依赖注入或动态模块加载注入到抽象层实现中，这样Thor就具备了完备的Hook能力。
- Thor的 Java Hook 能力 (类Xposed API)
Hook Handler#dispatchMessage方法，代码如下：
ThorHook.findAndHookMethod(Handler.class, "dispatchMessage", new IHookCallback() {
@Override
public void beforeHookedMethod(IHookParam param) {
Message msg = (Message) param.getArguments()[0];
Log.d(TAG, ">>>>>>>>>>>dispatchMessage: " + msg);
}
@Override
public void afterHookedMethod(IHookParam param) {
Log.d(TAG, "<<<<<<<<<<<<dispatchMessage: ");
}
}, Message.class);继续看Thor#findAndHookMethod的逻辑，代码如下：
/**
* 寻找方法并将其Hook，最后一个参数必须是Hook方法的回调
*
* @param clazz Hook方法所在类的类名称
* @param methodName Hook方法名
* @param hookCallback 回调{@link IHookCallback}
* @param parameterTypes Hook方法的参数类型
*/
public static void findAndHookMethod(Class<?> clazz, String methodName,
IHookCallback hookCallback, Class<?>... parameterTypes) {
......
Method methodExact = ThorHelpers.findMethodExact(clazz, methodName, parameterTypes);
hookMethod(methodExact, hookCallback);
......
}ThorHook#findAndHookMethod通过类的类类型、函数名和参数，找到相应的Method，再调用ThorHook#hookMethod进行Hook，继续看如下代码：
/**
* Hook指定的方法
*
* @param hookedMethod 待Hook的方法Method对象
* @param hookCallback Hook回调{@link IHookCallback}
*/
public static void hookMethod(Member hookedMethod, IHookCallback hookCallback) throws HookMethodException {
......
CallbacksHandler callbacksHandler;
synchronized (sHookedMethodCallbacks) {
callbacksHandler = sHookedMethodCallbacks.get(hookedMethod);
if (callbacksHandler == null) { // 未Hook过的Method
callbacksHandler = new CallbacksHandler();
callbacksHandler.register(hookCallback);
sHookedMethodCallbacks.put(hookedMethod, callbacksHandler);
} else { // Hook过的Method，只需要注册回调即可
callbacksHandler.register(hookCallback);
return;
}
}
ThorManager.getInstance().getHookEntity().hookMethod(hookedMethod, callbacksHandler);
}多个业务方如果Hook了同一个java 方法，会被加到缓存中，Hook回调的时候再逐个进行分发；继续可以看到hookMethod最后调用到了getHookEntity#hookMethod方法，最终会调用到具体Java Hook框架实现的hookMethod方法，例如Epic的适配代码如下：
/**
* Epic框架适配类
*/
public class EpicHookEntity implements IHookEntity {
@Override
public void hookMethod(Member hookedMethod, final IHookCallback hookCallback) {
// Epic Hook方法回调
XC_MethodHook xc_methodHook = new XC_MethodHook() {
@Override
protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
// 将Epic Hook方法信息包装成抽象层Hook方法信息
IHookParam hookParam = new EpicHookParam(param);
if (hookCallback != null) {
// 调用before回调
hookCallback.beforeHookedMethod(hookParam);
}
}
@Override
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
// 将Epic Hook方法信息包装成抽象层Hook方法信息
IHookParam hookParam = new EpicHookParam(param);
if (hookCallback != null) {
// 调用after回调
hookCallback.afterHookedMethod(hookParam);
}
}
};
// Epic Hook Method
DexposedBridge.hookMethod(hookedMethod, xc_methodHook);
}
}- Thor的 Native Hook 能力
使用PLT Hook 对应SO所在PLT表的open函数，Inline Hook puts方法，部分代码如下：
thor_abstract *impl = reinterpret_cast<thor_abstract *>(nativePtr);
// plt hook open
thor->thor_plt_hook(so_name, "open", (void *) ProxyOpen, (void **) &original_open);
// inline hook puts
impl->thor_inline_hook((void *) puts, (void *) new_puts, (void **) &origin_puts);根据4.2.1中的Native Hook接口可知，thor_plt_hook和thor_inline_hook成员都是函数指针，指针只有指向真正的Native Hook能力，代码才会生效，所以相应的Hook框架也需要根据Native Hook接口进行适配，例如xHook适配PLT Hook部分代码如下：
thor_abstract *thor = reinterpret_cast<thor_abstract *>(nativePtr);
// plt hook函数指针赋值
thor->thor_plt_hook = xhook_impl_plt_hook;
.....
// xhook适配部分代码
int xhook_impl_plt_hook(const char *so_name, const char *symbol, void *new_func, void **old_func) {
void *soinfo = xhook_elf_open(so_name);
if (!soinfo) {
return -1;
}
if (xhook_hook_symbol(soinfo, symbol, new_func, old_func) != 0) {
return -2;
}
xhook_elf_close(soinfo);
return 0;
}Android-Inline-Hook适配Inline Hook接口部分示例代码如下：
// inline hook函数指针赋值
thor->thor_inline_hook = impl_inline_hook;
// andorid-inline-hook适配部分代码
int impl_inline_hook(void *target_func, void *new_func, void **old_func) {
if (registerInlineHook((uint32_t) target_func, (uint32_t) new_func, (uint32_t **) old_func)) {
return -1;
}
if (inlineHook((uint32_t) target_func) != ELE7EN_OK) {
return -2;
}
return 0;
}我们在使用这些底层Hook框架适配组件（插件）的过程中，也遇到了一些问题，例如Epic在Hook Handler#dispatchMessage的过程中，会发生不符合预期的崩溃，但是在进一步调研了SandHook可以解决该问题之后，马上就适配了SandHook的实现来解决问题，业务方的代码不需要做任何修改和适配，再例如xHook的作者新写了一款PLT Hook框架bHook，解决了xHook的一些问题（例如增量Hook，unHook能力等等），我们也很快跟进对bHook框架进行了调研和适配，同样业务方也是无感知的，这两个例子从侧面佐证了Thor容器框架具有良好的兼容性和可扩展性。
同时同学们可能会有如下疑惑，如果Hook框架出问题，难道只能去找更好的开源方案进行适配吗？有没有银弹呢？这其实就回到了方案选型时所说的，由于安卓的碎片化和复杂性，从头开始开发一款同时支持Java和Native Hook的框架，没有稳定性问题并且兼容所有安卓版本、轻量且容灾的框架，重复造轮子并且ROI太低，所以我们要开发自己的一套容器框架，取长处补短板，充分利用好已有的框架来实现目标，当然也不排除在所有开源方案都不满足的情况下，进行深度二次开发或者自研底层Hook框架，不过这些对业务代码都不可见，不需要修改适配。
丨 4.2.3 轻量动态性
百度App作为一个航母级应用，对于包体积大小还是比较敏感的，根据Google Store的数据，包体积每增加6M，就降低1%的转化率，影响巨大，所以Thor容器框架要尽可能的做到轻量，基于此，我们需要把业务代码做成动态加载的插件，甚至是底层适配的Hook实现也要做成动态可加载的插件。
业务代码可以不在宿主中编写，只在插件代码中编写，然后将生成的插件动态下发到手机上，再通过插件加载模块动态加载生效。例如：在需要监控应用IO的情况下，下发IO插件和xHook插件到手机上安装，Hook IO操作（例如：open、read、write等），将不合理的IO操作上报给平台，同时在不需要监控的时候动态卸载关闭即可。
插件动态加载生效的大致流程如下：
- Thor容器框架会对插件进行v2签名校验，保证插件来源的安全性；
- 解析插件中的清单文件存储为info对象，包含插件包名、插件入口类、ABI List、插件版本等等；
- 对插件中的SO进行释放，不然classloader会找不到插件中的SO;
- 创建自定义的ThorClassLoader进行插件类加载，会先加载插件中的类再加载宿主中的类，部分代码如下：
/**
* 先加载Thor插件中的类，再加载宿主中的类
*
* @param name
*/
@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
Class<?> clazz = null;
try {
// 加载插件中的类
clazz = findOwnClass(name);
} catch (ClassNotFoundException ignored) {
// ignored
}
if (clazz != null) {
return clazz;
}
// 加载宿主中的类
return mHostClassLoader.loadClass(name);
}- 实例化插件入口类并判断其接口类型，注入相应的能力到Thor抽象层：
- 如果是Java Hook接口实现类，则注入Java Hook实例能力给Thor抽象层；
- 如果是Native Hook接口实现类，则注入Native Hook实例能力给Thor抽象层；
- 如果是Thor Module业务接口实现类，则将业务实例存储到map中，等待后续插件管理模块调度相应的生命周期。
大概流程图如下：
这里大家可能会有以下疑问：
- 如果上层的业务层插件先安装，底层实现层插件后安装的情况怎么办？
Thor有一个pending模式会等到实现层安装生效之后，业务层的逻辑再开始执行生效;
- Android 8.0的classloader有namespace机制，不同的classloader加载相同SO，会有多份SO在内存中，这个时候如何将插件中Native Hook能力传递给Thor抽象层呢？
通过翻看源码，Binder调用中的Parcel类拥有Native对象的内存指针，所以我们也借鉴相同的方法，将Native对象内存指针地址通过Java层进行传递，然后使用拥有相同内存布局的struct结构体进行转换，这样就可以拿到Native Hook实现了。
丨 4.2.4 容灾性
Hook技术毕竟是一个比较hack的技术，谁也无法保证百分百的兼容和稳定性，所以我们要针对这种特殊的崩溃情况进行兜底，将该框架可能造成的影响降到最低。目前有三个容灾能力：
- Thor容器框架在及时性要求不高的情况下，支持沙盒进程安装。如果安装过程中发生了崩溃，不会影响主进程，用户无感知，并且会自动回滚插件进行止损；
- Thor容器框架会结合安全模式，可以监控连续启动崩溃次数，如果超过阈值，就自动关闭Thor框架，快速自恢复及时止损；
- 通过百度内部的性能平台监控Thor相关崩溃，可以通过云控动态关闭Thor框架。
通过这三个容灾能力，基本能够保证百度App不会因为Thor容器框架发生大规模的崩溃影响用户体验，能够较好的管理风险。GEEK TALK
05 业务实践案例
Thor框架作为一套动态插件容器基础设施，真正让其起作用的是丰富的插件生态（如IO、内存、线程、隐私等等），可以根据实际需要，大胆的发挥想象，开发适合业务场景的插件。目前该框架可以应用于线下RD开发、线下流水线和线上云控开启，由于篇幅限制，摘选其中一些案例讲述。
丨 5.1 线程插件
由于在开发过程中随手就可以创建一个线程运行，也没有强制约束使用线程池，这样会导致很多游离线程，线程过多不仅会提高内存使用导致IO放大和OOM崩溃，并且有频繁的上下文切换会导致启动和流畅度问题。线程插件则通过Thor框架的PLT Hook能力Hook libart.so库中的pthead_create的函数，来监控线程的创建。核心代码如下：**
// 原始被方法函数指针
static void *(*origin_pthread_create)(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg) = NULL;
// Hook之后的Proxy方法
void *proxy_pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg) {
......
// 调用原始方法
void *ret = origin_pthread_create(thread, attr, start_routine, arg);
// 打印Java堆栈
printJavaStackTrace();
return ret;
}
void doHook(long nativePtr){
thor_abstract *impl = reinterpret_cast<thor_abstract *>(nativePtr);
// plt hook pthread_create
impl->thor_plt_hook("libart.so", "pthread_create", (void *) proxy_pthread_create, (void **) &origin_pthread_create);}
}Hook完成之后，会在创建线程的过程中先调用 proxy_pthread_create 的代理方法再调用原始的创建线程方法，在代理方法中通过反射打印创建当前线程的Java堆栈。在百度App启动阶段通过线程插件监控记录发现有100+个SP线程，和50+非线程池管理的线程，严重影响启动速度和用户体验。协助组内同学进行优化后（SP迁移KV组件，所有线程通过线程池管理），降低启动过程中线程数100+，优化TTI（Time To Interactive） 1s+。
丨 5.2 IO插件
由于在开发过程中有同学会把一些IO操作在主线程中执行，例如文件读写、网络传输，这样会导致主线程卡顿，影响启动速度、流畅度等，即使是小文件也可能因为内存不足和磁盘不足等原因导致IO读写放大，从而导致长耗时的IO，同时还有一些不合理的IO，例如：读写buffer过小会导致频繁的系统调用影响性能，以及重复读同一个文件等。IO插件则通过Thor框架的 PLT Hook能力 Hook IO操作（open、read和write、close等），用来记录监控主线程不合理的IO。核心代码如下：
......
thor->thor_plt_hook(so_name, "open", (void *) ProxyOpen, (void **) &original_open);
thor->thor_plt_hook(so_name, "read", (void *) ProxyRead, (void **) &original_read);
thor->thor_plt_hook(so_name, "write", (void *) ProxyWrite, (void **) &original_write);
thor->thor_plt_hook(so_name, "close", (void *) ProxyClose, (void **) &original_close);
......调用open时会先调用ProxyOpen，ProxyOpen中会存储fd（文件描述符）和IOInfo的map映射关系，后续的ProxyRead、ProxyWrite和ProxyClose则通过fd来完善IOInfo的信息，IOInfo部分字段如下：
class IOInfo {
public:
// 文件路径
const std::string file_path_;
// 开始时间
int64_t start_time_μs_;
// buffer大小
long buffer_size_ = 0;
// 连续读写次数
long max_continual_rw_cnt_ = 0;
// 文件大小
long file_size_ = 0;
// 总耗时
long total_cost_μs_ = 0;
};在最后文件Close的时候通过分析IOInfo即可分析出不合理的IO操作（例如主线程IO耗时过长、IO的buffer过小（导致系统调用增多）、重复读等）。在百度App启动过程中通过IO插件监控记录发现有20+不合理的IO操作，与各个业务方的同学进行协同和优化，最终启动速度TTI优化400ms+，提升了用户体验。
丨 5.3 隐私合规插件
由于个人信息法的颁布，应用不可以在隐私弹窗确认前获取用户个人信息，基于此，隐私合规插件使用Thor框架的Java Hook的能力，监控记录隐私弹窗前不合理的隐私API调用（例如定位、WI-FI、蓝牙等等），部分代码如下：
// hook getDeviceId
ThorHook.findAndHookMethod(TelephonyManager.class, "getDeviceId", new IHookCallbackImpl(), String.class);隐私合规插件结合了手百内部通用防劣化流水线的能力（这里不展开讲解），每天自动编译打包内置隐私合规插件，然后自动在真机上测试，监控记录隐私弹框前的隐私问题，最后自动分析、分发问题卡片给相应的业务同学进行修改，有效的规避了合规风险，防止被下架整改；
丨 5.4 内存插件
内存优化是性能和稳定性优化中的一大课题，如果内存占用过大，轻则导致频繁GC造成卡顿，重则内存溢出导致OOM应用崩溃。内存插件则通过Thor框架PLT Hook的能力，监控记录Java堆内存和Native内存（监控 malloc 和 free等函数）。内存插件目前有两个使用场景：
- 结合线下流水线的能力，每天自动编译打包内置内存插件，然后在真机上使用monkey随机测试，在内存水位高时dump hprof文件，并进行裁剪（通过PLT Hook write方法实现，参考Tailor在hprof文件写入过程中过滤不需要的信息），最后自动分析出内存泄漏问题和大对象问题，自动分发问题给相应的业务同学进行修改，将内存问题前置，防止问题上线影响用户体验。
- 结合线上Thor丰富的云控能力，动态下发到OOM用户手机上开启内存监控能力，然后回捞上报相关的数据进行问题分析、分发，解决线下不易复现的线上OOM崩溃问题。
06 总结
Hook这个话题由来以久，框架种类繁多，但是没有一款全面性、动态性以及兼容性好的框架，但是正是有这些优秀的框架（Xposed、Dexposed、Epic、xHook等），我们才能学习和借鉴其优秀的设计和理念，补齐不足，Thor只是在这条道路上迈出了一小步，后面需要更加完善和夯实Thor基础设施，并且丰富插件生态，在Android性能和稳定性治理上添砖加瓦。
相关链接：
[1] Dexposed链接：https://github.com/alibaba/dexposed
[2] ArtHook论文链接：http://publications.cispa.saarland/143/
[3] Epic链接：https://github.com/tiann/epic
[4] xHook链接：https://github.com/iqiyi/xHook
[5] Android-Inline-Hook链接：https://github.com/ele7enxxh/Android-Inline-Hook
[6] Tailor链接：https://github.com/bytedance/tailor
[7] Matrix链接：https://github.com/Tencent/matrix/