iOS app崩溃率 - 背景噪音水平？

Question

我们刚刚使用Crittercism框架发布了一个应用程序。一段时间后，我们有大约125K的应用程序负载和95次崩溃 - 率低于0.08％。

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

快速浏览显示其中许多是低级故障，不是明显造成的，而是程序员错误。

实施例

• 最大的组与后台线程上的CFNetworking有关，而静态HTML正在主线程的Web视图中呈现。
• free_list_checksum_botch
中存在一些KVO失败

但是我的问题是，在一个足够复杂的操作系统（在这种情况下是iOS）中，有一个足够复杂的应用程序（我认为它是），应该我，作为开发者，期望看到这种“背景噪音”水平？

我应该期望看到每1-2000次加载一个应用程序崩溃，仅仅因为操作系统不完美？还有其他人有类似的经历吗？

（我不是在寻找错误的解决方案..谢谢！）

Answer 1

Crittercism对应用程序崩溃进行了分析。他们的报告基于Android vs iOS崩溃。

他们得出结论，iOS上最受欢迎的应用程序崩溃了0.51％的应用程序启动。所以@Ashley Mills，如果你得到0.08％......你表现得很好。 （无论如何，我认为我的数据是正确的。）

不确定原始报告的位置，但我在此处阅读：

Forbes app crash rates, conducted by Crittercism

Answer 2

实际上，在黑暗的非技术性答案中的另一个镜头可能是。当您花费更多时间和精力在您的工具或其他工具中开发更多功能时，它会带给您（开发人员）继续深入研究这个特定问题的附加价值。

如果你的应用只是为了娱乐和学习，那么我可以看到这个问题作为一个有趣的冒险。从商业角度来看，你的时间价值是多少，并且正在弄清楚这个0.08％的问题会出售足够多（更多）的副本以使你的努力值得。

类似的是，哪些要求是必不可少的，哪些要求是什么？ 只是值得深思。我知道很多我工作过的公司都没有看到强调那个低收益的错误的价值。

Answer 3

我是一名iOS专业开发人员。当我的应用程序崩溃时，我会亲自接受它，因为这不是我的目标用户体验。崩溃是一种糟糕的用户体验。每个用户一次崩溃太多了。崩溃是一个错误。

话虽如此，我确实看到崩溃日志似乎无法解决，因为它们似乎表明了SDK中的问题。然而，我所学到的是，我自己的代码更有可能是最终的原因。

线程或块之间的时序问题可能导致任何数量的奇怪崩溃，或者仅仅是因为我做错了。就在最近，我发现我正在做一些与我正在更新的复杂表格完全错误的事情。此问题的崩溃日志几乎没有提供线索，除了我可能会看到的一般代码区域。当我挖掘代码并开始尝试时，我意识到我的错误，这最终是由我认为主线程与非主线程活动的巧妙分离引起的时序问题。在这种情况下，我对自己的利益太聪明了。 ： - ）

所以，总结一下：

• 一次崩溃导致崩溃太多，最终导致用户体验不佳。
• 通常，奇怪的低级别崩溃是您自己的代码复杂性和可能的​​时间问题的结果。

最后，我提出要考虑的问题：

• 您是否愿意仅仅因为遇到崩溃的用户占0.08％而惹恼或解雇您的某些用户？

深思熟虑。 ： - ）

Answer 4

我是一名专业的iPhone开发人员，而我所看到的是崩溃频率并不会让用户感到不安，它是崩溃发生的漏斗。

如果它们是间歇性的，您通常可以，当一个用户多次遇到特定的崩溃时，问题就会开始出现。这是不可接受的。

努力消除每次崩溃总是一件好事，但在很多情况下，这根本不现实，你必须决定你的时间花在哪里。如果您有机会重新编写UX流程的一部分或修复间歇性崩溃，则需要确定哪一个会使更多用户受益。

要记住的重要一点是，如果您选择不修复0.08％的时间发生的崩溃，那么除非他们多次遇到崩溃，否则您不会注销遇到它的用户。

Answer 5

虽然不是技术上的答案，但在我的iPhone上我个人希望有一个应用程序，我在一年中至少使用过一次或两次崩溃。我说这个级别是完全可以接受的，因为一般来说我发现它们在你第一次启动它时会崩溃很多我相信它是可以预期的。