CN101971144A - 受系统资源影响的阶段式停机 - Google Patents

Abstract

本发明提供了一种用于将其上正在运行多个软件组件的计算设备停机的方法。更具体地，本发明提供了一种方法，用于如果未向组件供应充足的资源以完成特定停机操作，则按照设备在重启时是否会经历严重问题，而对软件组件的停机划分优先级。

Description

受系统资源影响的阶段式停机

技术领域

本发明涉及计算设备以及将这种设备停机的相关联方法。更具体地，当请求设备停机时，多个软件组件正在该设备上运行，并且如果组件不能完成其停机任务，则指示每个组件按照计算设备受影响的严重性的顺序来执行停机任务。

背景技术

已知当诸如移动通信设备之类的计算设备正在操作时，设备的操作系统启动和控制各种软件组件的执行。操作系统执行每个组件以执行有助于移动通信设备的主操作功能的某些计算方面，诸如，主控电话呼叫或接收消息。实际上，为了执行主操作功能，已知的计算设备执行多个较小的操作，这些较小的操作组合起来以支持主操作。根据组件类型和操作，每个较小的操作可以由单个组件或多个组件来执行。

在使用移动通信设备主控电话呼叫的示例性实例中，较小的操作可以是：从移动通信设备的用户接收电话号码，与协同操作的移动电信网络建立通信，对来自用户的语音进行编码，或者对用于用户的语音进行解码。

为了组织在任意给定时刻在计算设备上运行的多个软件组件，计算设备将其布置成分层结构。每一层对应于来自基本操作级的抽象级。这样，最低层的组件实现能够非常快速执行的基本、原始的功能。最低层也是最有特权的层，因此该层内的组件通常能够访问操作系统的所有元件。从最低层到最高层贯穿该分层结构，由每一层内的组件执行的功能变得不那么原始，并且特权被取消。通常还存在这样的情况，较高层内的组件的操作依赖于较低层内的组件的操作。

已知对于要操作的组件，需要至少下列有限资源之一：功率、存储容量和存储器。当接收到将计算设备停机的请求时，无论是由设备发起还是由设备的用户发起，该设备都必须处理此刻正在设备上运行的所有组件。为了处理正在运行的组件，设备必须调度对有限资源的访问，使得组件可以完成其操作。通常可能要求在组件停机之前由组件完成的操作包括：将数据从工作存储器保存到存储存储器中、冲刷缓存或将永久存储器区域设置为只读。这种任务在本文中称为停机任务。

存在这样的情况，对于某些组件，在组件正处于其操作中途时移除电源并没有严重后果。然而，对于某些其他组件，在组件正处于其操作中途时移除电源有可能在设备重启时引起严重的问题，并且可能导致设备故障，仅部分运转或者完全不能运转。可能产生严重问题的一种可能事件是损坏或者丢失设备运行的关键数据。这种事件可能引起重启方面的问题，例如在重启时要求运行数据完整性例程，从而延迟重启。在极端情况下，数据可能丢失。

上面提到的停机过程的复杂性在于：组件通常在完成操作时需要使用存储容量和存储器，并且这些资源(诸如功率)也是有限供应的。经常首先由于缺少这种资源而引起停机，这通常是在设备电池耗尽时。

在个人计算机领域，已知为在个人计算机上运行的进程指派停机优先级别。这些停机优先级别定义了一些进程相对于系统中的其他进程的停机次序。一种示例情形是以Microsoft Developers Network (MSDN

)为特征的Microsoft

Windows

功能“SetProcessShutdownParameters(设置进程停机参数)”。注意，这些已知的系统简单地支持对进程停机次序的说明，它们并没有定义任何特定次序。

在个人计算机和移动通信设备两个领域中，还已知为了调度正在系统中运行的进程，实施优先级策略。在一种优先级策略中，进程具有对应于该进程功能对系统而言有多重要的优先级别。在诸优先级策略中，允许运行的进程是具有最高优先级的等待进程。优先级通常采取数字的形式，然而在系统之间有关为进程指派优先级并没有通用的协定。通常，优先级越高，进程就越重要，并且因此具有最低优先级的进程执行最粗浅的任务。应当注意，系统使用优先级策略来调度进程的操作，以便使得系统更为有效地操作。优先级策略不对进程进行调度来维持系统的完整性，并且由此无法避免停机后系统重启时的严重问题。

发明内容

为了解决上述问题，本发明的一个实施方式提供了一种用于将其上正运行多个软件组件的计算设备停机的方法。更具体地，本发明的一个实施方式提供了一种方法，用于在软件组件未被提供足够的资源来完成特定停机操作的情况下，根据设备在重启时是否会经历严重问题来对软件组件的停机划分优先级。

鉴于上述，本发明提供了一种将具有多个在计算设备上运行的软件组件的该设备停机的方法，该方法包括：

a.如果至少一个组件不能完成其停机任务，按照计算设备受影响的严重性，来向该组件或每个组件指派停机分类；

b.检测停机请求；以及

c.按照停机分类的顺序通知每个组件以执行其停机任务；其中响应于停机通知，每个被通知的组件执行其停机任务。

本发明的另一方面提供了一种包括停机管理器的计算设备，其中多个软件组件正在该设备上运行，该停机管理器执行下列步骤：

a.如果至少一个组件不能完成其停机任务，则按照计算设备受影响的严重性，来向该组件或每个组件指派停机分类；

b.检测停机请求；以及

c.按照停机分类的顺序通知每个组件以执行其停机任务；

其中响应于停机通知，每个被通知的组件执行其停机任务。

本发明的主要目的在于将执行对于计算设备的完整性而言的关键操作的组件的停机调度在执行非关键操作的组件之前。相应地，本发明的主要优势在于最小化了丢失或损坏对于设备运行而言关键的数据的风险。因此，本发明降低了计算设备故障、仅部分运转或完全不运转、或者丢失数据的可能性。

本发明的另一优势在于不对非关键组件进行调度，以免用尽更适合指派给更关键组件的计算设备的有限资源。本发明的另一效果在于，由于较少关键组件不能在移除电源之前完成其停机任务，因此在设备启动时需要执行较少的数据完整性校验来修复丢失或损坏的数据。因此，本发明的进一步优势在于，由于减少了执行数据完整性校验的需求，因而支持更快速的重启时间。

优选地，停机分类被指派给具有要在设备停机时执行的至少一个特定任务的每个组件。

优选地，实施方式中通知运行组件执行其停机任务的顺序从具有最关键停机分类的组件开始，继而按照关键性降低的次序继续，直到通知到具有最低关键停机分类的组件。

优选地，该顺序考虑了每个组件与其他组件的依赖关系。因此，当每个组件被通知执行其停机任务时，在顺序中的下一组件被通知执行其停机任务之前，该组件的相互依赖的组件也被通知执行其停机任务。

优选地，该顺序对应于计算设备的操作系统的分层结构。因此，仅在较高层启动的所有组件都已被通知执行其停机任务时，较低层启动的组件才被通知执行停机任务。

优选地，定义两个停机分类：“关键的”和“非关键的”。

优选地，有限资源包括：电池能量、存储容量和存储器。

优选地，在所有被通知的软件组件已执行其停机任务之后移除供给计算设备的电源。

优选地，计算设备是移动通信设备。将本发明应用于移动通信设备，诸如移动电话，提供了特别的优势，因为这种设备通常资源极度有限。

附图说明

现在将参考附图，对仅作为示例方式呈现的本发明优选实施方式进行描述，附图中类似的参考标号指示类似部件，其中：

图1是已知移动通信设备的示意性视图；

图2是已知移动通信设备的内部硬件元件的示意性视图；

图3是存储在已知移动通信设备的内部硬件元件上的软件内容的示意图视图；

图4是图3的软件内容的示例性结构的示意性视图；

图5是在已知移动通信设备上运行的相互依赖的软件进程的示意图视图；

图6是在图5的软件进程内运行的相互依赖的软件线程的示意性视图；

图7是存储在按照本发明的优选实施方式布置的移动通信设备的内部硬件元件上的软件内容的示意性视图；以及

图8是示出了按照优选实施方式布置的移动通信设备的操作的流程图。

具体实施方式

本发明的实施方式基于已知的移动设备平台，下面将针对图1-图6进行描述。

图1中通过参考标号2表示已知的移动通信设备。移动通信设备2包括显示屏4、输入按钮6和电源按钮8。移动通信设备2能够由用户操作以执行各种操作，诸如，主控电话呼叫。

图2示出了移动通信设备2的一些内部硬件元件的示意性视图。中央处理单元(CPU)10连接到硬件总线12，硬件总线12继而连接各种硬件单元，包括：电池14、某随机访问存储器(RAM)16、诸如闪存18的长期存储器、某只读存储器(ROM)19以及多个硬件设备20。硬件设备20包括诸如输入按钮6和显示屏4之类的设备。尽管移动通信设备2需要硬件设备20以运转，但是这些硬件设备不是特别用于构成本发明的一部分，因此将不会对此详细描述。

在操作中，硬件总线12在硬件单元16到20与控制CPU 10之间提供通信链路。控制命令通过CPU 10发送到硬件单元16到20，硬件单元16到20在相反方向上返回数据。电池14为此装置提供电源。此外，CPU 10对从硬件设备16到20接收的数据进行处理，以便完成其操作任务。因此，CPU 10指示和控制硬件设备16到20提供移动通信设备2的功能性。CPU 10的操作由软件操作系统24来指定，软件操作系统24(如图3中更具体示出的)通常存储在ROM19上。大体而言，操作系统24的职责是管理计算设备的硬件资源和软件资源。这些资源包括诸如CPU 10、RAM 16和存储器18之类的事物。如此，操作系统为在设备2上运行的软件应用提供了稳定、一致的方式来对待设备2的硬件资源，而无需应用知晓可用于硬件的物理资源的所有详情。

图4示出了安装在移动通信设备2上的操作系统24的示例性结构。操作系统24包括多个层：核心服务层28、基本服务层30、操作系统(OS)服务层32、应用服务层34和用户接口框架层36。这些层28、30、32、34和36反映了操作系统24中不同层上的功能性。多个软件组件，诸如进程和线程，在操作系统24的结构内操作以支持移动通信设备2操作。一般说来，越远离底部核心服务层28的层，对可用于硬件的物理资源的详情知道得越少。

核心服务层28是最低层，其实现执行得非常快速的最基本、原始的功能。此外，层28是最有特权的层，其能够访问操作系统24的所有元件。如果按次序考虑每个外面层30、32、34和36，则随着每个层30、32、34和36的位置越来越远离层28，每个层30、32、34和36的功能变得越来越不那么原始，而且特权被取消。

基本服务层30提供框架、库和实用程序，其使得硬件设备14到20能够结合CPU 10以变成可编程机器。OS服务层32控制下面的层(28、30)以提供完整功能操作系统，其能够跨不同技术范围而提供服务，诸如电话、消息收发、图形和数据连接性。应用服务层34为特定于不同可用技术的软件应用和服务提供通用框架。最后，用户接口框架层36为用户接口平台提供服务框架，例如图形用户接口框架。

在操作系统24的每一层28、30、32、34和36中，该层的操作由移动通信设备2使用各种不同的软件组件(例如，进程和线程)来实现。根据组件类型和操作，每个操作可以由单个组件或多个组件来执行。

图5和图6示出了操作系统24如何启动移动通信设备2上的多个软件组件以执行移动通信设备2的功能性。图5示出了通过链路42连接在一起的多个进程40。链路42的箭头指示进程40之间的操作流，因此在图5的上部发生的进程在下面较低的进程之前执行和完成。虚线44表示操作系统24的各层28、30、32、34和36之间的边界，因此线44可以用于确定哪个层28、30、32、34和36对各个进程40进行实例化。

图5的示例性情形示出了在用户接口框架层36中实例化单个进程40，例如作为移动通信设备2的用户通过按压电源按钮8以指示移动通信设备2停机的结果。图5还示出了随着移动通信设备2的操作系统24按照指示来执行停机操作，多个其他进程40被启动以完成较小的操作，这些操作组合在一起以支持整个停机操作。链路42指示存在于诸进程40之间的依赖关系。

图6详细示出了图5的进程40之一，以说明有些进程40包含多个较小的软件组件或线程50。每个线程50可以执行比进程40所执行的操作大小更小的操作。此外，线程50所执行的操作有助于线程50所位于的进程40的较大操作的执行。备选地，线程可以用于允许操作的多个实例对相同数据同时进行操作。时间推移由线程50和链路42的箭头表示，因此，发生在图6之上更高的操作在发生在图6之下更低的操作之前发生。

操作系统24按照上面所定义那样管理移动通信设备2的硬件和软件资源，以确保移动通信设备2稳定操作的方式之一是通过使用系统状态管理器(SSM)(未示出)。SSM的职责是管理移动通信设备2整个生命周期期间的状态，包括启动和停机。SSM提供了允许在移动通信设备2上运行的具有适当安全特权的软件组件请求改变系统状态的接口。移动通信设备2可以工作于四个不同的状态，分别是：启动、停机、正常和失败。SSM被配置成使得不同事件的发生导致SSM改变移动通信设备2的状态。例如，如果存在连续的启动失败，则SSM将移动通信设备2移动到失败状态。

系统状态由实现在位于闪存18或ROM 19上的软件代码中的策略来定义。这些策略定义了上述四个状态、允许的状态转移以及在状态转移期间执行的任务。当移动通信设备2改变状态时，SSM向已经请求要被通知到的软件组件分发系统状态改变通知。继而，被通知的进程能够暂时延迟未决状态改变，以便执行在状态改变之前必须执行的必要任务。此外，系统状态策略定义了被通知的组件必须完成其任务的最大响应时间，以及当被通知的组件在该事件内未完成其任务时发生的事情。

到目前为止，对移动通信设备2及其操作的上述描述包括包含在现有技术状态中的内容。接下来描述在本实施方式中提供的用于解决前面较早提到的问题的附加物。

更具体地，本发明的优选实施方式提供了包括本文前面参考图1到图6所描述的操作系统24的移动通信设备2。然而，如在图7中更具体地看到的，优选实施方式的ROM 19进一步包括停机管理器60，其能够影响操作系统24的操作。停机管理器60的操作与SSM紧密联系，并且在某些实施方式中，停机管理器60构成处理系统停机的SSM的一部分。

停机分类被指派给具有要在检测到设备停机之后且在设备停机完成之前执行的至少一个特定操作的每个软件组件。多种不同方法可以用于指示和指派软件组件的停机分类。在一个实现中，分类由进程元数据来指示，并且在创建定义软件组件的计算代码时由开发者手动指派。

可选地，在另一实现中，分类存储在闪存文本文件(未示出)中，该闪存文本文件存储在闪存18中。文本文件的内容包括通过名称参考的软件组件列表，以及针对每个软件组件的对应停机分类。文本文件中提到的每个软件组件是操作系统24的软件组件，因此其执行有助于操作系统24的功能性的任务。此外，文本文件中提到的每个软件组件具有要在检测到设备停机之后且在设备停机结束之前执行的特定任务。在编译时，文本文件中特定的每个软件组件按照其在文本文件中相应的条目而被指派停机分类。

无论使用哪种实现来指示和指派停机分类，都不向不具有要执行的特定停机任务的软件组件指派停机分类。相反，向具有要执行的特定停机任务的软件组件指派适当的停机分类，或者“关键的”，或者“非关键的”。

关键分类被指派给操作系统24的这种软件组件：如果其未提供有充足的资源来完成其停机任务，则认为会严重地影响移动通信设备2的完整性。严重影响的一个示例是导致移动通信设备2在停机之后重启时故障的数据被丢失或者损坏。非关键分类被指派给操作系统24的这种软件组件：即如果那些组件未提供有充足的资源来完成其停机任务，那么它们也不会严重地影响移动通信设备2的完整性。具有关键分类的操作系统24的软件组件在此后称为关键组件，而具有非关键分类的操作系统24的软件组件在此后称为非关键组件。

可以在计算设备上运行的关键组件的一些示例包括：

-冲刷缓存的文件系统进程；

-存留可改变的设置，例如可修改的硬件抽象层属性，或者冲刷数据库缓存；

-在设备已经出售给消费者之后对安装在设备上的应用进行初始化。

可以在计算设备上运行的非关键组件的一些示例包括：

-会话发起协议(SIP)服务器进程(其中网络注册将简单地超时)；

-通用即插即用(UPnP)网络服务进程(其中服务指示将简单地超时)；

-非系统应用(诸如可能期望保存用户的最高分的游戏)。

通常，非关键组件驻留在操作系统24的较高层，而关键组件驻留在较低层，当然这不一定总是这种情形。

在操作中，当请求设备停机时，停机管理器60发送状态改变通知，以向具有要执行的停机任务的软件组件通告移动通信设备2的系统状态中的改变。例如，设备停机请求可以作为移动通信设备自身请求停机的结果而发生，因为它的电池能量已经变得太低而不能保持继续操作。

现在将参考图8的流程图来描述从检测到设备停机的时刻开始的停机管理器60的操作。步骤100指示SSM检测到设备停机。一旦SSM已经检测到停机，则操作为停机管理器60的SSM按照启动软件组件的操作系统24的层(28到36)来通知正在运行的软件组件以执行停机任务。更具体地，所有正在运行的软件组件被组织成由域管理器(未示出)维护的域的层级体系。域管理器是停机管理器60的内部元件，该域层级体系的结构对应于操作系统24的分层结构。每个域的内容被布置成包含全部从操作系统24的分层结构中的类似位置启动的一组软件组件。如此，当某个软件组件被指派停机分类时，该组件注册到对应于该组件从其启动的操作系统的分层结构中的位置的域。

此外，经常存在这样的情况，某个软件组件的操作可以依赖于另一软件组件的操作。域被定义成使得在单个域内，没有软件组件可以依赖于也在该同一域内的任何其他软件组件。因此，当源于操作系统24的分层结构中的类似位置的软件组件互相依赖时，创建完全对应于操作系统24的分层体系中的相同位置的多个域。

一旦在步骤100中SSM检测到停机，则处理前进到步骤102，其中停机管理器60通知最高域中具有未决停机的正在运行的关键组件的所有软件组件。在通知之后，处理前进到步骤104。SSM的此操作有效地向组件通知系统状态改变为新的关键停机系统状态。步骤104表明仅最高域中的关键组件通过执行其停机任务来对该通知做出反应。注意，尽管该域中非关键的软件组件也接收停机通知，但是只有关键组件对该通知做出反应。此操作之后，处理前进到步骤106。在接收到执行停机任务的通知之后，关键组件执行那些任务，并且在其完成任务时向SSM确认。在步骤106，处理一直等待直到最高域中所有被通知的关键组件已经向SSM确认它们已经完成任务，此时处理返回到步骤102。此外，如果最高域中不是所有被通知的关键组件都已确认但是预定超时周期已经期满，则处理将会从步骤106流到步骤102。一旦返回到步骤102，SSM就通知次高域中具有未决停机的正在运行的关键组件的所有组件。处理继而将从步骤102流到步骤104和106，并接着返回到步骤102，如前面针对最高域所讨论的，不过这次是针对次高域。

步骤102的处理会继续经由步骤104和106按环路流动返回步骤102，只要存在包含正在运行的关键组件的域，有可用的功率资源以及不是所有预定超时周期都期满。对每个域进行处理的次序对应于操作系统24的分层结构。因此，对应于最高层(层36)的域中的关键组件将被首先指示执行停机任务。之后，任何剩余的关键组件将按照其相应的域距操作系统24的分层结构向下多远的次序，而被指示执行停机任务。如此，对应于较低层的域的组件仅在对应于所有较高层的域的组件已经结束执行其停机任务之后才被指示执行停机任务。而且，通过遵守该顺序，软件组件之间的依赖关系以适当的次序进行处理。更具体地，较高层中的软件组件执行较高级别的操作，并且通常依赖于较低层中执行较低级别操作的软件组件。因此，通过在较低层中软件组件之前通知较高层中的软件组件执行停机任务，软件组件以按照向下依赖关系的次序进行停机。一旦所有关键组件都已结束执行其停机任务或者所有超时周期都已期满，则处理流到步骤108。

步骤108的处理将依赖于停机管理器60的停机策略和移动通信设备2的有限资源的状态。在有限资源接近耗尽的情况下，不指示非关键组件执行停机任务，并且移除供给设备2的电源。这样的操作由从步骤108到步骤110的过程流来表示。可选地，如果所有的有限资源都没有接近耗尽，则处理从步骤108流到步骤112。

步骤112的处理类似于步骤102的处理，区别在于现在是“非关键”组件对SSM发布的未决停机通知做出反应。因此，SSM的此第二通知向组件有效地通知系统状态改变到新的非关键停机系统状态。这样，处理会按环路从步骤112流动到步骤114，接着到步骤116并继而返回步骤112，只要存在包含至少一个正在运行的非关键组件的域并且有可用的功率资源。可选地，有些非关键组件可以在其已经花费了比预定超时周期更长的时间来完成任务的情况下保持在执行其停机任务的状态中。一旦所有非关键组件已经被指示执行停机任务并且确认其已完成那些任务或者所有预定超时周期都期满，那么处理就从步骤112流到步骤110。如上面所提到的，在步骤110，移除供给移动通信设备2的电源，这标志着停机过程的结束。

按照上面参考图8的讨论操作的停机管理器60背后的原理在于实现停机策略，由此首先，按照最大重要性的次序和根据其与其他组件的相互依赖关系的次序，将关键组件停机，由此帮助保持移动通信设备2的完整性。其次，在所有关键组件已被指示执行其停机任务之后，停机策略通知非关键组件执行其停机任务。此过程确保了设备2的有限系统资源在更适合由关键组件使用时不会被非关键组件用尽。在这方面，应当回想到通常设备停机是在有限资源之一(通常是功率)很低时由设备本身命令的。因此，所剩下的资源应当花费在关键组件上。注意，停机策略仅在存在充足的可用资源(正如电池能量)时实施。如果可用功率资源在停机策略执行期间变得耗尽，则将移除供给移动通信设备2的电源。本发明的另一优势在于，单个软件组件，无论是关键的还是非关键的，在停机期间不能支配系统资源。这是因为预定超时周期确保在预定时间周期之后，SSM开始通知未决停机的其他组件，即使被通知的组件尚未确认其已完成停机任务。

上面已经参考由移动通信设备2请求的设备停机(例如因为功率资源快要耗尽)而讨论了本发明的停机管理器60。然而，本发明也能够在设备停机是由移动通信设备的用户请求时(例如当设备已打开时用户按压电源按钮8)进行操作。注意，当本发明与由设备2请求的设备停机结合使用时，可以从本发明获得最大益处。这是因为当用户请求设备停机时，通常的情况是完全存在足够的功率资源供所有组件停机。因此，不太需要对组件停机的次序划分优先级。也就是说，在这种环境中应用按照本发明的停机策略并不会有坏处。

本发明的优选实施方式已经参考被启动已执行操作系统的操作的软件组件进行了讨论。然而，可以对优选实施方式做出修改以产生备选实施方式，其中被启动以执行应用程序的操作的软件组件也可以服从阶段式停机策略。由于本发明的目的是保持诸如移动通信设备的计算设备的完整性，因此在一个备选实施方式中，应用程序软件组件可以仅被指派为非关键状态。按照这种方式，操作系统软件组件通过被指派关键状态，保持了在任何应用程序软件组件之前利用有限系统资源的能力。

尽管已经参考移动通信设备描述了优选实施方式，但是移动通信设备仅仅提供了帮助解释所附权利要求教导的更宽广的创造性概念的手段。因此，同样落入所附权利要求的范围内的备选实施方式可以结合其他计算设备进行操作，诸如膝上型计算机或台式计算机。

可以对上述实施方式做出各种附加和修改以提供其他实施方式，这对于作为本领域技术人员的读者而言是很显然的，并且任何以及所有这些实施方式均落入所附权利要求的范围内。

Claims (26)

1.一种将计算设备停机的方法，所述计算设备具有多个在该设备上运行的软件组件，所述方法包括：

a.如果至少一个组件不能完成其停机任务，那么按照所述计算设备受影响的严重性，来向所述组件或每个组件指派停机分类；

b.检测停机请求；以及

c.按照所述停机分类的顺序通知每个组件以执行其停机任务；

其中响应于停机通知，每个被通知的组件执行其停机任务。

2.如权利要求1的方法，其中停机分类被指派给具有要在设备停机时执行的特定任务的每个组件。

3.如权利要求1或2的方法，其中所述顺序开始于通知具有最关键停机分类的组件执行其停机任务，继而按照停机分类关键性降低的次序继续通知其他组件执行其停机任务。

4.如权利要求1或2的方法，其中步骤c包括：

c.按照根据所述停机分类以及与其他组件的依赖关系的顺序，通知每个组件执行其停机任务。

5.如权利要求4的方法，其中步骤c进一步包括：

c.按照根据所述计算设备的操作系统的分层结构的顺序，通知每个组件执行其停机任务。

6.如前述任一权利要求的方法，其中定义了两个停机分类。

7.如前述任一权利要求的方法，其中由于所述计算设备的用户请求停机，从而检测到停机。

8.如前述任一权利要求的方法，其中由于所述计算设备确定可用于所述设备的多个有限资源中的至少一个将要完全用完并且请求停机，从而检测到停机。

9.如权利要求8的方法，其中所述有限资源包括：电池能量、存储容量和存储器。

10.如前述任一权利要求的方法，进一步包括：在所有被通知的组件已执行其停机任务之后，移除所述计算设备的电源。

11.如前述任一权利要求的方法，其中所述计算设备是移动通信设备。

12.一种包括停机管理器的计算设备，其中多个软件组件正在所述设备上运行，并且所述停机管理器执行下列步骤：

a.如果至少一个组件不能完成其停机任务，则按照所述计算设备受影响的严重性，来向所述组件或每个组件指派停机分类；

b.检测停机请求；以及

c.按照所述停机分类的顺序通知每个组件以执行其停机任务；

其中响应于停机通知，每个被通知的组件执行其停机任务。

13.如权利要求12的设备，其中停机分类被指派给具有要在设备停机时执行的特定任务的每个组件。

14.如权利要求12或13的设备，其中所述顺序开始于通知具有最关键停机分类的组件执行其停机任务，继而按照停机分类关键性降低的次序继续通知其他组件执行其停机任务。

15.如权利要求12或13的设备，其中所述停机管理器按照根据所述停机分类以及与其他组件的依赖关系的顺序，通知每个组件执行其停机任务。

16.如权利要求13的设备，其中所述停机管理器按照根据所述计算设备的操作系统的分层结构的顺序，通知每个组件执行其停机任务。

17.如权利要求12-16中任一的设备，其中定义了两个停机分类。

18.如权利要求12-17中任一的设备，其中由于所述计算设备的用户请求停机，从而检测到停机。

19.如权利要求12-18中任一的设备，其中由于所述计算设备确定可用于所述设备的多个有限资源中的至少一个将要完全用完并且请求停机，从而检测到停机。

20.如权利要求19的设备，其中所述有限资源包括：电池能量、存储容量和存储器。

21.如权利要求12-20中任一的设备，其中在所有被通知的组件已执行其停机任务之后，移除所述计算设备的电源。

22.如权利要求12-21中任一的设备，其中所述计算设备是移动通信设备。

23.一种用于控制计算设备的停机的程序或程序套件，所述程序被安排成在由所述计算设备执行时，控制所述计算设备使得按照权利要求1-11中任一的方法进行停机。

24.一种存储按照权利要求23的程序或至少一个程序套件的存储介质。

25.一种计算设备，基本上如说明书中参考附图所描述的。

26.一种对基本上如说明书中参考附图所描述的计算设备进行停机的方法。

Images