一切从Android的Handler讲起(七):Handler在Android系统框架层的应用
前面的篇章,肥柴已经分析了Handler的消息处理机制,以及Android触摸事件原理——消息的来与与分发。那么既然有这套消息机制,Android官方必然有运用它的地方。
反应过来的读者已经知道肥柴要说啥了,没错,就是四大组件的生命周期。四大组件的生命周期就是遵循了事件驱动模型,它们均是由Android系统框架层产生相应的Message发送到UI的MessageQueue中触发的。
那么既然遵循事件驱动模型,就必然存在用于处理消息的Handler,Android源码的ActivityThread内部类H,就是用于处理对应Message的Handler。
/** ActivityThread.class */
class H extends Handler {
public static final int BIND_APPLICATION = 110;
@UnsupportedAppUsage
public static final int EXIT_APPLICATION = 111;
@UnsupportedAppUsage
public static final int RECEIVER = 113;
@UnsupportedAppUsage
public static final int CREATE_SERVICE = 114;
@UnsupportedAppUsage
public static final int SERVICE_ARGS = 115;
@UnsupportedAppUsage
public static final int STOP_SERVICE = 116;
// ......
public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
switch (msg.what) {
// ......
case BIND_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "serviceBind");
handleBindService((BindServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
// ......
}
Object obj = msg.obj;
if (obj instanceof SomeArgs) {
((SomeArgs) obj).recycle();
}
if (DEBUG_MESSAGES) Slog.v(TAG, "<<< done: " + codeToString(msg.what));
}
}
这里我们看到msg的obj是一个BindServiceData对象,而这个对象内部又有一个IBinder变量,这也就意味着Activity的生命周期是通过IPC通讯传递的。那么我们就得从启动一个Activity说起,肥柴在Android进阶知识(二十七):Activity的启动过程中详细介绍了Activity的启动过程,具体的流程如下。
这里是基于Android 10.0之后版本代码的调用启动Activity过程,肥柴稍微简化为如下流程。
总结来说:在应用进程调用启动Activity方法后,通过IPC请求,在SystemServer进程的ATMS中找到对应的Activity并创建,之后通过Binder的IPC通信回调到ApplicationThread,由于ApplicationThread处于Binder线程,因此需要通过Handler切换到UI线程。
这里我们也就引出了平时一直在说的一个注意项:在UI线程的生命周期做繁重的耗时任务会导致UI卡顿或者ANR。
由于任何UI线程的业务代码均逃离不了组件的生命周期,而生命周期又源于UI queue中的message的处理,所以如果在任何一个生命周期做了耗时任务,这会导致queue中后面的message无法得到及时的处理,所以看起来就是有反应延时,也就是视觉上的卡顿,严重的会长时间得不到处理,从而导致ANR的发生。
- - - - - Handler在Android系统框架层的应用篇完 - - - - -