常見Android編譯優化問題梳理總結

Posted on by

編譯常見問題

在開發過程中，有碰到過一些由於編譯優化導致的代碼修改並不符合我們預期的情況。這也就是之前為什麼我經常說編譯產物其實是不太可以被信任的。

  • 方法簽名變更，底層倉庫的方法變更但是上層模塊並沒有跟隨一起重新編譯導致的這個問題。
  • 常量優化，將一些常量的調用點直接替換成常量的值。
  • 刪除空導包， 沒有用的一些導包就會做一次剔除。

踩坑1

我們最近碰到一個 pipeline 相關而且很妖怪的問題。我們一個 pipeline 會檢查apk產物中是否存在異常的方法調用，就是之前介紹的在R8的基礎上開發出來的A8。但是最近有一個類被刪除瞭之後呢，但是代碼中還有一處調用點。但是這個檢測竟然被通過瞭，然後這部分代碼就被合入瞭master。

這個引用的文件就如上圖所示，是一個 debug buildType 中的，所以並不是所有的apk中都會存在這部分代碼。

然後呢，這個 MergeRequest 就被合入瞭 master 分支，因為當天是我們出下一個版本包的時間，然後交付給測試的就是全量編譯的 debug 和 release 包。別的開發同學rebase完master之後就發現 piepline 都跑不過瞭，就導致瞭他們當天的代碼無法被合入。

這個就是事情大概的起因和經過，但是各位有沒有想過為什麼會發生這個問題嗎。這個是不是我們的 pipeline 出現瞭bug，導致瞭這種問題無法被識別出來瞭呢。

以前有說過，如果簡單的說我們的快編系統就是把模塊替換成對應的aar，從而達到編譯提速。所以因為我們使用的是這個模塊對應的aar產物，所以大概率就是因為這個模塊的編譯產物和源代碼有差異導致瞭這個問題。

其實這個問題一出現我就已經知道大概率是由空導包優化導致的這個問題，因為在 pipeline 檢查的時候，檢測的apk產物中確實不存在這個導包。因為我們使用的是一個歷史版本的aar，其中無效導包的部分已經被編譯器做瞭刪除空導包的優化瞭。接下來我們看下我寫的一個demo中的無效導包。

圖一呢是源代碼java文件，圖二呢則是jar包中的代碼。可以簡單的看出來行號呢是可以對應的上的，但是這個 AppCompatActivity 的無效導包在產物中已經被優化掉瞭。這裡也就回答瞭在編譯過程中會保留行號，但是也會優化掉一部分不需要的代碼，讓我們編譯出來的產物更小。

所以也就導致瞭我們的產物和我們的源代碼之間的差異，另外一個角度就是說從apk中我們確實是不存在這個類的導包。但是呢在我們把這部分代碼重新編譯成aar的時候，就會出現source缺失，導致的語法樹無法生成，之後導致的編譯失敗問題。

這也就是所以我一直和大傢說編譯產物是不可以被信任的呢。

踩坑2

這個是之前的一個故事瞭，我們之前呢在模塊中定義瞭一些靜態常量吧，然後用來標識當前SDK的版本，然後這個值在別的模塊中被引用到瞭。

有一次因為需求變更，我們更改瞭這個靜態變量的值，然後呢我就把這個需求提測瞭。之後測試反饋給我為什麼這邊的這個值沒有變化啊。

我的天，當時我就是這樣，發生瞭什麼情況。然後呢我全量打瞭個包好瞭，我當時也就以為隻是編譯時的一個bug而已。然後後來呢，我查瞭下資料發現這個就是一個java編譯時的常量優化問題。過瞭一陣子吧，我面試瞭下字節跳動，然後我和面試官也聊瞭下這個話題，然後呢在這個方法簽名變更的問題上，當時我略輸一籌，哈哈哈哈。接下來我們就看下一個demo。

圖1呢也是java代碼，圖2呢則是aar中的編譯產物。其中我們可以看到，這個靜態常量在編譯成產物之後就會被編譯成這樣。

所以這個就解釋瞭我一開始碰到的這個問題，他就是由於我們的編譯器已經把aar中的這部分靜態常量編譯成瞭直接的值，然後呢我們的源變化之後如果沒有重新編譯對應的模塊，就會導致這個值一直無法被更新到最新的值。

到此這篇關於常見Android編譯優化問題梳理總結的文章就介紹到這瞭,更多相關Android編譯優化內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：