关键信息显示方法及装置、电子设备、存储介质

技术领域

本公开涉及计算机领域，尤其涉及一种关键信息显示方法及装置、电子设备、存储介质。

背景技术

在用户使用电子设备的过程中，经常遇到需要同时运行多个应用程序的情况。然而，对于类似手机等电子设备而言，通常默认以全屏的形式显示应用程序，导致其仅能够同时显示一个应用程序。

为此，在相关技术中，提出了通过非全屏窗口显示应用程度的技术方案，其中最具代表性的为通过悬浮窗显示应用程序，解决了无法同时显示多个应用程序的技术问题。

然而，在通过非全屏窗口显示应用程度时，通常会缩减所要显示的内容，使得与该应用程序相关的关键信息无法显示，或者显示不突出，导致了用户忽略关键信息的问题。

发明内容

本公开提供一种关键信息显示方法及装置、电子设备、存储介质，能够在应用程序通过非全屏窗口进行显示的情况下，将应用程序中包含的关键信息提取出来，并通过信息胶囊的形式进行临时显示，避免了用户忽略关键信息的情况。

根据本公开的第一方面，提供一种关键信息显示方法，包括：

获取应用程序运行中产生的相关数据，并从所述相关数据中确定出预定义的关键信息；

在确定所述应用程序通过非全屏窗口进行显示的情况下，生成与所述非全屏窗口关联展示的信息胶囊，以在所述信息胶囊中显示确定出的关键信息。

根据本公开的第二方面，提供一种关键信息显示方法，包括：

获取应用程序运行中产生的与所负责业务相关的业务数据，并从所述业务数据中确定出预定义的、与所述业务的类型对应的关键信息；

在确定所述应用程序通过迷你窗口进行显示的情况下，生成与所述迷你窗口关联展示的信息胶囊，以在所述信息胶囊中显示确定出的关键信息。

根据本公开的第三方面，提供一种关键信息显示装置，包括：

获取单元，获取应用程序运行中产生的相关数据，并从所述相关数据中确定出预定义的关键信息；

生成单元，在确定所述应用程序通过非全屏窗口进行显示的情况下，生成与所述非全屏窗口关联展示的信息胶囊，以在所述信息胶囊中显示确定出的关键信息。

根据本公开的第四方面，提供一种关键信息显示装置，包括：

获取单元，获取应用程序运行中产生的与所负责业务相关的业务数据，并从所述业务数据中确定出预定义的、与所述业务的类型对应的关键信息；

生成单元，在确定所述应用程序通过迷你窗口进行显示的情况下，生成与所述迷你窗口关联展示的信息胶囊，以在所述信息胶囊中显示确定出的关键信息。

根据本公开的第五方面，提供一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现如第一方面或第二方面所述的方法。

根据本公开的第六方面，提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如第一方面或第二方面所述方法的步骤。

在本公开的技术方案中，可以获取应用程度运行中产生的相关数据，并从中提取预定义的关键信息。在此基础上，本公开还进一步对应用程序的显示方式进行了判断，并在确定应用程序通过非全屏窗口进行显示的情况下，生成与该非全屏窗口关联展示的信息胶囊，并在该信息胶囊中显示确定出的关键信息。

应当理解的是，当应用程序通过非全屏窗口进行显示时，相较于全屏显示，必然对显示的内容进行了删减，或者缩放，会导致用户无法从非全屏窗口中浏览到关键信息，或者难以从众多信息中筛选出关键信息，容易出现由于未注意到关键信息，而影响用户体验的问题。然而，通过本公开的技术方案，在应用程序通过非全屏窗口进行显示时，会将关键信息提取出来，并以信息胶囊的形式进行临时显示，使得用户能够轻易地获取关键信息，避免了用户忽略关键信息的情况。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是本公开一示例性实施例示出的一种关键信息显示方法的流程图；

图2是本公开一示例性实施例示出的另一种关键信息显示方法的流程图；

图3是本公开一示例性实施例示出的一种应用于智能手机的关键信息显示方法的流程图；

图4是本公开一示例性实施例示出的一种信息胶囊与迷你窗口关联展示的界面示意图；

图5是本公开一示例性实施例示出的另一种信息胶囊与迷你窗口关联展示的界面示意图；

图6是本公开一示例性实施例示出的一种关键信息显示装置的框图之一；

图7是本公开一示例性实施例示出的一种关键信息显示装置的框图之二；

图8是本公开一示例性实施例示出的一种关键信息显示装置的框图之三；

图9是本公开一示例性实施例示出的一种关键信息显示装置的框图之四；

图10是本公开一示例性实施例中一种电子设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在用户使用电子设备的过程中，经常遇到需要同时运行多个应用程序的情况。例如，用户可能在看剧的同时，也在跟朋友聊天，因此，同时在电子设备上运行即时通讯应用程序和视频类应用程序。然而，对于类似手机等电子设备而言，通常默认以全屏的形式显示应用程序，导致其仅能够同时显示一个应用程序，例如，在显示视频类应用程序的情况下，即时通讯应用程序只能够在后台运行，这使得用户在上述场景下，必须在即时通讯应用程序和视频类应用程序之间进行频繁的切换。

为此，在相关技术中，提出了通过非全屏窗口显示应用程度的技术方案(又被称为小窗模式)，其中最具代表性的为通过悬浮窗显示应用程序，进而解决了无法同时显示多个应用程序的技术问题。例如，在上述场景下，可以以全屏模式显示视频类应用程序，而以小窗模式显示即时通讯应用程序，这样就避免了两应用程序之间的频繁切换。

然而，在通过非全屏窗口显示应用程度时，通常会缩减所要显示的内容，使得与该应用程序相关的关键信息无法显示，或者显示不突出，进而导致了用户忽略关键信息的问题。例如，在通过悬浮窗显示即时通讯应用程序的情况下，由于悬浮窗较小，使得接收到新消息时，页面的跳变并不是十分明显，导致用户没有注意到悬浮窗中页面的跳变，进而忽略了该新消息；再例如，在同时运行游戏类应用程序和即时通讯应用程序时，若用户在游戏中的角色死亡，很可能将该游戏类应用程序切换至小窗模式，而将即时通讯应用程序切换至全屏模式，以在通过即时通讯应用程序进行聊天的同时，通过小窗观察游戏中的状况，然而，在通过小窗模式显示游戏类应用程序时，其中的某些关键信息，如角色的重生倒计时等，显示范围很小，用户难以在小窗中看清该关键信息，进而导致用户无法及时地将游戏类应用程序切换至全屏模式，影响了游戏进程，降低了用户的游戏体验。

针对上述问题，本公开提出了一种关键信息显示方法，以解决通过非全屏窗口显示应用程序时，关键信息被用户忽略的技术问题。

图1为本公开一示例性实施例示出的一种关键信息显示方法的流程图。如图1所示，该方法可以包括以下步骤：

步骤102，获取应用程序运行中产生的相关数据，并从所述相关数据中确定出预定义的关键信息。

本公开的技术方案可以应用于任一类型的电子设备，例如，该电子设备可以为智能手机、平板电脑等移动终端，也可以为智能电视、PC(个人计算机，Personal Computer)等固定终端。应当理解的是，只需能够通过非全屏窗口显示应用程序的电子设备均可作为本公开中的电子设备，具体将本公开的技术方案应用于哪一种类型的电子设备可以由本领域技术人员根据实际需求确定，本公开对此不作限制。

由上述内容可知，相较于全屏模式，通过非全屏窗口显示应用程序时，会删减或缩小显示的内容，导致用户难以从非全屏窗口中获取关键信息。因此，本公开提出了将应用程序中的关键信息提取出来，并进行临时显示的技术方案，具体的，该关键信息被显示于生成的信息胶囊中。

应当理解的是，本公开生成了信息胶囊，以用于关键信息的展示，相当于对关键信息进行了独立显示，这使得用户无需从非全屏窗口包含的大量信息中人工筛选出关键信息，而是可以从信息胶囊中直接获取，避免了用户忽略关键信息的情况。

需要声明的是，本公开中的信息胶囊指的是：临时生成的用于显示关键信息的窗口。是否生成信息胶囊取决于：应用程序是否处于非全屏窗口模式，以及该应用程序中是否存在关键信息，当且仅当两者均满足时，才生成信息胶囊。之所以被称为信息胶囊，是由于在实际应用中，通常将该用于显示关键信息的窗口设计成类似胶囊的形状，以与上述非全屏窗口进行区别展示。

步骤104，在确定所述应用程序通过非全屏窗口进行显示的情况下，生成与所述非全屏窗口关联展示的信息胶囊，以在所述信息胶囊中显示确定出的关键信息。

在本公开中，关键信息可以由技术人员根据应用程序的相关信息预定义，例如，应用程序的开发商和电子设备的厂商可以预先进行协商，以确定该应用程序中包含的关键信息。在此基础上，电子设备即可根据预定义的内容，从应用程序运行产生的相关数据中确定出关键信息，并在该应用程序通过非全屏窗口进行显示的情况下，生成信息胶囊，对关键信息进行显示。

在本公开中，预定义的关键信息可以包括多种类型。

在一实施例中，预定义的关键信息可以与应用程序所负责的业务的类型相关。在实际操作中，可以优先获取应用程序在运行过程中，产生的与其所负责业务相关的业务数据，并从中确定出预定义的与该业务类型对应的关键信息。

应当理解的是，本实施例确定出的关键信息与应用程序所负责的业务相关，使得用户可以及时获取与该业务相关的关键信息，进而对该业务执行相应的操作。在实际应用中，可以将不同的业务数据预定义为关键信息。

在一种情况下，确定的关键信息可以与应用程序所负责业务所处的执行阶段相关。在实际操作中，可以预先定义若干与业务所处执行阶段对应的关键信息。那么，在应用程序运行的过程中，即可优先确定业务当前所处的执行阶段，并从获取的业务数据中，确定出与该执行阶段相匹配的关键信息，以在应用程序通过非全屏窗口进行显示的情况下，通过生成的信息胶囊进行显示；而当业务进入下一执行阶段时，则可以进一步从获取的业务数据中确定出与下一执行阶段相匹配的关键信息，以对信息胶囊中显示的关键信息进行更新。

举例而言，在上述应用程序为打车类应用程序的情况下，其所负责的业务即为打车业务。那么，可以预先定义打车业务在各个执行阶段所对应的关键信息。例如：

(1)可以将“尚未打到车”这一阶段的关键信息定义为：预计多少时间打到车。

(2)可以将“打到车后，司机正在赶来”这一阶段的关键信息定义为：预计赶来时间，或者，司机距您多少距离。

(3)可以将“司机已到达”这一阶段的关键信息定义为：请在多少时间内上车。

在此基础上，当用户开始打车时，即可显示类似于“预计3分钟后打到车”的关键信息；在用户刚打到车时，显示类似于“司机距您2公里”或者“预计5分钟后司机到达”；而在车到达时，显示类似于“请在3分钟内上车”。可见，在该情况下，用户可以根据显示的关键信息掌握业务的执行情况，以进行相应的安排，提升了用户体验。

再例如，在上述应用程序为游戏类应用程序的情况下，即可根据游戏进度确定关键信息。例如：

(1)可以将游戏处于“正在载入”这一阶段的关键信息定义为：游戏正在载入。

(2)可以“游戏角色处于复活中”这一阶段的关键信息定义为：角色复活倒计时。

在此基础上，当用户通过非全屏窗口显示游戏类应用程序时，即可通过显示的关键信息确定游戏进入到了哪一阶段，以便进行相应的操作，提高了游戏体验。

在另一种情况下，确定的关键信息可以与应用程序所负责业务涉及的对象相关。在实际操作中，可以预先定义若干与业务所涉及对象对应的关键信息。那么，在应用程序运行的过程中，即可优先确定与该业务涉及的对象相关的静态属性信息，以将预定义的静态属性信息确定为关键信息。例如，在上述关于打车类应用程序的举例中，打车业务所涉及的对象包括：司机、用户、车辆。此时，可以将司机的联系方式预定义为司机对应的静态属性信息，将车辆的车牌号预定义为车辆对应的静态属性信息。那么用户在打车过程中，可以显示其中至少一个，以便用户联系司机和/或寻找车辆。

当然，上述举例仅是示意性的，除了根据业务所处执行阶段，或者所涉及对象确定关键信息以外，还可以通过其他方式确定关键信息。例如，在应用程序为即时通讯应用程序时，可以将接收到的新消息或者针对该新消息产生的提醒信息作为关键信息，一旦接收到新消息，便将该新消息，或者针对该新消息的提醒信息作为关键信息进行展示。具体的，如何根据不同的应用程序设置关键信息可以由本领域技术人员根据实际情况确定，本公开对此不作限制。

在另一实施例中，确定的关键信息也可以与应用程序所负责的业务无关。具体的，确定的关键信息可以为：用于表征应用程序当前运行状况的运行数据。那么，在应用程序运行的过程中，即可获取应用程序的运行数据(即获取的应用程序的相关数据为：用于表征所述应用程序运行状况的运行数据)，并从中确定出用于表征当前运行状况的运行数据，以作为关键信息。

需要声明的是，尽管在上述表述中，“获取运行数据”以及“确定用于表征当前运行状况的运行数据”存在顺序上的先后关系。但在实际应用中，可以将某一类型的运行数据确定为关键信息后，实时获取该类型运行数据，并进行动态显示，而不是在每次显示时，均进行一次全部运行数据的获取。

当然，在本实施例中，具体将哪一类型的运行数据作为关键信息进行显示也可以通过预定义确定。例如，可以将CPU占用率、内存占用率、电量损耗值、流量损耗值、网络传输速度中的至少一个作为关键信息。

应当理解的是，将运行数据作为关键信息进行显示，能够使用户实时了解应用程序的运行状况，进而根据其运行状况进行相应的调整。例如，在将电量耗损值作为关键信息时，用户即可清晰地知晓该应用程序的运行对电量的影响，进而在发现某一应用程序消耗电量较多时，及时关闭该应用程序，以避免耗电过多而影响电子设备的正常使用；在将流量损耗值作为关键信息时也是类似；再例如，在实际使用电子设备的过程中，经常发现设备的CPU总占用率较高，而无法知晓具体被哪一应用程序所占用，若要知晓必须打开设置界面或者专业的监控软件进行查看，而本公开可以将其作为关键信息进行显示，使得用户在使用过程中即可直观地看到某一应用程序对CPU的占用情况，大幅简化了用户的操作。

在本公开中，在确定应用程序通过非全屏窗口进行显示时，可以调用预置的StartService接口，以通过Service服务程序生成与应用程序对应的信息胶囊，并将信息胶囊与用于显示该应用程序的非全屏窗口进行关联展示。在软件层面上，通常由应用程序调用上述StartService接口，以启用相应的Service服务程序；并且由应用程序确定出预定义的关键信息后，通过Intent将关键信息传输至Service服务程序，以由Service服务程序与操作系统配合生成信息胶囊，并在其中显示关键信息。

上述Intent负责应用的各个组件之间的通讯，是Android系统中用于传递信息的媒介。

应当理解的是，当应用程序由“通过非全屏窗口显示”切换至全屏显示模式时，即可将生成的信息胶囊关闭，以避免影响全屏显示的效果。在软件层面上，即可调用预置的StopService接口，以关闭上述Service服务程序，其中，当Service服务程序被关闭时，信息胶囊也被关闭。

本公开中的非全屏窗口可以包括多种类型的窗口。例如，该非全屏窗口可以为类似于上述悬浮窗的小窗口，也可以为占用屏幕面积更小的迷你窗口。在实际应用中，小窗口的面积大小通常维持在用户能够对应用程序进行操作大小；而迷你窗口则是在小窗口的基础上，进一步进行了缩小，使得用户可以更方便地对应迷你窗口以外的区域进行操作。

在大多数应用程序中，无论是在小窗口中还是在迷你窗口中，通常都是将全屏显示的内容进行等比例的缩小。换言之，应用程序在小窗口中显示内容时或在所述迷你窗口中显示内容时，显示的内容均与全屏显示时的内容一致。当然，除了等比缩小进行显示以外，也可以对全屏显示的内容进行删减后，再通过小窗口和/或迷你窗口进行显示，例如，在应用程序为视频类应用程序时，通过小窗口和/或迷你窗口进行显示时，可能不会显示播放区域下方的评论区和选集区。

应当理解的是，小窗口的面积大小通常维持在用户能够进行操作的大小，尽管相较于全屏显示，筛选出关键信息可能较为吃力，但用户尚且可以通过人工查找的方式获取关键信息。可见，在通过小窗口显示应用程序的情况下采用本方案，能够帮助用户从显示的信息中筛选出关键信息。

然而，迷你窗口在小窗口的基础上，进行了进一步的缩小，这使得用户难以看清应用程序显示的内容，即难以通过人工查找的方式从中获取关键信息。可见，在通过迷你窗口显示应用程序的情况下采用本方案，能够解决用户无法看清迷你窗口中的显示内容，而导致无法获取与应用程序相关的关键信息的问题。

需要声明的是，由于用户通常难以看清迷你窗口中显示的内容，若关键信息在信息胶囊中显示时占用的屏幕面积与在迷你窗口中显示时占用的面积一致，用户仍难以看清关键信息。因此，通常情况下，关键信息在信息胶囊中显示时占用的屏幕面积，大于在迷你窗口中显示时占用的屏幕面积，以使用户能够清楚地知晓关键信息的内容。

在本公开中，为了使用户能够清楚地知晓显示的信息胶囊与非全屏窗口之间的对应关系，通常将信息胶囊和非全屏窗口进行关联展示。

在一种情况下，可以通过保持信息胶囊与非全屏窗口之间的相对位置关系的方式，以使用户知晓信息胶囊中显示的关键信息对应于哪一非全屏窗口，具体的，在用户对任一应用程序对应的非全屏窗口和信息胶囊中的一方进行移动时，电子设备可以调整另一方的位置，以使非全屏窗口与信息胶囊之间的相对位置关系保持不变。

在另一种情况下，可以通过给同一应用程序对应的非全屏窗口和信息胶囊添加统一的信息标识的方式，使得用户知晓信息胶囊中显示的关键信息对应于哪一非全屏窗口，具体的，在用户对任一应用程序对应的非全屏窗口和信息胶囊中的一方进行移动时，可以保持另一方的位置不变，但在该任一应用程序对应的非全屏窗口与信息胶囊中显示统一的标识信息。例如，对于任一应用程序A而言，可以在其对应的非全屏窗口和信息胶囊中均显示标识“A”。

本公开中的信息胶囊可以包括多种类型，例如，可以包括信息展示类和应用控制类。其中，信息展示类，用于展示与应用程序相关的静态信息，如上文所介绍的多个举例中的关键信息均为静态信息，其所对应的信息胶囊即为信息展示类。而应用控制类的信息胶囊，则可以用于对应用程序的运行进行一定的控制，在实际操作中，可以针对信息胶囊预定义一控制操作，以在用户触发该信息胶囊的情况下，对相应的应用程序执行预定义的控制操作。

举例而言，在上述应用程序为单机类游戏应用程序时，可以将其信息胶囊的预定义操作设置为暂停和取消暂停，这样用户在该单机类游戏应用程序通过非全屏窗口显示时，也可以进行简单的控制，例如，在游戏播放剧情时，若用户想看游戏剧情，可以触发信息胶囊使其暂停，等到有时间时再切换至全屏模式进行观看，若不想看游戏剧情，也可以通过触发信息胶囊，以在对其他应用程序进行操作的过程中，使剧情在非全屏窗口中播放完毕。

当然，上述举例仅是示意性的，具体如何设置应用控制类信息胶囊的预定义操作，可由本领域技术人员根据实际情况设定，本公开对此不作限制。

在本公开中，需要强调的是，尽管在上述介绍中优先描述了“如何获取关键信息”，再描述了“在确定应用程序通过非全屏窗口显示的情况下，生成信息胶囊以对关键信息进行显示”。然而，在实际操作中，也可以优先判断应用程序是否通过非全屏窗口进行显示，再在已经确定通过非全屏窗口显示的情况下，获取关键信息，并将其显示于信息胶囊中。具体如何操作，可以由本领域技术人员根据实际情况确定，本公开对此不作限制。

由上述技术方案可知，本公开可以获取应用程度运行过程中产生的相关数据，并从中提取预定义的关键信息。在此基础上，本公开还进一步对应用程序的显示方式进行了判断，并在确定应用程序通过非全屏窗口进行显示的情况下，生成与该非全屏窗口关联展示的信息胶囊，以在该信息胶囊中显示确定出的关键信息。

应当理解的是，当应用程序通过非全屏窗口进行显示时，相较于全屏模式，必然对显示的内容进行了删减，或者缩放，会导致用户无法从非全屏窗口中浏览到关键信息，或者难以从众多信息中注意到关键信息，容易出现由于未注意到关键信息，而影响用户使用体验的问题。然而，通过本公开的技术方案，在应用程序通过非全屏窗口进行显示时，会将关键信息提取出来，并以信息胶囊的形式进行临时显示，使得用户能够轻易地获取关键信息，避免了用户忽略关键信息的情况。

进一步的，本公开中确定的关键信息可以与应用程序所负责的业务相关。其中，在一种情况下，确定的关键信息用于表征业务当前所处的执行阶段，使得用户可以根据显示的关键信息知晓业务的执行状况，进而做出相应的反应。在另一种情况下，关键信息可以与业务所涉及的对象相关，使得用户可以直接获取到与业务相关的对象的描述信息。

再进一步的，本公开中确定的关键信息也可以与应用程序所负责的业务无关，而仅仅用于表征应用程序的运行状况，即将应用程序的某一运行数据作为关键信息进行显示。可见，通过本公开的技术方案，使得用户可以在对应用程序的使用过程中，知晓该应用程序的运行状况，而无需如相关技术中需要打开设置页面或者专业的监控软件进行查看，大幅简化了用户操作。

在实际应用中，本公开的技术方案多用于对与应用程序所负责业务相关的关键信息进行提醒；且考虑到生成信息胶囊所损耗的资源和显示关键信息的能达到的效果，通常仅在应用程序通过迷你窗口进行显示的情况下，生成信息胶囊以对关键信息进行显示。下面，对该场景下的关键信息显示方法进行介绍。在介绍之前需要强调的是，在下一实施例中，仅仅将上一实施例中的关键信息进行了进一步的限定，以及将生成信息胶囊的条件进一步限定为：在通过迷你窗口显示应用程序的情况下而已，大多操作方式，例如获取关键信息、如何对信息胶囊进行关联展示等操作均可参照上一实施例的介绍，在下一实施例中不再赘述。

图2为本公开一示例性实施例示出的另一种关键信息显示方法的流程图。如图2所示，该方法可以包括以下步骤：

步骤202，获取应用程序运行中产生的与所负责业务相关的业务数据，并从所述业务数据中确定出预定义的、与所述业务的类型对应的关键信息。

应当理解的是，相较于全屏模式，通过迷你窗口显示应用程序时，会删减或缩小显示的内容，导致用户难以从迷你窗口中获取关键信息。因此，本公开提出了将应用程序中的关键信息提取出来，并进行临时显示的技术方案，具体的，该关键信息被显示于生成的信息胶囊中。

如上所述，本公开中的信息胶囊指的是：临时生成的用于显示关键信息的窗口。是否生成信息胶囊取决于：应用程序是否通过迷你窗口显示，以及该应用程序中是否存在关键信息，当且仅当两者均满足时，才生成信息胶囊。之所以被称为信息胶囊，是由于在实际应用中，通常将该用于显示关键信息的窗口设计成类似胶囊的形状，以与迷你窗口进行区别展示。

步骤204，在确定所述应用程序通过迷你窗口进行显示的情况下，生成与所述迷你窗口关联展示的信息胶囊，以在所述信息胶囊中显示确定出的关键信息。

在本实施例中，关键信息可以由技术人员根据应用程序所负责的业务预定义，例如，应用程序的开发商和电子设备的厂商可以预先进行协商，以确定将与该应用程序所负责业务相关的哪一业务数据确定为关键信息。具体将哪一业务数据确定为关键信息，通常与该业务的类型相关，例如，若应用程序负责的业务属于打车类业务，那么预定义的关键信息应当与打车类业务相关；再例如，若应用程序负责的业务属于视频播放类业务，那么预定义的关键信息应当与视频播放类业务相关。

在此基础上，电子设备即可根据预定义的内容，从应用程序运行产生的业务数据中确定出预定义的、与业务的类型对应的关键信息，并在该应用程序通过迷你窗口进行显示的情况下，生成信息胶囊，对确定的关键信息进行显示。

在一种情况下，确定的关键信息可以与应用程序所负责业务所处的执行阶段相关。在实际操作中，可以预先定义若干与业务所处执行阶段对应的关键信息。那么，在应用程序运行的过程中，即可优先确定业务当前所处的执行阶段，并从获取的业务数据中，确定出与该执行阶段相匹配的关键信息，以在应用程序通过迷你窗口进行显示的情况下，通过生成的信息胶囊进行显示；而当业务进入下一执行阶段时，则可以进一步从获取的业务数据中确定出与下一执行阶段相匹配的关键信息，以对信息胶囊中显示的关键信息进行更新。

在另一种情况下，确定的关键信息可以与应用程序所负责业务涉及的对象相关。在实际操作中，可以预先定义若干与业务所涉及对象对应的关键信息。那么，在应用程序运行的过程中，即可优先确定与该业务涉及的对象相关的静态属性信息，以将预定义的静态属性信息确定为关键信息。例如，在上述关于打车类应用程序的举例中，打车业务所涉及的对象包括：司机、用户、车辆。此时，可以将司机的联系方式预定义为司机对应的静态属性信息，将车辆的车牌号预定义为车辆对应的静态属性信息。那么用户在打车过程中，可以显示其中至少一个，以便用户联系司机和/或寻找车辆。

当然，上述举例仅是示意性的，除了根据业务所处执行阶段，或者所涉及对象确定关键信息以外，还可以通过其他方式确定与所负责业务的类型对应的关键信息。例如，在应用程序为即时通讯应用程序时，可以将接收到的新消息或者针对该新消息产生的提醒信息作为关键信息，一旦接收到新消息，便将该新消息，或者针对该新消息的提醒信息作为关键信息进行展示。具体的，如何根据不同的应用程序设置关键信息可以由本领域技术人员根据实际情况确定，本公开对此不作限制。

在本实施例中，在确定应用程序通过迷你窗口进行显示时，可以调用预置的StartService接口，以通过Service服务程序生成与应用程序对应的信息胶囊，并将信息胶囊与用于显示该应用程序的迷你窗口进行关联展示。在软件层面上，通常由应用程序调用上述StartService接口，以启用相应的Service服务程序；并且由应用程序确定出预定义的关键信息后，通过Intent将关键信息传输至Service服务程序，以由Service服务程序与操作系统配合生成信息胶囊，并在其中显示关键信息。

上述Intent负责应用的各个组件之间的通讯，是Android系统中用于传递信息的媒介。

应当理解的是，当应用程序由“通过迷你窗口显示”切换至全屏显示模式时，即可将生成的信息胶囊关闭，以避免影响全屏显示的效果。在软件层面上，即可调用预置的StopService接口，以关闭上述Service服务程序，其中，当Service服务程序被关闭时，信息胶囊也被关闭。

在本实施例中，也可以通过多种方式实现信息胶囊与迷你窗口之间的关联展示。

在一实施例中，在生成对应于迷你窗口对应的信息胶囊后，可以在同一应用程序对应的信息胶囊和迷你窗口中添加统一的信息标识。例如，对于任一应用程序A而言，可以在其对应的迷你窗口和信息胶囊中均显示标识“A”。

在另一实施例中，可以通过保持信息胶囊与迷你窗口之间的相对位置关系的方式，以使用户知晓信息胶囊中显示的关键信息对应于哪一迷你窗口，具体的，在用户对任一应用程序对应的迷你窗口和信息胶囊中的一方进行移动时，可以调整另一方的位置，以使迷你窗口与信息胶囊之间的相对位置关系保持不变。

需要声明的是，在本实施例中，信息胶囊既可以在迷你窗口内进行展示，也可以在区别于迷你窗口以外的其他区域中独立展示，具体如何进行展示可以由本领域技术人员根据实际情况确定，本公开对此不作限制。

应当理解的是，在通过迷你窗口对应用程序进行显示时，迷你窗口中显示的内容所占用的屏幕面积较小，用户通常难以看清。若关键信息在信息胶囊中显示时占用的屏幕面积与在迷你窗口中显示时占用的面积一致，用户将仍难以看清关键信息。因此，通常情况下，关键信息在信息胶囊中显示时占用的屏幕面积，大于在迷你窗口中显示时占用的屏幕面积，以使用户能够清楚地知晓关键信息的内容。

如上所述，本实施例中的信息胶囊可以包括多种类型，例如，可以包括信息展示类和应用控制类。其中，信息展示类，用于展示与应用程序相关的静态信息，所对应的信息胶囊即为信息展示类。而应用控制类的信息胶囊，则可以用于对应用程序的运行进行一定的控制，在实际操作中，可以针对信息胶囊预定义一控制操作，以在用户触发该信息胶囊的情况下，对相应的应用程序执行预定义的控制操作。

需要强调的是，尽管在上述介绍中优先描述了“如何获取关键信息”，再描述了“在确定应用程序通过迷你窗口显示的情况下，生成信息胶囊以对关键信息进行显示”。然而，在实际操作中，也可以优先判断应用程序是否通过迷你窗口进行显示，再在已经确定通过迷你窗口显示的情况下，获取关键信息，并将其显示于信息胶囊中。具体如何操作，可以由本领域技术人员根据实际情况确定，本公开对此不作限制。

由上述技术方案可知，本公开可以根据应用程序所负责业务的类型，为该应用程序预定义与该业务的类型对应的关键信息，以在应用程序运行的过程中，从产生的业务数据中确定出上述预定义的、与其业务的类型对应的关键信息，并在确定应用程序通过迷你窗口进行显示的情况下，生成信息胶囊，以对确定的关键信息进行显示。

应当理解的是，迷你窗口本身所占用的屏幕面积较小，但其仍需要显示大量与应用程序相关的信息，使得显示的内容占用的屏幕面积也很小，例如，字体相较于全屏模式大幅缩小，这使得用户难以看清迷你窗口中显示的内容，更难以从中获取关键信息。可见，通过本公开的技术方案，可以由设备自动获取其中包含的关键信息，并通过生成信息胶囊的方式对其进行显示，避免了用户难以看清迷你窗口中的内容，而导致的无法获取关键信息的问题。

接下来，以智能手机上安装的打车软件为例，对本公开的技术方案进行介绍。

图3为本公开一示例性实施例示出的一种应用于智能手机的关键信息显示方法的流程图。如图3所示，该方法可以包括以下步骤：

步骤301，在用户触发打车APP图标时，启动打车APP。

在本实施例中，打车APP的开发商与智能手机的厂商可以预先协商，以定义打车APP在打车业务的各个执行阶段所对应的关键信息。

举例而言，协商的各个执行阶段与关键信息的对应关系可以如下表1所示：

表1

在实际操作中，可以将上表1所示的预定义内容预置于打车APP中，以使打车APP能够根据打车业务所处阶段，确定出相应的关键信息。

步骤302，确定打车业务当前所处阶段。

步骤303，确定当前所处阶段对应的关键信息。

在本实施例中，在打车APP被启动后，打车APP即可监控打车业务所处的执行阶段，以确定出相应的关键信息。

承接上述举例，在确定当前所处阶段为未打到车时，即可基于搜集相关信息，如附近车辆数量、正在打车用户数量等数据，计算一预计响应时间。假设计算得到的预计响应时间为“3分钟”，则可将“预计3分钟内打到车”这一信息作为关键信息。

需要声明的是，在软件层面上，上述确定所处阶段、确定关键信息的步骤通常由打车APP执行。打车APP在确定关键信息后，即可调用StartService这一接口，以启用Service服务程序，并将关键信息交由Intent，使其将关键信息传输至Service服务程序，其中，该Intent还携带有打车APP的标识信息，以指示该关键信息对应的APP。服务程序则可以进一步将关键信息以及打车APP的信息传输至操作系统，以由操作系统确定打车APP当前所处的显示状态。

上述Intent负责应用的各个组件之间的通讯，是Android系统中用于传递信息的媒介。在打车APP通过Intent传递关键信息时，可以将关键信息封装成一数据包，并在以打车APP的标识对数据包进行命名的同时，通过预定义的秘钥key进行加密；在此基础上，操作系统在接收到的该数据包后，即可根据数据包的名称确定所对应的应用程序为上述打车APP，并通过预定义的秘钥key对数据包进行解析，以得到对应于该打车APP的关键信息。

步骤304，判断打车APP是否通过迷你窗口显示；若是，则跳转至步骤305，否则，跳转至步骤308。

在本实施例中，若操作系统确定打车APP通过迷你窗口显示，那么，即可生成相应的信息胶囊，以对得到的关键信息进行显示；若确定打车APP处于全屏窗口进行显示，则可以直接丢弃该关键信息，甚至可以进一步调用StopService接口，以关闭服务程序。

承接上述举例，假设打车APP通过迷你窗口进行显示，那么，即可生成对应于该迷你窗口的信息胶囊，进而将上述“预计3分钟内打到车”的关键信息显示于信息胶囊中。

在实际操作中，信息胶囊可以如图4所示：显示于迷你窗口内，也可以如图5所示：显示于迷你窗口外。两图中的迷你窗口的空白区域代表：用于显示打车APP相关信息的区域，例如，可以显示一地图，该地图上显示有用户的位置和司机的位置(图中未示出)。

其中，在图5所示的情况下，可以通过使迷你窗口与信息胶囊的相对位置关系保持一致的方式，或者为两者添加上述打车APP的标识的方式进行关联展示。

步骤305，生成信息胶囊，并在其中显示关键信息。

步骤306，判断打车业务所处阶段是否发生改变；若是，则跳转至步骤302，若否，则跳转至步骤307。

在本实施例中，还包括判断打车业务所处阶段是否发生变化的过程，以在确定发生了变化的情况下，重新确定关键信息。

需要声明的是，在软件层面上，操作系统通常不执行判断业务所处执行状态是否发生变化的步骤，而是由打车APP不断根据打车业务所处状态确定关键信息，并将关键信息经由服务程序传递至操作系统，而操作系统则是在接收到新的关键信息时，更新信息胶囊中显示的内容而已。

承接上述举例，当打车APP确定打车业务所处阶段变更为已打到车，但司机尚未到达的阶段，那么打车APP可以根据用户位置和司机位置，以及路况确定预计到达时间，进而将该预计到达时间发送至操作系统，操作系统则只需将信息胶囊中显示的原先的关键信息，替换为接收到的关键信息即可。假设当前确定的预计到达时间为“司机预计在5分钟后到达”，即可将信息胶囊原先显示的“预计3分钟内打到车”替换为“司机预计在5分钟后到达”。

当然，上述操作方式仅是示意性的，在实际应用中可能由于操作系统的不同，以及APP设计原理不同，导致实际操作方式也与上述操作方式存在差别，具体如何确定业务所处阶段，如何确定关键信息，以及如何确定应用程序的显示方式可由本领域技术人员根据实际情况确定，本实施例对此不作限制。

步骤307，保持信息胶囊中显示的关键信息。

步骤308，不显示关键信息。

需要强调的是，本实施例仅仅是以打车APP为例进行介绍，其他APP的操作方式也是类似，均可参照本实施例的操作方式。

由上述技术方案，本公开可以在应用程序通过迷你窗口进行显示的情况下，临时生成对应于该应用程序的信息胶囊，以对应用程序中包含的关键信息进行显示。

其中，在上述实施例中，确定的关键信息与应用程序负责的业务的执行阶段相关，使得用户可以通过显示的关键信息，确定业务的执行状况，进而做出相应的反应。例如，在上述实施例中，用户可以通过信息胶囊知晓是否已经打到车、打到车后司机多久后到达等信息，进而使用户可以合理地安排：何时出发前往上车地点。

图6是本公开一示例性实施例示出的一种关键信息显示装置的框图之一。参照图6，该装置包括获取单元601和生成单元602。

获取单元601，被装配为获取应用程序运行中产生的相关数据，并从所述相关数据中确定出预定义的关键信息；

生成单元602，被装配为在确定所述应用程序通过非全屏窗口进行显示的情况下，生成与所述非全屏窗口关联展示的信息胶囊，以在所述信息胶囊中显示确定出的关键信息。

可选的，

所述相关数据包括：与所述应用程序负责的业务相关的业务数据；

获取单元601进一步被装配为：

从所述业务数据中确定出预定义的与所述业务的类型对应的关键信息，以作为确定出的关键信息。

可选的，获取单元601进一步被装配为：

确定所述业务当前所处的执行阶段；

从所述业务的类型对应的关键信息中，确定出与所述执行阶段相匹配的关键信息，以作为确定出的关键信息。

可选的，获取单元601进一步被装配为：

确定与所述业务涉及的对象相关的静态属性信息；

将预定义类型的静态属性信息确定为所述关键信息。

可选的，

所述相关数据包括：用于表征所述应用程序运行状况的运行数据；

获取单元601进一步被装配为：

从所述运行数据中，确定出用于表征所述应用程度当前运行状况的运行数据，以作为所述关键信息。

可选的，所述运行数据包括下述至少之一：

CPU占用率、内存占用率、电量损耗值、流量损耗值、网络传输速度。

可选的，所述非全屏窗口包括：小窗口和/或迷你窗口；

所述小窗口在屏幕中占用的面积大于所述迷你窗口在屏幕中占用的面积；所述应用程序在小窗口中显示内容时或在所述迷你窗口中显示内容时，显示的内容均与全屏显示时的内容一致。

可选的，所述关键信息在所述信息胶囊中显示时所占用的屏幕面积，大于在所述迷你窗口中显示时占用的屏幕面积。

如图7所示，图7是本公开一示例性实施例示出的一种关键信息显示装置的框图之二，该实施例在前述图6所示实施例的基础上，还包括：调整单元603和控制单元604。

可选的，还包括：

调整单元603，被装配为当所述非全屏窗口与所述信息胶囊中的一方基于用户的操作进行移动时，调整另一方的位置，以使两者的相对位置关系保持不变；或者，保持另一方的位置不变，并在所述非全屏窗口与所述信息胶囊中显示统一的标识信息。

可选的，所述信息胶囊的类型为应用控制类；

控制单元604，被装配为在检测到所述信息胶囊被触发的情况下，对所述应用程序执行预定义的控制操作。

图8是本公开一示例性实施例示出的一种关键信息显示装置的框图之三。参照图8，该装置包括获取单元801和生成单元802。

获取单元801，被装配为获取应用程序运行中产生的与所负责业务相关的业务数据，并从所述业务数据中确定出预定义的、与所述业务的类型对应的关键信息；

生成单元802，在确定所述应用程序通过迷你窗口进行显示的情况下，生成与所述迷你窗口关联展示的信息胶囊，以在所述信息胶囊中显示确定出的关键信息。

可选的，获取单元801进一步被装配为：

确定与所述业务涉及的对象相关的静态属性信息；

将预定义类型的静态属性信息确定为所述关键信息。

可选的，生成单元802进一步被装配为：

调用StartService接口，以通过Service服务程序生成与所述应用程序对应的信息胶囊；

将所述信息胶囊与所述迷你窗口进行关联展示。

可选的，生成单元802进一步被装配为：

生成与所述迷你窗口对应的信息胶囊，并在所述迷你窗口和所述信息胶囊中添加统一的信息标识。

可选的，

所述信息胶囊在所述迷你窗口内进行展示；或者，

所述信息胶囊在区别于所述迷你窗口以外的其他区域中独立展示。

可选的，

所述关键信息在所述信息胶囊中显示时占用的屏幕面积，大于在所述迷你窗口中显示时占用的屏幕面积。

如图9所示，图9是本公开一示例性实施例示出的一种关键信息显示装置的框图之四，该实施例在前述图8所示实施例的基础上，还包括：确定单元803、调用单元804、调整单元805和控制单元806。

可选的，还包括：

确定单元803，被装配为确定所述业务当前所处的执行阶段；从所述业务的类型对应的关键信息中，确定出与所述执行阶段相匹配的关键信息，以作为确定出的关键信息

可选的，还包括：

调用单元804，被装配为在确定所述应用程序处于全屏显示模式的情况下，调用StopService接口，以关闭所述Service服务程序；所述信息胶囊在所述Service被关闭的情况下，被关闭。

可选的，还包括：

调整单元805，被装配为当检测到所述迷你窗口与所述信息胶囊中的一方基于用户的操作进行移动时，调整另一方的位置，以使所述迷你窗口与所述信息胶囊的相对位置关系保持不变。

可选的，所述信息胶囊的类型为应用控制类；所述装置还包括：

控制单元806，被装配为在检测到所述信息胶囊被触发的情况下，对所述应用程序执行预定义的控制操作。对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

相应的，本公开还提供一种关键信息显示装置，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为实现如上述实施例中任一所述的关键信息显示方法，比如该方法可以包括：获取应用程序运行中产生的相关数据，并从所述相关数据中确定出预定义的关键信息；在确定所述应用程序通过非全屏窗口进行显示的情况下，生成与所述非全屏窗口关联展示的信息胶囊，以在所述信息胶囊中显示确定出的关键信息。

相应的，本公开还提供一种电子设备，所述电子设备包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于实现如上述实施例中任一所述的关键信息显示方法的指令，比如该方法可以包括：获取应用程序运行中产生的相关数据，并从所述相关数据中确定出预定义的关键信息；在确定所述应用程序通过非全屏窗口进行显示的情况下，生成与所述非全屏窗口关联展示的信息胶囊，以在所述信息胶囊中显示确定出的关键信息。

图10是根据一示例性实施例示出的一种用于实现进程调度方法的装置1000的框图。例如，装置1000可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图10，装置1000可以包括以下一个或多个组件：处理组件1002，存储器1004，电源组件1006，多媒体组件1008，音频组件1010，输入/输出(I/O)的接口1012，传感器组件1014，以及通信组件1016。

处理组件1002通常控制装置1000的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件1002可以包括一个或多个处理器1020来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件1002可以包括一个或多个模块，便于处理组件1002和其他组件之间的交互。例如，处理组件1002可以包括多媒体模块，以方便多媒体组件1008和处理组件1002之间的交互。

存储器1004被配置为存储各种类型的数据以支持在装置1000的操作。这些数据的示例包括用于在装置1000上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器1004可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件1006为装置1000的各种组件提供电力。电源组件1006可以包括电源管理系统，一个或多个电源，及其他与为装置1000生成、管理和分配电力相关联的组件。

多媒体组件1008包括在所述装置1000和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件1008包括一个前置摄像头和/或后置摄像头。当装置1000处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件1010被配置为输出和/或输入音频信号。例如，音频组件1010包括一个麦克风(MIC)，当装置1000处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器1004或经由通信组件1016发送。在一些实施例中，音频组件1010还包括一个扬声器，用于输出音频信号。

I/O接口1012为处理组件1002和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件1014包括一个或多个传感器，用于为装置1000提供各个方面的状态评估。例如，传感器组件1014可以检测到装置1000的打开/关闭状态，组件的相对定位，例如所述组件为装置1000的显示器和小键盘，传感器组件1014还可以检测装置1000或装置1000一个组件的位置改变，用户与装置1000接触的存在或不存在，装置1000方位或加速/减速和装置1000的温度变化。传感器组件1014可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件1014还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件1014还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件1016被配置为便于装置1000和其他设备之间有线或无线方式的通信。装置1000可以接入基于通信标准的无线网络，如WiFi，2G或3G，4G LTE、5G NR(New Radio)或它们的组合。在一个示例性实施例中，通信组件1016经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件1016还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，装置1000可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器1004，上述指令可由装置1000的处理器1020执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

以上所述仅为本公开的较佳实施例而已，并不用以限制本公开，凡在本公开的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本公开保护的范围之内。