前言
眾所周知泽示，Bug是線上應(yīng)用極力規(guī)避但又無法避免的缸血。對(duì)于致命的Bug蜜氨，我們可以通過Crash日志進(jìn)行分析；對(duì)于無法復(fù)現(xiàn)的Bug捎泻、特定操作步驟引起的Bug飒炎、某些版本/系統(tǒng)才出現(xiàn)的Bug，每個(gè)開發(fā)者都有自己的一套分析笆豁、定位郎汪、解決的方法。
本文以工作中遇到的幾個(gè)iOS 11 Bug為例闯狱，介紹快速定位煞赢、分析、解決Bug的經(jīng)驗(yàn)哄孤。
正文
iOS 11裁剪圖片偏移問題
功能背景：
用戶從本地相冊(cè)選擇圖片照筑，然后裁剪一個(gè)正方形區(qū)域，最后生成用戶頭像瘦陈。
Bug描述：
iOS 11的iPhone X凝危，選擇本地圖片，然后進(jìn)行裁剪晨逝，生成的圖片有明顯的偏移蛾默，如下：
功能實(shí)現(xiàn)：
裁剪控件是系統(tǒng)提供的UIImagePickerController。
Bug定位：
用模擬器進(jìn)行復(fù)現(xiàn)捉貌，并斷點(diǎn)在UIImagePickerController的回調(diào)方法支鸡，再用Xcode查看實(shí)際的返回參數(shù)和圖片。
如下：
①是特意選擇的區(qū)域趁窃，剛好覆蓋到瀑布的頂部苍匆；
②是UIImagePickerController的返回參數(shù)，通過po命令查看棚菊；
③是按照返回參數(shù)的CropRect在原圖截取出來的區(qū)域浸踩；
④是返回參數(shù)中的圖片；
經(jīng)過可以對(duì)比發(fā)現(xiàn)统求，③和④的圖片是一致的检碗，并且明顯與①所選中的區(qū)域有所偏移据块。以同樣的方式嘗試iPhone X和6s的模擬器，發(fā)現(xiàn)都有偏移現(xiàn)象折剃，且iPhone X的偏移更為嚴(yán)重另假。
檢查本地代碼，確認(rèn)是正常的方式調(diào)用UIImagePickerController怕犁，那具體是哪一步影響裁剪結(jié)果呢边篮？
仔細(xì)體驗(yàn)UIImagePickerController的裁剪功能，發(fā)現(xiàn)一個(gè)可疑的現(xiàn)象：
6s模擬器戈轿，藍(lán)色箭頭指向的區(qū)域是無法選擇的！
以這個(gè)區(qū)域?yàn)橥黄瓶谡笞樱瑢?duì)比此處區(qū)域的高度值和裁剪的偏移值思杯，得到大致是1：2的比例，符合2x屏幕。
用iPhone X模擬器同樣復(fù)現(xiàn)了這個(gè)問題，并且不能選擇的區(qū)域更大催训。
而且非常有意思的是：iPhone X模擬器的裁剪偏移量為44pixel窖梁。
對(duì)于做過iPhone X適配的開發(fā)，對(duì)于44這個(gè)數(shù)值域是非常敏感的（頂部安全區(qū)域的高度），猜測是和statusBar有關(guān)。
再找到6s的模擬器對(duì)比裁剪偏移量，果不其然澎办，大致是22pixel。
至此于宙，Bug摸清來龍去脈：
UIImagePickerController的裁剪選擇視圖向下偏移了status bar的高度浮驳，但是裁剪的時(shí)候還是按照y=0計(jì)算，導(dǎo)致結(jié)果產(chǎn)生偏移捞魁。（猜測是iOS 11 UIScrollView的contentInsetAdjustmentBehavior屬性導(dǎo)致）
Bug解決：
裁剪時(shí)至会，隱藏statusBar。
PS：此Bug在iOS8也會(huì)出現(xiàn)谱俭，iOS 9/10是正常的奉件。
iOS 8隱藏statusBar需要在UIImagePickerController的delegate實(shí)現(xiàn)中，添加以下代碼
- (void)navigationController:(UINavigationController *)navigationController
willShowViewController:(UIViewController *)viewController
animated:(BOOL)animated {
if ([navigationController isKindOfClass:[UIImagePickerController class]] ) {
[[UIApplication sharedApplication] setStatusBarHidden:YES];
}
}
小結(jié)：
善用工具县貌，快速定位。
對(duì)于能夠復(fù)現(xiàn)的Bug凑懂，Xcode連接真機(jī)斷點(diǎn)調(diào)試是最方便的方法煤痕。
但是切記，不要沉浸在單步調(diào)試和盲目枚舉嘗試的過程。
iOS 11圖像放大閃爍問題
功能背景：
用戶點(diǎn)擊圓形頭像后摆碉，頭像會(huì)放大到等同屏幕寬度塘匣，并且從圓形展示變成正方形展示。
Bug描述：
iOS 11的iPhone 7p巷帝，在點(diǎn)擊頭像之后忌卤，在頭像放大的過程中會(huì)有閃爍的現(xiàn)象。（iPhone X效果最為嚴(yán)重楞泼，除了閃爍還有抖動(dòng)現(xiàn)象）
功能實(shí)現(xiàn)：
圓角按鈕通過layer.cornerRadius實(shí)現(xiàn)驰徊，頭像放大是UIView的animation block動(dòng)畫；
Bug定位：
先用模擬器進(jìn)行嘗試堕阔，發(fā)現(xiàn)無法復(fù)現(xiàn)棍厂；再用真機(jī)進(jìn)行測試，發(fā)現(xiàn)偶然會(huì)閃爍的現(xiàn)象印蔬。
用錄屏工具輔助勋桶，定位到閃爍是因?yàn)閳D片放大的動(dòng)畫過程中脱衙，出現(xiàn)了某一幀異常：
上面的展示效果類似OpenGL紋理展示的GL_CLAMP_TO_EDGE模式侥猬，懷疑是圖像放大過程中的邊界處理有異常。
帶著疑問回看代碼捐韩。查看頭像詳情時(shí)退唠，點(diǎn)擊頭像（為圓形）會(huì)全屏顯示頭像大圖。整個(gè)過程的動(dòng)畫內(nèi)容包括兩個(gè)：
1荤胁、imageView的frame變成覆蓋整個(gè)屏幕瞧预；
2、imageView的layer.cornerRadius變成0仅政；
以上的代碼垢油，在iOS 10下沒有閃爍問題，但是iOS 11就會(huì)出現(xiàn)這個(gè)異常圆丹。
遇到代碼不同iOS版本的表現(xiàn)不同時(shí)滩愁，先查一下API的變動(dòng)。
查看蘋果的文檔后發(fā)現(xiàn)辫封，layer的cornerRadius屬性在iOS 11之前是不支持Block動(dòng)畫的硝枉。iOS 11之后新增了cornerRadius屬性的Block動(dòng)畫支持，但是明顯支持效果不是很好倦微。
Bug解決：
解決方案1：移除動(dòng)畫過程中cornerRadius的屬性變化妻味；
解決方案2：統(tǒng)一用CoreAnimation來實(shí)現(xiàn)；
小結(jié)：
模擬器先行欣福，真機(jī)驗(yàn)證责球。
模擬器具備多開的優(yōu)勢，可以同時(shí)打開多個(gè)系統(tǒng)的多個(gè)設(shè)備；但是因?yàn)槟M器的cpu架構(gòu)與真機(jī)不同雏逾，最終必須用真機(jī)驗(yàn)證裁良。
文檔為主，Google為輔校套。
iOS版本升級(jí)經(jīng)常引入Bug价脾，對(duì)于這種不同iOS系統(tǒng)導(dǎo)致的問題，需要查看文檔（文檔包括Xcode的頭文件以及自帶的文檔）笛匙，如果文檔找不到則用Google查找對(duì)應(yīng)的關(guān)鍵詞侨把。
iOS 11動(dòng)畫異常問題
功能背景：
正常的動(dòng)畫效果，比如微信的聊天圖片放大動(dòng)畫和手Q的頭像放大動(dòng)畫妹孙，如下圖：
Bug描述：
動(dòng)畫與正常有異秋柄，最明顯是出現(xiàn)這個(gè)情況：
上圖的三角形區(qū)域應(yīng)該是如下的區(qū)域：
功能實(shí)現(xiàn)：
猜測是用UIView的Block動(dòng)畫，或者CoreAnimation實(shí)現(xiàn)蠢正。
Bug定位：
Bug不限于普通app骇笔，在系統(tǒng)app也會(huì)出現(xiàn)這種異常，表現(xiàn)形式為：頁面切換卡頓嚣崭、動(dòng)畫執(zhí)行異常笨触。
Debug調(diào)試開發(fā)中發(fā)現(xiàn)，動(dòng)畫的animationBlock和completionBlock的調(diào)用時(shí)序是正常的雹舀。以頭像縮小的動(dòng)畫為例芦劣，以下是正常的動(dòng)畫時(shí)序：
從動(dòng)畫的異常表現(xiàn)上猜測，原因是動(dòng)畫延遲執(zhí)行说榆。
嘗試在completionBlock中改變背景顏色虚吟，可以看出動(dòng)畫還在執(zhí)行時(shí)，背景顏色發(fā)生了變化签财；
嘗試在動(dòng)畫開始改變視圖顏色串慰，可以發(fā)現(xiàn)動(dòng)畫執(zhí)行存在明顯的延遲；
可以確定：當(dāng)發(fā)生這個(gè)錯(cuò)誤之后唱蒸，動(dòng)畫的執(zhí)行實(shí)現(xiàn)會(huì)推遲邦鲫，導(dǎo)致completionBlock調(diào)用的時(shí)候動(dòng)畫仍在執(zhí)行，產(chǎn)生異常的現(xiàn)象油宜。
用下面的時(shí)序圖來描述：在第10s提交一個(gè)0.2s的動(dòng)畫掂碱，動(dòng)畫執(zhí)行完畢的時(shí)間是10.5s左右（正常應(yīng)該是10.2s)，動(dòng)畫延遲時(shí)間在0.2~0.4s區(qū)間慎冤。
通過KVO觀察layer的frame和presentationLayer的frame疼燥，整個(gè)動(dòng)畫過程的調(diào)用也是正常。
在模型樹=>呈現(xiàn)樹=>渲染樹這條鏈路上蚁堤，開發(fā)者通過代碼層面上只能獲取到前兩個(gè)環(huán)境的數(shù)據(jù)醉者，至此問題停止深入但狭。
只能把Bug總結(jié)為：iOS 11系統(tǒng)的手機(jī)在某些情況下會(huì)發(fā)生系統(tǒng)錯(cuò)誤，導(dǎo)致整個(gè)手機(jī)的動(dòng)畫機(jī)制出現(xiàn)異常撬即。
Bug出現(xiàn)之后立磁，無法通過代碼修復(fù)（iOS系統(tǒng)錯(cuò)誤），只能重啟手機(jī)剥槐。
Bug解決：
提示用戶重啟手機(jī)（可暫時(shí)修復(fù)）唱歧；
向蘋果提交Bug。
小結(jié)：
對(duì)于某些所有APP都存在的異沉Ｊ現(xiàn)象颅崩，歸類為系統(tǒng)級(jí)Bug，可以在developer.apple.com的Bug Reporter提交Bug蕊苗。
猜測沿后、定位到問題所在之后，可以嘗試修復(fù)朽砰，但是此Bug不在此列尖滚，不建議花費(fèi)過多精力。
iOS 11 下拉刷新異常問題
功能背景：
在某些頁面中瞧柔，存在下拉刷新/上拉加載更多的功能漆弄。
Bug描述：
iOS 11的手機(jī)，在下拉刷新之后非剃，會(huì)一直處于“加載中”的狀態(tài)置逻。
功能實(shí)現(xiàn)：
通過KVO監(jiān)聽tableView的屬性推沸，并判斷具體的操作备绽，最終通過自定義的dragDelegate回調(diào)。
Bug定位：
通過模擬器復(fù)現(xiàn)鬓催，發(fā)現(xiàn)iOS 10的模擬器正常肺素，iOS 11的模擬器存在此問題。
在后臺(tái)數(shù)據(jù)返回的接口處斷點(diǎn)宇驾，確定數(shù)據(jù)返回是否正常倍靡，發(fā)現(xiàn)iOS 11的模擬器根本沒有返回?cái)?shù)據(jù)。
據(jù)此回溯定位：后臺(tái)數(shù)據(jù)沒有返回=>客戶端沒發(fā)協(xié)議=>下拉刷新沒有回調(diào)课舍。
再從UIScrollView的delegate回調(diào)入手塌西，單步調(diào)試定位到問題：
UITableView iOS 11新增了一個(gè)屬性：dragDelegate，與開發(fā)者自定義的dragDelegate沖突筝尾！
Bug解決：
修改屬性名捡需，同時(shí)注意以后在給系統(tǒng)的類添加屬性時(shí)，需要加上自己的方法名前綴筹淫，防止與系統(tǒng)沖突站辉。
小結(jié)：
正向和逆向的鏈?zhǔn)椒治龇绞绞亲畛Ｒ姷腂ug定位方法；
對(duì)于實(shí)在無法定位時(shí)，再使用二分注釋的方法饰剥。
總結(jié)
iOS 11更新之后出現(xiàn)的問題比以往的版本更多殊霞，要求開發(fā)者需要投入更多的精力去適配，甚至?xí)嬖谝恍╅_發(fā)者無法修復(fù)的Bug汰蓉。為了iPhone X全新的交互體驗(yàn)绷蹲，iOS 11做了非常大的改動(dòng)，之前的beta版本問題更多顾孽。
善用Xcode的調(diào)試工作瘸右，勤看具體API的頭文件，遇到問題仔細(xì)分析岩齿。
無需對(duì)Bug產(chǎn)生厭惡和恐懼太颤，但也不要沉浸在單步調(diào)試和盲目嘗試的快感中。充分利用寶貴的時(shí)間盹沈，減少無用的步驟龄章，覺察自己解決Bug過程中的不足，盡量從解決問題中習(xí)得新的知識(shí)和方法乞封。
