¿Por qué necesito limpiar Dalche Cache?


46

Cuando actualizo una ROM personalizada, siempre hay una instrucción para borrar el caché Dalvik . No veo una razón por la cual esto es necesariamente.

Al observar el logcat mientras el sistema se inicia, puedo ver claramente que si una aplicación cambia, su dexarchivo se invalida y luego se regenera. Sin embargo, cuando menciono esto en cualquier parte me encuentro con el silencio. Como si ni siquiera algunos desarrolladores de ROM lo supieran y solo lo hacen porque todos los demás lo saben.

Entonces las preguntas:

  • ¿Hubo una versión de Android donde los archivos Dalvik no se invalidaron durante el arranque?
  • ¿Hay alguna ventaja en hacerlo usted mismo, en lugar de dejar que el sistema haga el trabajo que se supone que debe hacer?

Una respuesta ideal incluiría referencias al código relevante, por lo que tendría una referencia la próxima vez que aparezca.

Respuestas:


43

Para responder tu pregunta:

  • No conozco ninguna versión de Android en la que Dalvik no se haya invalidado en el arranque. Tal vez la versión inicial 1.0 tenía eso, realmente no lo sé, ha pasado por Eclair, Froyo, Gingerbread, Ice Cream Sandwich. Debes buscar en el árbol de origen y volverlo a crear en CupCake o Donut (1.5 y 1.6 respectivamente)

  • La razón detallada :)

La razón por la que debe usarse Wipe Cache es porque todas las aplicaciones, incluidas las aplicaciones del sistema, tienen un archivo dex adjunto, cuando la ROM se inicia por primera vez, el Dalvik de Android revisa todas y cada una de esas aplicaciones, y extrae el archivo dex de él y colóquelo en la memoria caché /data/dalvik-cache, acelerando así la ejecución de la aplicación en sí.

La mayoría de las ROM tienen apks que están odex 'ed, el caché está incluido en el apk como un archivo externo.

Una gran cantidad de modders ROM personalizados tendrían esos apks deodex 'd, lo que significa que el archivo dex se reemplaza y se vuelve a empaquetar para facilitar el tema / modificar un apk.

Cuando actualiza una ROM personalizada y no borra la memoria caché, las apk de la ROM personalizada más nueva tendrán un archivo dex diferente adjunto, y cuando Dalvik las revise, verá el archivo dex existente en caché que se encuentra en el directorio, y lo omite, luego, cuando ejecuta la aplicación, se le garantiza un cierre forzado o ANR (la aplicación no responde).

No está perdiendo datos per se, si usa ClockWorkMod Recovery y se selecciona Borrar datos , entonces sí, todas las configuraciones relacionadas con las aplicaciones se borran limpiamente /data/app.

Por lo tanto, puede borrar la memoria caché pero no borrar datos , lo que se hace de manera efectiva se ubica en las nuevas aplicaciones en su lugar, en las que se conserva la configuración. Este era un escenario bastante común con CyanogenMod nightlies donde se destella una construcción ROM inestable / de prueba, y la configuración se retiene con borrado de caché. El kilometraje variará según las aplicaciones descargadas del mercado (es probable que la configuración haya cambiado según la versión).

Para obtener los mejores resultados, sería aconsejable realizar tanto la eliminación de datos como la eliminación de memoria caché para garantizar la integridad y sin errores de programa dentro de la propia aplicación.

Sí, eso significaría que el tiempo de arranque sería más lento, pero es el momento inicial. Después de eso, se iniciaría más rápido. En pocas palabras, limpiar explícitamente el caché en sí a través de CWM realmente ayuda a acelerarlo y a garantizar que no haya residuos de la versión anterior en el lugar que puedan enredarse (ahora en esta etapa, me estoy dando cuenta de su pregunta, así que para ser justos, en realidad no visto que Android no realiza la invalidación de la memoria caché en el arranque al actualizar una nueva ROM ...)

¡Usa la fuente Luke en serio! :RE

frameworks/base/core/java/com/android/internal/os/ZygoteInit.javaes el código de arranque para cada tiempo de ejecución apk. Interactúa con el código C nativo que se encuentra en el dalvikárbol de directorios que contiene instrucciones específicas del conjunto de chips para interpretar el código de bytes dentro del conjunto de instrucciones de la CPU nativa al apk. ARMv6 es más o menos una versión pirateada de ARMv5 (que era el conjunto de chips original en las versiones anteriores de Android anteriores a Eclair), por lo que no verá ARMv6 en la fuente AOSP de google. CyanogenMod tendrá ese ARMv6 en su fuente.


En aras de esta discusión, supongamos que estamos hablando de un lanzamiento oficial de CM7. Permítanme comenzar diciendo que nunca, jamás, limpié mi caché Dalvik y nunca experimenté problemas que se resolverían al hacerlo. Debido a que no está indexado, no hay forma de que haya múltiples archivos (o) dex presentes, y por lo tanto, en el arranque, el archivo antiguo se reemplaza por uno recién generado. Ah, y si es realmente un gran problema, ¿por qué los desarrolladores no agregan esto al script de actualización? Comprobaré la fuente, gracias.
RR

1
En realidad, puede ponerlo explícitamente en el script de actualización, pero eso puede molestar a otros cuando parpadea porque "Oh, mierda, perdí mi configuración / datos" y CM probablemente no quería quemarse por las preguntas / respuestas de la llama como en " ¿Por qué borraste mi caché al actualizar una nueva versión de CM? " - tal vez sea responsabilidad de CM, ¿le dio esa opción al usuario final? Y poniéndolos de nuevo sobre ellos para que, si parpadearan sin borrado, y se quejan en los foros a lá "Hey, mi aplicación se está bloqueando", CM puede darse la vuelta y decir "¿Te borraste?"
t0mm13b

No quise decir data/datapero data\dalvik-cache. Posiblemente solo los del sistema.
RR

1
Las ROM de AOSP de stock están indexadas, CM ha modificado el sistema de compilación para usar desodex ... solo diciendo;)
t0mm13b

2
Gracias por la respuesta detallada t0mm13b. Solo para que quede claro ... Parece que la respuesta simple a la pregunta publicada es "No lo hace. Se borra por defecto en el momento del arranque". ¿Correcto?
GollyJer
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.