如果你有过分析iOS崩溃日志的经验，一定经常看到日志里出现很多<redacted>的字段。这篇文章就是帮助开发者将这些字段符号化为对应的系统库方法名。

如果你已经掌握了这方面的知识，就直接去这里iOS-System-Symbols，下载我整理好的系统库符号文件吧。

符号化的作用

当获取到app的crash日志时，第一步就是将其符号化。作用是把日志堆栈中的方法调用显示出来，对于来自app内部的方法，还能直接给出方法对应.m文件的所在行。

符号化前（这里项目的Build Settings里的Strip Style设为了Debugging Symbols，所以这里能直接看到MyApp的方法名。更多和symbol相关的设置，请看这里）：

Thread 7:
0   libsystem_kernel.dylib          0x000000018efb416c 0x18efb3000 + 4460 (mach_msg_trap + 8)
1   libsystem_kernel.dylib          0x000000018efb3fdc 0x18efb3000 + 4060 (mach_msg + 72)
2   MyApp                           0x000000010091e558 0x1000bc000 + 8791384 (ksmachexc_i_handleExceptions + 148)
3   libsystem_pthread.dylib         0x000000018f097860 0x18f094000 + 14432 (<redacted> + 240)
4   libsystem_pthread.dylib         0x000000018f097770 0x18f094000 + 14192 (_pthread_start + 284)

符号化后：

Thread 7:
0   libsystem_kernel.dylib          0x000000018efb416c mach_msg_trap + 8
1   libsystem_kernel.dylib          0x000000018efb3fdc mach_msg + 72
2   MyApp                           0x000000010091e558 ksmachexc_i_handleExceptions (KSCrashSentry_MachException.c:233)
3   libsystem_pthread.dylib         0x000000018f097860 _pthread_body + 240
4   libsystem_pthread.dylib         0x000000018f097770 _pthread_body + 0

可以发现，frame 3里libsystem_pthread.dylib的<redacted>变成了_pthread_body，frame 2里MyApp的ksmachexc_i_handleExceptions变成了更为完整的ksmachexc_i_handleExceptions (KSCrashSentry_MachException.c:233)，直接给出了方法及其所在文件和行数。

详细的符号化方法，请参考符号化iOS Crash文件的3种方法。这里就不重复了。

需要注意的是，很多时候，crash日志里并不会有MyApp的调用，而全都是系统库的调用：

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libobjc.A.dylib                 0x000000018b816f30 0x18b7fc000 + 110384 (objc_msgSend + 16)
1   UIKit                           0x0000000192e0a79c 0x192c05000 + 2119580 (<redacted> + 72)
2   UIKit                           0x0000000192c4db48 0x192c05000 + 297800 (<redacted> + 312)
3   UIKit                           0x0000000192c4d988 0x192c05000 + 297352 (<redacted> + 160)
4   QuartzCore                      0x00000001900d6404 0x18ffc5000 + 1119236 (<redacted> + 260)
5   libdispatch.dylib               0x000000018bc551c0 0x18bc54000 + 4544 (<redacted> + 16)
6   libdispatch.dylib               0x000000018bc59d6c 0x18bc54000 + 23916 (_dispatch_main_queue_callback_4CF + 1000)
7   CoreFoundation                  0x000000018cd79f2c 0x18cc9d000 + 905004 (<redacted> + 12)
8   CoreFoundation                  0x000000018cd77b18 0x18cc9d000 + 895768 (<redacted> + 1660)
9   CoreFoundation                  0x000000018cca6048 0x18cc9d000 + 36936 (CFRunLoopRunSpecific + 444)
10  GraphicsServices                0x000000018e729198 0x18e71d000 + 49560 (GSEventRunModal + 180)
11  UIKit                           0x0000000192c80628 0x192c05000 + 505384 (<redacted> + 684)
12  UIKit                           0x0000000192c7b360 0x192c05000 + 484192 (UIApplicationMain + 208)
13  MyApp                           0x0000000100016e54 0x100004000 + 77396 (_mh_execute_header + 77396)
14  libdyld.dylib                   0x000000018bc885b8 0x18bc84000 + 17848 (<redacted> + 4)

这时候就必须符号化系统库了。符号化后的日志：

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libobjc.A.dylib                 0x000000018b816f30 objc_msgSend + 16
1   UIKit                           0x0000000192e0a79c -[UISearchDisplayController _sendDelegateDidBeginDidEndSearch] + 72
2   UIKit                           0x0000000192c4db48 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 312
3   UIKit                           0x0000000192c4d988 -[UIViewAnimationState animationDidStop:finished:] + 160
4   QuartzCore                      0x00000001900d6404 CA::Layer::run_animation_callbacks(void*) + 260
5   libdispatch.dylib               0x000000018bc551c0 _dispatch_client_callout + 16
6   libdispatch.dylib               0x000000018bc59d6c _dispatch_main_queue_callback_4CF + 1000
7   CoreFoundation                  0x000000018cd79f2c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
8   CoreFoundation                  0x000000018cd77b18 __CFRunLoopRun + 1660
9   CoreFoundation                  0x000000018cca6048 CFRunLoopRunSpecific + 444
10  GraphicsServices                0x000000018e729198 GSEventRunModal + 180
11  UIKit                           0x0000000192c80628 -[UIApplication _run] + 684
12  UIKit                           0x0000000192c7b360 UIApplicationMain + 208
13  MyApp                           0x0000000100016e54 main (main.m:15)
14  libdyld.dylib                   0x000000018bc885b8 start + 4

可以看出是UISearchController的delegate导致的问题，检查一下就发现UISearchDisplayController的delegate是assign的，是由于点击搜索条的同时pop了界面导致的crash。

从这里可以发现，符号化系统库是很有必要的。

如何符号化系统库

符号化自己app的方法名，需要编译ipa时生成的dySYM文件。而要将系统库的<redacted>符号化为完整的方法名，也需要系统库的符号文件。

1. 匹配对应的符号文件版本

系统库符号文件不是通用的，而是对应crash所在设备的系统版本和CPU型号的。

crash日志中有这样两个信息：

Code Type:       ARM-64
OS Version:      iOS 10.2 (14C82)

Code Type表示此设备的CPU为armv7、armv7s还是arm64。

OS Version表示此设备的系统版本号，括号中的字符串代表了此系统的build号。可以在这里查找build号：iOS SDK，iOS version history。

2. 将对应版本的符号文件放到指定目录

这时候，把获取到的对应版本的符号文件放到Mac的~/Library/Developer/Xcode/iOS DeviceSupport目录下，再使用符号化iOS Crash文件的3种方法里提到的Xcode自带的符号化工具symbolicatecrash进行符号化。这个工具会自动搜索系统库符号文件。

获取系统符号文件的4个方法

从真机上获取

大部分系统库符号文件只能从真机上获取，苹果也没有提供下载。
当你用Xcode第一次连接某台设备进行真机调试时，会看到Xcode显示Processing symbol files，这时候就是在拷贝真机上的符号文件到Mac系统的/Users/xxx/Library/Developer/Xcode/iOS DeviceSupport目录下。

目录下的10.2(14C82)这样的文件夹就是对应的符号文件，通常都有1-3GB的大小，很占用空间，动不动就累积成3、40GB。很多讲清理Mac垃圾文件的教程都会说要删除这个目录下的文件，真是坑爹。正确做法是做成压缩包保存到外部硬盘里，需要符号化的时候再重新解压到此目录。

寻找苹果官方的下载地址

之前watch的调试出现bug时，有人找出过几个watch的符号文件下载地址。见No symbols for paired Apple Watch。
但是我尝试按照对应的命名格式，并没有找到iOS符号文件的下载地址。

从已解密的固件中提取符号文件

某些已经被破解的固件可以直接提取系统文件，但是未破解的固件（较新的固件和arm64的固件），无法用这种方式获取。

固件解密步骤：

1.下载对应版本的.ipsw固件，直接解压，解压后里面有几个.dmg格式的镜像文件，最大的.dmg文件就是系统镜像。
2.从Firmware_Keys找到对应固件的解密key（页面上Root Filesystem字段的key）。
3.用一个dmg工具进行解密，下载地址。使用方式：cd到解压后的ipsw文件夹，执行./dmg extract xxx-xxxx-xxx.dmg dec.dmg -k <key>。extract后面跟两个参数，分别是系统镜像dmg的名字和解密后的文件名，-k 后面填写第2步获取到的key，如果key不对，解密会失败。
4.等待。最终会生成一个dec.dmg文件，双击打开即可加载系统镜像。

提取符号文件方法：
参考聊聊从iOS固件提取系统库符号中的二、系统库符号提取部分。

update:目前大多数固件都能解密了，而且iOS 10之后苹果不再进行加密，因此之后都可以用这个方式获取符号文件。

下载旧版本Xcode，提取SDK

旧版本的Xcode里包含了对应的iPhoneSDK，可以从中获得符号文件。
路径是/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/。里面的System/Library里就可以看到framework，而且同时包含了armv7,armv7s,arm643个平台的版本。

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/version.plist可以查看是哪个版本。把iPhoneOS.sdk文件夹的名字改成对应的CFBundleVersion (ProductBuildVersion)格式，然后在里面加一层Symbols子文件夹，把System,Library,usr都放进Symbols里，就可以和其他符号文件一样使用了。

但是当iOS版本只包含了bug修复，而没有改变API，Xcode就不会有附带对应的SDK，还是需要从真机上获取。而且从Xcode7开始，苹果用tbd文件代替了真机符号文件，所以这个方法也失效了。
参考：Xcode software image for user iOS in order to symbolicate iOS calls, Missing iOS symbols at “~/Library/Developer/Xcode/iOS DeviceSupport”。

获取符号文件的难题

这个时候，游戏就开始了：

• 很多时候crash日志只给出了系统的调用栈，不能直接定位到自己app的代码，因此需要符号化系统库。
• 用户的crash来自各种系统版本，需要对应版本的系统符号文件才能符号化。
• 系统库符号文件只能从真机上获取，苹果没有提供下载。
• 从iOS 7.0(11A465)到iOS 10.2(14C92)一共有50个build版本，公司的测试机是不会覆盖到这么变态的完整度的。
• 同一个版本，有时候会给iPhone和iPad、甚至6和6s提供不同build的固件。
• 某些版本是某些机子的特供版，例如10.0.3(14A551)是iPhone 7和 7 Plus独有的，这就更加大了收集难度。
• 同一个iOS版本可能有多个build，例如10.1(14B72)和10.1(14B72c)，苹果觉得更新幅度太小，就没有提升版本号。
• 除了build号的区别，符号文件在不同CPU平台上也有区别，意味着来自4s(armv7)和6s(arm64)的符号文件，即便build号是一样的，也无法通用。所以50个build号又要翻倍，达到了88个，所以精确来说我只是收集了（63/88）的进度。幸运的是，arm64机型的系统库里附带了armv7s。

规则好厉害的收集游戏啊。收集品其实还有稀有度的区别，其中最厉害的应该是10.0，这是iPhone 7和7 Plus独有的出厂系统，而且没有固件可以下载，因此即便有iPhone 7也不能通过刷机来得到10.0。

其实我一直很奇怪为什么很少见到开发者抱怨找不到系统符号文件，从而召集大家进行收集并分享，猜测可能的原因是：

• 懒。遇到无法符号化的问题，没有去解决。
• 有些公司可能很早就开始对crash日志自动符号化了，因此很早就开始收集符号文件。只要一直跟着苹果的每一个版本升级，收集起来还是挺简单的。而这些资源，开发者并不会注意到可以共享出来。
• crash收集和符号化使用的是第三方服务，第三方平台会帮助符号化系统库。

但是我找了一下，没有找到一家明确声明了能够符号化所有系统库的第三方平台。从腾讯的Bugly论坛里也能发现，有些系统方法并没有符号化出来，系统库是缺失的。（update：找到了一个国外的平台，在stack overflow上说能符号化所有版本的系统库，但是是收费服务，我也没有测试）

在公司小组里，大部分时候都是我来分析crash日志，所以当遇到缺少系统符号文件的情况，就会十分无奈。很多时候，没有符号化的crash日志根本无法提供有用信息。

系统符号文件下载地址

暴力收集

收集不全一直让我很不爽。之前搜刮了组内的测试机，只收集到了有限的几个（感谢无私提供iPhone 7让我刷机降级的同事）。终于，这周末特意跑去了一趟二手机市场寻找旧版本的设备来拷贝，总算是收集得完整了一点，但是也花了我121块钱。

心情总算愉悦了。

其中大部分都是拷贝自arm64设备的，armv7的符号文件收集我是放弃了。有哪位大侠有兴趣把这个游戏玩通关的吗？还有 tvOS 和 watchOS的符号，我也放弃了。
(update:又花了些时间从Xcode的SDK和固件里提取了armv7s和armv7的固件，现在只剩下几个arm64的版本了)。

整理了一下传到了网盘，地址见下方，有需要的去下载吧。

目前还缺少的符号文件

通过各种方式，目前已经收集得差不多了，只剩下最后一个10.0(14A346)版本没有得到。如果哪位小伙伴有这个版本，可以分享一下。

分享可以直接贴下载地址，也可以提交到这个github项目iOS-System-Symbols。如果我得到了新的符号文件，也会在这个项目里更新。

网盘下载地址

下载地址请见这个项目：iOS-System-Symbols。如果我得到了新的符号文件，会在这个项目里更新。

我把里面的那几个dyld_shared_cache_xxxx大文件单独拿出来了，目的是减小压缩包大小。如果只是符号化的话，用不到这几个文件，只是在真机调试的时候才需要。

符号文件版本列表

这些是我已经收集到的符号文件，包括了对应的CPU信息。iOS10系统开始不支持armv7的机器。但是iOS9以下还是支持armv7的。

查看是否带有对应CPU架构的符号文件的方式：到10.2 (14C92)/Symbols/System/Library/Caches/com.apple.dyld这样的目录下，会有对应的dyld_shared_cache_arm64，dyld_shared_cache_armv7s，dyld_shared_cache_armv7文件，如果缺失了，就说明对应的CPU架构符号文件还不存在。（经过试验，这几个大文件并不影响符号化，只是在真机调试的时候才有用，因此如果嫌太占用空间，可以删去）。

机型对应CPU架构

结束语

最后再次呼吁一下，如果谁有上面缺失的符号文件，就请共享一下吧。虽然只是做一点微小的工作，但是能够有很大帮助。

不觉得填满上面那个列表会很爽吗？

update：现在基本上已经收集完了。

额外提示

其实这些符号文件就是真机上的系统库，包括了完整的系统库二进制文件。有时候要反编译某些系统framework，但是模拟器SDK里没有对应的framework（比如只有真机上才有的CoreMotion.framework），就可以在这些真机上的系统库里找到了。

参考

• http://www.jianshu.com/p/11710e7ab661
• 符号化iOS Crash文件的3种方法
• iOS SDK
• iOS version history
• No symbols for paired Apple Watch
• 聊聊从iOS固件提取系统库符号
• Xcode software image for user iOS in order to symbolicate iOS calls
• Missing iOS symbols at “~/Library/Developer/Xcode/iOS DeviceSupport”