iOS各類調試技巧豪華套餐（轉） iOS各類調試技巧豪華套餐

 

iOS各類調試技巧豪華套餐

 

 

目錄　　

前言
逼優雞
知己知彼 百戰不殆
抽刀斷Bug
　　普通操做
　　全局斷點（Global BreakPoint）
　　條件斷點(Condational Breakpoints)
打印的藝術
　　NSLog
　　開啓殭屍對象(Enable NSZombie Objects)
進擊的碼農
　　Console(lldb 命令)
　　Profile(instruments)
　　Xcode視圖調試
結語

前言

最近博主臨近畢業季，爲了完美的寫一篇畢業論文，真是：「鋤禾日當午，汗滴禾下土」<—— 這句詩跟畢業我寫畢業論文沒任何一毛錢關係，我就是忽然想吟溼了。不過博主做爲網絡工程專業的好青年，曾經的願望和理想就是在下水道幹出一番轟轟烈烈的大事業，沒錯是就是下水道，咱們的征途在下水道！！不過你們別誤會，我不是忍者龜的腦殘粉！聽我繼續說！我想的是等我在各大排水系統各大下水道功成名就的時候，我就能夠指着一個井蓋對個人孫子說：「諾 那個下面的通訊光纜是爺爺我接的！！」 我滿臉自豪地接受着這孫子的敬仰！可是啊，曾經的願望都實現不了了，我深深愛着的地下通訊光纜啊，曾經多少個夜晚淚水打溼了個人畢業論文，渲染開的筆墨那都是哥逝去的青春啊。

由於生活就像開了博主一個玩笑，讓博主遇到了一種雞，那是一種特殊品種的雞，它叫作逼優雞！！就是這隻雞讓博主平白無故的成了一隻APM超200的野生究極程序猿！！吼~ 嗷~，把博主帶離了下水道！而且與這隻雞踏上另外一端征途！臨走的時候，下水道的通訊光纜就交給大家了，肥皂基友們(網絡工程的基友們)！！我靠，他們居然在打印店花了50塊錢就直接買了一套深度豪華畢業論文套餐！裏面包含了論文，工程製圖，CAD，報價清單，拓撲結構……最重要的是老闆承諾不需任何修改，直接能夠經過畢業答辯，不經過來年免費再提供一套論文，最貼心的是居然支持經過再付款！！，
圖1

老子寫論文寫了半個月像狗同樣，他們居然直接就買了！就這麼買過去了！！對得起老師的諄諄教誨、本身的辛苦付出和父母的期待麼？我就問大家慚愧不慚愧？爲何買的時候不喊上我？淚已淌幹~

扯蛋過多容易腎虧

 

逼優雞

終於來到了你們期待的正片，今天我就要和你們講我和逼優雞的故事，逼優雞它優雅低調，它身材玲瓏，藏匿在黑暗處，挑動着個人慾望！曾多個日夜博主都……（擦！尼瑪，逼優雞是什麼鬼？說好的技術文章?）同窗你真的(biè)急，你先坐下，先把鞋子穿好！我說的逼優雞它的英文名叫作(Bug)，它挺(T)美(M)的(D)……
歌仔唱的好：
多少猿曾被它奪走年輕的容顏
多少猿曾在它面前亮門禿了頭
多少Bug曾經生命中來了又還
可知一輩子有你我都陪在你身邊
圖2

無數個夜晚你揪着頭髮和Bug撕咬的情景博主能夠體會，因此此次的這篇文章博主就要給你們整理一個調教iOS逼優雞的方法豪華套餐！！放心！絕對的深度豪華，由於已經加入肯德基豪華午飯~咳咳~實際上是由於逼優雞(Bug)對於咱們畢竟是除了老婆以外第二可怕的存在！咱們必需要練就銅頭鐵臂十八般武藝，祭練奇門巧技各類大殺！方可與之周旋並將之殲滅！好！跟着博主一塊兒裝逼一塊兒飛吧！！！！

第一步：
我看你們蓬頭垢面的就知道你們剛剛也才debug回來 ，咱們就先寫個hello world壓壓驚把！
第二步
……

 

知己知彼 百戰不殆

此處爲大量Copy！不喜請噴！

The software doesn't do something that the product specification says it should do.
The software does something that the product specification says it shouldn't do.
The software does something that the product specification doesn't mention.
The software doesn't do something that the product specification doesn't mention but should.
The software is difficult to understand, hard to use, slow, or in the software tester's eyes will be viewed by the end user as just plain not right.

我不是英文教師，請你們自行切換多語言閱讀模式。
也還有有人粗暴的定義 」Bug就是錯誤「，除了世界上第一隻Bug是飛進去的那隻蟲子外，其餘Bug毋庸置疑那都是程序員們本身生下來的！程序員們本身犯的錯誤！若是說一個軟件做品(請尊重你本身的做品，不要喊他們」產品」或者」項目」)是程序員們本身的孩子，那麼Bug就是這個孩子的生的病，有病得治，藥不能停！生病有各類治療方法，物療，理療，化療，心理療……那麼「治療」Bug也是有多中方法的！下面博主會一一列舉！懲治這些個Bug以前，博主要先阿拉巴拉一番，遇到Bug也是一件比較嗶了狗了的事情，你要知道任何人都會生病，沒有例外！全部任何代碼都有Bug這是定理，咱們首先要從心態上端正Bug這件事情，咱們能夠理解爲缺憾也是一種美，就像阿雨說的「沒有皺紋的祖母是可怕的，沒有白髮的老者是讓人遺憾的。沒有廢墟的人生太累了，沒有廢墟的大地太擠了，掩蓋廢墟的舉動太僞詐了。」Debug是爲了證實程序有錯，而不是證實程序無錯誤；因此咱們要作到臨Bug而不懼者,聖人之勇也！因此咱們要作到戰略上藐視它，戰術上重視它！你要心理默唸Bug其實挺(T)美(M)的(D)!anyway 無Bug不生活！！

 

抽刀斷Bug

斷點，（我求大家不要想到張敬軒，阿軒他容易麼，小受又怎麼了？大家這幫人真是的！！），我要說的斷點是BreakPoint！基本上不是殘廢的IDE都具備斷點調試功能吧！尤爲是XCode，咱們家的IDE斷點調試功能但是強中又是強中手！在這以前你們能夠先了解一下哈子是斷點？它怎麼實現的？工做原理怎麼樣的？博主就獻醜說說本身的理解吧，斷點，顧名思義就是從前有一個點，後來它斷了，謝謝，個人故事講完了。哎喲還不服，這些基礎常識的東西本身不會查？你還真的臉皮厚上天了去了，還要博主給你查喲，本身查去！

普通操做

如圖3

基本的斷點操做以下

圖4

 

點擊那個黑列列就建立了一個斷點，再次點擊就臨時取消這個斷點(可是不刪除)，長按那個斷點拖出去就刪除了(mac os的系統工程師就是稀飯拖動的快感)，固然也能夠右鍵那個建立的斷點，會彈出相應地菜單。
固然也還能夠監視某個變量！
圖5

在對象視圖中，右鍵某個對象，點擊「Watch ‘XXX’」就完成XXX對象的監視了。

這裏我監視了lab這個UILabel的變量，每當這個變量進行更新它的信息就會被打印到控制檯。
好吧！咱們最基本的建立斷點的工做已經學會了，Xcode舒服在什麼地方呢？就是不分Debug模式和Run模式的，能夠說是無縫切換的，你只要沒有建立斷點，那麼就是Run的正常模式，若是建立了斷點而且運行到斷點處，就自動進入Debug模式咯，不像某EC開頭的IDE，控制面板就像開飛機的同樣，幾萬個按鈕覺得很強大，其實只用了Run和Stop，還有什麼Debug模式，App模式……，果真Xcode的優越感在對比中更增強烈了，舒服到極點呀，就像夏天的海風拂過菊花，嗯是的 就是那種感受！
咱們建立好了斷點，運行到斷點就自動停下來了，像這樣：
圖6

這些Debug的最基本操做技能是每個入門的iOS開發者都要掌握的，應該當成一種本能，就像狗愛吃翔同樣(噢 對不起 博主不是歧視狗的意思，博主也養過狗，很二逼可是從不吃翔！真的據我所知它歷來不吃翔的，這裏只是比喻只是比喻)。

 

全局斷點（Global BreakPoint）

有時候在程序出錯的時候不能能準肯定位到奔潰的那一行代碼,而是直接跑到main循環或者Appdelegate裏面， 或者會給你這樣的提示：

EXEC_BAD_ACCESS：

是否是有種想哭的衝動？尼瑪~至少給我一些堆棧信息也好呀~……這個時候你千萬不要砸鼠標和鍵盤哦，一切都是主機在運行，你砸鼠標和鍵盤有什麼用呢？應該是踢主機呀~~，如今有了全局斷點，孃親不再擔憂你砸鼠標了，你只須要這樣：
圖7

在Debug導航面板進行上圖的操做，你就創建了全局斷點，這樣只要遇到錯誤，debug程序就會自動定位到棧底的信息，也就是你最早出錯的代碼的那一行，這樣你就能夠快樂的debug拉~~

 

條件斷點(Condational Breakpoints)

從前有一個遊戲，叫作擼啊擼，有些玩家他們知道怎麼操做，會放技能會走路，可是他們不知道買裝備，玩了一局下來，鞋子小刀都沒有買。我爲何講這個故事呢？由於不少小朋友學東西和玩遊戲同樣，看完前面的幾種調試技能，就覺得本身已經屌爆無敵了，其實他們不過是出門不帶裝備的玩家，若是隻是使用了以上的調試技能只能說是低玩，在高大的逼優雞面前根本就是會被瞬秒的那種，因此學會裝備本身才是王道！條件斷點，就是學會有的放矢！

咱們來看一段代碼
圖8

你是否是想問博主爲什麼那麼風騷，居然上了Swift了！！我此刻只想吟一首溼：別人笑我太淫蕩，我家住在黃鶴樓。
反正這個年代你們都是吃飽了撐着的，博主也是，因此就學學Swift咯。
咱們若是在一個循環裏面使用了斷點，若是這個循環執行了100萬次，那你的斷點要執行那麼屢次，你不以爲蛋蛋都涼了的憂傷麼？因此咱們這麼作：
圖9

這樣只有遍歷到c==「H」的時候 斷點纔會被觸發。

圖10

是否是很棒呢！
有些童鞋的鈦合金狗眼已經看到了編輯斷點那裏有一個Action的東西，那是什麼呢？
這個是很是強大的，能夠在你斷點的位置，執行各類操做，好比執行腳本命令，控制檯命令(能夠制定調試信息自定義保存)、打印信息等，
博主最喜歡的就是這個Log message啦，簡單粗暴！根本就不須要print啊NSLog嘛，直接在斷點的Action打印就行了（其實這個是Xcode和調試器結合的高能產物，下面再介紹）。具體能夠這樣：
圖11

其實剛剛博主撒謊了，博主最喜歡的Action並非Log Message，而是Sound，顧名思義嘛，斷點射在Bug上，這樣遇到斷點就會發出聲音，聽到我本身設置的聲音，我就知道是什麼Bug了，聽聲識Bug，呵呵，EXEC_BAD_ACCESS的錯誤我設置成了波多野老師的聲音，unrecognized selector send to instancd的錯誤我設置成了蒼老師的…… 不要問我係統怎麼沒有吉澤明步的聲音，我根本就不知道誰是吉澤明步。

固然還有更增強大的條件斷點就是這貨啦
圖12

添加以後在 Symbol 一欄輸入 viewDidLoad。
這樣一來，在程序中全部的 viewDidLoad 方法被調用時都會觸發斷點。
圖13

固然，咱們也能夠僅僅爲特定的某個類的方法添加斷點。在 Symbol 一欄輸入 [ClassName viewDidLoad] (Objective-C) 或 ClassName.viewDidLoad (Swift) 便可。
好比：unrecognized selector sent to instance 0xaxxxx 這種錯誤，這個instance能夠這樣快速定位
圖14

 

 

打印的藝術

儘管ARC已經讓內存管理變得簡單、省時和高效，可是在object的life-cycles中跟蹤一些重要事件依然十分重要。畢竟ARC並無徹底排除內存泄露的可能性，或者試圖訪問一個被release的對象。爲了這個目的，咱們能夠很藝術地偷窺對象正在作些什麼，想一想就好有快感。

NSLog

小夥伴們第一節課學習ViewController的生命週期的時候，老師確定很猥瑣的教了你們，在viewController的每一個生命週期的方法中使用了NSLog來偷窺！沒錯，這樣其實就是最簡單爆炸的跟蹤生命週期的方法了，不過系統本身的NSLog真心有點羸弱，輸出的信息太少，根本就不能知足咱們的慾望，這裏我教你們強化你的Log！！
能夠用下面的這段宏

//A better version of NSLog #define NSLog(format, ...) do { \ fprintf(stderr, "<%s : %d> %s\n", \ [[[NSString stringWithUTF8String:__FILE__] lastPathComponent] UTF8String], \ __LINE__, __func__); \ (NSLog)((format), ##__VA_ARGS__); \ fprintf(stderr, "-------\n"); \ } while (0)

 

關於宏的威力 你們能夠亂入個人博文《 iOS中的預編譯指令的初步探究》
這樣打印出來的東西纔像話嘛(其實NSLog的打印是很是低效的，甚至比print低100倍，感興趣本身翻翻蘋果手冊咯)。 
使用objc語言(強類型)而且用NSLog打印的時候，經常搞不清楚NSLog(@「%?」,xxx) xxx這種類型該是什麼什麼類型輸出，應該是%d呢仍是%@亦或是%f？？？傻傻分不清楚~，因此玩轉NSLog你應該要知道如下這幾個全局方法！
圖17

開啓殭屍對象(Enable NSZombie Objects)

Xcode能夠把那些已經release掉得對象，變成「殭屍」，當咱們訪問一個Zombie對象時，Xcode能夠告訴咱們正在訪問的對象是一個不該該存在的對象了。由於Xcode知道這個對象是什麼，因此可讓咱們知道這個對象在哪裏，以及這是何時發生的。
因此Zombies是你的好基友！他可讓你輸出的信息更具體！！
具體這樣作：
圖15

本身再試試輸出Object的信息咯，是否是很棒呢？
殭屍只能用在模擬器和OC語言哦~

 

進擊的碼農

若是說你已經把打印的藝術運用的風生水起了，而且斷點的使用能夠信手拈來爲所欲爲，那麼你已經在與逼優雞的對峙中，穩操大部分勝券了，你已是一個孤高冷豔的程序員了，俯視一切低能的逼優雞了！可是！面對更強大的敵人——你那禿頂1000°近視牙齒夾着韭菜的有着十年對戰逼優雞的同事面前、以及笑裏藏刀眼睛有眼屎可是能用眼神殺死你的面試官…… 對於他們，你仍是太弱，你的技能的磨練還太少！因此你必需要進擊！！比逼優雞還要強大的敵人出現了！咱們須要更強大的武器。

Console(lldb 命令)

咱們的目標是要武裝到鼻毛！console窗口你們知道就是哪一個黑乎乎好多字會滾出來，尤爲是被逼優雞幹到的時候，那麼同窗們有沒有遇到這種console呢
圖16

咱們家的編譯器歷史 敬請亂入 《iOS中的預編譯指令的初步探究》 ，沒錯咱們如今正在使用着世界上最好的c、c++、oc、swift的編譯器——LLVM,lldb就是這個世界上最好的LLVM的調試器！不要害羞，由於咱們是最優秀的！因此確定要用最好的！千萬別客氣喲，隨便用，就像本身家同樣啊，啊 哈哈 吃吃吃 別隻顧着吃飯，多夾菜……哎~博主好客的職業病又犯了~，什麼？你不知道在哪裏用lldb？
首先！你得先crash或者把程序斷下來！直到你看到圖16的(lldb)字樣出現，你就能夠敲命令了~~
每次你想查看變量，常量，你要從新寫NSLog去打印，而後從新編譯，去執行，重頭開始？太累了，有了lldb你只要這樣
圖18

是否是方便到爆炸？
當你有一個switch語句，你爲了測試每個case，你都要製造假條件去測試；有一個if…else…語句，你爲了測試不一樣的狀況，你要硬編碼寫了不一樣的狀況，編譯好幾回爲了測試每種狀況……，我想你應該知道爲何本身的頭髮那麼稀疏了。
以上的這些狀況，只需一次編譯，使用lldb的thread命令，僞造返回值，欺騙寄存器，就能夠爲所欲爲的作完全部測試了。
是否是牛逼到爆炸？
lldb真的很強大，博主沒有騙你，這篇博文到此的全部調試技巧lldb均可以實現，各類斷點，各類打印，調用python插件，運行中斷，操做硬件底層，控制程序運行線程……lldb均可以作到！彷彿lldb就是另外一個強大的世界！！！
是否是強大到爆炸？
其實若是你不想貪多嚼不爛的話，你只要精通這個調試工具，基本前面的調試技能你能夠不用學了，在這裏博主也是不才，lldb的強大不是博主隨便說幾句就能夠表達的出來的， 
更多地須要你們事必躬親，才能真正體會到那種美好，那種暢快無比的調試體驗！
這裏博主無私地掏出任意門，這裏有很好的文章！可讓你好好的回味，呵呵
《The LLDB Debugger》
《About LLDB and Xcode》
《LLDB調試命令初探》
《與調試器共舞 - LLDB 的華爾茲》

 

Profile(instruments)

 

圖19

這個東西怎麼翻譯呢？咱們就叫檢查器吧！！也許已經學習了iOS開發大半年的你，歷來都沒注意到或者使用這個工具，可是博主很負責任的告訴你如今市面上任何一款出色的APP都會使用instruments來讓代碼更加健壯！難道instrument是春藥？怎麼會使代碼健壯呢？
這個健壯不是那個健壯~哎~~ 我才18歲能不能清純一點呀

instrument裏面包含了不少工具，內存溢出分析，性能分析，各類分析…… 若是細說的話，這個真的能夠爲每一個工具開一篇博客，可是博主是一個懂得授人以魚不如授人以漁的道理的老司機！因此博主固然不會所有說一遍！咱們就來領着你們看看專用debug的內存溢出分析工具的使用吧！
圖20

在使用leaks以前你們能夠試試這個「Analyze」
圖21

analyze能夠快速的發現你的代碼中release的問題，以及繼承過程當中的父類方法缺失等等問題！通常一個優秀的iOS開發工程師No Warning、Pass Analyze是最基本的操守！我知道你已經對於你本身的項目的上百個warning已經麻木了，但博主我負責人地告訴你，這樣很差！，由於有一首雲南民歌《老司機帶帶我》聽得博主神清氣爽！

堅守做爲iOS開發者的貞操！跟着我高喊口號！

No Warning！Pass Analyze！

咱們繼續回來使用leaks！若是analyze都經過了，那麼就可使用leaks工具，發現千年老妖級別的側漏了！
圖22

若是提示某一個對象有側漏的風險，你還能夠這樣彈出側邊的拓展細節
圖23

直接點擊方法就能夠直接進入代碼部分了！！
是否是很簡單粗暴呢！固然還不少其餘工具，不過叫作篇幅的東西老是限制人，誒 真蛋疼~真的還想多說點的 
想要更多瞭解instrument 你們能夠看看這篇文章！
《How to Use Instruments in Xcode》

 

Xcode視圖調試

有時候有些逼優雞隱藏的比較深，代碼幾乎都翻了個遍，仍是沒找到問題出在哪，博主能夠理解那種風中凌亂，蛋碎一地的趕腳，由於無數個日夜博主就是深陷當中沒法自拔，後來乾脆直接從新新建一個工程！仍是不行！！我去，直到有一天博主早上起來，看到鏡子中本身帥氣的臉龐，我才忽然頓悟，原來長得帥能夠那樣快速的找到bug！最終鎖定是可愛又可恨的xib和storyboard出了問題！！某個constraint或者view的嵌套邏輯又或者團隊協做Git衝突等等問題，致使io -v什麼的錯誤，這種狀況去檢查視圖文件，可能xcode崩潰打不開那個xib或者storyboard，你直接使用文本工具打開這個xml類型的標記文件，你差點吐血，幾萬行的記錄狗眼都看瞎了……。

可是這個歷史要被終結！！由於咱們強大的xcode的視圖調試功能！！

如下內容，徹底copy，若有不適，堅持看完！請叫我快樂的搬運工！
抄襲自《View Debugging in Xcode 6》
蘋果在Xcode 6中作了很多明顯的改善和優化，視圖調試就是其中之一。一般，App用戶界面的行爲不會符合開發者指望的那樣，好比或者不展現視圖，或者沒有正確地展現。本文講解如何使用Xcode的新的視圖調試功能來簡化開發者對問題界面的確認和修復。

1.Demo 工程

開始之初先從github（https://github.com/tutsplus/ViewDebugging）上下載示例工程並打開ViewDebugging.xcodeproj。該工程包含一個簡單的包含少數視圖控制器的可點擊的應用程序、應用程序委託以及一個storyboard。該app是爲iPhone而設計，但受益於iOS 8的自適應佈局,因此界面展現在任何設備上都沒有問題。

您剛剛下載的應用程序示例工程是一個簡單的to-do list應用程序，包含可查看其餘信息的簡單屏幕，好比該示例工程中的項目數，用戶頭像以及@***的推特操做。點擊Xcode左上角的運行按鈕將展現在iOS模擬器中運行的應用程序。
圖24

很快會注意到用戶界面中存在問題-表視圖中沒有展現任何數據。在工程導航面板中打開FirstViewController.swift並找到如下代碼：

var mockNotesDataSource: [String] = ["Do some laundry", "Finish homework", "Walk the dog", "Learn about view debugging"] { didSet { self.tableView.reloadData() } }

 

能夠看到mockNotesDataSource變量是表視圖的數據源。使用Swift的屬性觀察者功能，在數據源發生改變時，表視圖會自動從新加載。經過查看以上代碼片斷，你會發現應該應用中應該有4個項目須要展現，但如今不展現數據就說明某些地方出現了差錯。

啓用視圖調試

問題彷佛與用戶界面有關。運行app過程當中，按下底部的Debug View Hierarchy 按鈕，或者從菜單中選擇Debug > View Debugging > Capture View Hierarchy 來啓動視圖調試。

圖25

啓動視圖調試後，Xcode會對應用程序的視圖層次拍一個快照並展現三維原型視圖來探究用戶界面的層級。該三維視圖除了展現app的視圖層次外，還展現每一個視圖的位置、順序和視圖尺寸，以及視圖間的交互方式。

示例工程在Xcode中的三維視圖展現正常，但表視圖單元格彷佛有點太寬了。
圖26

暫停應用程序調試並在左側選中Main.Storyboard來修復問題。點擊表視圖並選中Editor > Resolve Auto Layout Issues > Reset to Suggested Constraints.
圖27

編譯並再次運行應用程序以肯定用戶界面展現正常。點擊Debug View Hierarchy按鈕更進一步瞭解視圖調試的功能。

視圖調試功能

點擊並拖拽三維渲染圖的任意一邊，可旋轉或者傾斜用戶界面，向左或者向右傾斜可選中某個表視圖。

選中後，Xcode會高亮該視圖，並在會在右邊展現Object 和Size檢查器。查看在跳轉欄頂部並確認UITableView是右邊最後一個項目。
圖28

Object 和 Size檢查器包括大量有用的信息。過去開發者須要依賴日誌語句或者斷點來檢查視圖的配置。

打開右邊的Size inspector（規格檢查器），下方是Auto Layout，能夠看到視圖上已經應用了正確的約束。在Object inspector中，咱們能夠檢查所選視圖的屬性。
圖29

在Xcode的調試區有9個視圖調試過程當中要用到的按鈕和滑塊兒。
圖30

從左到右控件排序：

調整視圖間距：調整不一樣視圖間的間距。

展現被剪切的內容：當前展現視圖中被剪切的部分。

展現約束：展現選中視圖的約束。

重置查看區域：將3D渲染透視圖恢復至默認狀態。

調整查看模式：選擇性地展現3D渲染透視圖，好比僅展現內容，僅展現框架以及同時展現內容和框架。

縮小：縮小3D渲染透視圖

恢復：將3D渲染透視圖恢復至默認尺寸。

放大：放大3D渲染透視圖

調整可視視圖範圍：隱藏視圖或展現視圖，一步步解析3D渲染視圖，向左或者向右滑動滑塊兒有相反的效果。

建議花一點時間上手操做下這些空間，並理解各自的用處。

視圖層排序

再次編譯和運行應用程序，並點擊用戶界面底部的"More"標籤。第一眼看去界面看起來還OK，可是它沒有按照開發者的定義準確執行，圖片上的模糊效果沒有展現出來。咱們能夠經過調試視圖層次來更好地肯定問題所在。

向左或者向右拖拽視圖來查看具體狀況，接着將view spacing slider向右拖動。
圖31

這樣一來，不一樣視圖間的間距變大了，層次也更加清晰，咱們看到在圖片"下方"還隱藏着另外一個視圖，選中隱藏的視圖，它就是"丟失"的視覺效果視圖。
圖32

打開Main.storyboard 並選中Second View Controller Scene。在左側的文檔概覽面板中，展開Second View Controller的視圖對象以查看子視圖的排序。

Xcode在文檔概覽中按照遞升順序堆疊視圖，換句話說，列表頂層的視圖是視圖層次的基礎。

修復問題很簡單。運行時，Blur Effect View隱藏在Sky Image之下，由於它是視圖層次的第一個視圖。在文檔概覽中點擊並拖拽 Blur Effect View，結果會以下圖展現同樣：
圖33

再次運行應用程序就能看到模糊效果了。應用程序的用戶界面看起來符合設計的初衷。咱們還能夠查看iOS模擬器的其餘調試功能，看看還完善了其餘什麼地方或功能。

5.iOS模擬器調試功能

編譯並運行應用程序，選中模擬器，從 Debug菜單中選擇Color Blended Layers選項。
圖34

而後會看到app的用戶界面被紅色和綠色覆蓋，顯示了哪些圖層能夠被疊加覆蓋，以及哪些圖層是透明的。混合層屬於計算密集型視圖，因此推薦儘量地使用不透明的圖層。
圖35

蘋果在其文檔（iOS Simulator User Guide）中對此進行了註明，並在表視圖處理上使用了不透明圖層。滾動視圖時會有些表現不大好的地方，一個重要的緣由就是使用了混合圖層，而若是內容背景是不透明層，那麼頁面滾動效果就會很是流暢和平穩。

對於這款應用程序來講，假使用戶有數百個項目要展現，可能會出現滾動性能不一致的狀況。表視圖單元格當前使用的是混合層。因爲視圖控制器的視圖背景是白色，因此無論表視圖單元格使用的是混合層或者不透明層，終端用戶不會覺察到有什麼不同。

打開Main.storyboard並選中To Do list Scene中的表視圖單元格屬性。在屬性檢查器（Attributes Inspector）中，向下滾動Drawing分區並勾選Opaque。
圖36

在啓用Color Blended Layers的狀態下編譯並運行應用程序。因爲表視圖單元格如今使用了不透明層，因此會用綠色覆蓋，以指示它們是不透明的。

除了標記圖層外，還有其餘一些有用的功能可幫開發者在iOS模擬器中調試應用。如下是其中一些比較有用的：

Toggle Slow Animations in Frontmost App: 選中模擬器，打開Debug菜單選中Toggle Slow Animations in Frontmost App，該功能能夠下降app中動畫的運行速度，適合調試包含複雜動畫的應用程序。也但是使用快捷鍵Command-T來操做。
Color Copied Images:該選項能夠給繪製時被Core Animation複製的圖片添加藍綠色疊加層。
Color Misaligned Images:若是圖片邊界沒有與目標像素完美對齊，該功能可爲圖片疊加上一層品紅色。若是圖片使用肯定的比例大小繪製，那麼該功能會爲圖片添加一層黃色疊加。
Color Off Screen Rendered:.該選項爲離屏渲染內容添加一個黃色的疊加層。
不少開發者會忽略接入電話時應用狀態欄的設計問題，你能夠經過觸發通話中狀態欄來簡單測試。在iOS模擬器中，從Hardware菜單中選中Toggle In-Call Status Bar。

想查看app如何響應事件，可按下Command-T來啓用slow animations，並按下Command-Y來展現電話接入時的狀態欄。假若你的應用程序使用了導航欄，那麼操做系統會爲你兼顧到這一起。
圖37

除了給視圖着色外，還要記住iOS模擬器也能夠調試Core Location問題。你能夠在特定經緯度模擬設備，

若是你的應用程序使用iCloud來管理數據，你也能夠手動觸發同步事件。

本文中使用的demo app很是簡單，使用文中提到的技術能夠幫你在將來節省很多時間。視圖調試能夠幫你修正不少用戶界面中出現的問題。

除了Xcode和InterfaceBuilder以外，使用iOS模擬器的調試功能能夠提高應用性能和識別開發過程當中的瓶頸。蘋果的人機交互指南（中文版 英文版）強調了積極響應對app的重要性，能讓用戶以爲應用易於使用和操做。蘋果對InterfaceBuilder的提高讓視圖調試變得史無前例的簡單。

結語

這篇文章博主花了3個禮拜，斷斷續續才寫完的，當中錯漏應該很是多，可是不管如何鄙人以爲應該算是配的上豪華套餐的稱號了，當中iOS開發的基本、經常使用以及高階的調試技能都涉及了，可是仍然有不少其餘的奇門巧技沒有介紹到，主要是可惡的「篇幅」限制住了博主廣博的愛，可是不管如何，這篇文章你們暫且能夠當作是一個調試技術的目錄，由於博主在這裏寫的講的很粗淺，你不該該只知足於這篇文章，你若是想要改變世界的話，你應該藉着博主的這篇目錄式文章深刻地學習與研究！

固然還有Crash的日誌、測試工程、以及強大牛逼哄哄的第三方調試庫等這篇博客沒有涉及到，這是一個遺憾，可是我相信聰明的你會去Google一番的！

還有咱們與逼優雞的故事纔剛剛開始

 

本文是我在其餘地方看到的，以爲不錯。分享給你們。原文地址：http://www.cnblogs.com/daiweilai/p/4421340.html