百度App效能優化工具篇 - Thor原理及實踐

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介面實現中。

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抽象層：

1. 如果是Java Hook介面實現類，則注入Java Hook例項能力給Thor抽象層；

2. 如果是Native Hook介面實現類，則注入Native Hook例項能力給Thor抽象層；

3. 如果是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容器框架發生大規模的崩潰影響使用者體驗，能夠較好的管理風險。

五.  業務實踐案例

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崩潰問題。

六.  總結

Hook這個話題由來以久，框架種類繁多，但是沒有一款全面性、動態性以及相容性好的框架，但是正是有這些優秀的框架 （Xposed、Dexposed、Epic、xHook等） ，我們才能學習和借鑑其優秀的設計和理念，補齊不足，Thor只是在這條道路上邁出了一小步，後面需要更加 完善和夯實Thor基礎設施，並且豐富外掛生態 ，在Android效能和穩定性治理上添磚加瓦。