تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
الشكل 1. مربّع حوار ANR معروض للمستخدم
يشرح هذا المستند كيف يحدد نظام Android ما إذا كان التطبيق
لا يستجيب ويوضح كيفية الحفاظ على استجابة تطبيقك.
مهما كانت كتابة الرمز البرمجي بشكل جيد، من الممكن أن يشعر التطبيق بالبطء أو التعليق أو تجميده لفترات طويلة أو قد يستغرق وقتًا طويلاً لمعالجة الإدخال. إذا كان تطبيقك يعمل في المقدّمة وكان لا يستجيب، سيظهر للمستخدم مربّع حوار
"التطبيق لا يستجيب" (ANR)، كما هو موضّح في الشكل 1. يسمح مربع حوار ANR
للمستخدم بفرض إغلاق التطبيق. وإذا لم يكن التطبيق يعمل في المقدّمة،
سيتم إيقافه بدون تنبيه صوتي. من المهم تصميم سرعة استجابة التطبيق
لتقليل مربعات حوار ANR.
مشغِّلات ANR
بشكل عام، يعرض النظام خطأ ANR إذا لم يتمكّن التطبيق من الاستجابة للبيانات التي أدخلها المستخدم في سلسلة التعليمات الرئيسية، المعروفة أيضًا باسم سلسلة تعليمات واجهة المستخدم، ما يؤدي إلى منع النظام من معالجة أحداث إدخالات المستخدم الواردة.
على سبيل المثال، يمكن أن يحدث خطأ ANR في حال تنفيذ أحد التطبيقات لعملية حظر متعلّقة بوحدات الإدخال والإخراج، مثل الوصول إلى الشبكة، في سلسلة تعليمات واجهة المستخدم. مثال آخر هو عندما يقضي تطبيق ما الكثير من الوقت
في إنشاء هيكل متقن داخل الذاكرة أو حساب الخطوة التالية
في لعبة على مؤشر ترابط واجهة المستخدم.
في Android، يتم مراقبة استجابة التطبيق من خلال خدمتَي النظام ActivityManager وWindowManager. يعرض Android مربع حوار ANR لتطبيق
عندما يرصد أحد الحالات التالية:
عدم الاستجابة لحدث إدخال، مثل الضغط على المفتاح أو أحداث النقر على الشاشة، في غضون 5 ثوانٍ
في ما يلي نصائح عامة لتجنّب أخطاء ANR. ولمزيد من التفاصيل حول تشخيص الأنواع المختلفة من أخطاء ANR وتصحيحها،
يُرجى الاطّلاع على الصفحات الأخرى في هذا القسم.
أبقِ سلسلة التعليمات الرئيسية غير محظورة في جميع الأوقات، واستخدِم سلاسل المحادثات بشكل استراتيجي.
عدم تنفيذ عمليات حظر أو عمليات طويلة الأمد في سلسلة التعليمات الرئيسية للتطبيق
بدلاً من ذلك، يمكنك إنشاء سلسلة تعليمات للموظفين وتنفيذ معظم الأعمال فيها.
حاول تقليل أي تزايد زائد بين سلسلة التعليمات الرئيسية
والسلاسل الأخرى.
قلل أي عمل غير متعلق بواجهة المستخدم في سلسلة التعليمات الرئيسية، على سبيل المثال عند التعامل مع عمليات البث أو تشغيل الخدمات. يجب أن تقوم أي طريقة يتم تشغيلها في مؤشر ترابط واجهة المستخدم
بأقل عمل ممكن على مؤشر الترابط هذا. وعلى وجه الخصوص، يجب ألا تقدّم الأنشطة أقل قدر ممكن من عملية الإعداد في مراحل النشاط الرئيسية، مثل onCreate() وonResume(). يمكنك الاطّلاع على نظرة عامة على العمل في الخلفية للحصول على مزيد من المعلومات
حول الحلول المتاحة لجدولة العمل على سلسلة محادثات
في الخلفية والتواصل مرة أخرى مع واجهة المستخدم.
يُرجى توخي الحذر عند مشاركة مجموعات سلاسل المحادثات بين المكوّنات. لا تستخدم سلاسل التعليمات نفسها
في عمليات الحظر المُحتمل لفترة طويلة والمهام الحساسة للوقت،
مثل استلام البث.
الحفاظ على سرعة بدء تشغيل التطبيق عليك تقليل العمليات البطيئة أو المحظورة في رمز بدء تشغيل التطبيق،
مثل تنفيذ الطرق التي يتم تشغيلها أثناء إعداد الخناجر.
وقت تنفيذ BroadcastReceiver محدود، لأنّ أجهزة استقبال البث
تهدف إلى إجراء كميات صغيرة ومنفصلة من العمل في الخلفية، مثل
حفظ إعداد أو تسجيل
Notification. ولذلك، كما هو الحال مع أي طرق أخرى تستدعي سلسلة محادثات واجهة المستخدم، يجب أن تتجنّب التطبيقات العمليات أو الحسابات التي يُحتمل أن تكون طويلة الأمد في جهاز استقبال البث. بدلاً من تنفيذ المهام طويلة المدى عبر مؤشر ترابط واجهة المستخدم، يمكنك تنفيذها في الخلفية لتنفيذها لاحقًا. يمكنك الاطّلاع على نظرة عامة على العمل في الخلفية للحصول على مزيد من المعلومات حول الحلول الممكنة.
تحدث مشكلة أخرى شائعة في كائنات BroadcastReceiver عند تنفيذها بوتيرة كبيرة جدًا. قد يؤدي التنفيذ المتكرر في الخلفية إلى تقليل حجم الذاكرة المتاحة للتطبيقات الأخرى. لمزيد من المعلومات حول طريقة تفعيل عناصر BroadcastReceiver وإيقافها بكفاءة، يُرجى الاطّلاع على نظرة عامة على عمليات البث.
تعزيز الاستجابة
وبشكل عام، إنّ الحد الأدنى الذي يمكن للمستخدمين اكتشاف بطء في أداء التطبيق
هو من 100 إلى 200 ملّي ثانية. في ما يلي نصائح إضافية لجعل تطبيقك يبدو مستجيبًا للمستخدمين:
إذا كان تطبيقك يعمل في الخلفية استجابةً لإدخال المستخدمين، أظهِر أنّ تطبيقك يتم إحراز تقدم، كما هو الحال مع ProgressBar في واجهة المستخدم.
بالنسبة إلى الألعاب على وجه التحديد، عليك إجراء عمليات حسابية للحركات في سلسلة التعليمات.
إذا كانت مرحلة الإعداد الأولية لتطبيقك تستغرق وقتًا طويلاً، فننصحك بعرض شاشة بداية أو عرض طريقة العرض الرئيسية في أسرع وقت ممكن.
الإشارة إلى أن التحميل قيد التقدم لملء المعلومات بشكل غير متزامن.
في كلتا الحالتين، نوصي بالإشارة بطريقة ما إلى أن هذا التقدم يتم إحرازه،
حتى لا يلاحظ المستخدم أن التطبيق قد تم تجميده.
استخدم أدوات الأداء مثل Perfetto وCPU Profiler
لتحديد المؤثِّرات السلبية في استجابة تطبيقك.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ 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,["# Keep your app responsive\n\n**Figure 1.** An ANR dialog displayed to the user.\n\nThis document describes how the Android system determines whether an app isn't\nresponding and shows how to keep your app responsive.\n\nNo matter how well-written your code is, it's possible for your app to still\nfeel sluggish, hang, freeze for significant periods, or take too long to process\ninput. If your app is in the foreground and is unresponsive, the user gets an\nApplication Not Responding (ANR) dialog, as shown in figure 1. The ANR dialog\nlets the user force quit the app. If the app isn't in the foreground, then it's\nsilently stopped. It's critical to design responsiveness into your app to\nminimize ANR dialogs.\n\nANR triggers\n------------\n\nGenerally, the system displays an ANR if an app can't respond to user input on\nthe main thread---also known as the UI thread---preventing the system from\nprocessing incoming user input events.\n\nFor example, an ANR can occur if an app performs a blocking I/O operation, such\nas network access, on the UI thread. Another example is when an app spends too\nmuch time building an elaborate in-memory structure or computing the next move\nin a game on the UI thread.\n\nIn Android, app responsiveness is monitored by the [`ActivityManager`](/reference/android/app/ActivityManager) and\n[`WindowManager`](/reference/android/view/WindowManager) system services. Android displays the ANR dialog for an app\nwhen it detects one of the following conditions:\n\n- No response to an input event---such as key press or screen tap events---within 5 seconds.\n- A [`BroadcastReceiver`](/reference/android/content/BroadcastReceiver) doesn't finish executing within 10 to 20 seconds, for foreground intents. For more information, see [Broadcast receiver timeout](/topic/performance/anrs/diagnose-and-fix-anrs#broadcast-receiver-anr).\n\nAvoid ANRs\n----------\n\nThe following are general tips to avoid ANRs. For more details about diagnosing\nand debugging different types of ANRs, see the other pages in this section.\n\n- Keep the main thread unblocked at all times, and use threads strategically.\n\n - Don't perform blocking or long-running operations on the app's main thread.\n Instead, create a worker thread and do most of the work there.\n\n - Try to minimize any lock contention between the main thread and other\n threads.\n\n - Minimize any non-UI related work on the main thread, such as when handling\n broadcasts or running services. Any method that runs in the UI thread must\n do as little work as possible on that thread. In particular, activities must\n do as little as possible to set up in key lifecycle methods, such as\n `onCreate()` and `onResume()`. See [Background work overview](/guide/background) for more\n information about available solutions for scheduling work on a background\n thread and communicating back with the UI.\n\n - Be careful when sharing thread pools between components. Don't use the same\n threads for potentially long-blocking operations and time-sensitive tasks\n such as broadcast receiving.\n\n | **Note:** Because such threading usually is accomplished at the class level, you can think of responsiveness as a class problem. Compare this with basic code performance, which is a method-level concern.\n- Keep app startup fast. Minimize slow or blocking operations in the app's\n startup code, such as methods run during dagger initialization.\n\n- If you're using `BroadcastReceiver`, consider running broadcast receivers in a\n non-main thread using [`Context.registerReceiver`](/reference/android/content/Context#registerReceiver(android.content.BroadcastReceiver,%20android.content.IntentFilter,%20java.lang.String,%20android.os.Handler,%20int)). For more information,\n see [ANRs in BroadcastReceiver](#anrs-in-broadcast-receiver).\n\n - If you use [`goAsync()`](/reference/android/content/BroadcastReceiver#goAsync()), make sure [`PendingResult.finish`](/reference/kotlin/android/content/BroadcastReceiver.PendingResult?#finish) is called quickly before the ANR timeout.\n\nANRs in BroadcastReceiver\n-------------------------\n\n`BroadcastReceiver` execution time is constrained because broadcast receivers\nare meant to do small, discrete amounts of work in the background, such as\nsaving a setting or registering a [`Notification`](/reference/android/app/Notification). So, as with other\nmethods called in the UI thread, apps must avoid potentially long-running\noperations or calculations in a broadcast receiver. Instead of performing\nlong-running tasks via the UI thread, perform them in the background for later\nexecution. See [Background work overview](/guide/background) for more information about possible\nsolutions.\n\nAnother common issue with `BroadcastReceiver` objects occurs when they execute\ntoo frequently. Frequent background execution can reduce the amount of memory\navailable to other apps. For more information about how to enable and disable\n`BroadcastReceiver` objects efficiently, see [Broadcasts overview](/guide/components/broadcasts).\n| **Tip:** You can use [`StrictMode`](/reference/android/os/StrictMode) to help find potentially lengthy operations such as network or database operations that you might accidentally be doing on your main thread.\n\nReinforce responsiveness\n------------------------\n\nGenerally, 100 to 200ms is the threshold beyond which users perceive slowness in\nan app. Here are additional tips for making your app seem responsive to users:\n\n- If your app is doing work in the background in response to user input, show\n that progress is being made, such as with a [`ProgressBar`](/reference/android/widget/ProgressBar) in your UI.\n\n- For games specifically, do calculations for moves in a worker thread.\n\n- If your app has a time-consuming initial setup phase, consider showing a\n [splash screen](/develop/ui/views/launch/splash-screen) or rendering the main view as quickly as possible.\n Indicate that loading is in progress and fill the information asynchronously.\n In either case, we recommend indicating somehow that progress is being made,\n so that the user doesn't perceive that the app is frozen.\n\n- Use performance tools such as [Perfetto](/topic/performance/tracing) and [CPU Profiler](/studio/profile/cpu-profiler) to\n determine bottlenecks in your app's responsiveness."]]
