Android 熱修復 Tinker Gradle Plugin 解析

鴻洋_發表於2017-05-25

原文網址 : http://www.codeceo.com/article/tinker-gradle-plugin-analysis.html

AndroidGradlePlugin

本文已在我的公眾號hongyangAndroid原創首發。

一、概述

前面寫了兩篇分析了tinker的loader部分原始碼以及dex diff/patch演算法相關解析，那麼為了保證完整性，最後一篇主要寫tinker-patch-gradle-plugin相關了。

（距離看的時候已經快兩個月了，再不寫就忘了，趕緊記錄下來）

注意：

本文基於1.7.7

前兩篇文章分別為：

有興趣的可以檢視~

在介紹細節之前，我們可以先考慮下：通過一個命令生成一個patch檔案，這個檔案可以用於下發做熱修復（可修復常規程式碼、資源等），那麼第一反應是什麼呢？

正常思維，需要設定oldApk，然後我這邊build生成newApk，兩者需要做diff，找出不同的程式碼、資源，通過特定的演算法將diff出來的資料打成patch檔案。

ok，的確是這樣的，但是上述這個過程有什麼需要注意的麼？

我們在新增資源的時候，可能會因為我們新增的一個資源，導致非常多的資源id發生變化，如果這樣直接進行diff，可能會導致資源錯亂等（id指向了錯誤的圖片）問題。所以應當保證，當資源改變或者新增、刪除資源時，早已存在的資源的id不會發生變化。
我們在上線app的時候，會做程式碼混淆，如果沒有做特殊的設定，每次混淆後的程式碼難以保證規則一致；所以，build過程中理論上需要設定混淆的mapping檔案。
當專案比較大的時候，我們可能會遇到方法數超過65535的問題，我們很多時候會通過分包解決，這樣就有主dex和其他dex的概念。整合了tinker之後，在應用的Application啟動時會非常早的就去做tinker的load操作，所以就決定了load相關的類必須在主dex中。
在接入一些庫的時候，往往還需要配置混淆，比如第三方庫中哪些東西不能被混淆等（當然強制某些類在主dex中，也可能需要配置相對應的混淆規則）。

如果大家嘗試過接入tinker並使用gradle的方式生成patch相關，會發現在需要在專案的build.gradle中，新增一些配置，這些配置中，會要求我們配置oldApk路徑，資源的R.txt路徑，混淆mapping檔案路徑、還有一些比較tinker相關的比較細緻的配置資訊等。

不過並沒有要求我們顯示去處理上述幾個問題（並沒有讓你去keep混淆規則，主dex分包規則，以及apply mapping檔案），所以上述的幾個實際上都是tinker的gradle plugin 幫我們做了。

所以，本文將會以這些問題為線索來帶大家走一圈plugin的程式碼（當然實際上tinker gradle plugin所做的事情遠不止上述）。

其次，tinker gradle plugin也是非常好的gradle的學習資料~

二、尋找檢視程式碼入口

下載tinker的程式碼，匯入後，plugin的程式碼都在tinker-patch-gradle-plugin中，不過當然不能抱著程式碼一行一行去啃了，應該有個明確的入口，有條理的去閱讀這些程式碼。

那麼這個入口是什麼呢？

其實很簡單，我們在打patch的時候，需要執行tinkerPatchDebug（注：本篇部落格基於debug模式講解）。

當執行完後，將會看到執行過程包含以下流程：

:app:processDebugManifest
:app:tinkerProcessDebugManifest（tinker）
:app:tinkerProcessDebugResourceId (tinker)
:app:processDebugResources
:app:tinkerProguardConfigTask(tinker)
:app:transformClassesAndResourcesWithProguard
:app:tinkerProcessDebugMultidexKeep (tinker)
:app:transformClassesWidthMultidexlistForDebug
:app:assembleDebug
:app:tinkerPatchDebug(tinker)複製程式碼

注：包含(tinker)的都是tinker plugin 所新增的task

可以看到部分task加入到了build的流程中，那麼這些task是如何加入到build過程中的呢？

在我們接入tinker之後，build.gradle中有如下程式碼：

if (buildWithTinker()) {
    apply plugin: 'com.tencent.tinker.patch'
    tinkerPatch {} // 各種引數
}複製程式碼

如果開啟了tinker，會apply一個plugincom.tencent.tinker.patch：

名稱實際上就是properties檔案的名字，該檔案會對應具體的外掛類。

對於gradle plugin不瞭解的，可以參考www.cnblogs.com/davenkin/p/…，後面寫會抽空單獨寫一篇詳細講gradle的文章。

下面看TinkerPatchPlugin，在apply方法中，裡面大致有類似的程式碼：

// ... 省略了一堆程式碼
TinkerPatchSchemaTask tinkerPatchBuildTask 
        = project.tasks.create("tinkerPatch${variantName}", TinkerPatchSchemaTask)
tinkerPatchBuildTask.dependsOn variant.assemble

TinkerManifestTask manifestTask 
        = project.tasks.create("tinkerProcess${variantName}Manifest", TinkerManifestTask)
manifestTask.mustRunAfter variantOutput.processManifest
variantOutput.processResources.dependsOn manifestTask

TinkerResourceIdTask applyResourceTask 
        = project.tasks.create("tinkerProcess${variantName}ResourceId", TinkerResourceIdTask)
applyResourceTask.mustRunAfter manifestTask
variantOutput.processResources.dependsOn applyResourceTask

if (proguardEnable) {
    TinkerProguardConfigTask proguardConfigTask 
            = project.tasks.create("tinkerProcess${variantName}Proguard", TinkerProguardConfigTask)
    proguardConfigTask.mustRunAfter manifestTask

    def proguardTask = getProguardTask(project, variantName)
    if (proguardTask != null) {
        proguardTask.dependsOn proguardConfigTask
    }

}
if (multiDexEnabled) {
    TinkerMultidexConfigTask multidexConfigTask 
            = project.tasks.create("tinkerProcess${variantName}MultidexKeep", TinkerMultidexConfigTask)
    multidexConfigTask.mustRunAfter manifestTask

    def multidexTask = getMultiDexTask(project, variantName)
    if (multidexTask != null) {
        multidexTask.dependsOn multidexConfigTask
    }
}複製程式碼

可以看到它通過gradle Project API建立了5個task，通過dependsOn,mustRunAfter插入到了原本的流程中。

例如：

TinkerManifestTask manifestTask = ...
manifestTask.mustRunAfter variantOutput.processManifest
variantOutput.processResources.dependsOn manifestTask複製程式碼

TinkerManifestTask必須在processManifest之後執行，processResources在manifestTask後執行。

所以流程變為：

processManifest-> manifestTask-> processResources複製程式碼

其他同理。

ok，大致瞭解了這些task是如何注入的之後，接下來就看看每個task的具體作用吧。

注：如果我們有需求在build過程中搞事，可以參考上述task編寫以及依賴方式的設定。

三、每個Task的具體行為

我們按照上述的流程來看，依次為：

TinkerManifestTask
TinkerResourceIdTask
TinkerProguardConfigTask
TinkerMultidexConfigTask
TinkerPatchSchemaTask複製程式碼

丟個圖，對應下：

四、TinkerManifestTask

#TinkerManifestTask
@TaskAction
def updateManifest() {
    // Parse the AndroidManifest.xml
    String tinkerValue = project.extensions.tinkerPatch.buildConfig.tinkerId

    tinkerValue = TINKER_ID_PREFIX + tinkerValue;//"tinker_id_"

    // /build/intermediates/manifests/full/debug/AndroidManifest.xml
    writeManifestMeta(manifestPath, TINKER_ID, tinkerValue)

    addApplicationToLoaderPattern()
    File manifestFile = new File(manifestPath)
    if (manifestFile.exists()) {
        FileOperation.copyFileUsingStream(manifestFile, project.file(MANIFEST_XML))
    }
}複製程式碼

這裡主要做了兩件事：

writeManifestMeta主要就是解析AndroidManifest.xml，在<application>內部新增一個meta標籤,value為tinkerValue。

例如：
```
   <meta-data
          android:name="TINKER_ID"
          android:value="tinker_id_com.zhy.abc" />複製程式碼
```

這裡不詳細展開了，話說groovy解析XML真方便。

addApplicationToLoaderPattern主要是記錄自己的application類名和tinker相關的一些load class com.tencent.tinker.loader.*，記錄在project.extensions.tinkerPatch.dex.loader中。

最後copy修改後的AndroidManifest.xml至build/intermediates/tinker_intermediates/AndroidManifest.xml。

這裡我們需要想一下，在文初的分析中，並沒有想到需要tinkerId這個東西，那麼它到底是幹嘛的呢？

看一下微信提供的引數說明，就明白了：

在執行過程中，我們需要驗證基準apk包的tinkerId是否等於補丁包的tinkerId。這個是決定補丁包能執行在哪些基準包上面，一般來說我們可以使用git版本號、versionName等等。

想一下，在非強制升級的情況下，線上一般分佈著各個版本的app。但是。你打patch肯定是對應某個版本，所以你要保證這個patch下發下去隻影響對應的版本，不會對其他版本造成影響，所以你需要tinkerId與具體的版本相對應。

ok，下一個TinkerResourceIdTask。

五、TinkerResourceIdTask

文初提到，打patch的過程實際上要控制已有的資源id不能發生變化，這個task所做的事就是為此。

如果保證已有資源的id保持不變呢？

實際上需要public.xml和ids.xml的參與，即預先在public.xml中的如下定義，在第二次打包之後可保持該資源對應的id值不變。

注：對xml檔案的名稱應該沒有強要求。

<public type="id" name="search_button" id="0x7f0c0046" />複製程式碼

很多時候我們在搜尋固化資源，一般都能看到通過public.xml去固化資源id，但是這裡有個ids.xml是幹嘛的呢？

下面這篇文章有個很好的解釋~

blog.csdn.net/sbsujjbcy/a…

首先需要生成public.xml，public.xml的生成通過aapt編譯時新增-P引數生成。相關程式碼通過gradle外掛去hook Task無縫加入該引數，有一點需要注意，通過appt生成的public.xml並不是可以直接用的，該檔案中存在id型別的資源，生成patch時應用進去編譯的時候會報resource is not defined，解決方法是將id型別型的資源單獨記錄到ids.xml檔案中，相當於一個宣告過程，編譯的時候和public.xml一樣，將ids.xml也參與編譯即可。

ok，知道了public.xml和ids.xml的作用之後，需要再思考一下如何保證id不變？

首先我們在配置old apk的時候，會配置tinkerApplyResourcePath引數，該引數對應一個R.txt，裡面的內容涵蓋了所有old apk中資源對應的int值。

那麼我們可以這麼做，根據這個R.txt，把裡面的資料寫成public.xml不就能保證原本的資源對應的int值不變了麼。

的確是這樣的，不過tinker做了更多，不僅將old apk的中的資源資訊寫到public.xml，而且還干涉了新的資源，對新的資源按照資源id的生成規則，也分配的對應的int值，寫到了public.xml，可以說該task包辦了資源id的生成。

分析前的總結

好了，由於程式碼非常長，我決定在這個地方先用總結性的語言總結下，如果沒有耐心看程式碼的可以直接跳過原始碼分析階段：

首先將設定的old R.txt讀取到記憶體中，轉為：

一個Map，key-value都代表一個具體資源資訊；直接複用，不會生成新的資源資訊。
一個Map，key為資源型別，value為該類資源當前的最大int值；參與新的資源id的生成。

接下來遍歷當前app中的資源，資源分為：

values資料夾下檔案

對所有values相關資料夾下的檔案已經處理完畢，大致的處理為：遍歷檔案中的節點，大致有item，dimen，color，drawable，bool，integer，array，style，declare-styleable，attr，fraction這些節點，將所有的節點按型別分類儲存到rTypeResourceMap（key為資源型別，value為對應型別資源集合Set）中。

其中declare-styleable這個標籤，主要讀取其內部的attr標籤，對attr標籤對應的資源按上述處理。

res下非values資料夾

開啟自己的專案有看一眼，除了values相關還有layout,anim,color等資料夾，主要分為兩類：

一類是對檔案即為資源，例如R.layout.xxx，R.drawable.xxx等；另一類為xml文件中以@+（去除@+android:id），其實就是找到我們自定義id節點，然後擷取該節點的id值部分作為屬性的名稱（例如：@+id/tv，tv即為屬性的名稱）。

如果和設定的old apk中檔案中相同name和type的節點不需要特殊處理，直接複用即可；如果不存在則需要生成新的typeId、resourceId等資訊。

會將所有生成的資源都存到rTypeResourceMap中，最後寫檔案。

這樣就基本收集到了所有的需要生成資源資訊的所有的資源，最後寫到public.xml即可。

總結性的語言難免有一些疏漏，實際以原始碼分析為標準。

開始原始碼分析

@TaskAction
def applyResourceId() {
     // 資源mapping檔案
    String resourceMappingFile = project.extensions.tinkerPatch.buildConfig.applyResourceMapping

    // resDir /build/intermediates/res/merged/debug
    String idsXml = resDir + "/values/ids.xml";
    String publicXml = resDir + "/values/public.xml";
    FileOperation.deleteFile(idsXml);
    FileOperation.deleteFile(publicXml);

    List<String> resourceDirectoryList = new ArrayList<String>();
    // /build/intermediates/res/merged/debug
    resourceDirectoryList.add(resDir);

    project.logger.error("we build ${project.getName()} apk with apply resource mapping file ${resourceMappingFile}");

    project.extensions.tinkerPatch.buildConfig.usingResourceMapping = true;

    // 收集所有的資源，以type->type,name,id,int/int[]儲存
    Map<RDotTxtEntry.RType, Set<RDotTxtEntry>> rTypeResourceMap = PatchUtil.readRTxt(resourceMappingFile);

    AaptResourceCollector aaptResourceCollector = AaptUtil.collectResource(resourceDirectoryList, rTypeResourceMap);

    PatchUtil.generatePublicResourceXml(aaptResourceCollector, idsXml, publicXml);
    File publicFile = new File(publicXml);
    if (publicFile.exists()) {
        FileOperation.copyFileUsingStream(publicFile, project.file(RESOURCE_PUBLIC_XML));
        project.logger.error("tinker gen resource public.xml in ${RESOURCE_PUBLIC_XML}");
    }
    File idxFile = new File(idsXml);
    if (idxFile.exists()) {
        FileOperation.copyFileUsingStream(idxFile, project.file(RESOURCE_IDX_XML));
        project.logger.error("tinker gen resource idx.xml in ${RESOURCE_IDX_XML}");
    }
}複製程式碼

大體瀏覽下程式碼，可以看到首先檢測是否設定了resource mapping檔案，如果沒有設定會直接跳過。並且最後的產物是public.xml和ids.xml。

因為生成patch時，需要保證兩次打包已經存在的資源的id一致，需要public.xml和ids.xml的參與。

首先清理已經存在的public.xml和ids.xml，然後通過PatchUtil.readRTxt讀取resourceMappingFile（引數中設定的），該檔案記錄的格式如下：

int anim abc_slide_in_bottom 0x7f050006
int id useLogo 0x7f0b0012
int[] styleable AppCompatImageView { 0x01010119, 0x7f010027 }
int styleable AppCompatImageView_android_src 0
int styleable AppCompatImageView_srcCompat 1複製程式碼

大概有兩類，一類是int型各種資源；一類是int[]陣列，代表styleable，其後面緊跟著它的item（熟悉自定義View的一定不陌生）。

PatchUtil.readRTxt的程式碼就不貼了，簡單描述下：

首先正則按行匹配，每行分為四部分，即idType,rType,name,idValue（四個屬性為RDotTxtEntry的成員變數）。

idType有兩種INT和INT_ARRAY。
rType包含各種資源：

ANIM, ANIMATOR, ARRAY, ATTR, BOOL, COLOR, DIMEN, DRAWABLE, FRACTION, ID, INTEGER, INTERPOLATOR, LAYOUT, MENU, MIPMAP, PLURALS, RAW, STRING, STYLE, STYLEABLE, TRANSITION, XML

developer.android.com/reference/a…

name和value就是普通的鍵值對了。

這裡並沒有對styleable做特殊處理。

最後按rType分類，存在一個Map中，即key為rType，value為一個RDotTxtEntry型別的Set集合。

回顧下剩下的程式碼：

//...省略前半部分
     AaptResourceCollector aaptResourceCollector = AaptUtil.collectResource(resourceDirectoryList, rTypeResourceMap);
    PatchUtil.generatePublicResourceXml(aaptResourceCollector, idsXml, publicXml);
    File publicFile = new File(publicXml);
    if (publicFile.exists()) {
        FileOperation.copyFileUsingStream(publicFile, project.file(RESOURCE_PUBLIC_XML));
        project.logger.error("tinker gen resource public.xml in ${RESOURCE_PUBLIC_XML}");
    }
    File idxFile = new File(idsXml);
    if (idxFile.exists()) {
        FileOperation.copyFileUsingStream(idxFile, project.file(RESOURCE_IDX_XML));
        project.logger.error("tinker gen resource idx.xml in ${RESOURCE_IDX_XML}");
    }複製程式碼

那麼到了AaptUtil.collectResource方法，傳入了resDir目錄和我們剛才收集了資源資訊的Map,返回了一個AaptResourceCollector物件，看名稱是對aapt相關的資源的收集：

看程式碼：

public static AaptResourceCollector collectResource(List<String> resourceDirectoryList,
                                                    Map<RType, Set<RDotTxtEntry>> rTypeResourceMap) {
    AaptResourceCollector resourceCollector = new AaptResourceCollector(rTypeResourceMap);
    List<com.tencent.tinker.build.aapt.RDotTxtEntry> references = new ArrayList<com.tencent.tinker.build.aapt.RDotTxtEntry>();
    for (String resourceDirectory : resourceDirectoryList) {
        try {
            collectResources(resourceDirectory, resourceCollector);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
    for (String resourceDirectory : resourceDirectoryList) {
        try {
            processXmlFilesForIds(resourceDirectory, references, resourceCollector);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
    return resourceCollector;
}複製程式碼

首先初始化了一個AaptResourceCollector物件，看其構造方法：

public AaptResourceCollector(Map<RType, Set<RDotTxtEntry>> rTypeResourceMap) {
    this();
    if (rTypeResourceMap != null) {
        Iterator<Entry<RType, Set<RDotTxtEntry>>> iterator = rTypeResourceMap.entrySet().iterator();
        while (iterator.hasNext()) {
            Entry<RType, Set<RDotTxtEntry>> entry = iterator.next();
            RType rType = entry.getKey();
            Set<RDotTxtEntry> set = entry.getValue();

            for (RDotTxtEntry rDotTxtEntry : set) {
                originalResourceMap.put(rDotTxtEntry, rDotTxtEntry);

                ResourceIdEnumerator resourceIdEnumerator = null;
                    // ARRAY主要是styleable
                if (!rDotTxtEntry.idType.equals(IdType.INT_ARRAY)) {
                        // 獲得resourceId
                    int resourceId = Integer.decode(rDotTxtEntry.idValue.trim()).intValue();
                    // 獲得typeId
                    int typeId = ((resourceId & 0x00FF0000) / 0x00010000);


                    if (typeId >= currentTypeId) {
                        currentTypeId = typeId + 1;
                    }

                        // type -> id的對映
                    if (this.rTypeEnumeratorMap.containsKey(rType)) {
                        resourceIdEnumerator = this.rTypeEnumeratorMap.get(rType);
                        if (resourceIdEnumerator.currentId < resourceId) {
                            resourceIdEnumerator.currentId = resourceId;
                        }
                    } else {
                        resourceIdEnumerator = new ResourceIdEnumerator();
                        resourceIdEnumerator.currentId = resourceId;
                        this.rTypeEnumeratorMap.put(rType, resourceIdEnumerator);
                    }
                }
            }
        }
    }
}複製程式碼

對rTypeResourceMap根據rType進行遍歷，讀取每個rType對應的Set集合；然後遍歷每個rDotTxtEntry：

加入到originalResourceMap，key和value都是rDotTxtEntry物件
如果是int型資源，首先讀取其typeId，並持續更新currentTypeId(保證其為遍歷完成後的最大值+1)
初始化rTypeEnumeratorMap，key為rType，value為ResourceIdEnumerator，且ResourceIdEnumerator中的currentId儲存著目前同類資源的最大的resouceId，也就是說rTypeEnumeratorMap中儲存了各個rType對應的最大的資源Id。

結束完成構造方法，執行了

遍歷了resourceDirectoryList，目前其中只有一個resDir，然後執行了collectResources方法；
遍歷了resourceDirectoryList，執行了processXmlFilesForIds

分別讀程式碼了：

collectResources

private static void collectResources(String resourceDirectory, AaptResourceCollector resourceCollector) throws Exception {
    File resourceDirectoryFile = new File(resourceDirectory);
    File[] fileArray = resourceDirectoryFile.listFiles();
    if (fileArray != null) {
        for (File file : fileArray) {
            if (file.isDirectory()) {
                String directoryName = file.getName();
                if (directoryName.startsWith("values")) {
                    if (!isAValuesDirectory(directoryName)) {
                        throw new AaptUtilException("'" + directoryName + "' is not a valid values directory.");
                    }
                    processValues(file.getAbsolutePath(), resourceCollector);
                } else {
                    processFileNamesInDirectory(file.getAbsolutePath(), resourceCollector);
                }
            }
        }
    }
}複製程式碼

遍歷我們的resDir中的所有資料夾

如果是values相關資料夾，執行processValues
非values相關資料夾則執行processFileNamesInDirectory

processValues處理values相關檔案，會遍歷每一個合法的values相關資料夾下的檔案，執行processValuesFile(file.getAbsolutePath(), resourceCollector);

public static void processValuesFile(String valuesFullFilename,
                                     AaptResourceCollector resourceCollector) throws Exception {
    Document document = JavaXmlUtil.parse(valuesFullFilename);
    String directoryName = new File(valuesFullFilename).getParentFile().getName();
    Element root = document.getDocumentElement();

    for (Node node = root.getFirstChild(); node != null; node = node.getNextSibling()) {
        if (node.getNodeType() != Node.ELEMENT_NODE) {
            continue;
        }

        String resourceType = node.getNodeName();
        if (resourceType.equals(ITEM_TAG)) {
            resourceType = node.getAttributes().getNamedItem("type").getNodeValue();
            if (resourceType.equals("id")) {
                resourceCollector.addIgnoreId(node.getAttributes().getNamedItem("name").getNodeValue());
            }
        }

        if (IGNORED_TAGS.contains(resourceType)) {
            continue;
        }

        if (!RESOURCE_TYPES.containsKey(resourceType)) {
            throw new AaptUtilException("Invalid resource type '<" + resourceType + ">' in '" + valuesFullFilename + "'.");
        }

        RType rType = RESOURCE_TYPES.get(resourceType);
        String resourceValue = null;
        switch (rType) {
            case STRING:
            case COLOR:
            case DIMEN:
            case DRAWABLE:
            case BOOL:
            case INTEGER:
                resourceValue = node.getTextContent().trim();
                break;
            case ARRAY://has sub item
            case PLURALS://has sub item
            case STYLE://has sub item
            case STYLEABLE://has sub item
                resourceValue = subNodeToString(node);
                break;
            case FRACTION://no sub item
                resourceValue = nodeToString(node, true);
                break;
            case ATTR://no sub item
                resourceValue = nodeToString(node, true);
                break;
        }
        try {
            addToResourceCollector(resourceCollector,
                    new ResourceDirectory(directoryName, valuesFullFilename),
                    node, rType, resourceValue);
        } catch (Exception e) {
            throw new AaptUtilException(e.getMessage() + ",Process file error:" + valuesFullFilename, e);
        }
    }
}複製程式碼

values下相關的檔案基本都是xml咯，所以遍歷xml檔案，遍歷其內部的節點，（values的xml檔案其內部一般為item，dimen，color，drawable，bool，integer，array，style，declare-styleable，attr，fraction等），每種型別的節點對應一個rType，根據不同型別的節點也會去獲取節點的值，確定一個都會執行：

addToResourceCollector(resourceCollector,
    new ResourceDirectory(directoryName, valuesFullFilename),
    node, rType, resourceValue);複製程式碼

注：除此以外，這裡在ignoreIdSet記錄了宣告的id資源，這些id是已經宣告過的，所以最終在編寫ids.xml時，可以過濾掉這些id。

下面繼續看：addToResourceCollector

原始碼如下：

private static void addToResourceCollector(AaptResourceCollector resourceCollector,
                                           ResourceDirectory resourceDirectory,
                                           Node node, RType rType, String resourceValue) {
    String resourceName = sanitizeName(rType, resourceCollector, extractNameAttribute(node));

    if (rType.equals(RType.STYLEABLE)) {

        int count = 0;
        for (Node attrNode = node.getFirstChild(); attrNode != null; attrNode = attrNode.getNextSibling()) {
            if (attrNode.getNodeType() != Node.ELEMENT_NODE || !attrNode.getNodeName().equals("attr")) {
                continue;
            }
            String rawAttrName = extractNameAttribute(attrNode);
            String attrName = sanitizeName(rType, resourceCollector, rawAttrName);

            if (!rawAttrName.startsWith("android:")) {
                resourceCollector.addIntResourceIfNotPresent(RType.ATTR, attrName);
            }
        }
    } else {
        resourceCollector.addIntResourceIfNotPresent(rType, resourceName);
    }
}複製程式碼

如果不是styleable的資源，則直接獲取resourceName，然後呼叫resourceCollector.addIntResourceIfNotPresent(rType, resourceName)。

如果是styleable型別的資源，則會遍歷找到其內部的attr節點，找出非android:開頭的（因為android:開頭的attr的id不需要我們去確定），設定rType為ATTR，value為attr屬性的name，呼叫addIntResourceIfNotPresent。

public void addIntResourceIfNotPresent(RType rType, String name) { //, ResourceDirectory resourceDirectory) {
    if (!rTypeEnumeratorMap.containsKey(rType)) {
        if (rType.equals(RType.ATTR)) {
            rTypeEnumeratorMap.put(rType, new ResourceIdEnumerator(1));
        } else {
            rTypeEnumeratorMap.put(rType, new ResourceIdEnumerator(currentTypeId++));
        }
    }

    RDotTxtEntry entry = new FakeRDotTxtEntry(IdType.INT, rType, name);
    Set<RDotTxtEntry> resourceSet = null;
    if (this.rTypeResourceMap.containsKey(rType)) {
        resourceSet = this.rTypeResourceMap.get(rType);
    } else {
        resourceSet = new HashSet<RDotTxtEntry>();
        this.rTypeResourceMap.put(rType, resourceSet);
    }
    if (!resourceSet.contains(entry)) {
        String idValue = String.format("0x%08x", rTypeEnumeratorMap.get(rType).next());
        addResource(rType, IdType.INT, name, idValue); //, resourceDirectory);
    }
}複製程式碼

首先構建一個entry，然後判斷當前的rTypeResourceMap中是否存在該資源實體，如果存在，則什麼都不用做。

如果不存在，則需要構建一個entry，那麼主要是id的構建。

關於id的構建：

還記得rTypeEnumeratorMap麼，其內部包含了我們設定的"res mapping"檔案，儲存了每一類資源（rType）的資源的最大resourceId值。

那麼首先判斷就是是否已經有這種型別了，如果有的話，獲取出該型別當前最大的resourceId，然後+1，最為傳入資源的resourceId.

如果不存在當前這種型別，那麼如果型別為ATTR則固定type為1；否則的話，新增一個typeId，為當前最大的type+1（currentTypeId中也是記錄了目前最大的type值），有了型別就可以通過ResourceIdEnumerator.next()來獲取id。

經過上述就可以構造出一個idValue了。

最後呼叫：

addResource(rType, IdType.INT, name, idValue);複製程式碼

檢視程式碼：

public void addResource(RType rType, IdType idType, String name, String idValue) {
    Set<RDotTxtEntry> resourceSet = null;
    if (this.rTypeResourceMap.containsKey(rType)) {
        resourceSet = this.rTypeResourceMap.get(rType);
    } else {
        resourceSet = new HashSet<RDotTxtEntry>();
        this.rTypeResourceMap.put(rType, resourceSet);
    }
    RDotTxtEntry rDotTxtEntry = new RDotTxtEntry(idType, rType, name, idValue);

    if (!resourceSet.contains(rDotTxtEntry)) {
        if (this.originalResourceMap.containsKey(rDotTxtEntry)) {
            this.rTypeEnumeratorMap.get(rType).previous();
            rDotTxtEntry = this.originalResourceMap.get(rDotTxtEntry);
        } 
        resourceSet.add(rDotTxtEntry);
    }

}複製程式碼

大體意思就是如果該資源不存在就新增到rTypeResourceMap。

首先構建出該資源實體，判斷該型別對應的資源集合是否包含該資源實體（這裡contains只比對name和type），如果不包含，判斷是否在originalResourceMap中，如果存在（這裡做了一個previous操作，其實與上面的程式碼的next操作對應，主要是針對資源存在我們的res map中這種情況）則取出該資源實體，最終將該資源實體加入到rTypeResourceMap中。

ok，到這裡需要小節一下，我們剛才對所有values相關資料夾下的檔案已經處理完畢，大致的處理為：遍歷檔案中的節點，大致有item，dimen，color，drawable，bool，integer，array，style，declare-styleable，attr，fraction這些節點，將所有的節點按型別分類儲存到rTypeResourceMap中（如果和設定的"res map"檔案中相同name和type的節點不需要特殊處理，直接複用即可；如果不存在則需要生成新的typeId、resourceId等資訊）。

其中declare-styleable這個標籤，主要讀取其內部的attr標籤，對attr標籤對應的資源按上述處理。

處理完成values相關資料夾之後，還需要處理一些res下的其他檔案，比如layout、layout、anim等資料夾，該類資源也需要在R中生成對應的id值，這類值也需要固化。

processFileNamesInDirectory

public static void processFileNamesInDirectory(String resourceDirectory,
                                               AaptResourceCollector resourceCollector) throws IOException {
    File resourceDirectoryFile = new File(resourceDirectory);
    String directoryName = resourceDirectoryFile.getName();
    int dashIndex = directoryName.indexOf('-');
    if (dashIndex != -1) {
        directoryName = directoryName.substring(0, dashIndex);
    }

    if (!RESOURCE_TYPES.containsKey(directoryName)) {
        throw new AaptUtilException(resourceDirectoryFile.getAbsolutePath() + " is not a valid resource sub-directory.");
    }
    File[] fileArray = resourceDirectoryFile.listFiles();
    if (fileArray != null) {
        for (File file : fileArray) {
            if (file.isHidden()) {
                continue;
            }
            String filename = file.getName();
            int dotIndex = filename.indexOf('.');
            String resourceName = dotIndex != -1 ? filename.substring(0, dotIndex) : filename;

            RType rType = RESOURCE_TYPES.get(directoryName);
            resourceCollector.addIntResourceIfNotPresent(rType, resourceName);

            System.out.println("rType = " + rType + " , resName = " + resourceName);

            ResourceDirectory resourceDirectoryBean = new ResourceDirectory(file.getParentFile().getName(), file.getAbsolutePath());
            resourceCollector.addRTypeResourceName(rType, resourceName, null, resourceDirectoryBean);
        }
    }
}複製程式碼

遍歷res下所有資料夾，根據資料夾名稱確定其對應的資源型別（例如：drawable-xhpi，則認為其內部的檔案型別為drawable型別），然後遍歷該資料夾下所有的檔案，最終以檔名為資源的name，資料夾確定資源的type，最終呼叫：

resourceCollector
.addIntResourceIfNotPresent(rType, resourceName);複製程式碼

processXmlFilesForIds

public static void processXmlFilesForIds(String resourceDirectory,
                                         List<RDotTxtEntry> references, AaptResourceCollector resourceCollector) throws Exception {
    List<String> xmlFullFilenameList = FileUtil
            .findMatchFile(resourceDirectory, Constant.Symbol.DOT + Constant.File.XML);
    if (xmlFullFilenameList != null) {
        for (String xmlFullFilename : xmlFullFilenameList) {
            File xmlFile = new File(xmlFullFilename);

            String parentFullFilename = xmlFile.getParent();
            File parentFile = new File(parentFullFilename);
            if (isAValuesDirectory(parentFile.getName()) || parentFile.getName().startsWith("raw")) {
                // Ignore files under values* directories and raw*.
                continue;
            }
            processXmlFile(xmlFullFilename, references, resourceCollector);
        }
    }
}複製程式碼

遍歷除了raw*以及values*相關資料夾下的xml檔案，執行processXmlFile。

public static void processXmlFile(String xmlFullFilename, List<RDotTxtEntry> references, AaptResourceCollector resourceCollector)
        throws IOException, XPathExpressionException {
    Document document = JavaXmlUtil.parse(xmlFullFilename);
    NodeList nodesWithIds = (NodeList) ANDROID_ID_DEFINITION.evaluate(document, XPathConstants.NODESET);
    for (int i = 0; i < nodesWithIds.getLength(); i++) {
        String resourceName = nodesWithIds.item(i).getNodeValue();


        if (!resourceName.startsWith(ID_DEFINITION_PREFIX)) {
            throw new AaptUtilException("Invalid definition of a resource: '" + resourceName + "'");
        }

        resourceCollector.addIntResourceIfNotPresent(RType.ID, resourceName.substring(ID_DEFINITION_PREFIX.length()));
    }

    // 省略了無關程式碼
}複製程式碼

主要找xml文件中以@+（去除@+android:id），其實就是找到我們自定義id節點，然後擷取該節點的id值部分作為屬性的名稱（例如：@+id/tv，tv即為屬性的名稱），最終呼叫：

resourceCollector
    .addIntResourceIfNotPresent(RType.ID, 
        resourceName.substring(ID_DEFINITION_PREFIX.length()));複製程式碼

上述就完成了所有的資源的收集，那麼剩下的就是寫檔案了：


public static void generatePublicResourceXml(AaptResourceCollector aaptResourceCollector,
                                             String outputIdsXmlFullFilename,
                                             String outputPublicXmlFullFilename) {
    if (aaptResourceCollector == null) {
        return;
    }
    FileUtil.createFile(outputIdsXmlFullFilename);
    FileUtil.createFile(outputPublicXmlFullFilename);

    PrintWriter idsWriter = null;
    PrintWriter publicWriter = null;
    try {
        FileUtil.createFile(outputIdsXmlFullFilename);
        FileUtil.createFile(outputPublicXmlFullFilename);
        idsWriter = new PrintWriter(new File(outputIdsXmlFullFilename), "UTF-8");

        publicWriter = new PrintWriter(new File(outputPublicXmlFullFilename), "UTF-8");
        idsWriter.println("<?xml version=\"1.0\" encoding=\"utf-8\"?>");
        publicWriter.println("<?xml version=\"1.0\" encoding=\"utf-8\"?>");
        idsWriter.println("<resources>");
        publicWriter.println("<resources>");
        Map<RType, Set<RDotTxtEntry>> map = aaptResourceCollector.getRTypeResourceMap();
        Iterator<Entry<RType, Set<RDotTxtEntry>>> iterator = map.entrySet().iterator();
        while (iterator.hasNext()) {
            Entry<RType, Set<RDotTxtEntry>> entry = iterator.next();
            RType rType = entry.getKey();
            if (!rType.equals(RType.STYLEABLE)) {
                Set<RDotTxtEntry> set = entry.getValue();
                for (RDotTxtEntry rDotTxtEntry : set) {
                    String rawName = aaptResourceCollector.getRawName(rType, rDotTxtEntry.name);
                    if (StringUtil.isBlank(rawName)) {
                        rawName = rDotTxtEntry.name;
                    }
                    publicWriter.println("<public type=\"" + rType + "\" name=\"" + rawName + "\" id=\"" + rDotTxtEntry.idValue.trim() + "\" />")；          
                }
                Set<String> ignoreIdSet = aaptResourceCollector.getIgnoreIdSet();
                for (RDotTxtEntry rDotTxtEntry : set) {
                    if (rType.equals(RType.ID) && !ignoreIdSet.contains(rDotTxtEntry.name)) {
                        idsWriter.println("<item type=\"" + rType + "\" name=\"" + rDotTxtEntry.name + "\"/>");
                    } 
                }
            }
            idsWriter.flush();
            publicWriter.flush();
        }
        idsWriter.println("</resources>");
        publicWriter.println("</resources>");
    } catch (Exception e) {
        throw new PatchUtilException(e);
    } finally {
        if (idsWriter != null) {
            idsWriter.flush();
            idsWriter.close();
        }
        if (publicWriter != null) {
            publicWriter.flush();
            publicWriter.close();
        }
    }
}複製程式碼

主要就是遍歷rTypeResourceMap，然後每個資源實體對應一條public標籤記錄寫到public.xml中。

此外，如果發現該元素節點的type為Id，並且不在ignoreSet中，會寫到ids.xml這個檔案中。（這裡有個ignoreSet，這裡ignoreSet中記錄了values下所有的<item type=id的資源，是直接在專案中已經宣告過的，所以去除）。

六、TinkerProguardConfigTask

還記得文初說：

我們在上線app的時候，會做程式碼混淆，如果沒有做特殊的設定，每次混淆後的程式碼差別應該非常巨大；所以，build過程中理論上需要設定混淆的mapping檔案。

在接入一些庫的時候，往往還需要配置混淆，比如第三方庫中哪些東西不能被混淆等（當然強制某些類在主dex中，也可能需要配置相對應的混淆規則）。

這個task的作用很明顯了。有時候為了確保一些類在main dex中，簡單的做法也會對其在混淆配置中進行keep（避免由於混淆造成類名更改，而使main dex的keep失效）。

如果開啟了proguard會執行該task。

這個就是主要去設定混淆的mapping檔案，和keep一些必要的類了。

@TaskAction
def updateTinkerProguardConfig() {
    def file = project.file(PROGUARD_CONFIG_PATH)
    project.logger.error("try update tinker proguard file with ${file}")

    // Create the directory if it doesnt exist already
    file.getParentFile().mkdirs()

    // Write our recommended proguard settings to this file
    FileWriter fr = new FileWriter(file.path)

    String applyMappingFile = project.extensions.tinkerPatch.buildConfig.applyMapping

    //write applymapping
    if (shouldApplyMapping && FileOperation.isLegalFile(applyMappingFile)) {
        project.logger.error("try add applymapping ${applyMappingFile} to build the package")
        fr.write("-applymapping " + applyMappingFile)
        fr.write("\n")
    } else {
        project.logger.error("applymapping file ${applyMappingFile} is illegal, just ignore")
    }

    fr.write(PROGUARD_CONFIG_SETTINGS)

    fr.write("#your dex.loader patterns here\n")
    //they will removed when apply
    Iterable<String> loader = project.extensions.tinkerPatch.dex.loader
    for (String pattern : loader) {
        if (pattern.endsWith("*") && !pattern.endsWith("**")) {
            pattern += "*"
        }
        fr.write("-keep class " + pattern)
        fr.write("\n")
    }
    fr.close()
    // Add this proguard settings file to the list
    applicationVariant.getBuildType().buildType.proguardFiles(file)
    def files = applicationVariant.getBuildType().buildType.getProguardFiles()

    project.logger.error("now proguard files is ${files}")
}複製程式碼

讀取我們設定的mappingFile，設定

-applymapping applyMappingFile複製程式碼

然後設定一些預設需要keep的規則：

PROGUARD_CONFIG_SETTINGS =
"-keepattributes *Annotation* \n" +
"-dontwarn com.tencent.tinker.anno.AnnotationProcessor \n" +
"-keep @com.tencent.tinker.anno.DefaultLifeCycle public class *\n" +
"-keep public class * extends android.app.Application {\n" +
"    *;\n" +
"}\n" +
"\n" +
"-keep public class com.tencent.tinker.loader.app.ApplicationLifeCycle {\n" +
"    *;\n" +
"}\n" +
"-keep public class * implements com.tencent.tinker.loader.app.ApplicationLifeCycle {\n" +
"    *;\n" +
"}\n" +
"\n" +
"-keep public class com.tencent.tinker.loader.TinkerLoader {\n" +
"    *;\n" +
"}\n" +
"-keep public class * extends com.tencent.tinker.loader.TinkerLoader {\n" +
"    *;\n" +
"}\n" +
"-keep public class com.tencent.tinker.loader.TinkerTestDexLoad {\n" +
"    *;\n" +
"}\n" +
"\n"複製程式碼

最後是keep住我們的application、com.tencent.tinker.loader.**以及我們設定的相關類。

TinkerManifestTask中：addApplicationToLoaderPattern主要是記錄自己的application類名和tinker相關的一些load class com.tencent.tinker.loader.*，記錄在project.extensions.tinkerPatch.dex.loader。

七、TinkerMultidexConfigTask

對應文初：

當專案比較大的時候，我們可能會遇到方法數超過65535的問題，我們很多時候會通過分包解決，這樣就有主dex和其他dex的概念。整合了tinker之後，在應用的Application啟動時會非常早的就去做tinker的load操作，所以就決定了load相關的類必須在主dex中。

如果multiDexEnabled開啟。

主要是讓相關類必須在main dex。

"-keep public class * implements com.tencent.tinker.loader.app.ApplicationLifeCycle {\n" +
    "    *;\n" +
    "}\n" +
    "\n" +
    "-keep public class * extends com.tencent.tinker.loader.TinkerLoader {\n" +
    "    *;\n" +
    "}\n" +
    "\n" +
    "-keep public class * extends android.app.Application {\n" +
    "    *;\n" +
    "}\n"複製程式碼

Iterable<String> loader = project.extensions.tinkerPatch.dex.loader
    for (String pattern : loader) {
        if (pattern.endsWith("*")) {
            if (!pattern.endsWith("**")) {
                pattern += "*"
            }
        }
        lines.append("-keep class " + pattern + " {\n" +
                "    *;\n" +
                "}\n")
                .append("\n")
    }複製程式碼

相關類都在loader這個集合中，在TinkerManifestTask中設定的。

八、TinkerPatchSchemaTask

主要執行Runner.tinkerPatch

protected void tinkerPatch() {
    try {
        //gen patch
        ApkDecoder decoder = new ApkDecoder(config);
        decoder.onAllPatchesStart();
        decoder.patch(config.mOldApkFile, config.mNewApkFile);
        decoder.onAllPatchesEnd();

        //gen meta file and version file
        PatchInfo info = new PatchInfo(config);
        info.gen();

        //build patch
        PatchBuilder builder = new PatchBuilder(config);
        builder.buildPatch();

    } catch (Throwable e) {
        e.printStackTrace();
        goToError();
    }
}複製程式碼

主要分為以下環節：

生成patch
生成meta-file和version-file，這裡主要就是在assets目錄下寫一些鍵值對。（包含tinkerId以及配置中configField相關資訊）
build patch

（1）生成pacth

顧名思義就是兩個apk比較去生成各類patch檔案，那麼從一個apk的組成來看，大致可以分為：

dex檔案比對的patch檔案
res檔案比對的patch res檔案
so檔案比對生成的so patch檔案

看下程式碼：

public boolean patch(File oldFile, File newFile) throws Exception {
    //check manifest change first
    manifestDecoder.patch(oldFile, newFile);

    unzipApkFiles(oldFile, newFile);

    Files.walkFileTree(mNewApkDir.toPath(), new ApkFilesVisitor(config, mNewApkDir.toPath(),
            mOldApkDir.toPath(), dexPatchDecoder, soPatchDecoder, resPatchDecoder));

    soPatchDecoder.onAllPatchesEnd();
    dexPatchDecoder.onAllPatchesEnd();
    manifestDecoder.onAllPatchesEnd();
    resPatchDecoder.onAllPatchesEnd();

    //clean resources
    dexPatchDecoder.clean();
    soPatchDecoder.clean();
    resPatchDecoder.clean();
    return true;
}複製程式碼

程式碼內部包含四個Decoder：

manifestDecoder
dexPatchDecoder
soPatchDecoder
resPatchDecoder

剛才提到需要對dex、so、res檔案做diff，但是為啥會有個manifestDecoder。目前tinker並不支援四大元件，也就是說manifest檔案中是不允許出現新增元件的。

所以，manifestDecoder的作用實際上是用於檢查的：

minSdkVersion<14時僅允許dexMode使用jar模式（TODO：raw模式的區別是什麼？）
會解析manifest檔案，讀取出組大元件進行對比，不允許出現新增的任何元件。

程式碼就不貼了非常好理解，關於manifest的解析是基於該庫封裝的：

github.com/clearthesky…

然後就是解壓兩個apk檔案了，old apk（我們設定的），old apk 生成的。

解壓的目錄為：

old apk: build/intermediates/outputs/old apk名稱/
new apk: build/intermediates/outputs/app-debug/

解壓完成後，就是單個檔案對比了：

對比的思路是，以newApk解壓目錄下所有的檔案為基準，去oldApk中找同名的檔案，那麼會有以下幾個情況：

在oldApkDir中沒有找到，那麼說明該檔案是新增的
在oldApkDir中找到了，那麼比對md5，如果不同，則認為改變了（則需要根據情況做diff）

有了大致的瞭解後，可以看程式碼：

Files.walkFileTree(
    mNewApkDir.toPath(), 
    new ApkFilesVisitor(
        config, 
        mNewApkDir.toPath(),
          mOldApkDir.toPath(), 
          dexPatchDecoder, 
          soPatchDecoder, 
          resPatchDecoder));複製程式碼

Files.walkFileTree會以mNewApkDir.toPath()為基準，遍歷其內部所有的檔案，ApkFilesVisitor中可以對每個遍歷的檔案進行操作。

重點看ApkFilesVisitor是如何操作每個檔案的：

@Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {

    Path relativePath = newApkPath.relativize(file);
    // 在oldApkDir中找到該檔案
    Path oldPath = oldApkPath.resolve(relativePath);

    File oldFile = null;
    //is a new file?!
    if (oldPath.toFile().exists()) {
        oldFile = oldPath.toFile();
    }

    String patternKey = relativePath.toString().replace("\\", "/");

    if (Utils.checkFileInPattern(config.mDexFilePattern, patternKey)) {
           dexDecoder.patch(oldFile, file.toFile());
    }
    if (Utils.checkFileInPattern(config.mSoFilePattern, patternKey)) {
        soDecoder.patch(oldFile, file.toFile());
    }
    if (Utils.checkFileInPattern(config.mResFilePattern, patternKey)) {
         resDecoder.patch(oldFile, file.toFile());
    }
    return FileVisitResult.CONTINUE;
}複製程式碼

首先去除newApkDir中的一個檔案，在oldApkDir中尋找同名的apk；然後根據名稱判斷該檔案屬於：

dexFile -> dexDecoder.patch 完成dex檔案間的比對
soFile -> soDecoder.patch 完成so檔案的比對
resFile -> resDecoder.patch 完成res檔案的比對

各種檔案的規則是可配置的。

####（1）dexDecoder.patch

public boolean patch(final File oldFile, final File newFile)  {
    final String dexName = getRelativeDexName(oldFile, newFile);

    // 檢查loader class，省略了拋異常的一些程式碼
    excludedClassModifiedChecker.checkIfExcludedClassWasModifiedInNewDex(oldFile, newFile);


    File dexDiffOut = getOutputPath(newFile).toFile();

    final String newMd5 = getRawOrWrappedDexMD5(newFile);

    //new add file
    if (oldFile == null || !oldFile.exists() || oldFile.length() == 0) {
        hasDexChanged = true;
        copyNewDexAndLogToDexMeta(newFile, newMd5, dexDiffOut);
        return true;
    }

    final String oldMd5 = getRawOrWrappedDexMD5(oldFile);

    if ((oldMd5 != null && !oldMd5.equals(newMd5)) || (oldMd5 == null && newMd5 != null)) {
        hasDexChanged = true;
        if (oldMd5 != null) {
            collectAddedOrDeletedClasses(oldFile, newFile);
        }
    }

    RelatedInfo relatedInfo = new RelatedInfo();
    relatedInfo.oldMd5 = oldMd5;
    relatedInfo.newMd5 = newMd5;

    // collect current old dex file and corresponding new dex file for further processing.
    oldAndNewDexFilePairList.add(new AbstractMap.SimpleEntry<>(oldFile, newFile));

    dexNameToRelatedInfoMap.put(dexName, relatedInfo);

    return true;
}複製程式碼

首先執行：

checkIfExcludedClassWasModifiedInNewDex(oldFile, newFile);

該方法主要用處是檢查 tinker loader相關classes必須存在primary dex中，且不允許新增、修改和刪除。

所有首先將兩個dex讀取到記憶體中，按照config.mDexLoaderPattern進行過濾，找出deletedClassInfos、addedClassInfos、changedClassInfosMap，必須保證deletedClassInfos.isEmpty() && addedClassInfos.isEmpty() && changedClassInfosMap.isEmpty()即不允許新增、刪除、修改loader 相關類。

繼續，拿到輸出目錄：

build/intermediates/outputs/tinker_result/

然後如果oldFile不存在，則newFile認為是新增檔案，直接copy到輸出目錄，並記錄log

copyNewDexAndLogToDexMeta(newFile, newMd5, dexDiffOut);複製程式碼

如果存在，則計算兩個檔案的md5，如果md5不同，則認為dexChanged(hasDexChanged = true)，執行：

collectAddedOrDeletedClasses(oldFile, newFile);複製程式碼

該方法收集了addClasses和deleteClasses的相關資訊，記錄在：

addedClassDescToDexNameMap key為addClassDesc 和該dex file的path
deletedClassDescToDexNameMap key為deletedClassDesc 和該dex file的path

後續會使用這兩個資料結構，mark一下。

繼續往下走，初始化了一個relatedInfo記錄了兩個檔案的md5，以及在oldAndNewDexFilePairList中記錄了兩個dex file，在dexNameToRelatedInfoMap中記錄了dexName和relatedInfo的對映。

後續會使用該變數，mark一下。

到此，dexDecoder的patch方法就結束了，僅將新增的檔案copy到了目標目錄。

那麼發生改變的檔案，理論上應該要做md5看來在後面才會執行。

如果檔案是so檔案，則會走soDecoder.patch。

####（2）soDecoder.patch

soDecoder實際上是BsDiffDecoder

@Override
public boolean patch(File oldFile, File newFile)  {
    //new add file
    String newMd5 = MD5.getMD5(newFile);
    File bsDiffFile = getOutputPath(newFile).toFile();

    if (oldFile == null || !oldFile.exists()) {
        FileOperation.copyFileUsingStream(newFile, bsDiffFile);
        writeLogFiles(newFile, null, null, newMd5);
        return true;
    }

    //new add file
    String oldMd5 = MD5.getMD5(oldFile);

    if (oldMd5.equals(newMd5)) {
        return false;
    }

    if (!bsDiffFile.getParentFile().exists()) {
        bsDiffFile.getParentFile().mkdirs();
    }
    BSDiff.bsdiff(oldFile, newFile, bsDiffFile);

    //超過80%，返回false
    if (Utils.checkBsDiffFileSize(bsDiffFile, newFile)) {
        writeLogFiles(newFile, oldFile, bsDiffFile, newMd5);
    } else {
        FileOperation.copyFileUsingStream(newFile, bsDiffFile);
        writeLogFiles(newFile, null, null, newMd5);
    }
    return true;
}複製程式碼

如果oldFile不存在，則認為newFile為新增檔案，直接copy到目標檔案（連著so相關目錄）。

若oldFile存在，則比對二者md5，如果md5不一致，則直接進行bsdiff演算法，直接在目標位置寫入bsdiff產生的bsDiffFile。

本來到此應該已經結束了，但是接下來做了一件挺有意思的事：

繼續判斷了生成的patch檔案是否已經超過newFile的80%，如果超過80%,則直接copy newFile到目標目錄，直接覆蓋了剛生成的patch檔案。

那麼soPatch整個過程：

如果是新增檔案，直接copy至目標資料夾，記錄log
如果是改變的檔案，patch檔案超過新檔案的80%，則直接copy新檔案至目標資料夾，記錄log
如果是改變的檔案，patch檔案不超過新檔案的80%，則copy patch檔案至目標資料夾，記錄log

如果newFile是res 資源，則會走resDecoder

(3)resDecoder.patch

@Override
public boolean patch(File oldFile, File newFile) throws IOException, TinkerPatchException {
    String name = getRelativePathStringToNewFile(newFile);

    File outputFile = getOutputPath(newFile).toFile();

    if (oldFile == null || !oldFile.exists()) {
        FileOperation.copyFileUsingStream(newFile, outputFile);
        addedSet.add(name);
        writeResLog(newFile, oldFile, TypedValue.ADD);
        return true;
    }

    //new add file
    String newMd5 = MD5.getMD5(newFile);
    String oldMd5 = MD5.getMD5(oldFile);

    //oldFile or newFile may be 0b length
    if (oldMd5 != null && oldMd5.equals(newMd5)) {
        return false;
    }
    if (Utils.checkFileInPattern(config.mResIgnoreChangePattern, name)) {
        Logger.d("found modify resource: " + name + ", but it match ignore change pattern, just ignore!");
        return false;
    }
    if (name.equals(TypedValue.RES_MANIFEST)) {
        Logger.d("found modify resource: " + name + ", but it is AndroidManifest.xml, just ignore!");
        return false;
    }
    if (name.equals(TypedValue.RES_ARSC)) {
        if (AndroidParser.resourceTableLogicalChange(config)) {
            Logger.d("found modify resource: " + name + ", but it is logically the same as original new resources.arsc, just ignore!");
            return false;
        }
    }
    dealWithModeFile(name, newMd5, oldFile, newFile, outputFile);
    return true;
}複製程式碼

如果oldFile不存在，則認為新增檔案，直接copy且加入到addedSet集合，並記錄log

如果存在，且md5不同調研dealWithModeFile(設定的sIgnoreChangePattern、MANIFEST和邏輯上相同的ARSC不做處理)。


private boolean dealWithModeFile(String name, String newMd5, File oldFile, File newFile, File outputFile) {
    if (checkLargeModFile(newFile)) {
        if (!outputFile.getParentFile().exists()) {
            outputFile.getParentFile().mkdirs();
        }
        BSDiff.bsdiff(oldFile, newFile, outputFile);
        //未超過80%返回true
        if (Utils.checkBsDiffFileSize(outputFile, newFile)) {
            LargeModeInfo largeModeInfo = new LargeModeInfo();
            largeModeInfo.path = newFile;
            largeModeInfo.crc = FileOperation.getFileCrc32(newFile);
            largeModeInfo.md5 = newMd5;
            largeModifiedSet.add(name);
            largeModifiedMap.put(name, largeModeInfo);
            writeResLog(newFile, oldFile, TypedValue.LARGE_MOD);
            return true;
        }
    }
    modifiedSet.add(name);
    FileOperation.copyFileUsingStream(newFile, outputFile);
    writeResLog(newFile, oldFile, TypedValue.MOD);
    return false;
}複製程式碼

這裡，首先check了largeFile，即改變的檔案是否大於100K（該值可以配置）。

如果非大檔案，則直接copy至目標檔案，且記錄到modifiedSet，並記錄了log。

如果是大檔案，則直接bsdiff，生成patch File；接下來也檢查了一下patch file是否超過newFile的80%，如果超過，則直接copy newFile覆蓋剛生成的patch File；

總體和so patch基本一致。

到這裡，除了dex patch中對改變的dex檔案沒有做處理以外，so 和 res都做了。

接下來執行了：


public boolean patch(File oldFile, File newFile) throws Exception {
    //...

    soPatchDecoder.onAllPatchesEnd();
    dexPatchDecoder.onAllPatchesEnd();
    manifestDecoder.onAllPatchesEnd();
    resPatchDecoder.onAllPatchesEnd();

    //clean resources
    dexPatchDecoder.clean();
    soPatchDecoder.clean();
    resPatchDecoder.clean();
    return true;
}複製程式碼

其中dexPatchDecoder和resPatchDecoder有後續實現。

(4) dexPatchDecoder.onAllPatchesEnd

# DexDiffDecoder
@Override
public void onAllPatchesEnd() throws Exception {
    if (!hasDexChanged) {
        Logger.d("No dexes were changed, nothing needs to be done next.");
        return;
    }

    generatePatchInfoFile();

    addTestDex();
}複製程式碼

如果dex檔案沒有改變，直接返回。

private void generatePatchInfoFile() throws IOException {
    generatePatchedDexInfoFile();

    logDexesToDexMeta();

    checkCrossDexMovingClasses();
}複製程式碼

主要看generatePatchedDexInfoFile


private void generatePatchedDexInfoFile() {
    // Generate dex diff out and full patched dex if a pair of dex is different.
    for (AbstractMap.SimpleEntry<File, File> oldAndNewDexFilePair : oldAndNewDexFilePairList) {
        File oldFile = oldAndNewDexFilePair.getKey();
        File newFile = oldAndNewDexFilePair.getValue();
        final String dexName = getRelativeDexName(oldFile, newFile);
        RelatedInfo relatedInfo = dexNameToRelatedInfoMap.get(dexName);
        if (!relatedInfo.oldMd5.equals(relatedInfo.newMd5)) {
            diffDexPairAndFillRelatedInfo(oldFile, newFile, relatedInfo);
        } else {
            // In this case newDexFile is the same as oldDexFile, but we still
            // need to treat it as patched dex file so that the SmallPatchGenerator
            // can analyze which class of this dex should be kept in small patch.
            relatedInfo.newOrFullPatchedFile = newFile;
            relatedInfo.newOrFullPatchedMd5 = relatedInfo.newMd5;
        }
    }
}複製程式碼

oldAndNewDexFilePairList中記錄了兩個dex檔案，然後根據dex file獲取到dexName，再由dexNameToRelatedInfoMap根據name獲得到RelatedInfo。

RelatedInfo中包含了兩個dex file的md5，如果不同，則執行diffDexPairAndFillRelatedInfo。

private void diffDexPairAndFillRelatedInfo(File oldDexFile, 
                        File newDexFile, RelatedInfo relatedInfo) {
    //outputs/tempPatchedDexes
    File tempFullPatchDexPath = new File(config.mOutFolder 
                + File.separator + TypedValue.DEX_TEMP_PATCH_DIR);
    final String dexName = getRelativeDexName(oldDexFile, newDexFile);

    File dexDiffOut = getOutputPath(newDexFile).toFile();
    ensureDirectoryExist(dexDiffOut.getParentFile());


    // dex diff , 去除loader classes
    DexPatchGenerator dexPatchGen = new DexPatchGenerator(oldDexFile, newDexFile);
    dexPatchGen.setAdditionalRemovingClassPatterns(config.mDexLoaderPattern);

    dexPatchGen.executeAndSaveTo(dexDiffOut);


    relatedInfo.dexDiffFile = dexDiffOut;
    relatedInfo.dexDiffMd5 = MD5.getMD5(dexDiffOut);

    File tempFullPatchedDexFile = new File(tempFullPatchDexPath, dexName);

    try {
        new DexPatchApplier(oldDexFile, dexDiffOut).executeAndSaveTo(tempFullPatchedDexFile);

        Logger.d(
                String.format("Verifying if patched new dex is logically the same as original new dex: %s ...", getRelativeStringBy(newDexFile, config.mTempUnzipNewDir))
        );

        Dex origNewDex = new Dex(newDexFile);
        Dex patchedNewDex = new Dex(tempFullPatchedDexFile);
        checkDexChange(origNewDex, patchedNewDex);

        relatedInfo.newOrFullPatchedFile = tempFullPatchedDexFile;
        relatedInfo.newOrFullPatchedMd5 = MD5.getMD5(tempFullPatchedDexFile);
    } catch (Exception e) {
        e.printStackTrace();
        throw new TinkerPatchException(
                "Failed to generate temporary patched dex, which makes MD5 generating procedure of new dex failed, either.", e
        );
    }

    if (!tempFullPatchedDexFile.exists()) {
        throw new TinkerPatchException("can not find the temporary full patched dex file:" + tempFullPatchedDexFile.getAbsolutePath());
    }
    Logger.d("\nGen %s for dalvik full dex file:%s, size:%d, md5:%s", dexName, tempFullPatchedDexFile.getAbsolutePath(), tempFullPatchedDexFile.length(), relatedInfo.newOrFullPatchedMd5);
}複製程式碼

開始針對兩個dex檔案做dex diff，最終將生成的patch 檔案放置在目標資料夾中。

接下來，生成一個臨時資料夾，通過DexPatchApplier針對生成的patch檔案和old dex file，直接做了合併操作，相當於在本地模擬執行了在客戶端上的patch操作。

然後再對新合併生成的patchedNewDex與之前的origNewDex，進行了checkDexChange，即這兩者類級別對比，應該所有的類都相同。

最後在dexDecoder的onAllPatchesEnd中還執行了一個addTestDex

private void addTestDex() throws IOException {
    //write test dex
    String dexMode = "jar";
    if (config.mDexRaw) {
        dexMode = "raw";
    }

    final InputStream is = DexDiffDecoder.class.getResourceAsStream("/" + TEST_DEX_NAME);
    String md5 = MD5.getMD5(is, 1024);
    is.close();

    String meta = TEST_DEX_NAME + "," + "" + "," + md5 + "," + md5 + "," + 0 + "," + 0 + "," + dexMode;

    File dest = new File(config.mTempResultDir + "/" + TEST_DEX_NAME);
    FileOperation.copyResourceUsingStream(TEST_DEX_NAME, dest);
    Logger.d("\nAdd test install result dex: %s, size:%d", dest.getAbsolutePath(), dest.length());
    Logger.d("DexDecoder:write test dex meta file data: %s", meta);

    metaWriter.writeLineToInfoFile(meta);
}複製程式碼

copy了一個test.dex檔案至目標資料夾，該檔案儲存在tinker-patch-lib的resources資料夾下，主要用於在app上進行測試。

完成了所有的diff工作後，後面就是生成patch檔案了。

（2）打包所有生成的patch檔案

//build patch
PatchBuilder builder = new PatchBuilder(config);
builder.buildPatch();複製程式碼

詳細程式碼：

public PatchBuilder(Configuration config) {
    this.config = config;
    this.unSignedApk = new File(config.mOutFolder, PATCH_NAME + "_unsigned.apk");
    this.signedApk = new File(config.mOutFolder, PATCH_NAME + "_signed.apk");
    this.signedWith7ZipApk = new File(config.mOutFolder, PATCH_NAME + "_signed_7zip.apk");
    this.sevenZipOutPutDir = new File(config.mOutFolder, TypedValue.OUT_7ZIP_FILE_PATH);
}

public void buildPatch() throws Exception {
    final File resultDir = config.mTempResultDir;
    //no file change
    if (resultDir.listFiles().length == 0) {
        return;
    }
generateUnsignedApk(unSignedApk);
    signApk(unSignedApk, signedApk);

    use7zApk(signedApk, signedWith7ZipApk, sevenZipOutPutDir);

    if (!signedApk.exists()) {
        Logger.e("Result: final unsigned patch result: %s, size=%d", unSignedApk.getAbsolutePath(), unSignedApk.length());
    } else {
        long length = signedApk.length();
        Logger.e("Result: final signed patch result: %s, size=%d", signedApk.getAbsolutePath(), length);
        if (signedWith7ZipApk.exists()) {
            long length7zip = signedWith7ZipApk.length();
            Logger.e("Result: final signed with 7zip patch result: %s, size=%d", signedWith7ZipApk.getAbsolutePath(), length7zip);
            if (length7zip > length) {
                Logger.e("Warning: %s is bigger than %s %d byte, you should choose %s at these time!",
                    signedWith7ZipApk.getName(),
                    signedApk.getName(),
                    (length7zip - length),
                    signedApk.getName());
            }
        }
    }

}複製程式碼

主要會生成3個檔案：unSignedApk，signedApk以及signedWith7ZipApk。

unSignedApk只要將tinker_result中的檔案壓縮到一個壓縮包即可。
signedApk將unSignedApk使用jarsigner進行簽名。

signedWith7ZipApk主要是對signedApk進行解壓再做sevenZip壓縮。

好了，到此茫茫長的文章就結束啦~~~

受限於本人知識，文中難免出現錯誤，可以直接留言指出。

九、總結

一直關注tinker的更新，也在專案中對tinker進行了使用與定製，tinker中包含了大量的可學習的知識，專案本身在也具有非常強的價值。

對於tinker的“技術的初心與堅持”一文感觸頗深，希望tinker越來越好~

可以閱讀以下文章，繼續瞭解tinker~~

支援我的話可以關注下我的公眾號，每天都會推送新知識~

歡迎關注我的微信公眾號：hongyangAndroid
（可以給我留言你想學習的文章，支援投稿）

Android熱修復之Tinker整合最新詳解
2019-04-02
Android
Android進階之Walle多渠道打包&Tinker熱修復
2019-03-26
Android
簡單易懂的tinker熱修復原理分析
2018-08-03
【Android 熱修復】美團Robust熱修復框架原理解析
2021-10-08
Android框架
2018深入解析Android熱修復技術
2018-11-15
Android
Android 熱修復
2018-12-26
Android
capt 與 Android Gradle Plugin
2019-01-07
APTAndroidGradlePlugin
Android熱修復原理
2019-05-05
Android
Android熱修復原理（一）熱修復框架對比和程式碼修復
2018-03-13
Android框架
Flutter Android 端熱修復（熱更新）實踐
2019-10-31
FlutterAndroid
Android熱修復簡單總結
2019-02-18
Android
修復Gradle CreateProcess error=206
2019-01-21
GradleError
深入探索Android熱修復技術原理讀書筆記 —— 程式碼熱修復技術
2021-05-08
Android筆記
深入探索Android熱修復技術原理讀書筆記 —— 資源熱修復技術
2021-05-11
Android筆記
深入探索Android熱修復技術原理讀書筆記 —— 熱修復技術介紹
2021-05-06
Android筆記
Android每週一輪子：Nvwa（熱修復）
2018-04-19
Android
Android熱修復(Hot Fix)案例全剖析（一）
2021-09-09
Android
【Android 修煉手冊】Gradle 篇 -- Gradle 的基本使用
2019-05-09
AndroidGradle
Gradle 自定義 plugin
2019-04-28
GradlePlugin
筆記深入探索Android熱修復技術原理
2019-02-27
筆記Android
Android進階（八）熱修復基本原理
2019-02-15
Android
flutter在android端啟動流程和熱修復
2021-03-10
FlutterAndroid
解決Android Studio每次匯入專案都會下載Gradle和Android Gradle plugin的問題
2024-08-15
AndroidGradlePlugin
寫給 Android 開發者的 Gradle 系列（三）撰寫 plugin
2018-05-21
AndroidGradlePlugin
手把手帶你打造一個 Android 熱修復框架
2019-01-11
Android框架
robust 熱修復實踐
2018-06-29
自定義Gradle-Plugin 外掛
2019-03-04
GradlePlugin
Robust 2.0：支援Android R8的升級版熱修復框架
2023-05-20
Android框架
熱修復和外掛化
2018-07-31
淺析“熱更新”（熱修復）解決方案
2018-11-30
Gradle入門系列(五)——Gradle其它模組與Plugin外掛
2019-01-05
GradlePlugin
熱修復與外掛化基礎——Java與Android虛擬機器
2018-05-13
JavaAndroid虛擬機
寫給 Android 開發者的 Gradle 系列（四）plugin 實戰包體積瘦身
2018-05-27
AndroidGradlePlugin
熱修復與外掛化基礎——Java與Android的類載入器
2018-05-17
JavaAndroid
手動實現最簡單的Android熱修復（最新最全詳細小白教程）
2018-07-14
Android
Android 修圖（換證件照背景，汙點修復）
2019-09-11
Android
Gradle系列之Android Gradle基礎配置
2020-09-17
GradleAndroid
android Gradle錯(一)
2018-11-22
AndroidGradle
Android Gradle外掛
2021-06-22
AndroidGradle