前幾天在一些公眾號中看到這兩個框架，但是沒在意，畢竟我從來沒用過熱修復，因為根本用不到，我們做的外包，只針對一家，出了Bug及時改並且釋出版本（反正是一個沒什麼前途的app），而且合作方 也預設如此，所以從來沒用到過，週日閒的無聊，就先把Sophix看了一下，最終執行成功。
我不說是怎麼整合的，畢竟再怎麼講也講過官方文件還有一些大神的部落格，我只說一下我遇到的問題：

官方文件

想了想，Sophix用起來挺傻瓜式的，沒什麼好講的，開始配置的時候一個App ID，一個App Secret、RSA金鑰他們的位置不好找，在這個位置點選列表的管理就可以看到這三個

在通過新舊包進行對比產生補丁包的時候，我（window版本）只是勾選了日誌，並配置了簽名，正常；
在用官方提供的測試軟體的時候，不管我怎麼輸入包名都沒用，都顯示連線不上，然後我就沒用這個測試軟體，直接上傳補丁後下發，然後正常接收，如果有問題

SophixManager.getInstance().setContext(this)
                .setAppVersion(appVersion)
                .setAesKey(null)
                .setEnableDebug(true)
                .setPatchLoadStatusStub(new PatchLoadStatusListener() {
                    @Override
                    public void onLoad
 
(final int mode, final int code, final String info, final int handlePatchVersion) {
                        // 補丁載入回撥通知
                        if (code == PatchStatus.CODE_LOAD_SUCCESS) {
                            // 表明補丁載入成功
                            Log.e("ccer", "成功");
                        } else
 
 if (code == PatchStatus.CODE_LOAD_RELAUNCH) {
                            // 表明新補丁生效需要重啟. 開發者可提示使用者或者強制重啟;
                            // 建議: 使用者可以監聽進入後臺事件, 然後呼叫killProcessSafely自殺，以此加快應用補丁，詳見1.3.2.3
                            Log.e("ccer", "重啟");
                        } else {
                            // 其它錯誤資訊, 檢視PatchStatus類說明
                            Log.e("ccer", "other"+code);
                        }
                    }
                }).initialize();

可以在最後的else中列印一下code，對比code碼來找原因，這個官方文件有。然後這個沒怎麼費時間就ok了，當然，我沒深入使用，只是簡單的試試效果，還不錯，然後就無意中看到了費用問題。

價格總覽

萬一哪天要是做大了，這也是一大筆錢啊；

走，換一家；

今天看的Bugly，用起來挺頭疼的，開始整合的時候還好，然後到調整出效果一大堆毛病；

官方文件

正常的整合

thinker-support.gradle

...

/**
 * 此處填寫每次構建生成的基準包目錄
 */
def baseApkDir = "app-1225-13-47-33"

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

   ...

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

  ...

}

...

其他的都和官網差不多，主要用到的就是這幾個引數

在配置混淆規則的時候，要開啟混淆

   buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
        }
    }

不然生成不了app-release-mapping.txt檔案；

順序：
先生成基準包（也就是你要上線的包）

thinker-support.gradle中要更改一下

tinkerId = "base-3.0"

最好base後面跟著版本號

從右往左看，雙擊assembleRelease，會生成最左側的那個日期基準包，等下次你要執行這個命令的時候，直接可以在中間那個紅框中找到直接執行；現在基準包生成了，準備生成補丁包；

thinker-support.gradle中要更改一下

def baseApkDir = "app-1225-13-47-33"

這個日期要和左側的那個基準包的日期以及名字要 一樣（我這左邊有多個，你選擇你要上線的那個）

tinkerId = "patch-3.0-2"

這個也要改一下；
然後執行生成補丁，雙擊buildTinkerPatchRelease

還是從右往左看，雙擊後，大概3、5秒後生成補丁包，最左邊的，下次生成同樣可在中間選擇

最終提交那個patch-signed_7zip.apk到官網中；

這個才是整個修改後的針對基準包而生成的補丁檔案，之前我就搞錯了，每次我都是先在手機上執行一遍，然後生成基準包，補丁，壓根就不是針對我手機上執行的那個的補丁，所以一直沒效果；還有那個tinkerId我也只是改動base後面的數字，直到偶然才換到patch，浪費了不少時間；開始連那兩個命令都沒找到，找了半天，我還以為那兩個命令是在終端執行。。。

還有

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

裡面的引數看清楚，第三個引數要搞清楚自己的包名，官網給的是xxx.xxx，不要一時眼花看過去了。

在SampleApplicationLike中要配置自己的App ID

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

很奇怪，App Key怎麼沒用到？？？還是隻是初始階段沒用到

最後，一切按照官方的來，我的就OK了！

還有一個好訊息，就是他不收費。當然還得吐槽一下，它的生效時間有點慢。

（我在xml中放了一個TextView，寫到我帥嗎？然後補丁改為賊帥，第一遍竟然不出來，我還以為他在質疑自己，終於第二次他遵從了心底的聲音，但是這個停頓讓我很受打擊，這個聖誕節有點不愉快！！！）

多渠道打包官網也有講：
方法一：gradle配置productFlavors方式[有限制，一次最多五個渠道包]

如果你配置超過5個的話，那麼就意味著你要一個補丁，一個補丁上傳到Bugly補丁管理後臺，況且我們也只允許同時下發5個版本的補丁。這裡提一下為什麼要上傳所有渠道的補丁，因為通過productFlavors配置，會修改buildConfig類中的FLAVOR欄位，這會導致生成的不同渠道包的dex是不一樣的，所以只能針對具體渠道進行打補丁。這就非常的尷尬了，那怎麼辦呢？有沒有版本通過一個補丁就能夠修復所有渠道，答案是：有的，但前提是你要保證所有渠道包程式碼是一致的。

方法二：多渠道打包、walle

目前只遇到、解決這麼些問題，應該是我只處於嘗試階段，所以見識淺短，當我正真用到的時候載深入探究。

值得注意的一點就是他們都有一些限制，當你考慮用到這個的時候，你要考慮清楚它的限制。