1. 簡介

這是Unity Android APP il2cpp熱更完美解決方案的Demo（Git地址）的說明。

和現有的熱更解決方案不同的是，他不會引入多餘的語言（只是UnityScript，c#…），對Unity程式設計和編碼沒有任何限制。你可以在預置和場景裡的GameObject上新增任何的Compnents元件，需要序列化的和不需要序列化的，他們都是可以熱更的，也不需要做額外的標記處理。簡而言之，在此方案下，Unity的所有資源和指令碼，都是可以熱更的。

本文接下來將介紹如何去製作熱更檔案和如何應用這些熱更檔案。為了簡化Demo的設計，Demo包含的熱更檔案會事先以全量更新的方式製作好，一起打到了Apk裡面。具體到專案中熱更檔案得放伺服器，正式上線得放CDN，以增量更新的方式搗鼓出和文中一樣的目錄結構就OK了。

2. 方案總覽

Unity在以il2cpp方式匯出Android工程（或者Apk檔案）的時候，程式碼會被編譯成libil2cpp，而相關的資源、配置和序列化資料會以他們各自的格式匯出到android的assets目錄（assets/bin/Data）。這兩部分，libil2cpp和assets目錄，必須匹配（即需要在同一次打包中提取，可能有的變了，有的沒變，增量方式只提取變化的部分）才能正常工作，不然Unity會在啟動時崩潰。本方案就是熱更這兩部分。

熱更的正式流程如下圖.

流程說明：

• 步驟1，在Unity的邏輯之前，libbootstrap會檢查本地是否有Patch. Apk安裝後，沒應用過任何熱更，本地是不會有Patch檔案的，走no流程。如果熱更過，則會有Patch目錄，走yes流程。Patch目錄如何準備，後面會將到。

• 步驟2，載入Patch目錄對應架構（arm/x86）的libil2cpp庫，並應用assets目錄的更新檔案。

• 步驟3，開始Unity的流程，進入Unity第一個場景，並執行相關的Unity Script，一般是C#，我們都以C#舉例。

• 步驟4，檢查服務端是否有新的patch，這步demo沒有演示，需要自己實現。

• 步驟5，下載新的patch，這步demo也沒有演示，需要自己實現

• 步驟6，根據規則準備patch目錄，詳細規則會在後面描述。在Demo中只是將全量更新包解壓，全量更新包打包的時候目錄結構就是對的，所以不需要做其他的處理。

• 步驟7，呼叫libbootstrap的介面設定patch目錄，因為libil2cpp已經載入進程序，所以需要重啟APP，從新的patch目錄載入patch。這步Demo中有設定patch目錄的例子。

• 步驟8，重啟APP，Demo提供了純C#程式碼。

• 步驟9，沒有新的Patch，就正常進入遊戲了。

流程裡更詳細的描述和如何生成Patch檔案，見第三章。

3. Demo詳述

3.1. Demo目錄結構

工程所有檔案均置於AndroidIl2cppPatchDemo目錄下。各檔案目錄說明如下表。

所有檔案就這麼多，專案用git管理，master分支為母包分支，version1和version2分支為熱更1和熱更2分支，分支間會有些細微的差別，version1主要測試序列化資料，version2添加了新場景和新指令碼，具體可以diff檢視。下面會詳細描述打包過程和如何應用熱更檔案。

3.2. 打包過程

所有的打包邏輯在檔案Editor\AndroidBuilder.cs裡。展開主選單AndroidBuilder, 可以看到有5步，為了和熱更啟動流程區分，我們就叫他過程。

• 過程1：以il2cpp的方式，匯出Gradle Android工程。選擇Gradle Android工程，而不是ADT Android工程，只是因為Unity2018不再支援ADT方式。Demo並不依賴AndroidStudio，只是匯出的Android工程目錄結構是以Gradle的方式註釋，之後的構建步驟都是呼叫原始JDK/SDK的方式。Demo這部分的程式碼可以複用，但需要根據專案需求做一些修改。

• 過程2：需要修改一下Android工程，因為libbootstrap需要在進入Unity的幀迴圈前，檢查載入本地準備好的patch。大多數情況，你可以複用這個步驟的程式碼。但是如果你的專案修改了Unity Java的繼承體系，你需要檢查一下這塊程式碼是否有呼叫到。如果沒有呼叫到，後面Unity幀迴圈中的邏輯和資源，用的都是Apk內的相應檔案。

• 過程3：生成熱更檔案。如在第二章所述，patch分為兩部分，il2cpp庫和assets/bin/Data目錄。具體做法程式碼均有提供，需要注意的是必須遵守各個檔案的命名方式和相對路徑。各個檔案均有壓縮，對於增量包，如果壓縮前的檔案和之前相比沒有變化，則不需要製作對應的壓縮檔案。這部分製作壓縮部分的程式碼可複用，增量部分需要自己實現，熱更檔案最好也加進版本管理（svn/git/…）中。

• 過程4: 生成打包的windows指令碼。指令碼僅依賴JDK/SDK命令，可複用。生成指令碼後，Android工程就不依賴Unity了，可以隨意替換檔案，再次呼叫指令碼生成新的Apk。需要注意的是，打包用的so動態庫，是pkg_raw目錄下的so檔案，替換時請注意。首次會在Unity目錄下生成keystore目錄和相應的簽名檔案，可以將此簽名替換，並修改匯出指令碼中的簽名密碼。

• 過程5: 執行過程4中的指令碼，生成Apk安裝檔案，可複用。

主選單AndroidBuilder下還提供了選單“Running Step 1, 2, 4, 5 for the base version”，這是一鍵構建母包版本用的，母包不需要製作patch檔案，所以少了過程3；和選單“Runnnig Step 1-4 for patch versions”，這是一鍵構建Patch用的，因為在demo裡，不需要匯出Apk檔案。

關於打包這裡得多說兩句。 如果沒有采用AssetBundle的方式打包，Unity會按各自格式，將所有場景和依賴輸出到assets/bin/Data目錄，這樣子也是可以熱更的。但是，不要這麼做，因為這樣做微小的改動會影響到多個檔案，導致熱更檔案過大。最好是自己用AssetBundle的方式將資源做一個清晰的劃分，打包好的AssetBundle放在assets下的其他目錄。需要注意和libil2cpp庫和assets/bin/Data的檔案向匹配（保證是同一個版本的輸出）。執行時可以重寫AssetBundleManager.overrideBaseDownloadingURL載入最新的AssetBundle。

3.3. 執行時應用熱更檔案

我們回顧一下第二章的流程圖，結合打包過程和Demo的程式碼，做進一步的說明.

打包過程2裡，在Unity的遊戲邏輯之前，插入了三行Java程式碼。

+        System.loadLibrary("main");
+        System.loadLibrary("unity");
+        System.loadLibrary("bootstrap");
        mUnityPlayer = new UnityPlayer(this);

這三行程式碼保證了上圖中步驟1-2能在步驟3之前執行，下一行mUnityPlayer的程式碼即開始了步驟3的執行。步驟3之後所有的邏輯，都是已熱更過的il2cpp庫裡的Unity Script（c#，…）了。熱更部分的邏輯如果有修改，會在熱更後體現，如果這部分的bug不影響下次熱更，則可以通過熱更修復，否則應指引使用者清除本地資料，以母包熱更邏輯更新到最新。所以，在方案的應用中，仍需儘量保證熱更部分的程式碼穩定，不能隨意更改。

如前所述，Demo裡沒有步驟4和步驟5的相關邏輯，步驟6中Patch的準備，Demo只是簡單地將全量壓縮包解壓，相關邏輯在Script/VersionSettor.cs檔案中。準備更新目錄時，應保證libil2cpp部分被解壓，命名方式和Demo保持一致，而assets_bin_Data下的檔案不需要解壓，應保證目錄結構和Demo保持一致。如果是增量更新，Patch目錄下的檔案應該是相對於母包的修改檔案。在持續熱更中，應保證在步驟7前，本地當前Patch目錄的完整性（保證執行中的App還能正常執行），新的Patch應新建目錄，通過硬連結的形式從當前Patch目錄中提取所需要的沒變化的檔案，準備好後執行步驟7，重啟後將老Patch目錄刪除. 步驟7和步驟8的程式碼也在Script/VersionSettor.cs檔案中，樣子如下

        //4. tell libboostrap.so to use the right patch after reboot
        string error = Bootstrap.use_data_dir(runtimePatchPath);
        if (!string.IsNullOrEmpty(error))
        {
            messageBox.Show("use failed. path:" + zipLibil2cppPath + ", error:" + error, "ok", () => { messageBox.Close(); });
            yield break;
        }

        //5. reboot app
        yield return StartCoroutine(Restart());

4. Verify 和 Build

4.1. Verify

安裝預編譯的Apk檔案，點選按鈕可以切換各個版本。

Apk連結

4.2. Build

依賴

• Unity (我用Unity2017/Unity2018)
• JDK.(我用JDK1.8)
• Android SDK.(我用Android SDK platform 23 和 build tools 26.0.2（低於26.0.2，Unity2018不支援），最好是這兩個版本，不然得重新下載)
• Android NDK r13b. (Unity il2cpp原來只支援這個版本，現在不知道放開沒，反正這個版本沒問題)
• Git

Build指引

• 1. 在Unity中（Edit->Preference->External tools）設定好 JDK/SDK/NDK 路徑，打包程式碼裡會從Unity中讀取。
• 2. 如果你的Android SDK的build tools版本不是26.0.2，需要修改程式碼 AndroidBuilder.cs，第14行.
• 3. 如果你使用的Android platform不是android-23，修改程式碼 AndroidBuilder.cs，第15行.
• 4. 出母包，執行選單 AndroidBuilder->Run Step 1, 2, 4, 5 for base version, 成功後會彈出檔案管理器顯示apk所在的目錄.
• 5. 一般來說你不需要打Patch檔案，如果要打，用git checkout version1或version2，執行選單 AndroidBuilder->Run Step 1-4 for Patch Version。PrebuildPatches目錄下的相應檔案會被更新。

5. 剩下的工作和建議

打包部分

• 設定部分需要根據專案實際做修改。
• 熱更檔案的增量版本化管理。

執行時部分

• 檢查新版本和下載熱更檔案。
• 持續增量更新的Patch目錄的準備。
• 用Asset Bundle管理資源。

另外，打包的工作儘量自動的一鍵化，一次化，除非你想在打包當晚集體晒月亮。另外，低成本的打包流程，大家都願意在真機上看結果，利於產品的穩定。Demo其實提供了一套自動化的框架和指令碼，理解透，化為己用，也是幸事一件。如果有更好的方式，歡迎討論。