最近幾天，專案中在增加推送功能，選用的極光推送SDK，相信大家也都用過，官方文件的整合步驟很詳細，整合也很容易。但是這跟今天的主題有什麼關係呢？？？ 黑人問號？？？別急，下面就來說說我今天的遭遇。坑~~~

話說，由於iOS10之後，蘋果對推送進行了重大更新，主要是新增了 User Notifications Framework框架， 具體資訊可以檢視蘋果官方文件，這裡就不多解釋了。於是我就突發奇想，利用新增的三種本地推送，TimeInteval，Calendar，Location，在專案中增加自定義推送設定，讓使用者自己想要的推送的內容，圖片或者視訊，可以基於位置，時間和日曆。 很不錯，於是開始寫程式碼，由於極光對iOS10和10以下的Api進行了封裝，所以直接可以呼叫。當我寫完第一個TimeInteval

。。。 只是提示捕獲了異常，然而並沒有具體的資訊，Xcode也沒有定位到底是哪一行出錯的。。。這就尷尬了。於是，我想到了崩潰日誌。 怎麼檢視？很簡單，將自己的iPhone連線到mac上，然後點選下圖的位置：

接著在按照下圖的步驟檢視具體的資訊

在點選View Device Logs後可以看到你的裝置中所有的崩潰資訊，可以根據時間進行排序，我們找到剛才的崩潰資訊，出現了以下介面：

崩潰資訊大致大致可以分為以上幾個部分，下面來詳細介紹：

第一部分是閃退程序的相關資訊：

Incident Identifier ： 是崩潰報告的唯一識別符號。

CrashReporter Key： 是與裝置標識相對應的唯一鍵值。雖然它不是真正的裝置識別符號，但也是一個非常有用的情報:如果你看到100個崩潰日誌的CrashReporter Key值都是相同的，或者只有少數幾個不同的CrashReport值，說明這不是一個普遍的問題，只發生在一個或少數幾個裝置上。

Hardware Model ：標識裝置型別。 如果很多崩潰日誌都是來自相同的裝置型別，說明應用只在某特定型別的裝置上有問題。上面的日誌裡，崩潰日誌產生的裝置是iPhone 4s。

Process：對專案的操作許可權，上面的是可讀可寫

Path:崩潰檔案的路徑

Identifier:專案識別符號，就是Bundle Id

Version:版本號

.....等等.......

第二部分

給出了一些基本資訊，包括閃退發生的日期Date/Time和時間Launch Time，裝置的iOS版本OS Version等。

第三部分
Exception Type:異常的型別。
Exception Codes ：異常錯誤碼
Termination Reason：閃退的原因，比如常見的陣列越界啊，什麼的。
Triggered by Thread：出現問題在哪個執行緒，這個比較重要，首先確定在哪個執行緒中出了問題，然後再去定位。

第四部分
這部分提供應用中所有執行緒的回溯日誌。 執行緒呼叫的一些，堆疊資訊，壓根看不懂，所有需要進行符號化處理。

首先，這裡介紹下官方的，也就是利用Xcode自帶的崩潰日誌分析工具symbolicatecrash,自己嘗試了下效果一般，只是把它轉換成常規的崩潰資訊，用法這裡就不細說了，附上一篇文章，裡面有具體的用法，傳送門。。。

其實，現在網上有很多蒐集崩潰日誌的第三方，下面介紹幾個相對比較專業的：

一丶Bugly

Bugly 是騰訊內部使用的移動應用崩潰檢測服務，同時支援 iOS 和 Android 平臺。目前 Bugly 已經對移動開發者開放。移動開發者在自己的  App 中接入 Bugly 的 SDK 後，就能在應用崩潰後獲得資訊上報。開發者可以通過 Bugly 的網站看到崩潰的概要和詳情。崩潰概要包括，崩潰的列表、近日按小時統計趨勢、昨天前天的崩潰次數和崩潰率。

具體用法：

• 登入Bugly，註冊應用：

• 選擇異常上報
  

  
  
  

• 可以選著SDK整合，也可以使用Pod，我當然選著Pod了，這麼方便：
  通過CocoaPods整合，在工程的Podfile
  裡面新增以下程式碼：

   pod 'Bugly'

  初始化Bugly,在工程AppDelegate.m
  的application:didFinishLaunchingWithOptions:
  方法中初始化Bugly：
  Objective-C

  - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
      [Bugly startWithAppId:@"此處替換為你的AppId"];
       return YES;
    }

      Swift

 func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObje ct: AnyObject]?) -> Bool {
      Bugly.startWithAppId("此處替換為你的AppId")
      return true
 }

友情提醒：使用Bugly採集崩潰資訊，要使用真機，不能使用模擬器，不可以Xcode啟動真機App，因為，崩潰後，程式會停止在mian函式，那麼上傳崩潰資訊就走執行不了了。

看看，Bugly的崩潰資訊：

可以看到，Bugly可以幫助我們做一些崩潰資料的統計與分析。

當我們進入崩潰的詳情頁面，可以清楚的看到在哪一個控制器，哪一個方法，什麼原因引起的崩潰。

這裡還要推薦下Bugly的內測分發功能，也是相當的不錯，通過二維碼掃描下載，省去了很多麻煩，還可以設定密碼許可權等一系列操作，大家不妨去試試~

二丶Fabric

Fabric是Twitter在2014年舉辦的首屆開發者大會上提供給第三方移動應用開發者的新工具，具體資訊可以去它的官網進行瀏覽，下面介紹具體整合的步驟：

訪問官網地址(進行註冊賬號)：

https://fabric.io

下載客戶端地址：

1：註冊成功後，並把客戶端軟體下載後，就可以登入客戶端進行操作，選擇要增加的工程檔案

2：運用客戶端，生成指令碼

因為這邊是直接採用把fabric框架直接拉進到專案中，所以生成的指令碼為這種樣式，若是採用Pod引入，其指令碼會不一樣；指令碼的引入都會在專案的Info.Plist產生一個配置採單；

3：把指令碼複製到XCode專案的相關地方

 注意：當有一個專案多個targets時，要對每個targets進行run Script設定，確保每個targets裡面的info.plist檔案有生成相應的配置，否則執行會報錯；

4：引入相應的框架檔案，直接從客戶端拉到專案中

注意：除了直接把fabric拉進專案引用，還可以用POD進行管理外掛，只是其指令碼的內容格式不一樣；

5：在專案中引入檔案，並初始化框架，註冊並特意編寫錯誤的程式碼

 6：根據客戶端提示執行最後一步,點Done回去，等待程式釋出

7：回到XCODE的專案中，對專案進行釋出

注意：選擇Release,然後進行Archive;

8：當Archive成功釋出以後，客戶端會有提示，是否要進行dsym的上傳

注意：選擇Distribute，進入下一個頁面，此處可以輸入接受通知的郵件地址，可以是多人接收，然後下一步提示語輸入，然後開始進行上傳dysm檔案；

9:成功執行以後就可以檢視錯誤的資訊

注意：其實fabric的原理還是把釋出後的dsym上傳後對它進行定位，顯示出錯誤的位置；如果不用客戶端這種上傳，也可以中完成到指令碼的加入後，把釋出生成的dysm壓縮成包進行上傳；後官網對應的專案進行操作，如下圖：

一句程式碼搞定，然後登陸極光官網，開啟極光開發者服務，找到如下位置：

OK，現在已經可以看到剛才崩潰的資訊了，當然你也點開檢視具體的崩潰資訊。

當我看到那個錯誤摘要的時候，恍然大悟！！！

time interval must be at least 60 if repeating

於是，在我改完程式碼之後，果然成功執行，沒有報錯。極光的這個崩潰收集還是挺好用的。

總結：平時我們在測試專案的時候儘量使用真機而不是模擬器，一方面真機的功能全面，另一方面可以更好的收集崩潰資訊，便於分析Bug所在及時解決，上線的專案也是如此，可以通過打包傳送給指定的郵箱或伺服器來收集分析解決Bug。你問我沒有真機怎麼辦？？？兄弟，聽說前端現在很火，要不要考慮轉行~