Jetpack — ما هو، مكونات الهندسة المعمارية

ما هو Android Jetpack؟

Android Jetpack هو مجموعة من المكتبات والأدوات والإرشادات المعمارية من Google، تم تقديمها في عام 2018 في Google I/O. حل Jetpack محل Support Library وAndroid Architecture Components، ودمجها في نظام بيئي واحد. قبل Jetpack، كانت كل مكتبة Android يتم تحديثها بشكل مستقل، مما خلق تعارضات في الإصدارات. قام Jetpack بمزامنة الإصدارات تحت معرف AndroidX موحد وقدم نموذج إصدارات رئيسية مستقرة مع تصحيحات ثانوية.

تنقسم مكتبات Jetpack إلى أربع فئات: Architecture (ViewModel وRoom وNavigation وWorkManager)، UI (Fragment وCompose وAnimation وPalette)، Behavior (DownloadManager وMedia وPermissions وSharing)، Foundation (Android KTX وMultidex وAppCompat). كل فئة تعالج مهام طبقة معينة من التطبيق — من إدارة البيانات إلى واجهة المستخدم.

فلسفة Jetpack

تقدم Google ثلاثة مبادئ لـ Jetpack: accelerate development (كود样板 أقل، منطق أعمال أكثر)، eliminate boilerplate (ViewModel يلغي الحفظ اليدوي للحالة، Room يلغي كتابة SQLiteOpenHelper) و build with confidence (كل مكتبة تجتاز أكثر من 15,000 اختبار قبل الإصدار). وفقًا لـ Android Developers (2026)، فإن التطبيقات التي تستخدم Jetpack بها أعطال أقل بنسبة 30% مرتبطة بدورة الحياة.

AndroidX كأساس

جميع مكتبات Jetpack يتم توزيعها تحت معرف AndroidX (القطع الأثرية مثل androidx.*). حل AndroidX محل Support Library (القطع الأثرية مثل com.android.support.*)، وقسم المكتبة المتجانسة إلى قطع أثرية معيارية مع إصدارات مستقلة. يتم الترحيل إلى AndroidX عبر خيار android.useAndroidX=true في gradle.properties — يقوم Android Studio تلقائيًا بتحويل الاستيرادات.

مكونات الهندسة المعمارية: ViewModel وLifecycle وLiveData

ViewModel هو المكون المركزي لهندسة Jetpack الذي يخزن بيانات واجهة المستخدم. على عكس النشاط الذي يتم تدميره عند تدوير الشاشة، يبقى ViewModel في الذاكرة. يقوم المستخدم بملء نموذج، يدير الهاتف — لا تفقد البيانات. يتم مسح ViewModel تلقائيًا عندما ينهي LifecycleOwner (النشاط أو الجزء) دورة حياته بشكل دائم (finish).

class ProfileViewModel : ViewModel() {

    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            val user = repository.getUser(userId)
            _userName.value = user.name
        }
    }
}

@OptIn(ExperimentalLifecycleApi::class)
class MyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        println("تم تشغيل الشاشة")
    }
}

LiveData — حاوية بيانات قابلة للملاحظة تحترم دورة الحياة. إذا كانت الشاشة غير مرئية (onStop)، لا ترسل LiveData تحديثات — وهذا يمنع تسرب الذاكرة والأعطال عند محاولة تحديث نشاط غير موجود. Lifecycle — فئة تخزن الحالة الحالية (CREATED وSTARTED وRESUMED) وتسمح للمكونات الأخرى بالاشتراك في تغييرات الحالة. معًا، تشكل ViewModel وLiveData وLifecycle أساس الهندسة التفاعلية لنظام Android.

ViewModelScope و coroutines

viewModelScope — CoroutineScope مدمج مرتبط بدورة حياة ViewModel. يتم إلغاء جميع coroutines التي تم إطلاقها في هذا النطاق تلقائيًا عند مسح ViewModel. هذا يلغي الإدارة اليدوية لـ Disposable وCompositeDisposable في كل ViewModel. للعمل مع viewModelScope، يلزم الاعتماد androidx.lifecycle:lifecycle-viewmodel-ktx.

Room: العمل مع قاعدة البيانات على Android

Room هي مكتبة ORM من Jetpack توفر طبقة تجريد فوق SQLite. بدلاً من كتابة استعلامات SQL الخام وتحويل Cursor يدويًا إلى كائنات، يعلن المطور عن Entity (جدول) وDAO (كائن الوصول إلى البيانات) وDatabase (نقطة الدخول). يتحقق Room من استعلامات SQL في وقت الترجمة عبر التعليق التوضيحي @Query — إذا كانت الجداول أو الأعمدة غير موجودة، يفشل البناء مع خطأ واضح.

@Entity
data class User(
    @PrimaryKey val id: String,
    val name: String,
    val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM User WHERE id = :userId")
    suspend fun getUser(userId: String): User?

    @Insert
    suspend fun insertUser(user: User)
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Entity User تصف جدولاً بثلاثة أعمدة. يعلن DAO عن وظائف suspend للعمل مع coroutines — يتم تنفيذ الاستعلام على خيط خلفية تلقائيًا. Room يدعم الترحيلات عبر التعليق التوضيحي @Migration: يصف المطور script SQL للانتقال بين الإصدارات، وينفذه Room دون فقدان البيانات. في حالة عدم وجود ترحيل، يرمي Room IllegalStateException — وهذا يحمي المشاريع من فقدان البيانات العرضي عند تحديث المخطط.

TypeConverters والعلاقات

Room يخزن فقط الأنواع البدائية ومغلفاتها. لتخزين القوائم أو Date أو الكائنات المخصصة، يتم استخدام @TypeConverter — طريقة ثابتة تحول نوعًا إلى String (JSON) أو Long (timestamp). يتم نمذجة العلاقات بين الجداول عبر كائنات متداخلة مع التعليق التوضيحي @Relation وفئات POJO المساعدة مع @Transaction لاستعلامات join فعالة.

Navigation Component: الرسوم البيانية والوسائط

Navigation Component — مكتبة Jetpack لإدارة الانتقالات بين الشاشات. بدلاً من استدعاء FragmentTransaction يدويًا، يقوم المطور بإنشاء رسم بياني للتنقل (ملف XML مع عقد وجهة)، ويقوم النظام بتوليد فئة Directions مع طرق انتقال آمنة من حيث النوع. يضمن Navigation Component التشغيل الصحيح لمكدس الرجوع والروابط العميقة ونقل الوسائط بين الشاشات.

// nav_graph.xml
// 
//     android:name=".ProfileFragment">
//     
//         android:defaultValue="-1"
//         app:argType="integer" />
// 

// في كود الجزء:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        loadProfile(args.userId)
    }
}

يتم تمرير الوسائط userId في الرسم البياني للتنقل مع تحديد النوع (integer) وقيمة افتراضية. يتم إنشاء فئة ProfileFragmentArgs تلقائيًا بواسطة إضافة Navigation Safe Args — وهي تحتوي على جميع الوسائط مع أنواع Kotlin الصحيحة. يتم تكوين الروابط العميقة في الرسم البياني: app:deepLink="app://profile/{userId}". يقوم Navigation Component بنفسه بتحليل URL وإنشاء مكدس الرجوع كما لو كان المستخدم قد تنقل عبر الواجهة.

التنقل السفلي والتنقل الشرطي

يتكامل Navigation Component مع BottomNavigationView عبر NavController: كل عنصر قائمة يرتبط بوجهة في الرسم البياني. التبديل بين العلامات لا يعيد إنشاء الجزء — يحافظ Navigation Component على الحالة عبر NavBackStackEntry. للتنقل الشرطي (إظهار تسجيل الدخول إذا لم يتم المصادقة)، يتم استخدام navController.navigate(condition) مع التحقق في onCreate.

AndroidX: Support Library من الجيل الجديد

AndroidX هي بنية معاد تصميمها لـ Support Library حيث حصلت كل مكتبة على قطعة أثرية خاصة بها بإصدار مستقل. بدلاً من com.android.support:appcompat-v7:28.0.0 الواحد، يقدم AndroidX androidx.appcompat:appcompat:1.7.0 و androidx.recyclerview:recyclerview:1.4.0 وهكذا. هذا أزال المشكلة حيث كانت التبعيات المختلفة تسحب إصدارات مختلفة من Support Library، مما يسبب تعارضات.

يتم الترحيل إلى AndroidX تلقائيًا في Android Studio 3.2+ عبر القائمة Refactor → Migrate to AndroidX. يقوم الاستوديو باستبدال جميع الاستيرادات في ملفات Java/Kotlin والبيانات والموارد. التوافق مع الإصدارات السابقة هو الميزة الرئيسية لـ AndroidX: المكتبات تعمل على Android 5.0 (API 21) وما فوق، وتغطي 97% من الأجهزة النشطة وفقًا لـ Google Play Console (2025).

القطع الأثرية الرئيسية لـ AndroidX

القطع الأثرية الأكثر استخدامًا: appcompat (السمة الداكنة، Material Design على واجهات API القديمة)، recyclerview (قوائم متكيفة مع ViewHolder)، constraintlayout (حاوية مرنة بتسلسل هرمي مسطح)، cardview (بطاقات Material Design)، preference (شاشة الإعدادات بنمط Material). كل قطعة أثرية لها إصدار مستقل، مما يسرع توصيل الإصلاحات دون تحديث الحزمة بأكملها.

مكتبات Jetpack الهامة الأخرى

بالإضافة إلى Architecture وAndroidX، يتضمن Jetpack العديد من المكتبات المتخصصة للمهام النموذجية لتطوير التطبيقات المحمولة. WorkManager — للمهام الخلفية مع تنفيذ مضمون (مزامنة، تحميل السجلات)، يدعم المهام الدورية والمؤجلة، بالإضافة إلى قيود الشبكة والبطارية. DataStore — بديل لـ SharedPreferences يعتمد على coroutines، يدعم الخصائص المقيدة (Preferences DataStore) وProtocol Buffers (Proto DataStore).

• Hilt — إطار عمل DI يعتمد على Dagger يبسط حقن التبعيات عبر التعليقات التوضيحية @HiltViewModel و@Inject و@Module. تكامل مدمج مع ViewModel وNavigation.
• Paging 3 — مكتبة لتحميل البيانات المرقمة من الشبكة/قاعدة البيانات مع دعم RemoteMediator (شبكة + ذاكرة تخزين مؤقت) وStateFlow وCompose.
• CameraX — واجهة برمجة تطبيقات للعمل مع الكاميرا، تجرد اختلافات الشركات المصنعة (Samsung وXiaomi وHonor) عبر واجهة CameraController موحدة.
• Security Crypto — تشفير البيانات عبر EncryptedSharedPreferences وEncryptedFile استنادًا إلى AES-256 بمفتاح رئيسي في Android Keystore.

كل مكتبة لها SDK الأدنى الخاص بها والقطعة الأثرية. تصدر Google الإصدارات الرئيسية مرة واحدة في السنة (متزامنة مع إصدار Android) وتصحيحات أمان كل ثلاثة أشهر. توصية — قم بتضمين المكتبات الضرورية فقط لتجنب زيادة حجم APK. مجموعة Jetpack الكاملة (جميع القطع الأثرية) تزن أكثر من 20 ميجابايت، لكن التطبيق النموذجي يستخدم 5-7 مكتبات، مما يضيف 3-5 ميجابايت إلى APK.