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

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

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

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

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

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

Ответы (1)

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

  • Я не знаю ни одной версии Android, в которой Dalvik не становился недействительным при загрузке. Может в начальной версии 1.0 было такое, я правда не знаю, прошли Эклер, Фройо, Имбирный пряник, Мороженое Сэндвич. Вам нужно заглянуть в исходное дерево и перебазировать его обратно в CupCake или Donut (1.5 и 1.6 соответственно).

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

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

У большинства ПЗУ есть apk -файлы, отредактированные odex , кеш встроен в сам apk в виде внешнего файла.

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

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

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

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

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

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

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

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

Ради этого обсуждения давайте предположим, что мы говорим об официальном выпуске CM7. Позвольте мне начать с того, что я никогда, никогда не стирал кеш dalvik и никогда не сталкивался с проблемами, которые можно было бы решить, сделав это. Поскольку он не одексирован, не может быть нескольких файлов (o)dex, и, таким образом, при загрузке старый файл заменяется вновь сгенерированным. О, и если это действительно важно, почему разработчики не добавят это в скрипт обновления? Исходник посмотрю, спасибо.
На самом деле вы можете явно указать это в скрипте обновления, но это может разозлить других при перепрошивке, потому что «О, дерьмо, я потерял свои настройки / данные», и CM, вероятно, не хотел обжечься вопросами / ответами пламени, как в « Зачем ты стер мой кеш при прошивке нового релиза CM?" - может быть, это связано с ответственностью CM, поэтому он предоставил эту возможность конечному пользователю? И поставить на них обратно, чтобы если они прошились без вайпа, и скулить на форумах а-ля "Эй, у меня приложение крашится", СМ мог обернуться и сказать "А ты вайп сделал?"
Я не имел в виду, data/dataно data\dalvik-cache. Возможно только системные.
Стандартные ПЗУ AOSP одексированы, CM модифицировал систему сборки для использования деодексации .... просто говорю;)
Последний последний комментарий: некоторые моддеры ПЗУ либо основывали бы свой код на AOSP vanilla, CAF или CM, поэтому, если вы, например, должны были перейти от CM к CAF, то явно очистите данные/кэш из-за различий, также то же самое для перехода от АОСП до СМ. Здесь вступает в игру здравый смысл. Но вы, похоже, сосредоточены исключительно на CM, переходя от одной ночной версии к другой или от стабильной к следующей стабильной, тогда да, никаких незначительных различий там, кроме ключей подписи ПЗУ и т. д. Аналогично, если вы используете GB CM72 и переходите к ICS CM9, тогда да благоразумно было бы сделать так же!
Я сосредоточен только на CM, потому что я посещаю только темы CM на форумах, поэтому я вижу только то, что они говорят. Для переключения между ветками мэра я могу понять необходимость вайпа (может различия в ВМ?) или между версией ОС (2.3 на 4.0), но я никогда не делаю этого ни для чего другого, и мой телефон работает нормально. Таким образом, похоже, что в исходном случае (обновление до версии never rom) на самом деле просто иметь что-то в качестве страховки, если пользователи будут жаловаться.
Примечание: это бессмысленное действие, потому что так делают все остальные, очень распространено среди ром-шефов modaco (парней, которые работают с winzip)
Спасибо за подробный ответ t0mm13b. Просто, чтобы я ясно... Кажется, простой ответ на опубликованный вопрос: «Вы этого не сделаете. Он стирается по умолчанию во время загрузки». Правильный?
Этот ответ все еще актуален для Android 7 или выше? Потому что кажется, что кэши dalvik не генерируются при перезагрузке после их удаления. что происходит?
Зачем мне стирать Dalvik Cache?
СпросиСетьПолитика конфиденциальности1y, 3v