16

We've just released an app using the Crittercism framework. After some time, we've had about 125K app loads, and 95 crashes - a rate of less than 0.08%.

One crash happened 19 times, another 10, but the other 41 all occurred 3 or less. If there were any major problems with the app, I would expect to see significantly more failures in particular areas, so I'm happy with the level of figures I'm seeing.

A quick look shows many of them to be low level failures, not obviously caused but programmer error.

Examples

  • The largest group are all to do with CFNetworking on a background thread while static HTML is being being rendered in a web view on the main thread.
  • There are some KVO failures in free_list_checksum_botch

But my question is, in a sufficiently complex OS (iOS in this case), with a sufficiently complex app (which I think it is), should I, as a developer, expect to see this level of "background noise"?

Should I expect to see one app crash per 1-2000 loads, just because the OS isn't perfect? Has anyone else had a similar experience?

(I'm not looking for solutions to the errors themselves.. thanks!)

4

5 に答える 5

6

Crittercism は、アプリのクラッシュに関する分析を実施しました。彼らのレポートは、Android と iOS のクラッシュに基づいています。

彼らは、iOS で最も人気のあるアプリは、アプリの起動の 0.51% をクラッシュさせると結論付けました。だから@Ashley Mills、0.08％を取得している場合...うまくやっています。（とにかく、私の数字は正しいと思います）。

元のレポートがどこにあるかはわかりませんが、ここで読みました。

Crittercism が実施した Forbes アプリのクラッシュ率

于 2012-05-30T18:47:43.843 に答える
6

実際には、暗い非技術的な答えの別のショットが可能性があります。ツール内でより多くの機能を開発するか、別のツールを完全に開発するために、より多くの時間と労力を費やすことができる場合、その特定の問題を掘り下げ続けることで、開発者にどのような付加価値がもたらされるでしょうか。

あなたのアプリが単に楽しみと学習のためのものであれば、この問題を掘り下げるのは楽しい冒険だと思います。ビジネスの観点から言えば、あなたの時間の価値は何であり、この 0.08% の問題が、あなたの努力に見合うだけの十分な (より多くの) コピーを販売することになると考えることです。

似ているのは、どの要件が必須であり、どの要件が欲求であるかということです。考えるだけの食べ物です。私が働いてきた企業の多くは、バグの発生率が低いことを強調することに価値を見いだしていないことを私は知っています。

于 2012-05-31T06:01:44.087 に答える
4

私はiOS開発者であり、専門的に雇用されています。それは私が目指していたユーザーエクスペリエンスではないため、アプリがクラッシュしたときに個人的にそれを取ります。クラッシュはユーザーエクスペリエンスの低下です。ユーザーごとに1回のクラッシュは多すぎます。クラッシュはバグです。

そうは言っても、SDKの奥深くで問題を示しているように見えるため、解決できないように見えるクラッシュログを確実に目にしました。しかし、私が学んだことは、最終的には自分のコードについて何かがある可能性が高いということです。

スレッドまたはブロック間のタイミングの問題によって、または私が何か間違ったことをしたという理由だけで引き起こされる可能性のある奇妙なクラッシュはいくつもあります。つい最近、更新中の複雑なテーブルに関して、まったく間違ったことをしていることに気づきました。この問題のクラッシュログは、私が見るかもしれないコードの一般的な領域を除いて、ほとんど手がかりを提供しませんでした。コードを掘り下げて実験を始めると、間違いに気づきました。これは、メインスレッドと非メインスレッドのアクティビティを巧妙に分離したことが原因であると考えたタイミングの問題でした。この場合、私は自分の利益のために賢すぎました。:-)

したがって、要約すると、次のようになります。

  • 1つのクラッシュはクラッシュが多すぎて、最終的にはユーザーエクスペリエンスが低下します。
  • 多くの場合、奇妙な低レベルのクラッシュは、独自のコードの複雑さと、場合によってはそこでのタイミングの問題の結果です。

最後に、考慮すべきこの質問を提供します。

  • クラッシュを経験しているユーザーの0.08％に該当するという理由だけで、一部のユーザーを怒らせたり、解雇したりしますか？

思考の糧。:-)

于 2012-03-27T15:25:12.430 に答える
2

私はプロの iPhone 開発者であり、クラッシュの頻度はユーザーを混乱させるものではなく、クラッシュが発生する経路です。

それらが断続的に発生する場合、通常は問題ありませんが、1 人のユーザーが特定のクラッシュを複数回経験すると、問題が発生し始めます。これは受け入れがたい。

すべてのクラッシュを排除しようとすることは常に良いことですが、多くの場合、それは現実的ではなく、どこに時間を費やすのが最適かを判断する必要があります。UX フローの一部を修正したり、断続的なクラッシュを修正したりする機会がある場合は、どちらがより多くのユーザーに利益をもたらすかを判断する必要があります。

覚えておくべき重要なことは、0.08% の確率で発生するクラッシュを修正しないことを選択した場合、複数回経験していない限り、それを経験しているユーザーを帳消しにすることにはならないということです。

于 2012-05-01T17:07:24.093 に答える
0

技術的な回答ではありませんが、私の iPhone では、よく使うアプリが年に 1 回か 2 回クラッシュすることが個人的に予想されます。そのレベルは完全に許容できると思います。一般的に、最初に起動したときにクラッシュすることが多いので、それは予想されることだと思います.

于 2012-03-27T15:12:00.357 に答える