本文是对iOS APP线上的bug采用何种方案解决和收集统计的一个总结，一个方法论，不涉及具体的crash收集。
如果我们APP在自己公司内部的设备崩溃了，我们有两种方式找到崩溃日志, 有了日志后可以使用atos命令或者symbolicatecrash工具进行符号还原, 具体可以根据这两个关键字搜。
- 将手机连接电脑 -> XCode -> Window-> Devices and Simulators ->View Device Logs，右键Export Log.
- 设置->隐私->分析与改进->分析数据，在这个列表里面找到对应的ips文件分享到电脑。 具体操作查看：iOS dSYM详解和分析crash，ips文件
那么对于线上的bug我们该如何监测闪退情况、收集闪退信息、解决crash呢？
一、线上崩溃的收集统计处理
1.官方收集
对于APP的崩溃情况官方也会收集，但是收集不全，因为设备能不能收集取决于用户设置，有一部分用户收集设置中未开启共享。
收集到的崩溃情况我们可以在APP Store Connect里面的APP分析中看到曲线图。
通过XCode–>Window–>organizer 选择对应的APP和版本可以查看到崩溃情况
然后可以对对应的奔溃“显示包内容”，里面可以找到具体的奔溃日志文件。
2.Bugly收集
集成Bugly是免费的，我们可以使用Bugly来监测卡顿、Crash情况，适合于中小型公司。
Bugly集成方式也简单，pod引入之后，配置一下自动上传dSYM符号的脚本就可以了；如果不会弄脚本，可以自己打包后手动上传符号表，其实这也能避免上传自己运行在release或debug环境下的符号表。
配置方式这个可以参考： iOS Bugly符号表的配置以及使用
3.自己公司开发收集统计性能数据的平台
由于使用bugly虽然免费，但是数据统计只能看到近30天，所以你有自己的定制化需求的话，就只能自己开发了。
对于一个有很多款用户量不低的APP的大公司，还是建议自身平台搭建APM性能监控的基础能力。监控先行~，这样便于针对性能监控上报的数据来进行APP使用体验优化；并且对于你们分析用户增长等问题时也能排除是APP本身出问题导致的。
不过做APM性能监控这个难度比较大，收集的方式都涉及到底层知识；适合于大公司。
当然除了apm性能监控能力建设，我们还需要对APP集成基本的日志上报，脱敏收集用户大体的操作记录，结合操作日志才能对crash、卡顿等问题解决。
