技术管理篇5一技术演变史(I)

我们通过观察技术演变的历史，了解哪些技术架构延续到今天，中间又有哪些变革，当时是为了解决什么问题，每种技术方案又有哪些不足，学习这些取舍的过程，对我们技术的提升非常有好处。技术的演进过程，其实就是一个不断封装复杂，简单化的过程。

今天先来说说单机应用程序。在互联网普及之前，大部分的程序都是以安装包的方式，运行在个人的电脑上，文件存储也在放在PC本地。所以当时的程序的难点是怎么把界面做的足够好用和美观，我们可以注意到早期的技术框架都是封装界面渲染的，比如MFC、Delphy和VB的控件化。因为把界面做好这个事的确挺麻烦。

在了解这些框架之前，我们先看一下界面渲染的逻辑，其实这个逻辑一直到今天都没有变过，从PC到手机。我们可以把显示屏的渲染，比作电影的播放，都是一帧一帧展示的，只是因为展示的频率过快，所以人的肉眼感知不到而已。我们把一帧拿出来看，就是一副图画，在显示器播放之前，实际上操作系统会提前缓存这个图画，这样显示器可以按照固定的频率播放这个缓存，而我们的应用程序实际上是在这个缓存的画布上作画。

我们来看这个缓存的画布存储是什么样的，实际上就是像素的矩阵，我们对这个画布的渲染实际上是大量的矩阵操作。实际上我们的CPU是不擅长这个工作的，这就导致了GPU的出现。CPU更像是大学教授、专家，少而精，他擅长各种复杂逻辑处理和计数；GPU更像是富士康工厂，单个人都是普通工人，复杂逻辑计算搞不定，但是重复性的劳动，效率极高，所以你看现在人工智能时代，GPU这个特点就又被充分利用起来。

操作系统上，我们可不止会安装一个软件，每个软件都有他的界面渲染需求，操作系统是如何平衡每个程序的呢？如何让各个程序有序地在这个画布上作画的呢？实际上各家操作系统在这块的架构基本上相同的。操作系统会让每个软件有一个界面主线程来作画，同时操作系统与这个主线程之间通过消息来传递信息，比如用户在界面上的各种操作，点击、拖动啊等等，都是通过消息来传递。只要软件没有退出，这个主线程就要一直执行下去。如果大家写过MFC程序，就会知道每个软件都会有一个消息Loop段代码，就是这个界面主线程，我把逻辑关系和代码段放到图1和图2，大家可以看一下。

图1-UI消息分发逻辑图

图2-消息处理代码段

大家可以看到，界面绘制方面，操作系统通过消息机制，很好地和各个软件之间解耦，同时又达到了高效的协作。我们可以在很多地方看到这样的设计模式，消息其实就是一种协议，从软硬件之间的结合，到操作系统内核态与用户态的协作，再到异构系统之间的MQ通讯，甚至到互联网底层的整个Http协议栈，每个地方都可以看到这种模式的身影。

现在，大家再做桌面应用，无论PC还是手机，其实很少再写这种消息Loop代码了。原因很简单，因为现在的控件化已经做的很好了，技术演进让我们站在了前人的肩膀上，可以更专注在业务本身。当然，我们也可以通过一些遗留的小地方，看到这些逻辑存在的痕迹。比如我们不能在业务处理的线程中直接访问界面控件，了解了这背后的机理，就很清楚了，因为控件只能在界面主线程中访问，绘制的过程是操作系统统一协调的，资源句柄是不允许各个软件自己争用的。再比如，我们不能在界面主线程中做业务复杂的操作，因为这会降低界面绘制的效率，出现卡顿的问题。

总结一下，我们今天聊了单机应用程序界面绘制的机理，下一篇，我们来看看控件化是怎么封装这个复杂度的。