我来问个比较宽泛一些的问题，大家项目中是如何稳定或者降低 app 的 crash 率的呢？ 大家集思广益，来想想法子，指点一下方向，不管是流程上的优化还是技术上的优化，不管是成熟的操作或者是乌托邦式的概念，我们旨在解决问题。
我来做沙发，我们现在为这个事情做了的有以下两点：
- 稳定性测试 uiautomationMonkey，初期还有些效果，后期基本上成为了鸡肋
- 进行用户测试，统计 crash 率
我认为需要注意的其中几个重点：
1、新功能需求
2、新功能与旧功能的耦合
3、数据库字段的增减【特别是减少的时候】【多出现在升级覆盖】
以上三点是重灾区，测试针对以上三点设计合适的用例是必须的，在有用例的基础上使用工具辅助。 然后当然主要还是监督开发的自测，代码质量也影响着产品质量是必然的。
光靠测试是很难保证完全的, 最好结合现有的一些开放服务, 比如 testin, 友盟都提供了用户统计和崩溃分析, 这些产品对企业做测试还是很有帮助的. 国外也有很多公司在做, 比如 google 分析.
参考链接 http://apm.testin.cn/zh/
#3 楼 @seveniruby 用户统计和崩溃分析，我们已经有了， 这些东西是能发现问题，但从测试的角度可控性不够。 从我们自身出发，能做的通用型的东西有哪些呢
其实吧，我是觉得这个东西是需要团队一起的，或者说开发和测试一起。crash 这种东西更多的是没有约定，大家胡乱按照自己的风格开发和 check in。所以从代码本身角度应该规范，能够规避掉很多问题
#4 楼 @297358102 你希望什么样子的可控性， 我是觉得对崩溃的原因进行总结梳理是很有必要的。 然后分析出特征， 以后就用这些特征扫描新代码即可。崩溃也是有规律的。
Android 的崩溃分类系统帮我们做了很多，比如空指针，classnotfound 之类，开发可以针对性的一块块去修。
但是 iPhone 的崩溃很难分类，我们的开发也没法做分类。app 很多个模块并行开发，看线上崩溃多数崩在多线程交互，开发很难排查出具体问题。 @seveniruby 静态代码检查，我们一直有做，线上崩溃多是动态调用，静态满足不了。
写 1 个 crash 抓取的程序传到服务器上，本地出现，上传服务器和本地也会保存一份。
还有就是接入第三方统计的，也是出现后，传到第三方数据中心，可以图形化去看，本地也传一份。
区别在 1 个是自己写，1 个是接入。。
我觉得你提问的重点是，如何确保发布的版本可控。稳定和减低 crash 可以通过线上监控工具解决，这方面工具有很多。