تصحيح الأخطاء غير المحتملة للصور المتحركة
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تتمثل إحدى أصعب المشكلات التي تواجه مطوري التطبيقات في
ضمان صور متحركة سلسة وخالية من أي خلل. ويصعب تصحيح الأخطاء خصوصًا عندما يؤدي النظام أيضًا مهامًا تستهلك موارد كثيرة في الخلفية. ليست هناك طريقة سهلة لتحديد ما إذا كانت بعض البيانات غير الواضحة ناتجة عن تطبيقك أو النظام. ومع ذلك، هناك أداة محلل يمكن أن تساعدك في تحديد
المصدر المحتمل للسلوك السيئ.
العرض على نظام التشغيل ChromeOS
عادةً ما يستخدم التطبيق الدقيق، مثل الألعاب، ميزة التخزين المؤقت المزدوج للحفاظ على انخفاض وقت استجابة المستخدم قدر الإمكان. ومع ذلك، هناك الكثير من العوامل التي قد تؤدّي إلى انخفاض مستوى الأداء. على سبيل المثال، إذا استغرق عرض الإطار وقتًا طويلاً، فلن تكون النتيجة
المقدمة جاهزة لعملية تبديل المخزن المؤقت التالي، وبالتالي يتكرر الإطار السابق.
وبعد ذلك، لا يمكن لبرنامج العرض البدء في عرض الإطار التالي،
متسببًا في المزيد من المشاكل. وهذا السيناريو مألوف بالنسبة إلى مطوّري برامج Android للأجهزة الجوّالة،
فعندما يتم تشغيل تطبيق على ChromeOS، يكون السياق أكثر تعقيدًا.
التطبيق الذي يعمل على سطح المكتب لا يتم عرضه مباشرةً على إطار عرض الشاشة. فهي تعرض البيانات في شكل زخرفة بدلاً من ذلك. عادةً ما يكون هناك تطبيقات متعددة،
يعرض كل منها رسوماته في زخرفة. ينشئ النظام طريقة عرض على الشاشة
باستخدام مُكوِّن لدمج كل الزخارف في صورة
كمبيوتر مكتبي واحدة.
يعمل المكوّن بشفافية في الخلفية. ومع ذلك، فهي تقدم تأخيرًا زمنيًا لإطار واحد
لزيادة استخدام مسار وحدة معالجة الرسومات إلى أقصى حد. في عالم مثالي،
قد لا يكون هذا ضروريًا، لكنه يخفف من تقلّبات أداء النظام ويساعد في موازنة الحمل غير المتماثل.
عندما يعمل نظام التشغيل بقوة، قد يتم ضغط وحدة معالجة الرسومات. قد يكون هناك تأخير من وقت عرض الإطار إلى وقت ظهوره على الشاشة. اعتمادًا على الأجهزة، قد يستخدم النظام التخزين المؤقت الرباعي
لتعويض ذلك. حتى مع حدوث تخزين مؤقت أعمق، يمكن أن يستمر حدوث خلل في مسار الرسوميات.
أداة تتبُّع رسومات ARC
يتضمَّن نظام التشغيل ChromeOS أداة تحليل توضِّح كيفية امتلاء المخازن المؤقتة
من خلال النظام، وعند حدوث عمليات تبديل الذاكرة، ومدى انشغال وحدة المعالجة المركزية (CPU)/وحدة معالجة الرسومات، والإجراءات التي ينفّذها تطبيقك في وقت معيَّن، كما هو موضّح في الصورة التالية:
إعداد المحلِّل
لاستخدام المحلِّل، يجب تشغيل الإصدار M75 أو إصدار أحدث.
وللحصول على أفضل النتائج، استخدِم جهاز Intel.
قبل استخدام المحلل، يمكنك إنشاء تطبيقك مع التتبعات.
أضف Trace.traceCounter(Trace.TRACE_TAG_GRAPHICS, "Event", <number>); إلى الرمز الخاص بك
حيث تريد تضمين التتبع. استخدام Event يبدأ بالبادئة customTrace لا تظهر البادئة في رسالة التتبُّع.
لإعداد المحلل، اتبع الخطوات التالية:
- فعِّل وضع مطوّر البرامج.
- فعِّل إعدادات Chrome وفعِّل أداة العرض المرئي للمخازن المؤقتة للرسومات من ARC.
- الانتقال إلى
chrome://arc-graphics-tracing
تشغيل المحلل
- اختَر إيقاف عند إيقاف الجهاز غير المهم.
- شغِّل تطبيق Android.
- عندما يكون تطبيق Android نشطًا مع التركيز على الجهاز، اضغط على Control+Shift+G.
عندما تظهر مشكلة، تظهر نافذة متصفّح منبثقة.
استخدِم مفتاحَي W وS للتكبير أو التصغير وتصغير المخطط الزمني.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Debug animation jank\n\nOne of the most difficult problems for app developers is\nensuring smooth, glitchless, and jank-free animation. This is especially hard to\ndebug when the system is also performing resource-intensive background\ntasks. There is no easy way to determine whether some jank is caused by your app or\nthe system. However, there is a profiler tool that can help you identify the\npossible source of the bad behavior.\n\nRender on ChromeOS\n------------------\n\nA fine-tuned app, like a game, usually uses double buffering to keep the user\nresponse time as low as possible. Still, there are many things that can degrade\nperformance. For example, if rendering a frame takes too long, the rendered\nresult is not ready for the next buffer swap, and consequently the previous\nframe repeats.\n\nThen, the renderer can't start rendering the next frame,\ncausing even more problems. This scenario is familiar to Android mobile\ndevelopers; when an app runs on ChromeOS, the context is even more complicated.\n\nAn app running on the desktop doesn't render directly to the screen's display\nframe. It renders its data into a texture instead. There are usually multiple\napps, each rendering its graphics into a texture. The system constructs the view\non the screen using a compositor to combine all the textures into a single\ndesktop image.\n\nThe compositor works transparently in the background. However, it introduces a\none-frame time delay to maximize the use of the GPU pipeline. In an ideal\nworld this might not be necessary, but it smooths system performance\nfluctuations and helps balance an asymmetrical load.\n\nWhen the OS is working very hard, the GPU might get squeezed. There can be a\ndelay from the time a frame renders to when it appears on the\nscreen. Depending on the hardware, the system might use quadruple buffering to\ncompensate. Even with deeper buffering, the graphic pipeline can still glitch.\n\nThe ARC graphics tracer\n-----------------------\n\nChromeOS has a profiling tool that shows how the buffers are percolating\nthrough the system, when memory swaps occur, how busy the CPU/GPU is, and what\nyour application is doing at a given time, shown in the following image:\n\n### Set up the profiler\n\nTo use the profiler, you must run M75 or later.\nFor best results, use an Intel device.\n\nBefore using the profiler, seed your app with traces.\nAdd `Trace.traceCounter(Trace.TRACE_TAG_GRAPHICS, \"Event\", \u003cnumber\u003e);` to your code\nwherever you'd like to include a trace. Use an `Event` that begins with\nthe prefix `customTrace`. The prefix doesn't appear in the trace message.\n\nTo set up the profiler, follow these steps:\n\n1. Turn on developer mode.\n2. Turn on Chrome settings and enable the **ARC graphic buffers visualization tool**.\n3. Navigate to `chrome://arc-graphics-tracing`.\n\n### Run the profiler\n\n1. Select **stop on jank**.\n2. Run the Android app.\n3. When the Android app is active and has focus, press \u003ckbd\u003eControl\u003c/kbd\u003e+\u003ckbd\u003eShift\u003c/kbd\u003e+\u003ckbd\u003eG\u003c/kbd\u003e.\n\nWhen some jank happens, a browser window pops up.\nUse the \u003ckbd\u003eW\u003c/kbd\u003e and \u003ckbd\u003eS\u003c/kbd\u003e keys to zoom and shrink the timeline."]]
