Android窗口管理分析(1):View如何绘制到屏幕上的主观理解

窗口管理可以说是Android系统中最复杂的一部分,主要是它涉及的模块比较多,虽然笼统的说是窗口管理,其实,除了WindowManagerService还包括SurfaceFlinger服务、Linux的共享内存及tmpfs文件系统、Binder通信、InputManagerService、动画、VSYNC同步技术等,一篇文章不可能分析完全,但是可以首先对于窗口的显示与管理有一个大概的轮廓,再分块分解,涉及的知识点大概如下:

窗口管理知识图谱.png

WMS的作用是窗口管理 不负责View绘制

既然是概述,我们不妨直观的思考一个问题,Activity是如何呈现到屏幕上的,或者说View是如何被绘制到屏幕上来的?或多或少,开发者都知道WindowManagerService是负责Android的窗口管理,但是它其实只负责管理,比如窗口的添加、移除、调整顺序等,至于图像的绘制与合成之类的都不是WMS管理的范畴,WMS更像在更高的层面对于Android窗口的一个抽象,真正完成图像绘制的是APP端,而完成图层合成的是SurfaceFlinger服务。这里通过一个简单的悬浮窗口来探索一下大概流程:

    TextView mview=new TextView(context);
    ...<!--设置颜色 样式-->
    WindowManager mWindowManager = (WindowManager) getSystemService(Context.WINDOW_SERVICE);
    WindowManager.LayoutParams wmParams = new WindowManager.LayoutParams();
    wmParams.type = WindowManager.LayoutParams.TYPE_TOAST;
    wmParams.format = PixelFormat.RGBA_8888;
    wmParams.width = 800;
    wmParams.height = 800;
    mWindowManager.addView(mview, wmParams);

以上代码可以在主屏幕上添加一个TextView并展示,并且这个TextView独占一个窗口。在利用WindowManager.addView添加窗口之前,TextView的onDraw不会被调用,也就说View必须被添加到窗口中,才会被绘制,或者可以这样理解,只有申请了依附窗口,View才会有可以绘制的目标内存。当APP通过WindowManagerService的代理向其添加窗口的时候,WindowManagerService除了自己进行登记整理,还需要向SurfaceFlinger服务申请一块Surface画布,其实主要是画布背后所对应的一块内存,只有这一块内存申请成功之后,APP端才有绘图的目标,并且这块内存是APP端同SurfaceFlinger服务端共享的,这就省去了绘图资源的拷贝,示意图如下:

绘图原理.jpg

以上是抽象的图层对应关系,可以看到,APP端是可以通过unLockCanvasAndPost直接同SurfaceFlinger通信进行重绘的,就是说图形的绘制同WMS没有关系,WMS只是负责窗口的管理,并不负责窗口的绘制,这一点其实也可以从IWindowSession的binder通信接口看出来:

interface IWindowSession {

    int add(IWindow window, int seq, in WindowManager.LayoutParams attrs,
            in int viewVisibility, out Rect outContentInsets,
            out InputChannel outInputChannel);
            
    int addToDisplay(IWindow window, int seq, in WindowManager.LayoutParams attrs,
            in int viewVisibility, in int layerStackId, out Rect outContentInsets,
            out InputChannel outInputChannel);
            
    int relayout(IWindow window, int seq, in WindowManager.LayoutParams attrs,
            int requestedWidth, int requestedHeight, int viewVisibility,
            int flags, out Rect outFrame, out Rect outOverscanInsets,
            out Rect outContentInsets, out Rect outVisibleInsets,
            out Configuration outConfig, out Surface outSurface);
            
    void remove(IWindow window);
...
}

从参数就可以看出,APP与WindowManagerService通信的时候没有任何View相关的信息,更不会说将视图的数据传递给WMS,基本都是以IWindow为基本单位进行通信的,所以涉及的操作也都是针对窗口的,比如整个窗口的添加、移除、大小调整、分组等,单单从窗口显示来看,WMS的作用确实很明确,就是在服务端登记当前存活窗口,后面还会看到,这会影响SurfaceFlinger的图层混合,可以说是为SurfaceFlinger服务的。

在对于日常开发来说,WMS的窗口分组有时候会对开发带来影响,如果不知道窗口分组管理,可能有点忙迷惑,比如Dialog必须使用Activity的Context,PopupWindow不能作为父窗口,尤其要避免作为Webview的容器等,这些都跟WMS窗口的组织有关系。PopupWindow、Dialog、Activity三者都有窗口的概念,但又各有不同,Activity属于应用窗口、PopupWindow属于子窗口,而Dialog位于两者之间,从性质上说属于应用窗口,但是从直观理解上,比较像子窗口(其实不是)。Android中的窗口主要分为三种:系统窗口、应用窗口、子窗口,Toast就属于系统窗口,而Dialog、Activity属于应用窗口,不过Dialog必须依附Activity才能存在。PopupWindow算是子窗口,必须依附到其他窗口,依附的窗口可以使应用窗口也可以是系统窗口,但是不能是子窗口。

窗口组织形式.jpg

当然,WMS的作用不仅只是管理窗口,它还负责窗口动画、Touch事件等,后面会逐个模块分析。

View绘制与数据传递

既然WMS的作用只是窗口管理,那么图形是怎么绘制的呢?并且这些绘制信息是如何传递给SurfaceFlinger服务的呢?每个View都有自己的onDraw回调,开发者可以在onDraw里绘制自己想要绘制的图像,很明显View的绘制是在APP端,直观上理解,View的绘制也不会交给服务端,不然也太不独立了,可是View绘制的内存是什么时候分配的呢?是谁分配的呢?我们知道每个Activity可以看做是一个图层,其对应一块绘图表面其实就是Surface,Surface绘图表面对应的内存其实是由SurfaceFlinger申请的,并且,内存是APP与SurfaceFlinger间进程共享的。实现机制是基于Linux的共享内存,其实就是MAP+tmpfs文件系统,你可以理解成SF为APP申请一块内存,然后通过binder将这块内存相关的信息传递APP端,APP端往这块内存中绘制内容,绘制完毕,通知SF图层混排,之后,SF再将数据渲染到屏幕。其实这样做也很合理,因为图像内存比较大,普通的binder与socket都无法满足需求,内存共享的示意图如下:

View绘制与共享内存.jpg

总结

其实整个Android窗口管理简化的话可以分为以下三部分

  • WindowManagerService:WMS控制着Surface画布的添加与次序,动画还有触摸事件
  • SurfaceFlinger:SF负责图层的混合,并且将结果传输给硬件显示
  • APP端:每个APP负责相应图层的绘制,
  • APP与SurfaceFlinger通信:APP与SF图层之间数据的共享是通过匿名内存来实现的。

作者:看书的小蜗牛 原文链接: Android窗口管理分析(1):窗口管理及主观理解

仅供参考,欢迎指正

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Android中高级开发

Android开发之漫漫长途 Ⅵ——图解Android事件分发机制(深入底层源码)

该文章是一个系列文章,是本人在Android开发的漫漫长途上的一点感想和记录,我会尽量按照先易后难的顺序进行编写该系列。该系列引用了《Android开发艺术探索...

542
来自专栏吴老师移动开发

Flutter ScrollView上拉加载更多关于学习

2018.05.07 更新 上拉加载可以不用Notification,直接用ScrollController,代码如下:

1043
来自专栏Android开发小工

利用Android嵌套滑动机制轻松实现顶部布局置顶

传统的Android事件分发是子控件消费了事件,那么父控件就不能再处理这个事件了。也就是说一旦内部的滑动控件消费了滑动操作,外部的滑动控件就不能获取到这个滑动动...

663
来自专栏CSDN技术头条

React开发实践:如何做出好用的Switch组件

前言 HTML5 将 Web 开发者的战场从传统的 PC 端带到了移动端。然而移动端交互的核心在于手势和滑动,如果只是将 PC 端的点击体验简单地移植到移动端,...

2069
来自专栏分享达人秀

学会使用CardView,简单实现卡片式布局效果

还记得我们一共学过了多少UI控件了吗?都掌握的怎么样啊 安卓中一些常用控件学习得差不多了,今天再来学习一个新的控件CardView,在实际开发中...

2467
来自专栏非著名程序员

CoordinatorLayout的使用如此简单

曾在网上找了一些关于CoordinatorLayout的教程,大部分文章都是把CoordinatorLayout、AppbarLayout、Collapsing...

18210
来自专栏Android干货园

【PageLayout】非常简单的一键切换加载-空数据-错误页,支持自定义

Android中经常使用一个空白页和网络错误页用来提高用户体验,给用户一个较好的感官,如果获取到的数据为空,那么会显示一个空白数据页,如果在获取数据的过程中网络...

773
来自专栏AndroidTv

一起撸个简单粗暴的Tv应用主界面的网格布局控件(下)

上一篇中我们已经一起学了怎么简单粗暴的撸个支持动态布局的网格控件出来,但在上一篇的介绍中,并没有学习实现网格控件的滑动效果,所以本篇就来讲讲,要如何让我们的网格...

3308
来自专栏潇涧技术专栏

Head First Android ActionBar

最近在Android Studio中新建项目时发现Activity还是和以前一样,默认继承自ActionBarActivity,但是ActionBarActiv...

791
来自专栏郭霖

Android 3D滑动菜单完全解析,实现推拉门式的立体特效

在上一篇文章中,我们学习了Camera的基本用法,并借助它们编写了一个例子,实现了类似于API Demos里的图片中轴旋转功能。不过那个例子的核心代码是来自于A...

26210

扫码关注云+社区