En primer lugar, te recomiendo encarecidamente que uses il2cpp para el empaquetado de Android. Nuestro proyecto comparó mono y descubrió que il2cpp fallaba mucho menos que mono. Por lo general, se recomienda verificar Development Build y Autocontent Profiler para el empaquetado de control de calidad. De esta manera, si ocurre un bloqueo, puede localizarlo directamente desde el registro o conectar el generador de perfiles a la máquina real.
Veamos un registro de accidentes
Como se muestra en la figura a continuación, WorldSceneMgr.cs es nuestro propio código c #, aquí podemos ubicar directamente qué línea del bloqueo y la pila completa se puede usar para localizar el bloqueo en este momento porque el método CheckEventGenerator de WorldSceneMgr.cs llama a Función relacionada, lo que hace que el motor de física de la unidad se cuelgue.
Si es el paquete de versiones oficiales, la tabla de símbolos .so generada por el código c # que escribimos debe guardarse al empaquetar. Puede consultar la documentación de la unidad para el método de ahorro
La dirección del bloqueo se puede encontrar en el registro de errores y se puede restaurar mediante addr2line. El método detallado también puede hacer referencia a la documentación de la unidad.
https://support.unity3d.com/hc/en-us/articles/115000292166-Symbolicate-Android-crash
Si su proyecto todavía usa mono, también puede usar el método anterior para restaurar la pila de fallas.
Tal vez todos reciban el sdk del informe de fallos, no importa si tenemos un .so con una tabla de símbolos, podemos restaurar la pila de fallos. Por lo general, el desarrollo se empaquetará todos los días, pero el número de versión y el nombre del paquete son los mismos. Pero el archivo .so de cada paquete es diferente, por lo que al informar el bloqueo, debe enviar una bandera única para distinguirlo en el futuro.
Más tarde, encontramos otro problema. A veces, cuando QA estaba probando, se agotaban y fallaban, o la interfaz o la lógica eran anormales debido a un error de código. Dado que no tenían un registro detallado al informar el error, la tecnología de error poco clara solo se puede corregir adivinando. Así que creamos una herramienta de extracción de registros con un solo clic para el control de calidad.
Como se muestra en la siguiente figura, la tecnología copia adb.ext AdbWinApi.dll AdbWinUsbApi.dll fastboot.ext en su propio directorio sdk de Android, estas bibliotecas dependientes requeridas por adb.
El script es run.bat
@echo off
set "year=%date:~0,4%"
set "month=%date:~5,2%"
set "day=%date:~8,2%"
set "hour_ten=%time:~0,1%"
set "hour_one=%time:~1,1%"
set "minute=%time:~3,2%"
set "second=%time:~6,2%"
set adb="%~dp0\adb.exe"
echo %adb%
%adb% logcat -v time -d > %year%%month%%day%%hour_ten%%hour_one%%minute%%second%.log &Cuando la prueba de control de calidad se queda sin errores o fallas, solo necesita conectarse a la computadora en 2 minutos (un período corto de tiempo) y hacer doble clic rápidamente en run.bat para extraer automáticamente el registro completo del teléfono móvil actual. Es conveniente para nosotros ver la tecnología al enviar el error.
Nota: Si el asistente móvil 360 está instalado en la PC, el puerto adb estará ocupado (matar 360 no funcionará). Debes cerrar la interfaz de configuración del asistente 360. Recuérdame cuando el dispositivo esté conectado cuando el dispositivo esté encendido. Cierra el cuadro flotante y reinicia la computadora.