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

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

نعم. الاسم التسويقي لتحديثات 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. لم يعُد تعذُّر تحديث الحِزم أثناء التحديث عبر الأثير (OTA) يؤدي إلى عدم إمكانية تشغيل الجهاز، بل يحتفظ نظام 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/+/android16-qpr1-release/services/core/java/com/android/server/pm/OtaDexoptService.java) الدالة getAvailableSpace قبل تحسين كل حزمة لتجنُّب التعبئة الزائدة /data. يُرجى العِلم أنّ قيمة المساحة المتاحة هنا لا تزال تقديرًا متحفّظًا، فهي تمثّل مقدار المساحة المتبقية قبل بلوغ الحدّ الأدنى المعتاد لمساحة التخزين في النظام (يتم قياسها كنسبة مئوية وعدد وحدات بايت). لذلك، إذا كانت مساحة التخزين /data ممتلئة، لن يكون هناك نسختان من كل ملف .odex. يتضمّن الرمز نفسه أيضًا BULK_DELETE_THRESHOLD: إذا اقترب الجهاز من ملء المساحة المتاحة (كما هو موضح أعلاه)، تتم إزالة ملفات .odex الخاصة بالتطبيقات غير المستخدَمة. هذه حالة أخرى لا تتضمّن نسختَين من كل ملف .odex.

في أسوأ الحالات التي تكون فيها /data ممتلئة تمامًا، ينتظر التحديث إلى أن تتم إعادة تشغيل الجهاز في النظام الجديد ولا يعود بحاجة إلى ملفات .odex الخاصة بالنظام القديم. يتولّى PackageManager تنفيذ ذلك (frameworks/base/+/android16-qpr1-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215). وبعد تشغيل النظام الجديد بنجاح، يمكن أن يزيل installd (frameworks/native/+/android16-qpr1-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/+/android16-qpr1-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 تقريبًا من إجمالي المساحة المتاحة.

هل يتطلّب الإصدار 2.0 من AVB تحديثات عبر الهواء من النوع A/B؟

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

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

لا.

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

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

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

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

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

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

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

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

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

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

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