但是，启动时的时间却有些问题，比较慢。在这个 CPU 上，应用程序画面加载与显示的时间需要 2.4秒，其中 1.5 秒是花在了建立与显示 UI 上。

　　在较慢的 CPU 上，这样的启动速度是 GTK+ 运行在 X，X 再写到 framebuffer 上导致的。我们需要分析具体的瓶颈在什么地方。在深入的调试中，当使用PC机来运行我们的应用，而在ARM设备上显示时，初始化和显示的时间几乎可以忽略不计。同样，将应用运行在ARM设备上，而在PC机上显示时，性能也很好。所以数据包的传输，framebuffer上的显示及GTK+的运算速度都不是问题所在。速度慢的原因可能是这几个因素的先后顺序引起的。而且内存的占用上也存在问题。在初始阶段，GTK+构造了大量的对象，GTK+和X是使用共享内存来通讯的，X写到framebuffer，framebuffer也是不变地写到显存上。这些都是发生在一个较窄总线上相同的内存空间里，这个就会引起速度慢。

　　现在知道了X在启动时比较花费时间。在客户模式下的GTK+的应用，需要连接到X server，通过了认证，得到位深及其他资源。当然，使用X系统的好处要远大于它的不足。X系统提供了一个灵活的client/server模型，这样更有利于应用的灵活加入。你可以在同一时间显示不用的应用窗口，而像GTK+/Fb等其他的GUI方式无法做到这一点，当然QPE是个例外。

　　2.4秒的延时，也并不能完全否定一切。在一个700MHZ的windows系统的PC上，Microsoft Word, Excel and IE几乎都需要2秒的时间来启动。KEdit, 一个KDE的应用程序，在500MHZ的PIII上，加载的时间也需要1.37秒。

　　对于启动时间，需要采用其他的办法来加以改善。一个策略就是在用户等待的时候，显示一些东西来表示系统正在工作，这样会使用户忽略掉启动时间的缓慢。另一个策略就是可以预先在背后启动一些通用的程序，来有效减少集中启动的时间。这也是通常嵌入系统所惯用的做法。

　　优化

　　在ARM7的系统上，由于没有浮点运算FPU，所以GTK+中的浮点运算部分最好是去掉，否则会大大影响性能。GTK+使用到的浮点变量只分布在少数的几个窗口中，并且去掉它们会带来3%到12%的性能提高。

　　高像素的应用会导致速度较慢，这大多是由于GTK+与X中对高像素的效率低下的处理有关。如涉及到的XPM，XPM （X pixmap）格式是被设计来做到较好的兼容性，而不是更加快速。X系统是一个像素一个像素地画到server的pixmap的。GTK+的像素处理也很低效，它是使用fgetc()来读取XPM文件的，这就会带来大量的上下文切换开销。

　　X窗口系统的结构也导致了像素的加载变慢。GTK+客户端需要加载，分析XPM文件，将像素值通过传输协议发送给server，然后server才将像素值放入framebuffer。如果客户端直接将数据写到framebuffer server那将会有效很多。

　　处理的GTK+像素的办法就是，写一个临时的中间过程，取得render过的像素，使用这个原始数据来替换XPM数据，这个原始数据就可以直接强制写到X server上。从结构上来看，这虽然不是一个很好的处理办法，但在效率上却要比使用XPM要快上80%。

　　总结

　　现在的消费电子大多需要一个美观，实用的图形界面系统GUI。在嵌入系统linux下，有很多种GUI可供选择。使用开放代码的GUI的优点就是你可以将其裁剪得满足你的各种各样的特殊需求。GTK+就是一个很好的选择，而X-window系统提供了一个稳定可靠的client/server模型。当你得到一个只有2.9M大小的定制过的GUI时，对大多数的嵌入系统还是很有参考价值的。

　　关于作者

　　余涛，高级软件工程师，现从事 linux 嵌入式系统的开发工作，主要研究方向嵌入系统，UPNP 多媒体播放系统。您可以通过电子邮件 yut616@21cn.com 和他联系。希望能与更多的朋友交流关于 Linux 方面的知识。

　　(参考链接: http://www.ibm.com/developerworks/cn/linux/l-embedded-gui/index.html)