جودة الخدمة

بدءًا من 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 للخدمات التمييز بين التطبيقات المختلفة التي تتصل بها من خلال استخدام معرّف UID (معرّف مستخدم Android). تتضمّن HIDL آليات مدمجة لاسترداد معرّف UID للتطبيق الذي يتصل بها من خلال الطريقة ::android::hardware::IPCThreadState::getCallingUid. يمكن العثور على قائمة بمعرّفات UID في 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 أو الإصدارات الأقدم، كان بإمكان برنامج التشغيل الإشارة إلى حدوث خطأ فقط من خلال رمز الخطأ GENERAL_FAILURE. بدءًا من Android 11، يمكن استخدام رمزَي الخطأ MISSED_DEADLINE للإشارة إلى أنّه تم إيقاف وحدة العمل لأنّه تم بلوغ المهلة أو لأنّ برنامج التشغيل توقّع أنّه لن يتم إكمال وحدة العمل بحلول المهلة. يمكن استخدام رمزَي الخطأ RESOURCE_EXHAUSTED للإشارة إلى أنّ المهمة قد فشلت بسبب قيود على الموارد داخل برنامج التشغيل، مثل عدم توفّر ذاكرة كافية لبرنامج التشغيل لإجراء الطلب.

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

التحقق من صحة البيانات

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