本文详细阐述了Android App层的关键组件工作原理，包括Activity、Service、BroadcastReceiver和ContentProvider，以及消息机制如Handler、MessageQueue和Looper。此外，文章还深入探讨了Window和WindowManager的内部机制，为读者提供了全面的Android应用开发基础理论。
日以继夜近两个星期，终于完成这篇了，之所以自己这么看重，是因为这篇应该是读书笔记里最重要的一篇了，这篇能吃透的话，基本安卓app层玩的机制都能理解的很清楚了，所以我也倾注了全部的心血来写这篇，希望跟大家一起分享。
简单先说下：这里将第九章（四大组件的工作过程），第十章（Android的消息机制）放在第八章（理解Window和WindowManager）前面的原因是：学习理解Window的知识最好需要先了解Activity的运行机制以及handler的工作原理，所以大家读主席这本书的时候也建议按照这个顺序来读这三章，对window的理解会更水到渠成，以上。如果看这篇前你还没有去看第二章的IPC机制，我强烈建议你看懂IPC再回来看这篇，会发现一切都变得非常清晰。热切期盼各位看完能有收获，有任何错误或者疑问都可在评论中给出，我会一一回复，感谢～
Chapter-9 四大组件的工作过程
- 先说两句，玉刚的书中主要侧重的是过程分析和代码讲解，这样一页一页的翻完之后总有一种意犹未尽却不够清晰的感觉，一开始我依然是用文字list的方式来梳理，后来发现看起来还是有点不够清晰，达不到我想要的效果，所以改了两版后我决定用图 + 文字说明的方式来表现，希望大家可以看得更清晰。注意这里左侧是用UML画的流程图，发现还挺方便的，类中的方法是按照调用顺序排列的，右侧的UML图则是真正的UML图，会标注出一些重要类的结构关系，排除各位看书时看到各种A继承B，B继承C时晕了的感觉。
- 四大组件概述：
1） Activity的主要作用是展示一个界面并和用户交互，它扮演的是一种前台界面的角色。
2） Service是一种计算型组件，用于在后台执行一系列计算任务，但因为其本身还是运行在主线程中的，因此耗时的后台计算仍然需要在单独的线程中去完成。
3） BroadcastReceiver是一种消息型组件，用于在不同的组件乃至不同的应用之间传递消息。广播注册有两种方式，动态注册通过Context.registerReceiver()来实现，必须要应用启动才能注册；静态注册则在AndroidManifest文件中进行，应用安装时会被系统解析，不需要启动应用就可接收广播。
4） ContentProvider是一种共享型组件，用于向其他组件乃至其他应用共享数据。 - Activity的工作过程
- Service
启动：
绑定：
- BroadcastReceiver
注册（动态）：
发送和接收：
- ContentProvider
1） 当ContentProvider所在的进程启动的时候，它会同时被启动并被发布到AMS中，这个时候它的onCreate要先去Application的onCreate执行。
2） 启动方式请看page363，这里就不画了，书上画的非常清晰易懂，就写几个tips 吧。
a. 应用启动的入口为ActivityThread的main方法，main方法会创建ActivityThread实例并创建主线程消息队列。
b. attach方法中远程调用AMS的attachApplication方法，并提供ApplicationThread用于和AMS的通信。
c. attachApplication方法会通过bindApplication方法和H来调回ActivityThread的handleBindApplication，这个方法会先创建Application，再加载ContentProvider，然后才会回调Application的onCreate方法。
d. ContentProvider的multiprocess属性决定了ContentProvider是否是单例（false时），一般都用单例。
e. ContentResolver的具体类是ApplicationContentResolver，当ContentProvider所在进程未启动时，第一次访问它会触发ContentProvider的创建以及进程启动。
3） query流程
Chapater-10 Android的消息机制
- 三大件：Hanlder，MessageQueue，Looper。
- MessageQueue内部的数据结构并非队列，而是单链表，它只是用来存储数据。
- Looper是真正的数据处理者，线程默认没有Looper，使用Handler必须为线程创建Looper，UI线程也就是ActivityThread创建时会初始化Looper，所以主线程中默认可以直接使用Handler。
- UI线程检查当前线程的操作在ViewRootImpl的checkThread方法中，我们常见的不能在子线程中访问view的异常就是在这里抛出的。
- 不允许子线程访问主线程的原因是UI控件不是线程安全的，而加锁又会导致UI的操作过于复杂。
- Handler的工作过程，图（page374），我简单概括一下就是：假设创建Handler的线程是A，耗时操作的线程是B，B线程中拿到handler实例发送消息或者post一个Runnable，实际是调用了MessageQueue的enqueueMessage方法，进入了消息队列，线程A中的Looper发现了这个消息，就会处理这个消息，也就是消息中的Runnable或者handler的handleMessage方法会被调用，这样handler中的业务逻辑就被切换到线程A中去了。
- ThreadLocal我用一句大白话来讲解，就是看上去只new了一份，但在每个不同的线程中却可以拥有不同数据副本的神奇类。其本质是ThreadLocal中的Values类维护了一个Object[]，而每个Thread类中有一个ThreadLocal.Values成员，当调用ThreadLocal的set方法时，其实是根据一定规则把这个线程中对应的ThreadLocal值塞进了Values的Object[]数组中的某个index里。这个index总是为ThreadLocal的reference字段所标识的对象的下一个位置。
- MessageQueue的工作原理：主要方法为enqueueMessage和next。
a. enqueueMessag主要就是一个单链表的插入操作，
b. next方法是一个无限循环，如果消息队列中没有消息，next方法就阻塞，有新消息到来时，next方法会返回这条消息并将其从单链表中删除。 - Looper的工作原理：
a. prepare方法，为当前没有Looper的线程创建Looper。
b. prepareMainLooper和getMainLooper方法用于创建和获取ActivityThread的Looper。
c. quit和quitSafely方法，前者立即退出，后者只是设定一个标记，当消息队列中的所有消息处理完毕后会才安全退出。子线程中创建的Looper建议不需要的时候都要手动终止。
d. loop方法，死循环，阻塞获取msg并丢给msg.target.dispatchMessage方法去处理，这里的target就是handler。 - Handler的工作原理：
a. 无论sendMessage还是post最终都是调用的sendMessageAtTime方法。
b. 发送消息其实就是把一条消息通过MessageQueue的enqueueMessage方法加入消息队列，Looper收到消息就会调用handler的dispatchMessage方法。它的处理过程参考书page388的流程图，一看就懂～
c. 这里我补充一个东西，当我们直接Handler h = new Handler()时，本质调用的是Handler(Callback callback, Boolean async)构造方法，这个方法里会调用Looper.myLooper()方法，这个方法其实就是返回的ThreadLocal里保存的当前线程的Looper，这也就解释了为什么我们在主线程中这样new没有问题，子线程中如果不先Looper.prepare会抛出异常的原因，前面多次说了，因为ActivityThread会在初始化的时候创建自己的Looper。 - 主线程的消息循环：
Chapter-8 Window和WindowManager
- 一些基础知识：
1） Window的实现类是PhoneWindow。
2） Window的具体实现位于WindowManagerService中，WindowManager和WindowManagerService的交互是一个IPC过程。
3） Window实际是View的直接管理者。 - 常用的WindowManager.LayoutParams的Flag和Type
1） FLAG：
FLAG_NOT_FOCUSABLE，当前Window不获取焦点，也不接收各种输入事件，会同时启用FLAG_NOT_TOUCH_MODAL，事件会传递给下层具有焦点的Window。
FLAG_NOT_TOUCH_MODAL，当前Window区域外的单击事件传递给底层，区域内的单击事件自己处理，一般都需要开启。
FLAG_SHOW_WHEN_LOCKED，可以让Window显示在锁屏界面上。
2） Type：
应用Window，一般对应一个Activity。层级范围1～99。
子Window，不能单独存在，需要特定的父Window，比如一般的Dialog。层级范围1000～1999。
系统Window，需要权限声明，比如Toast。层级范围2000～2999。一般可以选用WindowManager.LayoutParams.TYPE_SYSTEM_ERROR，同时声明权限。
3） WindowManager提供的功能：addView，updateViewLayout，removeView - Window的内部机制：Window并不实际存在，以View的形式存在。每个Window对应着一个View和ViewRootImpl，Window和View通过ViewRootImpl建立联系。所以在实际使用中其实我们并不能访问到真正的Window，而只能通过WindowManager。
1） 几个重要的window类的关系（发现主席不大爱画UML，我就代工了）
2） Window的添加过程
WindowManagerGlobal中的addView：
检查参数是否合法；
如果子Window还需要调节布局参数；
创建ViewRootImpl并将View添加到列表中；
通过ViewRootImpl的setView来更新界面并完成Window的添加过程：requestLayout中的scheduleTraversals是View绘制的入口，最终通过WindowSession来完成Window的添加过程，注意其实这里是个IPC过程，最终会通过WindowManagerService的addWindow方法来实现Window的添加。
3） Window的删除过程
WinodwManagerGlobal中的removeView；
findViewLocked来查找待删除待View的索引，再调用removeViewLocked来做进一步删除；
removeViewLocked通过ViewRootImpl的die方法来完成删除操作，包括同步和异步两种方式，同步方式可能会导致意外的错误，不推荐，一般使用异步的方式，其实就是通过handler发送了一个删除请求，将View添加到mDyingViews中；
die方法本质调用了doDie方法，真正删除View的逻辑在该方法的dispatchDetachedFromWindow方法中，主要做了四件事：垃圾回收，通过Session的remove方法删除Window，调用View的dispatchDetachedFromWindow方法同时会回调View的onDetachedFromWindow以及onDetachedFromWindowInternal，调用WindowManagerGlobal的doRemoveView刷新数据。
4） Window的更新过程
WindowManagerGlobal的updateViewLayout；
更新View的LayoutParams；
更新ViewImple的LayoutParams，实现对View的重新测量，布局，重绘；
通过WindowSession更新Window的视图，WindowManagerService.relayoutWindow()。 - Window的创建过程
1） Activity
Activity的attach方法中，系统会创建Activity所属的Window并为其设置回调；
Window对象的创建通过PolicyManager的makeNewWindow方法；
Window的具体实现是PhoneWindow类；
Window创建好之后，通过PhoneWindow的setContentView将Activity与Window进行关联，这个方法大致步骤：
a. 如果没有DecorView就创建，id是android.R.id.content；
b. 将Activity设置的ContentView设置到DecorView的mContentParent中；
c. 回调Activity的onContentChanged方法通知Activity视图已经发生改变；
d. Activity onResume的时候会调用Activity的makeVisible方法真正完成DecorView的添加和显示。
2） Dialog
a. 通过PolicyManager的makeNewWindow方法创建Window；
b. 初始化DecorView，和Activity类似；
c. Dialog的show方法中，通过WindowManager将DecorView添加到Window中；
d. Dialog关闭时，会通过WindowManager来移除DecorView，方法为removeViewImmediate(mDecor)；
e. 想要创建一个使用application context的Dialog可按照本章2-2的方法设置，dialog.getWindow.setType(WindowManager.LayoutParams.TYPE_SYSTEM_ERROR)，记得在manifest中设置权限。
3） Toast
a. Toast内部有两类IPC：Toast访问NotificationManagerService；NotificationManagerService（下文简称NMS）访问Toast的TN接口；
b. Toast属于系统Window，内部视图mNextView一种为系统默认样式，另一种通过setView方法来指定一个自定义View。
c. TN是一个Binder类，NMS处理Toast的显示隐藏请求时会跨进程回调TN中的方法，所以TN运行在Binder线程池中，所以需要handler切换到当前发送Toast请求的线程中，也就是说没有Looper的线程是无法弹出Toast的。
d. Toast的show方法调用了NMS的enqueueToast方法，该方法先将Toast请求封装成ToastRecord并丢入mToastQueue队列中（非系统应用最多塞50个）。
e. NMS通过showNextToastLocked方法来显示当前View，Toast显示由ToastRecord的callback方法中的show方法完成，callback其实就是TN对象的远程Binder，所以最终调用的是TN中的方法，并运行在发起Toast请求应用的Binder线程池中。
f. 显示以后，NMS通过scheduleTimeoutLocked方法发送延时消息，延时后NMS通过cancelToastLocked方法来隐藏Toast并从队列中移除，隐藏依然通过ToastRecord的callback中的hide方法实现。
g. callback回调TN的show和hide方法后，会通过handler发送两个Runnable，里面的handleShow和handleHide方法是真正完成显示和隐藏Toast的地方。handleShow方法中将Toast的视图添加到Window中，handleHide方法将Toast视图从Window中移除。
扫一扫
776
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
