Una de las características que brindamos a los editores de aplicaciones en SafeDK, tanto para Android como para iOS, es el informe de fallas y esto significa que he visto muchos escenarios de fallas y seguimientos de pila en mis días.
Ahora, mientras nos centramos en cómo el código de terceros puede bloquear su aplicación, durante las fases de prueba exploramos la aplicación en su conjunto y vemos bastantes escenarios.
En mi experiencia con clientes que tienen tanto una versión de Android como una de iOS, no puedo afirmar categóricamente que las de iOS son mucho menos. Pero puedo pensar en varios casos por los que Android es mucho más propenso a la inestabilidad.
- Cómo usar PubNub para crear una aplicación de atención al cliente que tenga características básicas como ClickDesk y Pure Chat
- ¿Qué pasó con el iPhone SE?
- ¿Existe una plataforma para desarrolladores de aplicaciones iOS que proporcione recomendaciones para ingresos y fuentes de tráfico?
- Aplicaciones de iOS: ¿Cuál es un buen editor de texto para iPhone con soporte DropBox?
- ¿Cuáles son las aplicaciones para hacer videollamadas y video chat?
En primer lugar, a menudo es ridículamente fácil escribir una pequeña aplicación en Android. ¿Por qué? Debido a que está basado en Java y muchas personas saben cómo codificar en Java (tuve un curso obligatorio durante mi licenciatura en CS). Dado que muchas personas saben cómo codificar, y hay bastantes ejemplos para comenzar, puede hacer mucho fácilmente sin comprender realmente lo que hay debajo del capó. No necesita preocuparse por la administración de la memoria, por un lado (o eso cree). Desarrollar para iOS es una historia diferente. El lenguaje y el marco son mucho más de bajo nivel, el conocimiento y la comprensión de los conceptos generalmente se requieren en niveles superiores y, como resultado, los editores a menudo buscan desarrolladores más calificados y conocedores que se preocupan mucho más de que su código no solo esté ejecutando una tarea, sino También lo estoy haciendo muy bien. (Sin embargo, tenga en cuenta que esto es solo una observación de lo que he encontrado personalmente).
Además, Google solo recientemente comenzó a ponerse al día con todo el concepto de “pruébelo antes de lanzarlo”, tanto en términos de pruebas internas como de integridad y beta testers. Además, el proceso de llevar una aplicación a un usuario en iOS es mucho más costoso.
El principal problema con Android es que es muy abierto. Esto permite una amplia gama de posibilidades y capacidades, pero hace que sea imposible probar realmente una aplicación. Hemos visto un escenario que estaba bien en todos los ámbitos, pero que seguía fallando en un modelo específico de Samsung debido a los cambios realizados en el SDK y el sistema operativo Android en ese modelo específico.
En otro escenario, vimos un modelo que cambió el sistema operativo y permitió a los usuarios deshabilitar los permisos antes de que formara parte del marco oficial de Android (es decir, permisos de tiempo de ejecución en Android Marshmallow). La decisión del fabricante fue lanzar una SecurityException (como cuando el permiso no estaba definido en el manifiesto) que bloqueaba la aplicación si no se manejaba. Por supuesto, los desarrolladores (un desarrollador de SDK en este escenario) no anticiparon esto y causaron el bloqueo de todas las instancias de la aplicación. Registramos 17,000 accidentes en menos de 24 horas.
Además, esto hace que la calidad de los dispositivos Android sea mucho más baja y menos propensa a actualizarse. Los cambios en el hardware y el marco a menudo hacen que sea imposible para los usuarios obtener actualizaciones importantes. Entonces, si bien los desarrolladores continúan utilizando las últimas herramientas de compilación y realizan pruebas en dispositivos más limpios, mejores y más actualizados, esto con demasiada frecuencia no puede imitar el comportamiento de usuarios reales y dispositivos reales en el mundo real.
Sin embargo, por mucho que Android esté abierto, también es muy complejo. Usarlo sabia y correctamente no es una tarea fácil. Es por eso que vemos muchos instanes donde los desarrolladores sobrecargan el hilo de la interfaz de usuario, usan mal el diseño y cometen algunos errores fundamentales que a menudo resultan en fallas. La variedad de dispositivos también es un factor importante aquí. Llamar a un método inocente como getActiveNetworkInfo generalmente funciona bien en la oficina, pero nuestro extenso análisis ANR (Application Not Responding) nos muestra que esto tiene un gran impacto en la experiencia del usuario, específicamente porque el dispositivo tiene poca memoria y / o CPU.
Pero no todo es culpa de los desarrolladores. La complejidad de Android a menudo resulta en un comportamiento inesperado. Sentí una verdadera simpatía por los desarrolladores que estaban desconcertados por bloqueos que no deberían haber ocurrido. Yo mismo me quedé perplejo cuando un objeto Parceable construido por el sistema operativo y enviado a mí a través de un Intent fue simplemente inconsistente en el comportamiento.
Un ejemplo que vimos fue cuando Android decidió reforzar la seguridad y extrajo el componente Webview del sistema operativo a su propia aplicación [sistema] en el dispositivo al reconstruir el marco para Android Lollipop. De esa manera, podrían impulsar la seguridad actualizada para todos los usuarios, independientemente de los cambios de hardware y fabricante. Y, de hecho, la aplicación recibe una actualización aproximadamente cada dos semanas. Sin embargo, los dispositivos Lollipop aún tienen un error que hace que las aplicaciones se bloqueen cuando intentan acceder a la vista web durante una de sus actualizaciones frecuentes. En un caso, vimos 100,000 bloqueos en el lapso de 2 días para una aplicación con un promedio de 500,000 usuarios activos diarios.
Y, por último, tanto los desarrolladores de iOS como de Android corren el riesgo de fallar al introducir código de terceros. Según nuestra última encuesta de más de 150,000 aplicaciones de Android, las encontramos usando 17.8 SDK en promedio, es decir, casi 18 bibliotecas. Para anuncios, análisis, pagos y mucho más. Vimos empresas grandes y pequeñas que introducen bloqueos en las aplicaciones, y las aplicaciones tardan en actualizar estas bibliotecas con las correcciones de errores necesarias porque ejerce una presión adicional sobre los ciclos de lanzamiento y prueba.
Los SDK de terceros no siempre prevén cómo se utilizarán, en qué escenario podrían encontrarse y la integración puede variar de una aplicación a otra. Es por eso que es mucho más probable que se bloqueen o que usen excesivamente la memoria o la batería. Y ser un tercero a menudo significa que confían en los comentarios de los desarrolladores para conocer sus fallas y mejorar. A veces, los desarrolladores eliminan estas bibliotecas sin esos comentarios y siguen teniendo errores.
Lo vemos más a menudo con SDK de publicidad. Creatividades complejas, código JavaScript dentro de vistas web que sale mal y mucho más. Cuando los anuncios reproducibles llegaron al mercado hace seis meses, los problemas de memoria aumentaron y los bloqueos se acumulaban.
No puedo decir que iOS se bloquea menos con certeza. Puedo dar testimonio de una corazonada basada en la experiencia pasada y algunos datos ampíricos que pueden o no dar testimonio del grupo más grande de aplicaciones.
Sin embargo, creo que la excesiva apertura de Android, junto con su complejidad y la inquebrantable ligereza de lanzar una aplicación con un conocimiento inferior al profesional, hace que sea mucho más propensa a fallar.
En mi experiencia, los accidentes pueden estar contaminados con dispositivos específicos e incluso, sorprendentemente, países. Por lo tanto, solo cubren un pequeño subconjunto de usuarios. A cada parte pequeña no se le da mucha prioridad ya que es muy pequeña (por ejemplo, el 0.05% de los usuarios), pero en conjunto, los diferentes tipos de bloqueos equivalen a mucho más y se habrían solucionado mucho más rápido. Es menos probable que esto ocurra en un entorno más uniforme, como iOS, donde las actualizaciones se lanzan a menudo y se adoptan rápidamente por una gran mayoría.
En mi experiencia, lo mejor que puedes hacer es que nos quejemos. Revisiones de la tienda, departamento de quejas, lo que sea fácil y disponible. Ser específico y proporcionar detalles te ayudará a seguir usando aplicaciones y a reducir accidentes. Después de todo, los jugadores serios no quieren perder a ningún usuario en un mundo donde cada usuario es potencialmente un generador de dinero.
