تشخیص انحراف رابط کاربری
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
اندروید با ایجاد یک فریم از برنامه شما و نمایش آن بر روی صفحه، رابط کاربری را رندر می‌کند. اگر برنامه شما از رندر آهسته رابط کاربری رنج می برد، سیستم مجبور به رد شدن از فریم ها می شود. هنگامی که این اتفاق می افتد، کاربر یک سوسو زدن مکرر را روی صفحه نمایش خود مشاهده می کند که به آن jank گفته می شود.
هنگامی که jank رخ می دهد، معمولاً به دلیل کاهش سرعت یا مسدود کردن تماس ناهمگام در رشته رابط کاربری است (در اکثر برنامه ها، این موضوع اصلی است). می توانید از ردیابی سیستم برای شناسایی محل مشکل استفاده کنید.
جک را در اندروید 12 و بالاتر شناسایی کنید
برای دستگاه‌هایی که از Android 12 (سطح API 31) یا بالاتر استفاده می‌کنند، یک ردگیری گرفته شده در مسیر فریم‌های Janky در زیر صفحه نمایش در نمایه CPU نشان داده می‌شود.
برای تشخیص جنک،
در Android Studio، View > Tool Windows > Profiler را انتخاب کنید یا روی Profile کلیک کنید 
در نوار ابزار
اگر از کادر گفتگوی Select Deployment Target خواسته شد، دستگاهی را انتخاب کنید که برنامه خود را برای نمایه سازی در آن مستقر کنید. اگر دستگاهی را از طریق USB وصل کرده اید اما آن را در لیست نمی بینید، مطمئن شوید که اشکال زدایی USB را فعال کرده اید.
روی هر نقطه از جدول زمانی CPU کلیک کنید تا نمایه CPU باز شود.
System Trace را از منوی تنظیمات در CPU Profiler انتخاب کنید و روی Record کلیک کنید. پس از پایان تعامل با برنامه، روی Stop کلیک کنید.
شما باید تراک فریم های Janky را در زیر نمایشگر ببینید. به طور پیش فرض، Profiler فقط فریم های janky را به عنوان کاندیدای بررسی نشان می دهد. در داخل هر فریم جنکی، قسمت قرمز مدت زمانی را که فریم از مهلت رندر خود می گذراند، برجسته می کند. 
هنگامی که یک قاب جنکی پیدا کردید، روی آن کلیک کنید. به صورت اختیاری، می توانید M را فشار دهید تا زوم را برای تمرکز بر فریم انتخاب شده تنظیم کنید. رویدادهای مربوطه در این رشته ها برجسته می شوند: رشته اصلی، RenderThread و تکمیل GPU . 
می‌توانید به‌ترتیب با جابه‌جایی چک باکس‌های All Frames و Lifecycle ، همه فریم‌ها یا تفکیک زمان رندر را مشاهده کنید. 
جک را در اندروید 11 شناسایی کنید
برای دستگاه‌هایی که از Android 11 (سطح API 30) استفاده می‌کنند، یک ردیابی ثبت شده در بخش چرخه زندگی فریم در نمایه CPU نشان داده می‌شود.
بخش Frame Lifecycle شامل نام لایه و چهار آهنگ است. هر مسیر نشان دهنده یک مرحله در خط لوله رندر فریم است. عناصر چرخه حیات فریم به شرح زیر است:
- چرخه حیات قاب (نام لایه) : عنوان بخش حاوی نام لایه در پرانتز است. یک لایه یک واحد ترکیب است.
- Application : این آهنگ از زمانی که بافر توسط برنامه در صف قرار می‌گیرد تا زمانی که در صف قرار می‌گیرد را نشان می‌دهد. این معمولاً با رویدادهای ردیابی در
RenderThread مطابقت دارد. - Wait for GPU : این آهنگ نشان می دهد که چه مدت بافر متعلق به GPU بوده است. این زمان از زمانی است که بافر به GPU ارسال می شود تا زمانی که GPU کار خود را بر روی بافر تمام می کند. این نشان نمی دهد که GPU در این مدت فقط روی این بافر کار می کرد. برای اطلاعات دقیق در مورد آنچه که GPU در یک زمان معین روی آن کار می کند، ممکن است بخواهید از Android GPU Inspector استفاده کنید.
- ترکیب : این آهنگ زمان شروع از زمانی که SurfaceFlinger به بافر متصل می شود و آن را برای ترکیب ارسال می کند تا زمانی که بافر به نمایشگر ارسال می شود را نشان می دهد.
- قاب‌های روی صفحه : این آهنگ نشان می‌دهد که فریم چقدر روی صفحه بوده است.
بخش Frame Lifecycle نحوه حرکت یک فریم بافر بین مراحل مختلف خط لوله رندر را نشان می دهد. قاب ها با شماره قاب کدگذاری شده اند تا ردیابی یک فریم خاص آسان تر باشد.
اندروید استودیو همچنین تمامی فریم های موجود در ردیابی را در قالب جدول در تب All Frames نشان می دهد.
ستون‌های Frame # ، Application ، Wait for GPU و Composition همان داده‌هایی را نشان می‌دهند که در بخش Frame Lifecycle در بالا وجود دارد. ستون Frame Duration نشان دهنده زمان از شروع برنامه تا شروع Frames on Display است. این اساساً مدت زمانی است که طول می کشد تا یک فریم به صورت انتها به انتها ارائه شود.
می‌توانید جدول فریم‌ها را بر اساس هر ستونی مرتب کنید تا کوتاه‌ترین یا طولانی‌ترین فریم را سریع پیدا کنید. این جدول همچنین از کنترل های صفحه بندی پشتیبانی می کند که به شما کمک می کند در میان صدها فریم حرکت کنید.
برای شناسایی و بررسی jank در اندروید 11، این مراحل را دنبال کنید:
جدول All Frames را بر اساس ستون Application به ترتیب نزولی مرتب کنید تا فریم هایی که بیشترین طول را دارند ابتدا ظاهر شوند.
طولانی ترین فریم های در حال اجرا را پیدا کنید و ردیف جدول را انتخاب کنید. این روی قاب انتخابی در نمای خط زمانی سمت چپ بزرگنمایی می‌کند.
در بخش‌های Frame Lifecycle و Threads به دنبال رشته‌های مرتبط بگردید.
جک را در اندروید ۱۰ و پایین‌تر شناسایی کنید
برای دستگاه‌هایی که از Android 10 (سطح API 29) و پایین‌تر استفاده می‌کنند، اطلاعات مربوط به خط لوله گرافیکی سیستم‌عامل در یک بخش در ردیابی سیستم نمایه CPU به نام Display نمایش داده می‌شود.
- Frames : این بخش رشته UI و رویدادهای ردیابی
RenderThread را در برنامه شما نشان می دهد. رویدادهایی که بیش از 16 میلی‌ثانیه هستند، قرمز رنگ می‌شوند تا فریم‌های بالقوه janky برجسته شوند، زیرا از مهلت رندر با سرعت 60 فریم در ثانیه (فریم بر ثانیه) فراتر می‌روند. - SurfaceFlinger : این بخش نشان می دهد که SurfaceFlinger چه زمانی بافرهای فریم را پردازش می کند. SurfaceFlinger یک فرآیند سیستمی است که وظیفه ارسال بافرها برای نمایش را بر عهده دارد.
- VSYNC : این بخش VSYNC را نشان می دهد، سیگنالی که خط لوله نمایش را همگام می کند. آهنگ سیگنال برنامه VSYNC را نشان می دهد، که نشان می دهد برنامه شما خیلی دیر شروع می شود. به طور معمول، این اتفاق می افتد زیرا رشته UI مشغول است. این باعث می‌شود که یک سوسو زدن قابل مشاهده بر روی صفحه نمایش شما در طول یک انیمیشن ظاهر شود و تا زمانی که انیمیشن یا اسکرول کامل شود، تاخیر ورودی اضافی اضافه می‌کند. این به ویژه برای نمایشگرهای با نرخ تازه سازی بالا بسیار مهم است، زیرا ممکن است بیشتر از 60 بار در ثانیه یا با نرخ متغیر رخ دهند.
- BufferQueue : این بخش نشان می دهد که چه تعداد بافر فریم در صف قرار گرفته اند و منتظر مصرف SurfaceFlinger هستند. برای برنامه‌های مستقر در دستگاه‌های دارای Android 9 (سطح API 28) یا بالاتر، این آهنگ تعداد بافر سطح برنامه BufferQueue (
0 ، 1 ، یا 2 ) را نشان می‌دهد. BufferQueue می تواند به شما در درک وضعیت بافرهای تصویر هنگام حرکت بین اجزای گرافیکی اندروید کمک کند. به عنوان مثال، مقدار 2 به این معنی است که برنامه در حال حاضر دارای سه بافر است، که منجر به تاخیر ورودی اضافی می شود.
بخش Display سیگنال‌های مفیدی را برای تشخیص jank بالقوه ارائه می‌دهد - به عنوان مثال، زمانی که رشته UI یا RenderThread بیش از 16 میلی‌ثانیه طول بکشد. برای بررسی جزئیات دقیق آنچه باعث jank شده است، می توانید بخش Threads را بررسی کنید که رشته های مرتبط با رندر UI را نشان می دهد.
در شکل بالا، بخش Threads رشته رابط کاربری ( java.com.google.samples.apps.iosched )، RenderThread و رشته GPU completion را نشان می دهد. اینها موضوعات مرتبط با رندر رابط کاربری هستند و ممکن است به jank کمک کنند.
برای شناسایی jank در Android 10 یا پایین تر، این مراحل را دنبال کنید:
به مسیر Frames در Display نگاه کنید. قاب های قرمز کاندیدای تحقیق هستند.
هنگامی که یک فریم بالقوه عجیب و غریب پیدا کردید، با فشار دادن W یا حرکت دادن چرخ ماوس در حالی که Control ( Command در macOS) را نگه دارید، بزرگنمایی کنید. بزرگنمایی را ادامه دهید تا زمانی که ردیابی رویدادها را در رشته UI و RenderThread ببینید.
در شکل بالا، Choreographer#doFrame زمانی را نشان می‌دهد که رشته رابط کاربری Choreographer برای هماهنگ کردن انیمیشن، نمایش طرح‌بندی، طراحی تصویر و فرآیندهای مرتبط فرا می‌خواند. DrawFrames زمانی را نشان می دهد که RenderThread فرم می گیرد و دستورات ترسیم واقعی را به GPU صادر می کند.
اگر یک رویداد ردیابی طولانی را مشاهده کردید، می توانید بیشتر بزرگنمایی کنید و ببینید چه چیزی ممکن است در رندر آهسته نقش داشته باشد. شکل بالا inflate در رشته UI نشان می دهد، به این معنی که برنامه زمان خود را صرف افزایش طرح بندی می کند. همانطور که در زیر نشان داده شده است، وقتی روی یکی از رویدادهای inflate زوم می کنید، می توانید دقیقاً متوجه شوید که هر جزء UI چقدر طول می کشد.
بیشتر بدانید
برای کسب اطلاعات بیشتر در مورد نحوه کاهش jank، به منابع رایج jank مراجعه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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)."]]
