Chinaunix首页 | 论坛 | 博客
  • 博客访问: 192516
  • 博文数量: 111
  • 博客积分: 3010
  • 博客等级: 中校
  • 技术积分: 1240
  • 用 户 组: 普通用户
  • 注册时间: 2009-08-07 07:46
文章分类

全部博文(111)

文章存档

2015年(2)

2014年(1)

2011年(1)

2010年(7)

2009年(100)

我的朋友

分类: LINUX

2009-08-23 16:58:33

转载时请注明出处和作者联系方式

文章出处:http://www.limodev.cn/blog
作者联系方式:李先静

有 的应用程序起动过程比较长,在起动之后,一定时间内没有反应。为了避免让用户等得不耐烦,或者误以为死机了。在此期间,提供一个动画或者其它东西来标识正 在起动的状态,可能会更友好一些。Startup notification的初衷也在于此,它跟踪应用程序的起动过程,以便给用户提供一些反馈信息。

当然,Startup notification并不限于应用程序的起动过程,它也适用于打开窗口,或者其它长时间的操作。我们这里讨论的Startup notification有两层含义:

1.Startup notification协议。该协议由freedesktop()制定,它基于X Windows的客户端消息(ClientMessage)机制,因此消息可以跨进程传递,而无需要额外的IPC机制。在协议中,它定义了消息的类型、参 数、使用上下文和其它一些注意事项。

2.Startup notification库。Startup notification协议是基于X Windows消息来定义的,使用不太方便,而且只限于X Window环境,不具有可移植性。freedesktop同时提供了该协议的一种实现,该实现抽象出了定义良好的接口,使用者无需关心里面的实现,所以 很容易移植到非X Window的环境。

最初我对Startup notification没有多大兴趣,原因之一是因为,我们的GUI是基于DirectFB而非X Window,不能直接使用freedesktop提供的库,如果使用Startup notification,就得要自己去实现。我不喜欢把事情搞得复杂化,所以当时就没有考虑这个问题。直到最近遇到几个麻烦:

1.后台服务起动的依赖关系。我们有多个后台服务进程,放在一个起动脚本里起动,服务之间有严格的依赖关系,被依赖的服务可能还没有初始化完成,已经有客户端向它请求服务了,此时请求必定会失败,继而引发一些其它问题。

2.应用程序起动过程较长。等待时间过长,用户往往以为死机了,或者没有点中,然后狂击屏幕,结果造成多次起动,让系统变得更慢。

3.其它长时间操作,用户等得烦躁。有时打开某个窗口,或者保存文件,或者其它长时间操作,如果没有提示,用户就会等得着急。

由于我们的GUI是基于DirectFB的,不能使用X Windows的消息机制,自然无法从根本上兼容Startup notification协议,也不能直接使用freedesktop实现的库。看了一下freedesktop实现的Startup notification,它分为三个部分:

1.sn-launcher.h定义了起动者的接口。sn_launcher_context_initiate用来标识起动的开 始,sn_launcher_context_complete用来标识起动的结束。至于为什么起动者可以调用 sn_launcher_context_complete来标识起动结束,我想可能是因为起动可能会失败,如果失败被起动者根本没有机会发出起动结束的 的消息,为了配对,此时起动者可以发出一个结束消息。

2.sn-launchee.h定义了被起动者的接口。sn_launchee_context_complete用来标识起动的结束。被起动者起 动后,它进入正常状态了,就可以调用sn_launchee_context_complete告诉所有关注者:自己准备好了。

3.sn-monitor.h定义了监听者的接口。任何关注起动过程的程序都可以调用这套接口去监听起动过程,监听者可以是起动者,也可以是被起动者,也可以是第三方程序,所以这部分功能独立实现是合理的。

在研究之后,我们发现完全可以独立于X Window来实现兼容这套接口的库,尽管可以通过DirectFB的进程间通信机制去分发消息,但考虑到一些后台服务都是与界面无关的,为了避免与GUI的耦合,最终决定用DBUS而非DirectFB作为通信机制。

我们实现了一个名为AppManager的服务,它负责起动其它服务和应用程序,并作为Startup notification消息的中转站。在它提供的消息转发接口上,包装出Startup notification的接口,这套接口兼容freedesktop实现的Startup notification的接口,以保证其它应用程序可以方便的移植到我们平台上来。

有了Startup notification,前面三个问题就迎刃而解了:

1.后台服务起动的依赖关系。AppManager负责起动所有的服务,对于有依赖要求的服务,在收到起动完成的消息之后,才起动下一个服务。

2.应用程序起动过程较长。在起动过程中给出动画提示,以缓解用户着急的心态; 忽略此期间的点击消息,以避免重复起动。

3.其它长时间操作,用户等得烦躁。这可以在状态栏上显示状态动画,笔点移动到上面时,还可以给出提示。

给用户的状态提示是在一个地方完成,我们把它实现成一个桌面项,挂在状态栏里,它监听所有Startup notification事件,并在适当的时候给出状态提示。起动者和被起动者,只需要触发事件,而不关心事件处理,即简单化了实现,也隔离了用户界面和内部逻辑。

参考资源:

1.

2./startup-notification-spec/startup-notification-latest.txt

阅读(1457) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~