為何使用熱修復？

項目開發中難免會有一些問題，需要修改，直接進行發版的話成本較高。這時候我們就需要一個可以在不進行版本更新，就可以修復問題的工具。所以說，熱修復的定位就是對一些非緊急，需要解決的bug進行修復的輔助工具。

什么是Tinker？為何選用它？

• Tinker是微信官方的Android熱補丁解決方案，它支持動態下發代碼、So庫以及資源，讓應用能夠在不需要重新安裝的情況下實現更新。當然，你也可以使用Tinker來更新你的插件。

• 國內大大小小，有很多開源的熱修復工具，方案。但他們或多或少有著生產項目難以接受的問題：

  Tinker	QZone	AndFix	Robust
  類替換	yes	yes	no	no
  So替換	yes	no	no	no
  資源替換	yes	yes	no	no
  全平臺支持	yes	yes	yes	yes
  即時生效	no	no	yes	yes
  性能損耗	較小	較大	較小	較小
  補丁包大小	較小	較大	一般	一般
  開發透明	yes	yes	no	no
  復雜度	較低	較低	復雜	復雜
  gradle支持	yes	no	no	no
  Rom體積	較大	較小	較小	較小
  成功率	較高	較高	一般	最高

總的來說:

1. AndFix作為native解決方案，首先面臨的是穩定性與兼容性問題，更重要的是它無法實現類替換，它是需要大量額外的開發成本的；
2. Robust兼容性與成功率較高，但是它與AndFix一樣，無法新增變量與類只能用做的bugFix方案；
3. Qzone方案可以做到發布產品功能，但是它主要問題是插樁帶來Dalvik的性能問題，以及為了解決Art下內存地址問題而導致補丁包急速增大的。

特別是在Android N之后，由于混合編譯的inline策略修改，對于市面上的各種方案都不太容易解決。而Tinker熱補丁方案不僅支持類、So以及資源的替換，它還是2.X－8.X(目前也支持9.0)的全平臺支持。并且Tinker已運行在微信的數億Android設備上。

已知問題

理想很美好，愿世上沒有bug，or Tinker可以解決我們遇到的所有問題，但就幾次線上補丁的發布以及最終結果來看，他都或多或少有以下幾個問題：

• 以下都是針對我們使用的1.9.2版本來說明：
  1. 公司內部部分手機補丁沒有生效，測試部門的兩款Vivo手機，這個是tinker已知的問題，Vivo部分手機，會執行異步dex2oat，在dex合成等待時間內，并沒有修復成功，目前于使用tinker1.9.9版本測試時，確認已經修復。
  2. 項目更新了x5 webview的版本，下發補丁。但客戶反饋有手機會有手機連續閃退三次，回退到補丁前的版本。對于此問題，我們也仔細的研究了友盟后臺的crash日志，發現的確有華為android 8.0，9.0存在閃退的情況。
  3. Tinker必須要重啟后生效，硬傷。
  4. 對于整個android系統來說，熱修復方案其實是一種逆向行為，無論是哪種方案，都可能存在兼容性問題的，而且每次android新版本發布，尤其對虛擬機等做優化時，基本上都會成為熱修復的“坑”。
  5. 用戶安裝補丁后，可能修復過程或者修復后，app閃退，此時我們是閃退三次，再清除補丁，能否閃退一次就進行清除？
• 官方介紹說明，由于原理與系統限制，Tinker有以下已知問題：
  1. Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大組件(1.9.0支持新增非export的Activity)；
  2. 由于Google Play的開發者條款限制，不建議在GP渠道動態更新代碼；
  3. 在Android N上，補丁對應用啟動時間有輕微的影響；
  4. 不支持部分三星android-21機型，加載補丁時會主動拋出"TinkerRuntimeException:checkDexInstall failed"；
  5. 對于資源替換，不支持修改remoteView。例如transition動畫，notification icon以及桌面圖標。

對我們有何影響？如何解決

• 1.9.2不支持vivo，目前可以通過升級Tinker版本，較為簡單的解決。

• Tinker作為微信實際使用的動態代碼修復方案，他們也會不斷接收到來自于手機廠商，開發者反饋的各種問題，不斷更新版本。目前已經迭代到1.9.11并解決了部分問題。

• 對于組件新增，目前我們的bug場景不會涉及。google市場暫時不會上架，需要上架時，我們不下發補丁即可。

• 對于此次小邑出現的崩潰，目前總結有以下兩個原因：

  1. 更新X5版本，代碼設計修改點很大，風險性預估不充分，測試覆蓋不全面
  2. tinker版本項目中使用的還是1.9.2，此時android9.0尚未發布，廠家的定制系統可能不夠適配，需要及時迭代，方可使用。

• 對于補丁異常出現三次，再進行清除，我們可以設置次數。

• 對于補丁下發，我們沒有整體把控的數據支持；于此，我們增加補丁下發覆蓋率（下載補丁數/活躍用戶數），成功率（成功/活躍用戶數）的數據統計。新增bugly渠道跟蹤異常，bugly可以更及時，準確的反饋異常。

• 接下來我們重點考慮如何降低Tinker導致的異常崩潰：

  1. 對于補丁版本嚴格把控，對補丁修改涉及的影響點評估。并列入修改點，提供給項目經理，再向上請示，是否進行相關修改。

  2. 確認發布補丁時，需要對補丁修復后的app，測試針對影響點，盡可能多的利用公司手機，覆蓋測試。

  3. 結合線上資源，對補丁進行云測，擴大覆蓋面，非正式包可設置補丁成功直接重啟，進而不影響云測。

  4. 啟用灰度測試，僅針對部分園區下發，并跟蹤成功率，崩潰率等數據，進行補丁是否全面下發的判斷。