جودة الخدمة

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

درجة الأهمية

بالنسبة إلى نظام التشغيل Android 11 أو الإصدارات الأحدث، يتم إعداد الطُرز بأولوية في NN HAL 1.3. ترتبط هذه الأولوية بالنماذج الأخرى المعدّة التي يمتلكها التطبيق نفسه. يمكن أن تستهلك عمليات التنفيذ ذات الأولوية الأعلى موارد حوسبة أكبر من عمليات التنفيذ الأقل أولوية، ويمكن أن تؤدي إلى إيقاف عمليات التنفيذ ذات الأولوية المنخفضة أو استبعادها.

استدعاء NN HAL 1.3 الذي يتضمن Priority كوسيطة صريحة هو IDevice::prepareModel_1_3. يُرجى العِلم أنّ IDevice::prepareModelFromCache_1_3 تتضمّن ضمنًا Priority في وسيطات ذاكرة التخزين المؤقت.

وهناك العديد من الاستراتيجيات الممكنة لدعم الأولويات وذلك حسب قدرات السائق ومسرِّعة السرعة. إليك عدة استراتيجيات:

  • بالنسبة إلى السائقين الذين لديهم دعم أولوية مدمج، انشر الحقل Priority مباشرةً في مسرِّعة الأعمال.
  • يمكنك استخدام قائمة انتظار أولوية لكل تطبيق لدعم الأولويات المختلفة حتى قبل أن تصل عملية التنفيذ إلى مسرِّعة الأعمال.

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

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

يتيح Android للخدمات التفريق بين تطبيقات الاتصال المختلفة من خلال استخدام AID (معرّف Android الفريد). يحتوي HIDL على آليات مضمَّنة لاسترداد المعرِّف الفريد لتطبيق الاتصال من خلال الطريقة ::android::hardware::IPCThreadState::getCallingUid. يمكن الاطّلاع على قائمة بأنواع الإيدز في libcutils/include/cutils/android_filesystem_config.h.

المواعيد النهائية

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

في ما يلي استدعاءات NN HAL 1.3 التي تتضمن مواعيد OptionalTimePoint النهائية كوسيطة:

  • IDevice::prepareModel_1_3
  • IDevice::prepareModelFromCache_1_3
  • IPreparedModel::execute_1_3
  • IPreparedModel::executeSynchronously_1_3
  • IPreparedModel::executeFenced

للاطّلاع على التنفيذ المرجعي لميزة الموعد النهائي لكل طريقة من الطرق المذكورة أعلاه، يُرجى الاطّلاع على نموذج برنامج التشغيل NNAPI على frameworks/ml/nn/driver/sample/SampleDriver.cpp.

رموز الخطأ

يتضمّن Android 11 أربع قيم لرموز الخطأ في NN HAL 1.3 لتحسين عملية الإبلاغ عن الأخطاء، ما يتيح للسائقين إبلاغ حالتهم وتطبيقاتهم بشكل أفضل باسترداد البيانات بشكل أكثر سلاسة. هذه هي قيم رموز الخطأ في ErrorStatus.

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

في نظام التشغيل Android 10 أو الإصدارات الأقدم، لا يمكن أن يشير برنامج التشغيل إلا إلى عطل في نظام التشغيل Android من خلال رمز الخطأ GENERAL_FAILURE. بدءًا من الإصدار Android 11، يمكن استخدام رمزَي الخطأ "MISSED_DEADLINE" للإشارة إلى إلغاء أعباء العمل بسبب انقضاء الموعد النهائي أو توقُّع عدم اكتمال أعباء العمل بحلول الموعد النهائي. يمكن استخدام رمزَي الخطأ RESOURCE_EXHAUSTED للإشارة إلى تعذُّر المَهمّة بسبب محدودية الموارد في برنامج التشغيل، مثلاً إذا كان السائق لا يملك ذاكرة كافية لإجراء المكالمة.

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

التحقُّق

يتم اختبار جودة وظيفة الخدمة من خلال اختبارات NNAPI VTS (VtsHalNeuralnetworksV1_3Target). يشمل ذلك مجموعة من الاختبارات للتحقّق من الصحة (TestGenerated/ValidationTest#Test/) للتأكّد من أنّ السائق يرفض الأولويات غير الصالحة وإجراء مجموعة من الاختبارات باسم DeadlineTest (TestGenerated/DeadlineTest#Test/) لضمان معالجة السائق للمواعيد النهائية بشكل صحيح.