本系列將從以下三個方面對Tinker進行源碼解析： 轉載請標明本文來源：http://www.cnblogs.com/yyangblog/p/6252855.html更多內容歡迎star作者的github：https://github.com/LaurenceYang/article如果發現本文有什 ...
本系列將從以下三個方面對Tinker進行源碼解析：
- Android熱更新開源項目Tinker源碼解析系列之一：Dex熱更新
- Android熱更新開源項目Tinker源碼解析系列之二:資源文件熱更新
- 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過程中所需要考慮的問題做一個闡述。
