由浅入深学习新模块之window_manager（一） 原创 精华
作者：王清
前言：
作为一个开发人员，随着时代和行业的发展，总会不断的接触不同的新任务，新模块，这就需要不断的学习与沉淀。因为工作的需求，笔者需要对一些自己负责模块之外的模块进行学习和熟悉，对此笔者把这个学习过程以该系列文章做一个记录分享给大家。
学习新模块的总体思路：
学习的最好的方式就输出，这个是我写这篇文章的原因。
次好的方式是带着疑问，通过学习与思考，在解决自己疑问的过程中获得知识与认知，最后恍然大悟的时候获得学习的满足感。
本篇作为学习一个新模块的第一篇，主要是对window_manager模块建立一个初步的，总体的认知。具体需要解决的疑问如下：
1. window_manager是什么？
2. window_manager模块在整个系统中做什么？
3. window_manager自己的总体的框架是什么？
带着这几个疑问，我们进入正题：
window_manager是什么？
我们可以在OpenHarmony，IOS，Android，windows等图形界面系统中都可以看到一个名为窗口管理的框架模块，至于为什么叫window_manager,而不是什么door_manager，desktop_manager,原因就是长期占据图形界面系统霸主地位的就是微软的windows，受众最广，使用的开发者最多，导致后续的系统的设计者和开发者重复造轮子的时候总会借鉴这个成熟的框架。
我们可以参考下微软在前几代图形操作系统中的主要特点来理解下window_manager这个模块的地位：
1983年，微软为IBM涉及的首款windows程序：
特点：多窗口，可改变大小窗口
1985年，微软发布windows首个版本windows1.0：
特点：窗口不可重叠，但是可以平铺，窗口不可以覆盖下方图标区域。
1987年，微软发布windows2.03：
特点：窗口可以改变大小，可以重叠，添加部分窗口控制功能。
到了windows3.0和windows3.1时代，加入了大量的图形界面，单纯的从界面上看已经和现代的windows操作系统非常接近，并成为当时兼容机的标配，代表图形操作系统进入成熟发展期。而从发展的历程上看，DOS这类非图形界面向图形界面的变迁过程中，window视窗的概念被孕育和发展，窗口的管理系统或者说框架，即window_manager框架，也成为了现代图形操作系统中核心模块。
本章小结：
- window_manager是现代图形操作系统的核心模块。
- window_manager模块迄今已有40年左右的发展史，虽然随着技术的进步，但是窗口管理的核心概念如最初的窗口大小控制，布局控制，窗口属性等一直沿用至今，了解下历史可以让我们学习该模块更好的举一反三。
window_manager模块在整个系统中做什么
(我们现在学习的模块都率属于OpenHarmony开源操作系统，系统及框架均以OpenHarmony为准）
我们想去了解一个模块，需要了解这个模块在整个系统的位置，这个模块的功能有哪些，紧密关联的模块有哪些，给其他模块提供什么样的支撑，以及自身的功能集的实现需要其他模块为自己提供怎样的支持等等等等。
针对以上的问题，我们一个个来探究：
- window_manager模块在整个系统中的位置：
window_manager模块又称为窗口管理子系统，它与graphic子系统共同组成了OpenHarmony三大核心子系统中的图形子系统。
图形子系统：
graphic子系统：
提供了图形接口能力，提供图形的 NDK（native development kit，原生开发包）能力，包括：WebGL、Native Drawing的绘制能力、OpenGL 指令级的绘制能力支撑等。
窗口管理子系统：
提供窗口管理和Display管理的基础能力，是系统图形界面显示所需的基础子系统。
- 窗口管理子系统的具体功能：
按照官网的描述，窗口管理子系统
窗口管理：窗口提供管理窗口的一些基础能力，包括对当前窗口的创建、销毁、各属性设置，以及对各窗口间的管理调度。
DisPlay：屏幕属性提供管理显示设备的一些基础能力，包括获取默认显示设备的信息，获取所有显示设备的信息以及监听显示设备的插拔行为。
- 与其他模块的关系
窗口管理子系统接口对开发者不可见，主要是给其他几个模块调用，如AAFWK(原能力子系统)、多媒体、相机等。
对于应用开发者来说，接触最多的是ability，而ability页面内容由窗口进行展示，也就是ability必然会使用该模块的接口去创建window对象。
对于上层UI框架，其向图形子系统申请窗口，并使用2D图像绘制引擎skia向窗口中绘入画面；而窗口附着在ability上，ability由元能力子系统AAFWK进行管理；
window_manager框架本身则提供创建、销毁窗口的接口，以及窗口的显示、隐藏、切换、缩放等动作等。
对于下层驱动程序，图形子系统图像的最终显示由驱动决定。
window_manager自身的结构：
从window_manager结构可以很清晰的看出window_manager模块分成窗口管理和Display两块，均使用Client/Server模式，各自细分模块的功能如下：
- Window Manager Client
应用进程窗口管理接口层，提供窗口对对象抽象和窗口管理接口，对接原能力和UI框架。
- Display Manager Client
应用进程Display管理接口层，提供Display信息抽象和Display管理接口。
- Window Manager Server
窗口管理服务，提供窗口布局、Z序控制、窗口树结构、窗口拖拽、窗口快照等能力，并提供窗口布局和焦点窗口给多模输入
窗口布局：重叠，平铺等
Z序控制：窗口可以重叠的前提就要求有Z序控制，Z序可以理解为在传统的以X,Y为坐标的屏幕中的Z轴的序列，来表示窗口在屏幕这个平面堆叠的顺序。
窗口树结构：WindowRoot，WindowNode就是管理窗口树结构的模块。
窗口拖拽：窗口拖拽事件处理。
窗口快照：这个是智能手机兴起之后流行的功能，用于多开应用窗口的时候便捷查看和切换应用或者窗口。
我们对比下window发布的前几个版本窗口的功能，可以看到窗口管理的主要功能这几十年来并没有多少变化，包括笔者查看的一篇写于2008年的windows系统的窗口管理的技术文章，于今也是大同小异。
-
Display Manager Server
Display管理服务，提供Display信息、屏幕截图、屏幕亮灭和亮度处理控制，并处理Display与Screen映射关系
对其他一些概念的解释：
Display，Screen，Window：
这三个概念很容易混淆，我们可以参考下Linux下图形管理中的定义：
Display :
若干个屏幕(screen)以及一套输入设备（键盘和鼠标）构成一个display，display概念的关键就是有一套完整的输入输出。屏幕不一定必须是一个，可以有多个，各个屏幕可以用来显示相同的内容，也可以用来构成矩阵显示一个大屏幕的内容。
Screen :
Screen的层次在display之下，是一个实际的Monitor或是Device。一个screen对应一个根窗口（root window），根窗口的大小与screen相同。
Window :
Window是比screen还要小一级的概念了。Window是有树形继承关系的，每一个屏幕上都对应有一个“窗口树”，树的根就是root window，即根窗口，它没有父窗口；除此之外，所有window都有父窗口。一个窗口还可能有子窗口，但并不是必须的。
参考文献：
- https://gitee.com/openharmony/window_window_manager 《window_manger仓介绍》
- https://www.open-open.com/news/view/185d270 《图说Windows演变史：1985-2012》
总结
本文介绍了地址翻译模式以及相关的配置。下一篇文章将继续对loongarch虚拟内存系统中的其他部分。
更多原创内容请关注：深开鸿技术团队
入门到精通、技巧到案例，系统化分享OpenHarmony开发技术，欢迎投稿和订阅，让我们一起携手前行共建生态。
深开鸿官网：https://www.kaihong.com
跟着楼主一起见证了window_manager的发展以及在OpenHarmony的使用，带着疑问学习确实更有目的性。
微软对窗口革新的贡献还是很大的
看来除了窗口快照以外，窗口在这些年确实没有什么改变
窗口的发展史讲的很好
85年窗口的样式感觉就确定下来没怎么变过了
发现自己window_manager还有很多功能都没用到，必须试试
“WindowManager” 是一个常见的操作系统模块名，它通常用于控制窗口的显示逻辑和管理窗口的位置、大小、层级等属性。虽然这个名字在不同的操作系统中可能会略有不同，但是它通常都会有类似的功能。
这个术语并没有与微软的 Windows 操作系统直接相关。实际上，WindowManager 这个名字的起源可以追溯到早期的图形用户界面 (GUI) 操作系统，比如 X Window System 和 Macintosh 操作系统。这些操作系统在早期的版本中都使用了类似的术语来描述窗口管理的模块，因此这个名字逐渐变得常见起来，并被其他操作系统采用。