市场上有多种移动应用Crash收集工具， 如友盟，MTJ等。
在iOS中， 收集Crash主要通过两种方式， 一种是信号量机制，因为crash通常会发出信号量，标明某某应用崩溃了， 另一种方式是每一个应用都有一个crash handle, 即崩溃钩子， 每当程序崩溃时， 都会执行这个回调。
信号量比起崩溃句柄的区别有点像ios开发中的通知和delegate。 信号量抛出后，可以被多个捕获crash的工具获取到，然后取当前的堆栈信息， 再利用该堆栈信息与原app的dsym文件进行比对， 就可以找到崩溃的代码行。
理论上讲， 这个信号量机制优秀于crash句柄， 因为这样的话，可以有多个收集工具并行收集， 前提是，每个收集工具收集后，继续抛出这个异常，而不是截断这个异常，当截断后后续的其它工具就收集不到这个异常了， 会导致其它工具收集不全的问题。 而友盟正是这样做的， 小小地ＢＳ一下。
利用crash 句柄这种方式使得crash信息只能被一个收集工具所收集到，因为句柄只有一个。如果一个应用中有多个收集工具都设置了这个句柄， 这里就得看谁最后设置这个句柄， 谁就有效。
上面是收集crash的方式说明， 现在说说Crashlytics这个工具。 原理和上面的一样。
不一样的是， 这个工具被twitter收购， 既然有这么一根大树， 那就保证了这个工具的稳定性。 所以建议使用， 目前是免费的。
使用步骤基本上可以分为如下：
1. 注册，
2. 收到邀请信， 然后一步步按其说明完成注册。
3. 根据其提示，下载一个mac app配合进行使用。
4. 当有崩溃发生时，会给注册的邮件发送崩溃统计，方便查看。
在crash信息收集时， 如果正在进行debug调试，是收集不到信息的。
使用Crashlytics的好处：
1.
Crashlytics不会漏掉任何应用崩溃信息(就这两个字让我决定使用crashlytics)
2.
Crashlytics可以象Bug管理工具那样，管理这些崩溃日志， 可以根据频率及影响用户量来自动设置优先级
3. 可以每天和每周将崩溃信息汇总发送到邮箱中。