ios bitcode 机制对 dsym 调试文件的影响

今天想试试用dsym和crash文件跟踪crash信息，可是一直返回如下信息：

Thread  name:  Dispatch queue: com.apple.main-thread
Thread  Crashed:
   libsystem_kernel.dylib            0x23269c84 __pthread_kill +
   libsystem_pthread.dylib           0x2330bb46 pthread_kill +
   libsystem_c.dylib                 0x232000c4 abort +
   libc++abi.dylib                   0x22d7a7dc __cxa_bad_cast +
   libc++abi.dylib                   0x22d936a0 default_unexpected_handler() +
   libobjc.A.dylib                   0x22d9f098 _objc_terminate() +
   libc++abi.dylib                   0x22d90e16 std::__terminate(void (*)()) +
   libc++abi.dylib                   0x22d905f4 __cxxabiv1::exception_cleanup_func(_Unwind_Reason_Code, _Unwind_Exception*) +
   libobjc.A.dylib                   0x22d9eed2 objc_exception_throw +
   CoreFoundation                    0x234e831e -[__NSArrayI objectAtIndex:] +
  test                              0x000791f2 __hidden#5_ (__hidden#43_:35)
  libdispatch.dylib                 0x2316fdd6 _dispatch_call_block_and_release +
  libdispatch.dylib                 0x231794e6 _dispatch_after_timer_callback +
  libdispatch.dylib                 0x2316fdc2 _dispatch_client_callout +
  libdispatch.dylib                 0x231826d2 _dispatch_source_latch_and_call +
  libdispatch.dylib                 0x23171d16 _dispatch_source_invoke +
  libdispatch.dylib                 0x231741fe _dispatch_main_queue_callback_4CF +
  CoreFoundation                    0x23594fc4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ +
  CoreFoundation                    0x235934be __CFRunLoopRun +
  CoreFoundation                    0x234e5bb8 CFRunLoopRunSpecific +
  CoreFoundation                    0x234e59ac CFRunLoopRunInMode +
  GraphicsServices                  0x2475faf8 GSEventRunModal +
  UIKit                             0x277d1fb4 UIApplicationMain +
  test                              0x000797de main (__hidden#317_:)
  libdyld.dylib                     0x23198872 start + 

确实是解析了不假，但是却只能得到

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 [] *
             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 []
                 AT_low_pc( 0x0000a0b0 )
                 AT_high_pc( 0x0000a154 )
                 AT_name( "__hidden#45_" )

0x00000035:     TAG_subprogram []
                 AT_low_pc( 0x0000a154 )
                 AT_high_pc( 0x0000a166 )
                 AT_name( "__hidden#1_" )

0x00000042:     TAG_subprogram []
                 AT_low_pc( 0x0000a168 )
                 AT_high_pc( 0x0000a16e )
                 AT_name( "__hidden#2_" )

0x0000004f:     TAG_subprogram []
                 AT_low_pc( 0x0000a170 )
                 AT_high_pc( 0x0000a176 )
                 AT_name( "__hidden#3_" )

0x0000005c:     TAG_subprogram []
                 AT_low_pc( 0x0000a178 )
                 AT_high_pc( 0x0000a1a4 )
                 AT_name( "__hidden#44_" )

0x00000069:     TAG_subprogram []
                 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 [] *
             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 []
                 AT_low_pc( 0x0000a208 )
                 AT_high_pc( 0x0000a20c )
                 AT_name( "__hidden#315_" )

0x000000ac:     TAG_subprogram []
                 AT_low_pc( 0x0000a20c )
                 AT_high_pc( 0x0000a20e )
                 AT_name( "__hidden#314_" )

0x000000b9:     TAG_subprogram []
                 AT_low_pc( 0x0000a210 )
                 AT_high_pc( 0x0000a212 )
                 AT_name( "__hidden#313_" )

0x000000c6:     TAG_subprogram []
                 AT_low_pc( 0x0000a214 )
                 AT_high_pc( 0x0000a216 )
                 AT_name( "__hidden#312_" )

0x000000d3:     TAG_subprogram []
                 AT_low_pc( 0x0000a218 )
                 AT_high_pc( 0x0000a21a )
                 AT_name( "__hidden#311_" )

0x000000e0:     TAG_subprogram []
                 AT_low_pc( 0x0000a21c )
                 AT_high_pc( 0x0000a22c )
                 AT_name( "__hidden#310_" )

0x000000ed:     TAG_subprogram []
                 AT_low_pc( 0x0000a22c )
                 AT_high_pc( 0x0000a2a2 )
                 AT_name( "__hidden#309_" )

0x000000fa:     TAG_subprogram []
                 AT_low_pc( 0x0000a2a4 )
                 AT_high_pc( 0x0000a372 )
                 AT_name( "__hidden#308_" )

0x00000107:     TAG_subprogram []
                 AT_low_pc( 0x0000a374 )
                 AT_high_pc( 0x0000a5b6 )
                 AT_name( "__hidden#307_" )

0x00000114:     TAG_subprogram []
                 AT_low_pc( 0x0000a5b8 )
                 AT_high_pc( 0x0000a65c )
                 AT_name( "__hidden#306_" )

0x00000121:     TAG_subprogram []
                 AT_low_pc( 0x0000a65c )
                 AT_high_pc( 0x0000a702 )
                 AT_name( "__hidden#305_" )

0x0000012e:     TAG_subprogram []
                 AT_low_pc( 0x0000a704 )
                 AT_high_pc( 0x0000a714 )
                 AT_name( "__hidden#304_" )

0x0000013b:     TAG_subprogram []
                 AT_low_pc( 0x0000a714 )
                 AT_high_pc( 0x0000a73a )
                 AT_name( "__hidden#302_" )

0x00000148:     TAG_subprogram []
                 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 [] *
             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 []
                 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进制文件？有这么智能？