إنشاء ملف شخصي

قد تختلف المشروعات الأكبر، أو تلك التي تنفّذ الكثير من منطق الإنشاء المخصص يتطلب منك التدقيق في عملية الإنشاء للعثور على المؤثِّرات السلبية. يمكنك القيام بذلك من خلال تحليل المدة التي تستغرقها Gradle لتنفيذ كل مرحلة من مراحل دورة حياة التصميم وكل مهمة تصميم. على سبيل المثال، إذا كان ملف الإصدار الشخصي أن Gradle يقضي الكثير من الوقت في تهيئة مشروعك، فقد تقترح أنك بحاجة إلى نقل منطق الإصدار المخصّص خارج مرحلة الضبط: بالإضافة إلى ذلك، إذا تستهلك المَهمة mergeDevDebugResources مقدارًا كبيرًا من وقت الإصدار، فقد يشير إلى أنك بحاجة إلى إما تحويل صورك إلى تنسيق WebP أو أوقِف معالجة ملفات PNG.

إذا كنت تستخدم يُعدّ Android Studio 4.0 أو الإصدارات الأحدث أفضل طريقة للتحقق من أداء الإصدار وهي استخدام أداة تحليل الإصدار.

بالإضافة إلى ذلك، هناك خياران لإنشاء ملف تعريفي خارج استوديو Android:

  1. أداة gradle-profiler المستقلة، أداة قوية لإجراء تحليل معمّق لتصميمك.

  2. يتوفّر خيار --profile لنظام Gradle. أداة ملائمة متاحة من سطر أوامر Gradle.

استخدام أداة gradle-profiler المستقلة

من أجل العثور على إعداد المشروع الذي يوفر لك أفضل سرعة إنشاء، عليك استخدام أداة تحليل Gradle، أداة لجمع معلومات التحليل وقياس الأداء لإصدارات Gradle. يتيح لك محلّل Gradle إنشاء سيناريوهات إنشاء وتنفيذها الأوقات، مما يمنع التباين الكبير بين النتائج ويضمن إمكانية التكرر النتائج.

وضع قياس الأداء وينبغي استخدامه لجمع معلومات حول عمليات الإنشاء النظيفة والتزايدية، أثناء وضع تحليل البيانات لجمع معلومات أكثر دقة عن عمليات التشغيل، بما في ذلك وحدة المعالجة المركزية (CPU) لقطات.

تتضمن بعض تهيئات إعداد المشروع لقياس الأداء ما يلي:

  • إصدارات المكونات الإضافية
  • إصدارات Gradle
  • إعدادات JVM (حجم الذاكرة وحجم الاحتفاظ بالبيانات وجمع البيانات غير المرغوب فيها وما إلى ذلك)
  • عدد العاملين في Gradle (org.gradle.workers.max)
  • خيارات لكل مكوّن إضافي لتحسين الأداء بشكل أكبر

الخطوات الأولى

  • تثبيت Gradle-profiler من خلال اتّباع هذه التعليمات
  • تشغيل: gradle-profiler --benchmark --project-dir <root-project> :app:assembleDebug

سيؤدي ذلك إلى قياس أداء إصدار حديث تمامًا لأنّ --benchmark يشغِّل المهمة عدة مرات دون تغيير المشروع بينهما. بعد ذلك، ستفتح إنشاء تقرير HTML ضمن دليل profile-out/ يعرض لك وأوقات التصميم.

هناك سيناريوهات أخرى قد تكون أكثر فائدة لقياس الأداء:

  • تغير الرمز في نص طريقة في إحدى الفئات التي تقوم فيها بمعظم عملك.
  • تغييرات واجهة برمجة التطبيقات في وحدة يتم استخدامها طوال مشروعك بينما أقل بشكل متكرر من التغييرات على التعليمات البرمجية الخاصة بك، فإن هذا يكون له تأثير أكبر مفيدة لقياسها.
  • تعديلات التصميم لمحاكاة التكرار على عمل واجهة المستخدم.
  • سلسلة تعديلات لمحاكاة التعامل مع أعمال الترجمة.
  • الإصدارات النظيفة لمحاكاة التغييرات التي تم إجراؤها على الإصدار نفسه (على سبيل المثال، نظام Gradle المتوافق مع Android أو تحديث المكوّن الإضافي أو تحديث Gradle أو إجراء تعديلات على رمز التصميم أقل من buildSrc).

من أجل قياس حالات الاستخدام هذه، يمكنك إنشاء سيناريو التي تُستخدم لتنفيذ gradle-profiler وتسري بشكل مناسب التغييرات على مصادرك. يمكنك مراجعة بعض السيناريوهات الشائعة أدناه.

تحليل إعدادات مختلفة للذاكرة/وحدة المعالجة المركزية (CPU)

لقياس إعدادات مختلفة للذاكرة ووحدة المعالجة المركزية، يمكنك إنشاء سيناريوهات متعددة تستخدم قيمًا مختلفة لـ org.gradle.jvmargs. بالنسبة على سبيل المثال، يمكنك إنشاء سيناريوهات:

# <root-project>/scenarios.txt
clean_build_2gb_4workers {
    tasks = [":app:assembleDebug"]
    gradle-args = ["--max-workers=4"]
    jvm-args = ["-Xmx2048m"]
    cleanup-tasks = ["clean"]
}
clean_build_parallelGC {
    tasks = [":app:assembleDebug"]
    jvm-args = ["-XX:+UseParallelGC"]
    cleanup-tasks = ["clean"]
}

clean_build_G1GC_4gb {
    tasks = [":app:assembleDebug"]
    jvm-args = ["-Xmx4096m", "-XX:+UseG1GC"]
    cleanup-tasks = ["clean"]
}

يجري تنفيذ العملية gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt. ثلاثة سيناريوهات، وسوف تتمكن من مقارنة المدة يستغرق :app:assembleDebug لكل إعداد من هذه الإعدادات.

تحليل إصدارات المكوّن الإضافي المختلفة لنظام Gradle

لمعرفة كيف يؤثر تغيير إصدار مكوّن Gradle الإضافي إنشاء سيناريو، وإنشاء سيناريو لقياس ذلك. يتطلب هذا بعض التحضير لجعل إصدار المكون الإضافي قابلاً لإدخاله من السيناريو. تغيير الجذر Build.gradle:

# <root-project>/build.gradle
buildscript {
    def agpVersion = providers.systemProperty("agpVersion").forUseAtConfigurationTime().orNull ?: '4.1.0'

    ext.kotlin = providers.systemProperty('kotlinVersion').forUseAtConfigurationTime().orNull ?: '1.4.0'

    dependencies {
        classpath "com.android.tools.build:gradle:$agpVersion"
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin"
    }
}

يمكنك الآن تحديد المكوّن الإضافي لنظام Gradle المتوافق مع Android والمكوّن الإضافي Kotlin Gradle من ملف السيناريوهات، وإضافة السيناريو بطريقة جديدة إلى ملفات المصدر:

# <root-project>/scenarios.txt
non_abi_change_agp4.1.0_kotlin1.4.10 {
    tasks = [":app:assembleDebug"]
    apply-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    System-properties {
      "agpVersion" = "4.1.0"
      "kotlinVersion" = "1.4.10"
}

non_abi_change_agp4.2.0_kotlin1.4.20 {
    tasks = [":app:assembleDebug"]
    apply-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    System-properties {
      "agpVersion" = "4.2.0-alpha16"
      "kotlinVersion" = "1.4.20"
}

إنشاء ملف تعريفي للإصدار التزايدي

معظم الإصدارات تدريجية، ما يجعلها واحدة من أهم السيناريوهات المختلفة. يتمتع محلل Gradle بدعم مكثف تحديد ملامح البناء التزايدي. قادر على تطبيق التغييرات على ملف مصدر تلقائيًا من خلال تغيير نص الطريقة أو إضافة طريقة جديدة أو تغيير تنسيق أو مورد سلسلة. بالنسبة مثلاً، يمكنك إنشاء سيناريوهات متزايدة مثل:

# <root-project>/scenarios.txt
non_abi_change {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to = ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
}

abi_change {
    tasks = [":app:assembleDebug"]
    apply-abi-change-to = ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
}

layout_change {
    tasks = [":app:assembleDebug"]
    apply-android-layout-change-to = "app/src/main/res/your_layout_file.xml"
}
string_resource_change {
    tasks = [":app:assembleDebug"]
    apply-android-resource-value-change-to = "app/src/main/res/values/strings.xml"
}

يجري تنفيذ العملية gradle-profiler --benchmark --project-dir &lt;root-project> --scenario-file scenarios.txt. سيتم إنشاء تقرير HTML الذي يضم بيانات قياس الأداء.

ويمكنك دمج سيناريوهات التزايد مع إعدادات أخرى، مثل حجم الذاكرة أو عدد العاملين، أو إصدار Gradle:

# <root-project>/scenarios.txt
non_abi_change_4g {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    jvm-args = ["-Xmx4096m"]
}

non_abi_change_4g_8workers {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    jvm-args = ["-Xmx4096m"]
    gradle-args = ["--max-workers=8"]
}

non_abi_change_3g_gradle67 {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    jvm-args = ["-Xmx3072m"]
    version = ["6.7"]
}

إنشاء ملف تعريفي لبنية نظيفة

من أجل قياس أداء إصدار نظيف، يمكنك إنشاء سيناريو تُستخدم لدفع تنفيذ ملف Gradle-profiler:

# <root-project>/scenarios.txt
clean_build {
    tasks = [":app:assembleDebug"]
    cleanup-tasks = ["clean"]
}

لتشغيل هذا السيناريو، استخدِم الأمر التالي:

gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt

استخدام خيار Gradle --profile

لإنشاء ملف تعريف تصميم وعرضه من سطر أوامر Gradle، نفذ الخطوات التالية:

  1. افتح نافذة سطر أوامر في جذر المشروع.
  2. عليك إجراء إنشاء نظيف من خلال إدخال الأمر التالي. أثناء الملف الشخصي بنائك، فيجب عليك تنفيذ إنشاء نظيف بين كل إصدار ملف تعريف لأنّ Gradle تتخطى المهام عندما لا يكون المدخلات إلى مهمة (مثل رمز المصدر) التغيير. وبالتالي، دائمًا ما يعمل الإصدار الثاني بدون أي تغييرات في المدخلات بشكل أسرع لأن لا تتم إعادة تشغيل المهام. لذا، فإن تنفيذ مهمة clean بين تصاميمك تضمن لك لمحة عن عملية الإنشاء بالكامل. 
    // On Mac or Linux, run the Gradle wrapper using "./gradlew".
gradlew clean
  3. تنفيذ إنشاء تصحيح أخطاء لإحدى نكهات منتجاتك، مثل سمة "dev" النكهة مع العلامات التالية: 
    gradlew --profile --offline --rerun-tasks assembleFlavorDebug
    • --profile: تفعِّل عملية إنشاء الملفات التعريفية.
    • --offline: يمنع Gradle من الجلب على الإنترنت والتبعيات لديك. وهذا يضمن أنها تضمن عدم حدوث أي تأخيرات بسبب Gradle أن محاولة تحديث تبعياتك لا تتداخل مع بيانات تحديد المواصفات. يُفترض أن تكون قد أنشأت بالفعل مشروعك مرة واحدة لجعل التأكد من تنزيل Gradle بالفعل وتخزين التبعيات المخزنة مؤقتًا.
    • --rerun-tasks: فرض إعادة تشغيل جميع المهام وتجاهلها في Gradle أي تحسينات للمهام.

  4. الشكل 1. عرض مشروع يشير إلى موقع تقارير ملفك الشخصي.

    بعد اكتمال عملية الإنشاء، استخدِم نافذة المشروع للانتقال إلى الدليل project-root/build/reports/profile/ (بتنسيق كما هو موضح في الشكل 1).

  5. انقر بزر الماوس الأيمن على الملف profile-timestamp.html واختَره. فتح في المتصفح > الخيار التلقائي: يجب أن يبدو التقرير مشابهًا للتقرير كما هو موضح في الشكل 2. يمكنك فحص كل علامة تبويب في التقرير لمعرفة المزيد مثل علامة التبويب تنفيذ المهام التي توضح المدة التي استغرقها Gradle لتنفيذ كل مهمة إنشاء.

    الشكل 2. عرض تقرير في متصفّح

  6. اختياري: قبل إجراء أي تغييرات على مشروعك أو إنشاء التهيئة، فكرر الأمر في الخطوة 3، ولكن احذف علم --rerun-tasks نظرًا لأن Gradle تحاول توفير الوقت من خلال إعادة تنفيذ المهام التي لم تتغير إدخالاتها (تتم الإشارة إلى هذه UP-TO-DATE في علامة التبويب تنفيذ المهمّة في التقرير، كما هو موضّح. في الشكل 3)، يمكنك تحديد المهام التي تؤدي عملاً عندما لا ينبغي أن يكون. على سبيل المثال، إذا كانت قيمة لم يتم وضع علامة على ":app:processDevUniversalDebugManifest" بأنّه UP-TO-DATE، قد يشير ذلك إلى أنّ إعدادات تصميمك هي تعديل البيان ديناميكيًا مع كل إصدار ومع ذلك، تحتاج بعض المهام إلى سيتم تنفيذها أثناء كل عملية إنشاء، مثل :app:checkDevDebugManifest.

    الشكل 3. جارٍ عرض نتائج تنفيذ المهام

والآن بعد أن أصبح لديك تقرير إنشاء ملف شخصي، يمكنك البدء في البحث عن فرص التحسين عن طريق فحص المعلومات في كل علامة تبويب إبلاغ. يجب تجربة بعض إعدادات الإصدار لأنّ مزاياها قد بين المشروعات ومحطات العمل. على سبيل المثال، قد تتضمن المشروعات ذات قاعدة الرموز البرمجية قد تستفيد من تقليص الرموز لإزالة الرموز غير المستخدَمة وتقليص حجم التطبيق ومع ذلك، فقد تستفيد المشروعات أكثر من تعطيل تقليص التعليمات البرمجية تمامًا. بالإضافة إلى ذلك، زيادة حجم كومة الذاكرة المؤقتة Gradle (باستخدام org.gradle.jvmargs) قد تؤثر سلبًا في الأداء على الأجهزة ذات الذاكرة المنخفضة.

بعد إجراء تغيير على تهيئة تصميمك، يُرجى ملاحظة نتائج التغييرات من خلال تكرار الخطوات أعلاه وإنشاء ملف إنشاء جديد. على سبيل المثال، يعرض الشكل 4 تقريرًا لعيّنة التطبيق نفسها بعد تطبيق النموذج. بعض التحسينات الأساسية الموضّحة في هذه الصفحة.

الشكل 4. الاطّلاع على تقرير جديد بعد تحسين الإصدار السرعة.