前言：本文所写的是博主的个人见解，如有错误或者不恰当之处，欢迎私信博主，加以改正！原文链接，demo链接
合理编写在世界各地获得性能测试的代码，但仍然觉得缓慢，挂起或冻结很长时间，或者花费太长的时间来处理输入。应用程序响应速度最糟糕的是“应用程序无响应”（ANR）对话框。
在Android中，系统会通过显示一个对话框来防止在一段时间内响应不足的应用程序，该对话框显示您的应用程序已停止响应，例如图1中的对话框。
在这一点上，您的应用程序在相当长的一段时间内没有反应，因此系统为用户提供退出应用程序的选项。设计应用程序的响应性至关重要，因此系统不会向用户显示ANR对话框。
本文档描述了Android系统如何确定应用程序是否响应，并提供了确保应用程序保持响应的准则
是什么原因引发的ANR？
通常，如果应用程序无法响应用户输入，系统将显示ANR。例如，如果应用程序上的某些I / O操作（通常是网络访问）阻塞UI线程，则系统无法处理传入的用户输入事件。或者应用程序花费太多时间来构建一个精心设计的内存结构或者计算UI线程中游戏中的下一步。确保这些计算效率非常重要，但即使最有效的代码仍然需要运行时间。
在任何情况下，你的应用程序执行一个潜在的耗时的操作，你不应该在UI线程上的执行工作，而是创建一个工作线程，并在那里进行大部分工作。这将保持UI线程（驱动用户界面事件循环）的运行，并防止系统断定您的代码已冻结。因为这样的线程通常是在类级别上完成的，所以你可以将响应能力看成类的问题。（与基本代码性能进行比较，这是一个方法级别的关注。）
在 Android 中，应用程序响应由 ActivityManager 和 WindowManager 系统服务进行监控。当检测到以下情况之一时，Android 将显示特定应用程序的 ANR 对话框：
- 在5秒内没有响应输入事件（如按键或屏幕触摸事件）。
-
BroadcastReceiver在10秒内尚未完成
如何避免ANR
默认情况下，Android应用程序通常在单线程上运行，“UI线程”或“主线程”。 这意味着您的应用程序在UI线程中执行的任务需要很长时间才能触发ANR对话框，因为您的应用程序并没有给自己一个处理输入事件或意图广播的机会。
因此，在UI线程中运行的任何方法都应该在该线程上尽可能少的工作。 特别地，Activvity 应尽可能少地在关键的生命周期方法中设置，如 onCreate() 和 onResume()。潜在的长时间运行操作（如网络或数据库操作）或计算上昂贵的计算（如调整位图大小）应在工作线程中完成（或者在数据库操作的情况下，通过异步请求）。
使用 AsyncTask 类创建一个更长时间操作的工作线程的最有效的方法。 只需扩展 AsyncTask 并实现 doInBackground() 方法来执行工作。 要向用户发布进度更改，可以调用 publishProgress()，该调用会调用 onProgressUpdate() 回调方法。 从实现 onProgressUpdate()（在UI线程上运行），您可以通知用户。 例如：
public class DownloadAsyncTask extends AsyncTask<URL,Integer,Long> {
//在这里做长时间的工作
@Override
protected Long doInBackground(URL... params) {
return null;
}
//进度更新，每次调用publishProgress()时都会调用它
@Override
protected void onProgressUpdate(Integer... values) {
super.onProgressUpdate(values);
}
//当doInBackground()完成时调用
@Override
protected void onPostExecute(Long aLong) {
super.onPostExecute(aLong);
}
}
要执行此工作线程，只需创建一个实例并调用execute():
new DownloadAsyncTask().execute(url);
你可能想要创建自己的 Thread 或 HandleThread 类，虽然它比 AsyncTask 更复杂。如果你这样做的话，应该调用Process.setThreadPriority()并传递THREAD_PRIORITY_BACKGROUND来设置线程的优先级为“background”优先级。如果没有以这种方式去设置线程为较低的优先级，那么线程有可能会减慢你的应该程序，因为默认情况下它与 UI 线程的优先级是相同的。
如果你实现了 Thread 或 HandleThread ，请确保你的 UI 线程在等待工作线程完成后不会被阻塞，请勿调用 Thread.wait() 或 Thread.sleep()。在等待工作线程完成后，主线程不应该阻塞，而需要为其他线程提供一个处理程序，以便在完成后将其返回。以这种方式设计应用程序将允许你的应用程序的 UI 线程保持对输入的响应，从而避免由5秒输入事件超时引起的 ANR 对话框。
BroadcastReceiver 执行时间的具体约束强调了广播接收者要做的事情：在后台工作量小，如保存设置或注册通知。因此，与 UI 线程中调用其他方法一样，应用程序应避免在广播接收器中潜在的长时间运行的操作或者计算，但是如果需要做耗时操作来响应意向广播，而不是通过工作线程进行密集的任务，则应该启动 IntentService。
BroadcastReceiver对象的另一个常见问题是当它们执行得太频繁时发生。频繁的后台执行减少了其他应用程序可用的内存量。
提示：你可以使用 StrictMode 来帮助找到潜在的长时间运行的操作，如网络或数据库操作，您可能会意外地在主线程上执行。
增强应用响应
通常，100到200ms是用户在应用程序中感觉的阈值，超过这个数值，用户会觉得应用程序感知迟钝。 因此，这里有一些额外的技巧，你应该做什么来避免ANR并使应用程序看起来响应用户：
- 如果你的应用程序在后台执行响应用户输入的工作，则显示正在进行进度（例如在 UI 中使用 ProgressBar）。
- 对于游戏来说，具体计算在工作线程中的进度。
- 如果您的应用程序具有耗时的初始设置阶段，请考虑显示启动屏幕或尽快呈现主视图，指示正在进行加载并异步填充信息。在这两种情况下，您应该以某种方式指出进展情况，以免用户察觉到应用程序被冻结。
- 使用 Systrace 和 Traceview 等性能工具来确定应用程序响应速度的瓶颈。
网友评论