前言

  iOS分析定位崩潰問題有很多種方式，但是釋出到AppStore的應用如果崩潰了，我們該怎麼辦呢？通常我們都會在系統中接入統計系統，在系統崩潰的時候記錄下崩潰日誌，下次啟動時將日誌傳送到服務端，比較好的第三方有umeng之類的。今天我們來講一下通過崩潰日誌來分析定位我們的bug。

dYSM檔案

  分析崩潰日誌的前提是我們需要有dYSM檔案，這個檔案是我們用archive打包時生成的.xcarchive字尾的檔案包。一個良好的習慣是，在你打包提交稽核的時候，將生成的.xcarchive與ipa檔案一同拷貝一份，按照版本號儲存下來，這樣如果線上出現問題可以快速的找到你想要的檔案來定位你的問題。

崩潰日誌

一般崩潰日誌都會像下面這樣:

NSConcreteMutableAttributedString addAttribute:value:range:: nil value
(null)
((
    CoreFoundation                      0x0000000185c642f4 <redacted> + 160
    libobjc.A.dylib                     0x00000001974880e4 objc_exception_throw + 60
    CoreFoundation                      0x0000000185c64218 <redacted
 
> + 0
    Foundation                          0x0000000186a9dfb4 <redacted> + 152
    Xmen                                0x10073fb30 Xmen + 7600944
    Xmen                                0x1006bbbf4 Xmen + 7060468
    UIKit                               0x000000018a9a47fc <redacted> + 60
    UIKit                               0x000000018a9a512c <redacted
 
> + 104
    UIKit                               0x000000018a6b2b6c <redacted> + 88
    UIKit                               0x000000018a9a4fd4 <redacted> + 444
    UIKit                               0x000000018a78e274 <redacted> + 1012
    UIKit                               0x000000018a999aac <redacted> + 2904
    UIKit                               0x000000018a785268 <redacted> + 172
    UIKit                               0x000000018a6a1760 <redacted> + 580
    QuartzCore                          0x0000000189fe9e1c <redacted> + 152
    QuartzCore                          0x0000000189fe4884 <redacted> + 320
    QuartzCore                          0x0000000189fe4728 <redacted> + 32
    QuartzCore                          0x0000000189fe3ebc <redacted> + 276
    QuartzCore                          0x0000000189fe3c3c <redacted> + 528
    QuartzCore                          0x0000000189fdd364 <redacted> + 80
    CoreFoundation                      0x0000000185c1c2a4 <redacted> + 32
    CoreFoundation                      0x0000000185c19230 <redacted> + 360
    CoreFoundation                      0x0000000185c19610 <redacted> + 836
    CoreFoundation                      0x0000000185b452d4 CFRunLoopRunSpecific + 396
    GraphicsServices                    0x000000018f35b6fc GSEventRunModal + 168
    UIKit                               0x000000018a70afac UIApplicationMain + 1488
    Xmen                                0x1008cf9c0 Xmen + 9238976
    libdyld.dylib                       0x0000000197b06a08 <redacted> + 4
)
dSYM UUID: 30833A40-0F40-3980-B76B-D6E86E4DBA85
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: Xmen
Base Address: 0x000000010007c000

是不是看的一臉懵逼，下面我來教大家如何結合crash log 與 dYSM檔案 來分析定位出程式碼崩潰在哪一個檔案的哪一行程式碼

提取崩潰日誌中有用的資訊

• NSConcreteMutableAttributedString addAttribute:value:range:: nil value 崩潰的原因是value為nil
• ” 4 Xmen 0x10073fb30 Xmen + 7600944” 它指出了應用名稱，崩潰時的呼叫方法的地址，檔案的地址以及方法所在的行的位置，我們需要的是這一個:”0x10073fb30”。
• “dSYM UUID: 30833A40-0F40-3980-B76B-D6E86E4DBA85”。
• “CPU Type: arm64”。

開始分析

• 開啟終端進入到你的dYSM檔案的目錄下面:
  cd /Dandy/XMEN/上線版本/2.0.17_105/aaaa.xcarchive/dSYMs
• 驗證下崩潰日誌中的UUID與本地的dYSM檔案是否是相匹配的：
  “Xmen”為你的app名稱
  dwarfdump --uuid Xmen.app.dSYM
  結果是:

UUID: BFF6AE00-8B5F-39BD-AFD0-27707C489B25 (armv7) Xmen.app.dSYM/Contents/Resources/DWARF/Xmen
UUID: 30833A40-0F40-3980-B76B-D6E86E4DBA85 (arm64) Xmen.app.dSYM/Contents/Resources/DWARF/Xmen

發現與我們日誌中的:UUID和CPU Type是相匹配的

• 查詢錯誤
  dwarfdump --arch=arm64 --lookup 0x10073fb30 /Dandy/XMEN/上線版本/2.0.17_105/aaaa.xcarchive/dSYMs/Xmen.app.dSYM/Contents/Resources/DWARF/Xmen
  “arm64”與”0x1008cf9c0”分別對應於上面我們從日誌中提取出來的有用資訊
  “/Dandy/XMEN/上線版本/2.0.17_105/aaaa.xcarchive/dSYMs/Xmen.app.dSYM/Contents/Resources/DWARF/Xmen”對應於你本地dYSM檔案目錄
  “Xmen”對應於你的app名稱
  結果像下面這樣:

File: /Dandy/XMEN/上線版本/2.0.17_105/aaaa.xcarchive/dSYMs/Xmen.app.dSYM/Contents/Resources/DWARF/Xmen (arm64)
Looking up address: 0x000000010073fb30 in .debug_info... found!
0x00219b05: Compile Unit: length = 0x00003dd0  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x0021d8d9)
0x00219b10: TAG_compile_unit [107] *
AT_producer( "Apple LLVM version 8.0.0 (clang-800.0.42.1)" )
AT_language( DW_LANG_ObjC )
AT_name( "/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View/DSSellerOrderSectionHeaderView.m" )
AT_stmt_list( 0x001272a9 )
AT_comp_dir( "/Dandy/checkSvn/IOS/xmen" )
AT_APPLE_major_runtime_vers( 0x02 )
AT_low_pc( 0x000000010072b8ac )
AT_high_pc( 0x000000010074e350 )
0x0021aec5:    TAG_subprogram [119] *
AT_low_pc( 0x0000000100739810 )
AT_high_pc( 0x000000010074006c )
AT_frame_base( reg29 )
AT_object_pointer( {0x0021aee3} )
AT_name( "-[DSSellerOrderSectionHeaderView updateContentWithOrderData:isEdit:]" )
AT_decl_file( "/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View/DSSellerOrderSectionHeaderView.m" )
AT_decl_line( 248 )
AT_prototyped( 0x01 )
0x0021af36:        TAG_lexical_block [138] *
AT_ranges( 0x00008640
[0x000000010073cf90 - 0x000000010073fb88)
[0x000000010073fbc0 - 0x000000010073fbc4)
End )
Line table dir : '/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View'
Line table file: 'DSSellerOrderSectionHeaderView.m' line 680, column 9 with start address 0x000000010073faf8
Looking up address: 0x000000010073fb30 in .debug_frame... not found.

我們來從終端結果來分析出我們想要的結果:
這一行告訴我們崩潰的程式碼所在的檔案的目錄

Line table dir : '/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View'

這一行告訴我們崩潰程式碼所在的具體檔案

AT_decl_file( "/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View/DSSellerOrderSectionHeaderView.m" )

這一行告訴我們崩潰程式碼是在哪一個方法裡面

AT_name( "-[DSSellerOrderSectionHeaderView updateContentWithOrderData:isEdit:]" )

這一行告訴我們崩潰程式碼具體在哪一行了

Line table file: 'DSSellerOrderSectionHeaderView.m' line 680, column 9 with start address 0x000000010073faf8

好的，現在我們分析到了崩潰程式碼在哪一行了，下面我們來找一找bug

查詢bug

  我們的程式碼都應該有託管平臺，每個版本上線都需要打一個tag，這是一個好習慣。下面我拉下我崩潰的對應版本的tag，找到崩潰程式碼那一行：

  結合崩潰日誌中告訴我:崩潰的原因是value為nil,發現是因為receiverTelephone欄位中有中文導致轉url時為nil導致的，下面的解bug就看各自本領啦。

結語

  希望對您有幫助，謝謝支援~