Solución de problemas y preguntas frecuentes de Crashlytics

Esta página proporciona ayuda para la resolución de problemas y respuestas a preguntas frecuentes sobre el uso de Crashlytics. Si no encuentra lo que busca o necesita ayuda adicional, comuníquese con el soporte de Firebase .

Solución de problemas generales/Preguntas frecuentes

Es posible que observes dos formatos diferentes para los problemas enumerados en la tabla de Problemas de Firebase console. Y es posible que también notes una característica llamada "variantes" dentro de algunos de tus problemas. ¡Este es el por qué!

A principios de 2023, implementamos un motor de análisis mejorado para agrupar eventos, así como un diseño actualizado y algunas funciones avanzadas para nuevos problemas (¡como variantes!). Consulte nuestra publicación de blog reciente para conocer todos los detalles, pero puede leer a continuación los aspectos más destacados.

Crashlytics analiza todos los eventos de su aplicación (como fallas, no fatales y ANR) y crea grupos de eventos llamados problemas : todos los eventos de un problema tienen un punto de falla común.

Para agrupar eventos en estos problemas, el motor de análisis mejorado ahora analiza muchos aspectos del evento, incluidos los marcos en el seguimiento de la pila, el mensaje de excepción, el código de error y otras características de plataforma o tipo de error.

Sin embargo, dentro de este grupo de eventos, los seguimientos de la pila que conducen al error pueden ser diferentes. Un seguimiento de pila diferente podría significar una causa raíz diferente. Para representar esta posible diferencia dentro de un problema, ahora creamos variantes dentro de los problemas: cada variante es un subgrupo de eventos en un problema que tiene el mismo punto de falla y un seguimiento de pila similar. Con variantes, puede depurar los seguimientos de pila más comunes dentro de un problema y determinar si diferentes causas raíz están provocando el error.

Esto es lo que experimentará con estas mejoras:

  • Metadatos renovados que se muestran dentro de la fila del problema
    Ahora es más fácil comprender y clasificar los problemas en su aplicación.

  • Menos problemas duplicados
    Un cambio de número de línea no genera un nuevo problema.

  • Depuración más sencilla de problemas complejos con diversas causas fundamentales
    Utilice variantes para depurar los seguimientos de pila más comunes dentro de un problema.

  • Alertas y señales más significativas
    Un nuevo problema en realidad representa un nuevo error.

  • Búsqueda más poderosa
    Cada problema contiene más metadatos de búsqueda, como el tipo de excepción y el nombre del paquete.

Así es como se están implementando estas mejoras:

  • Cuando recibamos nuevos eventos de su aplicación, verificaremos si coinciden con un problema existente.

  • Si no hay ninguna coincidencia, aplicaremos automáticamente nuestro algoritmo de agrupación de eventos más inteligente al evento y crearemos una nueva incidencia con el diseño de metadatos renovado.

Esta es la primera gran actualización que estamos realizando en nuestra agrupación de eventos. Si tiene comentarios o encuentra algún problema, háganoslo saber presentando un informe.

Si no ve métricas sin fallas (como usuarios y sesiones sin fallas) y/o alertas de velocidad, asegúrese de estar usando el SDK de CrashlyticsCrashlytics SDK 11.7.0+.

Si no ve registros de ruta de navegación , le recomendamos verificar la configuración de su aplicación para Google Analytics. Asegúrate de cumplir con los siguientes requisitos:

Si estás usando Unity IL2CPP y ves seguimientos de pila sin símbolos, intenta lo siguiente:

  1. Asegúrate de estar utilizando la versión 8.6.1 o superior del SDK de Crashlytics Unity.

  2. Asegúrese de estar configurado y ejecutando el comando crashlytics:symbols:upload Firebase CLI para generar y cargar su archivo de símbolos.

    Debe ejecutar este comando CLI cada vez que cree una compilación de lanzamiento o cualquier compilación para la que desee ver seguimientos de pila simbolizados en Firebase console. Obtenga más información en la página Obtenga informes de fallos legibles .

Sí, Crashlytics puede mostrar seguimientos de pila simbolizados para sus aplicaciones que usan IL2CPP. Esta capacidad está disponible para aplicaciones lanzadas en plataformas Android o Apple. Esto es lo que debes hacer:

  1. Asegúrate de estar utilizando la versión 8.6.0 o superior del SDK de Crashlytics Unity.

  2. Complete las tareas necesarias para su plataforma:

    • Para aplicaciones de la plataforma Apple : no se necesitan acciones especiales. Para las aplicaciones de la plataforma Apple, el complemento Firebase Unity Editor configura automáticamente su proyecto Xcode para cargar símbolos.

    • Para aplicaciones de Android : asegúrese de estar configurado y ejecutando el comando crashlytics:symbols:upload Firebase CLI para generar y cargar su archivo de símbolos.

      Debe ejecutar este comando CLI cada vez que cree una compilación de lanzamiento o cualquier compilación para la que desee ver seguimientos de pila simbolizados en Firebase console. Obtenga más información en la página Obtenga informes de fallos legibles .

El valor sin fallas representa el porcentaje de usuarios que interactuaron con su aplicación pero no tuvieron una falla durante un período de tiempo específico.

Aquí está la fórmula para calcular el porcentaje de usuarios sin fallas. Sus valores de entrada son proporcionados por Google Analytics.

CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100

  • Cuando ocurre una falla, Google Analytics envía un tipo de evento app_exception y CRASHED_USERS representa la cantidad de usuarios asociados con ese tipo de evento.

  • ALL_USERS representa la cantidad total de usuarios que interactuaron con su aplicación durante el período de tiempo que seleccionó en el menú desplegable en la parte superior derecha del panel de Crashlytics.

El porcentaje de usuarios sin fallos es una agregación a lo largo del tiempo , no un promedio.

Por ejemplo, imagina que tu aplicación tiene tres usuarios; los llamaremos Usuario A, Usuario B y Usuario C. La siguiente tabla muestra qué usuarios interactuaron con su aplicación cada día y cuáles de esos usuarios tuvieron una falla ese día:

Lunes Martes Miércoles
Usuarios que interactuaron con su aplicación A B C A B C A, B
Usuario que tuvo un accidente C B A

  • El miércoles, su porcentaje de usuarios sin fallas es del 50% (1 de cada 2 usuarios no tuvo fallas).
    Dos de sus usuarios interactuaron con su aplicación el miércoles, pero solo uno de ellos (Usuario B) no tuvo fallas.

  • Durante los últimos 2 días, su porcentaje de usuarios sin fallas es del 33,3 % (1 de cada 3 usuarios no tuvo fallas).
    Tres de sus usuarios interactuaron con su aplicación durante los últimos dos días, pero solo uno de ellos (Usuario C) no tuvo fallas.

  • Durante los últimos 3 días, su porcentaje de usuarios sin fallas es del 0 % (0 de cada 3 usuarios no tuvieron fallas).
    Tres de sus usuarios interactuaron con su aplicación durante los últimos tres días, pero ninguno de ellos tuvo fallas.

El valor de los usuarios sin fallos no debe compararse en diferentes períodos de tiempo. La probabilidad de que un solo usuario experimente una falla aumenta cuantas más veces usa su aplicación, por lo que es probable que el valor de los usuarios libres de fallas sea menor durante períodos de tiempo más largos.

Las notas permiten a los miembros del proyecto comentar sobre temas específicos con preguntas, actualizaciones de estado, etc.

Cuando un miembro del proyecto publica una nota, se etiqueta con el correo electrónico de su cuenta de Google. Esta dirección de correo electrónico es visible, junto con la nota, para todos los miembros del proyecto con acceso para ver la nota.

A continuación se describe el acceso necesario para ver, escribir y eliminar notas:

Consulte Comprender las métricas sin fallos .

Las notas permiten a los miembros del proyecto comentar sobre temas específicos con preguntas, actualizaciones de estado, etc.

Cuando un miembro del proyecto publica una nota, se etiqueta con el correo electrónico de su cuenta de Google. Esta dirección de correo electrónico es visible, junto con la nota, para todos los miembros del proyecto con acceso para ver la nota.

A continuación se describe el acceso necesario para ver, escribir y eliminar notas:

Integraciones

Si su proyecto utiliza Crashlytics junto con el SDK de anuncios de Google para móviles, es probable que los informadores de fallos estén interfiriendo al registrar controladores de excepciones. Para solucionar el problema, desactive los informes de fallos en el SDK de anuncios móviles llamando disableSDKCrashReporting .

Después de vincular Crashlytics a BigQuery, los nuevos conjuntos de datos que cree se ubican automáticamente en los Estados Unidos, independientemente de la ubicación de su proyecto de Firebase.

Problemas regresivos

Un problema ha tenido una regresión cuando lo cerró anteriormente, pero Crashlytics recibe un nuevo informe que indica que el problema ha vuelto a ocurrir. Crashlytics vuelve a abrir automáticamente estos problemas regresivos para que puedas abordarlos según corresponda para tu aplicación.

A continuación se muestra un escenario de ejemplo que explica cómo Crashlytics clasifica un problema como una regresión:

  1. Por primera vez, Crashlytics recibe un informe de fallo sobre el fallo "A". Crashlytics abre un problema correspondiente a ese bloqueo (Problema "A").
  2. Corrige este error rápidamente, cierra el problema "A" y luego publica una nueva versión de su aplicación.
  3. Crashlytics recibe otro informe sobre el problema "A" después de haber cerrado el problema.
    • Si el informe proviene de una versión de la aplicación que Crashlytics conocía cuando cerró el problema (lo que significa que la versión había enviado un informe de falla por cualquier falla), entonces Crashlytics no considerará que el problema ha retrocedido. La cuestión permanecerá cerrada.
    • Si el informe proviene de una versión de la aplicación que Crashlytics no conocía cuando cerró el problema (lo que significa que la versión nunca había enviado ningún informe de falla), entonces Crashlytics considera que el problema ha retrocedido y lo volverá a abrir. .

Cuando un problema regresa, enviamos una alerta de detección de regresión y agregamos una señal de regresión al problema para informarle que Crashlytics ha vuelto a abrir el problema. Si no desea que un problema se vuelva a abrir debido a nuestro algoritmo de regresión, "silencia" el problema en lugar de cerrarlo.

Si un informe proviene de una versión anterior de la aplicación que nunca había enviado ningún informe de fallas cuando cerró el problema, Crashlytics considera que el problema ha retrocedido y lo volverá a abrir.

Esta situación puede ocurrir en la siguiente situación: corrigió un error y lanzó una nueva versión de su aplicación, pero aún tiene usuarios en versiones anteriores sin la corrección del error. Si, por casualidad, una de esas versiones anteriores nunca había enviado ningún informe de fallos cuando usted cerró el problema, y ​​esos usuarios comienzan a encontrar el error, entonces esos informes de fallos desencadenarían un problema en regresión.

Si no desea que un problema se vuelva a abrir debido a nuestro algoritmo de regresión, "silencia" el problema en lugar de cerrarlo.

Informar excepciones no detectadas como fatales

Crashlytics puede informar excepciones no detectadas como fatales (a partir de la versión 10.4.0 del SDK de Unity). Las siguientes preguntas frecuentes ayudan a explicar los fundamentos y las mejores prácticas para utilizar esta función.

Al informar las excepciones no detectadas como fatales, obtienes una indicación más realista de qué excepciones pueden provocar que el juego no se pueda reproducir, incluso si la aplicación continúa ejecutándose.

Tenga en cuenta que si comienza a informar casos fatales, su porcentaje de usuarios sin fallas (CFU) probablemente disminuirá, pero la métrica CFU será más representativa de las experiencias de los usuarios finales con su aplicación.

Para que Crashlytics informe una excepción no detectada como fatal, se deben cumplir las dos condiciones siguientes:

Cuando empiece a recibir informes de excepciones no detectadas como fatales, aquí hay algunas opciones para manejar estas excepciones no detectadas:

Captar y manejar excepciones lanzadas

Las excepciones se crean y lanzan para reflejar estados inesperados o excepcionales . Resolver los problemas reflejados por una excepción lanzada implica devolver el programa a un estado conocido (un proceso conocido como manejo de excepciones ).

Es una buena práctica detectar y manejar todas las excepciones previstas, a menos que el programa no pueda regresar a un estado conocido.

Para controlar qué tipos de excepciones son capturadas y manejadas por qué código, incluya el código que podría generar una excepción en un bloque try-catch . Asegúrese de que las condiciones en las declaraciones catch sean lo más limitadas posible para manejar las excepciones específicas de manera adecuada.

Registrar excepciones en Unity o Crashlytics

Hay varias formas de registrar excepciones en Unity o Crashlytics para ayudar a depurar el problema.

Al utilizar Crashlytics, estas son las dos opciones más comunes y recomendadas:

  • Opción 1: imprimir en la consola de Unity, pero no informar a Crashlytics durante el desarrollo o la resolución de problemas

    • Imprima en la consola de Unity usando Debug.Log(exception) , Debug.LogWarning(exception) y Debug.LogError(exception) , que imprimen el contenido de la excepción en la consola de Unity y no vuelven a generar la excepción.

  • Opción 2: cargar en Crashlytics para obtener informes consolidados en el panel de Crashlytics para las siguientes situaciones:

    • Si vale la pena registrar una excepción para depurar un posible evento Crashlytics posterior, utilice Crashlytics.Log(exception.ToString()) .
    • Si aún se debe informar una excepción a Crashlytics a pesar de haber sido detectada y manejada, utilice Crashlytics.LogException(exception) para registrarla como un evento no fatal.

Sin embargo, si desea informar manualmente un evento fatal a Unity Cloud Diagnostics, puede usar Debug.LogException . Esta opción imprime la excepción en la consola de Unity como la Opción 1, pero también genera la excepción (ya sea que se haya lanzado o detectado todavía). Lanza el error de forma no local. Esto significa que incluso una Debug.LogException(exception) circundante con bloques try-catch todavía resulta en una excepción no detectada.

Por lo tanto, llame Debug.LogException si y sólo si desea realizar todo lo siguiente:

  • Para imprimir la excepción en la consola de Unity.
  • Subir la excepción a Crashlytics como un evento fatal.
  • Para generar la excepción, haga que se trate como una excepción no detectada y que se informe a Unity Cloud Diagnostics.

Tenga en cuenta que si desea imprimir una excepción detectada en la consola de Unity y cargarla en Crashlytics como un evento no fatal, haga lo siguiente:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}