这里说的交互方式应该指的是如何在非UI线程中修改UI线程中的组件。
一般来说有三种方式:
1.Activity.unOnUiThread(Runnable)
如果当前线程是UI Thread，立马执行action.run方法；否则将Runnable发送到UI Thread的event 队列中。
2. view.post(Runnable)
将action加入到UI thread 的message queue。
3.view.postDelayed(Runnable,long)同2一样，经过long时间之后将runnable发送给message queue。
5.1UI线程
当一个app启动时，系统为该app创建一个线程，成为主线程。这个主线程管理ui中的组件，包括分发事件，重绘view等。因此也叫做UI
Thread。我们还知道当默认情况下，系统并不为四大组件创建新的线程，都是运行在这个UI Thread之中，这种方式也称为单线程模型。所以一旦app中出现了耗时的工作(访问网络，写文件，读写数据库等等)有可能导致thread阻塞，如果这时系统无法及时分发事件，对于用户来说最直观的感受就是卡住了，而这时用户又不停的点击屏幕很有可能出现ANR。在设计app时要尽力避免出现ANR的出现，关于ANR请看5.2
而且UI toolkit不是线程安全的，所以一定不能从子线程中操作ui，只能在ui thread中操作ui。对于android中的这种单线程模型有两条规则
1.不要阻塞UI thread
2.不要在非UI Thread中操作UI
如果在子线程中访问ui线程中的view，会报错：android.view.ViewRootImpl$CalledFromWrongThreadException:Only
the original thread that created a view hierarchy can touch its views.
但是现实中需要进行耗时操作的场景又非常多，如果需要耗时操作，然后更新UI怎么做呢(下载图片然后更新imageview)？我们先来按照它的规则来指定自己的方案：
先按照规则1：不在UI Thread中做耗时操作，那么我们开启一个子线程来处理耗时操作，然后再更新view
newThread(new Runnable(){
public void run(){
//模拟耗时操作，比如上网下载图片
Bitmap b = loadBitmapFormWeb();
//不能直接访问UI Thread
imageview.setBitmap(b);//在子线程中如果直接访问UI线程，会报错，不允许这么做。
//这里可以操作runOnUiThread,imageView.post(Runnable),imageView.postDelay();
imageview.post(new Runnable(){
imageview.setImageBitmap(b);
});
}
}).start();
但是这又不符合规则2，不能在非UI Thread中操作UI。这就很矛盾了，android系统在设计时已经考虑过这个问题，所以在android系统提供了几种方式在非UI
Thread中访问UI线程:
Activity.runOnUiThread,View.post(),View.postDelayed()。
这样的话，耗时操作在子线程中执行，UI 更新在UI Thread中执行，两者互不干扰。
如果子线程过多时，代码就会显得很臃肿、可读性不好。所以android
系统中集成了一个AsyncTask工具类用来包装Thread+Handler，这个类的主要在子线程运行耗时操作，然后在UI线程更新UI。同时使得代码的可读性好多了。关于AsyncTask有专门介绍。
5.2 ANR
在使用android系统的时候或多或少可能遇到过ANR(Application
Not Responding), 类似的这种ANR对话框应该都见过。
.png)
为什么会出现:android中的所有组件默认都是在UI线程中完成的,其中有ActivityManagerService(AMS)和WindowsManagerService(WMS)会监控一个动作的响应时间，如果在一定范围内对用户交互没有处理完毕就会出现ANR。比如说分派事件,假如某一段时间内UI
线程做了耗时操作，线程阻塞了，那么用户的一个触摸事件就可能来不得及处理，超过一定的时间就会导致ANR。当然这只是ANR其中的一种出现原因。对于用于来说一旦开始交互事件没有响应，就有可能不停的触摸。这更增加了ANR的几率，对于开发者来说开发过程中一定尽量避免ANR出现的可能。
ANR出现有原因的，要同时满足几个条件:
1.主线程也就是必须在UI线程中相应超时。所以我们可以将耗时操作放在子线程中执行来避免这个条件出现。
2.超时,必须超过一定的时间限制，不同的ANR的时间限制不一样，下面有介绍。
3.交互时间或者特定操作。不同的ANR触发的时间不一样。
主要有三种ANR类型
1.KeyDispatchTimeOut(5s),主线程对用户交互事件5s中没有处理完毕(这种情况最常见):当app获得用户交互事件时(按键，触摸),系统先获得这个交互事件然后分派到这个app，分派到app之后再分派给对应的View(比如button)。如果在5s内，该交互事件没有处理完成就会通过一系列的回调函数，最终到AMS中处理该处理keyDispatchTimeOut超时。
.png)
一定要注意：出现这种ANR前提是有用户交互事件，如果没有交互事件，就算是主线程阻塞主线程也不会ANR，因为这个时候就没有事件派发。可以测试，如果仅仅是Thread.sleep(60000)，不做任何交互都不会出现ANR（看具体的设备和系统，我的荣耀3c畅玩版就不会出现，HTC的就出现）。
2.BroadcastTimeOut(10s)BroadcastReceiver 中的onReceiver方法执行超过10s。 .png)
3.ServiceTimeout(20s),service生命周期方法中执行事件超过20s。
2和3中不会产生对话框形式(和设备有关。我的华为荣耀3c畅玩版、htc都出现了)。这三种anr的出现影响最大的就是第一个，但是三者之间并不是单一出现的，有可能receiver中执行时阻塞，用户交互，系统没法及时处理该交互，出现第一种；如果receiver超时后又出现第二种。不管怎样，避免这三种操作就能最大程度的避免ANR的出现。
出现ANR时，有两个输出文件要重视:一个就是系统输出的log tag,一个就是/data/anr/traces.txt，这两个文件使我们定位ANR的利器
先看系统的log:
//ANR 在哪个进程发生了ANR
05-14 15:24:10.519: E/ActivityManager(499): ANR in com.example.servicedemo, time=1037238
//reson指明原因
05-14 15:24:10.519: E/ActivityManager(499): Reason: Broadcast of Intent { act=com.service.ACTION
flg=0x10 cmp=com.example.servicedemo/.MyReceiver }
//ago 指明ANR之前cup使用情况
05-14 15:24:10.519: E/ActivityManager(499): CPU usage from 4973ms to -1016msago:
//later指明ANR之后cpu使用情况
05-14 15:24:10.519: E/ActivityManager(499): CPU usage from 472ms to 993mslater:
再来看traces.txt内容:(目录:/data/anr/traces.txt)
----- pid 5085 at 2015-05-14 15:24:09 -----
Cmd line: com.example.servicedemo
DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0)
"main" prio=5 tid=1 TIMED_WAIT
| group="main" sCount=1 dsCount=0 obj=0x40ae3490 self=0x15cad58
| sysTid=5085 nice=0 sched=0/0 cgrp=default handle=1074472136
| schedstat=( 0 0 0 ) utm=17 stm=6 core=0
at java.lang.VMThread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:1047)
at java.lang.Thread.sleep(Thread.java:1029)
at com.example.servicedemo.MyReceiver.onReceive(MyReceiver.java:19)
这两个信息是如何输出的:在ams中的appNotResponding函数:
synchronized (this) {
//在某些情况下忽略ANR
// PowerManager.reboot() can block for a long time, so ignore ANRs while shutting down.
if (mShuttingDown) {
Slog.i(TAG, "During shutdown skipping ANR: " + app + " " + annotation);
return;
} else if (app.notResponding) {
Slog.i(TAG, "Skipping duplicate ANR: " + app + " " + annotation);
return;
} else if (app.crashing) {
Slog.i(TAG, "Crashing app skipping ANR: " + app + " " + annotation);
return;
}
//.....
// Log the ANR to the main log.
StringBuilder info = mStringBuilder;
info.setLength(0);
info.append("ANR in ").append(app.processName);
if (activity != null && activity.shortComponentName != null) {
info.append(" (").append(activity.shortComponentName).append(")");
}
info.append("\n");
if (annotation != null) {
info.append("Reason: ").append(annotation).append("\n");
}
if (parent != null && parent != activity) {
info.append("Parent: ").append(parent.shortComponentName).append("\n");
}
//指定traces文件保存地址
File tracesFile = dumpStackTraces(true, firstPids, processStats, lastPids);
String cpuInfo = null;
if (MONITOR_CPU_USAGE) {
updateCpuStatsNow();
synchronized (mProcessStatsThread) {
cpuInfo = mProcessStats.printCurrentState(anrTime);
}
//anr之前cpu负载信息
info.append(processStats.printCurrentLoad());
info.append(cpuInfo);
}
//anr之后cpu负载信息
info.append(processStats.printCurrentState(anrTime));
//将anr信息加入到dropBox中(管理log的工具)
addErrorToDropBox("anr", app, activity, parent, annotation, cpuInfo, tracesFile, null);
// Unless configured otherwise, swallow ANRs in background processes & kill the process.
//读取用户配置，是否显示后台进程anr对话框。不显示就直接杀死
boolean showBackground = Settings.Secure.getInt(mContext.getContentResolver(),
Settings.Secure.ANR_SHOW_BACKGROUND, 0) != 0;
synchronized (this) {
//设置为后台不显示anr dialong
if (!showBackground && !app.isInterestingToUserLocked() && app.pid != MY_PID) {
Slog.w(TAG, "Killing " + app + ": background ANR");
EventLog.writeEvent(EventLogTags.AM_KILL, app.pid,
app.processName, app.setAdj, "background ANR");
Process.killProcessQuiet(app.pid);//杀死进程
return;
}
// Bring up the infamous App Not Responding dialog，发送信息给mHandler，提示可以显示ANR对话框
Message msg = Message.obtain();
HashMap map = new HashMap();
msg.what = SHOW_NOT_RESPONDING_MSG;
msg.obj = map;
map.put("app", app);
if (activity != null) {
map.put("activity", activity);
}
mHandler.sendMessage(msg);
mHandler中handleMessage函数中相应的处理为:
case SHOW_NOT_RESPONDING_MSG: {
synchronized (ActivityManagerService.this) {
Dialog d = new AppNotRespondingDialog(ActivityManagerService.this,
mContext, proc, (ActivityRecord)data.get("activity"));
d.show();//显示anr对话框
}
} break;
如何避免:ANR产生的原因是因为在主线程中执行了耗时的操作,所以将耗时操作方法在子线程中执行，可以使用handler+thread 或者AsyncTask方式。
同时为了给用户好的体验，也有几个建议:
1.执行耗时操作时，给用户ui提示,比如进度对话框。
2.游戏类app用子线程计算。
3.应用程序的初始化，可以使用一个splash或者过场动画，这种使用的很多，比如一开始打开app时显示一张欢迎图片(天天动听)，这样既给用户app正在响应的感觉，同时可以执行耗时操作。