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

【问题标题】：iOS app crash rate - background noise level?iOS 应用程序崩溃率 - 背景噪音水平？
【发布时间】：2012-04-11 03:28:23
【问题描述】：

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

一次崩溃发生了 19 次，另外 10 次，但其他 41 次都发生了 3 次或更少。如果该应用程序有任何重大问题，我预计会在特定领域看到更多的失败，所以我对我看到的数据水平感到满意。

快速查看其中许多是低级故障，不是明显引起的，而是程序员错误。

示例

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

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

我是否应该期望每加载 1-2000 次就会出现一个应用程序崩溃，只是因为操作系统不完美？有没有其他人有过类似经历？

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

【问题讨论】：

标签： ios crash operating-system crittercism

【解决方案1】：

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

他们得出的结论是，iOS 上最受欢迎的应用会在 0.51% 的应用启动时崩溃。所以@Ashley Mills，如果你得到 0.08%……你做得很好。（无论如何，我认为我的数字是正确的）。

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

Forbes app crash rates, conducted by Crittercism

【讨论】：

比平均值更好，这很好 - 但我仍然不知道底层操作系统崩溃率是多少。虽然，老实说，我将大部分失败归咎于该项目的其他开发人员。
"但是我的问题是，在一个足够复杂的操作系统（在这种情况下是 iOS）中，有一个足够复杂的应用程序（我认为是这样），作为开发人员，我是否应该期望看到这个“背景噪音”的水平？Crittercism 分析涵盖了数以万计的应用程序，对您来说应该是一个足够好的答案。用户的任何其他单一响应都只是基于少数几个应用程序。现在给我赏金，或者赏金会落在你的头上。答案是肯定的，期待噪音。
应用启动与用户会话有何关联？应用程序的后台处理和稍后的恢复对应于相同的应用程序启动还是单独的应用程序启动？
我不知道那篇文章，但我认为应用程序启动是首次启动或从后台启动。所以是的，一个用户会话。

【解决方案2】：

实际上，可能是另一个非技术性答案。当您可以花费更多时间和精力在您的工具中开发更多功能或完全使用其他工具时，继续深入研究该特定问题会给您（开发人员）带来什么附加值。

如果您的应用只是为了娱乐和学习，那么我可以将深入研究这个问题视为一次有趣的冒险。从业务的角度来看，您的时间价值是多少，并且正在解决这个 0.08% 的问题，以便销售足够（更多）的副本以使您的努力值得。

类似的情况是，什么要求是必要的，什么要求是愿望？只是思考的食物。我知道我工作过的许多公司都没有看到强调收益低的错误的价值。

【讨论】：

我同意它可能太小而无需担心，特别是因为有问题的应用程序仅用于消耗数据，因此在崩溃中不会真正“丢失”任何东西。我的问题（恐怕还没有回答）是出于我自己的好奇心。
我怀疑（如果您在上面的帖子中查看我的评论），那 0.08% 几乎是不可避免的。当您查看 MS Explorer 甚至 Safari 时，它会经常崩溃。不幸的是，即使我们有完美的代码，我们也可能（无论如何在 iOS 设备上）被硬件中的虚假位翻转所击中。 iOS 也没有硬件支持 ECC，如果您在代码区域有一点点翻转，您的代码将表现得异常甚至无法正常工作，在您的数据中，您可能会冒险（如果它在分支语句中使用）到一个意想不到的地方。当然这些不会经常发生，但是当你把所有东西都加起来时......
啊...你完全理解了我的问题。当您启动应用程序数百万次时，有时它可能会因程序员错误以外的原因而崩溃。现在，如果我们能看到这个比率是多少……在此期间，有 50 分 :)

【解决方案3】：

我是一名 iOS 开发人员，受雇于专业人士。当我的应用程序崩溃时，我个人认为这不是我想要的用户体验。崩溃是一种糟糕的用户体验。每个用户一次崩溃太多了。崩溃是一个错误。

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

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

所以，总结一下：

一次崩溃会导致多次崩溃，最终导致糟糕的用户体验。
通常，奇怪的低级崩溃是您自己代码的复杂性以及其中可能存在时间问题的结果。

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

您是否愿意仅仅因为 0.08% 的用户遇到崩溃而生气或解雇一些用户？

值得深思。 :-)

【讨论】：

你几乎是在暗示一个操作系统，在这种情况下是 iOS，是没有错误的，不可能是问题的原因，看看这里的数字......他说的是 0.08% 的用户.这是一个非常小的数量，并且可能存在非常模糊的错误，QA 测试人员甚至自动化测试都不会发现 - 除非它们真的经过压力测试。我愿意尽可能修复每一次崩溃 - 我无法承担的就是花费数天时间尝试修复发生 50,000 次中 1 次的不起眼的崩溃。
我知道 iOS 并非没有错误。我见过很多莫名其妙的崩溃，我的代码甚至不在有问题的堆栈跟踪中。所以，不，iOS 并不完美。但它很接近。 ;-) 最终，您必须在解决此类崩溃方面的努力与围绕它们的其他数据（例如频率）取得平衡，并最终从花时间首先修复它们中受益。
@bandejapaisa 我认为虽然崩溃可能是操作系统的错误，但在大多数 情况下，根本原因是应用程序开发人员代码中的错误。鉴于此，从商业角度来看，调查该错误可能是值得的，因为它可能指向您甚至不知道的其他休眠错误，并且当它们现在醒来一年后将更难调试。同样，是否调查此类错误纯粹是一个商业决定。
调查错误。虽然整体崩溃数量可能很低，但对于少数用户或少数设备而言，崩溃可能非常可重复。想象一下，如果您下载了一个应用程序并且它根本无法运行。这些用户可能永远不会再次尝试该应用程序，仅仅因为您从未看到他们再次崩溃并不意味着该错误已修复。这也是一次很好的学习经历。
我还可以补充一点，硬件也不完美。有一个原因是服务器、卫星和许多数据和处理关键硬件部件具有用于内存位错误检测和纠正的 ECC，闪存（许多）具有用于沿多字字段进行多位纠正的 BCH 代码等... 用今天的计算能力测试一个硬件的每个可能的输入到输出在理论上仍然是不可能的（讽刺的是不是）。大多数情况下，硬件仅经过约 95% 的测试。在硬件和操作系统不完善的情况下，即使是完美的应用代码也可能存在缺陷。

【解决方案4】：

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

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

努力消除每一次崩溃总是一件好事，但在许多情况下这根本不现实，您必须决定最好将时间花在哪里。如果您有机会重新设计部分 UX 流程或修复间歇性崩溃，您需要决定哪一个对更多用户有利。

要记住的重要一点是，如果您选择不修复发生率为 0.08% 的崩溃，那么除非用户多次遇到该崩溃，否则您并没有将其注销。

【讨论】：

【解决方案5】：

虽然不是技术性的答案，但我个人希望在我的 iPhone 上，我经常使用的应用程序在一年内至少会崩溃一两次。我会说这个级别是完全可以接受的，因为通常我发现它们在你第一次启动时崩溃得更多，我相信这是可以预料的。

【讨论】：

这是一个很高的期望。作为一名开发人员，我努力消除每一次崩溃。作为用户，偶尔的崩溃真的不会打扰我。如果它使应用程序无法使用，或者它中断了我的使用（例如在游戏进行中） - 那么我会担心。但是如果我使用的是 RSS 阅读器并且它崩溃了......我只是重新启动它。