Android熱更新開源專案Tinker原始碼解析系列之三：so熱更新

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

1. Android熱更新開源專案Tinker原始碼解析系列之一：Dex熱更新
2. Android熱更新開源專案Tinker原始碼解析系列之二:資原始檔熱更新
3. Android熱更新開源專案Tinker原始碼解析系類之三：so檔案熱更新

轉載請標明本文來源：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過程中所需要考慮的問題做一個闡述。