نحن في فريق ChromeOS ملتزمون بتحسين أدوات وأُطر عمل المطوّرين التي تتيح لمطوّري تطبيقات Android تحسين تطبيقاتهم لأجهزة Chromebook بسلاسة. ولتحقيق ذلك، علينا أن نبحث باستمرار عن طرق لتوفير مجموعات أدوات فعّالة للمطوّرين من أجل تحسين تجربة تصميم التطبيقات للشاشات الكبيرة وأجهزة ChromeOS.
تطوّر نظام التشغيل ChromeOS على مر السنين مع ظهور تحديات جديدة. أحد هذه التحديات هو تحديد المشاكل الحرجة وإبلاغ المهندسين بها في وقت مبكر وبشكل متكرر. تُعدّ قواعد Lint أساسية للجودة، إذ تقدّم إشارات تنبيه للمطوّرين بشأن المشاكل التي ستحدث إذا لم يتم إصلاحها. توفّر قواعد التدقيق المعدَّلة للمطوّرين إمكانية أكبر للاطّلاع على طريقة تشغيل تطبيقاتهم على ChromeOS، مع عرض المشاكل، سواء كانت برامج أو أجهزة، التي ستتسبّب بلا شك في حدوث مشاكل في تطبيقات Android التي يتم تشغيلها على أي جهاز ChromeOS.
للحصول على مزيد من المعلومات الأساسية حول توفّر قواعد التدقيق هذه وأهميتها، يُرجى قراءة مشاركة المدوّنة.
أين توجد قواعد Lint هذه؟
نعمل على تطوير هذه الميزة منذ بضعة أشهر. مع جدول إصدار "استوديو Android"، يتم طرح بعض قواعد Lint مع إصدارات Electric Eel Canary. تتوفّر الآن بعض قواعد Lint هذه أيضًا في إصدارات Flamingo Canary. سنواصل العمل على إتاحة هذه الميزات في الإصدارات الثابتة من "استوديو Android" خلال الأشهر المقبلة.
من الأمور المهمة الأخرى التي يجب ملاحظتها أنّ هذه القواعد سيتم تفعيلها تلقائيًا في الإصدارات الأحدث من "استوديو Android". والهدف من ذلك هو تقديم إرشادات أكثر وضوحًا حول كيفية مساعدة المهندسين في تصميم التطبيقات لنظام التشغيل ChromeOS والشاشات الأكبر حجمًا في المستقبل.
قواعد Lint الجديدة (تم تعديلها اعتبارًا من الإصدار 3 من Flamingo Canary)
توافُق واجهة التطبيق الثنائية (ABI) مع معالجات x86/x86_64
تعمل غالبية أجهزة Chromebook على بنية Intel الأساسية، ما يجعلها منصة معمارية x86 في الغالب. لكي يكون ChromeOS متوافقًا بشكل سليم عند تضمين رمز NDK كجزء من الملف الثنائي، فإنّ توفُّر x86 يؤدي إلى تحسين الأداء بسبب إزالة الترجمة المطلوبة من مكتبات ARM. لذلك، ننصح فريق التطوير بشدة بإضافة دعم بنية x86 أو x86_64، لأنّ ذلك سيحسّن الأداء بشكل كبير لأي رمز برمجي أصلي على ChromeOS أو أي جهاز Intel.
الحلّ
إذا أمكن، أضِف x86 وx86_64 داخل abiSplits ضمن build.gradle. تأكَّد أيضًا من إضافة الرمز إلى المجلدات المناسبة لتوفير هذه الواجهات الثنائية لتطبيقات Android. لمزيد من المعلومات، يُرجى الرجوع إلى المستندات حول واجهات التطبيق الثنائية (ABI) لنظام التشغيل Android والمحادثة حول توافق واجهات التطبيق الثنائية من "خدمة إعلانات Google".
ملاحظة: تأكَّد من أنّ أي مكتبات خارجية مضمّنة يتم استخدامها تحتوي أيضًا على ملفات ثنائية x86 وx86_64.
قيود أجهزة ChromeOS
تتضمّن غالبية أجهزة ChromeOS مجموعة أصغر من عيّنات أجهزة الاستشعار والميزات الأخرى مقارنةً بهاتف Android. تهدف هذه القاعدة إلى تنبيه المطوّرين إلى أنّه في حال استخدام العلامة <uses-feature> مع android:required=true، لن يكون تطبيقك متاحًا على "متجر Google Play" على ChromeOS. ننصحك بشدة بالتأكّد من أنّ ميزة الجهاز غير مطلوبة تلقائيًا لضمان إمكانية الوصول إلى تطبيقك على أكبر عدد ممكن من الأجهزة. بدلاً من ذلك، يمكنك إضافة رمز دفاعي للتحقّق من أجهزة معيّنة في وقت التشغيل. مثال على ذلك
<uses-feature android:name="android.hardware.camera" android:required="true">
الحلّ
تأكَّد من أنّ الميزات المتوفّرة في تطبيقك مطلوبة فعلاً، وإذا لم تكن كذلك، غيِّر المَعلمة android:required إلى false وأضِف برمجة دفاعية عند الحاجة إلى طلبات البيانات من واجهة برمجة التطبيقات. للحصول على مزيد من المعلومات، يُرجى الرجوع إلى المستندات حول الميزات التي تم الإعلان عنها بوضوح.
الأنشطة التي لا يمكن تغيير حجمها
يبدأ Android Runtime for ChromeOS، الذي يعمل بالإصدار R من نظام التشغيل Android أو إصدار أحدث على أجهزة Chromebook، تطبيق Android إما في إصدار التطبيق المخصّص للهاتف أو الجهاز اللوحي، وذلك استنادًا إلى حالة واجهة المستخدم التلقائية. ومع ذلك، هناك خيار ثالث يوفّر تجربة أفضل لمستخدمي ChromeOS، وهو وضع "تغيير الحجم". من خلال تفعيل هذا الخيار كجزء من "النشاط"، يمكن للمستخدمين الذين يمكنهم استخدام تطبيقك في أي بيئات متعددة النوافذ الاستفادة من تغيير حجم تطبيقك إلى الحجم المناسب. ستسمح هذه التغييرات للمستخدمين بتوسيع واجهة المستخدم لتلبية احتياجاتهم. بعد إضافة هذه التغييرات إلى ملف البيان، اختبِر تطبيقك باستخدام "المحاكي المكتبي" المشار إليه أدناه.
الحلّ
أضِف السمة resizableActivity="true" إلى النشاط في ملف AndroidManifest.xml. لمزيد من المعلومات، يُرجى الرجوع إلى المستندات حول القيود المفروضة على الشاشات الكبيرة.
تغييرات الإعدادات
أحد التحذيرات الرئيسية بشأن الشاشات القابلة لتغيير الحجم هو أنّه في كل مرة يغيّر فيها المستخدم حجم التطبيق، يتم استدعاء onConfigurationChanged(). إذا كان تطبيقك يعيد رسم الشاشة بالكامل داخل هذه الطريقة، ستكون هناك آثار على الأداء مرتبطة بها. في الوقت الحالي، نتحقّق للتأكّد من عدم استدعاء finish() ضمن onConfigurationChanged، لأنّه يجب التعامل مع savedInstanceState بدقة أكبر بدلاً من فرض إعادة رسم كاملة. سنواصل البحث عن الحالات التي سيحدث فيها انخفاض في الأداء وتعديل هذه القاعدة وفقًا لذلك.
الحلّ
تأكَّد من عدم استدعاء finish() ضِمن واجهة برمجة التطبيقات onConfigurationChanged() في الأنشطة والتقسيمات. لمزيد من المعلومات، يُرجى الرجوع إلى المستندات حول التعامل مع تغييرات الإعدادات.
إمكانية استخدام لوحة المفاتيح والماوس
مع زيادة استخدام Jetpack Compose، أردنا التأكّد من أنّ إنشاء التطبيقات باستخدام هذه المكتبات يتضمّن أيضًا وظائف دعم الماوس ولوحة المفاتيح من الآن فصاعدًا. بمرور الوقت، سنواصل زيادة سهولة استخدام الماوس ولوحة المفاتيح ولوحة اللمس وغيرها من التفاعلات الطرفية. للحصول على التجارب الأساسية، عليك تعديل تبعيات Gradle إلى الحد الأدنى من الإصدارات المطلوبة.
الحلّ
تحديث androidx.compose.foundation:foundation إلى الإصدار 1.2 على الأقل لمزيد من المعلومات، يُرجى الرجوع إلى ملاحظات إصدار Compose.
ملاحظة: يتفاعل% 90 من المستخدمين مع التطبيقات على أجهزة Chromebook باستخدام لوحة المفاتيح والماوس. (المصدر: بيانات Google الداخلية لعام 2022*)
الملاحظات
يسعى الفريق باستمرار إلى تحسين هذه الأدوات والمستندات المتعلقة بتحسين التطبيقات للشاشات الكبيرة. من الخطوات المهمة في هذه العملية أن تقدّم لنا ملاحظاتك حول دقة قواعد Lint التي يتم نشرها في "استوديو Android" ومدى فائدتها. يمكنك إجراء ذلك من خلال تقديم ملاحظات بشأن القاعدة. عند ظهور قاعدة lint في "استوديو Android"، انقر على "تقديم ملاحظات حول هذا التحذير". من المفترض أن يتم نقلك إلى مربّع حوار يشبه المربّع أدناه. كلما كانت المعلومات المقدَّمة أكثر دقة وتفصيلاً، تمكّنّا من إجراء التغييرات المناسبة بسرعة أكبر.
