محتويات الدورة

تطوير Android / المتقدم: أنظمة محمولة وإصدارات موثوقة / الدرس 18

هندسة الإصدار وقابلية الرصد

جهّز إصداراً قابلاً للتكرار وراقب نتائج المستخدم بإشارات تراعي الخصوصية وخطة استجابة ملموسة.

وقت القراءة التقريبي: 4 دقيقةتاريخ مراجعة المحتوى
في هذه الصفحة

أهداف الدرس

  • اشرح التوقيع والترقيم والتقليص والتحقق من الإصدار.
  • صمّم إشارات تشغيل تربط الإخفاق بأثره على المستخدم.

اجعل حزمة الإصدار قابلة لإعادة البناء

الإصدار مراجعة مصدر وأدوات واعتماديات وإعداد وحزمة موقعة محددة. سجل المدخلات وافصل نقاط التنقيح وتشخيصه عن سلوك الإصدار. يرتب versionCode التحديثات، أما versionName فعنوان للمستخدم لا يعوض ترتيبها. احفظ هوية التطبيق ثابتة. تحدد هوية التوقيع قدرة التحديث على استبدال المثبت، لذا لفقد المفاتيح أو تغييرها آثار تتجاوز البناء. استخدم سير توقيع التوزيع المدعوم واحمِ اعتمادات الرفع خارج المستودع بوصول CI مضبوط.

تحقق من المتغير المحسن

قد يزيل تقليص الشيفرة ما لا يمكن الوصول إليه ويعيد تسمية الرموز، ويزيل تقليص الموارد غير المستخدم. قد يحتاج الانعكاس والتسلسل وJNI والموارد المشار إليها ديناميكياً قواعد حفظ دقيقة أو تكاملاً مدعوماً. تجنب قاعدة حفظ الجميع التي تخفي المشكلة وتبطل التحسين. اختبر متغيراً قريباً من الإصدار لأن نجاح التنقيح لا يكشف كل عيوب التقليص. احتفظ بخرائط الرموز والرموز الأصلية مع الحزمة المحددة لتفسير آثار الإنتاج لاحقاً. هي أدلة تشغيلية تخضع لسياسة وصول واحتفاظ.

kotlin صياغة تحسين قديمة مدعومة في وحدة التطبيق
android {
    buildTypes {
        getByName("release") {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

ادمج الصياغة القديمة المدعومة داخل app/build.gradle.kts بإضافة Android Gradle متوافقة. توفر AGP 9.3+ أيضاً optimization { enable = true } مع مجلدات keepRules الموثقة؛ اتبع الصياغة التي اختارها المشروع. يجب وجود ملف القواعد المحلي. تبقى أسرار التوقيع خارج المقتطف ولا يثبت التقليص وحده جاهزية الإصدار.

تحقق من الرحلات المعرضة للتراجع

نفذ فحوص الوحدة والتكامل والواجهة والترحيل ومتغير الإصدار المناسبة، ثم افحص manifest المدمج وسياسة الشبكة والمكونات المتاحة والأذونات والنسخ. جرّب تثبيتاً جديداً وترقية من إصدار سابق مدعوم. ضمّن تبديل الحساب والرفض والعمل المعلق دون اتصال والاستعادة والتخطيط العربي وتكبير الخط. تتغير متطلبات API الاستهداف وسياسات المتجر، فتحقق منها مباشرة قبل التوزيع بدلاً من تضمين مطلب مزعوم أحدث في دورة طويلة العمر. جاهزية الإصدار أدلة عن الحزمة وبيئاتها المدعومة.

قِس النتائج دون حمولات خاصة

تصف التعطلات وANR وتأخير البدء والإطارات وعمر الطابور وفشل المزامنة واحتكاك الأذونات جوانب مختلفة للتجربة. يوفر Android vitals إشارات جودة منصية وتوزيعية حيث تتوفر، وتضيف قياسات التطبيق سياق المجال. عرّف مخططات أحداث بفئات محدودة ومعرّفات معتمة بدلاً من العناوين والملاحظات والرموز والروابط الكاملة. سجل الإصدار وأبعاد البيئة المناسبة لتجميع التراجعات. يحتاج المقياس مقاماً وشرح عينة؛ تختلف عشرة إخفاقات بين عشر عمليات عنها بين مليون.

kotlin عقد قياسات محدود بلا محتوى مستخدم
enum class SyncResultCode { SUCCESS, TEMPORARY_FAILURE, CONFLICT, AUTH_REQUIRED }
data class SyncMetric(
    val result: SyncResultCode,
    val durationMs: Long,
    val pendingCount: Int
)
interface MetricsSink { fun record(metric: SyncMetric) }

fun reportSync(sink: MetricsSink, result: SyncResultCode, elapsedMs: Long, pending: Int) {
    require(elapsedMs >= 0 && pending >= 0)
    sink.record(SyncMetric(result, elapsedMs, pending))
}

قِس المدد بساعة رتيبة ونفذ MetricsSink بسياسات الموافقة والعينة والاحتفاظ والنقل المناسبة. يستبعد النموذج نص السجل والاعتمادات قصداً. تحقق من الأعداد الكبيرة أو غير المتوقعة قبل استخدامها كعناوين كثيرة القيم.

استعد للاستجابة للأدلة

يحد الطرح التدريجي الانكشاف الأولي بينما يفحص الفريق إشارات الجودة المتفق عليها. حدد معايير الإيقاف والمالكين وخطة التعافي قبل النشر. لا يعني التراجع دائماً تثبيت versionCode أقدم، وقد يمنع ترحيل القاعدة الرجوع الثنائي البسيط. فضّل إصلاحاً أمامياً محضراً أو تعطيل ميزة مضبوطاً عند الملاءمة. تحقق من عمل القياسات في إعداد الإصدار ومن إمكان تفسير التعطل بالخرائط المحفوظة. أغلق الدورة بتحويل التراجع الملاحظ إلى اختبار قابل للتكرار وفحص إصدار محسن.

الأخطاء الشائعة وإصلاحها

يتعطل متغير الإصدار وحده

لماذا يحدث؟
أزال التقليص شيفرة ديناميكية أو اختلف الإعداد.
كيف تصلحه؟
أعد الإنتاج بالحزمة المحسنة وأضف قواعد دقيقة مدعومة.
كيف تتجنب تكراره؟
ضمّن رحلات فحص متغير الإصدار في التحقق.

يتعذر تفسير آثار التعطل

لماذا يحدث؟
لا تطابق الخرائط الحزمة الموزعة.
كيف تصلحه؟
استرجع واربط خريطة الإصدار المحدد أو رموزه.
كيف تتجنب تكراره؟
أرشف الأدلة مع هوية الحزمة أثناء CI.

يعجز التراجع عن فتح القاعدة المرقاة

لماذا يحدث؟
خُطط لتراجع ثنائي دون توافق المخطط.
كيف تصلحه؟
استخدم تعافياً أمامياً مراجعاً أو مساراً متوافقاً.
كيف تتجنب تكراره؟
صمّم الترحيل وتعافي الطرح معاً.

اختبر فهمك

1. تنجح اختبارات التنقيح ويفشل التسلسل بعد التقليص. حدد تحقيقاً وتحققاً مفيدين محدودين.

اعرض الحل المشروح

أعد مسار التسلسل الفاشل في المتغير المحسن وافحص تكامل التقليص الرسمي للمكتبة وأضف الضبط المحدود اللازم. أعد المسار وفحصي الترقية والبدء. تجنب حفظ التطبيق كله كاستجابة أولى لأنه يحجب العقد المفقود.

2. تبلغ لوحة عشرين فشل مزامنة بعد إصدار. ما الأدلة اللازمة قبل وقف الطرح؟

اعرض الحل المشروح

افحص مجموع العمليات والمستخدمين المتأثرين والفئات وعمر الطابور وفئة الإصدار والتعافي. قارن الخط الأساس السابق بظروف مشابهة وافحص آثاراً ممثلة محجوبة. استخدم حدود الأثر ومخاطر سلامة البيانات المحددة مسبقاً لا عدداً خاماً بلا سياق.

أهم ما تعلمته

  • يتعلق تحقق الإصدار بالحزمة المحسنة المحددة.
  • يربط الرصد الإخفاقات التقنية بأثر المستخدم.
  • يشمل تخطيط التعافي توافق المخطط والأدلة المحفوظة.

المراجع الرسمية