最近我在看“ I am Zombie”，所以我就來看看iOS的這個工具啦，哈哈，一大群Zombies正在逼近！?。?/p>
什么是Zombie
是的，打開instruments之后其實會看到一個圖標(biāo)，這個圖標(biāo)多么讓人激動?。?！哈哈
我們順便來看下官方文檔的說法
The Zombies template causes persistent memory growth because it changes your environment so that deallocated objects are never technically deallocated. This is expected behavior, but it means that aside from zombie flags and memory address histories, any other statistics provided by the Allocations instrument should be ignored. You also shouldn’t add the Leaks instrument to the Zombies template, as it will produce inaccurate results. For iOS apps, use the Zombies template with the iOS Simulator, rather than a physical device.
不過我在嘗試的時候其實還沒有看到這段文字，所以我也是用了真機，不過卡的是一塌糊涂。我查了網(wǎng)上大部分的資料，有的會說Zombie不支持真機，其實就是rather than，你懂的，不過的確不建議用，本身調(diào)查的問題在這個環(huán)境上關(guān)系不大，更多的純粹就是代碼上的問題。
用白話文來解釋下吧，取名Zombie其實是有道理的，在iOS中我們經(jīng)常會有一些對象（雖然iOS在5.0之后引入了ARC）會手動或者自動被ARC銷毀掉，但是我們的程序可能并不知道對象不在了，還可能去調(diào)用它，導(dǎo)致了EXC_BAD_ACCESS的錯誤。當(dāng)然，如果程序簡單的話，很容易能夠排查出來，但是我們項目中大多是很復(fù)雜的，排查起來就有一定的困難。這個時候就會去使用Zombie工具來做輔助。注意，在專項里面工具都是輔助的，沒有一個工具是可以說你做了1，2，3，4步驟就知道問題在哪兒，幾乎沒有，所以專項并不是很多人想的那么簡單的。開啟Zombie有兩種方式，一種是通過instruments來直接使用，網(wǎng)上都會很推薦這種做法，還有一種就是在如下設(shè)置中去運行Zombie默認(rèn)就打包在app中，這種方法很不可取，因為一旦在上線之前忘記關(guān)閉這個選項的話可是毀滅性的。
簡單來講，Zombie會去取代那些已經(jīng)被銷毀的對象，讓這些對象并不是null的存在，而是僵尸的存在。這樣做的好處在于能夠給予我們更多的info來定位問題，而不好的話也是顯而易見的，上面官方的描述也寫的很清楚，一旦開啟full on Zombie mode（這個詞來自于美劇I am Zombie），那么你的應(yīng)用的內(nèi)存會不停的飆升，因為你的對象永遠都不會銷毀，直到app crash。所以這里大家要注意危險性。
什么是ARC
這其實要詳細了解，大家可以自行Google，這里我就隨便截圖一段，科普一下
Automatic Reference Counting，自動引用計數(shù)，即ARC，可以說是WWDC2011和iOS5所引入的最大的變革和最激動人心的變化。ARC是新的LLVM 3.0編譯器的一項特性，使用ARC，可以說一舉解決了廣大iOS開發(fā)者所憎恨的手動內(nèi)存管理的麻煩。
在工程中使用ARC非常簡單：只需要像往常那樣編寫代碼，只不過永遠不寫retain,release和autorelease三個關(guān)鍵字就好～這是ARC的基本原則。當(dāng)ARC開啟時，編譯器將自動在代碼合適的地方插入retain, release和autorelease，而作為開發(fā)者，完全不需要擔(dān)心編譯器會做錯（除非開發(fā)者自己錯用ARC了）。好了，ARC相當(dāng)簡單吧～到此為止，本教程結(jié)束。
什么是EXC_BAD_ACCESS
90%的錯誤來源在于對一個已經(jīng)釋放的對象進行release操作。不過的確看到這個缺陷，項目一復(fù)雜，很難去定位。
案例
所有說專項的沒有案例都是耍流氓，真心覺得這是真理。
我千辛萬苦的隨便找了一個案例，然后發(fā)現(xiàn)啟動之后就crash，我心都碎了，那么偶爾我們也要來修一次bug不是？基本上我縮小了范圍，錯誤代碼如下：
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// Override point for customization after application launch.
// Add the navigation controller's view to the window and display.
[self.window addSubview:navigationController.view];
[self.window makeKeyAndVisible];
return YES;
}
錯誤信息如
2015-09-25 21:32:05.749 Zombie[24745:854954] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Application windows are expected to have a root view controller at the end of application launch'
反正我是不懂，經(jīng)過了Google之后，我發(fā)現(xiàn)是iOS本身API的改變，應(yīng)該如下修改
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// Override point for customization after application launch.
// Add the navigation controller's view to the window and display.
- [self.window addSubview:navigationController.view];
+ [self.window setRootViewController:navigationController];
[self.window makeKeyAndVisible];
return YES;
}
好了，一切就妥妥的了。經(jīng)過一系列的操作之后我們可以看到：
類似的錯誤，然后可以看到如下的錯誤時候的信息
好了，接著讓我們開啟full on Zombie Mode吧。使用Zombie來啟動我們的應(yīng)用，按照同樣的操作，我們可以看到crash的時候會出現(xiàn)一個小的紫色旗子，上面的信息告訴我們，明顯是一個消息發(fā)給一個已經(jīng)被干掉的對象。
我們可以點擊Zombie這條額外信息的右邊的小箭頭，可以看到如下的信息
這里我們可以看到有AutoRelease指向了我們的Zombie project，我們點擊進入可以看到：
這里的lastString是一個AutoRelease的變量，而_lastString是指向這個字符串的指針，所以當(dāng)被自動釋放的時候，_lastString就指向了一個null，從而就變成了我們最早看到的那個錯誤。
至此，我們其實只要將lastString手動的保留一下retain，這個程序就不會再crash了。不過這個程序的確還是存在很多的內(nèi)存泄漏，作為之后的案例還是很不錯的。
