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

46

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

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

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

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

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

RR
источник

Ответы:

43

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

  • Не знаю ни одной версии 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 в своем источнике.

t0mm13b
источник
Ради этого обсуждения давайте предположим, что мы говорим об официальном релизе CM7. Позвольте мне начать с того, что я никогда не стирал кеш dalvik и никогда не сталкивался с проблемами, которые можно было бы решить при этом. Поскольку это не odexed, нет никакого способа, чтобы могло быть несколько (o) файлов dex, и, таким образом, при загрузке старый файл заменяется вновь сгенерированным. О, и если это действительно большое дело, почему разработчики не добавляют это в скрипт обновления? Я проверю источник, спасибо.
RR
1
На самом деле вы можете явно указать это в скрипте обновлений, но это может раздражать других при перепрошивке, потому что «О, чёрт, я потерял свои настройки / данные», а СМ, ​​вероятно, не хотел обжечься пламенными вопросами / ответами, как в » Почему вы стерли мой кеш при перепрошивке новой версии CM? " - Может быть, это ответственность CM, так что дал эту возможность конечному пользователю? И положить его обратно на них, чтобы, если они мигали без вайпов, и скулить на форумах: «Эй, мое приложение не работает», КМ может повернуться и сказать: «Вы стерли?»
t0mm13b
Я не имел в виду, data/dataно data\dalvik-cache. Возможно, только системные.
RR
1
Стандартные AOSP-ROM'ы odexed, CM модифицировали систему сборки для использования deodex .... просто говорю;)
t0mm13b
2
Спасибо за подробный ответ t0mm13b. Просто, чтобы было ясно ... Кажется, простой ответ на вопрос: «Вы этого не делаете. По умолчанию он стирается во время загрузки». Верный?
GollyJer