iOS应用程序崩溃率-背景噪音水平？

Question

我们刚刚发布了一个使用Crittercism框架的应用程序。过了一段时间，我们已经有了大约125 K的应用程序负载，95次崩溃--比率不到0.08%。

一次事故发生了19次，另一次发生了10次，而其他41次都发生了3次或更少。如果该应用程序有任何重大问题，我希望看到更多的失败在特定领域，所以我对我看到的数字水平感到满意。

快速看一看，它们中的许多都是低级别的故障，不是明显的原因，而是程序员的错误。

示例

• (最大的组)都与后台线程上的CFNetworking有关，而静态CFNetworking则在主线程上的web视图中呈现。free_list_checksum_botch

中存在一些KVO故障

但是我的问题是，在一个足够复杂的操作系统中(本例中是iOS)，有一个足够复杂的应用程序(我认为是这样)，作为一个开发人员，我是否应该看到这种程度的“背景噪音”？

我是否应该仅仅因为操作系统并不完美，就指望每1到2000次加载就会有一个应用程序崩溃呢？其他人也有过类似的经历吗？

(我并不是在寻找错误本身的解决方案。谢谢！)

Answer 1

Crittercism对app崩溃进行了分析。他们的报告是基于安卓与iOS的碰撞。

他们得出的结论是，iOS上最受欢迎的应用程序会导致0.51%的应用程序崩溃。阿希礼·米尔斯，如果你得到0.08%.你做得很好。(不管怎样，我想我的数字是正确的)。

不知道原来的报告在哪里，但我在这里读到：

Forbes app crash rates, conducted by Crittercism

Answer 2

实际上，另一个黑暗的非技术答案可能是。当您可以花费更多的时间和精力在您的工具中开发更多的功能，或者完全地开发其他工具时，您(开发人员)会给您(开发人员)带来什么附加值呢？

如果你的应用程序只是为了好玩和学习，那么我可以看到深入这个问题是一个有趣的冒险。从商业角度来看，你的时间值多少钱，并且正在解决这个0.08%的问题，它会卖出足够的(更多)拷贝，让你的努力值得一试。

类似的情况是，哪些要求是必要的，哪些是需求？只是思考的食粮。我知道我曾为许多公司工作过，但我不认为强调这么低的屈服错误有多大价值。

Answer 3

我是一名iOS开发人员，受雇于专业。当我的应用程序崩溃时，我会把它当成个人问题，因为这不是我想要的用户体验。崩溃是一种糟糕的用户体验。一次崩溃，每个用户，是太多了。撞车就是一只虫子。

尽管如此，我确实看到了一些崩溃日志，这些日志看起来是无法解决的，因为它们似乎在SDK中显示了一个问题。然而，我学到的是，我自己的代码中很可能有一些东西是最终的原因。

有许多奇怪的崩溃可能是由线程或块之间的计时问题引起的，或者仅仅是因为我做错了什么。就在最近，我发现我对一个正在更新的复杂表做了一些完全错误的事情。这个问题的崩溃日志几乎没有提供任何线索，除了我可能看到的代码的一般区域。当我深入研究代码并开始实验时，我意识到我的错误，这最终是一个时间问题，我认为这是一个聪明的分离主线程和非主线程活动。在这种情况下，我太聪明了。:-)

因此，总括而言：

• One崩溃是太多的崩溃，最终一个糟糕的用户
• 怪异的低级别崩溃是您自己的代码的复杂性以及可能的时间问题造成的。

。

最后，我提出这个问题，以考虑：

• 您是否愿意仅仅因为用户掉进0.08%的遭遇崩溃的用户而对他们发火或解雇他们？

思想的食粮。:-)