Tasa de bloqueo de la aplicación iOS: nivel de ruido de fondo?

Acabamos de lanzar una aplicación utilizando el marco Crittercism. Después de un tiempo, hemos tenido cargas de aplicaciones de 125K y 95 fallas, una tasa de menos de 0.08%.Tasa de bloqueo de la aplicación iOS: nivel de ruido de fondo?

Un accidente ocurrió 19 veces, otros 10, pero los otros 41 todos ocurrieron 3 o menos. Si hubiera algún problema importante con la aplicación, esperaría ver un número significativamente mayor de fallas en áreas específicas, por lo que estoy satisfecho con el nivel de las cifras que estoy viendo.

Un vistazo rápido muestra que muchos de ellos son fallas de bajo nivel, no causadas obviamente, pero error del programador.

Ejemplos

el grupo más numeroso son todas que ver con CFNetworking en un subproceso en segundo plano mientras se está HTML estático que se queden en una vista web en el hilo principal.
Hay algunos fallos MVA en free_list_checksum_botch

Pero mi pregunta es, en un sistema operativo suficientemente compleja (IOS en este caso), con una aplicación suficientemente compleja (que yo creo que es), debe Yo, como desarrollador, espero ver este nivel de "ruido de fondo"?

¿Debo esperar ver una aplicación fallar por cargas de 1-2000, simplemente porque el sistema operativo no es perfecto? ¿Alguien más tuvo una experiencia similar?

(No estoy en busca de soluciones a los mismos errores .. gracias!)

Fuente

2012-03-27 Ashley Mills

Aunque no es una respuesta técnica, en mi iPhone me gustaría personalmente esperan tener una aplicación que utilizo un choque mucho, al menos, una o dos veces durante un año. Yo diría que ese nivel es perfectamente aceptable, y dado que, en general, creo que chocan mucho más la primera vez que lo comienzas, creo que es algo que se espera.

Fuente

2012-03-27 15:12:00

Eso es una gran expectativa. Como desarrollador, me esfuerzo por eliminar cada falla. Como usuario, el choque ocasional realmente no me molesta. Si hace que la aplicación no se pueda utilizar o si interrumpe mi uso (por ejemplo, en el medio de un juego), me preocuparé. Pero si estoy usando un lector de RSS y se colgó ... simplemente lo reinicio. – bandejapaisa

Soy un desarrollador de iOS, empleado profesionalmente. Lo tomo personalmente cuando se cuelgan mis aplicaciones, porque esa no es la experiencia de usuario a la que aspiraba. Un bloqueo es una mala experiencia de usuario. Un bloqueo, por usuario, es demasiado. Un choque es un error.

Dicho esto, he visto sin duda registros de errores que parecen no tener solución, ya que parecen estar indicando un problema muy dentro en el SDK. Lo que he aprendido, sin embargo, es que es más que probable que haya algo sobre mi propio código que en última instancia sea la causa.

Hay varios bloqueos extraños que pueden ser causados por problemas de sincronización entre subprocesos o bloques o simplemente porque hice algo mal. Recientemente descubrí que estaba haciendo algo completamente incorrecto con respecto a una tabla compleja que estaba actualizando. Los registros de fallos para este problema no proporcionaron casi ninguna pista, excepto el área general de código que podría ver. A medida que profundicé en el código y comencé a experimentar, me di cuenta de mi error, que en última instancia fue un problema de temporización causado por lo que pensé que era una inteligente separación de la actividad del hilo principal frente a la del hilo principal. Yo era demasiado listo para mi propio bien, en este caso. :-)

Por lo tanto, para resumir:

Un accidente es demasiado muchos accidentes y en última instancia, una mala experiencia de usuario.
A menudo, los bloqueos de bajo nivel extraños son el resultado de la complejidad de su propio código y, posiblemente, los problemas de sincronización en.

Finalmente, ofrezco esta cuestión a tener en cuenta:

¿Está dispuesto a cabrear o despedir a algunos de los usuarios simplemente porque caen en el 0,08% de los usuarios que experimentan los accidentes?

Alimento para el pensamiento. :-)

Fuente

2012-03-27 15:25:12

Tienes razón, por supuesto, 1 caída realmente es demasiada. Pero en esto solo se trata de una aplicación de consumo, por lo que lo peor que le puede pasar a un usuario es que terminan en el trampolín (muchos ni siquiera lo leen como un bloqueo), y al reiniciar la aplicación los devuelve a donde estaban. ... ningún daño hecho. Y estoy totalmente contigo sobre la causa de muchos misteriosos errores. Me gustaría tener una idea de qué nivel (si hay uno) de fallas se deben a problemas inherentes del sistema operativo. –

Está casi sugiriendo que un SO, iOS en este caso, está libre de errores y no podría ser la causa de problemas, y mire los números aquí ... habla del 0.08% de los usuarios. Esta es una cantidad muy pequeña, y podría haber errores muy oscuros que nunca son recogidos por los verificadores de QA o incluso por las pruebas automáticas, a menos que estén realmente sometidos a una prueba de estrés. Estoy dispuesto a arreglar cada accidente que pueda, lo que no puedo permitirme es pasar días intentando solucionar un bloqueo oscuro que ocurre 1 de cada 50,000 veces. – bandejapaisa

Sé que iOS no está libre de errores. He visto muchos bloqueos inexplicables en los que mi código ni siquiera estaba en la traza de la pila ofensiva. Entonces, no, iOS no es perfecto. Pero está cerca. ;-) En última instancia, debe equilibrar su esfuerzo para resolver este tipo de fallas con otros datos que lo rodean (por ejemplo, la frecuencia) y beneficiarse al final de dedicar el tiempo para solucionarlos en primer lugar. –

Soy un desarrollador profesional de iPhone, y lo que he visto es que la frecuencia de colisiones no es lo que molesta a los usuarios, sino el embudo de cómo ocurren los bloqueos.

Si son intermitentes, generalmente está bien, el problema comienza a ocurrir cuando un usuario experimenta un bloqueo específico varias veces. Esto es inaceptable.

Esforzarse por eliminar cada choque siempre es algo bueno, pero en muchos casos simplemente no es realista, debe decidir dónde pasar mejor su tiempo. Si tiene la oportunidad de volver a trabajar una parte del flujo de UX o corregir un bloqueo intermitente, debe decidir cuál beneficia a más usuarios.

Lo importante que debe recordar es que si elige no reparar un bloqueo que ocurre el 0.08% de las veces, no está cancelando los usuarios que lo experimentan a menos que lo experimenten varias veces.

Fuente

2012-05-01 17:07:24

Crittercism realizó un análisis de bloqueos de aplicaciones. Su informe se basó en accidentes de Android vs iOS.

Concluyeron que las aplicaciones más populares en iOS bloquean el 0.51% de los lanzamientos de aplicaciones. Entonces, @Ashley Mills, si obtiene 0.08% ... lo está haciendo bien. (Creo que tengo mis cifras correctas, de todos modos).

No está seguro de que el informe original es, pero lo leí aquí:

Forbes app crash rates, conducted by Crittercism

Fuente

2012-05-30 18:47:43 bandejapaisa

Mejore ese promedio, lo cual es bueno, pero aún no sé cuál es la tasa de bloqueo del sistema operativo subyacente. Aunque, para ser honesto, culpo al otro desarrollador del proyecto por la mayoría de sus fallas. –

"Pero mi pregunta es, en un sistema operativo suficientemente complejo (iOS en este caso), con una aplicación suficientemente compleja (que creo que es), ¿debería yo, como desarrollador, esperar ver este nivel de" ruido de fondo "? El análisis Crittercism cubre decenas de miles de aplicaciones y debería ser una buena respuesta para usted. Cualquier otra respuesta individual de un usuario se basará en un puñado de aplicaciones. Ahora dame la recompensa, o la recompensa irá a la cabeza. .La respuesta es SÍ, espera ruido – bandejapaisa

¿Cómo se correlacionan las aplicaciones con las sesiones de los usuarios? ¿La creación de fondo de la aplicación y su posterior reanudación corresponden al mismo lanzamiento de la aplicación o lanzamientos de aplicaciones separados? – Dalmazio

En realidad otra oportunidad en la respuesta no técnica oscura podría ser. ¿Qué valor agregado le traerá (el desarrollador) para seguir profundizando en ese tema en particular, cuando podría estar gastando más tiempo y esfuerzo, ya sea desarrollando más capacidades dentro de su herramienta, o de otra herramienta por completo?

Si su aplicación es simplemente para divertirse y aprender, entonces podría ver en este tema como una aventura divertida. Desde una perspectiva comercial, ¿cuál es su tiempo valioso y está resolviendo que este problema del 0.08% va a vender suficientes (más) copias para que sus esfuerzos valen la pena.

Un análogo sería, ¿qué requisitos son esenciales y qué requisitos son los deseos? Solo algo para pensar. Sé que muchas de las empresas para las que he trabajado no ven el valor de hacer hincapié en el bajo rendimiento.

Fuente

2012-05-31 06:01:44 trumpetlicks

Estoy de acuerdo en que es probablemente demasiado pequeño para preocuparse, sobre todo porque la aplicación en cuestión es para consumo solo de datos, por lo que nada puede "perderse" en un choque. Mi pregunta (hasta ahora sin respuesta, me temo) fue por mi propia curiosidad. –

Sospecho que (si miras mi comentario en un hilo anterior), ese 0.08% es casi inevitable. Cuando miras MS Explorer, o incluso Safari, se bloquea con bastante regularidad. Desafortunadamente, incluso si tuviéramos un código perfecto, podríamos recibir un golpe (en dispositivos iOS de todos modos) con un falso cambio de hardware. iOS ni el hardware son compatibles con ECC, y si tiene un pequeño cambio en un área de código, su código actuará de manera peculiar o incluso no funcionará, en sus datos podrá aventurarse (si lo usó en una declaración de sucursal) a un lugar inesperado. De acuerdo, esto no sucede a menudo, pero cuando se agrega todo ....... – trumpetlicks

Ah ... ha captado mi pregunta exactamente. Cuando ejecutas una aplicación millones de veces, ocasionalmente puede fallar por algo que no sea un error del programador. Ahora, si pudiéramos ver cuál era esa tasa ... Mientras tanto, tenga 50 puntos :) –

Tasa de bloqueo de la aplicación iOS: nivel de ruido de fondo?

Respuesta

Cuestiones relacionadas