[手机平台]Alarm事件管理器设计备忘录

[手机平台]Alarm事件管理器设计备忘录

转载时请注明出处：http://blog.csdn.net/absurd

这里的Alarm是指定时提醒相关的Alarm事件。在智能手机里，个人信息管理(PIM)是其重要组成部分之一，而在PIM应用程序里，很大一部分都与Alarm有关，比如闹钟、日程和任务等等。加上其它诸如定时开/关机等杂七杂八的应用程序，很多应用程序都与Alarm事件有关。所以Alarm事件的处理，在很大程度上影响着系统的复杂性和工作量。这里对Alarm事件管理器的设计做个简要备忘。

设计时我们主要做了下列考虑：

1. 避免重复。众多应用程序都涉及到Alarm事件的管理，它们对Alarm事件的处理方式也很相似：Alarm信息存放在数据库里; 定时时间到了要提醒用户;用户可以查看Alarm事件的详细信息。为了避免不必要的重复，我们决定以统一的方式处理Alarm事件。

2. 作为后台服务运行。选用哪一种方式呢？作为一个函数库还是作为一个服务提供呢？ Alarm事件管理要一直运行，不能因为闹钟这个应用程序退出了，闹钟提醒就不起作用了。当然，我们也不能要求所有Alarm相关的应用程序都常驻内存，那样开销太大了。为了解决这个问题，我们决定让Alarm事件管理器作为后台服务运行。

3. 降低开销，提高性能。Alarm事件管理器的计算量并不大，除了进行一些排序和数据库操作外，大部分时间都处于睡眠状态。但是作为一个独立进程，一些必要开销是不可避免的，我们不希望系统中出现太多这类简单的服务进程。为了降低简单服务进程带来的额外开销，我们决定实现一个服务器框架，像Alarm事件管理器这类简单服务，通过插件挂起进来运行。

4. 降低应用程序的复杂度。作为一个服务提供，会不会比较麻烦呢？Alarm相关应用程序比较多，即使能降低一点复杂度，节省的工作量也是可观的。为了降低应用程序的复杂度，我们决定让Alarm事件管理器独立于应用程序，由一个Alarm桌面项来响应Alarm事件，直到用户要查看事件详情时，才起动相应的应用程序。

系统结构图：

<shapetype id="_x0000_t75" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 415.5pt; HEIGHT: 294.75pt" o:ole="" type="#_x0000_t75"><imagedata o:title="" src="file:///C:/DOCUME~1/q/LOCALS~1/Temp/msoclip1/01/clip_image001.png"></imagedata></shape>

1. 日程和闹钟等应用程序，完全不需要关心Alarm事件管理器，它们要做的只是把Alarm事件信息存入数据库，或者查看/修改已经存在的记录。它们不需要关心定时器的设置，不需要关心提醒用户的处理，更不需要一直运行。这大大降低了应用程序的复杂度。

2. 数据库是我们所有PIM应用程序的中心。它采用sqlite作为引擎，我们在sqlite上做了两大重要改进：一是把sqlite由函数库的方式改为服务器的方式，这为多个应用程序并发访问提供了方便。二是提供修改通知机制，采用发布/订阅模式，应用程序都可以监视数据库，数据库有任何变化，相应应用程序可以得到通知。

3. Alarm事件管理器作为一个插件在服务框架进程中运行。它会监视数据库中Alarm相关的表，一旦这些表被修改，它会更新Alarm事件列表，重新按时间排列Alarm事件列表，并更新定时器。它也提供了一个种事件通知机制，当定时器到时间了，它触发一个Alarm事件，并以Alarm事件相关信息作为参数。这是一个dbus事件，是可以跨进程传递的。

4. Alarm桌面项作为桌面的一个小插件运行。桌面通常是一直运行的，所以Alarm事件桌面项也是一直运行的。Alarm桌面项注册Alarm事件管理器的事件，当Alarm事件管理器的定时器到时间了，Alarm桌面项得到通知，然后弹出提示框提醒用户(可能伴随铃音)。

5. 如果用户要查看Alarm事件的详细信息，由Alarm桌面项起动相应的Alarm应用程序。应用程序名称是从Alarm事件信息中获得出的，所以Alarm桌面项与应用程序的耦合是很松散的。

为了保证Alarm桌面项和Alarm事件管理器的通用性，不必为不同的 Alarm应用程序做特殊处理，我们还需要注意几点：

1. 数据库中Alarm相关的表要统一处理。都要支持几个通用的字段，这些字段的名称、类型和意义要一致。

2. Alarm应用程序要支持统一的命令行参数。Alarm桌面项起动Alarm应用程序时，按统一的格式把Alarm事件ID传递给Alarm应用程序，Alarm应用程序打开ID对应的记录，让用户可以查看。

3. 通过配置信息去确定应用程序名称以及它和表的对应关系。在添加新的Alarm应用程序时，只需要修改这个配置文件即可。配置文件是由gconf管理的，可以在运行时添加。

特殊情况处理：

1. 关机。由于关机后，所有程序停止运行了，定时功能只能由硬件定时器处理。在关机前要把最近的Alarm事件设置到硬件定时器中。在linux下，应用程序不能直接操作硬件设备，只能由驱动提供一个接口，通常是一个设备文件，通过iocctl设置。另外也要避免在关机过程中，硬件定时器到时间，所以如果最近的Alarm事件离当前时间太近，在做适当延时处理。

2. Alarm开机。如果在关机前设置了硬件定时器，在关机状态也可以处理Alarm事件。硬件定时器到时间了，它会自动开机。开机后，我们从硬件的某个寄存器中读取一个标志位，用来判断是正常开机还是Alarm开机。如果是Alarm开机，在用户查看或者超时后，要重新关机(定时开机除外)。

~~end~~