Compile و Implementation على Android Studio
إضافة تبعيات بناء build dependencies يسهّل نظام إنشاء Gradle في Android Studio تضمين الثنائيات الخارجية أو وحدات المكتبة الأخرى في البنية كتركيبات. يمكن أن تكون الاعتمادات موجودة على جهازك أو في مستودع بعيد ، وأي تبعيات متعدية يتم الإعلان عنها يتم تضمينها تلقائيًا أيضًا.
توضح هذه الصفحة كيفية استخدام التبعيات مع مشروع Android الخاص بك ، بما في ذلك تفاصيل حول السلوكيات والتكوينات الخاصة بمكوّن Android الإضافي لـ Gradle. للحصول على دليل مفاهيمي أكثر عمقًا لاعتماديات Gradle ، يجب أن ترى أيضًا دليل Gradle لمدير التبعية - ولكن تذكر أن مشروع Android الخاص بك يجب أن يستخدم فقط تكوينات التبعية المحددة في هذه الصفحة.
تحذير:عند تحديد التبعيات ، يجب عدم استخدام أرقام الإصدارات الديناميكية ، مثل "+.com.android.tools.build:gradle:3". يمكن أن يتسبب استخدام هذه الميزة في حدوث تحديثات إصدار غير متوقعة وصعوبة في حل الاختلافات في الإصدارات.
تتطلب مثل هذه الاعتمادات عن بعد أن تعلن مستودعات التخزين عن بعد المناسبة حيث يجب أن يبحث Gradle عن المكتبة. إذا لم تكن المكتبة موجودة بالفعل محليًا ، فإن Gradle تسحبها من الموقع البعيد عندما يتطلب البناء ذلك (مثل عند النقر فوق Sync Project مع Gradle Files أو عند تشغيل البنية).
تكوينات الاعتمادية Dependency configurations
داخل كتلة التبعيات ، يمكنك إعلان تبعية المكتبة باستخدام أحد تهيئات التبعية المختلفة (مثل التنفيذ الموضح أعلاه). يوفر كل تبع تبعية Gradle إرشادات مختلفة حول كيفية استخدام التبعية. يصف الجدول التالي كل التهيئات التي يمكنك استخدامها للتبعية في مشروع Android الخاص بك. يقارن الجدول أيضًا هذه التهيئات مع تلك التي تم إيقافها اعتبارًا من Android Gradle Plugin 3.0.0.
| التكوين الجديد | التكوين مهمل | سلوك |
|---|---|---|
| implementation | compile | يضيف Gradle التبعية إلى classpath للترجمة ويقوم بتعبئة التبعية إلى مخرجات الإنشاء. ومع ذلك ، عندما تقوم الوحدة النمطية الخاصة بك بتكوين تبعية تنفيذ ، فإنها تدع Gradle تعرف أنك لا تريد أن تسر الوحدة النمطية التبعية إلى وحدات أخرى في وقت التحويل البرمجي. وهذا هو ، التبعية متاحة للوحدات الأخرى فقط في وقت التشغيل. يمكن أن يؤدي استخدام تكوين التبعية هذا بدلاً من api أو compile (deprecated) إلى تحسينات كبيرة في وقت الإنشاء نظرًا لأنه يقلل عدد الوحدات النمطية التي يحتاجها نظام الإنشاء لإعادة التجميع. على سبيل المثال ، إذا غيّر تبعية التطبيق API الخاص به ، فإن Gradle يعيد ترجمة ذلك التبعية والوحدات التي تعتمد عليها مباشرة. يجب أن تستخدم معظم وحدات الاختبار والاختبار هذا التكوين. |
| api. | compile | يضيف Gradle التبعية إلى classpath للإنشاء وإنشاء الإخراج. عندما تتضمن الوحدة النمطية اعتمادًا على واجهة برمجة التطبيقات ، فسيسمح لك Gradle بمعرفة أن الوحدة تريد تصدير تلك التبعية بشكل عمودي إلى وحدات أخرى ، بحيث تكون متاحة لها في وقت التشغيل والوقت التجميعي. يتصرف هذا التكوين تمامًا مثل الترجمة (التي تم إهمالها الآن) ، ولكن يجب عليك استخدامها بحذر وفقط مع التبعيات التي تحتاج إلى تصديرها بشكل انتقائي إلى المستهلكين الآخرين. ويرجع ذلك إلى أنه في حالة تغيير التبعية api لواجهة برمجة التطبيقات الخارجية ، فإن Gradle يعيد تجميع كل الوحدات التي يمكنها الوصول إلى تلك التبعية في وقت التحويل البرمجي. لذا ، فإن وجود عدد كبير من التبعيات api يمكن أن يزيد بشكل كبير من وقت البناء. ما لم تكن ترغب في كشف واجهة برمجة التطبيقات للتبعية إلى وحدة نمطية منفصلة ، يجب أن تستخدم وحدات المكتبة بدلاً من ذلك تبعيات التنفيذ |
| compileOnly | provided | يضيف Gradle التبعية إلى classpath الخاص بالتجميع فقط (أي ، لا يتم إضافته إلى مخرجات الإنشاء). يكون ذلك مفيدًا عند إنشاء وحدة Android وتحتاج إلى الاعتماد أثناء التحويل البرمجي ، ولكن من الاختياري أن تكون موجودة في وقت التشغيل. إذا كنت تستخدم هذا التكوين ، فيجب أن تتضمن وحدة المكتبة الخاصة بك شرطًا للوقت للتحقق مما إذا كانت التبعية متوفرة ، ومن ثم تغيير سلوكها بأمان حتى تظل تعمل إذا لم يتم توفيرها. يساعد ذلك في تقليل حجم ملف APK النهائي عن طريق عدم إضافة تبعيات مؤقتة غير حرجة. يعمل هذا التكوين مثلما يتم توفيره (والذي تم إيقافه الآن). |
| runtimeOnly | apk | يضيف Gradle التبعية إلى مخرجات الإنشاء فقط ، لاستخدامها أثناء وقت التشغيل. بمعنى ، لا يضاف إلى classpath الترجمة. هذا التكوين يتصرف تماما مثل APK (الذي هو الآن إهمال). |
| annotationProcessor | compile | لإضافة تبعية على مكتبة بمعالج توضيحي ، يجب عليك إضافتها إلى مسار معالج التعليقات التوضيحية باستخدام التوصيف التوضيحي المعالج. ويرجع ذلك إلى أن استخدام هذا التكوين يعمل على تحسين أداء الإنشاء من خلال فصل تصنيف فئة الترجمة من مسار فئة المعالج التوضيحي. إذا عثر Gradle على معالجات توضيحية على مسار التصنيف التجميعي ، فإنه يلغي تنشيط التجميع ، والذي يؤثر سلبًا على وقت الإنشاء (Gradle 5.0 أو أعلى يتجاهل معالجات التعليقات التوضيحية الموجودة على مسار التصنيف التجميعي). فترض Android Gradle Plugin أن التبعية هي معالج توضيحي إذا كان ملف JAR يحتوي على الملف التالي: META-INF / services / javax.annotation.processing.Processor. إذا اكتشف المكون الإضافي معالجًا توضيحيًا موجودًا في مسار التصنيف التجميعي ، فإنه ينتج عنه خطأ في الإنشاء. |
تنطبق التكوينات المذكورة أعلاه على مجموعة المصدر الرئيسي لمشروعك ، والتي يتم تطبيقها على جميع أشكال الإنشاء. إذا كنت ترغب بدلاً من ذلك في إعلان تبعية لمجموعة معينة فقط من مصادر مختلفة للبناء ، أو لمجموعة مصدر اختبار ، يجب أن تقوم بتكبير اسم التوصيف وبادئته باسم متغير الإنشاء أو مجموعة مصدر الاختبار.
إضافة معالجات التوضيحية annotation processors
إذا أضفت معالجات توضيحية إلى مسار التصنيف الخاص بك ، سترى رسالة خطأ مشابهة لما يلي:
خطأ: يجب أن يتم الإعلان بوضوح عن معالجات التعليقات التوضيحية الآن.
لحل هذا الخطأ ، قم بإضافة المعالجات التوضيحية إلى المشروع الخاص بك عن طريق تكوين التبعية الخاصة بك باستخدام annotationProcessor
المعالج التي تمثل الملفات أو الأدلة باستخدام واجهة Gradle's CommandLineArgumentProvider.
يتيح لك استخدام CommandLineArgumentProvider أو مؤلف معالج التعليق التوضيحي تحسين أداء وأداء التركيبات المتزايدة والتدريجية المخزنة مؤقتًا من خلال تطبيق التعليقات التوضيحية الخاصة بنوع البناء التزايدي على كل وسيطة.
على سبيل المثال ، تطبق الفئة أدناه CommandLineArgumentProvider ويوضّح كل وسيطة للمعالج. يستخدم النموذج أيضًا بنية لغة Groovy ويتم تضمينه مباشرة في ملف build.gradle الخاص بالوحدة النمطية.
ملاحظة:
عادةً ، يقدم مؤلفو المعالجات التوضيحية إما هذه الفئة أو إرشادات حول كيفية كتابة مثل هذه الفئة. ويرجع ذلك إلى أن كل وسيطة تحتاج إلى تحديد التعليق التوضيحي لنوع موقع البناء الصحيح للعمل على النحو المنشود.