對(duì)待棘手bug，新手與大牛的差距在哪里？
問(wèn)題描述：
- 自上上周起，團(tuán)隊(duì)中陸續(xù)有iOS開(kāi)發(fā)抱怨電腦特別卡。有細(xì)心的同學(xué)發(fā)現(xiàn)，因?yàn)閄code占用了約6-7G內(nèi)存，而部分mac只有8G內(nèi)存，所以?xún)?nèi)存爆滿(mǎn)引起卡頓。
- 而部分同學(xué)的mac是16G內(nèi)存的，比如我(嘲諷臉)，因?yàn)閮?nèi)存充足沒(méi)感覺(jué)到卡。
- 但這個(gè)問(wèn)題影響團(tuán)隊(duì)的開(kāi)發(fā)效率，所以需要去解決問(wèn)題。
內(nèi)存對(duì)比：
在沐浴更衣焚香、殺進(jìn)程、清緩存后，分別拉取相鄰的812版本代碼和816版本代碼分別編譯，得到結(jié)論：
- 812調(diào)試時(shí)，占用2G內(nèi)存
- 816調(diào)試時(shí)，占用6.8G內(nèi)存
吐槽：
- 對(duì)于這個(gè)數(shù)據(jù)，我們內(nèi)心是拒絕接受的。有如下2點(diǎn)吐槽:
- 如果代碼亂申請(qǐng)內(nèi)存，那么內(nèi)存爆掉的應(yīng)該是模擬器或真機(jī)。而不該是Xcode
- 如果當(dāng)前版本新增10w行代碼(其實(shí)不到)，對(duì)總代碼量增長(zhǎng)不超10%，Xcode內(nèi)存怎么可能翻兩翻。
- 所以我們覺(jué)得，這一定是蘋(píng)果的鍋，我們不背
但是不管是誰(shuí)的鍋，肯定是代碼或者配置觸發(fā)的，分析還要繼續(xù)。
分析方法選擇：
- 擺在我們面前有2個(gè)分析方法：
- 找代碼：通過(guò)二分法，編譯不同日期的版本，找到引發(fā)問(wèn)題的那次提交，確定是哪個(gè)改動(dòng)引起
- 找內(nèi)存：分析增大的內(nèi)存是什么，根據(jù)增大的內(nèi)容分析問(wèn)題出在哪。
- 如果使用方法1，編譯一次代碼需要15分鐘，假設(shè)問(wèn)題是某一行代碼引起的，估計(jì)需要找一天。如果是某多行代碼組合影響的問(wèn)題，時(shí)間會(huì)更長(zhǎng)。而且就算找到代碼，也未必知道原理是什么。
- 所以我選擇**方法2**，不行再退到方法1
分析步驟：
我在run的時(shí)候發(fā)現(xiàn)：
- 812初次打開(kāi)代碼內(nèi)存1G以?xún)?nèi)，編譯運(yùn)行時(shí)內(nèi)存2G，關(guān)閉Xcode后再打開(kāi)內(nèi)存2G
- 816初次打開(kāi)代碼內(nèi)存1G以?xún)?nèi)，編譯運(yùn)行時(shí)內(nèi)存6G，關(guān)閉Xcode后再打開(kāi)內(nèi)存6G
關(guān)閉Xcode后再打開(kāi)，此時(shí)Xcode并沒(méi)有run，所以推測(cè)他在做一件事：讀緩存
緩存文件：
- 大家都知道，Xcode編譯一個(gè)新工程會(huì)很慢，但是第二次編譯就很快。那是因?yàn)樗丫幾g結(jié)果存到了緩存文件中。第二次編譯只讀文件不編譯自然就快了。
- 緩存文件存儲(chǔ)在“/Users/你的用戶(hù)名/Library/Developer/Xcode/DerivedData”目錄下
- 812和816版本的緩存文件對(duì)比如下：
- 初步可以看出，緩存文件數(shù)量一致，但是大小差距很大。所以下一步就是來(lái)找茬：到底誰(shuí)變大了
- 經(jīng)過(guò)一番尋找，發(fā)現(xiàn)每個(gè)類(lèi)會(huì)生成三個(gè)文件：
.o文件：二進(jìn)制對(duì)象文件，不多說(shuō)
.d文件：文本文件，記錄該類(lèi)依賴(lài)的所有文件路徑
.dia文件：未知二進(jìn)制文件，但是變大的就是它
- dia是有一部分變大了，一部分沒(méi)變。嘗試用二進(jìn)制工具打開(kāi)讀了一下，有驚喜：
- 這不就是warning嘛
我的吐槽又來(lái)了：
- 是誰(shuí)!站出來(lái)!**寫(xiě)了4個(gè)G的warning!**
繼續(xù)分析:
那具體是什么導(dǎo)致的warning呢，面對(duì)幾千個(gè).dia文件，我內(nèi)心是崩潰的。
- 幸好找基友溝通，剛好他做了代碼warning掃描，發(fā)現(xiàn)816比812只是某組代碼多了107個(gè)warning，其他組沒(méi)變化，而且是nonnull相關(guān)warning，并不重要所以沒(méi)追究。
- 我們找到107處warning的代碼，查看提交記錄，就是在大家反饋卡頓之前。貌似就是它了。我們把warning解了，clean重新編譯，問(wèn)題得解。
問(wèn)題雖解，但是遺留2個(gè)問(wèn)題：
- 怎么就提交了107個(gè)warning?
- 區(qū)區(qū)107個(gè)warning。為啥會(huì)導(dǎo)致內(nèi)存飆升?我們還剩幾百個(gè)warning為啥沒(méi)問(wèn)題?
問(wèn)題1：
- 引發(fā)107個(gè)warning的只有一行代碼
- 對(duì)于nonnull相關(guān)warning蘋(píng)果的潛規(guī)則是這樣的：
自Xcode6起提供的新功能，可以申明一個(gè)函數(shù)的參數(shù)是必傳的(nonnull)還是可選的(nullable) ，這會(huì)讓代碼更嚴(yán)謹(jǐn)，我們是推薦使用的
兼容老代碼：整個(gè)頭文件都沒(méi)有nonnull/nullable申明的，編譯沒(méi)毛病
對(duì)新代碼高要求：只要給代碼中添加了一個(gè)nonnull/nullable，剩余的代碼也必須添加，否則其他每個(gè)接口就會(huì)有warning
- 所以，這次涉案的代碼是個(gè)舊工具類(lèi)，有107個(gè)函數(shù)。新增的一行代碼添加了nonnull。于是產(chǎn)生了107個(gè)warning
問(wèn)題2：
舉個(gè)例子，有A B C三個(gè)類(lèi)
- A.h有一個(gè)warning，其.dia文件中會(huì)如下信息：
insert '_Nullable' if the pointer may be null
insert '_Nonnull' if the pointer should never be null
- A.m文件絕對(duì)路徑
- A.h文件絕對(duì)路徑
- A.m文件第幾行引用了A.h，存在warning
- warning在A.h的位置
- warning描述是:pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified)
- fix的兩種方法：
- 總之，一處warning的信息大約是1k
- 如果B引用了A，則B的.dia文件包含如上所有信息，以及多個(gè)B的文件路徑，即B的描述信息超過(guò)A
- 如果C引用了B，而B(niǎo)在頭文件中引用了A，則C的描述信息超過(guò)B
所以
- 在工程上，107warning的文件，dia約130k。
- 所有直接間接引用的文件數(shù)量大概2500，單個(gè)文件都超過(guò)130k。文件大小約350M。
- 加上模擬器有2個(gè)cpu架構(gòu)(i386/x86_64)，會(huì)生成2份文件，緩存中還有個(gè)聚合的dgph文件。以及文件在內(nèi)存中結(jié)構(gòu)化后占用的內(nèi)存空間。
- 所以最終翻了幾倍，達(dá)到4G的內(nèi)存占用是可以理解的。
結(jié)論：
- 不要忽略warning，特別是頭文件中的warning，會(huì)被多處引用導(dǎo)致過(guò)大的描述信息
- 頭文件中盡量不要import頭文件，會(huì)造成過(guò)度的引用，放大問(wèn)題。
后續(xù)：
- 818版本已經(jīng)fix了core中的所有nonnull問(wèn)題。后續(xù)逐步將warning清零
- fix后內(nèi)存占用如圖
PS:這是蘋(píng)果的bug么?我覺(jué)得還是自己挖坑把自己埋了。
【本文為51CTO專(zhuān)欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
