اكتشاف البيانات غير المحتملة في واجهة المستخدم
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يعرض Android واجهة المستخدم من خلال إنشاء إطار من تطبيقك وعرضه على الشاشة. إذا كان تطبيقك يعاني من بطء في عرض واجهة المستخدم، فسيضطر النظام إلى تخطي الإطارات. وعند حدوث ذلك، يلاحظ المستخدم وميضًا متكررًا على الشاشة، وهو ما يُشار إليه باسم إزالة المشاكل.
يحدث هذا العطل عادةً بسبب بعض التباطؤ أو حظر الطلب غير المتزامن على سلسلة محادثات واجهة المستخدم (في معظم التطبيقات، تكون سلسلة المحادثات الرئيسية في معظم التطبيقات). يمكنك استخدام مسارات
النظام لتحديد مكان المشكلة.
رصد المشاكل غير المحتملة على نظام التشغيل Android 12 والإصدارات الأحدث
بالنسبة إلى الأجهزة التي تستخدم Android 12 (مستوى واجهة برمجة التطبيقات 31) أو الإصدارات الأحدث، يظهر تتبُّع تم التقاطه
في مسار الإطارات غير المستقرة ضمن لوحة الشاشة في أداة تحليل وحدة المعالجة المركزية (CPU).
لاكتشاف عدم فقدان البيانات،
في "استوديو Android"، اختَر عرض > أداة Windows > محلّل أو انقر على الملف الشخصي
في شريط الأدوات.
إذا طُلب منك ذلك من خلال مربع الحوار اختيار هدف النشر، اختَر الجهاز
الذي تريد نشر تطبيقك عليه لتحديد المواصفات. في حال توصيل جهاز باستخدام USB
ولكنه لم يظهر لك ضمن القائمة، تأكّد من أنّك فعّلت
ميزة "تصحيح أخطاء الجهاز عبر USB".
انقر في أي مكان في المخطط الزمني لوحدة المعالجة المركزية (CPU) لفتح محلّل وحدة المعالجة المركزية (CPU).
اختَر System Trace (تتبُّع النظام) من قائمة الإعدادات في أداة تحليل وحدة المعالجة المركزية (CPU) وانقر على تسجيل. بعد الانتهاء من التفاعل مع تطبيقك، انقر على إيقاف.
من المفترض أن يظهر لك مسار الإطارات غير الواضحة ضمن العرض. بشكل افتراضي، لا يعرض الملف الشخصي
إلا الإطارات غير المهمة كمرشح للتحقيق. ضمن كل إطار غير مستقر، يبرز الجزء الأحمر المدة التي يتخطى فيها الإطار
الموعد النهائي للعرض.
عند العثور على إطار غير مستقر، انقر عليه، وبشكل اختياري، يمكنك الضغط على M لضبط التكبير أو التصغير للتركيز على الإطار المحدد. يتم إبراز الأحداث ذات الصلة في سلاسل المحادثات التالية: سلسلة التعليمات الرئيسية وRenderThread وإكمال وحدة معالجة الرسومات.
يمكنك اختياريًا عرض جميع الإطارات أو عرض تحليل وقت العرض من خلال التبديل بين مربّعَي الاختيار جميع الإطارات ورحلة المستخدم على التوالي.
رصد الأعطال على Android 11
بالنسبة إلى الأجهزة التي تستخدم نظام التشغيل Android 11 (المستوى 30 لواجهة برمجة التطبيقات)، يظهر تتبُّع تم تسجيله في قسم
مراحل نشاط الإطار في محلّل وحدة المعالجة المركزية (CPU).
يحتوي قسم دورة حياة الإطار على اسم الطبقة وأربعة مسارات. ويمثل كل مسار مرحلة واحدة في مسار عرض الإطار. في ما يلي عناصر رحلة
الإطار:
- دورة حياة الإطار (اسم الطبقة): يحتوي عنوان القسم على اسم الطبقة
بين قوسين. الطبقة هي وحدة تركيب واحدة.
- التطبيق: يعرض هذا المسار الوقت المنقضي منذ أن أزال التطبيق المخزن المؤقت من قائمة الانتظار وحتى تمت إضافته مرة أخرى إلى قائمة الانتظار. ويتجاوب هذا عادةً مع أحداث
تتبُّع الأحداث في
RenderThread.
- انتظار وحدة معالجة الرسومات: يعرض هذا المسار مدة امتلاك وحدة معالجة الرسومات للمخزن المؤقت. وهذا هو الوقت منذ إرسال المخزن المؤقت إلى وحدة معالجة الرسومات إلى حين انتهاء وحدة معالجة الرسومات من عملها على المخزن المؤقت. ولا يشير هذا إلى أن وحدة معالجة الرسومات كانت تعمل فقط على هذا المخزن المؤقت خلال هذه الفترة. للحصول على معلومات تفصيلية حول الوحدات التي تعمل عليها وحدة معالجة الرسومات خلال فترة معيّنة، ننصحك باستخدام أداة Android GPU Inspector (أداة فحص وحدة معالجة الرسومات من Android).
- المقطوعة الموسيقية: تشير هذه الأغنية إلى الوقت الذي يوضع فيه SurfaceFlinger في مرحلة المخزن المؤقت، ويرسله لتركيبه إلى حين إرسال المخزن المؤقت إلى الشاشة.
- الإطارات على الشاشة: يعرض هذا المسار مدة ظهور الإطار على الشاشة.
يوضّح القسم دورة حياة الإطار كيفية تحرك المخزن المؤقت للإطارات بين المراحل المختلفة لمسار العرض. يتم ترميز الإطارات بالألوان حسب رقم
الإطار بحيث يسهل تتبع إطار معين.
ويعرض "استوديو Android" أيضًا جميع الإطارات في التتبُّع بتنسيق جدول في علامة التبويب جميع
الإطارات.
تمثل أعمدة رقم الإطار والتطبيق وانتظار وحدة معالجة الرسومات
والتكوين البيانات نفسها مثل المسارات في قسم دورة حياة الإطار كما هو موضح أعلاه. يمثل العمود Frame Duration الوقت من بداية Application إلى بداية Frames on Display. وهي في الأساس المدة التي يستغرقها عرض الإطار من البداية إلى النهاية.
يمكنك فرز جدول الإطارات حسب أي عمود للعثور بسرعة
على الإطار الأقصر أو الأطول. يوفّر الجدول أيضًا عناصر التحكّم في التقسيم على صفحات والتي تساعدك في التنقّل بين مئات الإطارات.
لرصد المشاكل غير المحتملة والتحقيق فيها على نظام التشغيل Android 11، اتَّبِع الخطوات التالية:
رتِّب جدول جميع الإطارات حسب عمود التطبيق بترتيب تنازلي
بحيث تظهر الإطارات التي تستغرق أطول مدة أولاً.
ابحث عن أطول الإطارات قيد التشغيل واختَر صف الجدول. يؤدي ذلك إلى تكبير الإطار المحدد في عرض المخطط الزمني إلى اليسار.
ابحث عن سلاسل المحادثات ذات الصلة في قسمَي مراحل نشاط الإطارات وسلاسل المحادثات.
رصد الأعطال على Android 10 والإصدارات الأقدم
بالنسبة إلى الأجهزة التي تعمل بنظام التشغيل Android 10 (المستوى 29 لواجهة برمجة التطبيقات) والإصدارات الأقدم، يتم عرض معلومات مسار رسومات نظام التشغيل ذات الصلة
في قسم واحد ضمن مسار نظام محلّل وحدة المعالجة المركزية (CPU) باسم الشاشة.
- الإطارات: يعرض هذا القسم سلسلة محادثات واجهة المستخدم و
RenderThread تتبُّع الأحداث
في تطبيقك. ويتم تمييز الأحداث التي تزيد مدتها عن 16 ملي ثانية باللون الأحمر
لتسليط الضوء على الإطارات البطيئة المحتملة لأنّها تتجاوز الموعد النهائي للعرض
بسرعة 60 لقطة في الثانية.
- SurfaceFlinger: تعرض هذه الصفحة الحالات التي يعالج فيها جهاز SurfaceFlinger التخزين المؤقت للإطارات. SurfaceFlinger هي عملية نظام مسؤولة عن إرسال المخازن المؤقتة لعرضها.
- VSYNC: يعرض هذا القسم إشارة VSYNC، وهي إشارة تعمل على مزامنة
مسار العرض. ويعرض المسار إشارة تطبيق VSYNC، التي تظهر عندما يبدأ تطبيقك متأخرًا. عادةً ما يحدث هذا لأن مؤشر ترابط
واجهة المستخدم مشغول. يتسبب ذلك في ظهور وميض مرئي على شاشتك أثناء إضافة صورة متحركة، ويضيف وقت استجابة إدخالاً إضافيًا إلى أن تكتمل الصورة المتحركة أو التمرير.
يُعتبَر ذلك مهمًا على وجه الخصوص إذا تم عرضها على الشاشات ذات معدّل التحديث العالي، إذ إنّها قد تتكرّر أكثر من 60 مرّة في الثانية أو بمعدّل متغير.
- BufferQueue: يعرض هذا القسم عدد المخازن المؤقتة للإطارات التي تم وضعها في قائمة الانتظار وتنتظر استهلاك SurfaceFlinger. بالنسبة إلى التطبيقات المنشورة على الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android (المستوى 28 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث، يعرض هذا المسار عدد المخزن المؤقت للمساحة الإجمالية للتطبيق
قائمة الانتظار المؤقت
(
0 أو 1 أو 2). ويمكن أن تساعدك قائمة الانتظار المؤقت في فهم حالة مخازن الصور
أثناء تنقّلها بين مكوّنات رسومات Android. على سبيل المثال، تعني القيمة
2 أنّ التطبيق مخزَّن مؤقتًا ثلاث مرات حاليًا، ما يؤدي إلى زيادة وقت الاستجابة
للإدخال.
يوفّر قسم الشاشة إشارات مفيدة لرصد البيانات غير الدقيقة المحتملة، على سبيل المثال، عندما تستغرق سلسلة تعليمات واجهة المستخدم أو RenderThread مدة أطول من 16 ملي ثانية. وللتحقّق من التفاصيل الدقيقة حول سبب عدم دقّة البيانات، يمكنك فحص قسم السلاسل الذي يعرض سلاسل المحادثات ذات الصلة بعرض واجهة المستخدم.
في الشكل أعلاه، يعرض قسم سلاسل المحادثات سلسلة تعليمات واجهة المستخدم
(java.com.google.samples.apps.iosched) وRenderThread وسلسلة
سلاسل المحادثات GPU completion. هذه هي سلاسل المحادثات ذات الصلة بعرض واجهة المستخدم وقد تساهم في البيانات غير الواضحة.
لاكتشاف الأجهزة غير المحتملة على Android 10 أو الإصدارات الأقدم، اتَّبِع الخطوات التالية:
انظر إلى مسار الإطارات في الشاشة. الإطارات الحمراء هي
المرشحة للتحقيق.
عند العثور على إطار من المحتمل أن يكون بطيئًا، يمكنك تكبيره بالضغط على W أو
تمرير عجلة الماوس أثناء الضغط مع الاستمرار على Control
(Command على نظام التشغيل macOS). واصِل التكبير حتى تبدأ في رؤية أحداث التتبُّع في سلسلة محادثات واجهة المستخدم وRenderThread.
في الشكل أعلاه، توضّح Choreographer#doFrame الحالات التي تستدعي فيها سلسلة واجهة المستخدم
Choreographer لتنسيق الرسوم المتحركة
وتنسيق العرض ورسم الصورة والعمليات ذات الصلة. DrawFrames
يظهر هذا الرمز عندما يتم إصدار RenderThread في شكل أوامر رسم ويصدرها إلى وحدة معالجة الرسومات.
إذا لاحظت عملية تتبُّع طويلة جدًا، يمكنك تكبيرها ومعرفة السبب المحتمَل وراء بطء العرض. يُظهر الشكل أعلاه inflate في سلسلة واجهة المستخدم،
مما يعني أن التطبيق يقضي وقتًا في تضخيم التنسيق.
عند تكبير أحد أحداث inflate، يمكنك معرفة المدة التي يستغرقها كل مكوِّن في واجهة المستخدم بالضبط، كما هو موضّح أدناه.
مزيد من المعلومات
لمزيد من المعلومات حول كيفية الحدّ من البيانات غير المرغوب فيها، يُرجى الاطّلاع على
المصادر الشائعة للبيانات غير المرغوب فيها.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ 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,["# UI jank detection\n\nAndroid renders UI by generating a frame from your app and displaying it on\nthe screen. If your app suffers from slow UI rendering, then the system is\nforced to skip frames. When this happens, the user perceives a recurring flicker\non their screen, which is referred to as *jank*.\n\nWhen jank occurs, it's usually because of some deceleration or blocking async\ncall on the UI thread (in most apps, it's the main thread). You can use system\ntraces to identify where the problem is.\n\nDetect jank on Android 12 and higher\n------------------------------------\n\nFor devices using Android 12 (API level 31) or higher, a captured trace is shown\nin the **Janky frames** track under the **Display** pane in the CPU Profiler.\n\nTo detect jank,\n\n1. In Android Studio, select **View \\\u003e Tool Windows \\\u003e Profiler** or click **Profile**\n in the toolbar.\n\n If prompted by the **Select Deployment Target** dialog, choose the device to\n which to deploy your app for profiling. If you've connected a device over USB\n but don't see it listed, ensure that you have\n [enabled USB debugging](/studio/debug/dev-options#enable).\n2. Click anywhere in the **CPU** timeline to open the CPU Profiler.\n\n3. Select **System Trace** from the configurations menu in the CPU Profiler and\n click **Record** . After you finish interacting with your app, click **Stop**.\n\n4. You should see the **Janky frames** track under **Display** . By default, the\n Profiler only shows janky frames as candidates for investigation. Within each\n janky frame, the red portion highlights the duration the frame takes past its\n rendering deadline.\n\n5. Once you find a janky frame, click on it; optionally, you can press **M** to\n adjust the zoom to focus on the selected frame. The relevant events are\n highlighted in these threads: the main thread, **RenderThread** and\n **GPU completion** .\n\n6. You can optionally see all frames or a breakdown of the rendering time by\n toggling the checkboxes **All Frames** and **Lifecycle** , respectively.\n\nDetect jank on Android 11\n-------------------------\n\nFor devices using Android 11 (API level 30), a captured trace is shown in the\n**Frame Lifecycle** section in the CPU Profiler.\n\nThe **Frame Lifecycle** section contains the layer name and four tracks. Each\ntrack represents one stage in the frame rendering pipeline. The **Frame\nLifecycle** elements are as follows:\n\n1. **Frame Lifecycle (Layer name)** : The section title contains the layer name in parentheses. A *layer* is a single unit of composition.\n2. **Application** : This track shows the time from when the buffer was dequeued by the app to when it was enqueued back. This usually corresponds to the trace events in `RenderThread`.\n3. **Wait for GPU** : This track shows how long the buffer was owned by the GPU. This is the time from when the buffer is sent to the GPU to when the GPU finishes its work on the buffer. **This does not indicate that the GPU was working only on\n this buffer during this time.** For detailed info on what the GPU works on during a given time, you may want to use [Android GPU Inspector](/agi).\n4. **Composition**: This track shows the time starting from when SurfaceFlinger latches on to the buffer and sends it for composition, to when the buffer is sent to the display.\n5. **Frames on display**: This track shows how long the frame was on the screen.\n\nThe **Frame Lifecycle** section illustrates how a frame buffer moves between\ndifferent stages of the rendering pipeline. The frames are color coded by frame\nnumber so that it's easier to track a particular frame.\n\nAndroid Studio also shows all frames in the trace in a table format in the **All\nFrames** tab.\n\nThe **Frame #** , **Application** , **Wait for GPU** , and\n**Composition** columns represent the same data as the tracks in the **Frame\nLifecycle** section as above. The column **Frame Duration** represents the time\nfrom the start of **Application** to the start of **Frames on Display**. This is\nessentially how long it takes to render a frame end-to-end.\n\nYou can sort the frames table by any column to quickly find the shortest or\nlongest frame. The table also supports pagination controls that help you navigate\nthrough hundreds of frames.\n\nTo detect and investigate jank on Android 11, follow these steps:\n\n1. Sort the **All Frames** table by the **Application** column in descending\n order, so that the frames that take the longest appear first.\n\n2. Find the longest running frames and select the table row. This zooms in on\n the selected frame in the timeline view to the left.\n\n3. Look for relevant threads in the **Frame Lifecycle** and **Threads** sections.\n\nDetect jank on Android 10 and lower\n-----------------------------------\n\nFor devices using Android 10 (API level 29) and lower, relevant OS graphics\npipeline information is displayed in a single section on the CPU Profiler system\ntrace called **Display**.\n\n- **Frames** : This section shows the UI thread and `RenderThread` trace events in your app. Events that are longer than 16ms are colored red to highlight potential janky frames because they exceed the deadline to render at 60 frames per second (fps).\n- **SurfaceFlinger**: This section shows when the SurfaceFlinger processes the frame buffers. SurfaceFlinger is a system process that is responsible for sending buffers to display.\n- **VSYNC**: This section displays the VSYNC, a signal that synchronizes the display pipeline. The track displays the VSYNC-app signal, which shows when your app is starting too late. Typically, this occurs because the UI thread is busy. It causes a visible flicker to appear on your screen during an animation and adds extra input latency until the animation or scroll completes. This is especially important to view for high-refresh-rate displays, as they may occur more frequently than 60 times per second or at a variable rate.\n- **BufferQueue** : This section shows how many frame buffers are queued up and are waiting for SurfaceFlinger to consume. For apps deployed to devices running Android 9 (API level 28) or higher, this track shows the buffer count of the app's surface [BufferQueue](https://source.android.com/devices/graphics#bufferqueue) (`0`, `1`, or `2`). BufferQueue can help you understand the state of image buffers as they move between the Android graphics components. For example, a value of `2` means that the app is currently triple-buffered, which results in extra input latency.\n\nThe **Display** section provides useful signals to detect potential jank---for\nexample, when the UI thread or `RenderThread` takes longer than 16 ms. To investigate\nexact details of what caused the jank, you can probe the **Threads**\nsection, which shows the threads relevant to UI rendering.\n\nIn the figure above, the **Threads** section shows the UI thread\n(`java.com.google.samples.apps.iosched`), `RenderThread`, and the `GPU completion`\nthread. These are the threads relevant to UI rendering and may contribute to\njank.\n\nTo detect jank on Android 10 or lower, follow these steps:\n\n1. Look at the **Frames** track in **Display**. The red frames are candidates\n for investigation.\n\n2. Once you find a potentially janky frame, zoom in by pressing `W` or\n scrolling the mouse wheel while holding \u003ckbd\u003eControl\u003c/kbd\u003e\n (\u003ckbd\u003eCommand\u003c/kbd\u003e on macOS). Continue zooming in until you start to see the\n trace events in the UI thread and `RenderThread`.\n\n In the figure above, `Choreographer#doFrame` shows when the UI thread calls\n [`Choreographer`](/reference/android/view/Choreographer) to coordinate\n animation, view layout, image drawing, and related processes. `DrawFrames`\n shows when `RenderThread` forms and issues actual drawing commands to the GPU.\n3. If you see a particularly long trace event, you can zoom in further and find out\n what may have contributed to the slow rendering. The figure above shows `inflate`\n in the UI thread, which means the app is spending time on inflating the layout.\n When you zoom into one of the `inflate` events, you can find out exactly how long\n each UI component is taking, as shown below.\n\nLearn more\n----------\n\nTo learn more about how to reduce jank, see\n[Common sources of jank](/topic/performance/vitals/render#common-jank)."]]
