7.Activity从创建到显示重要角色介绍
所有代码都是Android 11
根据Activity 中各个出现的角色的顺序,来了解Activity 从创建到显示的流程
1.PhoneWindow -->窗口的持有者,每个activity都需要持有一个window,通过ISessionService 与 WMS 交互, 将初始化后的surface 与 SurfaceFliger 中的 QueueByte 关联,PhonwWindow 创建时机 activity 反射创建之后, 在Activity.attach 方法中创建,
ActivityThread.java -->performLaunchActivity 先通过mInstrumentation 反射创建Activity ,在Activity.attach 中创建
2.DecorView -->Activity.setContentView 中所有View 的根节点,创建时机 PhoneWindow.setContentView, setContentView 实际调用的是getWindow.getContentView(),
Activity.java.onCreate() ---> Activity.java.setContentView() -->PhoneWindow.setContentView --> 创建 DecorView ,解析所有View,并添加到DecorView 中
在这里会出现几个经典面试题
经典面试题
- setContentView后,这里能获取到View 的宽高吗,为什么
2.setContentView后,此时View关联到了activity 之上了吗,为什么
3.setContentView后,这里可以可以使用线程更新View吗,为什么 ,
带着这3个疑问,我们来继续分析
3.WindowManager -->在 ActivityThread 收到 AMS 执行Activity onResume 的 handleResumeActivity 方法中,先执行Activity 的 onResume 方法, 再通过WindowManager.addView 方法,这里调用的是WindowManagerImpl.add 方法 ,将 DecorView 与 PhoneWindow 做关联
为什么调用的是WindowManagerImpl,Activity.attach 初始化的 mWindowManager 是通过Window 来创建的,而Window 创建 WindowMananger 的代码如下
Window.java
public void setWindowManager(WindowManager wm, IBinder appToken, String appName,
boolean hardwareAccelerated) {
mAppToken = appToken;
mAppName = appName;
mHardwareAccelerated = hardwareAccelerated;
if (wm == null) {
wm = (WindowManager)mContext.getSystemService(Context.WINDOW_SERVICE);
}
mWindowManager = ((WindowManagerImpl)wm).createLocalWindowManager(this);
}
可以看到Window 创建WindowManager 的是调用 WindowManagerImpl.createLocalWindowManager方法来创建的,继续跟踪如下
WindowManagerImpl.java
public WindowManagerImpl createLocalWindowManager(Window parentWindow) {
return new WindowManagerImpl(mContext, parentWindow);
}
4.WindowManagerGlobal -->单利创建,整个app进程只有一个 ,他的主要作用就是管理着所有的View ,所有的ViewRootImlp , 以及所有Window.LayoutParams
我们上面分析到WindowManagerImpl.addView 方法,他这里面2行代码,最终的一行就是调用 WindowManagerGlobal.addView
5.ViewRootImpl -->在 WindowManagerGlobal.addView 创建ViewRootImpl ,并将 DecorView 放入到ViewRootImpl 中, 在ViewRootImpl 方法中,先调用了requestLayout 方法, requestLayout 方法的调用逻辑是先checkThread ,然后发送消息屏障,在发送一个刷新View 的回调,等待垂直同步信号来临后,由mChoreographer 处理各种事件后,在调用doTraversal移除屏障消息,处理刷新事件,执行View树种各个View 的 onMeasure onLayou onDraw 等事件
看到这里我们就能回答上面那三个经典的面试题了,
1.setContentView后,这里能获取到View 的宽高吗
答:不能,在setContentView 后,只是将布局View 与 DecorView 做了关联,并没有执行View 的测量 流程,真正的测量流程是在 Activity 的 onResume 之后的下一个requestLayout 发出的屏障消息之后,
2.setContentView后,此时View关联到了activity 之上了吗
答:没有 在setContentView 后,只是将布局View 与 DecorView 做了关联,实际关联的地方再 Activity 的 onResume之后 调用的 WindowManager.addView ,通过WindowManagerGlobal 创建ViewRootImpl ,通过 ViewRootImpl 将View 与 ViewRootImpl Window 做的关联
3.setContentView后,这里可以可以使用线程更新View吗,还有在子线程更新UI 的方法吗,
答:可以 ,之所以不能在子线程中更新UI 的原因是因为 ViewRootImpl 的 刷新方法中调用了 checkThread 方法,来判断的当前线程,而 ViewRootImpl 的创建时机是在 Activity 的 onResume 方法之后,所以在 onCreate 方法开启线程由于 ViewRootImpl 都没有创建,所以不会触发这个判断,
想要在子线程更新UI ,我们先来分析一下ViewRootImpl 的checkThread 方法
public ViewRootImpl(Context context, Display display, IWindowSession session,
boolean useSfChoreographer) {
mThread = Thread.currentThread();
}
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
从上面可以看到 mThread 就是创建 ViewRootImpl 的线程,那么在更新时候的线程如果不是 ViewRootImpl 的创建线程就会报错,只要我们在子线程中创建ViewRootImpl ,就可以做到在子线程中刷新UI
6. 重中之重 Furface -->上面的流程执行完毕后, 需要准备的Window , View 树 都准备好了, 那么接下来就要开始绘制View 了,我们都知道在View 的onDraw 方法中有一个参数就是canvas ,那么这个canvas 是怎么来的呢,
ViewRootImpl.java -->performTraversals() 方法
可能很多人比较关注的是 performTraversals方法中调用到了 View 的 performMeasure performLayout performDraw,但是在测量与绘制之前,更重要的一部则是创建画布,如果连画布都没有,创建的View 也是没有意义的,而创建好了画布,又需要将画布上的内容交给显示器去显示,这也是需要在 测量与绘制之前就需要准备好,这里就涉及到了跨进程通信的流程
--> 创建Suface
ViewRootImpl.performTraversals()
--> ViewRootImpl.relayoutWindow()//测量Window 的大小,并将 mSurfaceControl 通过 ISessionManager 交给WMS关联SurfaceFliger
-->Session.relayout()
-->WindowManagerService.relayoutWindow()
在来分析一下 WindowManagerService的 relayoutWindow方法
WindowManagerService.relayoutWindow()
-->WindowManagerService.createSurfaceControl()
--> WindowStateAnimator.createSurfaceLocked()
-->WindowSurfaceController()
-->SurfaceControl.Builder.build()
-->SurfaceControl()
-->nativeCreate()
到了这里参与绘制的所有参与者都已经初始化完毕,接下来就可以执行 测量 布局 绘制等流程了,而这里还有一个比较重要的地方就是view 的canvas 是如何来的,
canvas = mSurface.lockCanvas(dirty);
DecorView 的canvas 是通过lockCanvas 来获取,而他的canvas 会一级一级向下传递,也就是说DecorView 上所有的子View 会公用一个surface 上个canvas,也就是同一个surface
这里也有一个经典面试题,那就是SurfaceView 与普通的View 有什么不同,他的不同为他带来了哪些好处,哪些不好之处,简要说一下SurfaceView
这里我们继续带着问题来分析接下来的流程
个人理解: SurfaceView 同样是一个View , 他与其他View 最大不同之处就在于,SurfaceView会单独持有一个 surface ,可以利用线程来更新View ,更大程度的保证在复杂的场景的刷新帧率,而他所有的操作都是借助 SurfaceHolder 来完成的,相对其他View 的操作性并不好,
经典面试题: View Window WindowManager WindowManagerService 的关系是什么样的
个人理解:Window 是 Activity 的显示的窗口, Activity 通过 WindowManager 管理这所有 Window , 并且WindowManager 通过 WindowManagerGlobal 来管理这所有ViewRootImpl 与 View , WindowManager 为所有View 的显示完善了 SurfaceContral ,并将 Surface 与 SurfaceFliger 的 QueueByte 关联起来,为显示器提供显示数据
