1. 如何追蹤app崩潰率，如何解決線上閃退
當iOS設備上的App應用閃退時，操作系統會生成一個crash日志，保存在設備上。crash日志上有很多有用的信息，比如每個正在執行線程的完整堆棧跟蹤信息和內存映像，這樣就能夠通過解析這些信息進而定位crash發生時的代碼邏輯，從而找到App閃退的原因。通常來說，crash產生來源于兩種問題：違反iOS系統規則導致的crash和App代碼邏輯BUG導致的crash，下面分別對他們進行分析。
違反iOS系統規則產生crash的三種類型
- 內存報警閃退當iOS檢測到內存過低時，它的VM系統會發出低內存警告通知，嘗試回收一些內存；如果情況沒有得到足夠的改善，iOS會終止后臺應用以回收更多內存；最后，如果內存還是不足，那么正在運行的應用可能會被終止掉。在Debug模式下，可以主動將客戶端執行的動作邏輯寫入一個log文件中，這樣程序童鞋可以將內存預警的邏輯寫入該log文件，當發生如下截圖中的內存報警時，就是提醒當前客戶端性能內存吃緊，可以通過Instruments工具中的Allocations 和 Leaks模塊庫來發現內存分配問題和內存泄漏問題。
- 響應超時當應用程序對一些特定的事件（比如啟動、掛起、恢復、結束）響應不及時，蘋果的Watchdog機制會把應用程序干掉，并生成一份相應的crash日志。這些事件與下列UIApplicationDelegate方法相對應，當遇到Watchdog日志時，可以檢查上圖中的幾個方法是否有比較重的阻塞UI的動作。
application:didFinishLaunchingWithOptions:
applicationWillResignActive:
applicationDidEnterBackground:
applicationWillEnterForeground:
applicationDidBecomeActive:
applicationWillTerminate:
- 用戶強制退出
一看到“用戶強制退出”，首先可能想到的雙擊Home鍵，然后關閉應用程序。不過這種場景一般是不會產生crash日志的，因為雙擊Home鍵后，所有的應用程序都處于后臺狀態，而iOS隨時都有可能關閉后臺進程，當應用阻塞界面并停止響應時這種場景才會產生crash日志。這里指的“用戶強制退出”場景，是稍微比較復雜點的操作：先按住電源鍵，直到出現“滑動關機”的界面時，再按住Home鍵，這時候當前應用程序會被終止掉，并且產生一份相應事件的crash日志。
應用邏輯的Bug
大多數閃退崩潰日志的產生都是因為應用中的Bug，這種Bug的錯誤種類有很多，比如SEGV：(Segmentation Violation，段違例)，無效內存地址，比如空指針，未初始化指針，棧溢出等； SIGABRT：收到Abort信號，可能自身調用abort()或者收到外部發送過來的信號； SIGBUS：總線錯誤。與SIGSEGV不同的是，SIGSEGV訪問的是無效地址（比如虛存映射不到物理內存），而SIGBUS訪問的是有效地址，但總線訪問異常（比如地址對齊問題）； SIGILL：嘗試執行非法的指令，可能不被識別或者沒有權限； SIGFPE：Floating Point Error，數學計算相關問題（可能不限于浮點計算），比如除零操作； SIGPIPE：管道另一端沒有進程接手數據；
常見的崩潰原因基本都是代碼邏輯問題或資源問題，比如數組越界，訪問野指針或者資源不存在，或資源大小寫錯誤等。
crash的收集
如果是在windows上你可以通過itools或pp助手等輔助工具查看系統產生的歷史crash日志，然后再根據app來查看。如果是在Mac 系統上，只需要打開xcode->windows->devices，選擇device logs進行查看，如下圖，這些crash文件都可以導出來，然后再單獨對這個crash文件做處理分析。
市場上已有的商業軟件提供crash收集服務，這些軟件基本都提供了日志存儲，日志符號化解析和服務端可視化管理等服務：
- Crashlytics (www.crashlytics.com)
- Crittercism (www.crittercism.com)
- Bugsense (www.bugsense.com)
- HockeyApp (www.hockeyapp.net)
- Flurry(www.flurry.com)
開源的軟件也可以拿來收集crash日志，比如Razor,QuincyKit（git鏈接）等，這些軟件收集crash的原理其實大同小異，都是根據系統產生的crash日志進行了一次提取或封裝，然后將封裝后的crash文件上傳到對應的服務端進行解析處理。很多商業軟件都采用了Plcrashreporter這個開源工具來上傳和解析crash，比如HockeyApp,Flurry和crittercism等。
由于自己的crash信息太長，找了一張示例：
- crash標識是應用進程產生crash時的一些標識信息，它描述了該crash的唯一標識（E838FEFB-ECF6-498C-8B35-D40F0F9FEAE4），所發生的硬件設備類型（iphone3,1代表iphone4），以及App進程相關的信息等；
- 基本信息描述的是crash發生的時間和系統版本；
- 異常類型描述的是crash發生時拋出的異常類型和錯誤碼；
- 線程回溯描述了crash發生時所有線程的回溯信息，每個線程在每一幀對應的函數調用信息（這里由于空間限制沒有全部列出）；
- 二進制映像是指crash發生時已加載的二進制文件。以上就是一份crash日志包含的所有信息，接下來就需要根據這些信息去解析定位導致crash發生的代碼邏輯， 這就需要用到符號化解析的過程（洋名叫：symbolication)。
解決線上閃退
首先保證，發布前充分測試。發布后依然有閃退現象，查看崩潰日志，及時修復并發布。
2. iOS應用生命周期
應用程序的狀態
Not running未運行：程序沒啟動。
Inactive未激活：程序在前臺運行，不過沒有接收到事件。在沒有事件處理情況下程序通常停留在這個狀態。
Active激活：程序在前臺運行而且接收到了事件。這也是前臺的一個正常的模式。
Backgroud后臺：程序在后臺而且能執行代碼，大多數程序進入這個狀態后會在在這個狀態上停留一會。時間到之后會進入掛起狀態(Suspended)。有的程序經過特殊的請求后可以長期處于Backgroud狀態。
Suspended掛起：程序在后臺不能執行代碼。系統會自動把程序變成這個狀態而且不會發出通知。當掛起時，程序還是停留在內存中的，當系統內存低時，系統就把掛起的程序清除掉，為前臺程序提供更多的內存。
下面看一下AppDelegate.m文件，這個關乎著應用程序的生命周期:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// 當應用程序啟動時執行，應用程序啟動入口，只在應用程序啟動時執行一次。若用戶直接啟動，lauchOptions內無數據,若通過其他方式啟動應用，lauchOptions包含對應方式的內容。
return YES;
}
- (void)applicationWillResignActive:(UIApplication *)application {
//當程序從active轉為inactive時會調用這個方法。例如：來電話、信息或者當用戶退出程序，程序從前臺專為后臺的過場。
//用這個方法可以暫定正在執行的任務，暫停計時器以及降低OpenGL的幀率。游戲可以用這個方法來暫停游戲。
}
- (void)applicationDidEnterBackground:(UIApplication *)application {
//用這個方法可以釋放資源、保存用戶數據、取消計時器以及儲存用來恢復程序的狀態信息，以免程序被終止。
//如果你的程序支持后臺模式，當用戶退出程序時，這個方法可以用來替代applicationWillTerminate：
}
- (void)applicationWillEnterForeground:(UIApplication *)application {
//從后臺到inactive時回調用這個方法，用這個方法你可以取消之前進入后臺很多操作
}
- (void)applicationDidBecomeActive:(UIApplication *)application {
// Restart any tasks that were paused (or not yet started) while the application was inactive. If the application was previously in the background, optionally refresh the user interface.
//程序已經進入前臺并且處于active狀態這個方法可以重啟之前在inactive狀態下被暫停的任務；如果程序之前處于后臺，可以選擇在這個方法里刷新UI界面
}
- (void)applicationWillTerminate:(UIApplication *)application {
//當程序即將被終止時調用，如果需要的話可以再次保存數據，可以參見applicationDidEnterBackground:
}
初次啟動：
iOS_didFinishLaunchingWithOptions
iOS_applicationDidBecomeActive
按下home鍵：
iOS_applicationWillResignActive
iOS_applicationDidEnterBackground
點擊程序圖標進入：
iOS_applicationWillEnterForeground
iOS_applicationDidBecomeActive
當應用程序進入后臺時,應該保存用戶數據或狀態信息，所有沒寫到磁盤的文件或信息，在進入后臺時，最后都寫到磁盤去，因為程序可能在后臺被殺死。釋放盡可能釋放的內存。
- (void)applicationDidEnterBackground:(UIApplication *)application
方法有大概5秒的時間讓你完成這些任務。如果超過時間還有未完成的任務，你的程序就會被終止而且從內存中清除。
如果還需要長時間的運行任務，可以在該方法中調用
[application beginBackgroundTaskWithExpirationHandler:^{
//....此處執行你的代碼....
}];
程序終止
程序只要符合以下情況之一，只要進入后臺或掛起狀態就會終止：
- iOS4.0以前的系統
- app是基于iOS4.0之前系統開發的。
- 設備不支持多任務
- 在Info.plist文件中，程序包含了 UIApplicationExitsOnSuspend 鍵。
系統常常是為其他app啟動時由于內存不足而回收內存最后需要終止應用程序，但有時也會是由于app很長時間才響應而終止。如果app當時運行在后臺并且沒有暫停，系統會在應用程序終止之前調用app的代理的方法
- (void)applicationWillTerminate:(UIApplication *)application
，這樣可以讓你可以做一些清理工作。你可以保存一些數據或app的狀態。這個方法也有5秒鐘的限制。超時后方法會返回程序從內存中清除。
3.Runtime
Objective-C 是面相運行時的語言（runtime oriented language），就是說它會盡可能的把編譯和鏈接時要執行的邏輯延遲到運行時。這就給了你很大的靈活性，你可以按需要把消息重定向給合適的對象，你甚 至可以交換方法的實現，等等。
RunTime簡稱運行時。就是系統在運行的時候的一些機制，其中最主要的是消息機制。OC的函數調用成為消息發送。屬于動態調用過程。在編譯的時候并不能決定真正調用哪個函數（事實證明，在編 譯階段，OC可以調用任何函數，即使這個函數并未實現，只要申明過就不會報錯。而C語言在編譯階段就會報錯）。只有在真正運行的時候才會根據函數的名稱找 到對應的函數來調用。
以下面的代碼為例：
[obj makeText];
其中obj是一個對象，makeText是一個函數名稱。對于這樣一個簡單的調用。在編譯時RunTime會將上述代碼轉化成
objc_msgSend(obj,@selector(makeText));
首先，編譯器將代碼[obj makeText];轉化為objc_msgSend(obj, @selector (makeText));，在objc_msgSend函數中。首先通過obj的isa指針找到obj對應的class。在Class中先去cache中 通過SEL查找對應函數method（猜測cache中method列表是以SEL為key通過hash表來存儲的，這樣能提高函數查找速度），若 cache中未找到。再去methodList中查找，若methodlist中未找到，則取superClass中查找。若能找到，則將method加 入到cache中，以方便下次查找，并通過method中的函數指針跳轉到對應的函數中去執行。
Objective-C Runtime 是什么？Objective-C 的 Runtime 是一個運行時庫（Runtime Library），它是一個主要使用 C 和匯編寫的庫，為 C 添加了面相對象的能力并創造了 Objective-C。這就是說它在類信息（Class information） 中被加載，完成所有的方法分發，方法轉發，等等。Objective-C runtime 創建了所有需要的結構體，讓 Objective-C 的面相對象編程變為可能。
具體還可以參考這篇文章
Method Swizzling 原理
在Objective-C中調用一個方法，其實是向一個對象發送消息，查找消息的唯一依據是selector的名字。利用Objective-C的動態特性，可以實現在運行時偷換selector對應的方法實現，達到給方法掛鉤的目的。每個類都有一個方法列表，存放著selector的名字和方法實現的映射關系。IMP有點類似函數指針，指向具體的Method實現。
我們可以利用 method_exchangeImplementations 來交換2個方法中的IMP，我們可以利用 class_replaceMethod 來修改類，我們可以利用 method_setImplementation 來直接設置某個方法的IMP，……歸根結底，都是偷換了selector的IMP。
