Количество ссылочных методов увеличилось после модуляции приложения

AS: 3,5,3; Плагин Android Gradle: 3.5.0; Gradle: 5.6.2;

Мы наблюдали резкое увеличение числа методов, на которые ссылается наше приложение, после разделения модуля app на несколько небольших модулей. Но странно то, что добавление ссылочных методов каждым классом меньше, чем упомянутое общее количество в Android Apk Analyzer Tool.

В целях тестирования я переместил WebActivity.class из модуля «приложение» в модуль «адаптеры», и число ссылок на методы увеличилось на 181 метод.

Обобщить:

app / WebActivity = 63546 Фактические методы, на которые ссылаются, но показывающие 65394 метода. adapter / WebActivity = 63543 фактические методы, на которые имеются ссылки, но показывающие 65575 методов.

Мы наблюдали, как количество добавленных методов увеличилось почти на 10 тыс. После добавления / разделения 4 новых модулей.

Какова точная проблема?

Каким образом модульность приложения может так сильно увеличить количество ссылочных методов?

Ниже приведены скриншоты, которые я сделал для двух разных различий в APK-файлах: WebActivity перемещена из модуля «приложение» в модуль «адаптер» и увеличено 181 упоминание методов:

WebActivity в модуле «приложение»

Перенес WebActivity в модуль «адаптер»

На скриншотах, почему добавление ссылочных методов каждым классом (отмечено красным цветом) не равно общему количеству, указанному в Apk Analyzer?

Я давно читаю о производительности кода и настройке параметров. На самом деле, программы 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 и увеличения модульности. следовательно, эти ссылки на метод.
• Модуляризация на самом деле влияет на производительность приложения, но делает обслуживание вашего приложения намного лучше.
• Опыт разработчика в модульности также сильно влияет на конечный результат.

ВАЖНОЕ ПРИМЕЧАНИЕ: почти все утверждения являются моими исследованиями. действительно, могут быть ошибки и сбои, и они будут обновлены, чтобы добавить гораздо больше информации в будущем.

Отвечая на мой собственный вопрос, как решение просто щелкнуло в моей голове, хотя это не пробовал, но будет работать, определенно или наиболее вероятно. :) Ответ, данный Mr.AF был очень полезен для достижения окончательного решения. Это говорит о том, почему? но не как этого избежать или как улучшить это.

Вот способ вернуть счетчик исходных / фактических ссылок на метод -

Это зависит не от того, как мы модулируем приложение, а от того, как мы добавляем зависимости. Если мы добавим зависимость, используя « реализацию », то эта зависимость останется закрытой для модуля, и никакой другой модуль не сможет ее использовать. И если мы добавим ту же зависимость, используя ' api ' (равнозначен устаревшей 'compile'), она станет общедоступной, и другие зависимые модули смогут ее использовать. Поскольку мы используем «реализацию» для добавления зависимостей в каждый модуль в многомодульном проекте, каждый модуль имеет все необходимые зависимости как автономные, поэтому его можно скомпилировать по отдельности. Это приводит к уменьшению времени сборки / компиляции, поскольку могут быть скомпилированы только измененные модули. Но использование так 'реализации' увеличивает количество ссылочных методовтак как есть много повторяющихся методов.

Таким образом, если время сборки не является вашим вопросом, а количество методов, на которые ссылаются, то вы можете нарисовать дерево зависимостей всех модулей и избежать добавления дублирующихся зависимостей, используя 'api' в базовом модуле. Таким образом, даже верхний модуль может использовать зависимости, добавленные базовым модулем, что позволит избежать дублирования. Помните, это увеличит время сборки.

Мы можем достичь и того, и другого, если сможем различать зависимости для отладки и сборки выпуска . Добавьте все зависимости, используя «реализацию» для отладочной сборки, и добавьте только обязательные и оптимизированные зависимости для сборки выпуска с помощью «api» . Таким образом, отладочная сборка будет быстрее, а сборка выпуска будет медленнее, что доступно.

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

Я вижу всю разницу в вашем 'ком' пакете. Вы можете расширить и сравнить, какие именно классы были сокращены. Если вы используете последнюю версию R8, она может удалить некоторый код по умолчанию. Когда вы помещаете некоторые классы в модуль сжатия, не знаете, могут ли публичные классы / методы быть удалены или должны оставаться для использования в другом модуле.