اقتراح تصميم إمكانية العرض في وقت تشغيل حزمة تطوير البرامج (SDK)

لا يمكن لحِزم SDK لعرض الإعلانات في "وقت تشغيل حِزم تطوير البرامج (SDK)" الوصول إلى التسلسل الهرمي لعرض الناشر. بدلاً من ذلك، تتضمّن حِزم تطوير البرامج (SDK) في "وقت التشغيل" طرق عرض خاصة بها. لا يمكن لحزمة SDK استخدام واجهات برمجة التطبيقات View نفسها التي تستخدمها خارج وقت تشغيل حزمة SDK لتحديد ما إذا كان الإعلان مرئيًا للمستخدم، لأنّ عرض الإعلان غير مرفق بأحد نوافذ التطبيق. ويشمل ذلك واجهات برمجة تطبيقات View في Android، مثل getLocationOnScreen أو getLocationInWindow أو getVisibility، التي لا تعرض القيمة المتوقّعة.

إنّ إتاحة قياس إمكانية عرض الإعلانات هو أحد المتطلبات الأساسية لوقت تشغيل حزمة SDK. يهدف اقتراح التصميم هذا إلى توفير إمكانية استخدام قياس المفتوح وخدمات القياس المشابهة. قد تنطبق أيضًا الحلول الموضّحة هنا على واجهات برمجة التطبيقات Attribution Reporting API.

الإمكانات

يهدف هذا التصميم إلى إتاحة حِزم تطوير البرامج (SDK) للإعلانات أو شركاء القياس لاحتساب بيانات إمكانية العرض التالية (الأسماء مؤقتة وقابلة للتغيير):

رسم توضيحي يعرض كيفية تفاعل مكوّنات إمكانية العرض في "وقت تشغيل حزمة تطوير البرامج (SDK)"
نظرة عامة على إمكانية عرض وقت تشغيل حزمة تطوير البرامج (SDK)
  • ‫viewport [Rect]: يمثّل هندسة شاشة الجهاز أو نافذة التطبيق، استنادًا إلى إمكانات النظام الأساسي.
  • uiContainerGeometry [Rect]: هندسة SandboxedSdkView التي تتم عرضها
  • ‫alpha [float]: مستوى التعتيم لعنصر SandboxedSdkView الذي يتم عرضه
  • onScreenGeometry [Rect]: مجموعة فرعية من uiContainerGeometry لم يتم اقتصاصها من خلال طرق العرض الرئيسية، حتى viewport.
  • occludedGeometry [Rect]: أجزاء onScreenGeometry التي يتم حجبها بواسطة أيّ جداول عرض في التسلسل الهرمي للتطبيق تتضمّن Rect لكلّ حجب، بما يتوافق مع صفر أو عرض واحد أو أكثر من عروض التطبيق التي تتقاطع مع SandboxedSdkView onScreenGeometry

المتطلبات

  • يتم التعبير عن قيم uiContainerGeometry وonScreenGeometry وoccludedGeometry في مساحة الإحداثيات الخاصة بالعنصر viewport.
  • يتم تسجيل تغييرات مستوى الرؤية بأقل وقت استجابة.
  • يمكن قياس مستوى الظهور على مدار دورة ظهور الإعلان بالكامل، بدءًا من أول مرة يظهر فيها إلى آخر مرة.

اقتراح التصميم

يستند هذا الاقتراح إلى آلية عمل عرض واجهة المستخدم باستخدام مكتبات واجهة المستخدم الخاصة بالمستخدِم والموفِّر. سنوسّع نطاق مكتبات واجهة المستخدم للسماح لحزمة SDK بتسجيل مراقب واحد أو أكثر لجلسة واجهة المستخدم. سيتلقّى المُراقب معلومات عن إمكانية العرض عند رصد الأحداث ذات الصلة التي تعدّل أنواع البيانات في قسم capabilities. يمكن لحِزم تطوير البرامج (SDK) لقياس الأداء في وقت تشغيل حِزم SDK (عمليات تنفيذ OMID وMRAID) إرفاق هذا المُراقب بجلسة واجهة المستخدم، حتى يمكن إرسال هذه المعلومات إليه مباشرةً. يمكن لشركاء القياس دمج المعلومات التي يتم الحصول عليها من مكتبات UI مع بيانات عن المحتوى المتاح حاليًا (مثل عند استخدام نصوص برمجية للقياس يتم إدراجها في تصميم الإعلان) لإنشاء أحداث قياس إمكانية الرؤية باستخدام JavaScript.

التحكّم في تدفق الإعلانات لزيادة إمكانية العرض
التحكّم في تدفّق بيانات إمكانية العرض

تستمع مكتبة العميل إلى التغييرات في واجهة مستخدِم الإعلان من خلال أدوات الاستماع إلى الأحداث، مثل ViewTreeObserver. عندما تحدّد مكتبة العميل أنّ واجهة مستخدم الإعلان تغيّرت بطريقة قد تؤثّر في قياس مدى الرؤية، تتحقّق من وقت إرسال الإشعار الأخير إلى المُراقب. إذا كان آخر تعديل أكبر من وقت الاستجابة المسموح به (يمكن ضبطه من خلال حزمة تطوير البرامج (SDK) ليصل إلى 200 ملي ثانية بحد أدنى على الأجهزة الجوّالة)، يتم إنشاء عنصر AdContainerInfo جديد ويتم إرسال إشعار إلى المُراقب. وهذا النموذج المستنِد إلى الأحداث أفضل لصحة النظام مقارنةً بالاستطلاع الذي تُجريه معظم عمليات تنفيذ OMID على Android اليوم.

واجهة برمجة التطبيقات

ستتم إضافة ما يلي إلى مكتبة privacysandbox.ui.core:

  • ‫SessionObserver: يتم تنفيذه عادةً من خلال حزمة تطوير البرامج (SDK) لقياس الأداء، ويتم إرفاقه بالجلسة التي تعرضها حزمة SDK من خلال privacysandbox.ui. ستتيح هذه الواجهة أيضًا لحزمة تطوير البرامج (SDK) للقياس تفعيل فئات معيّنة من إشارات إمكانية العرض. ويؤدي ذلك بدوره إلى السماح لمكتبة برامج العميل لواجهة المستخدم بجمع الإشارات التي تهمّ المُراقب فقط، ما يُعدّ أفضل لحالة النظام بشكل عام.
  • registerObserver(): تمت إضافة هذه الطريقة إلى فئة Session، وهي تسمح لأي مستخدم لديه إذن بالوصول إلى الجلسة بتسجيل مراقب. إذا تم تسجيل المُراقب بعد فتح جلسة واجهة المستخدم، سيتم إرسالAdContainerInfo المخزّنة مؤقتًا إليه على الفور. في حال التسجيل قبل فتح الجلسة، سيتم إرسالها AdContainerInfo عند فتح الجلسة.
  • AdContainerInfo: فئة تتضمّن وظائف للحصول على البيانات تتيح للمراقِب الحصول على معلومات حاوية الإعلانات للقراءة فقط لأنواع البيانات المدرَجة في القسم الإمكانات أعلاه. وستتطابق قيم العرض من وظائف الحصول هذه ، كلما أمكن ذلك، مع قيم العرض القابلة للتقسيم من وظائف الحصول الحالية في View وفئاتها الفرعية. إذا تم إنشاء حاوية الإعلان باستخدام Jetpack Compose، يؤدي ذلك إلى عرض السمات الدلالية للحاوية. يمكن استخدام هذه الفئة لاحتساب أحداث MRAID وOMID ذات الصلة بإمكانية العرض.
  • ‫SessionObserverotifyAdContainerChanged(): يُستخدَم لإعلام المُراقب عند تغيُّر مدى الرؤية. ويمرر عنصر AdContainerInfo. يتمّ تشغيل هذا الإجراء عند رصد أحداث تؤثّر في أنواع البيانات المدرَجة في القسم "الإمكانات". ملاحظة: قد يتمّ استدعاء هذه الطريقة بالإضافة إلى طُرق on Session. على سبيل المثال، يتمّ استدعاء Session.notifyResized() لطلب حزمة SDK لتغيير حجم الإعلان، ويتمّ استدعاء SessionObserver.notifyAdContainerChanged() أيضًا عند حدوث ذلك.
  • SessionObserverotifySessionClosed(): لإرسال إشعار إلى المُراقب بأنّه تم إغلاق الجلسة

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

يمكن تعديل أي رمز برمجي يتم تشغيله في عملية تطبيق التطبيق، بما في ذلك الرمز البرمجي من مكتبة privacysandbox.ui.client، في حال تعرّض التطبيق للاختراق. وبالتالي، فإنّ أي منطق لجمع الإشارات يتم تشغيله في عملية التطبيق معرّض للتلاعب من خلال رمز التطبيق. وينطبق ذلك أيضًا على رمز حزمة SDK الذي تم برمجته قبل توفّر "مبادرة حماية الخصوصية" والذي يتم تشغيله في عملية إرسال التطبيق. وبالتالي، لا يؤدي جمع الإشارات من خلال مكتبة واجهة المستخدم إلى تفاقم الوضع الأمني.

بالإضافة إلى ذلك، يمكن للرمز البرمجي في وقت تشغيل حزمة تطوير البرامج (SDK) استخدام واجهة برمجة تطبيقات لمنصّة تُسمى setTrustedPresentationCallback يمكن أن تمنحه ضمانات أقوى من الإطار العمل بشأن عرض واجهة مستخدِم الإعلان. setTrustedPresentationCallback يعمل على مستوى المساحة، ويمكن أن يساعد في تقديم تأكيدات حول المساحة التي تحتوي على واجهة مستخدم الإعلان من خلال تحديد الحد الأدنى من الحدود الدنيا للعرض، مثل النسبة المئوية للبكسل المرئي أو الوقت الذي يظهر فيه على الشاشة أو المقياس. يمكن التحقّق من هذه البيانات مقارنةً ببيانات مدى الرؤية المقدّمة من مكتبة عملاء واجهة المستخدِم الموضّحة أعلاه. وبما أنّ البيانات المقدَّمة من إطار العمل أكثر موثوقية، يمكن تجاهل أي أحداث من مكتبة واجهة المستخدم التي لا تتوافق بياناتها مع بيانات إطار العمل. على سبيل المثال، إذا تمّ استدعاء المستمع المقدَّم لـ setTrustedPresentationCallback من خلال إشعار بأنّه لا يتم عرض أي بكسل من واجهة مستخدِم الإعلان على الشاشة، وتعرض مكتبة واجهة مستخدِم العميل عددًا غير صفري من البكسل على الشاشة، يمكن تجاهل البيانات الواردة من هذه المكتبة.

الأسئلة المفتوحة

  1. ما هي إشارات مدى الرؤية التي تهمّك والتي لم يتم ذكرها في هذا الشرح؟
  2. يقضي الاقتراح الحالي بتعديل إمكانية العرض كل 200 ملي ثانية على الأقل، شرط أن يكون هناك تغيير ذي صلة في واجهة المستخدم. هل هذه الوتيرة مقبولة بالنسبة إليك؟ إذا لم يكن الأمر كذلك، ما هو معدّل التكرار الذي تفضّله؟
  3. هل تفضّل تحليل المعلومات من setTrustedPresentationCallback بنفسك، أو أن تُسقط مكتبة واجهة مستخدِم مقدّم الخدمة البيانات من مكتبة واجهة مستخدِم العميل عندما لا تتطابق مع بيانات setTrustedPresentationCallback؟
  4. كيف تستخدِم إشارات إمكانية العرض؟ يُرجى مساعدتنا في فهم حالات الاستخدام من خلال إرسال ملاحظات تجيب عن هذه الأسئلة.