يُعرف المشروع الذي يحتوي على وحدات Gradle المتعددة باسم المشروع متعدد الوحدات. ويشمل هذا الدليل أفضل الممارسات والأنماط المقترَحة لتطوير تطبيقات Android متعددة الوحدات.
مشكلة تزايد قاعدة الرموز
في قاعدة التعليمات البرمجية المتزايدة باستمرار، غالبًا ما تقل قابلية التوسع وسهولة القراءة وجودة التعليمات البرمجية بمرور الوقت. يأتي ذلك نتيجة زيادة حجم قاعدة التعليمات البرمجية بدون أن يتّخذ المشرفون عليها إجراءات نشطة لفرض هيكل يمكن صيانته بسهولة. إنّ تقسيم قاعدة التعليمات البرمجية هو وسيلة لهيكلة قاعدة التعليمات البرمجية بطريقة تعمل على تحسين قابلية صيانتها وتساعد في تجنب هذه المشاكل.
ما هي عملية التقسيم إلى وحدات؟
التقسيم إلى وحدات هو ممارسة لتنظيم قاعدة التعليمات البرمجية إلى أجزاء غير مرتبطة ومترابطة بذاتها. كل جزء هو وحدة. كل وحدة مستقلة تخدم غرضًا واضحًا. من خلال تقسيم المشكلة إلى مشكلات أصغر ويسهل حلها، يمكنك تقليل تعقيد تصميم نظام كبير وصيانته.
![](https://developer.android.google.cn/static/topic/modularization/images/1_sample_dep_graph.png?authuser=19&hl=ar)
مزايا التقسيم إلى وحدات
العديد من المزايا الخاصة بعملية التقسيم إلى وحدات، على الرغم من أنّ كل منها يركّز على تحسين قابلية صيانته وجودته بشكل عام لقاعدة الرموز البرمجية. يلخص الجدول أدناه الفوائد الرئيسية.
المزايا | ملخّص |
---|---|
إعادة الاستخدام | يتيح تقسيم النماذج فرصًا لمشاركة الرموز البرمجية وإنشاء تطبيقات متعددة من الأساس نفسه. الوحدات هي اللبنات الأساسية بشكل فعال. يجب أن تكون التطبيقات عبارة عن مجموع ميزاتها حيث يتم تنظيم الميزات كوحدات منفصلة. قد يتم تفعيل أو عدم تفعيل الوظيفة التي توفّرها وحدة معيّنة في تطبيق معيّن. على سبيل المثال، يمكن أن تكون السمة :feature:news جزءًا من صيغة الإصدار الكامل وتطبيق Wear، وليس جزءًا من صيغة الإصدار التجريبي. |
تحكّم صارم في مستوى الرؤية | تتيح لك الوحدات التحكّم بسهولة في المحتوى الذي يتم عرضه على أجزاء أخرى من قاعدة الرموز. يمكنك وضع علامة internal أو private على كل العناصر باستثناء واجهتك العامة، وذلك لمنع استخدامها خارج الوحدة. |
التسليم القابل للتخصيص | يستخدم عرض الميزات في Play الإمكانات المتقدمة لحِزم التطبيقات، ما يتيح لك تقديم ميزات معيّنة في تطبيقك بشروط أو عند الطلب. |
لا يمكن تحقيق المزايا المذكورة أعلاه إلا باستخدام قاعدة رموز مقسّمة إلى وحدات. يمكنك الاستفادة من المزايا التالية باستخدام أساليب أخرى، إلا أنّ تقسيمها إلى وحدات قد يساعدك على فرضها بشكل أكبر.
المزايا | ملخّص |
---|---|
سهولة التطوير | في حال استخدام قاعدة رموز برمجية مترابطة، يمكن أن يؤدي تغيير واحد إلى سلسلة من التغييرات في أجزاء من الرمز تبدو غير مرتبطة ببعضها البعض. سيتبنى المشروع المقسّم إلى وحدات بشكل صحيح مبدأ فصل المخاوف وبالتالي الحد من الاقتران. وهذا يمكِّن المساهمين من خلال قدر أكبر من الاستقلالية. |
الملكية | بالإضافة إلى تفعيل الاستقلالية، يمكن أيضًا استخدام الوحدات لفرض المساءلة. يمكن أن يكون للوحدة مالك مخصص مسؤول عن صيانة التعليمات البرمجية وإصلاح الأخطاء وإضافة الاختبارات ومراجعة التغييرات. |
التغليف | يعني التغليف أن كل جزء من التعليمات البرمجية يجب أن يحتوي على أقل قدر ممكن من المعرفة حول الأجزاء الأخرى. من السهل قراءة وفهم التعليمات البرمجية المعزولة. |
قابلية الاختبار | توضّح قابلية الاختبار مدى سهولة اختبار الرمز. الرمز القابل للاختبار هو الرمز الذي يمكن فيه اختبار المكونات بسهولة بمعزل عن بعضها. |
وقت الإصدار | يمكن لبعض وظائف Gradle، مثل الإنشاء التزايدي أو إنشاء ذاكرة تخزين مؤقت أو الإصدار الموازي، الاستفادة من الوحدات النمطية لتحسين أداء الإصدار. |
الصعوبات الشائعة
إنّ دقة قاعدة الترميز هي مقدار مؤلفها من وحدات. يحتوي قاعدة الترميز الأكثر دقة على وحدات أصغر وأصغر. عند تصميم قاعدة تعليمات برمجية مُقسمة إلى وحدات، يجب أن تقرر مستوى من الدقة. للقيام بذلك، ضع في الاعتبار حجم قاعدة التعليمات البرمجية وتعقيدها النسبي. إنّ استخدام عناصر دقيقة جدًا سيجعل الأعباء عبئًا عليك، وستقلل من مزايا تقسيمها إلى وحدات.
في ما يلي بعض المشاكل الشائعة:
- دقيقة جدًا: تجلب كل وحدة قدرًا معيّنًا من النفقات العامة في شكل زيادة تعقيد التصميم والرموز النموذجية. يجعل الإعداد المعقد للبنية من الصعب الحفاظ على اتساق الإعدادات عبر الوحدات. ينتج عن الكثير من التعليمات البرمجية النموذجية قاعدة رموز مرهقة يصعب صيانتها. إذا كان النفقات العامة يواجه تحسينات القابلية للتوسع، يجب أن تفكر في توحيد بعض الوحدات.
- غير دقيق: على طرف النقيض، في حال زيادة حجم الوحدات بشكل كبير، قد تحصل على كتلة صخرية أخرى وستفوتك المزايا التي توفّرها النماذج النمطية. على سبيل المثال، في مشروع صغير لا بأس في وضع طبقة البيانات داخل وحدة واحدة. ولكن مع نموها، قد يكون من الضروري فصل المستودعات ومصادر البيانات إلى وحدات مستقلة.
- أمر معقد جدًا: ليس من المنطقي دائمًا تقسيم مشروعك إلى وحدات. يتمثل العامل السائد في حجم قاعدة التعليمات البرمجية. إذا لم تكن تتوقع أن يتخطى مشروعك حد معين، فلن تنطبق مكاسب التوسع ووقت الإنشاء.
هل يُعدّ تقسيم الوحدات النمطية الأسلوب الصحيح بالنسبة لي؟
إذا كنت بحاجة إلى مزايا مثل قابلية إعادة الاستخدام أو التحكّم الصارم في مستوى الرؤية أو عرض الميزات في Play، لا بد أن يكون هناك تقسيم إلى وحدات. إذا لم يكن الأمر كذلك، ولكن ما زلت تريد الاستفادة من قابلية التوسع أو الملكية أو التغليف أو أوقات الإنشاء، فإن التقسيم إلى وحدات أمر يستحق أخذه في الاعتبار.
عيّنات
- الآن في Android: تطبيق Android يعمل بكامل طاقته مع تقسيمه إلى وحدات.
- نموذج لبنية متعددة الوحدات