摘要

本文介紹了 Android 插件化框架中，插件使用宿主資源時資源錯亂的問題，以及錯亂的原因、業(yè)界通用解決方案、我們提出的優(yōu)化方案。

本文將按照如下順序，循序漸進地進行講解：

簡單介紹 Android 插件化中資源部分的動態(tài)化。簡單介紹 Android 中的資源的一些基礎(chǔ)知識、使用方式及其編譯原理。介紹插件化場景下出現(xiàn)的資源錯亂問題及業(yè)界通用的解決方案。介紹一種新的方案——免資源固定方案，用于解決資源錯亂問題。單獨介紹一下免資源固定方案中的一個技術(shù)點：修改 apk 中的資源文件。1. Android 插件化中資源的動態(tài)化

Android 發(fā)展了這么多年，市面上涌現(xiàn)出許多插件化/熱修復(fù)框架，無論是插件化還是熱修復(fù)，都是為了實現(xiàn)對主apk以外內(nèi)容的動態(tài)化，這些內(nèi)容包括 dex（class）、res（資源）、so（動態(tài)庫）等。對于每一種內(nèi)容，業(yè)界都有許多實現(xiàn)方案，盡管方案各不相同，但底層原理都差不多，網(wǎng)上也有許多文章和開源項目可以學(xué)習(xí)參考。

(相關(guān)資料圖)

名詞解釋

宿主：直接安裝到用戶手機上的 App，宿主中的代碼在宿主安裝到用戶手機上的那一刻就定死了，不能再改變了（熱修復(fù)也只是讓錯誤的邏輯不走而已，并沒有改變原有的代碼）。

插件：獨立于宿主之外的一個文件。需要被宿主動態(tài)加載的 class、res、so 等的集合。（熱修復(fù)中這部分通常稱為 patch，這里為了方便，就叫插件吧）

java代碼：為了描述方便，apk 中的 dex 在編譯前一律稱為 java 代碼，編譯后一律稱為 dex（這個說法不準確，不要被我誤導(dǎo)了，一般為java / kotlin- > class- > dex ）

說到 Android 資源的動態(tài)化，思路都大同小異：

為每個插件創(chuàng)建一個 Resources 或者把插件的資源路徑添加到宿主 AssetManager，從而可以順利的加載到插件資源。插件編譯時通過配置 aapt2 參數(shù)對插件中資源 id 的 packageId 部分進行修改，保證插件與宿主資源 id 不沖突。對于插件中使用到的宿主資源，利用 aapt2 參數(shù)進行資源固定，保證宿主升級后插件使用到的宿主資源 id 不變。

aapt2 的出現(xiàn)使資源固定、packageId 修改變得容易了很多！

盡管 Android 資源的動態(tài)化技術(shù)已經(jīng)十分成熟，但是在實踐過程中還是有許多不足，比如“資源固定”就經(jīng)常被業(yè)務(wù)同學(xué)吐槽。

2. Android 中的資源介紹

在介紹資源固定之前，首先簡單介紹一下 Android 中資源相關(guān)的基礎(chǔ)知識。

2.1 Android 中的資源 id

Android 代碼在編譯成 apk 之后，每個資源都對應(yīng)一個唯一的資源 id，資源 id 是一個 8 位的 16 進制 int 值 0xPPTTEEEE ：

PP ：前兩位是 PackageId 字段，系統(tǒng)資源是 01，宿主資源 id 是 7f，其他如廠商自定義的皮膚包、webview 插件資源包會占用 02、03......，因此 App 資源和系統(tǒng)資源永遠不會沖突。市面上的插件框架為了保證插件和宿主資源不沖突，通常會把插件資源的 PP 改為其他值，如 7e、7d。TT ：中間兩位是 TypeId 字段，表示資源的類型，如 anim、drawable、string 等，這塊沒有嚴格的對應(yīng)關(guān)系，通常是按照字母順序分配 type 值。EEEE ：最后四位是 EntryId 字段，用于區(qū)分同一個 PackageId、同一個 TypeId 下不同 name 的資源，通常也是按照字母順序進行分配的。

注意：

資源 id 的分配默認是按資源的字母排序進行的，也就是說，當(dāng)新增一個 name 為 a 的資源，重新編譯之后，a 后面的同類型的資源 id 值都會被改變。aapt2 中提供了參數(shù)可以對資源 id 分配方式進行干預(yù)，aapt2 會優(yōu)先按照參數(shù)中配置的對應(yīng)關(guān)系分配 id，這個技術(shù)我們稱之為資源固定，也是目前插件化框架在解決資源錯亂問題中用的最多的技術(shù)。2.2 Android 中的資源使用方式

Android 中使用資源通常有兩種方式：

在 java 代碼中通過 R 的內(nèi)部類進行訪問，具體語法為：

[].R..

在 xml 中通過符號使用，具體語法為：

@[:]/

xml 中也可以通過 ? 代替 @ 的形式引用樣式屬性。也可以引入自定義屬性，如 android:layout_width 。這兩種用法不影響下文的介紹。

那么這兩種方式有什么區(qū)別呢？

從代碼書寫的角度來說，都是通過一個資源名稱（resource_name）來訪問資源。我們反編譯一下 apk，看看編譯后是什么樣的。

分別在項目 app module、library module、xml 中編寫如下代碼

我們反編譯一下 apk，看看這三種代碼在 apk 中是如何表現(xiàn)的。

可以發(fā)現(xiàn) appTest 方法和 xml 中的資源變成了數(shù)字(0x7f0e0069)，libTest 方法中的資源依舊是通過 Lcom/bytedance/lib/R$string;->test 訪問的

結(jié)論：

主 module 中引用的資源被編譯成了數(shù)值；子 module、aar 中通過 R 的內(nèi)部類間接引用數(shù)值；xml 中的資源 id 全部編譯成了數(shù)值。（看上圖中 xml 的屬性—— lay out_width 等依舊是字符串，其實它背后也是資源 id 數(shù)值，這塊的字符串其實是沒有用的，甚至在一些包體積優(yōu)化中可以直接去掉）。

那么為什么 libTest 方法中是通過 field 引用，而 appTest 中就變成數(shù)字了呢？

2.3 Android 中資源編譯的簡單流程

假設(shè)有一個工程，只有一個 app module，通過 maven 倉庫依賴若干三方 aar，項目編譯時的簡化流程如下圖：

下載三方 aar；將 app module 和三方 aar 中的資源經(jīng)過 aapt2 進行編譯、鏈接，最終生成R.jar和ap_R.jar 包含了最終打入 apk 的所有 R.class，每個依賴對應(yīng)一個。aapt2 也會默認按照字母排序為每個資源分配唯一的 id 值。注意：新增刪除一個資源都會導(dǎo)致它后面的資源 id 改變。aapt2 允許通過配置干預(yù) id 的分配。ap_ 文件中包含了所有編譯好的資源文件。App module 的 java 文件與 R.jar 一起被 javac 編譯。由于 R.jar 中的 field 都是 final，因此 app module 中通過 R 引用的資源全部被內(nèi)聯(lián)成了數(shù)值。而三方 aar 中由于已經(jīng)是 class，無需進行編譯，因此依舊是通過 R 引用來使用資源；最后把 app module 編譯出來的 .class、三方 aar 中的 .class 轉(zhuǎn)成 dex，與 ap_ 一起壓縮到 apk 中。

因此就很容易理解為啥 libTest 中依舊是通過 R 來使用資源，而 appTest 中通過數(shù)值直接引用（被內(nèi)聯(lián)）。

libTest module 雖然被 app module 通過源碼依賴，但是在資源編譯這塊其實是類似的，這里不展開介紹。

2.4 總結(jié)

Android 中的資源的無論是通過 java 代碼使用還是 xml 使用，最終都是通過資源 id 值進行查找的。

把 apk 拖到 as 中，查看 resources.arsc 文件，可以看到它里面包含了 apk 中所有資源的 id 索引，以及該資源名對應(yīng)的真正資源或值。很容易想到，App 運行起來也是通過資源 id 值經(jīng)過這個資源表來查找真正的資源內(nèi)容。

3. 插件使用宿主資源3.1 插件如何使用宿主資源

想象一下，我們想要把 App 的直播功能做成一個插件動態(tài)下發(fā)，直播功能所需要的大部分資源都在直播插件中，但是總有一些資源來自宿主，如一些通用的 UI 組件中包含的資源（support/androidx 庫）等。

那么，假設(shè)宿主中有一張圖片名為 icon，直播插件中的 xml 通過 @drawable/icon 引用了這張圖片，同時也在代碼中通過 R.drawable.icon 引用了它，實際直播插件中是沒有 icon 這張圖片的，它存在于宿主中。宿主編譯完后，按照前面的知識點，宿主中的 icon 對應(yīng)的數(shù)值被編譯成 0x7f010001。

插件本身也是一個 apk，根據(jù)前面介紹的知識點，插件編譯完成后，xml 中的 @drawable/icon 會編成一個數(shù)值（0x7f010001），java 代碼中的 R.drawable.icon 也會直接或間接編成一個數(shù)值（0x7f010001）。當(dāng)這個插件運行在宿主上，按照前面的介紹，插件會去查找 0x7f010001，發(fā)現(xiàn)可以找到，這樣就正確的使用了宿主資源。

插件編譯時我們會做一些處理，使插件中可以引用到宿主 id。

3.2 插件使用宿主資源有什么問題

前文介紹過，新增或刪除一個資源都可能導(dǎo)致其他許多資源的 id 被改變。

我們的宿主編譯出來后 icon 為 0x7f010001，基于已有的宿主編譯出一個插件后，插件中引用的 icon 也是 0x7f010001，此時沒什么問題。

宿主迭代后，新增了一個新的資源 aicon，按照前面介紹的資源 id 分配規(guī)則，新版本的宿主中 aicon 的 id 值為 0x7f010001，icon 的 id 值被分配為 0x7f010002。老版本的插件下發(fā)到新版本的宿主上時依舊會通過 0x7f010001去宿主中找 icon，自然就找錯了。運氣好一點可能只是圖片展示異常，運氣不好點可能就直接 crash 了。

3.3 如何解決這類問題

為了解決這個問題，業(yè)界目前有一個通用、穩(wěn)定的方案——資源固定。宿主編譯時通過 aapt2 提供的參數(shù)對插件使用到的資源進行固定，使宿主每次打包時這些資源的值永遠不發(fā)生改變。

資源固定方案的弊端：

一個插件對應(yīng)一個宿主的情況：必須把宿主的所有資源都進行固定。如果只固定插件使用的資源，當(dāng)一個宿主有兩個插件時，兩個插件各自給宿主固定自己需要的資源，在代碼合并時，很容易引發(fā)沖突，因為資源固定的值是不允許重復(fù)的；當(dāng)宿主接入多個涉及到資源固定的框架，如：插件化、資源熱修復(fù)、游戲重打包框架等，這些框架之間進行資源固定時也需要考慮統(tǒng)一固定，這個成本是很高的；資源固定提高了宿主接入框架的成本。一個插件運行在多個宿主的情況：

當(dāng)一個插件想要運行在多個宿主上，就需要每個宿主針對該插件的資源使用情況進行資源固定。一旦某個宿主已經(jīng)對某個資源進行了固定，導(dǎo)致其與該插件要求的資源固定產(chǎn)生沖突，插件就需要對該宿主進行妥協(xié)，根據(jù)該宿主已有的資源固定重新生成固定規(guī)則。這樣就無法實現(xiàn)一個插件在多個宿主上運行。我們目前有一個需求：同一個插件需要在上千個宿主上運行，如果不能解決這個問題，可能需要打成百上千個插件出來，很明顯是不合理的；

資源固定提高了宿主接入框架的成本。

為了解決上述的問題，我們研究了一套新的方案解決資源錯亂問題。

4. 免資源固定方案

同一個版本的插件運行在不同版本甚至不同的 App 上時，插件的代碼是固定的，而宿主中的資源 id 是會改變的，為了解決資源錯亂問題，當(dāng)前的思路是保證宿主每次出新版本時資源 id 不變。那么有沒有辦法在不約束宿主的情況下，讓插件始終跟宿主的資源 id 保持一致呢？

由于插件打包時，宿主是未知的，并且對于一個插件跑在多個宿主的情況，宿主也是多樣的。所以沒法指定讓插件把 id 打成滿足宿主的樣子，而前文也介紹過，插件中引用宿主id的地方都是常量。那怎么辦呢？

是否可以在插件運行到宿主上時，動態(tài)修改插件中的內(nèi)容，實現(xiàn)插件與宿主 id 值匹配的效果。

比如插件中使用了宿主的資源 icon，對應(yīng)的 id 值為 0x7f010001。當(dāng)該插件運行在一個 icon 為 0x7f010002的宿主上時，由于運行時資源查找都是通過 id 值進行的，此時我們只能知道插件是在找一個 id 為 0x7f010001 的資源。通過某些手段，如果我們可以把 0x7f010001 映射成 icon 這個字符串，然后利用 Android 系統(tǒng)提供的Resources#getIdentifier方法，動態(tài)獲取到當(dāng)前宿主中 icon 對應(yīng)的資源 id，即可保證插件加載到正確的資源。

這個工作需要在插件編譯時、運行時分別做一些工作配合完成實現(xiàn)。

4.1 插件編譯時工作

本小節(jié)內(nèi)容基于 agp4.1 介紹，各個版本有些許差異，但總體思路大同小異。

前面介紹了，插件使用宿主資源主要有兩種情況：1.通過 java 代碼 2.通過 xml。

4.1.1 處理 java 代碼中引用宿主的資源

java 代碼在編譯成 class 之后，對于引用宿主資源 id 的代碼，有的會編譯成數(shù)值，有的依舊是通過 R 引用。對于后者，我們可以很容易找出來，對于前者就有些困難了，因為單純?nèi)呙?class 中 0x7f 開頭的數(shù)字，很容易誤判，把一個無意義的數(shù)字也當(dāng)作資源 id 處理。

前面講了為什么 class 中的資源 id 會內(nèi)聯(lián)成數(shù)值，那我們不讓它內(nèi)聯(lián)不就好了嗎？只需要在編譯過程中處理 R.jar，移除 class 中所有的 final 字段，就可以保證插件中引用宿主的資源 id 全部通過 R 進行引用。

這塊需要對 agp 的工作流程、gradle plugin 的開發(fā)有一定的了解，用到了 asm 字節(jié)碼修改技術(shù)和 agp 提供的 transform api，不了解的同學(xué)可以單獨查一下，這塊就不詳細介紹了。

簡單來說就是通過這兩項技術(shù)，可以在編譯 apk 時，對 class 文件進行修改。

開始實踐

由于 R.jar 是在 processResourcesTask 中生成的，因此可以寫一個 gradle plugin，在 processResourcesTask 的 doLast 中獲取到 R.jar，修改 R.jar 中的字節(jié)碼，將 field 中的 id 為 0x7f 開頭的字段的 final 修飾符全部移除。這樣就可以保證插件 class 中所有引用宿主資源的地方都不會被內(nèi)聯(lián)成數(shù)值；經(jīng)過第一步的處理，插件中引用的宿主資源全部通過 R.xx.xx 來引用，但插件 R 中的數(shù)值依舊是無法與宿主對應(yīng)的。因此我們繼續(xù)寫一個 transform，掃描出插件中通過 R 引用資源的地方，利用 asm 將其從原來的 R 引用修改為方法調(diào)用。插件運行時，原本類似 R.drawable.test 的代碼不再是獲取一個常量數(shù)值，而是調(diào)用一個方法，內(nèi)部動態(tài)計算當(dāng)前宿主中對應(yīng)的值。?

總結(jié)：

以上，通過編譯時的一些處理，即可解決插件 java 代碼中引用宿主資源時免資源固定的問題。

優(yōu)點：無需資源固定。缺點：插件中的部分資源不進行內(nèi)聯(lián)，會使包體積有非常微小的增加，但是問題不大；插件引用宿主資源由原來的常量變成了方法調(diào)用，執(zhí)行效率降低，不過這塊可以通過緩存來解決。同時插件化本身就是一項黑科技技術(shù)，有時候犧牲一些性能，解決一個問題還是非常值得的。4.1.2 處理 xml 代碼中引用宿主的資源

xml 中引用宿主資源的問題僅靠編譯時是無法解決的，因為 xml 不像 java 代碼一樣可以執(zhí)行邏輯，前面介紹了，xml 在編譯結(jié)束后，資源全部編成了數(shù)值，而我們在編譯時又無法知道未來運行在哪個宿主，值為多少。所以修改 xml 中資源id的工作只能搬到運行時去搞。當(dāng)然也需要在編譯時做一些事情，輔助運行時的修改操作。

運行時我們需要修改 apk 的xml 中 0x7f 開頭的資源，將其數(shù)值改為對應(yīng)當(dāng)前宿主的正確數(shù)值，而通過 xml，我們只能拿到一個數(shù)值，因此我們可以在插件編譯時收集插件 xml 中使用的宿主資源所在的 xml 文件以及它們所對應(yīng)的資源 name，運行時借助前文提到的mapRes方法即可獲取到需要被修改后的值。

開始實踐

前文介紹過，aapt2 編譯/鏈接后會生成一個 ap_ 文件，這個文件中包含了最終會進入插件中的所有編譯后的資源（包括各種 xml、resources.arsc、AndroidManifest.xml ），我們只需要分析這些文件中引用的 0x7f 開頭的資源，根據(jù) R.txt（aapt2生成的一個文件）找到對應(yīng)的資源名，將資源名、id 值、所在文件記錄到一個文件中，一并打包進插件 apk 中。

至于如何掃描這些文件中 0x7f 的資源，我們在不同階段使用了不同方式，大家可以自行選擇：

使用 aapt2 命令 dump 文件信息，分析 dump 后的文本內(nèi)容（我們編譯時是這么做的，簡單粗暴、性能較差、不夠優(yōu)雅）；根據(jù)文件格式分析對文件內(nèi)容進行解析，找到 0x7f 開頭的資源（比較優(yōu)雅，效率也高，我們運行時是這樣做的）。

總結(jié)：

以上，便生成了一個文件，內(nèi)部存儲了插件 xml 中使用到的宿主資源的信息。大概長下面這樣：

前文一直在說 xml 中使用的宿主資源，看上面這個配置文件發(fā)現(xiàn) fileNames 中怎么會有 resoureces.arsc ？它明明不是 xml 文件？

其實 Android 資源編譯之后，values 相關(guān)的一些資源文件都不存在了，會直接進入到 resources.arsc 中，layout 這類文件還存在，resoureces.arsc 中 layout 指向的正是各種 layout.xml，而 string 等 value 類型的資源指向的是一個真實的內(nèi)容。感興趣的同學(xué)可以通過 Android Studio 打開 apk，觀察一下 resources.arsc 中的結(jié)構(gòu)。

4.2 插件安裝時的工作

前面介紹了在插件編譯時，給 java 代碼中插入了一些邏輯，實現(xiàn)了插件動態(tài)根據(jù)宿主環(huán)境獲取資源 id 的效果。但是 xml 編譯完之后，資源 id 都直接編譯成了數(shù)字，xml 中也無法插入邏輯，因此我們只能在插件運行前，根據(jù)宿主環(huán)境進行修改。

插件在宿主中運行前都有一個插件安裝的過程，類似于 apk 在 Android 系統(tǒng)中的安裝，因此只需要在每次插件安裝前，或者宿主升級后，根據(jù)編譯時生成的配置文件，結(jié)合 mapRes 方法，對插件中的 xml、resources.arsc 文件進行修改即可。

確定了修改時機和修改內(nèi)容，接下來就要詳細介紹怎么修改這些文件了。

5. 修改 apk 中的資源文件5.1 如何修改 xml、arsc 文件

Android 中的 layout、drawable、AndroidManifest 等文件在編譯成 apk 后，不再是常規(guī)的 xml 文件了，而是新的一種文件格式 Android Binary XML，我們這里稱之為 axml。那么如何修改 axml 文件呢？

所有的文件都有自己的文件格式，程序在讀取文件時都是讀的 byte 數(shù)組，然后根據(jù)文件格式解析 byte 數(shù)組中每一個元素的含義。因此我們只需要了解了 axml 的文件格式，按照規(guī)范解析這個文件，在 byte 數(shù)組中找到其中表示資源 id 的位置，將原本的資源 id 根據(jù) resMap 方法映射出新的值，然后修改 byte 數(shù)組中對應(yīng)的部分。（非常幸運，我們這里修改的只是 axml 文件中的一個 8 位 16 進制數(shù)，這個修改不會導(dǎo)致文件中內(nèi)容的長度、偏移等信息改變，因此直接替換對應(yīng)部分的 byte 數(shù)組即可。）

resources.arsc 是 apk 的資源索引表，里面記錄了 apk 中所有的資源，對于 values 類型的資源，資源對應(yīng)的內(nèi)容會全部進入到 resources.arsc 中，因此我們也需要對這個文件進行修改（如一個 style 的 parent 是宿主資源，我們就需要修改它）。修改的方法和 xml 類似，只需要按照規(guī)范解析 byte 數(shù)組，找到要修改內(nèi)容的偏移量，替換即可。

關(guān)于 axml、arsc 的文件格式，網(wǎng)上有很多文章介紹，這里就不詳細敘述了。

Apktool 是一款強大、開源的逆向工具，它可以把 apk 反編譯成源碼，那它肯定也有讀取 apk 中 axml、arsc 的代碼，不然怎么輸出一個可以編輯的 xml 源碼文件？所以我們可以直接去扒 apktool 中讀取 axml、arsc 的代碼，當(dāng)讀取到 axml 中屬于宿主的 id 時，記錄一下 byte 數(shù)組的偏移量，直接替換對應(yīng)位置的 byte 子數(shù)組。

aapt2 為我們提供了 dump 資源內(nèi)容的能力，可以幫助我們直接用“肉眼”去看 axml、arsc 的內(nèi)容，借助這個工具可以讓我們很方便的確認修改內(nèi)容，驗證修改是否生效。以 30.0 版本的 build-tools 中的 aapt2 為例，它的命令為aapt2 dump apk路徑 --file 資源路徑?。后面不跟--file 資源路徑，會直接 dump arsc。

以下是 dump 出來的 arsc，可以看到最后一個 style 的 parent 是一個 0x7f 開頭的宿主資源。

以下是 dump 出來的 activity_plugin1.xml，可以看到 TextView 中引用了一個宿主中的資源作為 backgroud。

5.2 修改 apk 中的 xml/arsc 文件

以上我們知道了如何修改一個 axml、arsc 文件。插件安裝時我們拿到的是 apk 文件，那么如何修改 apk 中的 axml、arsc 文件呢？

5.2.1 重壓縮方式修改

Apk 其實就是一個 zip 文件，修改 apk 中的文件內(nèi)容，首先想到的最簡單的方法就是讀取 zipFile 里面的文件，修改之后重壓縮。

java 為我們提供了一套操作 zipFile 的 api，我們可以輕松的將 zip 文件中的內(nèi)容讀取到內(nèi)存，在內(nèi)存中修改之后利用 ZipOutputStream 重新寫入到新的 zipFile 中。

代碼實現(xiàn)非常簡單。修改成功后，測試發(fā)現(xiàn)是可行的，那我們的第一步就算是成功了，說明運行時動態(tài)修改插件的路子是行的通的。

竊喜之于，發(fā)現(xiàn)修改過程十分耗時。以公司的直播插件為例（直播插件大約 30 MB，屬于比較大的插件了），在 9.0 及其以上的設(shè)備上耗時約 8s，在 7~8 的設(shè)備耗時大約 20～40s，在 7.x 以下設(shè)備大約耗時 10～20s。盡管插件安裝是在后臺進行，適當(dāng)?shù)脑黾右恍r間是可以接受的，但是幾十秒的耗時很明顯不可以接受。那我們只能想別的辦法了。

關(guān)于各個版本的耗時差異：

Android7.0 開始，官方使用 ZLIB 來提供 Deflater、Inflater 的實現(xiàn)，優(yōu)化了解壓壓縮算法速度（可以查看 Deflater.java、Inflater.java 的注釋）。但是 7.x/8.x 的 ZipFileInputStream 在讀取數(shù)據(jù)時有一個 8192 的 BUFSIZE 限制（ 8.x 之后移除了這個限制），導(dǎo)致在讀取數(shù)據(jù)時循環(huán)次數(shù)增多，效率反而下降。

7.0 開始，ZipFileInpugStream 在讀取數(shù)據(jù)時是通過 native 方法 ZipFile_read 進行的。以下是 android8.0 和 android9.0 中 ZipFile_read 的部分代碼。

5.2.2 直接修改 apk 的 byte 數(shù)組

Apk 其實就是一個 zip 文件，關(guān)于 zip 文件的介紹可以參考 Zip 的官方文檔。

簡單總結(jié)一下，zip 文件是由數(shù)據(jù)區(qū)、中央目錄記錄區(qū)、中央目錄尾部區(qū)組成（高版本的 zip 文件增加了新的內(nèi)容）。

中央目錄尾部區(qū)：通過尾部區(qū)我們可以知道 zip 包中文件的數(shù)目、中央目錄記錄區(qū)的位置等信息；中央目錄記錄區(qū)：通過尾部區(qū)我們可以快速找到中央目錄記錄區(qū)中的每一條文件記錄，這些記錄主要描述了 zip 包中文件的基本屬性如文件名、文件大小、是否壓縮、壓縮后的大小、文件在數(shù)據(jù)區(qū)中的偏移等；數(shù)據(jù)區(qū)：數(shù)據(jù)區(qū)用來存放文件真實的內(nèi)容，根據(jù)中央目錄記錄區(qū)記錄的內(nèi)容，可以快速在數(shù)據(jù)區(qū)找到對應(yīng)的文件元數(shù)據(jù)以及文件的真實數(shù)據(jù)（如果壓縮，則是壓縮后的數(shù)據(jù)）。

開始干活

了解了 zip 文件的格式后，我們只需要按照文件格式協(xié)議，在 apk 中找到我們需要修改的文件數(shù)據(jù)在 apk 中的偏移量，然后結(jié)合前面修改 axml/arsc 文件的方式，直接修改對應(yīng)的 byte 數(shù)組即可。借助 java 為我們提供的 RandomAccessFile 工具，我們可以快速的文件的任意位置進行讀取/寫入。

修改過程中發(fā)現(xiàn)，apk 中的 xml 文件大部分是被壓縮的（ res/xml 目錄下的一般不壓縮），這就導(dǎo)致我們從 apk 中拿出來的 byte 數(shù)組是 axml 被壓縮后的數(shù)據(jù)，我們要對這段數(shù)據(jù)進行修改，需要先利用 Deflate 算法對它進行解壓（ zip 文件中一般都是用的 Deflate 算法），然后進行修改再壓縮，但是經(jīng)過我們修改后，可能重新壓縮出來的數(shù)據(jù)就與修改前的數(shù)據(jù)長度不匹配了，如果是縮短還好，修改一下文件元數(shù)據(jù)即可，如果文件長度變長可能會導(dǎo)致后面文件的偏移量都要改變，牽一發(fā)而動全身。

好在插件的打包過程我們是可以侵入的，前面介紹“插件編譯時工作”時，我們在編譯時拿到了需要修改的文件，因此我們只需要控制 apk 打包時不要對這些文件進行壓縮（事實上 Android Target30 也要求 arsc 文件不進行壓縮）。這樣就很簡單的解決了問題，當(dāng)然會導(dǎo)致插件包體積的增加。

最終測試在直播插件中，開啟這個功能會導(dǎo)致包體積增加 20kb，對于接近 30mb 體積的直播插件來說，這個增量是可以接受的，而且也不會影響宿主包體積。（這個增量取決于插件有多少 xml 使用了宿主資源，一般插件的增量應(yīng)該都是小于直播插件的。）

改造完成后，經(jīng)測試，直播插件在各個版本手機上修改時長大約在 300～700ms 之間，修改速度提升了 10～90 倍。大部分插件也比直播插件小，耗時可以保證在 100ms 之內(nèi)。同時這個修改過程僅在插件第一次安裝或者宿主升級時做，并且是在后臺完成，所以是完全可以接受的。

關(guān)鍵詞： 進行修改 文件格式