熱修復Sophix的爬坑之路

寫該篇博客就是爲了總結下使用Sophix的過程中碰到的一些Bug及爬坑過程，希望各位極客還沒碰到，看了我的回顧總結後能對可能出現的困惑有幫助。

爬坑之路會 隨着路程越遠逐步完善

坑一：AndroidX 不兼容

開發環境

win10 + android studio 3.5.1 + gradle-5.4.1 + 設備API 5.1.1 + jdk1.8+ alicloud-android-hotfix:3.2.10

爬坑過程

這個Bug簡單來說就是3.2.10的時候Sophix還不支持androidx，使用了Androidx的Android5.1.1在進行resource 資源更新是就會報如圖錯誤。

最終的解決方法是通過我的堅持，Sophix最終進行修改優化兼容Androidx。版本升級爲3.2.12後支持了Androidx。心酸過程讓我一一道來。

我這個人有升級狂魔症，經常喜歡升級依賴，Gradle、插件等，反正只要能更新的，能升級的我都要立馬升級，更新，因此踩了不少的坑，碰到了不少的雷。本着我不入地獄誰入地獄的精神，依然一往無前，樂此不疲。 不扯遠了，回正題。

首先，我發現將項目轉爲Androidx後，發現自己的Sophix不能正常工作了，app打完補丁就崩潰，於是各種測試，測試其他還未轉androidx的項目正常。沒辦法只能求助全能的技術支持。

此時自己開始懷疑Sophix自身有問題，雖然Sophix是阿里的技術團隊開發的，我也對它迷之自信，但是我的懷疑心戰勝了崇拜心，大膽的猜測。 雖然技術支持堅稱SDK不會有問題，但是我一直堅持自己的觀點。


通過不斷地多種測試，拿出我的多Gradle版本,多Android SDk版本的熱更新測試，終於說服了Sophix 進行Androidx的兼容檢查，最終發現 sophix 3.2.8之前的sdk確實不兼容android 5.0、5.1、 6.0的androidx apk進行熱更新.


問題解決
OK,經過Sophix的工程師修復，Sophix 3.2.10升級到Sophix 3.2.12就能解決5.0，5.1,6.0 中安裝了 Androidx的apk後，進行resource修復報錯崩潰的bug。

總結

1. 常常看到阿里騰訊等大廠的產品我們就會覺得他們的產品肯定厲害，肯定沒問題，其實這是個誤解。 作爲程序員大家其實是認同軟件產品不能不存在Bug,好的和壞的就看bug率的多少了。 軟件產品是一個逐步完善逐步修復bug完善的過程。
2. 對於任何開發中碰到的問題，我們要大膽的假設和猜測，不能根據自己的經驗去認爲不可能。
   一切皆有可能，何況我們大多數人還不是特級大神，我們需要懷疑需要假設，通過實際的排查和驗證，才能排除不是那些因素造成了我們的問題。
   實踐是檢驗一切真理的唯一標準

坑二：patch 補丁反覆失效

這次碰到的Bug是補丁反覆失效，具體症狀是：補丁成功後，下次重啓軟件又恢復了原樣，繼續重啓補丁成功，繼續重啓恢復原樣。簡直就是子子孫孫無窮盡也！

開發環境

1. win10+gradle-5.6.4+android studio 3.6.3 + 設備API 5.1.1+jdk1.8
2. ‘com.aliyun.ams:alicloud-android-hotfix:3.2.14’
3. 有個特殊的情況是，我的軟件需要進行系統簽名，製作成系統軟件以便於軟件的靜默安裝。生成的apk需要經如下文件簽名，讓程序獲得系統級權限。
   
   系統簽名還需在AndroidManifest.xml中配置android:sharedUserId="android.uid.system"

爬坑過程

首先進行相關因素排查，然後根據自己的進行假設，一步步驗證排除假設直至找到最終真相。

1. 緩存清理

首先懷疑我進行了清緩存操作，於是我把各種自動清理垃圾緩存的代碼操作屏蔽 和管理軟件卸載，繼續測試，Bug未解決，該Bug與緩存清理無關。
補充說明： 後面交流才知道patch的下載路徑在/data/data/com.axecom.smartweightdj/files/sophix/patch(非系統簽名app的路徑，系統簽名的下載路徑我也沒權限看不到啊)。

2. MultiDex不正常
各種日誌分析測試，發現apk中有多個.dex文件，懷疑MultiDex失敗的問題。我的apk中有7個.dex文件，後面幾個.dex文件方法數只有幾百個。 一般來說只有方法數超過65535，纔會有兩個.dex文件，後面依次計算，超過65535*2纔會有3個.dex文件。

技術支持小哥讓我生成正常的apk,這可難倒我了，找不出我的apk生成多個.dex文件的原因，，我只能笨辦法，重建工程把內容以過去，好了，發現apk正常了，只有了2個.dex文件。



滿心歡喜的以爲搞定了，測試看看。我去，bug還是沒解決，依然存在。

3. System.exit(0)
繼續測試找背鍋俠。在關閉的過程中，有System.exit(0)這個操作，好吧會不會是它造成的，我猜一般應該和這個沒關係吧。

果然屏蔽了System.exit(0)方法後，Bug還是沒有解決。繼續其他猜想。

4. patch補丁是否加載正常
沒辦法，同樣一個補丁，Sophix是不會不斷下載同一補丁的，那麼實時觀察它的狀態吧。

此時不嘗試獲得兩個總結：
1.爲了能看到data\data\package中的patch文件，我取消了系統簽名，發現補丁竟然成功了。
2.非系統簽名app,如果系統未root，一般也看不到data\data\package中的信息，此時只能通過配置debuggable true，此時我們能通過 看到data\data\package中的數據。
意外驚喜是非系統簽名的app debuggable=true時， 補丁能正常。此時能看到data\data\package中的內容

趕緊測試debuggable=false時，補丁也能正常。此時權限問題無法看到data\data\package中的內容

在這裏插入圖片描述
3我的bug造成的原因肯定和系統簽名有關係

5. 系統root
爲了能看到系統簽名，我需要找一個root 版本進行測試。
找到 root 系統進行測試後補充該處的內容

該Bug肯定是和系統權限方面有關。

問題解決：
bug源碼解決了。這個bug折磨了我一個周的時間去整理和排除，可謂是傷透了心。

我的這個Bug一般人是碰不到的，需要系統簽名的軟件纔會碰到如此問題,希望你們不會碰到，截止20200516，我所知道能讓系統簽名的app也支持Sophix的只有讓Android 系統root。

總結

1. 其實生成了多個.dex的原因是：設置了 debuggable= true，此時生成了7個.dex文件，debuggable= false時生成的apk有2個.dex文件。

2. 這個Bug其實與debuggable的設置其實毫無關係，也即與.dex的多寡無關。這是後面經過我多次測試終於明白的。`**

3. 碰到技術bug能耐下心來去研究，排查，網上搜資料，始終能解決問題的。

4. 我的這個Bug的唯一解決方式是系統要root,或者將patch下載到外部空間如public\download中(但是Sophix現在是不支持修改設置patch下載地址的)

結語

• 首先要感謝自己的持之以恆，碰到的bug和爬坑過程，時間跨度在一個星期和一個多月。中間要做各種測試操作和驗證，補充相關論點支持，每次自己都未有想放棄的想法，雖然頭疼還是堅持排查最終也得到了解決。

• 非常感謝Sophix的技術支持@塗中和@徐厚、@劉寶文，這些Sophix的技術支持團隊非常的有耐心，對於技術疑惑回答都很及時且對提問者的問題都是有問必答比解決。非常敬佩他們的敬業精神，果然覺得阿里的招牌不是蓋的。

• 我在熱更新方向是從Bugly平臺轉到EMAS的，兩者的技術高低暫且不論，技術支持方面是高低立下的，真的建議大家更偏向Sophix,少踩Bugly的坑，我將用一片博文來闡述爲什麼。