今天想試試用dsym和crash文件跟蹤crash信息，可是一直返回如下信息：
Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x23269c84 __pthread_kill + 8 1 libsystem_pthread.dylib 0x2330bb46 pthread_kill + 62 2 libsystem_c.dylib 0x232000c4 abort + 108 3 libc++abi.dylib 0x22d7a7dc __cxa_bad_cast + 0 4 libc++abi.dylib 0x22d936a0 default_unexpected_handler() + 0 5 libobjc.A.dylib 0x22d9f098 _objc_terminate() + 192 6 libc++abi.dylib 0x22d90e16 std::__terminate(void (*)()) + 78 7 libc++abi.dylib 0x22d905f4 __cxxabiv1::exception_cleanup_func(_Unwind_Reason_Code, _Unwind_Exception*) + 0 8 libobjc.A.dylib 0x22d9eed2 objc_exception_throw + 250 9 CoreFoundation 0x234e831e -[__NSArrayI objectAtIndex:] + 186 10 test 0x000791f2 __hidden#5_ (__hidden#43_:35) 11 libdispatch.dylib 0x2316fdd6 _dispatch_call_block_and_release + 10 12 libdispatch.dylib 0x231794e6 _dispatch_after_timer_callback + 66 13 libdispatch.dylib 0x2316fdc2 _dispatch_client_callout + 22 14 libdispatch.dylib 0x231826d2 _dispatch_source_latch_and_call + 2042 15 libdispatch.dylib 0x23171d16 _dispatch_source_invoke + 738 16 libdispatch.dylib 0x231741fe _dispatch_main_queue_callback_4CF + 394 17 CoreFoundation 0x23594fc4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8 18 CoreFoundation 0x235934be __CFRunLoopRun + 1590 19 CoreFoundation 0x234e5bb8 CFRunLoopRunSpecific + 516 20 CoreFoundation 0x234e59ac CFRunLoopRunInMode + 108 21 GraphicsServices 0x2475faf8 GSEventRunModal + 160 22 UIKit 0x277d1fb4 UIApplicationMain + 144 23 test 0x000797de main (__hidden#317_:14) 24 libdyld.dylib 0x23198872 start + 2
確實是解析了不假，但是卻只能得到
test 0x000791f2 __hidden#5_ (__hidden#43_:35)
這個35是對的，的確是源文件第35行出了bug，但是，
hidden是什么東西？之后我又單獨查看了這個dsym文件，內容如下：
---------------------------------------------------------------------- File: /Users/Breeze/Desktop/crash/test.app.dSYM/Contents/Resources/DWARF/test (armv7) ---------------------------------------------------------------------- .debug_info contents: 0x00000000: Compile Unit: length = 0x00000073 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x00000077) 0x0000000b: TAG_compile_unit [1] * AT_producer( "__hidden#30_" ) AT_language( DW_LANG_ObjC ) AT_name( "__hidden#43_" ) AT_stmt_list( 0x00000000 ) AT_comp_dir( "__hidden#41_" ) AT_APPLE_optimized( 0x01 ) AT_APPLE_major_runtime_vers( 0x02 ) AT_low_pc( 0x0000a0b0 ) AT_high_pc( 0x0000a206 ) 0x00000028: TAG_subprogram [2] AT_low_pc( 0x0000a0b0 ) AT_high_pc( 0x0000a154 ) AT_name( "__hidden#45_" ) 0x00000035: TAG_subprogram [2] AT_low_pc( 0x0000a154 ) AT_high_pc( 0x0000a166 ) AT_name( "__hidden#1_" ) 0x00000042: TAG_subprogram [2] AT_low_pc( 0x0000a168 ) AT_high_pc( 0x0000a16e ) AT_name( "__hidden#2_" ) 0x0000004f: TAG_subprogram [2] AT_low_pc( 0x0000a170 ) AT_high_pc( 0x0000a176 ) AT_name( "__hidden#3_" ) 0x0000005c: TAG_subprogram [2] AT_low_pc( 0x0000a178 ) AT_high_pc( 0x0000a1a4 ) AT_name( "__hidden#44_" ) 0x00000069: TAG_subprogram [2] AT_low_pc( 0x0000a1a4 ) AT_high_pc( 0x0000a206 ) AT_name( "__hidden#42_" ) 0x00000076: NULL 0x00000077: Compile Unit: length = 0x000000db version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x00000156) 0x00000082: TAG_compile_unit [1] * AT_producer( "__hidden#30_" ) AT_language( DW_LANG_ObjC ) AT_name( "__hidden#301_" ) AT_stmt_list( 0x000000bf ) AT_comp_dir( "__hidden#41_" ) AT_APPLE_optimized( 0x01 ) AT_APPLE_major_runtime_vers( 0x02 ) AT_low_pc( 0x0000a208 ) AT_high_pc( 0x0000a796 ) 0x0000009f: TAG_subprogram [2] AT_low_pc( 0x0000a208 ) AT_high_pc( 0x0000a20c ) AT_name( "__hidden#315_" ) 0x000000ac: TAG_subprogram [2] AT_low_pc( 0x0000a20c ) AT_high_pc( 0x0000a20e ) AT_name( "__hidden#314_" ) 0x000000b9: TAG_subprogram [2] AT_low_pc( 0x0000a210 ) AT_high_pc( 0x0000a212 ) AT_name( "__hidden#313_" ) 0x000000c6: TAG_subprogram [2] AT_low_pc( 0x0000a214 ) AT_high_pc( 0x0000a216 ) AT_name( "__hidden#312_" ) 0x000000d3: TAG_subprogram [2] AT_low_pc( 0x0000a218 ) AT_high_pc( 0x0000a21a ) AT_name( "__hidden#311_" ) 0x000000e0: TAG_subprogram [2] AT_low_pc( 0x0000a21c ) AT_high_pc( 0x0000a22c ) AT_name( "__hidden#310_" ) 0x000000ed: TAG_subprogram [2] AT_low_pc( 0x0000a22c ) AT_high_pc( 0x0000a2a2 ) AT_name( "__hidden#309_" ) 0x000000fa: TAG_subprogram [2] AT_low_pc( 0x0000a2a4 ) AT_high_pc( 0x0000a372 ) AT_name( "__hidden#308_" ) 0x00000107: TAG_subprogram [2] AT_low_pc( 0x0000a374 ) AT_high_pc( 0x0000a5b6 ) AT_name( "__hidden#307_" ) 0x00000114: TAG_subprogram [2] AT_low_pc( 0x0000a5b8 ) AT_high_pc( 0x0000a65c ) AT_name( "__hidden#306_" ) 0x00000121: TAG_subprogram [2] AT_low_pc( 0x0000a65c ) AT_high_pc( 0x0000a702 ) AT_name( "__hidden#305_" ) 0x0000012e: TAG_subprogram [2] AT_low_pc( 0x0000a704 ) AT_high_pc( 0x0000a714 ) AT_name( "__hidden#304_" ) 0x0000013b: TAG_subprogram [2] AT_low_pc( 0x0000a714 ) AT_high_pc( 0x0000a73a ) AT_name( "__hidden#302_" ) 0x00000148: TAG_subprogram [2] AT_low_pc( 0x0000a73c ) AT_high_pc( 0x0000a796 ) AT_name( "__hidden#300_" ) 0x00000155: NULL 0x00000156: Compile Unit: length = 0x00000032 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x0000018c) 0x00000161: TAG_compile_unit [1] * AT_producer( "__hidden#30_" ) AT_language( DW_LANG_ObjC ) AT_name( "__hidden#317_" ) AT_stmt_list( 0x00000320 ) AT_comp_dir( "__hidden#41_" ) AT_APPLE_optimized( 0x01 ) AT_APPLE_major_runtime_vers( 0x02 ) AT_low_pc( 0x0000a798 ) AT_high_pc( 0x0000a7f4 ) 0x0000017e: TAG_subprogram [2] AT_low_pc( 0x0000a798 ) AT_high_pc( 0x0000a7f4 ) AT_name( "__hidden#316_" ) 0x0000018b: NULL
竟然全部都是hidden！！
原來是我在用orgenizer 導出ipa時，使用了下圖選項：
注意到這個 rebuild from bitcode 選項了嗎？看看說明：
我選擇了這個選項，之后使用導出的ipa和相應的dysm文件進行相應的操作，我們可以比較一下選和不選這個選項得到不同dysm的文件大小：
上邊2個是使用 bitcode發布選項后，出現的dsym，每個之后12K。而下面那個是不使用的dsym，有2.1M。
之后查看了其他網頁，有如下資料：
如果你的應用也准備啟用Bitcode編譯機制，就需要注意以下幾點：
· Xcode 7默認開啟Bitcode，如果應用開啟Bitcode，那么其集成的其他第三方庫也需要是Bitcode編譯的包才能真正進行Bitcode編譯
· 開啟Bitcode編譯后，編譯產生的.app體積會變大(中間代碼，不是用戶下載的包)，且.dSYM文件不能用來崩潰日志的符號化(用戶下載的包是Apple服務重新編譯產生的，有產生新的符號文件)
· 通過Archive方式上傳AppStore的包，可以在Xcode的Organizer工具中下載對應安裝包的新的符號文件
就是說，發布時可以模擬appstore的bitcode功能，但是為什么有2個 dsym文件，而只有一個ipa文件呢？難道這個ipa文件會根據不同的機器安裝成不同的2進制文件？有這么智能？