بدءًا من Android 11، توفّر واجهة برمجة التطبيقات NNAPI جودة خدمة أفضل من خلال السماح لأحد التطبيقات بتحديد الأولويات النسبية لنماذجه، والحد الأقصى للوقت المتوقّع لإعداد نموذج معيّن، والحد الأقصى للوقت المتوقّع لإكمال عملية تنفيذ معيّنة. بالإضافة إلى ذلك، يقدّم نظام التشغيل 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 (معرّف UID لنظام Android). يحتوي HIDL على آليات مدمجة لاسترداد معرّف UID للتطبيق الذي يجري الاتصال من خلال الطريقة ::android::hardware::IPCThreadState::getCallingUid
. يمكن العثور على قائمة بمعرّفات AID في 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
في الإصدار 10 من نظام التشغيل Android أو الإصدارات الأقدم، كان بإمكان برنامج التشغيل الإشارة إلى حدوث خطأ من خلال رمز الخطأ GENERAL_FAILURE
فقط. بدءًا من Android 11، يمكن استخدام رمزي الخطأ MISSED_DEADLINE
للإشارة إلى أنّه تم إيقاف وحدة العمل لأنّه تم بلوغ الموعد النهائي أو لأنّ برنامج التشغيل توقّع عدم اكتمال وحدة العمل بحلول الموعد النهائي. يمكن استخدام رمزي الخطأ RESOURCE_EXHAUSTED
للإشارة إلى أنّ المهمة تعذّر تنفيذها بسبب قيود على الموارد في برنامج التشغيل، مثل عدم توفّر مساحة ذاكرة كافية في برنامج التشغيل للمكالمة.
يشير الإصدار TRANSIENT
من كلا الخطأين إلى أنّ المشكلة مؤقتة،
وأنّ عمليات طلب تنفيذ المهمة نفسها في المستقبل قد تنجح بعد تأخير قصير. على سبيل المثال، يجب عرض رمز الخطأ هذا عندما يكون برنامج التشغيل مشغولاً بعمل سابق طويل الأمد أو يتطلّب موارد كثيرة، ولكن سيتم إكمال المهمة الجديدة بنجاح إذا لم يكن برنامج التشغيل مشغولاً بالعمل السابق. يشير PERSISTENT
إصدار كلا الخطأين إلى أنّه من المتوقّع دائمًا أن تفشل الطلبات المستقبلية إلى المهمة نفسها. على سبيل المثال، يجب عرض رمز الخطأ هذا عندما يقدّر برنامج التشغيل أنّ المهمة لن تكتمل بحلول الموعد النهائي حتى في ظل الظروف المثالية، أو عندما يكون النموذج كبيرًا جدًا بطبيعته ويتجاوز موارد برنامج التشغيل.
التحقُّق
يتم اختبار وظيفة جودة الخدمة في اختبارات VTS الخاصة بواجهة برمجة التطبيقات NNAPI
(VtsHalNeuralnetworksV1_3Target
)، ويشمل ذلك مجموعة من الاختبارات للتحقّق
(TestGenerated/ValidationTest#Test/
) من أنّ برنامج التشغيل يرفض الأولويات غير الصالحة، ومجموعة من الاختبارات تُعرف باسم DeadlineTest
(TestGenerated/DeadlineTest#Test/
) للتأكّد من أنّ برنامج التشغيل يتعامل مع المواعيد النهائية بشكل صحيح.