2016年11月重写Uber骑手应用程序，我们对降低测量的崩溃率并改善我们核心特征的正常运行时间来实现了重要的进展。但是，一个唠叨的问题是由内存（OOM）例外或难以检测的其他原因引起的应用终端。轶事，我们收到了应用程序未能在低内存情况下发射的报告，特别是在旧设备上，但在工具追踪这些问题的方式几乎没有。
考虑到这一点，Uber Engineering开发并开放了我们自己的启动原因记者。在本文中，我们将讨论如何设计这个强大的工具来帮助我们(以及其他人)检测iOS上的启动原因，并在此过程中构建更可靠的应用程序。
所以......为什么我的应用程序崩溃了？
从开发人员的角度来看，检测IOS上的典型崩溃相当简单。基础框架提供了一个NSSetUncaughtExceptionHandler回调，它使开发人员有机会记录有关未捕获的异常的信息。然而，当申请终止以获得其他原因时，可能很难确定出现问题。在这两种情况下，体验相同：应用程序停止工作和崩溃。我们寻求更多地深入了解这些崩溃的频率，以确定我们如何跟踪，又阻止它们。
我们实施的创业原因报告是基于Facebook的过程，减少OOM事件概述Facebook工程博客雷竞技到底好不好用。根据这个框架，一个新的应用程序可能会出现在有限的几个原因，包括:
- 该应用程序首次启动
- 该应用程序正在开发，应用程序作为调试的一部分崩溃
- 该应用程序在先前的运行时崩溃了
- 操作系统已升级
- app升级了
- 该应用程序在先前的运行中被强制退出
- 手机重新启动
- 该应用程序已终止在后台
- 手机耗尽内存并终止了应用程序
为了缩小可能的原因列表，Startup Reason Reporter假设应用程序是第一次启动的。然后，它根据上次启动时保存的信息，依次遍历这些可能性。如果我们无法从存储的数据中确定应用程序启动的原因，那么我们假设应用程序被终止，因为手机运行OOM。
先前运行信息的持久性
关键的是，Startup Reason Reporter要求有某种存储机制来持久化之前运行的应用程序所需要的信息。我们对Startup Reason Reporter的实现允许您使用任何您喜欢的存储机制，只要它实现了UbapplicationstartupreashreaseReqorporterpriorruninfoproprotocol.。该协议摘要确定启动原因所需的所有信息，例如先前的应用程序版本以及应用程序是否在后台或前台上次持续。我们提供具体的实施，ubapplicationstartupreashreagreporterpriorruninfo.那这是基于的NSUserDefaults，但是要认识到这可能不适用于所有用例。
挑战
启动原因记者严重依赖于可用的数据。特别是以前的rundidcrash.标志必须准确地妥善报告OOM问题。简而言之，默认假设是所有不属于已知存储桶的崩溃都被视为OOM事件，因此如果提供的数据不准确，则由启动原因报告者报告的一些数据可能是其他问题。捕获所有崩溃变体都超出了本次讨论的范围，但重要的是要捕获所有类型的崩溃，例如看门狗超时，分段错误和例外。
下一个步骤
《The Startup Reason Reporter》是用Objective-C编写的，但如果与Swift结合起来，也能发挥作用。用法相当简单:将所需的信息引导到实例UbapplicationStartupreaseRexreporter.。的UbapplicationStartupreaseRexreporter.然后将通过该启动原因进行spartueveren.财产。然后可以将结果送入您的分析管道，以进一步分析。
看一些我们错过或有一个想法的东西，这可能会更好地让这个项目变得更好吗？分享您的贡献启动原因记者在github上！
如果在优步规模的移动工程挑战吸引你，考虑申请一个角色在我们的iOS平台团队。
要了解有关Uber的移动开发的更多信息，请查看我们的Uber Mobility Meetup演示在这一点优步工程YouTube频道。
Tuomas Artman和Alex Medearis是Uber的iOS平台团队的软件工程师。
图片标题:法国神仙鱼(几乎)撞上了镜头圆顶”，作者康纳·梅尔沃德，博伊尔。
