el desarrollo de Android de alto rendimiento (optimización de la memoria)

Los problemas de memoria: anormal (fallo de memoria OOM asignación, etc.), Caton
mejoras ambas direcciones:

Optimización de la memoria RAM

Esa memoria en tiempo de ejecución reducida. programa OOM para prevenir la aparición de una excepción, así como la reducción de la probabilidad de programa debido a que la memoria es demasiado grande para ser matado mecanismo LMK.

optimización ROM

Es decir, reducido al volumen del programa ROM. Aquí se trata principalmente de reducir el espacio ocupado por el programa de prevención debido a la falta de pistas espacio ROM no se puede instalar.

El desarrollo de dispositivos móviles

Equipo calificación de desempeño:
los dispositivos móviles se han desarrollado una biblioteca de código abierto de Facebook llamada clase anual dispositivo.

2008 140 MB de RAM, 2018 mate 20 Pro 8 GB de RAM.

Mito: La memoria nativa no controlan

la cantidad de memoria nativa, la memoria física es insuficiente, lmk comenzó a matar el proceso.
por ejemplo: mapa de bits asignado manualmente al montón nativo y puesto en libertad.

// 步骤一：申请一张空的 Native Bitmap
Bitmap nativeBitmap = nativeCreateBitmap(dstWidth, dstHeight, nativeConfig, 22);

// 步骤二：申请一张普通的 Java Bitmap
Bitmap srcBitmap = BitmapFactory.decodeResource(res, id);

// 步骤三：使用 Java Bitmap 将内容绘制到 Native Bitmap 中
mNativeCanvas.setBitmap(nativeBitmap);
mNativeCanvas.drawBitmap(srcBitmap, mSrcRect, mDstRect, mPaint);

// 步骤四：释放 Java Bitmap 内存
srcBitmap.recycle();
srcBitmap = null；

detección de fugas de memoria y modificación

pérdida de memoria

A. Un programa de monitoreo pérdida de memoria

Método uno: leakcanry

Se ciclo de vida de actividad o investigación por parte de un objeto de referencia débil, si las pérdidas de memoria se encuentran descargan automáticamente el archivo hprof, obtener la revelación del camino más corto por la biblioteca HAHA, y finalmente a través del programa de notificación.

• dumphprof todavía causa la aplicación aparente Caton (Tema SuspendAll).

Por leakcanry realizar una personalización sencilla, podemos alcanzar el siguiente bucle cerrado vigilancia de una pérdida de memoria.

Segundo método: DDMS

Después de Android Studio 3.0 abierta DDMS Google no puede renunciar a DDMS

• En el SDK de android-sdk / tools / [comando ruta y ADB configuración es la misma ruta] allí archivos por lotes monitor.bat;
  

1, es necesario hacer clic en el montón de actualización en un proceso de depuración

2, haga clic en el lado derecho de la carretera usando la pila, haga clic en la causa gc, la situación se puede ver en la memoria en tiempo real

Método tres: la línea de comandos

adb shell dumpsys meminfo <package_name | pid> [-d]

adb shell ps para encontrar el correspondiente nombre de pid o paquete

Método cuatro: Asignación Rastreador

• Fragmentación de la información
• Al igual que con Traceview, análisis automatizado no se puede hacer, iniciar manualmente cada extremo.
• Asignación de seguimiento de tiempo y no causará demasiado impacto en el rendimiento del teléfono en sí, pero antes de que se detiene hasta que el volcado de datos, e incluso teléfono móvil normal pegado ANR.

Método cinco: Android Studio Profiler

II. Memoria del sistema Fix fugas Hack

listas AndroidExcludedRefs algunas de las razones citaron ejemplos porque el sistema no puede ser liberado, al mismo tiempo, para la mayoría de los ejemplos, proporcionará recomendaciones sobre cómo solucionar recomendaciones para introducirse a través. ,,, carta micro

La adopción de la recuperación de la memoria de respaldo

fuga Actividad hace que la referencia de actividad a la de mapa de bits, DrawingCache y así no puede ser liberado, lo que resulta en la presión en la memoria, medios para el reciclaje de revelar todos los detalles han sido fugas Actividad, intente recuperar los recursos que posee, solamente una cáscara Actividad de fugas, de ese modo reducir la presión sobre la memoria.

La práctica también es muy simple, se inicia a partir de la liberación de vista rootview recursiva todas las imágenes de vista del niño que intervienen en la actividad de tiempo onDestory, fondo, DrawingCache, oyentes, etc. recursos para convertirse en una actividad no da cuenta de la cáscara de los recursos, que no se escape recursos de imagen hará que se llevan a cabo.

  Drawable d = iv.getDrawable();
  if (d != null) {
      d.setCallback(null);
  }        
  iv.setImageDrawable(null);

En general, no sólo sabemos cómo se escapa algo de memoria pueden ser soluciones, lo más importante, a través de pruebas de rutina y monitoreo, para conseguir la detección de fugas de memoria y modificación de un conjunto de sistema de circuito cerrado.

Algunos métodos de reducción de la memoria en tiempo de ejecución

Cuando podemos asegurar que la aplicación no aparece en la pérdida de memoria, necesitamos alguna otra manera de reducir la memoria en tiempo de ejecución. Más a menudo, en realidad sólo queremos reducir la probabilidad de ocurrencia de la aplicación OOM.

A. Reducir el mapa de bits de espacio en la memoria

Vea el siguiente capítulo

propio monitor de la memoria II. DE

Para la función del sistema onLowMemory y otras funciones para todo el sistema, que es, para este proceso, la diferencia de su OOM memoria Dalvik no refleja, ni en el tiempo de nuestra función de devolución de llamada a la memoria de liberación.

• supervisar el uso de memoria proceso de pila en tiempo real alcanza el valor establecido de que está a punto de informar a la memoria relevante liberan módulos:

Runtime.getRuntime().maxMemory();  
  Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()；

• Modo de funcionamiento
  de forma periódica (cada 3 minutos en primer plano) para obtener este valor, este valor cuando llegamos a un nivel peligroso (por ejemplo, 80%), que debe ser principalmente para liberar nuestros diversos recursos de caché (mapa de bits para la mayor parte de la memoria caché).

WindowManagerGlobal.getInstance().startTrimMemory(TRIM_MEMORY_COMPLETE)

III. Hay uso sin escrúpulos proceso abierto

Cada proceso de vacío también consume 10 MB.
Para vistas web, biblioteca, etc., porque hay una pérdida de memoria o toma demasiado problema de memoria del sistema, podemos adoptar un proceso separado. La corriente de micro-canales los pondrá en una herramienta de proceso separadas.

IV. OOM detallada de informes

Cuando el sistema OOM accidente ocurre, la información de la memoria. montón grande, inBitmap, SparseArray. . .

optimización GC

prueba de rendimiento GC

Por ejemplo pausa de tiempo de suspensión, tiempo total, GC rendimiento, podemos obtener mediante el envío de una señal de ANR registro SIGQUIT.

adb shell kill -S QUIT PID
adb pull /data/anr/traces.txt

它包含一些 ANR 转储信息以及 GC 的详细性能信息:
sticky concurrent mark sweep paused:	Sum: 5.491ms 99% C.I. 1.464ms-2.133ms Avg: 1.830ms Max: 2.133ms     // GC 暂停时间

Total time spent in GC: 502.251ms     // GC 总耗时
Mean GC size throughput: 92MB/s       // GC 吞吐量
Mean GC object throughput: 1.54702e+06 objects/s 

tipo A. GC

1.GC_FOR_ALLOC
cuando la pila de memoria no es suficiente tiempo sería exigible, especialmente cuando el nuevo objeto. Dalvik.vm.heapstartsize valor puede ser aumentado, por lo que el número de GC_FOR_ALLOC durante el arranque se puede reducir. Tenga en cuenta que este disparador se lleva a cabo de una manera sincronizada.

2.GC_EXPLICIT
el GC se puede invocar, como System.gc, la prioridad de hilo General GC es relativamente baja, por lo que no necesariamente se desencadena inmediatamente el proceso de recogida de basura.

3.GC_CONCURRENT
cuando se activa la distribución del tamaño de objeto cuando más de 384 K, nota que este es un reciclaje de una manera asíncrona. Si encuentra un gran número de repetir aparece concurrente GC, lo que indica que el sistema podría haber sido objeto de más de 384 K se distribuyen, pero estos son a menudo algunos objetos temporales se activan repetidamente. Para darnos consejos son: reutilización de objetos no es suficiente.

(Se gasta 3,0 después del sistema) 4.GC_EXTERNAL_ALLOC

II. Fluctuación de memoria

Poco tiempo un gran número de objetos son creados y puesto en libertad inmediatamente.
Esta operación puede afectar a la velocidad de fotogramas, y para que el usuario percibe los problemas de rendimiento.

Tres. Optimización GC

1. La optimización de la concatenación de cadenas
reduce cadena de signo costura, para usar StringBuilder.
Reducción StringBuilder.enlarge, proporcionado inicialización de la capacidad;

logging.println(">>>>> Dispatching to " + msg.target + " " +
                msg.callback + ": " + msg.what);

2. Leer archivos para optimizar leer archivos ByteArrayPool, la capacidad de ajuste inicial, reducen expandirse.

3. La reutilización de recursos de
grupo de búfer global, para la aplicación frecuente, del tipo de comunicados de reutilización de objetos

4. Reducir objetos innecesarios o no razonables
ejemplo OnDraw, aplicación de destino disminución getView debe tratar de reutilización. Algo más es lógico, por ejemplo, la circulación continua de aplicación de las variables locales, etc.

La selección del formato de datos razonable SparseArray, SparseBooleanArray y LongSparseArray lugar Hashmap

Dé un buen objetivos de optimización:
por ejemplo, para el equipo de más de 512 MB y 2 GB de equipo, son dos ideas completamente diferentes de optimización.
Para el Sudeste de Asia, África, el usuario, y que la optimización de la memoria estándar será más exigentes de algunos.

3 aspectos de la optimización de la memoria

Clasificación del equipo, pérdidas de memoria de mapa de bits y la optimización de estos tres aspectos.

1, aparatos de clasificación

Similar años de clase de dispositivo, máquinas de gama baja cerrados animaciones complejas, o alguna función, el uso de imágenes en el formato 565, una memoria caché más pequeña y así sucesivamente.

if (year >= 2013) {
    // Do advanced animation
} else if (year >= 2010) {
    // Do simple animation
} else {
    // Phone too slow, don't do any animations
}

• gestión de la caché
  caché unificada. Cuando la memoria del sistema es baja, la liberación oportuna de memoria.
• modelo de proceso de
  un proceso de vacío se ocupará de 10 MB de memoria. Aumento de proceso sin escrúpulos.
• tamaño del paquete de instalación
  volumen de código, los recursos, por lo que la biblioteca de imágenes, llevándose con ellos la memoria de una gran relación.

2, mapa de bits Optimización

Análisis Android mapa de bits Evolución:

• sistema 2.x Android, cuando Dalvik asigna + máximo asignado + tamaño externo recién asignado> = Dalvik montón cuando se produce OOM. Cuando el mapa de bits se coloca en el medio externo.
  objeto de mapa de bits en el montón de Java, mientras que los datos de píxel se coloca en la memoria nativa. Si no lo hace de forma manual de invocación de reciclaje, recuperación de la memoria de finalización de mapa de bits nativo totalmente dependiente de la función de devolución de llamada, los estudiantes están familiarizados con Java debe saber que esta oportunidad no es controlable.
  Después BitmapFactory.Options sistema Android 2.x ocultos en el interior de la abertura inNativeAlloc reflexivo, mapa de bits no se contará en la aplicación de lo externo.

• Android 3.0 Android 7.0 ~ unificará objeto de mapa de bits y los datos de píxeles en el montón de Java.
  Así que incluso si no llamamos reciclaje, la memoria de mapa de bits se recuperará junto con el objeto.
  límite de montón de Java no tiene más que 512 MB, tal vez mi memoria física, así como 5GB, pero debido a la falta de aplicación o Java heap plomo memoria para OOM.
  sistemas Android 4.x, la abolición de contador externo, la distribución de mapa de bits similar al cambio de Java Dalvik heap en la solicitud, siempre que la asignación de la nueva memoria asignada +> = Dalvik montón ocurrirá máxima OOM tiempo (el entorno del arte regla y operativo Dalvik estadística o constante)
  se puede utilizar con facebook fresco de recursos de la biblioteca se puede poner en la imagen en nativo.

• androide 8.x se mudaron de montón de Java del montón nativo
  existe una realización, puede poner nativo de mapa de bits en la memoria, también se puede hacer una rápida liberación y objetos entre sí, mientras que GC cuando la memoria puede también ser tomado en cuenta para prevenir el abuso? NativeAllocationRegistry puede una vez que cumple con estos tres requisitos, Android 8.0 es el uso de la ayuda de vuelta a los mecanismos nativos de memoria.
  Android 8.0 también añade mapa de bits de mapa de bits de hardware de hardware, lo que puede reducir la memoria de imagen y mejorar la eficacia del renderizado.

Métodos específicos:

1. Galería Uniforme

por ejemplo: máquinas de bajo nivel utilizan 565 formato. Puede usar Glide, fresco o tomar el auto-desarrollo puede ser. Y la necesidad de promover la Bitmap.createBitmap, interfaz asociada BitmapFactory también se reúnen.

2. Unified Monitoring

En la galería después de la reunificación muy sencilla de supervisar el uso del mapa de bits, hay tres cosas a tener en cuenta aquí.

• monitoreo cuadro grande. Prevenir amplia. los residuos de píxeles
  es decir, tamaño de la imagen no debe exceder el tamaño de la vista. En este sentido, podemos anular estirable con ImageView.
  Desechos pixel de la imagen actual, el uso racional de 0,9 mapa
• Duplica el seguimiento.
  Respuestas: El análisis de mapa de bits duplicado se realiza en el servidor de fondo, que es ahora de hash directamente calcular para toda matriz de mapa de bits de métodos adecuados caballos.
• Fotos de memoria total.
  Cuando accidente OOM, también puede tomar la imagen de la memoria total, la memoria de imágenes Top N se escriben en el registro de bloqueo para ayudar a solucionar el problema.

A imageLoader proceso bueno, 2.X, imagen 4.X 5.X o el usuario puede cargar oculto, pero también puede ser un tamaño de adaptación, la calidad, etc. colocado en el marco.

3, pérdidas de memoria

pérdida de memoria no es simplemente recuperar la memoria no utilizada.

pérdida de memoria se divide en dos tipos:
la misma pérdida de objeto.
Fugas cada vez que un nuevo objeto, se pueden producir cientos de miles de objetos inútiles.

Excelente diseño del marco se puede reducir o evitar incluso los programadores cometer errores. Muchas pérdidas de memoria son causados ​​por el esquema de diseño razonable, una variedad de casos individuales en todas partes, MVC Controlador del ciclo de vida es mucho mayor que Vista.

• pérdidas de memoria Java
  establecen LeakCanary similares automatizado programa de monitoreo.
  Durante el desarrollo, esperamos a la fuga aparece emergente del cuadro de diálogo, lo que permite a los desarrolladores identificar más fácilmente y resolver problemas.
• monitor de OOM
  grupo estadounidense tiene un componente de análisis de enlaces pérdida de memoria Android automatizado de la sonda, que genera instantánea memoria HPROF en el caso de la OOM, a continuación, un análisis más detallado de este documento a través de un proceso separado. Pero utilizar este archivo para su posterior análisis en línea. Sin embargo, el uso de esta herramienta en línea de riesgo es relativamente grande, una instantánea de memoria en el tiempo del accidente puede causar un colapso secundaria, y algunos teléfonos móviles generan hprof instantánea podría tardar varios minutos para experimentar el impacto de esto en los usuarios es relativamente grande.
• pérdida de memoria nativa supervisión de
  un hablé de Malloc depuración (depuración Malloc) y Malloc gancho (Hook Malloc) parecía bastante estable. En WeMobileDev artículo reciente de "práctica optimización de la memoria terminal de micro-letras Android", la carta de micro también hizo algún otro programa por encima de intentos. https://mp.weixin.qq.com/s/KtGfi5th-4YHOZsEmTOsjg?
  No es tan perfecto.

El proceso de desarrollo se puede utilizar para solucionar problemas de pérdidas de memoria y herramientas MAT Androd Profiler utilizados en conjunto con, y un seguimiento diario de la llave en el sistema, por lo que la detección oportuna de problemas.

Memoria supervisar
algunos monitorear el desempeño problema de pérdida de memoria, por lo general sólo se abren para el personal interno y muy pequeña parte del usuario.
En línea: la necesidad de controlar los problemas relacionados con la memoria de otras maneras más eficaces.

modo de adquisición
, de acuerdo con el muestreo del usuario, en lugar de pago por muestra. Los usuarios siguen éxitos de cobro revertido.
Los usuarios de la recepción, se puede capturar cada 5 minutos PSS, almacenamiento dinámico de Java, los cuadros de memoria total.

Calcular el índice

Memoria UV ritmo anormal = PSS más de 400 MB de UV / UV adquiere
valor por el que el PSS puede conseguir obtener el valor Debug.MemoryInfo por el cual el PSS Debug.MemoryInfo.
Toca la tasa máxima: Java puede reflejar el uso de la memoria, si más de 85% del límite máximo del montón, GC se harán más frecuentes, probablemente causa OOM y Caton.

内存 UV 触顶率 = Java 堆占用超过最大堆限制的 85% 的 UV / 采集 UV

long javaMax = runtime.maxMemory();
long javaTotal = runtime.totalMemory();
long javaUsed = javaTotal - runtime.freeMemory();
// Java 内存使用超过最大限制的 85%
float proportion = (float) javaUsed / javaMax;

cliente en general sólo se informaron los datos, todos los cálculos se procesan en el fondo, por lo que se puede hacer flexible.

3.GC monitoreo
en el laboratorio o en un entorno de prueba interna, sino que también puede controlar la asignación situación de memoria de Java y GC por Debug.startAllocCounting, tener en cuenta que esta opción tiene algún impacto en el rendimiento, aunque también se puede utilizar, pero ha sido Android está marcado como obsoletos. Mediante el control de la información, podemos obtener el número y tamaño de asignación de memoria, así como iniciar el número de veces GC.

long allocCount = Debug.getGlobalAllocCount();
long allocSize = Debug.getGlobalAllocSize();
long gcCount = Debug.getGlobalGcInvocationCount();

Después de que el sistema Android 6.0 puede obtener información más precisa acerca de GC.

// 运行的 GC 次数
Debug.getRuntimeStat("art.gc.gc-count");
// GC 使用的总耗时，单位是毫秒
Debug.getRuntimeStat("art.gc.gc-time");
// 阻塞式 GC 的次数
Debug.getRuntimeStat("art.gc.blocking-gc-count");
// 阻塞式 GC 的总耗时
Debug.getRuntimeStat("art.gc.blocking-gc-time");

Hay que prestar especial atención al número de GC bloqueo y consume mucho tiempo, porque va a suspender hebras de la aplicación puede causar la aplicación que se produzca Caton.