تعيش أندرويد الأصلية في 2026 تحوّلًا عميقًا. تستقر Kotlin 2.3 كلغة المرجع، وJetpack Compose يحل نهائيًا محل تخطيطات XML القديمة في المشاريع الجديدة، وتفرض Google target SDK 36 على كل تقديم جديد إلى Play Store ابتداءً من 31 أغسطس. للمطوّر الذي يبدأ على أندرويد أو يعود بعد بضع سنوات، المشهد مختلف جذريًا عمّا قدّمته الدروس قبل سنتين أو ثلاث. يضع هذا الدليل الخريطة الكاملة: الإصدارات الدقيقة في مايو 2026، الفلسفة التعريفية لـ Compose، الهندسة المعمارية الحديثة حول StateFlow والـ unidirectional data flow، منظومة Jetpack الموحدة، وسلسلة الإنتاج حتى توقيع AAB. كل ورشة كبرى تُحيل إلى درس مخصص خطوة بخطوة.

لماذا أندرويد الأصلية الحديثة في 2026

هدأ نقاش « الأصلي مقابل المتعدد المنصات ». Flutter وReact Native وKotlin Multiplatform تغطي الآن حالات استخدام واضحة المعالم، وأندرويد الأصلية لم تعد موضع تساؤل تلقائي عند كل مشروع جديد. عندما نستهدف أندرويد حصريًا، أو نحتاج للتحكم الدقيق في الرسوم المتحركة، إمكانية الوصول، أجهزة الاستشعار، أو APIs النظام الحديثة مثل الأمن البيومتري المتطور أو اللوحات المتكيّفة مع الـ foldables، يبقى SDK الأصلي لا يُهزَم. الفرق التي تطوّر تطبيقات الدفع، الصحة، الإنتاجية بـ widgets غنية، أو تطبيقات استهلاكية ذات استجابة عالية، لا تزال تختار الأصلي بكثافة.

حجّة الإنتاجية انقلبت لصالح Compose. حيث كان Android View System يفرض XML + binding + adapter + custom views، يتيح Compose وصف شاشة كاملة في بضع عشرات من أسطر Kotlin، مع إعادة تركيب تلقائي عند تغيّر حالة. تقيس الفرق داخليًا مكاسب 40 إلى 60% على وقت تطوير الشاشات المعقدة. على جانب أدوات التطوير، Android Studio Otter 3 Feature Drop يدمج الآن أصلًا المعاينة التفاعلية، الجلسات الوكيلة لاختبارات التكامل، والفحص المباشر لرسم بياني إعادة التركيب.

أخيرًا، أصبح إيقاع Google قابلًا للتنبؤ. منصة رئيسية في السنة (Android 16 في 2025، Android 17 منتظر نهاية 2026)، Feature Drop لـ Android Studio كل ثلاثة إلى أربعة أشهر، إصدارات Compose موائمة بـ BOM شهري. مما يجعل الكدسة مستقرة والتخطيط الصناعي ممكنًا.

Kotlin 2.3: ما الذي تغيّر لأندرويد

Kotlin 2.3.21 هو الإصدار المستقر وقت الكتابة، مع 2.4 RC الذي يُقدّم context parameters المستقرة وexplicit backing fields. لمشروع أندرويد حديث، نستهدف Kotlin 2.3.21 ونراقب 2.4 الصادر يونيو/يوليو 2026. K2، المُجمِّع الجديد الافتراضي منذ 2.0، أصبح الآن مُختبَرًا في الإنتاج: تجميع تزايدي أسرع، دعم أفضل للتعليقات، توافق KSP2 في كل مكان.

الـ Coroutines هي طبقة عدم التزامن الرسمية. suspend fun في كل مكان: في Retrofit لاستدعاءات HTTP، في Room لاستعلامات SQL، في ViewModels لتنسيق العمل. structured concurrency وFlows تحل محل كل منطق قائم على callback. هذا التحوّل في النموذج له أثر مباشر على القراءة: عملية شبكة + cache + UI تتسع لبضعة أسطر بدلًا من سلسلة callbacks Java.

على جانب التسلسل، حلّت kotlinx.serialization محل Gson وMoshi في غالبية المشاريع الجديدة: توليد عند التجميع عبر KSP، لا انعكاس runtime، أداء ممتاز، ودعم أصلي لـ sealed classes لـ APIs ذات التمييز. الرباعي Kotlin + Compose + Coroutines + Serialization يُشكّل الإعداد الافتراضي لأي تطبيق أندرويد حديث.

Jetpack Compose في 2026: نموذج تعريفي وإدارة الحالة

Compose هو UI تعريفي: نصف ما يجب على الشاشة عرضه بناءً على الحالة الراهنة، لا كيفية الانتقال من حالة سابقة إلى تالية. الدالة @Composable هي الوحدة الأساسية. يستدعيها runtime عند كل إعادة تركيب، أي عند كل تغيير لحالة مُراقبة. هذا النهج، الموروث من React وSwiftUI، يُغيّر العقلية: نُفكّر بـ « دالة نقية من الحالة إلى UI ».

تُدار الحالة صراحةً. remember { mutableStateOf(initial) } يحفظ قيمة بين إعادات التركيب، rememberSaveable يُديمها عبر تغييرات الإعداد (دوران، موت العملية)، وللحالة المتعلقة بالأعمال نرفعها إلى ViewModel يكشف StateFlow. القاعدة الذهبية تُسمّى state hoisting: لا يجب أن يمتلك composable حالته إذا كان آخر يحتاج لقراءتها أو تعديلها.

الطبقة البصرية تتبع Material 3 (Material You) افتراضيًا. الـ thème يكشف لوحة ألوان ديناميكية تتكيف مع خلفية المستخدم على Android 12+، والمكونات الأساسية (Scaffold، NavigationBar، TopAppBar، FilledTonalButton) تغطي 90% من الاحتياجات. لاكتشاف Compose عمليًا، درس أول شاشات Compose يستعرض خطوة بخطوة بناء قائمة، نموذج، وتنقّل، مع إدارة الحالة والـ thème.

Compose BOM 2026.05.00 يُحاذي كل مكتبات Compose بالإصدار 1.11.1 المستقر. هو الإصدار الذي نُعلنه في Gradle لتجنّب تعارضات الإصدارات الانتقالية. الـ BOM هو platform Gradle يُقيّد دون فرض: نُضيف الوحدات المُرادة دون تحديد رقمها.

منظومة Jetpack 2026، لبنة تلو الأخرى

Jetpack يجمع المكتبات الرسمية AndroidX. في 2026، الكدسة القانونية لتطبيق جديد تحتوي على مجموعة محدودة لكن قوية. Navigation Compose يُدير التوجيه بين الشاشات بـ API type-safe. Lifecycle يُقدّم ViewModel للنجاة من تغييرات الإعداد وتنسيق الـ coroutines عبر viewModelScope. Hilt (Dagger تحت الغطاء) يحقن التبعيات بصياغة قائمة على annotations.

للتخزين، مستويان. على المستوى الخفيف key-value: DataStore Preferences (يحل محل SharedPreferences المُهجَّر). للبيانات المُهيكَلة: Room. Room 3.0، الصادر في مارس 2026، حصري KSP، يُولّد الآن كود Kotlin 100%، ويدعم Kotlin Multiplatform عبر حزمة androidx.room3. لمشاريع جديدة، ننطلق مباشرة بـ Room 3.0. درس التخزين المحلي بـ Room وCompose يُفصّل إعداد قاعدة مُنمَّطة، الترحيلات، والتكامل مع Flows التفاعلية.

على جانب الشبكة، Retrofit 3.0 الصادر في مايو 2025 يبقى الحل المرجعي، الآن مع OkHttp 4.12 وتكامل coroutines من الدرجة الأولى. التفاصيل في درس استهلاك واجهة REST مع Retrofit. للصورة، Coil 3 (الإصدار المستقر 3.4.0 في ربيع 2026) هو المكافئ الحديث لـ Glide/Picasso، مكتوب بـ Kotlin، متعدد المنصات، ومتوافق مع Compose عبر AsyncImage.

تُكتب اختبارات UI بـ androidx.compose.ui.test، التي تكشف ComposeTestRule لكتابة assertions على شجرة composables. لم نعد بحاجة لـ Espresso في غالبية الحالات. درس اختبارات UI Compose يُغطّي assertions، actions، الحالات المتوقعة، وتكامل CI.

الهندسة المعمارية الحديثة: unidirectional data flow

الهندسة المعمارية الرسمية الموصى بها من Google تُسمى Modern Android Development وتعتمد على ثلاث طبقات. طبقة UI (composables + ViewModels)، طبقة domaine (use cases، اختيارية للمشاريع الصغيرة)، وطبقة data (repositories تُنسّق الشبكة، القاعدة المحلية وذاكرة cache). تدفّق البيانات أحادي الاتجاه: طبقة data تُصدر، طبقة UI تستهلك، الأحداث تصعد عبر callbacks أو دوال مُستدعاة على ViewModel.

الـ ViewModel يكشف StateFlow<UiState> الذي يُراقبه composable عبر collectAsStateWithLifecycle(). عند حدث مستخدم (نقرة، إدخال)، يُستدعى أسلوب من ViewModel يُحدّث الحالة عبر _uiState.update { ... }. تنطلق إعادة التركيب تلقائيًا. لا callbacks معقدة، لا آلة حالة يدوية. النمط مُفصّل في ViewModel وStateFlow مع Jetpack Compose.

حقن التبعيات بـ Hilt يُبسّط التركيب: نُعلّق على الأصناف، نطلب التبعيات في معاملات المُنشئ، الإطار يحقن في runtime. للمشاريع أقل من خمس شاشات، Koin يبقى بديلًا خفيفًا، لكن Hilt يُهيمن واضحًا على السوق الاحترافية.

نمط Repository وإدارة مصادر متعددة

تطبيق جاد يجمع عدة مصادر بيانات: cache ذاكرة للجلسة الراهنة، قاعدة محلية لوضع عدم الاتصال، API بعيدة كمصدر للحقيقة. نمط Repository يخدم كتجريد وحيد لـ UI: مهما كان مصدر البيانات، ViewModel يُحادث Repository، الذي يُقرّر. يُسمى هذا Single Source of Truth: القاعدة المحلية هي SSOT، والشبكة تُغذّيها.

عمليًا، يكشف Repository دوال suspend أو Flows. عندما تطلب UI قائمة المقالات، يُرجع Repository فورًا Flow القادم من Room (الذي يُحدَّث تلقائيًا عند كل تغيير)، ويُطلق بالتوازي refresh من API يكتب في القاعدة. UI لا ترى سوى Flow واحد وتبقى تفاعلية. تُسمى هذه الهندسة Network Bound Resource في مصطلحات Google. تتجنّب الشاشات الفارغة عند اتصال متقطع وتُعطي تجربة فورية عند فتح التطبيق.

لحالات الأعمال المعقدة (مثل حساب سلة بقواعد خصومات، أو التحقق من نموذج بقيود متقاطعة)، نُدخل طبقة domaine بين ViewModel وRepository. كل UseCase صنف بمسؤولية واحدة (operator fun invoke(...))، سهل الاختبار وحدويًا. للمشاريع الصغيرة (أقل من خمس شاشات)، هذه الطبقة زائدة ونستدعي Repository مباشرة من ViewModel. المبدأ: ابدأ بسيطًا، أضف هيكلًا عندما يستوجبه التعقيد.

الرسوم المتحركة والأداء في Compose

Compose يتوفر على API رسوم متحركة معبّر وأدائي. لرسم تغيير حالة بسيط، animate*AsState يغطي الغالبية: animateFloatAsState للشفافية، animateColorAsState لـ thème، animateDpAsState للحجم. للرسوم الأكثر تعقيدًا (دخول/خروج عناصر قائمة، انتقالات مشتركة)، AnimatedVisibility وAnimatedContent وSharedTransitionLayout يُغطّون الجوهر.

أداء Compose يعتمد جوهريًا على استقرار المعاملات. composable يُعاد تركيبه فقط إذا تغيّر أحد معاملاته. إذا كان معامل موسومًا بـ stable (أنواع بدائية، String، أصناف مُعلَّقة @Stable أو @Immutable)، يستطيع Compose تخطّي إعادة التركيب. إذا كان غير مستقر (List قابلة للتعديل، lambda تلتقط حالة)، يلتجئ Compose للأمان ويُعيد التركيب. تحليل إعادات التركيب المفرطة يتم عبر Layout Inspector في وضع « Recomposition counts ».

للقوائم الطويلة، LazyColumn وLazyRow لا يُركّبان إلا العناصر المرئية، مثل RecyclerView. قدّم دائمًا key مستقر لكل item لتجنّب إعادات تركيب لا فائدة منها عند الإدراج/الحذف. للشبكات بأعمدة متغيّرة، LazyVerticalGrid مع GridCells.Adaptive(minSize = 120.dp) يتكيّف تلقائيًا مع حجم الشاشة، مما يُغطّي بأناقة الهواتف، الـ foldables المفتوحة، والأجهزة اللوحية في كود واحد.

التحضير للإنتاج: من البناء إلى Play Store

بمجرد تطوير التطبيق، الانتقال للإنتاج يتطلّب خطوات لا يمكن ضغطها. Gradle Build مُعَدّ لتوليد Android App Bundle (.aab) في وضع release، توقيع بـ keystore مُخزَّن خارج المستودع ومُشفَّر، توقيع بـ Google Play (Play App Signing v2) ليُدير Google نفسه مفاتيح توقيع APKs المُوزَّعة على المستخدمين. العملية الكاملة في درس نشر تطبيق Kotlin على Play Store.

ثلاث مواعيد حاسمة لـ 2026. 1 نوفمبر 2025 (مرّت): محاذاة ذاكرة 16 KB إلزامية لكل تقديم أو تحديث جديد يستهدف Android 15+ على 64-bit. AGP 8.5.1 وما بعد يُحاذي الـ natives تلقائيًا، لكن مكتبات NDK/JNI يجب إعادة تجميعها. 31 أغسطس 2026: target SDK 36 إلزامي لكل تقديم أو تحديث جديد. 1 نوفمبر 2026: سياسات شفافية جمع البيانات الجديدة تُفرض على كل تطبيقات المتجر.

البدء عمليًا: من أين نبدأ

التسلسل الموصى به لمن يبدأ. أولًا، تثبيت Android Studio Otter 3 Feature Drop بـ JDK 17 المُضمَّن، إعداد محاكي أو جهاز فعلي، وإنشاء مشروع فارغ من template « Empty Activity (Compose) ». درس تثبيت Android Studio وإعداد Kotlin الحديثة يستعرض هذه الخطوة، مغطّيًا اختيارات SDK، إعداد ذاكرة IDE، وتفعيل KSP.

ثم، فهم Compose ببناء شاشات بسيطة. قائمة بطاقات، نموذج بتحقق، تنقّل بين شاشتين بتمرير argumants. هكذا نتعلّم composables الأساسية، state hoisting، وthème Material 3. المرحلة التالية: إدخال ViewModel مع StateFlow لفصل منطق الأعمال عن UI.

ثم الاتصال بالعالم الخارجي. Retrofit لاستدعاء REST API، إدارة الأخطاء، حالات التحميل/الخطأ/النجاح في UI. ثم التخزين المحلي بـ Room لوضع عدم الاتصال. وأخيرًا، إضافة اختبارات UI لتأمين التراجعات، وسلسلة النشر. بهذا الإيقاع، في 8 إلى 10 أسابيع من الممارسة المنتظمة، نمتلك تطبيق أندرويد قابلًا للنشر.

أخطاء شائعة في 2026

الخطأ	السبب	الحل
إعادة تركيب مفرطة	حالة غير مستقرة تُمرَّر كمعامل composable	ارفع الحالة، استخدم `derivedStateOf`، علّق `@Stable`
تسرّب ذاكرة عبر callbacks	إشارة لـ composable أو activity في coroutine طويلة	أطلق في `viewModelScope`، استخدم `LaunchedEffect`
بناء معطوب بعد تحديث AGP	plugin Kotlin/AGP/Compose غير محاذية	التحاذي على المصفوفة الرسمية
تطبيق غير مرئي للمستخدمين الجدد	target SDK < 35 بعد 31 أغسطس 2025	الانتقال لـ target SDK 36 فورًا
تعطّل 16 KB على Android 15+	مكتبة أصلية غير محاذية	إعادة التجميع بـ NDK r28+، تحقّق بـ `readelf`
StateFlow غير مُجمَّع	استخدام `.value` في composable	دائمًا `collectAsStateWithLifecycle()`

تكييف الكدسة مع قيود الميدان

ليس الجميع يطوّر على MacBook M4 بـ ألياف متماثلة. على جهاز متواضع، Android Studio Otter 3 يطلب على الأقل 16 GB RAM للعمل بشكل مريح مع المحاكي؛ 8 GB تبقى قابلة للعب إذا عطّلنا الفحص في الزمن الحقيقي وطوّرنا على جهاز فعلي موصول بـ USB بدل المحاكي. المحاكي يستهلك كثيرًا CPU وRAM؛ هاتف مستعمل أقل من 100 يورو موصول في وضع المطوّر يبقى أفضل بكثير للاختبار في ظروف حقيقية.

على جانب الاتصال، التحميل الأولي لـ SDK أندرويد (~6 GB) وGradle (~500 MB) يُثقل اتصال 4G مشتركًا. الأفضل القيام بالتثبيت الأولي في مساحة عمل مشتركة بألياف أو ليلًا في الساعات الخاملة. بمجرد إعداد المشروع، التطوير اليومي يستهلك 50 إلى 200 MB يوميًا للتبعيات التزايدية. لـ CI، GitHub Actions يُقدّم 2000 دقيقة مجانًا شهريًا، كافية لمشروع شخصي أو MVP في الإنتاج.

الأسئلة الشائعة

هل لا يزال يتوجب تعلم Java لأندرويد؟
لا. Kotlin هي اللغة الرسمية من الدرجة الأولى منذ Google I/O مايو 2017، وأكّدت Google استراتيجية « Kotlin-first » لأندرويد في 2019. 95% من المشاريع المهنية الجديدة تبدأ بـ Kotlin. معرفة Java تبقى مفيدة لقراءة قواعد كود قديمة أو مكتبات أطراف ثالثة.

هل Compose يحل تمامًا محل Views XML؟
نعم للمشاريع الجديدة. Compose ونظام Views يمكن أن يتعايشا عبر ComposeView وAndroidView، مما يتيح ترحيل تدريجي. لكن لمشروع جديد في 2026، الانطلاق بـ Compose 100% هو القاعدة.

هل Kotlin Multiplatform يستحق العناء؟
لمشاركة منطق الأعمال بين أندرويد وiOS، KMP ناضج ومُتبنّى من ناشرين كبار (Netflix، McDonald’s، Philips). لطبقة UI، Compose Multiplatform مستقر على desktop منذ ديسمبر 2021 وعلى iOS منذ مايو 2025. لمشروع أندرويد أول، الأفضل توطيد المنصة الأحادية قبل استكشاف KMP.

ما الفرق بين LiveData وStateFlow؟
LiveData هو المعيار القديم المربوط بـ lifecycle أندرويد. StateFlow هو المكافئ الحديث القائم على Coroutines، أقوى (transform، combine، debounce)، أكثر قابلية للاختبار، ومتوافق Kotlin Multiplatform. لكل كود جديد، نختار StateFlow.

أي حاسوب أدنى للتطوير؟
16 GB RAM، 256 GB SSD، CPU حديث (Apple Silicon، Intel i5 12th gen+، Ryzen 5 5000+). تحت ذلك، التطوير ممكن لكن التجربة تتدهور سريعًا مع المحاكي. Mac Mini M2 أو mini-PC Ryzen يُقدّمان نسبة جودة/سعر ممتازة.

كم من الوقت لنشر تطبيق أول؟
بين 8 و16 أسبوعًا حسب المستوى الأولي. مطوّر ويب يعرف Kotlin يمكن أن ينشر MVP في 4 أسابيع. مبتدئ كامل يجب أن يتوقّع 3 إلى 4 أشهر بتعلّم منتظم.

KSP أم KAPT؟
KSP في كل مكان. KAPT ليس مُهجَّرًا رسميًا لكن دخل في وضع صيانة بقيود على K2. Room 3.0 وغالبية المكتبات الجديدة تخلت عنه، Hilt محاذى، وأوقات التجميع مقسومة على 2 أو 3 على مشاريع متوسطة الحجم.

هل نقلق من الاستبدال بالـ AI؟
وضع الـ agent في Android Studio Otter 3 يُولّد أجزاء كبيرة من الكود من وصف بلغة طبيعية. لكنه copilote، ليس بديلًا: التحقق من منطق الأعمال، اختيار الهندسة، التصحيح في الإنتاج، والتحكيم بين الأداء والقراءة يبقى من مسؤولية المطوّر. الإنتاجية ترتفع، الحاجة لمهارات صلبة أيضًا.

Coroutines وFlow: أسس عدم التزامن

الـ Coroutines هي طبقة عدم التزامن الرسمية لـ Kotlin منذ 2018، لكن استخدامها توحّد في 2026. suspend fun يمكن استدعاؤها فقط من coroutine أو suspend أخرى، مما يُلزم البرمجة غير المتزامنة بالبقاء صريحة. العمليات المُعطِّلة (شبكة، قرص) تُفوَّض إلى dispatchers مخصصة: Dispatchers.IO للـ I/O، Dispatchers.Default لحساب CPU، Dispatchers.Main لـ UI أندرويد.

الـ Flows هي تدفّقات قيم غير متزامنة. Flow<User> يُصدر صفر، واحد أو عدة User على مدى الزمن. مُشغّلات Flow (map، filter، combine، debounce، flowOn) تتيح تركيب أنابيب قابلة للقراءة. على جانب UI، collectAsStateWithLifecycle() يحترم دورة الحياة: تتوقف المُجمَّعة عند انتقال الشاشة للخلف وتستأنف تلقائيًا عند العودة.

Kotlin وJetpack Compose في 2026: أندرويد الأصلية الحديثة