tinker使用

1.從github上下載tinker的demo

2.同步gradle

如果報錯 Error:(28, 0) Cause: can't get git rev, you should add git to system path or just input test value, such as 'testTinkerId'

是提示你沒有設定tinker的id。

解決方法：

1.給專案加一個git。

2.設定一個thinkerId,在下面程式碼上給一個thinkerID ，String gitRev = “testTinkerId”(id取值需謹慎，後面會介紹id的作用)

def gitSha() {
try {
String gitRev = 'git rev-parse --short HEAD'.execute(null, project.rootDir).text.trim()
if (gitRev == null) {
throw new GradleException("can't get git rev, you should add git to system path or just input test value, such as 'testTinkerId'")
}
return gitRev
} catch (Exception e) {
throw new GradleException("can't get git rev, you should add git to system path or just input test value, such as 'testTinkerId'")
}
}
 

然後再同步一下，應該沒問題了。

TinkerId的官方定義：
tinkerId是用了區分基準安裝包的，我們需要嚴格保證一個基準包的唯一性。在設計的初期，我們使用的是基準包的CentralDirectory的CRC，但某些APP為了生成渠道包會對安裝包重新打包，導致不同的渠道包的CentralDirectory並不一致。

編譯補丁包時，我們會自動讀取基準包AndroidManifest的tinkerId作為package_meta.txt中的TINKER_ID。將本次編譯傳入的tinkerId, 作為package_meta.txt中的NEW_TINKER_ID。當前NEW_TINKER_ID並沒有被使用到，只是保留作為配置項。如果我們使用git rev作為tinkerid, 這時只要使用git diff TINKER_ID NEW_TINKER_ID即可獲得所有的程式碼差異。

我們需要保證tinkerId一定是要唯一性的，這裡推薦使用git rev或者svn rev. 如果我們升級了客戶端版本，但tinkerId與舊版本相同，會導致可能會載入舊版本的補丁。這裡我們一定要注意，升級可客戶端版本，需要更新tinkerId!

3.簽名打包

studio –> Build –> Generate signed APK

注意，簽名檔案選擇gradle裡面配置簽名檔案！在tinker-sample-android\app\keystore資料夾下

signingConfigs {
    release {
        try {
            storeFile file("./keystore/release.keystore")
            storePassword "testres"
            keyAlias "testres"
            keyPassword "testres"
        } catch (ex) {
            throw new InvalidUserDataException(ex.toString())
        }
    }

    debug {
        storeFile file("./keystore/debug.keystore")
    }
}

按照指示簽名打包完畢。這時你的專案中會有剛剛打包生成的apk檔案和一個xxx-R.txt檔案(打包release版本的還會多一個xxxx-mapping.txt檔案) 路徑 app//build//bakApk

將apk檔案安裝到手機。

至此，apk已經安裝到手機。這便是基準apk

4.修改對比編譯

這時我們需要修改基準apk檔案的內容，比如修改某個按鈕的欄位，或是新增一些view（暫不支援新增四大元件）。

然後將路徑app//build//bakApk下的apk檔名複製到tinkerOldApkPath，R.txt複製到tinkerApplyResourcePath，如果是release版本還需將mapping.txt複製到tinkerApplyMappingPath

ext {
//for some reason, you may want to ignore tinkerBuild, such as instant run debug build?
tinkerEnabled = true

//for normal build
//old apk file to build patch apk
tinkerOldApkPath = "${bakPath}/xxxx.apk"
//proguard mapping file to build patch apk
tinkerApplyMappingPath = "${bakPath}/"
//resource R.txt to build patch apk, must input if there is resource changed
tinkerApplyResourcePath = "${bakPath}/xxxx-R.txt"

//only use for build all flavor, if not, just ignore this field
tinkerBuildFlavorDirectory = "${bakPath}/app-1018-17-32-47"
}

然後在studio右上角的gradle裡面找到tinker下面的 tinkerPatchDebug （如果之前簽名是release的，那麼這裡選擇tinkerPatchRelease）

等待編譯完成，會在 app//build//outputs 下生成tinkerPatch資料夾，裡面能找到 patch_signed_7zip.apk檔案。這便是 基準apk包和新apk包的差異檔案補丁。

將patch_signed_7zip.apk拷到手機的根目錄（在demo的MainActivity裡面定義了檔名和位置，自己看看程式碼）。

5.合併差異

demo應用裡面點選第一個按鈕 load patch，如果 toast顯示 patch success, please restart process。點選KILL SELF，在開啟應用，就會發現新修改的欄位新增的view就已經修復好了。

如果toast提示 patch fail, please check reason。這時就需要找問題了。

開啟Android Monitor,檢視LOAD PATCH時的log資訊。 Regex 左邊的篩選輸入 tinker，右邊的選項選擇 No Filters。

自己檢視log資訊，如果log報錯說簽名有問題，那是因為兩次簽名不一致導致的。確認步驟3裡面是否使用了demo給的簽名檔案。如果還是不行，自己配置新的簽名檔案吧。

其他的問題我再沒有遇到了。如果有遇到問題，不要急躁，再多找找原因，log資訊很重要，找到錯誤原因，自己動手解決要比伸手問人爽多了。不鼓勵伸手黨。

至此tinker的demo使用完成。

使用demo時暫時遇到這幾點問題。如有其它問題，請指出。