Я давно читаю о производительности кода и настройке параметров. На самом деле, программы Android - одна из моих задач.
Давайте сначала познакомимся с основными или наиболее важными концепциями, в которых мы можем найти решение.
Как заявил разработчик Android
модуль может быть независимо собран, протестирован и отлажен
Поэтому модули имеют свои собственные Gradle & Dependencies. И вы можете изучить их в проекте Hierarchy Viewer.
На самом деле, упор на модульность делает упор на техническое обслуживание . В отличие от Performance Matters. Потому что модульность имеет такое важное влияние:
- Увеличение глубины наследования
Вот диаграмма, которую я сделал, чтобы прояснить это. Как вы можете видеть, при использовании дискретного модуля, для вызова метода A проводится 2N micro secsсравнение с использованием N micro secsбез дискретного модуля.
Этот вопрос мне приходит в голову, что Referenced Methods считает то, что связано с глубиной наследования?
Ответ таков: хотя использование модульности увеличивает Referenced Methods.but, но на самом деле это не влияет на производительность приложения, и основной возможной проблемой является глубина наследования, при которой в большинстве случаев игнорируется .
Я подчеркиваю, что увеличение ссылочных методов в модульности связано с каждым модулем Gradle & Dependencies
Каким образом модульность приложения может так сильно увеличить количество ссылочных методов?
Условия, в которых влияют APK анализатор важно ссылки методы
Также обратите внимание, что минификация и сжатие кода могут также значительно изменить содержимое файла DEX после компиляции исходного кода.
В дополнение к приведенному выше официальному заявлению, я хочу добавить еще одно условие, в котором анализатор воздействия APK это:
Насколько опытен разработчик в модульности?
Модульность подобна дому, в котором архитектура (разработчик) определяет, где должна быть кухня, а где должна быть комната отдыха, а где должен быть туалет.
Что если архитектура решит объединить WC и Kitchen? Да, это катастрофа.
Это может произойти во время модульности, если разработчик не очень опытен.
Ответы на вопросы ОП в дополнение к дополнительной информации
Здесь я отвечу на оп заданные вопросы в комментариях
Зачем отдельному Gradle добавлять к количеству ссылочных методов? И для отдельной зависимости, если конечный результат - один APK, то я не думаю, что дублированные зависимости в «app» и модуле функций добавят к количеству ссылочных методов.
Поскольку модули могут быть собраны, протестированы и отлажены, они ДОЛЖНЫ иметь свои собственные Gradle & Dependencies.
Пока выполняется многомодульный проект, компилятор генерирует несколько .dexфайлов, в том числе:
.dexфайл для общих интегрированных зависимостей- модули
.dexs
зависимости .dexФайл представляет собой объединение всех модулей Gradles.
Давайте посмотрим, как модуль Gradle влияет на окончательный счетчик ссылочных Mothods ?!
Есть 2 APK с одинаковым результатом, но разница в счетчиках ссылочных методов.
Они оба являются пустыми действиями, у которых 1.7kразница в количестве ссылок на методы, которая очень высока, зависит от их функциональности. Ключевая разница заключается в том, что на модуле Gradle один из них был настроен на
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
}
Еще один настроен на
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.2.0-alpha01'
implementation 'androidx.constraintlayout:constraintlayout:2.0.0-beta4'
}
Хотя они - просто пустые действия, но минимальная разница в Gradle вызвала 1.7k разницу в счетчиках ссылочных методов.
И приложение Gradle это
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation project(path: ':module')
}
Основная проблема заключается в том, почему добавление индивидуально ссылочного количества методов отличается от общего количества ссылочных методов в Apk Analyzer?
Это просто фильтр IDE больше ничего. наверняка, если вы выберете только .dexфайл, то Reference Reference Counts равен SUM для каждой строки Referenced Method Count, но если вы выбрали несколько.dex файлов, вы увидите разницу в SUM и фактическом Count, что из-за равенства в ссылках, которые предпочитал Analyzer отфильтровать их.
на ваших скриншотах вы выбрали несколько .dex файлов, а затем анализатор равенства фильтров.
В нашем проекте мы используем централизованный файл dependencies.gradle, поэтому нет шансов на другую версию. Итак, как вы думаете, даже если у нас будет одинаковый / точный набор зависимостей и их версий в функциональных модулях, это увеличит количество ссылочных методов?
Теоретически это НЕ должно увеличивать количество ссылочных методов. НО , как я уже объяснил, опыт разработчика сильно влияет на конечный результат.
Team Analyzer должен проверять и исправлять проблемы с производительностью до выпуска, как
- правила защиты
- сокращенные и минимизированные ресурсы
- AndroidManifest.xml
- настройки gradle
Теперь я хочу уточнить, как опыт разработчика и сопровождение кода влияют на конечный результат. ДАЖЕ, если ваш APK использует централизованные зависимости
в приведенном выше примере я увеличил количество 5.1kссылок на методы, даже если бы у меня были централизованные зависимости !!!!!
Как это возможно?
Ответ: я только что добавил бесполезный и скрытый .jarфайл вlibs директорию проекта. так же легко, как вы можете видеть, я повлиял на конечный результат.
Как вы можете видеть опыт разработчика влияет на окончательный result.as результат, практически возможно , что упомянутые методы рассчитывают увеличить Хотя Теоретически РЕКОМЕНДУЕМЫЙ НЕ .
И почему нет разницы в количестве ссылок на методы, когда я компилирую только модуль 'app', отключив параллельную компиляцию? Он должен был уменьшиться, поскольку использовались бы только зависимости модуля «app», верно?
компиляция не имеет никакого отношения к ссылочным методам countts.it соответствует требованиям разработчика.
Вывод
Я рассмотрел все возможности вокруг проблемы. Действительно, это может быть вызвано различными ситуациями, и разработчик, используя это руководство, может решить эту проблему.
- Я надеюсь, что вы узнали, почему ссылочные методы были увеличены и почему в некоторых случаях они могут быть резко увеличены.
- Модули имеют свои модули Gradle & Dependencies и увеличения модульности. следовательно, эти ссылки на метод.
- Модуляризация на самом деле влияет на производительность приложения, но делает обслуживание вашего приложения намного лучше.
- Опыт разработчика в модульности также сильно влияет на конечный результат.
ВАЖНОЕ ПРИМЕЧАНИЕ: почти все утверждения являются моими исследованиями. действительно, могут быть ошибки и сбои, и они будут обновлены, чтобы добавить гораздо больше информации в будущем.
