編譯常見(jiàn)問(wèn)題

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

• 方法簽名變更，底層倉(cāng)庫(kù)的方法變更但是上層模塊并沒(méi)有跟隨一起重新編譯導(dǎo)致的這個(gè)問(wèn)題。
• 常量?jī)?yōu)化，將一些常量的調(diào)用點(diǎn)直接替換成常量的值。
• 刪除空導(dǎo)包， 沒(méi)有用的一些導(dǎo)包就會(huì)做一次剔除。

踩坑1

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

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

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

這個(gè)就是事情大概的起因和經(jīng)過(guò)，但是各位有沒(méi)有想過(guò)為什么會(huì)發(fā)生這個(gè)問(wèn)題嗎。這個(gè)是不是我們的?pipeline?出現(xiàn)了bug，導(dǎo)致了這種問(wèn)題無(wú)法被識(shí)別出來(lái)了呢。

以前有說(shuō)過(guò)，如果簡(jiǎn)單的說(shuō)我們的快編系統(tǒng)就是把模塊替換成對(duì)應(yīng)的aar，從而達(dá)到編譯提速。所以因?yàn)槲覀兪褂玫氖沁@個(gè)模塊對(duì)應(yīng)的aar產(chǎn)物，所以大概率就是因?yàn)檫@個(gè)模塊的編譯產(chǎn)物和源代碼有差異導(dǎo)致了這個(gè)問(wèn)題。

其實(shí)這個(gè)問(wèn)題一出現(xiàn)我就已經(jīng)知道大概率是由空導(dǎo)包優(yōu)化導(dǎo)致的這個(gè)問(wèn)題，因?yàn)樵?pipeline?檢查的時(shí)候，檢測(cè)的apk產(chǎn)物中確實(shí)不存在這個(gè)導(dǎo)包。因?yàn)槲覀兪褂玫氖且粋€(gè)歷史版本的aar，其中無(wú)效導(dǎo)包的部分已經(jīng)被編譯器做了刪除空導(dǎo)包的優(yōu)化了。接下來(lái)我們看下我寫的一個(gè)demo中的無(wú)效導(dǎo)包。

圖一呢是源代碼java文件，圖二呢則是jar包中的代碼。可以簡(jiǎn)單的看出來(lái)行號(hào)呢是可以對(duì)應(yīng)的上的，但是這個(gè)?AppCompatActivity?的無(wú)效導(dǎo)包在產(chǎn)物中已經(jīng)被優(yōu)化掉了。這里也就回答了在編譯過(guò)程中會(huì)保留行號(hào)，但是也會(huì)優(yōu)化掉一部分不需要的代碼，讓我們編譯出來(lái)的產(chǎn)物更小。

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

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

踩坑2

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

有一次因?yàn)樾枨笞兏覀兏牧诉@個(gè)靜態(tài)變量的值，然后呢我就把這個(gè)需求提測(cè)了。之后測(cè)試反饋給我為什么這邊的這個(gè)值沒(méi)有變化啊。

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

圖1呢也是java代碼，圖2呢則是aar中的編譯產(chǎn)物。其中我們可以看到，這個(gè)靜態(tài)常量在編譯成產(chǎn)物之后就會(huì)被編譯成這樣。

所以這個(gè)就解釋了我一開(kāi)始碰到的這個(gè)問(wèn)題，他就是由于我們的編譯器已經(jīng)把a(bǔ)ar中的這部分靜態(tài)常量編譯成了直接的值，然后呢我們的源變化之后如果沒(méi)有重新編譯對(duì)應(yīng)的模塊，就會(huì)導(dǎo)致這個(gè)值一直無(wú)法被更新到最新的值。