pthread_create——Mi batalla con los hilos de Huawei

Cuánto tiempo sin verte. Al final del año, me gustaría hablar contigo sobre un extraño desbordamiento de recuerdos.

Sin más, empecemos por el crash.

Evidentemente se creó un hilo, de 1040kb, y la memoria se desbordó.

Es hora de que comparemos la situación general de desbordamiento de memoria.

Se produjo un desbordamiento de la memoria cuando se volvió a asignar la memoria.

Entonces adivinaría si las dos situaciones anteriores son causadas por memoria insuficiente, o si lo anterior es lo mismo que lo siguiente y es causado por memoria insuficiente.

¿Por qué falló cuando creé un hilo? La memoria necesaria para crear un hilo generalmente no es muy grande. ¿Es realmente una coincidencia que esta gota colmó el vaso?

Sacaré la conclusión directamente aquí, porque explorar las causas del desbordamiento de memoria en pthread_create no es el objetivo principal de este artículo. Este artículo analiza principalmente cómo combatirlo.

Todo el mundo debería saber que cuantos más hilos se crean, mayor es el consumo de recursos. El propio Android no limita el número máximo de hilos que una aplicación puede soportar, dejando el control al propio diseñador de la aplicación.

Entonces es obvio que los fabricantes nacionales no creen en el desarrollo nacional, o en otras palabras, debido a su propia personalización, los fabricantes nacionales todavía no pueden evitar crear mucha redundancia incluso si siguen el método de desarrollo de aplicaciones. . hilo.

Por tanto, Huawei tomó la delantera, y Meizu posteriormente ajustó el número de hilos controlables en un gran número de sus modelos a 500 y 3000 respectivamente.

Si tienes muchas dudas o aún estás confundido, te enviaré el siguiente portal.

En primer lugar, necesitamos encontrar todos los lugares relacionados con hilos que puedan aparecer en la aplicación. o busque Fuera de la aplicación donde pueden aparecer grupos de subprocesos.

Esto es sólo un ejemplo, no una lista exhaustiva.

Sin decir nada, comencemos con el método de construcción

Cuando llega una nueva tarea

En resumen, es core gt no central; gt; handler

Bien, después de que realmente descubramos qué está pasando con el Ejecutor, echemos un vistazo al RestAdapter de Retrofit1.

Ingrese a la clase Builder, la clase interna de RestAdapter.

Si no configura httpExecutor específicamente, Retrofit lo ayudará a configurar un grupo de subprocesos predeterminado. Sigamos viendo qué tipo de grupo de subprocesos es.

Vaya directamente a la clase de implementación de la plataforma Android para descubrir qué es defaultHttpExecutor. Después de mirar newCachedThreadPool, básicamente queda claro que utiliza el grupo de subprocesos de caché encapsulado por el sistema. p>

Según nuestro análisis anterior, hay 0 subprocesos principales y se utiliza una cola sincronizada. SynchronousQueue no tiene capacidad. Según la lógica actual, no lo explicaré en detalle aquí. que debe ejecutarse, se tomará inmediatamente una vez que se coloque. La cola de sincronización no se explicará en detalle aquí, puede estudiarla usted mismo. Se puede pensar que una vez que llega una tarea, se creará un nuevo hilo inmediatamente. Si el hilo está inactivo durante 60 segundos, se eliminará.

Por lo tanto, en teoría, este grupo de subprocesos puede generar subprocesos Integer.MAX_VALUE en casos extremos. Luego, cuando este número aumenta linealmente, puede ver el colapso de Huawei y Meizu (debido a su propia protección ANR, puede ser). difícil para usted ver el fallo del Meizu 3000, o incluso el fallo de otras decenas de miles de teléfonos móviles)

Por lo tanto, para evitar este tipo de situaciones, debemos brindar una solución personalizada para el grupo de subprocesos, usted Puede elegir un número máximo limitado de subprocesos para que coincida con la cola SynchronousQueue, o elegir un número máximo limitado de subprocesos para que coincida con otras clases de implementación de BlockingQueue con capacidad limitada.

Por ejemplo

Puede explorar y explorar usted mismo un conjunto de configuraciones de grupo de subprocesos que sean más adecuadas para los escenarios de su aplicación.

Recuerde, una vez que aparece un grupo de subprocesos con un límite superior, se debe establecer una política de desbordamiento. El nuevo método ThreadPoolExecutor.DiscardOldestPolicy() se usa arriba. Esta política descartará la cola de caché cuando el grupo de subprocesos. Se desborda El que entra primero, inserta el nuevo.

Optimizar el número de hilos es mucho más que eso.

Otro ejemplo son diferentes nombres de dominio de API. Por lo general, necesitamos crear diferentes objetos Retrofit y es necesario inicializar diferentes objetos Retrofit. Pasar diferentes OkhttpClient y el mismo OkhttpClient también tendrá una gran diferencia en el número de subprocesos. .

Lo más importante es ser bueno observando, probando, filtrando información inútil de los registros de fallas y localizando el punto de falla del hilo durante el proceso de codificación normal.

Finalmente, me rasqué la cabeza durante 10 minutos porque no podía entender el límite de hilos de Huawei.