XML-ориентированные графические интерфейсы и производительность

Читая страницу Online Developer Guide на макетах XML , я нашел следующее заявление:

Ваши описания пользовательского интерфейса являются внешними по отношению к вашему коду приложения, что означает, что вы можете изменять или адаптировать его, не изменяя исходный код и не перекомпилируйте.

Я знаю много преимуществ XML-макетов и ресурсов, но поскольку XML-файлы размещены внутри APK, я думаю, что нет реального способа изменить GUI без переупаковки. Я имею в виду, что большинство из нас использует плагин eclipse ADT и ANT для упаковки приложений, поэтому нет никакой реальной выгоды в том, чтобы не компилировать файлы классов (так как после изменения файлов ресурсов разработчику придется переупаковать приложение и создать новый APK файл). Из-за этого невозможно перераспределить GUI на устройствах без повторного развертывания всего APK.

Если это предположение было истинным, тогда файлы XML будут одинаковыми в течение всего жизненного цикла файла APK. Я предполагаю, что эти файлы (особенно макеты) должны быть проанализированы и обработаны во время выполнения (до действия onCreate), что было бы менее эффективно, чем создание графического интерфейса программно (например, в Swing). Макет обычно не является узким местом, но если я прав, я вижу здесь небольшую трату времени, которую можно было бы лучше использовать (например, с анимацией).

При чтении одной и той же страницы говорится:

Когда вы компилируете свое приложение, каждый файл макета XML скомпилируется в ресурс View.

Осмотрев один из моих APK, я искал предварительно скомпилированный файл внутри classes.dex и нет ничего, кроме моих классов java и файла R.class . XML-файлы макета находятся внутри /res/layout folder , и есть файл с именем resources.arsc который, как представляется, содержит информацию о других ресурсах (строки, имена значков), но ничего не связано с Views, я думаю (исправьте меня, Неверно).

Мои вопросы:

  • Являются ли файлы компоновки XML предварительно скомпилированы и к какому файлу?
  • Если нет, есть ли возможность компиляции полностью прекомпилировать информацию о макете в файл для более быстрого времени загрузки? (В идеале это будет файл класса)
  • Если нет, есть ли способ создать этот файл в первом исполнении и кэшировать его в папке установки приложения, чтобы последующие исполнения во время выполнения могли читать этот файл вместо разбора XML и иметь более быстрое время загрузки?

Заранее спасибо.

Solutions Collecting From Web of "XML-ориентированные графические интерфейсы и производительность"

Если у вас есть gander в документации класса LayoutInflater , вы заметите, что они говорят:

По соображениям производительности просмотр инфляции в значительной степени зависит от предварительной обработки файлов XML, которая выполняется во время сборки. Поэтому в настоящее время невозможно использовать LayoutInflater с XmlPullParser над простым XML-файлом во время выполнения; Он работает только с XmlPullParser возвращенным из скомпилированного ресурса ( R.something file ).

Так что да, файлы макетов действительно предварительно скомпилированы до некоторой степени, И, судя по приведенной выше выдержке, он будет в выходном файле R$layout.class (но я не уверен на это на 100%). Предварительно скомпилированный файл макета находится в вашем скомпилированном пакете APK, как /res/layout/<layout_id>.xml . Вы заметите, что извлеките его и откройте в текстовом редакторе, чтобы большинство XML-элементов простого текста были сопоставлены с некоторой двоичной формой.

Вероятно, это будет тот же самый вид сжатия, который вы можете увидеть в файлах AndroidManifest.xml которые упаковываются в APK.