2. 程式人生 > >Android熱更新Tinker + 多渠道打包 + 加固的流程詳解

Android熱更新Tinker + 多渠道打包 + 加固的流程詳解

阿新 • • 發佈：2019-01-02

一、Tinker熱修復

關於熱修復的作用，不用多說了，一句話概括就是通過讓使用者無感的方式來修復線上應用的bug。這裡介紹的是微信Tinker。
下面的接入方式都是參考自Tinker官方文件來。我這裡主要是把我接入的步驟(通過AndroidStudio + gradle方式)說一遍。下面的步驟都是基於tinker-support外掛:1.0.8版本，以及sdk 1.3.1 進行。所以檢視此文時需要參考官方文件是否有更新，避免接入的方式改變導致接入出現問題。Tinker的官方接入指南地址為：https://bugly.qq.com/docs/user-guide/instruction-manual-android-hotfix/?v=20170912151050

1、新增外掛依賴

工程根目錄下“build.gradle”檔案中新增：

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        // tinkersupport外掛, 其中lastest.release指拉取最新版本，也可以指定明確版本號，例如1.0.4
        classpath "com.tencent.bugly:tinker-support:1.0.8"
    }
}

2、整合SDK

gradle配置：
在app module的“build.gradle”檔案中新增（示例配置）：

 android {
        defaultConfig {
          ndk {
            //設定支援的SO庫架構
            abiFilters 'armeabi' //, 'x86', 'armeabi-v7a', 'x86_64', 'arm64-v8a'
          }
        }
      }
      dependencies {
          compile "com.android.support:multidex:1.0.1" // 多dex配置
          //註釋掉原有bugly的倉庫
          //compile 'com.tencent.bugly:crashreport:latest.release'//其中latest.release指代最新版本號，也可以指定明確的版本號，例如2.3.2
 

          compile 'com.tencent.bugly:crashreport_upgrade:1.3.1'
          compile 'com.tencent.bugly:nativecrashreport:latest.release' //其中latest.release指代最新版本號，也可以指定明確的版本號，例如2.2.0
      }

後續更新升級SDK時，只需變更配置指令碼中的版本號即可。

在app module的“build.gradle”檔案中新增：

// 依賴外掛指令碼，平時編寫程式碼的時候這裡其實可以註釋，不然每次build都會生成基準包，只要在打正式包和補丁包的時候放開註釋就好了
apply from: 'tinker-support.gradle'

您需要在同級目錄下建立tinker-support.gradle這個檔案哦。
tinker-support.gradle內容如下所示（示例配置）：

apply plugin: 'com.tencent.bugly.tinker-support'

def bakPath = file("${buildDir}/bakApk/")

/**
 * 此處填寫每次構建生成的基準包目錄
 */
def baseApkDir = "app-0208-15-10-00"

/**
 * 對於外掛各引數的詳細解析請參考
 */
tinkerSupport {

    // 開啟tinker-support外掛，預設值true
    enable = true

    // 指定歸檔目錄，預設值當前module的子目錄tinker
    autoBackupApkDir = "${bakPath}"

    // 是否啟用覆蓋tinkerPatch配置功能，預設值false
    // 開啟後tinkerPatch配置不生效，即無需新增tinkerPatch
    overrideTinkerPatchConfiguration = true

    // 編譯補丁包時，必需指定基線版本的apk，預設值為空
    // 如果為空，則表示不是進行補丁包的編譯
    // @{link tinkerPatch.oldApk }
    baseApk = "${bakPath}/${baseApkDir}/app-release.apk"

    // 對應tinker外掛applyMapping
    baseApkProguardMapping = "${bakPath}/${baseApkDir}/app-release-mapping.txt"

    // 對應tinker外掛applyResourceMapping
    baseApkResourceMapping = "${bakPath}/${baseApkDir}/app-release-R.txt"

    // 構建基準包和補丁包都要指定不同的tinkerId，並且必須保證唯一性
    tinkerId = "base-1.0.1"

    // 構建多渠道補丁時使用
    // buildAllFlavorsDir = "${bakPath}/${baseApkDir}"

    // 是否啟用加固模式，預設為false.(tinker-spport 1.0.7起支援）
    // isProtectedApp = true

    // 是否開啟反射Application模式
    enableProxyApplication = false

}

/**
 * 一般來說,我們無需對下面的引數做任何的修改
 * 對於各引數的詳細介紹請參考:
 * https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97
 */
tinkerPatch {
    //oldApk ="${bakPath}/${appName}/app-release.apk"
    ignoreWarning = false
    useSign = true
    dex {
        dexMode = "jar"
        pattern = ["classes*.dex"]
        loader = []
    }
    lib {
        pattern = ["lib/*/*.so"]
    }

    res {
        pattern = ["res/*", "r/*", "assets/*", "resources.arsc", "AndroidManifest.xml"]
        ignoreChange = []
        largeModSize = 100
    }

    packageConfig {
    }
    sevenZip {
        zipArtifact = "com.tencent.mm:SevenZip:1.1.10"
//        path = "/usr/local/bin/7za"
    }
    buildConfig {
        keepDexApply = false
        //tinkerId = "1.0.1-base"
        //applyMapping = "${bakPath}/${appName}/app-release-mapping.txt" //  可選，設定mapping檔案，建議保持舊apk的proguard混淆方式
        //applyResourceMapping = "${bakPath}/${appName}/app-release-R.txt" // 可選，設定R.txt檔案，通過舊apk檔案保持ResId的分配
    }
}

注意，這裡記得修改為基線版本包名稱的修改。我這裡的基線版本輸出檔名為 ：tinker_demo-release
所以修改為如下：
apk輸出

3、初始化SDK

我這裡使用的是enableProxyApplication = false 的情況 。因為這是Tinker推薦的接入方式，一定程度上會增加接入成本，但具有更好的相容性。true的情況具體看官方文件。
整合Bugly升級SDK之後，我們需要按照以下方式自定義ApplicationLike來實現Application的程式碼（以下是示例）：
自定義Application：

public class SampleApplication extends TinkerApplication {
    public SampleApplication() {
        super(ShareConstants.TINKER_ENABLE_ALL, "xxx.xxx.SampleApplicationLike",
                "com.tencent.tinker.loader.TinkerLoader", false);
    }
}

注意：這個類整合TinkerApplication類，這裡面不做任何操作，所有Application的程式碼都會放到ApplicationLike繼承類當中
引數解析
引數1：tinkerFlags 表示Tinker支援的型別 dex only、library only or all suuport，default: TINKER_ENABLE_ALL
引數2：delegateClassName Application代理類 這裡填寫你自定義的ApplicationLike
引數3：loaderClassName Tinker的載入器，使用預設即可
引數4：tinkerLoadVerifyFlag 載入dex或者lib是否驗證md5，預設為false

然後記得在manifest檔案中修改為自定義的Application：

application

自定義ApplicationLike，我們只需把下面的程式碼拷貝到我們的專案中就可以了，記得修改onCreate方法中的Bugly.init()中的key：

public class SampleApplicationLike extends DefaultApplicationLike {

    public static final String TAG = "Tinker.SampleApplicationLike";

    public SampleApplicationLike(Application application, int tinkerFlags,
            boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime,
            long applicationStartMillisTime, Intent tinkerResultIntent) {
        super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
    }


    @Override
    public void onCreate() {
        super.onCreate();
        // 這裡實現SDK初始化，appId替換成你的在Bugly平臺申請的appId
        // 除錯時，將第三個引數改為true
        Bugly.init(getApplication(), "0123456789", false);
    }


    @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    @Override
    public void onBaseContextAttached(Context base) {
        super.onBaseContextAttached(base);
        // you must install multiDex whatever tinker is installed!
        MultiDex.install(base);

        // 安裝tinker
        // TinkerManager.installTinker(this); 替換成下面Bugly提供的方法
        Beta.installTinker(this);
    }

    @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    public void registerActivityLifecycleCallback(Application.ActivityLifecycleCallbacks callbacks) {
        getApplication().registerActivityLifecycleCallbacks(callbacks);
    }

}

注意：tinker需要你開啟MultiDex,你需要在dependencies中進行配置compile “com.android.support:multidex:1.0.1”才可以使用MultiDex.install方法； SampleApplicationLike這個類是Application的代理類，以前所有在Application的實現必須要全部拷貝到這裡，在onCreate方法呼叫SDK的初始化方法，在onBaseContextAttached中呼叫Beta.installTinker(this);。

在此，Tinker的接入已經完成，是不是比想象中簡單多了簡單。

4、使用

打正式包：

首先打正式包前，記得修改tinker-support.gradle檔案中的tinkerId：
tinkerId最好是一個唯一標識，例如git版本號、versionName等等。 如果你要測試熱更新，你需要對基線版本進行聯網上報。
這裡強調一下，基線版本配置一個唯一的tinkerId，而這個基線版本能夠應用補丁的前提是整合過熱更新SDK，並啟動上報過聯網，這樣我們後臺會將這個tinkerId對應到一個目標版本，例如tinkerId = “bugly_1.0.0” 對應了一個目標版本是1.0.0，基於這個版本打的補丁包就能匹配到目標版本。
tinkerId

然後通過gradle進行打包：
assemableRealease

然後會在tinkerSupport.gradle上配置的路徑輸出基線包，我這裡是：build檔案下的baseApk下：

在此我們需要記得儲存好基線包資料夾以及基線包的TinkerId（補丁包與根據基線包TinkerId進行匹配，所以TinkerId一般使用版本號來標識）。

baseApk

好了，我們把這基線包釋出到bugly平臺上即可：

release

打補丁包：
那現在剛剛釋出線上的應用有問題了，那我們首先在基線包的程式碼上進行程式碼的修復，然後進行打補丁包進行修復了。
首先，修改tinkersuppor.gradle裡面的baseApkDir配置，就是上面打基線包生成的以時間戳命名的資料夾名稱：
1

然後再修改tinkerId:
2

然後通過gradle進行打補丁包:
3

最後會在配置的指定檔案下生成補丁包檔案：
4

然後我們把上面的 patch_signed_7zip.apk檔案上傳到bugly分發即可：
5

連線手機除錯檢視log，如果列印以下log證明補丁包已經下載成功：
6

列印以下log證明 補丁包已經合併到手機的應用中：
7

至此bug修復完成。

5、問題：

1）、有人在寫Demo測試時，把基準包上傳了，補丁包上傳時出了未匹配到可應用的App版本的報錯。
8

那是因為我們的基準包雖然已經上傳了，但是還沒有一部手機安裝使用並上報聯網。所以Bugly的後臺伺服器找不到對應要下發的App版本，所以導致了該錯誤。
解決方案是，用手機安裝一次基準包，檢視log有以下列印，證明聯網上報成功，然後在重新發布一下補丁包就不會出現以上問題了。
9

2 )、怎樣去測試我這個補丁包能否正常使用，而且先不下發給所有使用者?
那這時就要使用開發裝置進行測試了。
10

我們在釋出新補丁時有個開發裝置可以選擇，我們可以通過Bugly.setIsDevelopmentDevice(getApplication(), true);方法設定為開發者裝置吶？而且需要在打基準包時就需要設定好。
那這時會有人疑問要去修改線上的基準包？這不實際吧，而且也做不了啊。
那怎麼辦呢？
首先 我們在線上版本的程式碼（每次上線前要利用git去保留一個線上版本的分支）上新增設定為開發者裝置的程式碼，然後重新進行打基準包的操作(記得： tinkerId 和線上版本的一致)，把這個基準包安裝到測試手機上（注意不是上傳到bugly）。
然後我們再進行程式碼的修復，打補丁包。把補丁包上傳到bugly，設定為開發裝置。然後我們在重新退出再開啟測試機上的應用，檢視日誌，列印如下表明補丁包已經分發合併到當前測試手機的應用上。而線上的使用者是接收不了的。
最後我們已經確保這補丁包沒問題了，我們要把這補丁包分發給所有使用者。那我們就可以再bugly平臺上重新編輯補丁包的下發設定為全部裝置即可。

11

到此，我們的Tinker熱更新接入和使用已經完成。

二、 多渠道打包 + 加固。

關於為什麼要進行多渠道打包的問題，相信大家都清除，就是為了方便統計更清楚地和了解應用在各應用市場的分佈情況，便於產品和運營做一些針對性的產品運營推廣方案。
Android原生是提供了一套多渠道打包的方案給開發者的，然後也有很多其它第三方也提供了打渠道包的方案，比如熱門的美團walle打包，360打包工具等。
那我們就針對這幾種打包方案結合Tinker熱修復的接入進行分析：

1、Android原生的多渠道打包：

12

Android原生的多渠道打包是通過再gradle檔案中新增productFloavors配置，實現大渠道打包的。

但是這種方案有很多缺點。首先就是它打包速度很慢，每打一個包都要重新編譯一次。假如我打一個包要3分鐘，那我打10個渠道包，就要30分鐘。假如中間有一些問題又需要重新進行打包，那不就是一個坑爹的過程？

而另一方面，因為這種方式，會修改buildConfig類中的FLAVOR欄位， 會使得我們的每個安裝包的dex檔案都是不一樣的，那使用Tinker熱修復打的補丁包就要針對具體的渠道進行打補丁。假如我有10個渠道包，那就要針對這10個渠道包打10個補丁包，那是一個更坑爹的過程，老闆高薪請你來打包的，內心慚愧啊。那就算你耐得住打包這寂寞過程，buly也是隻允許同時下發5個版本的補丁。所以這個方式是不實際的。

美團的walle打包方案是基於Android Signature V2 Schme 簽名下的新一代渠道包打包神器，它通過在Apk中的APK SignNature Block 區塊新增自定義的渠道資訊來生成渠道包，從而提高了渠道包的生成效率。也就是說它只是編譯打包一次，然後每個渠道複製一次再往裡面新增渠道資訊而已。所以這個過程就算打100個包，速度也是非常快的。
walle有兩種整合方式，一種是通過gradle進行整合，一種是通過命令列工具使用方式（https://github.com/Meituan-Dianping/walle/blob/master/walle-cli/README.md）
這裡介紹gradle整合方式：

配置build.gradle
在位於專案的根目錄 build.gradle 檔案中新增Walle Gradle外掛的依賴， 如下：

buildscript {
    dependencies {
        classpath 'com.meituan.android.walle:plugin:1.1.6'
    }
}
並在當前App的 build.gradle 檔案中apply這個外掛，並新增上用於讀取渠道號的arr包
apply plugin: 'walle'

dependencies {
    compile 'com.meituan.android.walle:library:1.1.6'
}
並在當前App的 build.gradle 檔案上配置外掛，預設就行不用改：
walle {
    // 指定渠道包的輸出路徑
    apkOutputFolder = new File("${project.buildDir}/outputs/channels");
    // 定製渠道包的APK的檔名稱
    apkFileNameFormat = '${appName}-${packageName}-${channel}-${buildType}-v${versionName}-${versionCode}-${buildTime}.apk';
    // 渠道配置檔案
    channelFile = new File("${project.getProjectDir()}/channel")
}

建立一個名為channel的txt檔案，配置渠道資訊：
15

16
然後就在程式碼中可以通過以下方式獲取渠道資訊並上傳給對應的統計平臺：

String channel = WalleChannelReader.getChannel(this.getApplicationContext());

打渠道包的過程也很簡單：
就是控制檯下的Terminal通過gradle的命令進行打包： gradlew clean assembleReleaseChannels
17

輸出路徑如下：
18

然後我們打補丁包的過程仍然是原來的過程進行。

我們來測試一下：

19
安裝到手機，正常獲取到渠道資訊：
20

那我們來試試把這些渠道包進行加固，就用360加固重簽名之後再安裝試試：

21

但是這種方式感覺不夠直接，有沒有更好的方案吶?有的，往下看。

3、360多渠道打包 + 360加固。

首先，我們需要下載最新的360加固助手，登入賬戶。

23

簽名配置：
24

多渠道配置：
25

配置好之後，我們只需在加固應用介面，選擇需要的應用進行加固，它就會自動進行加固，然後打渠道包，再進行重簽名。然後輸出到指定的資料夾，全程自動化操作，而且過程非常快。一個字：爽！

26

27

這個過程僅需在tinkerSupport.gradle中修改isProtectedApp = true欄位，然後打好基準包然後用加固助手進行自動化操作即可。

這時我們先來看看專案中的manifest檔案：
28

再來看看打包之後應用寶渠道的manifest檔案：
29

可以看到通過360加固助手的多渠道打包，根據對應的統計平臺插入了各個渠道的資訊。

三、總結。

說了那麼多，其實在最終的建議方案就是 先接入Tinker熱更新，然後打基準包，利用.360加固助手進行加固打渠道包在重簽名。上傳其中一個渠道包到bugly平臺上。當有bug時，在基準包基礎上打補丁包，把補丁包上傳到bugly平臺即可。

13

相關推薦

Android熱更新Tinker + 多渠道打包 + 加固的流程詳解

一、Tinker熱修復 關於熱修復的作用，不用多說了，一句話概括就是通過讓使用者無感的方式來修復線上應用的bug。這裡介紹的是微信Tinker。 下面的接入方式都是參考自Tinker官方文件來。我這裡主要是把我接入的步驟(通過AndroidStudio +

微信Android熱更新Tinker使用詳解（by 星空武哥）

Tinker是什麼 Tinker是微信官方的Android熱補丁解決方案，它支援動態下發程式碼、So庫以及資源，讓應用能夠在不需要重新安裝的情況下實現更新。當然，你也可以使用Tinker來更新你的外掛。 它主要包括以下幾個部分： gradle編譯外掛: tinker

Android 6.0許可權機制及開發流程詳解

許可權機制變更的背景 在Android6.0之前，app在安裝時會提示使用者此app需要使用哪些許可權，但使用者只能選擇同意或拒絕安裝，而不能單獨對某項許可權進行授予或拒絕。只要使用者選擇了安裝，即表示使用者接受了app對這些許可權的使用，如果使用者不希望app獲取某些涉及隱

Android之Android 6.0許可權機制及開發流程詳解

許可權機制變更的背景 在Android6.0之前，app安裝時會提示使用者此app需要使用哪些許可權，但使用者不能單獨對某項許可權進行授權或拒絕，只要使用者選擇了安裝，即表示使用者接受了app對這些許可權的使用，如果使用者不希望app獲取某些涉及隱私的資訊，例如讀取

Android熱更新技術——Tinker、nuwa、AndFix、Dexposed

一、熱修復技術作用 　　線上app BUG緊急修復，不重新發版，不重新安裝，線上遠端修復問題 二、侷限性與適用場景 補丁只能針對單一客戶端版本，隨著版本差異變大補丁體積也會增大； 補丁不能支援所有的修改，例如AndroidManifest； 補丁無論對程式碼還是資源的更新成功率都無法達到1

Android熱更新：微信Tinker框架的接入與測試

轉載於:http://www.jianshu.com/p/aadcf2ea69a6 Android熱修復框架的對比（最終選擇微信Tinker） Android熱修復框架的對比 AndFix作為native解決方案，首先面臨的是穩定性與相容性問題，更重要的是它無法實現類替換，它是需要大量額外的開發成本的；

bugly整合Tinker熱修復，多渠道打包 簽名

自己記錄一下，對其他人有幫助更好 https://mp.weixin.qq.com/s/1kRTqyF4JC5lLwpxUae9NA   （感謝分享） 在這裡面使用的是博主說的第二種方式  快速打渠道包工具（Gradle）  walle 然後在git上找到 walle的專案

Android熱更新開源專案Tinker原始碼解析系列之一：Dex熱更新

Tinker是微信的第一個開源專案，主要用於安卓應用bug的熱修復和功能的迭代。 Tinker github地址：https://github.com/Tencent/tinker 首先向微信致敬，感謝毫無保留的開源出了這麼一款優秀的熱更新專案。

站在巨人的肩上——Android熱更新框架Tinker探索之旅

參考資料： 1.Tinker 2.Android 熱修復 Tinker接入及原始碼淺析 如果大家對tinker比較陌生，請先去看看tinker的wiki和鴻洋_大神的這篇文章 現在比較流行的熱修復框架的優缺點和特色，在Tinker的wiki下都可

關於tinker 熱修復的多渠道打包方式

上篇部落格介紹了tinker 熱修復的接入的問題[http://blog.csdn.net/qq1221jyj/article/details/73743612] 當接入成功後，專案又做了多渠道的東西。難道要一個渠道對應一個補丁包嗎？那哪哪哪 ～～簡直開玩笑。

Android 熱修復 Tinker接入及源碼淺析

uil obj 安全 Language num sse b2c rom 其中 一、概述 放了一個大長假，happy，先祝大家2017年笑口常開。 假期中一行代碼沒寫，但是想著馬上要上班了，趕緊寫篇博客回顧下技能，於是便有了本文。 熱修復這項技術，基本上已經成為項目比較

Android熱更新技術的研究與實現(二)

Sophix—阿里終極熱修復方案 不過阿里作為大廠咋可能沒有個自己的熱更新框架呢，所以阿里爸爸最近還是做了一個新的熱更新框架SopHix 巴巴再次證明我是最強的，誰都沒我厲害！！！因為我啥都支援，而且沒缺點。。簡直就是無懈可擊！ 那麼我們就來專案整合下

android 熱更新

熱更新的產生 線上版本出現嚴重的bug，需要重新發版。熱更新能快速的解決線上問題，不需要重新發版。 熱更新流程 線上檢測到嚴重的crash 拉出一個新的分支來修復線上問題 開發人員自測，專案測試人員測試，然後jenkins構建和補丁生成 app通過

Android熱更新方案Robust

美團•大眾點評是中國最大的O2O交易平臺，目前已擁有近6億使用者，合作各類商戶達432萬，訂單峰值突破1150萬單。美團App是平臺主要的入口之一，O2O交易場景的複雜性決定了App穩定性要達到近乎苛刻的要求。使用者到店消費買優惠券時死活下不了單，定外賣一個明顯可用的紅包怎麼

關於 android 熱更新的討論方案

Android 不僅系統版本眾多，機型眾多，而且各個市場都各有各的政策和稽核速度，每次釋出一個版本對於開發同學來講都是一種漫長的煎熬。相比於 iOS 兩三天就能達到 80% 的覆蓋速度而言，Android 應用版本升級至少需要兩週才能達到 80% 的升級率，嚴重

由Sophix引發的Android熱更新底層原理探索

移動網際網路市場日趨成熟，移動產品研發進入平穩發展階段，這意味著開發者的思維和研發模式也應轉入下半程。安全領域技術在開發中的應用一直是作業系統平臺發展週期中的重要一環。熱修復，作為安全領域技術的衍生品，自2016年開始，持續受到關注，並不斷演進。        2016年上半年，為了提升產品在敏捷開發下的最佳

Android熱更新簡介

上面分析了Android中的類的載入的流程，可以看出來DexPathList物件中的dexElements列表是類載入的一個核心，一個類如果能被成功載入，那麼它的dex一定會出現在dexElements所對應的dex檔案中，並且dexElements中出現的順序也很重要，在dexElements前面出現的de

android熱更新之Bugly

有一段時間沒有更新部落格了，主要是快畢業了，出來實習找工作，現在在一家公司做安卓，今天是上班的第三天，前兩天瞭解了一下專案，現在專案需要增加熱更新方案，於是我研究了一下市場上的開源方案，今天注重講一下騰訊的bugly。（本文只是對bugly的大致流程進行梳理，並

Bugly Android熱更新總結篇

前言 之前發過一篇文章——Bugly熱更新SDK你需要知道的一些事，那是Bugly整合Tinker之後正式釋出的第一個版本—1.2.0，針對我們熱更新能力進行的一些說明，經過之後的版本迭代當中也是不斷的跟進Tinker版本並且不斷優化和簡化開發者的接入，讓開發

unity3d配置Android環境，打包釋出Apk流程詳解

Unity配置Android環境，打包釋出安卓流程 SDK檔案 二、安裝 JDK  執行安裝程式jdk-7u67-windows-x64 Java-JDK 分別點選下一步進行安裝。 安裝中 在安裝過程中先後會出現兩次選擇安裝目錄的介面，如果預設路徑不是以下兩個路徑，全部改為以下路徑，如果