IOS剖析解體日志
我的簡書文章地址
前言IOS剖析定位解體問題有很多種方式，但是發布到AppStore的使用假如解體了，我們該怎樣辦呢？通常我們都會在零碎中接入統計零碎，在零碎解體的時分記載下解體日志，下次啟動時將日志發送到服務端，比擬好的第三方有umeng之類的。明天我們來講一下經過解體日志來剖析定位我們的bug。
dYSM文件剖析解體日志的前提是我們需求有dYSM文件，這個文件是我們用archive打包時生成的.xcarchive後綴的文件包。一個良好的習氣是，在你打包提交審核的時分，將生成的.xcarchive與ipa文件一同拷貝一份，依照版本號保管上去，這樣假如線上呈現問題可以疾速的找到你想要的文件來定位你的問題。
普通解體日志都會像上面這樣:
NSConcreteMutableAttributedString addAttribute:value:range:: nil value
(null)
((
CoreFoundation 0x0000000185c642f4 + 160
libobjc.A.dylib 0x00000001974880e4 objc_exception_throw + 60
CoreFoundation 0x0000000185c64218 + 0
Foundation 0x0000000186a9dfb4 + 152
Xmen 0x10073fb30 Xmen + 7600944
Xmen 0x1006bbbf4 Xmen + 7060468
UIKit 0x000000018a9a47fc + 60
UIKit 0x000000018a9a512c + 104
UIKit 0x000000018a6b2b6c + 88
UIKit 0x000000018a9a4fd4 + 444
UIKit 0x000000018a78e274 + 1012
UIKit 0x000000018a999aac + 2904
UIKit 0x000000018a785268 + 172
UIKit 0x000000018a6a1760 + 580
QuartzCore 0x0000000189fe9e1c + 152
QuartzCore 0x0000000189fe4884 + 320
QuartzCore 0x0000000189fe4728 + 32
QuartzCore 0x0000000189fe3ebc + 276
QuartzCore 0x0000000189fe3c3c + 528
QuartzCore 0x0000000189fdd364 + 80
CoreFoundation 0x0000000185c1c2a4 + 32
CoreFoundation 0x0000000185c19230 + 360
CoreFoundation 0x0000000185c19610 + 836
CoreFoundation 0x0000000185b452d4 CFRunLoopRunSpecific + 396
GraphicsServices 0x000000018f35b6fc GSEventRunModal + 168
UIKit 0x000000018a70afac UIApplicationMain + 1488
Xmen 0x1008cf9c0 Xmen + 9238976
libdyld.dylib 0x0000000197b06a08 + 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就看各自身手啦。
結語希望對您有協助，謝謝支持~
以上就是對IOS剖析解體日志的相關引見，希望對您學習ios有所協助，感激您關注本站!
【IOS剖析解體日志】的相關資料介紹到這裡，希望對您有所幫助！ 提示：不會對讀者因本文所帶來的任何損失負責。如果您支持就請把本站添加至收藏夾哦！
