常見Android編譯優(yōu)化問題梳理總結(jié)

更新時間：2022年08月16日 11:33:03 作者：敲代碼的老賈

這篇文章主要介紹了常見Android編譯優(yōu)化問題梳理總結(jié)，文章圍繞主題展開詳細的內(nèi)容介紹，具有一定的參考價值，需要的小伙伴可以參考一下

編譯常見問題

在開發(fā)過程中，有碰到過一些由于編譯優(yōu)化導(dǎo)致的代碼修改并不符合我們預(yù)期的情況。這也就是之前為什么我經(jīng)常說編譯產(chǎn)物其實是不太可以被信任的。

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

踩坑1

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

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

然后呢，這個 MergeRequest 就被合入了 master 分支，因為當天是我們出下一個版本包的時間，然后交付給測試的就是全量編譯的 debug 和 release 包。別的開發(fā)同學(xué)rebase完master之后就發(fā)現(xiàn) piepline 都跑不過了，就導(dǎo)致了他們當天的代碼無法被合入。

這個就是事情大概的起因和經(jīng)過，但是各位有沒有想過為什么會發(fā)生這個問題嗎。這個是不是我們的 pipeline 出現(xiàn)了bug，導(dǎo)致了這種問題無法被識別出來了呢。

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

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

圖一呢是源代碼java文件，圖二呢則是jar包中的代碼?？梢院唵蔚目闯鰜硇刑柲厥强梢詫?yīng)的上的，但是這個 AppCompatActivity 的無效導(dǎo)包在產(chǎn)物中已經(jīng)被優(yōu)化掉了。這里也就回答了在編譯過程中會保留行號，但是也會優(yōu)化掉一部分不需要的代碼，讓我們編譯出來的產(chǎn)物更小。

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

這也就是所以我一直和大家說編譯產(chǎn)物是不可以被信任的呢。

踩坑2

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

有一次因為需求變更，我們更改了這個靜態(tài)變量的值，然后呢我就把這個需求提測了。之后測試反饋給我為什么這邊的這個值沒有變化啊。

我的天，當時我就是這樣，發(fā)生了什么情況。然后呢我全量打了個包好了，我當時也就以為只是編譯時的一個bug而已。然后后來呢，我查了下資料發(fā)現(xiàn)這個就是一個java編譯時的常量優(yōu)化問題。過了一陣子吧，我面試了下字節(jié)跳動，然后我和面試官也聊了下這個話題，然后呢在這個方法簽名變更的問題上，當時我略輸一籌，哈哈哈哈。接下來我們就看下一個demo。