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

هل استخدمت Google تحديثات عبر الهواء (OTA) من النوع A/B على أي أجهزة؟

نعم. الاسم التسويقي لتحديثات الإصدار التجريبي هو التحديثات بدون التوقّف عن استخدام الهاتف. تم شحن هواتف Pixel وPixel XL التي تم طرحها في تشرين الأول (أكتوبر) 2016 مع نظام A/B، وتستخدم جميع أجهزة Chromebook التنفيذ نفسه لنظام A/B.update_engine إنّ عملية تنفيذ رمز النظام الأساسي اللازم متاحة للجميع في الإصدار 7.1 من نظام Android والإصدارات الأحدث.

لماذا تكون منصات الحجز الإلكترونية التي تجري اختبارات A/B أفضل؟

توفّر تحديثات عبر الهواء (OTA) من النوع A/B تجربة أفضل للمستخدم عند تثبيت التحديثات.  وقد أثبتت هذه الميزة نجاحها من خلال القياسات التي تم إجراؤها على تحديثات الأمان الشهرية: فاعتبارًا من أيار (مايو) 2017، كان% 95 من مالكي هواتف Pixel يستخدمون آخر تحديث أمان بعد شهر واحد، مقارنةً بنسبة% 87 من مستخدمي Nexus، كما أنّ مستخدمي Pixel يثبّتون التحديثات بشكل أسرع من مستخدمي Nexus. لم يعُد تعذُّر تثبيت التحديثات أثناء التحديث عبر الأثير يؤدي إلى عدم إمكانية تشغيل الجهاز، بل يحتفظ Android بإمكانية الرجوع إلى صورة النظام السابقة التي كانت تعمل إلى أن يتم تشغيل صورة النظام الجديدة بنجاح.

ما هو system_other؟

يتم تخزين التطبيقات في ملفات ‎ .apk، وهي في الواقع أرشيفات ZIP. يحتوي كل ملف ‎ .apk على ملف واحد أو أكثر من ملفات ‎ .dex التي تتضمّن رمز Dalvik البايت المحمول. يتم تخزين ملف ‎ .odex (ملف ‎.dex محسّن) بشكل منفصل عن ملف ‎ .apk ويمكن أن يحتوي على لغة الآلة الخاصة بالجهاز. إذا كان ملف .odex متاحًا، يمكن لنظام التشغيل Android تشغيل التطبيقات بسرعات ترجمة مسبقة بدون الحاجة إلى انتظار ترجمة الرمز في كل مرة يتم فيها تشغيل التطبيق. ملف ‎.odex ليس ضروريًا تمامًا، إذ يمكن لنظام التشغيل Android تشغيل شفرة ‎ .dex مباشرةً من خلال التفسير أو الترجمة الفورية (JIT)، ولكن يوفّر ملف ‎ .odex أفضل مزيج من سرعة التشغيل وسرعة وقت التشغيل إذا كانت المساحة متوفرة.

مثال: بالنسبة إلى ملف installed-files.txt من جهاز Nexus 6P يعمل بالإصدار 7.1 من نظام التشغيل Android ويبلغ إجمالي حجم صورة النظام 2628 ميغابايت (2755792836 بايت)، يكون تفصيل أكبر المساهمين في إجمالي حجم صورة النظام حسب نوع الملف على النحو التالي:

‎.odex	‫1391770312 بايت	50.5%
‎.apk	‫846878259 بايت	‫30.7%
‎.so (رموز C/C++‎ البرمجية الأصلية)	‫202162479 بايت	‫7.3%
ملفات ‎.oat/صور ‎.art	‫163892188 بايت	‫5.9%
الخطوط	‫38952361 بايت	1.4%
بيانات اللغة في ICU	‫27468687 بايت	‫0.9%

وتتشابه هذه الأرقام مع الأجهزة الأخرى أيضًا، لذا تشغل ملفات .odex على أجهزة Nexus/Pixel نصف مساحة قسم النظام تقريبًا. وهذا يعني أنّه يمكننا مواصلة استخدام نظام الملفات ext4 ولكن كتابة ملفات .odex في القسم B في المصنع ثم نسخها إلى /data عند التشغيل الأول. إنّ مساحة التخزين الفعلية المستخدَمة مع نظام التشغيل ext4 A/B هي نفسها المستخدَمة مع نظام التشغيل SquashFS A/B، لأنّه في حال استخدام SquashFS، كنا سنرسل ملفات .odex المُحسَّنة مسبقًا على system_a بدلاً من system_b.

ألا يعني نسخ ملفات .odex إلى /data فقدان المساحة المحفوظة في /system على /data؟

إجابتك غير صحيحة. على هواتف Pixel، يتم استخدام معظم المساحة التي تشغلها ملفات ‎ .odex للتطبيقات التي تكون عادةً على /data. تتلقّى هذه التطبيقات تحديثات Google Play، لذا لا يتم استخدام ملفات ‎ .apk و‎ .odex في صورة النظام خلال معظم فترة استخدام الجهاز. ويمكن استبعاد هذه الملفات بالكامل واستبدالها بملفات .odex صغيرة مستندة إلى الملف الشخصي عندما يستخدم المستخدم كل تطبيق فعليًا (وبالتالي لا تتطلّب مساحة للتطبيقات التي لا يستخدمها المستخدم). لمزيد من التفاصيل، يُرجى الاطّلاع على محاضرة تطوّر الفن التي أُلقيت في مؤتمر Google I/O لعام 2016.

يصعب إجراء المقارنة لعدة أسباب رئيسية:

• لطالما كانت ملفات .odex للتطبيقات التي يحدّثها Google Play متاحة على /data فور تلقّي أول تحديث.
• لا تحتاج التطبيقات التي لا يشغّلها المستخدم إلى ملف ‎ .odex على الإطلاق.
• تنتج عملية التجميع المستندة إلى الملف الشخصي ملفات ‎ .odex أصغر حجمًا من عملية التجميع مسبقًا (لأنّ العملية الأولى تعمل على تحسين الرموز البرمجية المهمة للأداء فقط).

للحصول على تفاصيل حول خيارات الضبط المتاحة لمصنّعي المعدات الأصلية، يُرجى الاطّلاع على ضبط ART.

أليس هناك نسختان من ملفات .odex في /data؟

الأمر أكثر تعقيدًا بعض الشيء ... بعد كتابة صورة النظام الجديدة، يتم تشغيل الإصدار الجديد من dex2oat على ملفات .dex الجديدة لإنشاء ملفات .odex الجديدة. يحدث ذلك أثناء تشغيل النظام القديم، لذا يكون ملفا .odex القديم والجديد متاحَين على /data في الوقت نفسه.

يستدعي الرمز البرمجي في OtaDexoptService (frameworks/base/+/android17-release/services/core/java/com/android/server/pm/OtaDexoptService.java) الدالة getAvailableSpace قبل تحسين كل حزمة لتجنُّب التعبئة الزائدة /data. يُرجى العِلم أنّ المساحة المتاحة هنا لا تزال محدودة: وهي مقدار المساحة المتبقية قبل بلوغ الحدّ الأدنى المعتاد لمساحة التخزين في النظام (يتم قياسها كنسبة مئوية وعدد وحدات بايت). لذلك، إذا كانت مساحة /data ممتلئة، لن يكون هناك نسختان من كل ملف .odex. يتضمّن الرمز نفسه أيضًا BULK_DELETE_THRESHOLD: إذا كان الجهاز على وشك ملء المساحة المتوفّرة (كما هو موضّح أعلاه)، تتم إزالة ملفات .odex الخاصة بالتطبيقات غير المستخدَمة. هذه حالة أخرى لا تتضمّن نسختَين من كل ملف .odex.

في أسوأ الحالات التي تكون فيها /data ممتلئة تمامًا، ينتظر التحديث إلى أن تتم إعادة تشغيل الجهاز في النظام الجديد ولا يعود بحاجة إلى ملفات .odex الخاصة بالنظام القديم. يتولّى PackageManager تنفيذ ذلك (frameworks/base/+/android17-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215). وبعد تشغيل النظام الجديد بنجاح، يمكن أن يزيل installd (frameworks/native/+/android17-release/cmds/installd/dexopt.cpp#2422) ملفات .odex التي كان يستخدمها النظام القديم، ما يؤدي إلى إعادة الجهاز إلى الحالة الثابتة التي تتضمّن نسخة واحدة فقط.

لذا، على الرغم من أنّه من المحتمل أن يحتوي /data على نسختَين من جميع ملفات .odex، (أ) هذا الإجراء مؤقت و (ب) لا يحدث إلا إذا كانت لديك مساحة خالية كبيرة على /data على أي حال. باستثناء أثناء التحديث، لا تتوفّر سوى نسخة واحدة. وكجزء من ميزات الثبات العامة في ART، لن يتم ملء /data بملفات .odex على أي حال (لأنّ ذلك سيشكّل مشكلة أيضًا في نظام غير A/B).

ألا تؤدي كل عمليات الكتابة والنسخ هذه إلى زيادة تآكل ذاكرة الفلاش؟

لا تتم إعادة كتابة سوى جزء صغير من الذاكرة المؤقتة: يكتب تحديث نظام Pixel الكامل حوالي 2.3 غيغابايت. (يتم أيضًا إعادة تجميع التطبيقات، ولكن ينطبق ذلك أيضًا على الإصدارات غير التجريبية). في السابق، كانت عمليات OTA الكاملة المستندة إلى الحظر تكتب مقدارًا مشابهًا من البيانات، لذا يجب أن تكون معدلات استهلاك الذاكرة مشابهة.

هل يؤدي وميض قسمَي نظام إلى زيادة وقت وميض المصنع؟

لا، لم يزد حجم صورة النظام في Pixel (بل تم تقسيم المساحة على قسمَين).

ألا يؤدي الاحتفاظ بملفات .odex على القسم B إلى إبطاء عملية إعادة التشغيل بعد إعادة الضبط على الإعدادات الأصلية؟

نعم. إذا كنت قد استخدمت جهازًا، ونزّلت تحديثًا عبر الأثير، وأعدت ضبط الجهاز على الإعدادات الأصلية، ستكون عملية إعادة التشغيل الأولى أبطأ من المعتاد (دقيقة و40 ثانية مقابل 40 ثانية على هاتف Pixel XL) لأنّه سيتم فقدان ملفات .odex من القسم B بعد التحديث الأول عبر الأثير، وبالتالي لا يمكن نسخها إلى القسم /data. هذا هو المقابل.

يجب أن تكون عملية إعادة الضبط على الإعدادات الأصلية عملية نادرة مقارنةً بعملية إعادة التشغيل العادية، وبالتالي فإنّ الوقت المستغرَق أقل أهمية. (لا يؤثّر ذلك في المستخدمين أو المراجعين الذين يحصلون على أجهزتهم من المصنع، لأنّ القسم B يكون متاحًا في هذه الحالة). يعني استخدام برنامج الترجمة الفورية أنّنا لسنا بحاجة إلى إعادة ترجمة كل شيء، لذا فإنّ الأمر ليس سيئًا كما قد تتوقّع. يمكن أيضًا وضع علامة على التطبيقات للإشارة إلى أنّها تتطلّب الترجمة المسبقة باستخدام coreApp="true" في ملف البيان (frameworks/base/+/android17-release/packages/SystemUI/AndroidManifest.xml#23). ويتم حاليًا استخدام هذه العلامة في system_server لأنّه لا يُسمح بالترجمة في الوقت الفعلي لأسباب تتعلّق بالأمان.

ألا يؤدي الاحتفاظ بملفات .odex في /data بدلاً من /system إلى إبطاء عملية إعادة التشغيل بعد التحديث عبر الهواء؟

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

هل يمكننا (هل يجب) شحن جهاز A/B بسعة 32 غيغابايت؟ ‫16 غيبيبايت؟ ‫8 غيغابايت؟

يعمل حجم 32 غيغابايت بشكل جيد كما تم إثباته على هواتف Pixel، ويعني حجم 320 ميغابايت من 16 غيغابايت انخفاضًا بنسبة %2. وبالمثل، فإنّ 320 ميغابايت من 8 غيغابايت تمثّل انخفاضًا بنسبة %4. من الواضح أنّ تقسيم A/B ليس الخيار الأفضل للأجهزة التي تتضمّن 4 غيغابايت، لأنّ مساحة 320 ميغابايت الإضافية تشكّل% 10 تقريبًا من إجمالي المساحة المتاحة.

هل يتطلّب AVB2.0 تحديثات عبر الأثير بنظام التشغيل A/B؟

لا، لأنّ ميزة التشغيل المتحقّق منه في Android تتطلّب دائمًا إجراء تحديثات مستندة إلى الحِزم، ولكن ليس بالضرورة تحديثات A/B.

هل تتطلّب تحديثات OTA التي يتم إجراؤها باستخدام اختبار أ/ب توفُّر AVB2.0؟

لا.

هل تؤدي تحديثات A/B OTA إلى إيقاف ميزة "الحماية من العودة إلى الحالة السابقة" في AVB 2.0؟

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

إذا كنت تثبّت تحديثًا أثناء تشغيل النظام، ألن يكون ذلك بطيئًا؟

في التحديثات غير المتوافقة مع A/B، يكون الهدف هو تثبيت التحديث بأسرع ما يمكن لأنّ المستخدم ينتظر ولا يمكنه استخدام الجهاز أثناء تطبيق التحديث. في المقابل، عند إجراء تحديثات A/B، يكون الهدف هو تقليل التأثير إلى أدنى حد ممكن لأنّ المستخدم يواصل استخدام جهازه، لذا يتم إجراء التحديث ببطء عمدًا. من خلال منطق في برنامج Java لتحديث النظام (وهو GmsCore بالنسبة إلى Google، أي الحزمة الأساسية التي توفّرها خدمات Google للأجهزة الجوّالة)، يحاول نظام Android أيضًا اختيار وقت لا يستخدم فيه المستخدمون أجهزتهم على الإطلاق. تتيح المنصة إمكانية إيقاف التحديث مؤقتًا واستئنافه، ويمكن للعميل استخدام هذه الميزة لإيقاف التحديث مؤقتًا إذا بدأ المستخدم في استخدام الجهاز واستئنافه عندما يكون الجهاز غير نشط مرة أخرى.

تتضمّن عملية تثبيت تحديث عبر الأثير مرحلتَين، ويتم عرض ذلك بوضوح في واجهة المستخدم على النحو التالي: الخطوة 1 من 2 والخطوة 2 من 2 ضمن شريط التقدّم. تتطابق الخطوة 1 مع كتابة كتل البيانات، بينما تتطابق الخطوة 2 مع عملية التجميع المُسبَق لملفات .dex. تختلف هاتان المرحلتان تمامًا من حيث تأثيرهما في الأداء. المرحلة الأولى هي الإدخال/الإخراج البسيط. لا يتطلّب ذلك الكثير من الموارد (ذاكرة الوصول العشوائي ووحدة المعالجة المركزية والإدخال/الإخراج) لأنّه ينسخ الوحدات ببطء.

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

وتشبه هذه العملية ما يحدث عندما يثبّت Google Play تحديثًا لتطبيق في الخلفية قبل عرض الإشعار تم تحديث 5 تطبيقات، كما كان يحدث منذ سنوات.

ماذا لو كان المستخدم ينتظر التحديث؟

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

ماذا يحدث إذا تعذّر تطبيق تحديث؟

في حال عدم توفّر تحديثات A/B، إذا تعذّر تطبيق أحد التحديثات، كان الجهاز يصبح غير قابل للاستخدام. الاستثناء الوحيد هو إذا حدث الخطأ قبل بدء تشغيل أي تطبيق (لأنّه تعذّر التحقّق من الحزمة، مثلاً). باستخدام تحديثات A/B، لا يؤثّر تعذُّر تطبيق تحديث في النظام الذي يتم تشغيله حاليًا. يمكنك ببساطة إعادة محاولة التحديث لاحقًا.