Я довго читав про продуктивність коду та налаштування параметрів. В іншому, програми Android є одним із моїх фокусів.
Давайте спочатку введемо основні чи найважливіші поняття, в яких допомагають нам досягти рішення.
Як заявив розробник Android
Модуль може бути самостійно побудований, протестований та налагоджений
Тому модулі мають власні Gradle & Dependpendations. Ви можете вивчити це в проекті Hierarchy Viewer.
Власне, модуляризація акцентується на питаннях технічного обслуговування . На відміну від питань продуктивності. Тому модуляризація має такий важливий вплив:
- Збільшити глибину спадкування
Ось схема, яку я склав, щоб зробити це зрозумілим. Як ви бачите. Тим часом, використовуючи дискретний модуль, для виклику методу А 2N micro secsпорівнюють його N micro secsбез дискретного модуля.
Це питання мені прийшло в голову, що посилані методи розраховують, що стосується глибини спадкування?
Відповідь: Хоча використання модуляризації збільшує посилані Methods.but, це насправді не впливає на продуктивність програми, і головна можлива проблема - глибина спадкування, в якій у більшості випадків нехтують .
Я наголошую, що посилення посилальних методів на модуляризацію обумовлено кожним модулем Gradle & залежностей
Як модуляризація додатків може збільшити кількість посилань на метод настільки високо?
Умови, в яких впливає на аналізатор APK важливо посилаються методи
Також зауважте, що мінімізація та скорочення коду можуть також суттєво змінити вміст файлу DEX після того, як компілюється вихідний код.
На додаток до вищеописаного офіційного твердження, я хочу додати ще одну умову, в якій впливає аналізатор APK, це:
наскільки досвідчений розробник має модуляризацію?
модуляція - це як будинок, який архітектура (розробник) визначає, де повинна бути кухня, а де повинна бути кімната відпочинку, а де - туалет.
Що робити, якщо архітектура вирішить поєднати туалет і кухню? Так це лихо.
Це може статися під час модуляризації, якщо розробник не має великого досвіду.
Відповідь на питання ОП у додатку до додаткової інформації
Ось я відповідаю на опитувані запитання в коментарях
Чому б окремий Gradle додав до числа посилається метод? А для окремої залежності, якщо кінцевий результат є єдиним APK, то я не думаю, що дублюючі залежності в "застосунку" та модулі функцій не додадуть до кількості посилань методу.
Оскільки модулі можуть бути побудовані, протестовані та налагоджені, вони ОБОВ'ЯЗКОВО мати свої Gradle & Dependpendes.
Поки виконується багатомодульний проект, компілятор генерує кілька .dexфайлів, включаючи:
.dexфайл для загальних інтегрованих залежностей- модулі
.dexs
.dexФайл залежності - це інтеграція всіх модулів градулів
Давайте подивимось, як модуль 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 різницю в підрахунку методів.
І App 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файл Кількість довідкових методів дорівнює SUM кожного рядка Коефіцієнт посилань, але якщо ви вибрали кілька разів.dex файлів, ви побачите різницю в SUM і фактичному що через рівність у посиланнях, які аналізатор вважав за краще фільтруйте їх.
на своїх знімках екрана ви вибрали кілька .dexфайлів, а потім рівність фільтру Analyzer.
у нашому проекті ми використовуємо централізований файл залежностей.gradle, щоб не було шансів на іншу версію. Отже, ви думаєте, навіть якщо ми маємо однаковий / точний набір залежностей та їх версій у функціональних модулях, це збільшить кількість посилальних методів?
Теоретично НЕ повинно збільшувати кількість посилальних методів. Але , як я пояснив це, досвід розробників сильно впливає на кінцевий результат.
Командний аналізатор повинен перевірити та виправити проблеми з роботою перед тим, як випустити
- правила прогуарда
- скорочуються та мінімізуються ресурси
- androidManifest.xml
- налаштування gradle
Тепер я хочу уточнити, як досвід розробника та підтримка коду впливає на кінцевий результат. ЦІЛЬКО, якщо ваш APK використовує централізовані залежності
у вищенаведеному прикладі я збільшувався 5.1kв підрахунку посилань на методики, навіть якщо я мав централізовані залежності !!!!!
Як це можливо?
Відповідь: я просто додав марний і прихований .jarфайл у libsкаталог проекту. так само просто, як ви можете бачити, що я вплинув на кінцевий результат.
Як ви можете бачити, що досвід розробників впливає на кінцевий результат. Як результат, практично можливо, що кількість посилань на цей метод може бути збільшена, хоча теоретично НЕ слід .
І чому немає різниці в кількості посилань методу, коли я компілюю лише модуль "app", відключаючи паралельну компіляцію? Це мало б зменшитися, оскільки використовувались б лише залежності "модуля" програми, правда?
компіляція не має жодного відношення до посиланих методів counts.it відповідає тому, що розробник хоче виконати.
Висновок
Я висвітлив усі можливості навколо цього питання. Дійсно, це може виникнути з різних ситуацій, і розробник за допомогою цього керівництва може виправити проблему.
- Я сподіваюся, що ви дізналися, чому посилані методи були розширені і чому в деяких випадках вона може бути різко зросла.
- Модулі мають свої Gradle & Dependpendations та модулі збільшення модуляризації. отже, ці Методичні посилання.
- Модуляризація фактично впливає на ефективність програми, але вона робить обслуговування Вашого додатка значно кращим.
- Досвід розробників з модуляризації також сильно впливає на кінцевий результат.
ВАЖЛИВО ПРИМІТКА: майже всі заяви є моїми дослідженнями та дослідженнями. Дійсно, можуть бути помилки та помилки, і вони будуть оновлюватися, щоб додати набагато більше інформації в майбутньому.
