من المعروف أن ميزة إمكانية الوصول في Android تسبب تأخرًا في واجهة المستخدم. هل هو خطأ أم أنه ميزة؟ لماذا يحدث؟ نحن في XDA نحقق في السبب الجذري.
يكمن جمال Android في الطرق العديدة المختلفة التي يمكن أن تتفاعل بها تطبيقات الطرف الثالث مع النظام. تطبيقات إدارة كلمات المرور مثل لاست باس توفير القدرة على تغذية بيانات اسم المستخدم/كلمة المرور ذات الصلة تلقائيًا إلى أي شاشة تسجيل دخول تقريبًا. مساعد النص يسمح لك بتقصير وقتك في إرسال الرسائل النصية إلى أصدقائك بشكل كبير من خلال السماح لك بإنشاء وحدات ماكرو لتوسيع النص. الحافظة الأصلية يقلل من المتاعب التي ينطوي عليها التبديل المتكرر بين التطبيقات لنسخ كميات كبيرة من النص من خلال السماح لك بالنقر المزدوج على أي حقل إدخال لإظهار الحافظة. من يستطيع أن ينسى جرينيفاي، ربما يكون التطبيق رقم 1 الأكثر موصى به من قبل المتحمسين، والذي يبقي تطبيقات الخلفية المارقة تحت المراقبة وبالتالي يمكن أن يعزز عمر البطارية؟ أخيرًا، على الرغم من أنها أقل دراية لدى معظم المستخدمين، هناك الإدخال التلقائي - مكون إضافي لـ Tasker مصمم لأتمتة النقرات على الشاشة وإدخال النص وإيماءات التمرير وغير ذلك الكثير. تخدم جميع هذه التطبيقات حالات استخدام مختلفة إلى حد كبير، ولكن كل تطبيق من هذه التطبيقات يعتمد على جزء يساء فهمه للغاية من وظائف Android الأساسية:
إمكانية الوصول.بالنسبة لمستخدم Android العادي، قد يبدو غريبًا أن يتم التحكم في العديد من هذه الميزات الرائعة التي يستخدمها تطبيقك المفضل من خلال إعداد ضمن إمكانية الوصول القائمة الفرعية. صنع التطبيق يمكن الوصول من المفترض عادةً أن يعني أن تطبيق Android قابل للاستخدام من قبل شخص لديه الإعاقات. فلماذا في العالم تمتلك LastPass أو Native Clipboard أو Text Aide أو Greenify أو AutoInput إمكانية الوصول خدمة؟ علاوة على ذلك، لماذا يبدو تمكين خدمة الوصول كذلك؟ يسبب الكثير من تأخر واجهة المستخدم? لا يبدو أنه يهم إصدار Android الذي تستخدمه - سواء كان كذلك أندرويد 5.0 لوليبوب أو أندرويد 7.0 نوجا - لأن التأخير الناجم عن بعض خدمات إمكانية الوصول يمكن أن يؤثر على تجربتك. الحل البسيط لهذه المشكلة هو مجرد تعطيل خدمات الوصول التي ربما قمت بتمكينها - ولكن من خلال القيام بذلك، فإننا نفقد الكثير من الوظائف المفيدة. الحل الآخر هو تقديم التماس إلى Google "لإصلاح" تأخر إمكانية الوصول إلى Android، لكن Google تدعي أن إمكانية الوصول إلى Android هي كذلك العمل على النحو المنشود. لقد تحدثنا إلى عدد قليل من المطورين الذين لديهم معرفة وثيقة بخدمات إمكانية الوصول وبحثنا في كيفية عمل الوظيفة، ونحن هنا لاختبار هذا الادعاء: هل تأخر إمكانية الوصول إلى Android هو خطأ أم أنها ميزة؟
فهم إمكانية الوصول إلى Android
كما قد تتخيل من الاسم، فإن إمكانية الوصول مخصصة في الغالب للمطورين لتوفير وظائف إضافية لأي مستخدمين ذوي إعاقة. في الواقع، نظرة خاطفة سريعة على صفحات التوثيق الرسمية لإمكانية الوصول يكشف أن Google لديها رؤية ضيقة جدًا حول أنواع الخدمات التي يجب أن تقدمها خدمات إمكانية الوصول.
يتمتع العديد من مستخدمي Android بقدرات مختلفة تتطلب منهم التفاعل مع أجهزتهم التي تعمل بنظام Android بطرق مختلفة. ويشمل ذلك المستخدمين الذين لديهم قيود بصرية أو جسدية أو مرتبطة بالعمر تمنعهم من الرؤية بشكل كامل أو باستخدام شاشة تعمل باللمس، والمستخدمين الذين يعانون من ضعف السمع والذين قد لا يتمكنون من إدراك المعلومات والتنبيهات الصوتية.
يوفر Android ميزات وخدمات إمكانية الوصول لمساعدة هؤلاء المستخدمين على التنقل على أجهزتهم بشكل أكبر بسهولة، بما في ذلك تحويل النص إلى كلام، وردود الفعل اللمسية، والتنقل بالإيماءات، وكرة التتبع، ولوحة الاتجاهات ملاحة.
جوجل اعد كلامك، والذي يتم تثبيته مسبقًا على كل هاتف يعمل بنظام Android، يعد مثالًا رائعًا لما يفترض أن تكون عليه خدمة إمكانية الوصول "النموذجية". الوصول الصوتي يأخذ إمكانية الوصول خطوة أخرى إلى الأمام ويسمح بالتحكم الكامل تقريبًا في هاتفك باستخدام صوتك فقط. لكن حقيقة أن Google قصدت استخدام خدمات إمكانية الوصول بهذه الطريقة لا تمنع ذلك المطورين من تنفيذها بأي طريقة يريدونها - وهذا بالضبط ما يمتلكه المطورون منتهي. يرجع السبب في ذلك بالضبط إلى الطريقة التي تعمل بها إمكانية الوصول والتي تجعل هذه الميزة مفيدة بشكل لا يصدق للمستخدمين ذوي الإعاقة أو بدونها.
لتبسيط الأمور قليلاً، إليك ملخصًا أساسيًا لكيفية عمل إمكانية الوصول في Android. يقوم المطور بإنشاء خدمة إمكانية الوصول التي تشترك في مختلف أحداث إمكانية الوصول التي يرسلها النظام إلى الخدمة اعتمادًا على استيفاء معايير معينة أم لا. عندما يتم تعطيل جميع الخدمات ضمن الإعدادات -> إمكانية الوصول، لا يقوم Android بجمع أو إرسال أي أحداث إمكانية الوصول. ولكن عندما يبدأ المستخدم في تمكين خدمات إمكانية الوصول، سيبدأ Android في المراقبة والجمع فقط أحداث إمكانية الوصول التي تطلبها خدمة إمكانية الوصول. على سبيل المثال، خدمة إمكانية الوصول التي تشترك في حدث إمكانية الوصول TYPE_WINDOW_CONTENT_CHANGED سيتم إخطارك من قبل النظام في كل مرة أن يحدث تغيير في النافذة الحالية. تم استدعاء حدث إمكانية الوصول آخر TYPE_VIEW_CLICKED الحرائق في كل مرة ينقر المستخدم على زر من نوع ما.
عرض توضيحي لإمكانية الوصول إلى Android. في هذا الفيديو قمت بتفعيل التطبيق تاسكر لرصد التغييرات في عنوان النافذة. يتطلب هذا تمكين خدمة الوصول الخاصة بـ Tasker. يمكنك تكرار ذلك عن طريق إنشاء ملف تعريف جديد في Tasker مع تعيين سياق "الحدث" على "مجموعة متغيرة" واختيار %WIN كمتغير تريد مراقبته. في المجمل، تم التقاط هذا الفيديو الذي تبلغ مدته حوالي دقيقة واحدة 107 تغييرات في النافذة الحالية.
تحدث هذه الأنواع من أحداث إمكانية الوصول بتكرار كبير أثناء تفاعل المستخدم العادي. لذا تخيل ماذا يحدث عندما يقوم المستخدم يتيح خدمات إمكانية الوصول المتعددة التي تتطلب إطلاق أحداث إمكانية الوصول عالية التردد. صحيح - بطئ. وللتخفيف من ذلك، يمكن للمطورين تحديد أنواع أحداث إمكانية الوصول الخاصة بهم بشكل أضيق يجب أن تتفاعل الخدمة وفي أي سياق، مثل القدرة على تقييد الخدمة للتفاعل فقط عندما تكون في تطبيقات معينة أو للحد من فترة الاقتراع بين الأحداث. ولكن بخلاف ذلك فإن مقدار النفقات العامة الناتجة عن خدمة إمكانية الوصول يعتمد في الغالب على ما هي أنواع أحداث إمكانية الوصول يشترك فيه. في جوهر الأمر، لن تتسبب كل خدمة إمكانية الوصول في حدوث تأخير. قد تؤدي خدمة إمكانية الوصول الفردية التي تتطلب حدثًا عالي التردد إلى حدوث تأخير، خاصة إذا الخدمة المذكورة مقترنة بخدمة أخرى تتطلب حدثًا آخر عالي التردد مراقبة.
التعمق في إمكانية الوصول باستخدام APK Teardowns
كما يمكنك أن ترى من الفيديو المنشور أعلاه، يمكن لخدمة إمكانية الوصول التي تراقب التغييرات في محتوى النافذة القيام بذلك يؤدي إلى تغييرات ملحوظة إلى حد ما في أداء واجهة المستخدم نظرًا للكم الهائل من أحداث إمكانية الوصول التي تم التقاطها والتي تم إطلاقها بواسطة نظام. ومع ذلك، من الصعب جدًا تحديد مقدار الحمل الناتج عن خدمة إمكانية الوصول معينة. لن تؤدي مراقبة LogCat عمومًا إلى أي شيء، حيث تتم طباعة أحداث إمكانية الوصول إلى LogCat فقط إذا اختار مطور خدمة الوصول القيام بذلك. ولحسن الحظ، فهو الأب لجميع خدمات الوصول إلى Android، الإدخال التلقائي، يفعل ذلك بالضبط. ويكون إخراج LogCat فوضويًا تمامًا كما تتخيل.
الإدخال التلقائي لا يخفي الحقيقة عنا. يمكن أن تكون النفقات العامة الناتجة عن التطبيق هائلة جدًا اعتمادًا على الأحداث التي تراقبها. ولكن هذا الحمل ضروري لكي يعمل التطبيق. لكي يعترض الإدخال التلقائي كل ضغطة على المفتاح، وكل إيماءة على الشاشة، وكل تحديث لواجهة المستخدم، وكل ضغطة على زر، فإنه الاحتياجات لمراقبة أحداث إمكانية الوصول المعنية. بدون هذه الأحداث، لا يمكن للإدخال التلقائي الارتباط بالنظام وتوفير أتمتة واجهة المستخدم غير المحدودة تقريبًا التي يسمح بها حاليًا. وبالتالي، فإن جميع وظائف AutoInput منطقية تمامًا في سياق إمكانية الوصول. ولكن بالنسبة للتطبيقات الأخرى، نحتاج إلى إلقاء نظرة أعمق قليلًا لفهم كيفية التعامل مع خدمات إمكانية الوصول الخاصة بها.
خدمة إمكانية الوصول صفات يتم تعريفها في ملف الموارد XML داخل APK. ولذلك، يمكننا إجراء APK المسيل للدموع على تطبيق مزود بخدمة إمكانية الوصول لمعرفة سمات الخدمة. يعمل كل تطبيق بشكل مختلف، لذا سأحاول شرح كيفية ارتباط سمات الخدمة الخاصة به بالوظيفة المحددة التي يؤديها.
الحافظة الأصلية
Native Clipboard هو ما أستخدمه عندما يتعلق الأمر بمديري الحافظة. إذا كنت تبحث عن مدير حافظة قابل للتخصيص بشكل كبير، فإن Native Clipboard هو تطبيق رائع جدًا. حتى أنه يحتوي على مكون Xpose Module للسماح لك بالضغط لفترة طويلة على زر "لصق" لإظهار مدير الحافظة! لسوء الحظ، إذا لم يكن لديك إمكانية الوصول إلى Xpose Framework (مثل كل مستخدم على Nougat)، فسيتعين عليك تسوية الأمر لتمكين خدمة إمكانية الوصول والتي ستتيح لك النقر نقرًا مزدوجًا على أي إدخال نص لإظهار الحافظة مدير. وإليك ما يستلزم ذلك.
"@string/access_decs"
android: accessibilityEventTypes="typeViewClicked|typeViewFocused|typeViewLongClicked|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="100"
android: accessibilityFlags="flagReportViewIds|flagRetrieveInteractiveWindows"
android: canRetrieveWindowContent="true"
xmlns: andro /> تطلب خدمة إمكانية الوصول في Native Clipboard إطلاق حدث إمكانية الوصول في كل مرة يتم فيها النقر على طريقة العرض، أو النقر عليها لفترة طويلة، أو التركيز عليها، أو إذا كان هناك تغيير في حالة النافذة. بدون الوصول إلى الكود المصدري، لا أستطيع أن أقول بالضبط كيف تعمل Native Clipboard، ولكن من المحتمل أن Native Clipboard ينتظر حتى تشير حالة النافذة إلى أن لوحة المفاتيح الإلكترونية مفتوحة حاليًا، ثم يقوم بمراقبة النقرات على الإدخال مجال. يحتوي التطبيق على فترة استقصاء تبلغ 100 مللي ثانية، لذا فهي بالتأكيد سريعة بما يكفي للتفاعل بشكل أساسي على الفور مع التغييرات في رؤية لوحة المفاتيح الناعمة بالإضافة إلى النقرات المزدوجة. قد يؤدي هذا إلى بعض الحمل الزائد لواجهة المستخدم عندما يستخدم المستخدم لوحة المفاتيح الإلكترونية لكتابة أي نص، مما قد يؤدي إلى حدوث تأخير.
جرينيفاي
التالي هو موفر البطارية المفضل لدى الجميع، Greenify. يستخدم Greenify أحداث إمكانية الوصول لتشغيل وظائفه غير الجذرية.
"@string/accessibility_service_description"
android: settingsActivity="com.oasisfeng.greenify.accessibility.AccessibilitySettings"
android: accessibilityEventTypes="typeAnnouncement|typeNotificationStateChanged|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric" android: notificationTimeout="0"
android: accessibilityFlags="flagReportViewIds"
android: canRetrieveWindowContent="true"
xmlns: andro /> ويستخدم التغييرات في حالة النافذة لتحديد وقت إيقاف تشغيل شاشة الهاتف، ويتطلب تأخير تنشيط شاشة القفل عن طريق تغيير خيار في إعدادات الأمان. سيتلقى Greenify أيضًا أحداثًا من نوع الإعلان أو تم تغيير حالة الإشعار، وهذا الأخير غير ضروري على أجهزة Android 5.0+ بفضل ميزة الوصول إلى الإشعارات. ومع ذلك، فإنها ستظل تتلقى هذه الأحداث بغض النظر عن تلك الحقيقة. لا ينبغي أن يسبب Greenify الكثير من النفقات العامة في حد ذاته، ولكن الاحتمال قائم.
نوفا قاذفة
من المحتمل أن يكون تطبيق Nova Launcher هو تطبيق Launcher التابع لجهة خارجية الأكثر شيوعًا في السوق، وهو مثال ممتاز لتطبيق يستخدم خدمة إمكانية الوصول مع الحد الأدنى من النفقات العامة أو بدونها. السبب الوحيد لوجود الخدمة هو مساعدة أجهزة معينة في أداء الإيماءات.
"@string/accessibility_service_description"
android: accessibilityEventTypes=""
android: packageNames="com.teslacoilsw.launcher"
android: accessibilityFeedbackType=""
android: notificationTimeout="10000"
android: canRetrieveWindowContent="false"
xmlns: andro /> كما ترون، لا يوجد حدث إمكانية الوصول محدد في ملف XML. كل ما هو مذكور هو اسم الحزمة - Nova Launcher. ما يحدث هنا هو حل بديل لبعض الأجهزة التي لا تعمل عليها إيماءات Nova Launcher. ستوفر هذه الخدمة لـ Nova Launcher جميع أحداث إمكانية الوصول التي تم إطلاقها منها فقط داخل Nova Launcher. قد يبدو الأمر غريبًا، ولكن يبدو أنها طريقة لإصلاح إيماءات الشاشة الرئيسية لـ Nova إذا كان جهازك لا يعمل معها. نظرًا لأن هذا يطلب الأحداث فقط من Nova نفسها، فإن الخدمة لا تفرض سوى القليل جدًا من النفقات العامة.
لاست باس
أخيرًا، ربما تكون خدمة الوصول الأكثر شهرة والتي تسبب تأخيرًا (ربما بسبب شعبيتها الهائلة) - LastPass. مشكلة التأخر في LastPass هي ملحوظ جدا أن الشركة لديها مسؤول صفحة الأسئلة الشائعة التي تصف المشكلة. كما تنص الأسئلة الشائعة، لا يوجد شيء يمكنك فعله بشأن التأخير باستثناء تعطيل الخدمة. لماذا تبدو خدمة LastPass سيئة للغاية عندما يتعلق الأمر بالتأخير؟ دعونا نلقي نظرة على سمات الخدمة.
"@string/accessibility_service_description"
android: accessibilityEventTypes="typeViewFocused|typeWindowContentChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="200"
android: accessibilityFlags="flagReportViewIds"
android: canRetrieveWindowContent="true"
android: canRequestEnhancedWebAccessibility="true"
xmlns: andro /> الحقيقة هي أنه لا يوجد شيء خارج عن المألوف مع خدمة LastPass. إنه يطلب فقط نوعين من الأحداث للمراقبة - TYPE_VIEW_FOCUSED وTYPE_WINDOW_CONTENT_CHANGED. يقوم بذلك لأنه يحتاج إلى معرفة متى يتغير/يصبح محتوى التطبيق/صفحة الويب موضع التركيز، ثم يقوم باسترداد محتوى النافذة الحالية للبحث عن أي حقول إدخال كلمة المرور. ولكن نظرًا لأن الخدمة تفعل ذلك باستمرار في حدثين لإمكانية الوصول يتم تشغيلهما بشكل متكرر للغاية، فإن ذلك يؤدي إلى حدوث تأخير. هذه هي الحقيقة المؤسفة.
العيش مع التأخر
عندما قرأنا لأول مرة أن Google كانت تغلق تقارير الأخطاء المتعلقة بتأخر إمكانية الوصول لأن الميزة "تعمل على النحو المنشود"، شعرنا بالحيرة والانزعاج مثل الكثير منكم. ولكن بدلاً من قبول التفسير على ظاهره، قررنا أن ننظر في الأمر بأنفسنا لنحدد الحقيقة. لذلك عندما قال موظف Google في صفحة تقرير الأخطاء ما يلي:
مرحبًا، هذه المشكلة مستمرة عبر إصدارات Android، وسيكون هناك دائمًا تأخير إضافي عند تمكين خدمة إمكانية الوصول. وذلك لأن الجهاز، بالإضافة إلى واجهة المستخدم القياسية، يوفر الكثير من المعلومات لخدمات إمكانية الوصول حتى يتمكنوا من توفير تجربة مستخدم بديلة لهؤلاء المستخدمين.
لقد وصلنا إلى الفهم لماذا هذا هو السلوك المقصود. التطبيقات التي تستخدم خدمات إمكانية الوصول بطريقة غير مقصودة من Google ستتحمل دائمًا بعض النفقات العامة على الأداء؛ هذه التكلفة ضرورية ببساطة لتزويد الخدمات بكمية كبيرة من المعلومات التي تنشطها إمكانية الوصول في Android في الخلفية. تأخر Android في خدمات إمكانية الوصول هو ليس علة، ولكن الميزة. وهي ميزة سيتعين علينا التعايش معها ما لم يتم إعادة صياغة النظام بأكمله، ولا أستطيع أن أتخيل كيف سيتم القيام بذلك لاستيعاب العديد من مجموعات الميزات المختلفة من العديد من التطبيقات المختلفة.
على أقل تقدير، لن يتقبل مطورو LastPass هذا الأمر. لقد عمل مطوروها مع مطوري Chromium من أجل تحسين دعم إمكانية الوصولربما عن طريق تمكين دعم LastPass من خلال استخدام واجهات برمجة التطبيقات بدلاً من تمكين خدمة إمكانية الوصول. يعد تحسين النفقات العامة التي تتكبدها خدمات إمكانية الوصول أحد الاحتمالات، ولكن كما لاحظ العديد من المطورين ضمنيًا منتديات Chromium، فهي مجرد وسيلة مساعدة لن تحل حقيقة أن الاستخدامات غير المقصودة لخدمات إمكانية الوصول قد تؤدي إلى بطئ.
شكر خاص لمطور AutoInput، joaomgcd، للإجابة على العديد من أسئلتي المتعلقة بإمكانية الوصول!