知道了 native 替換方式兼容性問題的原因，我們是否有辦法尋求一種新的方式，不依賴于 ROM 底層方法結構的實現而達到替換效果呢？

我們發現，這樣 native 層面替換思路，其實就是替換 ArtMethod 的所有成員。那么，我們并不需要構造出 ArtMethod 具體的各個成員字段，只要把 ArtMethod 的作為整體進行替換，這樣不就可以了嗎？

也就是把原先這樣的逐一替換。

變成了這樣的整體替換。

因此 Andfix 這一系列繁瑣的替換:

其實可以濃縮為：

就是這樣，一句話就能取代上面一堆代碼，這正是我們深入理解替換機制的本質之后研發出的新替換方案。

剛才提到過，不同的手機廠商都可以對底層的 ArtMethod 進行任意修改，但即使他們把 ArtMethod 改得六親不認，只要我像這樣把整個 ArtMethod 結構體完整替換了，就能夠把所有舊方法成員自動對應地換成新方法的成員。

但這其中最關鍵的地方，在于 sizeof(ArtMethod)。如果 size 計算有偏差，導致部分成員沒有被替換，或者替換區域超出了邊界，都會導致嚴重的問題。

對于 ROM 開發者而言，是在 art 源代碼里面，所以一個簡單的 sizeof(ArtMethod)就行了，因為這是在編譯期就可以決定的。

但我們是上層開發者，app 會被下發給各式各樣的 Android 設備，所以我們是需要在運行時動態地得到 app 所運行設備上面的底層 ArtMethod 大小的，這就沒那么簡單了。

想要忽略 ArtMethod 的具體結構成員直接取得其 size 的精確值，我們還是需要從虛擬機的源碼入手，從底層的數據結構及排列特點探尋答案。

在 art 里面，初始化一個類的時候會給這個類的所有方法分配空間，我們可以看到這個分配空間的地方：

類的方法有 direct 方法和 virtual 方法。direct 方法包含 static 方法和所有不可繼承的對象方法。而 virtual 方法就是所有可以繼承的對象方法了。

AllocArtMethodArray 函數分配了他們的方法所在區域。

可以看到，ptr 是這個方法數組的指針，而方法是一個接一個緊密地 new 出來排列在這個方法數組中的。這時只是分配出空間，還沒填入真正的 ArtMethod 的各個成員值，不過這并不影響我們觀察 ArtMethod 的空間結構。

正是這里給了我們啟示，ArtMethod 們是緊密排列的，所以一個 ArtMethod 的大小，不就是相鄰兩個方法所對應的 ArtMethod 的起始地址的差值嗎？

正是如此。我們就從這個排列特點入手，自己構造一個類，以一種巧妙的方式獲取到這個差值。

由于 f1 和 f2 都是 static 方法，所以都屬于 direct ArtMethod Array。由于 NativeStructsModel 類中只存在這兩個方法，因此它們肯定是相鄰的。

那么我們就可以在 JNI 層取得它們地址的差值：

然后，就以這個 methSize 作為 sizeof(ArtMethod)，代入之前的代碼。

問題就迎刃而解了。

值得一提的是，由于忽略了底層 ArtMethod 結構的差異，對于所有的 Android 版本都不再需要區分，而統一以 memcpy 實現即可，代碼量大大減少。即使以后的 Android 版本不斷修改 ArtMethod 的成員，只要保證 ArtMethod 數組仍是以線性結構排列，就能直接適用于將來的 Android 8.0、9.0 等新版本，無需再針對新的系統版本進行適配了。事實也證明確實如此，當我們拿到 Google 剛發不久的 Android O(8.0)開發者預覽版的系統時，hotfix demo 直接就能順利地加載補丁跑起來了，我們并沒有做任何適配工作，魯棒性極好。

【注：本文源自網絡文章資源，由站長整理發布】

web 前端中文站 , 版權所有丨如未注明 , 均為原創丨本網站采用BY-NC-SA協議進行授權

轉載請注明原文鏈接：詳解 Android 熱更新升級如何突破底層結構差異？

總結

以上是生活随笔為你收集整理的android 上下偏差怎么写_详解 Android 热更新升级如何突破底层结构差异？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。