Зачем мне стирать Dalvik Cache?

Когда я обновляю пользовательское ПЗУ, всегда есть инструкция, чтобы стереть кеш Dalvik . Я не вижу причины, почему это обязательно.

Наблюдая за logcat во время загрузки системы, я ясно вижу, что если приложение изменилось, его dexфайл становится недействительным, а затем регенерируется. И все же, когда я упоминаю об этом где-либо, меня встречает тишина. Как будто даже некоторые разработчики ПЗУ не знают об этом, и они делают это только потому, что все остальные.

Итак, вопросы:

• Была ли версия для Android, где файлы Dalvik не были признаны недействительными во время загрузки?
• Есть ли какое-то преимущество в том, чтобы делать это самостоятельно, вместо того, чтобы позволить системе выполнять работу, которую она должна делать?

Идеальный ответ будет включать ссылки на соответствующий код, поэтому я буду иметь ссылку в следующий раз, когда это произойдет.

Чтобы ответить на ваши вопросы:

• Не знаю ни одной версии Android, где Dalvik не был аннулирован при загрузке. Возможно, первоначальная версия 1.0 имела, я действительно не знаю, что она прошла через Eclair, Froyo, Gingerbread, Ice Cream Sandwich. Вам нужно заглянуть в дерево исходников и вернуть его обратно в CupCake или Donut (1.5 и 1.6 соответственно)

• Подробная причина :)

Причина, по которой Wipe Cache необходимо использовать, заключается в том, что все apks, включая системные apks, имеют прикрепленный к нему файл dex , когда ПЗУ загружается впервые, Android Dalvik просматривает каждый из этих apks и извлекает файл dex из него и поместите его в кеш, /data/dalvik-cacheтем самым ускоряя выполнение самого приложения.

Большинство ПЗУ имеют apk, которые являются odex 'ed, кеш встроен в сам apk как внешний файл.

Многие пользовательские моддеры ПЗУ имеют такие apks deodex 'd, что означает, что файл dex заменяется и переупаковывается, чтобы упростить создание темы / изменение apk.

Когда вы прошиваете пользовательское ПЗУ и не стираете кеш, к новому файлу apk нового пользовательского ПЗУ будет прикреплен другой файл dex , а когда Dalvik просматривает их, он видит существующий кэшированный файл dex, найденный в каталоге, и пропускает его, затем при запуске приложения гарантируется принудительное закрытие или ANR (приложение не отвечает).

Вы не теряете данные как таковые, если вы используете ClockWorkMod Recovery и выбрано « Очистить данные» , тогда да, все настройки, относящиеся к приложениям, стираются корректно - смотрите /data/app.

Таким образом, вы можете стереть кэш, но не стереть данные. То, что сделано эффективно, размещено в новых апках на месте, в которых сохранены настройки. Это было довольно распространенным сценарием для ночных вечеринок CyanogenMod, когда происходит сборка нестабильного / тестируемого ПЗУ, а настройки сохраняются с очисткой кэша. Пробег будет варьироваться в зависимости от того, какие приложения загружены с маркета (настройки могут измениться в зависимости от версии, вполне вероятно).

Для достижения наилучших результатов было бы целесообразно выполнить как Wipe Data, так и Wipe Cache для обеспечения целостности и отсутствия программных ошибок внутри самого приложения.

Да, это будет означать, что время загрузки будет медленнее, чем начальное время отключения. После этого загрузка будет быстрее. Короче говоря, явное стирание самого кэша с помощью CWM на самом деле помогает ускорить его и гарантировать отсутствие остатков от предыдущей версии на месте, которые могут быть повреждены (сейчас на этом этапе я понимаю ваш вопрос, так что, честно говоря, на самом деле не видел, что Android не выполняет аннулирование самого кэша при загрузке при перепрошивке нового ROM ..)

Используйте источник Люк серьезно! : D

frameworks/base/core/java/com/android/internal/os/ZygoteInit.javaэто код загрузки для каждой среды выполнения apk. Он взаимодействует с собственным кодом C, найденным в dalvikдереве каталогов, которое содержит специальные инструкции набора микросхем для интерпретации байт-кода в наборе команд apk для собственного процессора. ARMv6 является в значительной степени взломанной версией ARMv5 (которая была исходным чипсетом в более старых версиях Android до Eclair), поэтому вы не увидите ARMv6 в источнике AOSP от Google. CyanogenMod будет иметь этот ARMv6 в своем источнике.