曾经在面试的时候，面试官问了一句：如果App发布以后，用户在使用的过程中出现崩溃、卡顿或者错误，你是怎么处理的？
当时我就按常规思路回答了这个问题，无非就是在App中提供意见反馈、留下联系方式之类的废话，显然没有回答到问题的点子上，自己也意识到回答得有点勉强。试想有多少用户愿意在App出现故障后专门给你发送信息反馈，然后还要别人留下联系方式让你骚扰他？
出现这样的情况，当然要去反思一下，当时我就去翻看了时下流行的App，其中微信的处理方式是列出常见的问题，分功能模块的去细分可能出现的问题，只需要用户点击选择就可以进行反馈，这样至少不会太让用户产生太大的反感情绪。另外我猜想微信这样处理的背后还有自己的Bug详细信息收集系统，将产生的Bug文件保存在本地，在必要的时候再上传到Bug收集系统的服务器上去。
但一般的小公司哪有这个精力和成本去设计这样的Bug体系呢？没关系，其他公司已经考虑到了这样的问题，友盟、Bugly等服务平台已经基本上可以满足Bug收集的要求了，我们在开发的时候接入他们提供的SDK即可，在App出现异常错误的时候，App就会将产生的异常错误实时上传到已注册的平台上去，简单方便。
以Bugly为例，我们可以看到App上传的Bug信息，一目了然，所产生的信息和我们在代码调试时产生的异常提示相似，虽然这样不能及时地让我们精确判断问题的位置所在，待至少给我们提供了一个解决问题的思路，我想这已经足够了。
如果我们在自己内部测试的时候，每次都去服务平台上查看Bug信息，太费事。那么Apple给我们提供了一种方式：
NSSetUncaughtExceptionHandler (&UncaughtExceptionHandler);
其中，UncaughtExceptionHandler是一个函数指针类型，所指向的函数需要我们实现，可以取自己想要的名字。当程序发生异常崩溃时，该函数会得到调用，这跟C，C++中的回调函数的概念是一样的。
