谁来结束 GUI 程序？

作者 |dog25

责编 | 屠敏

出品 | CSDN博客

在之前使用Windows XP的时候，都会有这样的经历，即打开一大堆的窗口，在任务栏排的满满的，同样程序的不同程序还可以分组，看似很有条理的样子…

不光Windows，Linux桌面、MacOS竟然也学着Windows的样子，也这么做。当然了，我没有扒过GUI的历史，也不敢确认这种携带任务栏的GUI桌面到底是源自何方，不过无所谓，就假设它是微软的原创吧。

一直纳闷，Windows的手机和平板总是看起来别别扭扭的，也不知道哪里出了问题。后来终于找到了这件事和任务栏的关联。

在手机，平板这种屏幕有限，且用户关注单一全屏UI的环境下，根本就没有任务栏存在的必要，推而广之，其实就算在Windows XP上，也不需要有任务栏，那为什么要有任务栏？

我假设任务栏是从微软开始设计出来的。

任务栏是为了暂存GUI程序的窗口的，虽然桌面本身就已经支持了重叠窗口，但是为了让桌面可以更加整洁些，Windows允许将非前台的程序窗口最小化暂存到任务栏，等到它获得焦点的时候，再恢复它到前端。

现在的问题是，为什么要暂存一个GUI窗口，直接结束掉这个程序不行吗？答案看起来很简单，因为有很多的状态需要尚未保存和同步，比如用户可能在记事本上输入了一句不完整的话等等。

但这根本不是问题的满意答案，系统完全可以在结束这个GUI程序时自动保存状态啊，在用户看来，用户关心的是，只要它恢复的时候能保持和它上次离开焦点时的样子一致就可以了，而这些都是可以系统后台完成的啊。

任务栏根本就不需要，在GUI桌面系统，任何时候有且只有一个GUI程序的窗口时焦点窗口，系统可以随时结束任何非焦点的GUI程序，只要当它再次希望获得焦点时，恢复到系统关闭它时的状态即可。

没错，Android等手机，平板操作系统就是这么控制GUI窗口的，对于这些手机操作系统而言，一个小小的屏幕上往往只有一个程序在获取输入和输出，以上的特征更加明显，那么后台的程序便可以随时持久化后被系统结束掉，以节约能耗，当用户再度切换到该程序的时候，系统重新运行该程序就好了，然后反序列化同步状态即可。

Android和Windows的差别在于，到底是谁来结束GUI程序的差别，Android将控制权完全掌握在系统手中，而Windows XP则将控制权交给了用户。

在Windows XP看来，它是把所有的程序的控制权都交给了用户了，并没有对GUI程序加以区别，这是老式UNIX的传统。然而，GUI程序有所不同。

和服务器程序比如Apache需要持续侦听端口提供服务不同，GUI程序的运行几乎完全靠用户的操作来驱动，一旦失去焦点，GUI程序几乎是无事可做的，它就静静地hang在哪里，平白无故地占用着系统的资源，而这是没有必要的。

Windows 8开始有了Metro界面，新的GUI控制改变了Windows XP的做法，它也可以在保证状态同步的前提下，随时结束非焦点GUI程序了。然而，毕竟有历史的兼容性包袱，Windows 8做的并不纯粹，它仍然可以用任务栏来暂留GUI程序窗口。怪不得Surface的界面总是那么别扭，估计也有这方面的原因。

可能有人会有疑问，这样岂不是不能同时协同操作多个GUI程序了吗？

事实上并不是说只要GUI程序失去焦点就马上被关闭的，而是维持一个LRU链表，把最近超过多久不活跃的GUI程序关掉。

涉及到多个GUI程序之间切换的话，只需要为被关闭的GUI程序保留一个图标即可，只要save/restore做好，程序加载够快，就可以做到 像以前一样的自如切换。

在GUI程序失去焦点的时候获取事件，事件处理回调中保存上下文信息，这样一来，系统便可以在任何它觉得合适的时候结束掉该GUI程序了，比如该程序太久不活动，比如电池电量少于40%，比如CPU过热等等。最直接的策略还是维护一个LRU链表，把最近最不经常使用的GUI程序结束掉，以维持资源消耗在一个可以接受的水平。

不过，GUI进程生命周期是由用户控制还是由系统控制，这是一个永远都会有争议的话题。这就像微内核和大内核谁好谁坏一样。

另外，专业人士喜欢把电脑桌面仅留一张背景然后所有东西都扔进开始菜单，这个估计也是微软给带的。事实上，真实情况是，当你真的在使用电脑的时候，桌面背景很少有机会完全显露。在我看来，正确的做法应该是将应用程序分组，然后合理布局在桌面上，就像MacOS那样，就挺好。

版权声明：本文为CSDN博主「dog250」的原创文章。