iOS App-Absturzrate - Hintergrundgeräuschpegel?

Question

Wir haben gerade eine App mit dem Crittercism Framework veröffentlicht. Nach einiger Zeit hatten wir etwa 125.000 App-Ladungen und 95 Abstürze - eine Rate von weniger als 0,08%.

Ein Unfall geschah 19 Mal, weitere 10, aber die anderen 41 alle 3 oder weniger aufgetreten. Wenn es große Probleme mit der App gäbe, würde ich erwarten, dass es in bestimmten Bereichen wesentlich mehr Ausfälle geben wird. Daher bin ich mit dem Zahlenniveau, das ich sehe, zufrieden.

Ein kurzer Blick zeigt viele von ihnen zu Low-Level-Fehler, nicht offensichtlich verursacht, aber Programmierer Fehler.

Beispiele

• Die größte Gruppe sind alle mit CFNetworking auf einem Hintergrund-Thread zu tun, während statische HTML ist in einer Web-Ansicht auf dem Haupt-Thread gemacht zu werden zu werden.
• Es gibt einige KVO Ausfälle in free_list_checksum_botch

Aber meine Frage ist, in einem ausreichend komplexen OS (iOS in diesem Fall), mit einer ausreichend komplexen app (was ich denke, es ist), sollten Ich, als Entwickler, erwarte dieses Niveau von "Hintergrundgeräuschen" zu sehen?

Sollte ich einen App-Crash pro 1-2000 Ladevorgänge erwarten, nur weil das Betriebssystem nicht perfekt ist? Hat jemand anderes eine ähnliche Erfahrung gemacht?

(Ich bin nicht selbst nach Lösungen für die Fehler .. Dank! Suchen)

Answer 1

Obwohl keine technische Antwort auf meinem iPhone würde ich persönlich erwarte eine app, die ich zumindest vielen Absturz verwenden haben ein- oder zweimal im Jahr. Ich würde sagen, dass dieses Level vollkommen akzeptabel ist, und da ich im Allgemeinen finde, dass sie beim ersten Start viel mehr abstürzen, glaube ich, dass es etwas zu erwarten ist.

Answer 2

Ich bin ein iOS-Entwickler, berufstätig. Ich nehme es persönlich, wenn meine Apps abstürzen, weil das nicht die Benutzererfahrung ist, die ich anstrebte. Ein Absturz ist eine schlechte Benutzererfahrung. Ein Absturz pro Benutzer ist zu viel. Ein Absturz ist ein Fehler.

Ich habe definitiv Crash-Logs gesehen, die scheinbar unlösbar sind, weil sie ein Problem tief im SDK anzuzeigen scheinen. Was ich jedoch gelernt habe, ist, dass es höchstwahrscheinlich etwas an meinem eigenen Code gibt, der letztendlich die Ursache ist.

Es gibt jede Menge bizarre Abstürze, die durch Timing-Probleme zwischen Threads oder Blöcken verursacht werden können, oder nur weil ich etwas falsch gemacht habe. Erst vor kurzem habe ich entdeckt, dass ich in Bezug auf einen komplexen Tisch, den ich auf den neuesten Stand gebracht habe, etwas völlig falsches gemacht habe. Die Absturzprotokolle für dieses Problem lieferten fast keine Hinweise außer für den allgemeinen Bereich des Codes, den ich mir ansehen könnte. Als ich mich in den Code vertiefte und anfing zu experimentieren, erkannte ich meinen Fehler, der letztendlich ein Timing-Problem war, das durch eine clevere Trennung von Hauptthread- und Nicht-Hauptthread-Aktivität verursacht wurde. Ich war in diesem Fall zu schlau für mich. :-)

Also, um es zusammenzufassen:

• Ein Absturz zu viele Abstürze ist und letztlich eine schlechte Benutzererfahrung.
• Oft sind bizarre Low-Level-Abstürze das Ergebnis der Komplexität Ihres eigenen Codes und möglicher Timing-Probleme.

Schließlich biete ich diese Frage zu prüfen:

• Sind Sie bereit, einige Ihrer Benutzer zu verärgern oder entlassen, nur weil sie in die 0,08% der Nutzer fallen Abstürze erlebt?

Denkanstoß. :-)

Answer 3

Ich bin ein professioneller iPhone-Entwickler, und was ich gesehen habe, ist die Absturzhäufigkeit ist nicht das, was Benutzer verärgert, es ist der Trichter für, wie die Unfälle passieren.

Wenn sie intermittierend sind Sie in der Regel in Ordnung, das Problem tritt auf, wenn ein Benutzer einen bestimmten Absturz mehrere Male erlebt. Das ist inakzeptabel.

Das Bestreben, jeden Absturz zu entfernen, ist immer eine gute Sache, aber in vielen Fällen ist es einfach nicht realistisch, Sie müssen entscheiden, wo Ihre Zeit am besten ist. Wenn Sie die Möglichkeit haben, einen Teil des UX-Flusses zu überarbeiten oder einen zeitweiligen Absturz zu beheben, müssen Sie entscheiden, welcher davon für mehr Benutzer von Vorteil ist.

Die wichtige Sache zu erinnern ist, wenn Sie sich entscheiden, einen Absturz nicht zu beheben, der 0,08% der Zeit passiert, Sie schreiben die Benutzer nicht ab, es erfahren, es sei denn sie erfahren es mehrmals.

Answer 4

Crittercism führte eine Analyse zu App-Abstürzen durch. Ihr Bericht basierte auf Android- und iOS-Abstürzen.

Sie kamen zu dem Schluss, dass die beliebtesten Apps auf iOS 0,51% der App-Starts abstürzen. Also @Ashley Mills, wenn du 0,08% bekommst ... geht es dir gut. (ich denke, ich habe meine Zahlen sowieso korrekt).

nicht sicher, wo der ursprüngliche Bericht, aber ich las es hier:

Forbes app crash rates, conducted by Crittercism

Answer 5

Eigentlich ein weiterer Schuss im Dunkeln nicht-technische Antwort könnte sein. Welchen zusätzlichen Nutzen bringt es Ihnen (dem Entwickler), sich weiter mit diesem speziellen Problem zu beschäftigen, wenn Sie mehr Zeit und Aufwand investieren, um entweder mehr Möglichkeiten innerhalb Ihres Tools oder ein anderes Tool vollständig zu entwickeln.

Wenn Ihre App einfach zum Spaß und zum Lernen ist, dann könnte ich sehen, wie Sie dieses Thema als ein lustiges Abenteuer erkunden. Aus geschäftlicher Sicht, was ist Ihre Zeit wert und stellt fest, dass dieses Problem mit 0,08% genug (mehr) Kopien verkauft, um Ihre Bemühungen wert zu machen.

Analog wäre, welche Anforderungen sind wesentlich, und welche Anforderungen sind Wünsche? Nur zum Nachdenken. Ich weiß, dass viele der Firmen, für die ich gearbeitet habe, nicht den Wert sehen, wenn sie über diesen Niedrigstand eines nachgebenden Fehlers betonen.