إدارة التهيئة في تطوير التطبيقات المحمولة: ما هي، وما الخيارات وكيفية الإعداد

إدارة التهيئة في Android: Build Variant وbuild.gradle

Build Variant — مزيج من Build Type (debug/release/staging) وProduct Flavor (free/paid وdemo/full). يقوم Gradle تلقائيًا بإنشاء variant لكل تركيبة: freeDebug وfreeRelease وpaidDebug وpaidRelease. يمكن أن يكون لكل variant كود وموارد وتبعيات خاصة به — هذا هو أساس إدارة التهيئة في التطبيقات المحمولة على Android.

Build Variant مقابل Product Flavor

Build Type — إعدادات البناء: هل التصحيح مفعل، التوقيع، تحسين ProGuard. debug افتراضيًا يحتوي على debuggable=true، release — minifyEnabled=true.

Product Flavor — متغير التطبيق: مجاني (free)، مدفوع (paid)، تجريبي (demo). يمكن أن تحتوي النكهات على applicationId وموارد وتبعيات SDK مختلفة.

// build.gradle — إعداد نكهات المنتج في Android
android {
    productFlavors {
        free {
            applicationId "com.example.app.free"
            versionName "1.0-free"
        }
        paid {
            applicationId "com.example.app.paid"
            versionName "1.0-paid"
        }
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt')
        }
    }
}

المثال ينشئ نكهتين: free وpaid. تم تعيين applicationId منفصل لـ free — وهذا يسمح بتثبيت كلا التطبيقين على جهاز واحد. BuildConfig يتم إنشاؤه لكل variant: BuildConfig.FLAVOR = "free"، BuildConfig.BUILD_TYPE = "debug". استخدم BuildConfig في الكود للمنطق الشرطي.

settings.gradle وGradle KTS

settings.gradle — ملف Gradle الجذر الذي يصف وحدات المشروع.

Gradle KTS — بديل لـ Groovy باستخدام Kotlin DSL. KTS يوفر الإكمال التلقائي في Android Studio والتحقق من الأنواع. موصى به للمشاريع الجديدة.

إدارة التهيئة في iOS: Scheme و.xcconfig

إدارة التهيئة في iOS تُبنى على Scheme — تهيئة Xcode التي تحدد ماذا وكيف يتم البناء: Build Configuration (Debug/Release) والاختبارات والتحليل والأرشفة. يمكن نسخ Scheme لبيئات مختلفة (Development وStaging وProduction). يتم تخزين Scheme في ملف .xcscheme في مجلد xcshareddata.

ملفات .xcconfig

.xcconfig — ملف تهيئة Xcode يخزن إعدادات البناء في شكل نصي. لإدارة التهيئة في التطبيقات المحمولة، يستخدم iOS .xcconfig: التحكم في الإصدارات في Git، إعادة الاستخدام بين المشاريع، إعدادات يدوية أقل. في .xcconfig يتم تعيين SWIFT_ACTIVE_COMPILATION_CONDITIONS وPRODUCT_BUNDLE_IDENTIFIER وCODE_SIGN_IDENTITY.

Info.plist — ملف بيانات وصفية للتطبيق. يخزن الإصدار والمعرّف والأذونات. يمكن أن يكون Info.plist مختلفًا لكل Scheme — عبر Info.plist File في Build Settings.

AndroidManifest.xml — المكافئ في Android: يخزن الأذونات والمكونات والبيانات الوصفية.

Scheme مقابل Build Configuration

Scheme — سيناريو البناء (ماذا تفعل). Build Configuration — مجموعة الإعدادات (كيف تفعل). يستخدم Scheme واحد Build Configuration واحدة (Debug أو Release). لـ CI/CD: قم بتعيين إجراء Archive على Release وإجراء Test على Debug في نفس Scheme.

إدارة التهيئة في Flutter وReact Native: pubspec.yaml وPodfile و.env

pubspec.yaml — ملف تهيئة مشروع Flutter. يحتوي على التبعيات والإصدارات والموارد. يدعم متغيرات البيئة من خلال --dart-define.

Podfile — مدير تبعيات CocoaPods لنظام iOS. يحدد إصدارات المكتبات والمنصة.

.env — ملف بمتغيرات البيئة لجميع المنصات. تستخدم Flutter وReact Native نهجًا مختلفًا لإدارة التهيئة: dart-define في Flutter وreact-native-config في React Native. إدارة التهيئة في المشاريع متعددة المنصات تتضمن أدوات مختلفة حسب المجموعة التقنية.

.env ومتغيرات البيئة

.env — ملف نصي بأزواج مفتاح=قيمة. لا يتم رفعه إلى Git (أضف إلى .gitignore). لـ Flutter — flutter_dotenv، لـ iOS — Config.xcconfig مع #include، لـ Android — BuildConfig. متغيرات env: API_URL وSENTRY_DSN وAPP_SECRET. في إدارة التهيئة في تطوير التطبيقات المحمولة، .env هو المعيار الفعلي لتخزين الأسرار خارج المستودع.

Podfile وpubspec.yaml

Podfile يصف تبعيات CocoaPods والمنصة (platform :ios, '15.0'). pubspec.yaml لـ Flutter — dependencies وdev_dependencies. كلاهما يدعم التبعيات الشرطية: pod 'Analytics', :configs => ['Release'] أو flutter pub add --flavor free. في IT Sectr، نستخدم .env + BuildConfig للأسرار وPodfile للتبعيات الأصلية في المشاريع المحمولة.

يوضح الجدول الاختلافات الرئيسية في إدارة التهيئة بين المنصات المحمولة. Android يوفر مرونة أكبر من خلال Build Variant. iOS أبسط لكنه أقل مرونة. Flutter يمركز التهيئة في dart-define، لكن التبعيات الأصلية لا تزال تتطلب إعداد Podfile/build.gradle.

التجميع الشرطي في إدارة التهيئة

التجميع الشرطي — تضمين أو استبعاد الكود في مرحلة التجميع اعتمادًا على الأعلام. هذا جزء من إدارة التهيئة: يسمح بدمج أدوات التصحيح (التسجيل، المفتش) في بنيات debug وإزالتها من release. يختلف التنفيذ عبر المنصات.

التجميع الشرطي في Swift

#if DEBUG — توجيه معالج مسبق في Swift. الكود داخل الكتلة يتم تجميعه فقط في تهيئة Debug. أعلام أخرى: #if !RELEASE، #if targetEnvironment(simulator). Active Compilation Conditions في Build Settings — أضف أعلامك المخصصة عبر -D FLAG_NAME. إدارة تهيئة البناء من خلال شروط التجميع هي ممارسة قياسية في iOS.

التجميع الشرطي في Kotlin

BuildConfig.DEBUG — حقل منطقي، true في بناء debug. يتم إنشاء BuildConfig تلقائيًا بواسطة Gradle. للأعلام المخصصة استخدم buildConfigField في build.gradle: buildConfigField "boolean"، "REPORT_CRASHES"، "true". في الكود: if (BuildConfig.REPORT_CRASHES) { ... }.

التجميع الشرطي في Flutter

dart-define — أعلام تجميع Flutter: flutter run --dart-define=ENV=staging. في الكود: const env = String.fromEnvironment('ENV', defaultValue: 'production'). للتجميع الشرطي للتطبيقات المحمولة، استخدم إضافة build_runner مع توليد الكود.