【原】Android熱更新開源項目Tinker源碼解析系列之三：so熱更新，androidtinker

【原】Android熱更新開源項目Tinker源碼解析系列之三：so熱更新，androidtinker

本系列將從以下三個方面對Tinker進行源碼解析：

轉載請標明本文來源：http://www.cnblogs.com/yyangblog/p/6252855.html
更多內容歡迎star作者的github：https://github.com/LaurenceYang/article
如果發現本文有什麼問題和任何建議，也隨時歡迎交流~

首先講下Android裡面關於so的加載的兩種方式：

方式一：System.loadLibrary， 這種方式傳入的是so的名字，會直接從系統的目錄去加載so文件，系統的路徑包括/data/data/${package_name}/lib、/system/lib、/vender/lib等這類路徑。

方式二：System.load， 這種方式傳入的是so的絕對路徑，直接從這個路徑加載so文件。

Tinker的so文件熱更新的原理就是通過方式二，直接加載新的so實現的。

相對於Dex和資源的更新，是不是簡單很多。

so文件的熱更新流程同dex、資源文件一樣，包含補丁生成，補丁合成，補丁加載三個部分。

生成補丁時比較新舊so文件使用BSdiff算法生成補丁包，

然後在下發補丁成功後根據BSpatch算法將補丁包和舊的library合成新的library，

並將更新後的Library庫文件保存在tinker下面的目錄下，

這個目錄就是/data/data/${package_name}/tinker/lib。

然後在加載的時候直接通過System.load加載該目錄下面的so文件。

具體的源碼不再做闡述。

需要注意的是，Tinker中so的熱更新對用戶並不是無感的，需要用戶自發的去加載自己需要的庫文件，下面是tinker的wiki裡關於這方面的描述：

但是Tinker並沒有直接將補丁的lib路徑添加到DexPathList中，理論上這樣可以做到程序完全沒有感知的對Library文件作補丁。這裡主要是因為在多abi的情況下，某些機器獲取的並不准確。
所以想要加載最新的庫，需要自己使用TinkerInstaller.load*Library去加載庫文件，它會自動嘗試先去Tinker中的庫文件加載，加載不成功會調用System.loadLibrary調用系統的庫文件。

1 //load lib/armeabi library
2 TinkerInstaller.loadArmLibrary(getApplicationContext(), "stlport_shared");
3 //load lib/armeabi-v7a library
4 TinkerInstaller.loadArmV7Library(getApplicationContext(), "stlport_shared");

另外，對於第三方庫文件的加載，Tinker無法干預其加載時機，但是只要在我們的代碼提前加載第三方的庫文件即可。

若想對第三方代碼的庫文件更新，可先使用TinkerInstaller.load*Library對第三方庫做提前的加載！

當前使用方式似乎並不能做到開發者透明，這是因為Tinker想盡量少的去hook系統框架減少兼容性的問題。

到此，tinker的源碼解析系列到此結束。

本系列從dex，資源文件和so的補丁生成，補丁合成和補丁加載角度出發，做了一個簡要的流程分析。

因為自己水平有限，很多地方也沒有太過深入。

對tinker感興趣的同學可以到tinker的官方github去看更多的文檔。

也歡迎大家多多拍磚。

轉載請標明本文來源：http://www.cnblogs.com/yyangblog/p/6252855.html
更多內容歡迎star作者的github：https://github.com/LaurenceYang/article
如果發現本文有什麼問題和任何建議，也隨時歡迎交流~

 下一篇文章將對在實際使用tinker過程中所需要考慮的問題做一個闡述。