Android中 主线程 Looper.loop() 死循环?
2017-04-30 14:31
573 查看
用过Handler的同学都应该直到,主线程默认为我们创建了Looper,所以一般情况下我们在主线程使用Handler直接new就是了,但是你会不会有个疑问,Looper里面做的是死循环拿消息的机制,这个代码放在主线程不会造成卡死吗?
OK。我们看看loop()这个方法里面究竟做了些什么?
上面的代码不需要全部看清,我们知道大概的流程是:一个for的死循环,然后从queue里面取消息,然后不断交给msg.target进行处理。
首先我们要明白一点,Android应用程序的主线程在进入消息循环过程前,会在内部创建一个Linux管道(Pipe),这个管道的作用是使得Android应用程序主线程在消息队列为空时可以进入空闲等待状态,这样CPU并不会消耗太多资源在当前这个线程,并且使得当应用程序的消息队列有消息需要处理时唤醒应用程序的主线程。
然后其实刚才的msg.target.dispatchMessage(msg),target就是Handler对象,也就是我们ActivityThread的H对象
用过Handler的人都知道,我们在Handler发送消息之后,经过looper取消息后,会重新交给Handler去handleMessage,我们看上面的case,创建activity消息(LAUNCH_ACTIVITY),销毁activity的消息(DESTROY_ACTIVITY)等操作都在里面进行分发处理,那么当收到信息的时候,主线程就能正常运行,做出反应。
那么这个Handler是在哪里发出的消息呢?我们重新回去之前ActivityThread的main()方法,漏掉了一个非常重要的步骤thread.attach(false);这个Thread是ApplicationThread对象,Binder的服务端,用于接收系统服务AMS发送来的事件),该Binder线程通过Handler将Message发送给主线程。
thread.attach(false)方法代码如下:
mgr.attachApplication(mAppThread)最重要,这句将当前mAppThread为对象与AMS建立关系,之后AMS就可以通过这个代理对象发送消息给主线程
最后进去ApplicationThread对象一探究竟:
“` private class ApplicationThread extends ApplicationThreadNative {
private static final String DB_INFO_FORMAT = ” %8s %8s %14s %14s %s”;
“`
上面简单粘了其中一个方法,sendMessage()就是发送消息给主线程的方法。
调用生命周期是因为有Looper,有MessageQueue,还有沟通的桥梁Handler,通过IPC机制调用Handler发送各种消息,保存到MessageQueue中,然后在主线程中的Looper提取了消息,并在主线程中调用Handler的方法去处理消息.最终完成各种声明周期.
第一步,看看我们的Looper创建在哪里
Activity的启动一般会调用到ActivityThread,里面有main方法,是初始化activity必经阶段,我们的Looper,就是在main的过程创建的。public static void main(String[] args) { Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain"); SamplingProfilerIntegration.start(); // CloseGuard defaults to true and can be quite spammy. We // disable it here, but selectively enable it later (via // StrictMode) on debug builds, but using DropBox, not logs. CloseGuard.setEnabled(false); Environment.initForCurrentUser(); // Set the reporter for event logging in libcore EventLogger.setReporter(new EventLoggingReporter()); // Make sure TrustedCertificateStore looks in the right place for CA certificates final File configDir = Environment.getUserConfigDirectory(UserHandle.myUserId()); TrustedCertificateStore.setDefaultUserDirectory(configDir); Process.setArgV0("<pre-initialized>"); //1.准备阶段 Looper.prepareMainLooper(); ActivityThread thread = new ActivityThread(); thread.attach(false); if (sMainThreadHandler == null) { sMainThreadHandler = thread.getHandler(); } if (false) { Looper.myLooper().setMessageLogging(new LogPrinter(Log.DEBUG, "ActivityThread")); } // End of event ActivityThreadMain. Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); //2.循环启动 Looper.loop(); throw new RuntimeException("Main thread loop unexpectedly exited"); }
OK。我们看看loop()这个方法里面究竟做了些什么?
public static void loop() { final Looper me = myLooper(); if (me == null) { throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread."); } final MessageQueue queue = me.mQueue; // Make sure the identity of this thread is that of the local process, // and keep track of what that identity token actually is. Binder.clearCallingIdentity(); final long ident = Binder.clearCallingIdentity(); //1.死循环来了 for (;;) { Message msg = queue.next(); // might block if (msg == null) { // No message indicates that the message queue is quitting. return; } // This must be in a local variable, in case a UI event sets the logger final Printer logging = me.mLogging; if (logging != null) { logging.println(">>>>> Dispatching to " + msg.target + " " + msg.callback + ": " + msg.what); } final long traceTag = me.mTraceTag; if (traceTag != 0) { Trace.traceBegin(traceTag, msg.target.getTraceName(msg)); } try { msg.target.dispatchMessage(msg); } finally { if (traceTag != 0) { Trace.traceEnd(traceTag); } } if (logging != null) { logging.println("<<<<< Finished to " + msg.target + " " + msg.callback); } // Make sure that during the course of dispatching the // identity of the thread wasn't corrupted. final long newIdent = Binder.clearCallingIdentity(); if (ident != newIdent) { Log.wtf(TAG, "Thread identity changed from 0x" + Long.toHexString(ident) + " to 0x" + Long.toHexString(newIdent) + " while dispatching to " + msg.target.getClass().getName() + " " + msg.callback + " what=" + msg.what); } msg.recycleUnchecked(); } }
上面的代码不需要全部看清,我们知道大概的流程是:一个for的死循环,然后从queue里面取消息,然后不断交给msg.target进行处理。
首先我们要明白一点,Android应用程序的主线程在进入消息循环过程前,会在内部创建一个Linux管道(Pipe),这个管道的作用是使得Android应用程序主线程在消息队列为空时可以进入空闲等待状态,这样CPU并不会消耗太多资源在当前这个线程,并且使得当应用程序的消息队列有消息需要处理时唤醒应用程序的主线程。
然后其实刚才的msg.target.dispatchMessage(msg),target就是Handler对象,也就是我们ActivityThread的H对象
private class H extends Handler { ...省略代码 public void handleMessage(Message msg) { if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what)); switch (msg.what) { case LAUNCH_ACTIVITY: { Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart"); final ActivityClientRecord r = (ActivityClientRecord) msg.obj; r.packageInfo = getPackageInfoNoCheck( r.activityInfo.applicationInfo, r.compatInfo); handleLaunchActivity(r, null, "LAUNCH_ACTIVITY"); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); } break; case RELAUNCH_ACTIVITY: { Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityRestart"); ActivityClientRecord r = (ActivityClientRecord)msg.obj; handleRelaunchActivity(r); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); } break; case PAUSE_ACTIVITY: { Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityPause"); SomeArgs args = (SomeArgs) msg.obj; handlePauseActivity((IBinder) args.arg1, false, (args.argi1 & USER_LEAVING) != 0, args.argi2, (args.argi1 & DONT_REPORT) != 0, args.argi3); maybeSnapshot(); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); } break; case PAUSE_ACTIVITY_FINISHING: { Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityPause"); SomeArgs args = (SomeArgs) msg.obj; handlePauseActivity((IBinder) args.arg1, true, (args.argi1 & USER_LEAVING) != 0, args.argi2, (args.argi1 & DONT_REPORT) != 0, args.argi3); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); } break; case STOP_ACTIVITY_SHOW: { Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStop"); SomeArgs args = (SomeArgs) msg.obj; handleStopActivity((IBinder) args.arg1, true, args.argi2, args.argi3); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); } break; case STOP_ACTIVITY_HIDE: { Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStop"); SomeArgs args = (SomeArgs) msg.obj; handleStopActivity((IBinder) args.arg1, false, args.argi2, args.argi3); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); } break; case SHOW_WINDOW: Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityShowWindow"); handleWindowVisibility((IBinder)msg.obj, true); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); break; case HIDE_WINDOW: Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityHideWindow"); handleWindowVisibility((IBinder)msg.obj, false); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); break; case RESUME_ACTIVITY: Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityResume"); SomeArgs args = (SomeArgs) msg.obj; handleResumeActivity((IBinder) args.arg1, true, args.argi1 != 0, true, args.argi3, "RESUME_ACTIVITY"); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); break; case SEND_RESULT: Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityDeliverResult"); handleSendResult((ResultData)msg.obj); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); break; case DESTROY_ACTIVITY: Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityDestroy"); handleDestroyActivity((IBinder)msg.obj, msg.arg1 != 0, msg.arg2, false); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); break; case BIND_APPLICATION: Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication"); AppBindData data = (AppBindData)msg.obj; handleBindApplication(data); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); break; case EXIT_APPLICATION: if (mInitialApplication != null) { mInitialApplication.onTerminate(); } Looper.myLooper().quit(); break; case NEW_INTENT: Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityNewIntent"); handleNewIntent((NewIntentData)msg.obj); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); break; case RECEIVER: Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "broadcastReceiveComp"); handleReceiver((ReceiverData)msg.obj); maybeSnapshot(); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); break; //省略其他一堆case } Object obj = msg.obj; if (obj instanceof SomeArgs) { ((SomeArgs) obj).recycle(); } if (DEBUG_MESSAGES) Slog.v(TAG, "<<< done: " + codeToString(msg.what)); } }
用过Handler的人都知道,我们在Handler发送消息之后,经过looper取消息后,会重新交给Handler去handleMessage,我们看上面的case,创建activity消息(LAUNCH_ACTIVITY),销毁activity的消息(DESTROY_ACTIVITY)等操作都在里面进行分发处理,那么当收到信息的时候,主线程就能正常运行,做出反应。
那么这个Handler是在哪里发出的消息呢?我们重新回去之前ActivityThread的main()方法,漏掉了一个非常重要的步骤thread.attach(false);这个Thread是ApplicationThread对象,Binder的服务端,用于接收系统服务AMS发送来的事件),该Binder线程通过Handler将Message发送给主线程。
thread.attach(false)方法代码如下:
private void attach(boolean system) { sCurrentActivityThread = this; mSystemThread = system; if (!system) { //省略代码 android.ddm.DdmHandleAppName.setAppName("<pre-initialized>", UserHandle.myUserId()); RuntimeInit.setApplicationObject(mAppThread.asBinder()); final IActivityManager mgr = ActivityManagerNative.getDefault(); try { mgr.attachApplication(mAppThread); } catch (RemoteException ex) { throw ex.rethrowFromSystemServer(); } // Watch for getting close to heap limit. //省略代码 } else { //省略代码 } // add dropbox logging to libcore DropBox.setReporter(new DropBoxReporter()); }
mgr.attachApplication(mAppThread)最重要,这句将当前mAppThread为对象与AMS建立关系,之后AMS就可以通过这个代理对象发送消息给主线程
最后进去ApplicationThread对象一探究竟:
“` private class ApplicationThread extends ApplicationThreadNative {
private static final String DB_INFO_FORMAT = ” %8s %8s %14s %14s %s”;
private int mLastProcessState = -1; private void updatePendingConfiguration(Configuration config) { synchronized (mResourcesManager) { if (mPendingConfiguration == null || mPendingConfiguration.isOtherSeqNewer(config)) { mPendingConfiguration = config; } } } public final void schedulePauseActivity(IBinder token, boolean finished, boolean userLeaving, int configChanges, boolean dontReport) { int seq = getLifecycleSeq(); if (DEBUG_ORDER) Slog.d(TAG, "pauseActivity " + ActivityThread.this + " operation received seq: " + seq); sendMessage( finished ? H.PAUSE_ACTIVITY_FINISHING : H.PAUSE_ACTIVITY, token, (userLeaving ? USER_LEAVING : 0) | (dontReport ? DONT_REPORT : 0), configChanges, seq); }
“`
上面简单粘了其中一个方法,sendMessage()就是发送消息给主线程的方法。
总结
到此想必各位也就明了,主线程确实是阻塞的,像我们平时自己new 的线程一样,如果不加入looper做死循环,当run()方法走完的时候,系统就会回收线程所占的资源,所以说主线程阻塞是一个伪命题,只不过是没有弄明白既然阻塞了,为什么还能调用各种声明周期而已.调用生命周期是因为有Looper,有MessageQueue,还有沟通的桥梁Handler,通过IPC机制调用Handler发送各种消息,保存到MessageQueue中,然后在主线程中的Looper提取了消息,并在主线程中调用Handler的方法去处理消息.最终完成各种声明周期.
相关文章推荐
- Android中为什么主线程不会因为Looper.loop()里的死循环卡死?
- Android中为什么主线程不会因为Looper.loop()里的死循环卡死?
- Android中为什么主线程不会因为Looper.loop()里的死循环卡死?
- 关于Android中为什么主线程不会因为Looper.loop()里的死循环卡死?引发的思考,事实可能不是一个 epoll 那么 简单。
- Android中为什么主线程不会因为Looper.loop()里的死循环卡死
- Android中为什么主线程不会因为Looper.loop()里的死循环卡死?
- 关于Android中为什么主线程不会因为Looper.loop()里的死循环卡死?
- Android为什么主线程不会因为Looper.loop()里的死循环卡死
- Android中为什么主线程不会因为Looper.loop()里的死循环卡死?
- Android主线程looper是死循环问题
- Android中为什么主线程不会因为Looper.loop()方法造成阻塞
- Android中为什么主线程不会因为Looper.loop()方法造成阻塞
- Android中为什么主线程不会因为Looper.loop()方法造成阻塞
- android 线程中创建消息循环Looper.prepare() Looper.loop()
- Android温习:Looper.loop() android线程中的消息循环
- Android:Looper类,Looper.prepare()和Looper.loop()
- Android -- Looper.prepare()和Looper.loop()
- Android实战技巧:消息循环与Looper
- Android -- Looper.prepare()和Looper.loop() —深入版
- Android 之 Looper、MessageQueue、Handler 与消息循环