کیفیت خدمات

از 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 (شناسه Android) بین برنامه‌های تماس مختلف تمایز قائل شوند. ‫HIDL دارای سازوکارهای داخلی برای بازیابی UID برنامه تماس‌گیرنده ازطریق روش ::android::hardware::IPCThreadState::getCallingUid است. فهرست AIDs را می‌توانید در 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 هر دو خطا نشان می‌دهد که تماس‌های آینده با همان تکلیف همیشه انتظار می‌رود ناموفق باشد. برای مثال، این کد خطا باید زمانی برگردانده شود که گرداننده تخمین بزند که تکلیف حتی در شرایط ایده‌آل هم تا مهلت مقرر تکمیل نخواهد شد، یا اینکه مدل ذاتاً خیلی بزرگ است و از منابع گرداننده فراتر می‌رود.

اعتبارسنجی

عملکرد کیفیت خدمات در آزمایش‌های NNAPI VTS (VtsHalNeuralnetworksV1_3Target) آزمایش می‌شود. این شامل مجموعه‌ای از آزمایش‌ها برای اعتبارسنجی (TestGenerated/ValidationTest#Test/) است تا اطمینان حاصل شود که درایور اولویت‌های نامعتبر را رد می‌کند و مجموعه‌ای از آزمایش‌ها به نام DeadlineTest (TestGenerated/DeadlineTest#Test/) است تا اطمینان حاصل شود که درایور مهلت‌ها را به‌درستی مدیریت می‌کند.