• [手机平台]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事件,直到用户要查看事件详情时,才起动相应的应用程序。

     

    系统结构图

    o_alarmevent 

    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~~

     

     
  • 相关阅读:
    Appium+python自动化13-native和webview切换【转载】
    Appium+python自动化12-appium元素定位【转载】
    Appium+python自动化11-adb必知必会的几个指令【转载】
    Appium+python自动化10-AVD 模拟器【转载】
    Appium+python自动化9-SDK Manager【转载】
    Appium+python自动化8-Appium Python API【转载】
    Appium+python自动化7-输入中文【转载】
    Appium+python自动化6-Remote远程控制【转载】
    Appium+python自动化5-Appium Inspector【转载】
    Centos-内核核心组成
  • 原文地址:https://www.cnblogs.com/zhangyunlin/p/6167807.html
Copyright © 2020-2023  润新知