CN117130697B - 在任务栏固定应用的方法和装置 - Google Patents

Abstract

本申请提供一种在任务栏固定应用的方法和装置，该方法包括：从第一数据库中获取推荐应用列表中每个应用的全路径信息；第一数据库中存储有多个应用的全路径信息，多个应用包括推荐应用列表中的所有应用；推荐应用列表是根据用户使用应用的习惯生成的，推荐应用列表中包括至少一个应用；根据推荐应用列表中每个应用的全路径信息，将推荐应用列表中的应用固定到任务栏。该方案主要通过从预存储了推荐应用列表中每个应用的全路径信息的数据库中获取全路径信息和固定应用，使得任意被推荐的应用都能够固定到任务栏中，提升用户使用体验。

Description

在任务栏固定应用的方法和装置

技术领域

本申请涉及电子设备技术领域，尤其涉及一种在任务栏固定应用的方法和装置。

背景技术

用户在使用笔记本电脑、电脑等电子设备时，对于常用的应用会固定在任务栏中，方便每次打开。但由于任务栏能够容纳的应用数量有限，所以任务栏尽可能将用户最期望使用的应用优先展示在任务栏中，才会最大程度给用户带来好的使用体验。

为了解决这一问题，出现了推荐待固定应用的方法，就是通过学习用户使用应用的习惯，来为用户推送最期望使用的应用，这样就可以让用户知道自己的习惯，并从这些推荐的应用中选取一些固定到任务栏中了。或者还可以直接现将所有推荐的应用都固定到任务栏，然后由用户从中按需删减。但是，在实际使用时发现，虽然多数应用是可以固定到任务栏中的，但有些应用是无法固定的。所以就导致推荐的应用虽然满足了用户的期望，却由于存在无法固定的应用，导致这些应用不能真正按照用户期望展示在任务栏中，无法达到推荐待固定应用这一方案的理想效果，影响用户使用体验。

因此，如何使得任意被推荐的应用都能固定到任务栏中是亟待解决的技术问题。

发明内容

本申请提供一种在任务栏固定应用的方法和装置，能够使得任意被推荐的应用都能固定到任务栏中。

第一方面，提供了一种在任务栏固定应用的方法，该方法包括：从第一数据库中获取推荐应用列表中每个应用的全路径信息；第一数据库中存储有多个应用的全路径信息，多个应用包括推荐应用列表中的所有应用；推荐应用列表是根据用户使用应用的习惯生成的，推荐应用列表中包括至少一个应用；根据推荐应用列表中每个应用的全路径信息，将推荐应用列表中的应用固定到任务栏。

在本申请技术方案中，主要通过从预存储了推荐应用列表中每个应用的全路径信息的数据库中获取全路径信息和固定应用，使得任意被推荐的应用都能够固定到任务栏中，提升用户使用体验。

推荐应用列表是根据用户使用应用的习惯生成的，推荐应用列表中包括至少一个应用。该推荐应用列表可以理解为是通过学习用户对应用的使用习惯，所生成的用户最期望使用的应用的一个列表，这个列表中的应用是用户最希望展示在任务栏中的。也可以认为该推荐应用列表中的应用是为用户推荐的待固定到任务栏的应用，或者说为用户推荐的最符合用户固定期望的应用。

第一数据库中存储有多个应用的全路径信息，这多个应用包括推荐应用列表中的所有应用。可以认为第一数据库是用来集中存储电子设备中各个应用的全路径等这类应用信息的数据库。应理解，对于第一数据库具体采用电子设备中的哪个或哪些存储模块不存在限定，只要能够满足存储需求即可，也就是至少能够存储下推荐应用列表中所有应用的应用信息的容量，以及至少能够在需要固定应用的时候，存储的应用信息都不会被删除或篡改或覆盖，保证满足固定应用时的读取应用信息的需求。

应用信息除了包括上述全路径信息，还可以包括应用的启动进程名称和/或应用的启动进程标识。

结合第一方面，在第一方面的某些实现方式中，应用信息还包括应用的启动进程名称和/或应用的启动进程标识。

上述全路径信息也可以理解为是应用的启动进程的全路径的信息。全路径是指位于电脑的存储硬盘的哪个分区下的哪个文件夹下，一直到目标文件的路径。全路径也可以称之为绝对路径。对于任意一个存储在电子设备中的文件都有其唯一的全路径。

需要说明的是，对于一个应用，虽然可能会包括一个或多个进程，但必然都会包括一个用于启动该应用的启动进程，本申请主要以启动进程为例。当还包括其他进程时，应用信息还可以包括其它进程的进程名称、进程标识和进程的全路径。

在一种实现方式中，为了减少存储压力，可以只存储推荐应用列表中的所有应用的应用信息。也就是，在推荐应用列表生成之后，才进行存储，并且在存储的时候只存储推荐应用列表中的应用的应用信息。

在另一种实现方式中，可以存储所有应用的应用信息，不受推荐应用列表的局限。这样的好处是，无论后续哪个应用被推荐了，都不需要再更新数据库，但相对的也增大了存储数据量。

对于上述两种实现方式，可以按照实际需求采用。对于只存储推荐应用列表中应用的方式，可能会遗漏其他应用的应用信息，但由于推荐应用列表中都是最满足用户期望的应用，所以说明用户最可能固定到任务栏的应用已经都包含在内了，或者说已经基本满足用户固定应用的需求了，所以这种遗漏在这种特定应用场景下，不会带来过多不好的影响。对于全都存储的方式，是最全面的存储，对于多个用户使用同一个电子设备的场景可能会更加适用。因为，这种场景下，推荐应用列表中应用的变动较大，所以如果采用第一种方式，就需要重新获取变动了的应用的应用信息，而如果采用第二种方式，无论怎样变化，都不需要再重新获取。

在一个例子中，当只有一个用户使用电子设备时，在第一数据库中只存储推荐应用列表中应用的应用信息。这个例子可以看成第一种实现方式中的一个示例。也就是针对单用户使用场景，推荐应用列表的变动相对会较小，只存储推荐应用列表中的应用的应用信息已经足以满足需求。

在另一个例子中，当有多个用户使用电子设备时，在第一数据库中存储所有应用的应用信息。这个例子可以看成第二种实现方式中的一个示例。也就是针对多用户使用场景，推荐应用列表的变动相对会较大，所以全部存储会更适合。

在又一种实现方式中，当推荐应用列表被更新时，在第一数据库中存储更新后的推荐应用列表中所有应用的应用信息的同时，不删除已存储在第一数据库中的应用的应用信息。也就是说，只增加新的，不删除旧的。这种方式，可以看成是上述两种方式的一种折中，也就是第三种实现方式。简而言之，这种实现方式中的存储方式，能够在推荐应用列表变动较大时，满足用户的固定应用的需求的前提下，进一步减少存储操作。

结合第一方面，在第一方面的某些实现方式中，上述方法还包括：

监听推荐应用列表中每个应用是否启动；

当监听到推荐应用列表中的至少一个应用启动时，获取启动的至少一个应用的应用信息，应用信息包括全路径信息；

将监听到的应用信息存储到第一数据库中。

在这种实现方式中，按照推荐应用列表存储应用信息，可以看成是上述第一种实现方式的存储(也就是只存储推荐应用列表中应用的应用信息)和第三种实现方式的存储(虽然按照推荐应用列表来存储推荐应用列表中应用的应用信息，但对于已经存储在数据库中的应用信息不会删除)的执行过程的示例。上述三种存储的实现方式主要解决的是存哪些存多少的问题，而在这种实现方式中，主要解决的是何时存储的问题。对于一个应用，当它运行的时候是可以获取到其全路径这些信息的，所以可以监听推荐应用列表中每个应用是否启动，也就是监听推荐应用列表中每个应用的启动进程是否创建，当有创建事件发生，就说明这个应用启动了，就可以获取到启动的应用(或者认为正在运行的应用)的应用信息。

结合第一方面，在第一方面的某些实现方式中，在将监听到的应用信息存储到第一数据库中时，可以包括：

当第一数据库中不包括被监听应用的应用信息时，将监听到的该被监听应用的应用信息存储到第一数据库中；或者，

当第一数据库中包括被监听应用的应用信息时，将第一数据库中已存储的该被监听应用的应用信息替换为监听到的应用信息；或者，当第一数据库中已存储的该被监听应用的应用信息与监听到的应用信息不同的时候，将第一数据库中已存储的该被监听应用的应用信息替换为监听到的应用信息。

也就是说，在往第一数据库中存储应用信息时，如果数据库中没有存储记录，就可以增加进去，而如果已经有了存储记录就可以替换已经有的。这种实现方式，相当于最小代价的去更新数据库中的存储信息。上述被监听应用可以理解为是上述被监听到的至少一个应用中的应用。

还应理解，在替换的时候包括两种可能的处理方式，可以不比较，而是将已存储应用信息(例如上述第一数据库中已存储的该被监听应用的应用信息)直接替换成新监听到的应用信息(例如上述监听到的应用信息)，或者是先比较已存储应用信息和新监听到的应用信息之间是不是一样的，并只有不一样的时候才替换成新监听到的。前一种处理方式，就不需要再去比较新旧应用信息有没有变化了，更快速，而且也实现了实时更新，但对于数据库中数据的修改频次会更高。后一种处理方式增加了判断比较的步骤，但是也减少了修改次数。两种处理方式各有优势。

结合第一方面，在第一方面的某些实现方式中，在从第一数据库中读取推荐应用列表中每个应用的全路径信息时，可以包括：

通过遍历推荐应用列表中每个应用的方式，依次从第一数据库中查找并读取每个应用的全路径信息。

也就是说，按照推荐应用列表，依次逐个去从第一数据库中查找每个应用的信息。例如可能是根据每个应用的名称或者启动进程的名称或者启动进程的标识，通过查表的方式，从第一数据库中找出对应的该应用的全路径。

结合第一方面，在第一方面的某些实现方式中，在根据推荐应用列表中每个应用的全路径信息，将推荐应用列表中的应用固定到任务栏时，可以包括：

当任务栏中不包括推荐应用列表中的第一应用时，根据第一应用的全路径信息，将第一应用固定到任务栏。

这种方式能够使得满足用户期望的应用优先被固定。此处对第一应用到底是推荐应用列表中的哪个应用不存在限定，只要是列表中有但任务栏中没有的，都可以称之为第一应用。

结合第一方面，在第一方面的某些实现方式中，上述方法还包括：当推荐应用列表中不包括任务栏中的第二应用时，将第二应用从任务栏中删除。

这种方式删除不再符合用户期望的应用，使得任务栏中的应用都是满足用户期望的。此处对第二应用到底是任务栏中的哪个应用不不存在限定，只要是任务栏中有但列表中没有的，都可以称之为第二应用。

上述增加第一应用和删除第二应用这两种实现方式的结合，就能够实现最小代价(最小变化原则)更新任务栏中固定的应用的目的。

结合第一方面，在第一方面的某些实现方式中，被固定到任务栏中的推荐应用列表中的应用的图标还包括角标，角标用于表示该图标对应的应用是包含于推荐应用列表的。

换而言之，就是为基于推荐应用方案固定的应用打上标记，跟用户自行通过任务栏管理或者右击应用图标选择相应选项的方式这种传统固定方式固定的应用加以区分。

第二方面，提供了一种在任务栏固定应用的装置，该装置包括由软件和/或硬件组成的用于执行第一方面的任意一种方法的单元。

第三方面，提供了一种电子设备，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，当处理器执行计算机程序时能够实现第一方面的任意一种方法。

第四方面，提供了一种芯片，包括处理器，该处理器用于读取并执行存储在存储器中的计算机程序，当计算机程序被处理器执行时能够实现第一方面的任意一种方法。

可选地，该芯片还包括存储器，存储器与处理器电连接。

可选地，该芯片还可以包括通信接口。

第五方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，当计算机程序被处理器执行时能够实现第一方面的任意一种方法。

第六方面，提供了一种计算机程序产品，该计算机程序产品包括计算机程序，当计算机程序被处理器执行时能够实现第一方面的任意一种方法。

附图说明

图1是本申请实施例的一种适用场景的示意图。

图2是本申请实施例的一种在任务栏固定应用的方法的示意性流程图。

图3是本申请实施例的一种在任务栏中固定应用的方案的执行过程的示意性框架图。

图4是本申请实施例的一种电子设备的软件架构示意图。

图5是本申请实施例的一种存储应用信息的执行过程的示意性流程图。

图6是本申请实施例的一种在任务栏固定应用的执行过程的示意图。

图7是本申请实施例的一种在任务栏固定应用的执行结果的示意图。

图8是本申请实施例的一种在任务栏固定应用的装置的示意图。

图9是本申请实施例的一种电子设备的硬件结构示意图。

具体实施方式

下面结合附图对本申请实施例的方案进行介绍。本申请提供的在任务栏固定应用的方法能够应用于笔记本电脑、电脑、台式机、服务器以及平板电脑等具有任务栏和具有在任务栏固定应用的功能的电子设备。

图1是本申请实施例的一种适用场景的示意图。如图1所示，屏幕B是电子设备A的组成部分，在屏幕B所显示的任务栏C中，包括有多个元素，这些元素中包括日期、网络、隐藏图标的标识，以及包括多个固定在任务栏C的应用图标，此处以包括开始目录、电子邮件、浏览器、文件管理这几个应用的图标为例。

电子设备A可以是电脑、笔记本电脑、平板电脑，还可以是服务器等各类电子设备，只要是具有任务栏和具有在任务栏固定应用的功能的电子设备即可。电脑可以是分体式、一体式等，不存在限定。对于各类电子设备的形态、大小、样式也都不存在限定。图1中给出了几种电子设备A的示例，但应理解，电子设备A也可以是其他满足上要求的电子设备，不局限于图1所示。

可以看出任务栏C的长度有限，导致能显示的应用图标的数量是有限的。

在实际使用时，用户可以通过从资源管理器、控制面板或开始菜单等任意可能的方式，找到目标应用，然后通过右击应用图标的方式找到“固定到任务栏”的选项，当点击了该选项就可以将该应用图标固定的任务栏了。此外，用户还可以通过在任务栏右击的方式，从任务栏设置或任务栏管理等可能的选项进入任务栏的管理界面，按照指示将一些应用固定到任务栏中。上述方式均为人工自主固定应用到任务栏的示例。

而为了提升用户体验，出现了通过推荐待固定应用的方法，就是通过学习用户使用应用的习惯，来为用户推送最期望使用的应用，这样就可以让用户知道自己的习惯，并从这些推荐的应用中选取一些固定到任务栏中了。或者还可以直接现将所有推荐的应用都固定到任务栏，然后由用户从中按需删减。但是，在实际使用时发现，虽然多数应用是可以固定到任务栏中的，但有些应用是无法固定的。所以就导致推荐的应用虽然满足了用户的期望，却由于存在无法固定的应用，导致这些应用不能真正按照用户期望展示在任务栏中，无法达到推荐待固定应用这一方案的理想效果，影响用户使用体验。

经分析发现，无法固定应用的原因是，在固定应用图标的时候，需要获取到应用的全路径，在传统方案中，获取这个全路径的方式是从注册表中读取出来。但是部分应用的安装路径并没有保存在注册表中，从而导致这些应用无法固定到任务栏。

本申请基于上述分析，以及基于用户对于应用的安装路径并不会频繁更换，所以只要想办法使得任意应用的全路径都能保存和在固定的时候能获取到，即可解决上述问题。所以，本申请实施例提供了一种新的在任务栏固定应用的方法，主要通过将因公的全路径信息集中存储在一个数据库中方便后续读取，以及在需要固定应用的时候，从这个数据库中读取推荐应用列表中每个应用的全路径，就可以将任意的被推荐应用固定到任务栏中了。将全路径集中存储在数据库的方式，使得应用的固定不再受传统方案中注册表的局限，从而使得任意应用都能被固定，当将其应用于推荐应用的固定时，就能够保证任意被推荐的应用都能够按照用户期望进行固定，保证了推荐方案的期望效果，提升用户使用体验。

需要说明的是，本申请实施例主要针对的是Windows操作系统或者其他存在有的应用不能固定到任务栏的情况的操作系统。而安卓系统由于固定应用的方式是不同的，不存在不能固定应用的问题，所以不在本申请所说的范围内。也就是说，本申请针对的是具有在任务栏固定应用的功能，但是却存在有些应用不能在任务栏固定的情况，而对于所有应用都能固定在任务栏的情况和不存在任务栏的情况，由于不存在本申请所针对的技术问题，不做讨论。简而言之，本申请主要解决的是，由于有些应用不能固定到任务栏，导致推荐应用的方案不能达到预期效果的技术问题。

图2是本申请实施例的一种在任务栏固定应用的方法的示意性流程图。该方法能够应用于上文所述任意一种电子设备中。下面对图2各步骤进行介绍。

S201、从第一数据库中获取推荐应用列表中每个应用的全路径信息。

第一数据库中存储有多个应用的全路径信息，这多个应用包括推荐应用列表中的所有应用。可以认为第一数据库是用来集中存储电子设备中各个应用的全路径等这类应用信息的数据库。应理解，对于第一数据库具体采用电子设备中的哪个或哪些存储模块不存在限定，只要能够满足存储需求即可，也就是至少能够存储下推荐应用列表中所有应用的应用信息的容量，以及至少能够在需要固定应用的时候，存储的应用信息都不会被删除或篡改或覆盖，保证满足固定应用时的读取应用信息的需求。

应用信息除了包括上述全路径信息，还可以包括应用的启动进程名称和/或应用的启动进程标识(processidentity，PID)。上述全路径信息也可以理解为是应用的启动进程的全路径的信息。全路径是指位于电脑的存储硬盘的哪个分区下的哪个文件夹下，一直到目标文件的路径。全路径也可以称之为绝对路径。对于任意一个存储在电子设备中的文件都有其唯一的全路径。

需要说明的是，对于一个应用，虽然可能会包括一个或多个进程，但必然都会包括一个用于启动该应用的启动进程，本申请主要以启动进程为例。当还包括其他进程时，应用信息还可以包括其它进程的进程名称、进程标识和进程的全路径。

在一种实现方式中，为了减少存储压力，可以只存储推荐应用列表中的所有应用的应用信息。也就是，在推荐应用列表生成之后，才进行存储，并且在存储的时候只存储推荐应用列表中的应用的应用信息。

在另一种实现方式中，可以存储所有应用的应用信息，不受推荐应用列表的局限。这样的好处是，无论后续哪个应用被推荐了，都不需要再更新数据库，但相对的也增大了存储数据量。

对于上述两种实现方式，可以按照实际需求采用。对于只存储推荐应用列表中应用的方式，可能会遗漏其他应用的应用信息，但由于推荐应用列表中都是最满足用户期望的应用，所以说明用户最可能固定到任务栏的应用已经都包含在内了，或者说已经基本满足用户固定应用的需求了，所以这种遗漏在这种特定应用场景下，不会带来过多不好的影响。对于全都存储的方式，是最全面的存储，对于多个用户使用同一个电子设备的场景可能会更加适用。因为，这种场景下，推荐应用列表中应用的变动较大，所以如果采用第一种方式，就需要重新获取变动了的应用的应用信息，而如果采用第二种方式，无论怎样变化，都不需要再重新获取。

在一个例子中，当只有一个用户使用电子设备时，在第一数据库中只存储推荐应用列表中应用的应用信息。这个例子可以看成第一种实现方式中的一个示例。也就是针对单用户使用场景，推荐应用列表的变动相对会较小，只存储推荐应用列表中的应用的应用信息已经足以满足需求。

在另一个例子中，当有多个用户使用电子设备时，在第一数据库中存储所有应用的应用信息。这个例子可以看成第二种实现方式中的一个示例。也就是针对多用户使用场景，推荐应用列表的变动相对会较大，所以全部存储会更适合。

在又一种实现方式中，当推荐应用列表被更新时，在第一数据库中存储更新后的推荐应用列表中所有应用的应用信息的同时，不删除已存储在第一数据库中的应用的应用信息。也就是说，只增加新的，不删除旧的。这种方式，可以看成是上述两种方式的一种折中，也就是第三种实现方式。举例说明，假设更新前的列表A中包括有5个应用，更新后的列表B中包括有6个应用，但是列表A中有2个应用不包括在列表B中，也就是说，列表B中这6个应用中，有3个是列表A中已经有的，有3个是新增的。那么，按照这个例子，就只需要存储3个新增的应用的应用信息，也不需要删除列表A中那2个不包括在列表B中的应用的应用信息。这样，如果用户后续突然又增加了对这2个只存在于列表A中的应用的使用时，也就是生成了列表C，而列表C中又再次包括了这2个应用的时候，就不会因为前面的删除操作导致还要重新再获取一次这2个应用的应用信息了。简而言之，这种实现方式中的存储方式，能够在推荐应用列表变动较大时，满足用户的固定应用的需求的前提下，进一步减少存储操作。

推荐应用列表是根据用户使用应用的习惯生成的，推荐应用列表中包括至少一个应用。该推荐应用列表可以理解为是通过学习用户对应用的使用习惯，所生成的用户最期望使用的应用的一个列表，这个列表中的应用是用户最希望展示在任务栏中的。也可以认为该推荐应用列表中的应用是为用户推荐的待固定到任务栏的应用，或者说为用户推荐的最符合用户固定期望的应用。

在又一种实现方式中，在步骤S201之前，上述方法还包括：

监听推荐应用列表中每个应用是否启动；

当监听到推荐应用列表中的至少一个应用启动时，获取启动的这至少一个应用的应用信息，该应用信息包括全路径信息；

将监听到的应用信息存储到第一数据库中。

在这种实现方式中，按照推荐应用列表存储应用信息，可以看成是上述第一种实现方式的存储(也就是只存储推荐应用列表中应用的应用信息)和第三种实现方式的存储(虽然按照推荐应用列表来存储推荐应用列表中应用的应用信息，但对于已经存储在数据库中的应用信息不会删除)的执行过程的示例。上述三种存储的实现方式主要解决的是存哪些存多少的问题，而在这种实现方式中，主要解决的是何时存储的问题。对于一个应用，当它运行的时候是可以获取到其全路径这些信息的，所以可以监听推荐应用列表中每个应用是否启动，也就是监听推荐应用列表中每个应用的启动进程是否创建，当有创建事件发生，就说明这个应用启动了，就可以获取到启动的应用(或者认为正在运行的应用)的应用信息。

还应理解，在获取启动的应用的应用信息的时候，当启动的应用是一个的时候，就是获取这一个应用的应用信息，当启动的应用是多个的时候可以同时获取这多个应用的每个应用的应用信息。

在将监听到的应用信息存储到第一数据库中时，根据存储方式的不同，具体的存储操作也存在差异。如果采用的是上述第一种实现方式的存储(也就是只存储推荐应用列表中应用的应用信息)，那么这个第一数据库中存储的应用信息可以是被清空了的，也就是说，在获取到推荐应用列表之后，先将第一数据库中存储的应用信息全部清空。则在执行上述将监听到的应用信息存储到第一数据库中的步骤时，就都是首次存储，直接存储即可。如果采用的是上述第三种实现方式的存储(虽然按照推荐应用列表来存储推荐应用列表中应用的应用信息，但对于已经存储在数据库中的应用信息不会删除)，那么这个第一数据库中存储的应用信息不会被清空，是一种随着推荐应用列表的不断更新而不断增加的存储方式。此时，可以是只增加数据库中没有的应用信息。

在一个例子中，上述将监听到的应用信息存储到所述第一数据库中的步骤可以包括：

当第一数据库中不包括被监听应用的应用信息时，将监听到的该被监听应用的应用信息存储到第一数据库中；或者，

当第一数据库中包括被监听应用的应用信息时，将第一数据库中已存储的该被监听应用的应用信息替换为监听到的应用信息；或者，当第一数据库中已存储的该被监听应用的应用信息与监听到的应用信息不同的时候，将第一数据库中已存储的该被监听应用的应用信息替换为监听到的应用信息。

也就是说，在往第一数据库中存储应用信息时，如果数据库中没有存储记录，就可以增加进去，而如果已经有了存储记录就可以替换已经有的。这种实现方式，相当于最小代价的去更新数据库中的存储信息。上述被监听应用可以理解为是上述被监听到的至少一个应用中的应用。

还应理解，在替换的时候包括两种可能的处理方式，可以不比较，而是将已存储应用信息(例如上述第一数据库中已存储的该被监听应用的应用信息)直接替换成新监听到的应用信息(例如上述监听到的应用信息)，或者是先比较已存储应用信息和新监听到的应用信息之间是不是一样的，并只有不一样的时候才替换成新监听到的。前一种处理方式，就不需要再去比较新旧应用信息有没有变化了，更快速，而且也实现了实时更新，但对于数据库中数据的修改频次会更高。后一种处理方式增加了判断比较的步骤，但是也减少了修改次数。两种处理方式各有优势。

在另一个例子中，当从第一数据库中读取推荐应用列表中每个应用的全路径信息时，可以包括：

通过遍历推荐应用列表中每个应用的方式，依次从第一数据库中查找并读取每个应用的全路径信息。

也就是说，按照推荐应用列表，依次逐个去从第一数据库中查找每个应用的信息。例如可能是根据每个应用的名称或者启动进程的名称或者启动进程的标识，通过查表的方式，从第一数据库中找出对应的该应用的全路径。

在又一个例子中，当推荐应用列表中的所有应用的应用信息都在第一数据库中存储时，结束对推荐应用列表中的应用的监听。在这个例子中，相当于当每个列表中的应用都启动过一次之后，需要的数据都存储好了，就可以结束监听，节省占用的资源。

在这个例子中，还可以进一步的，当推荐应用列表被更新之后，也就是新的推荐应用列表生成后，重新执行上述步骤，也就是执行上述监听推荐应用列表中每个应用是否启动；当监听到推荐应用列表中的至少一个应用启动时，获取启动的这至少一个应用的应用信息，该应用信息包括全路径信息；以及将监听到的应用信息存储到第一数据库中的步骤。区别在于，此时监听的是更新后的推荐应用列表中的应用，存储的也是更新后的推荐应用列表中应用的应用信息。

在又一种实现方式中，监听电子设备中所有应用是否启动；当监听到任意一个应用启动时，获取该应用的应用信息，并存储到第一数据库中。这种实现方式，只要应用发生启动就会触发一次存储。这种存储是一种全面无遗漏的存储方式。但是这种方式由于是一直在监听所有应用，所以需要消耗的资源相对较多。尤其对于一些应用，用户几乎不怎么使用，这种监听就有点浪费资源了。

在一个例子中，只监听第一数据库中没有存储记录的应用是否启动。这个例子中一定程度减少了监听消耗的资源，但是对于那些用户几乎不怎么使用的应用的监听依然是一种浪费。

还需要考虑的一种情况是，有没有一种可能，有个应用在推荐应用列表中，但是一直没有启动过，导致第一数据库中一直不会存储这个应用的应用信息，也就导致后续无法将这个应用固定到任务栏中？首先，这种情况发生的概率几乎可以忽略不计，因为推荐应用列表是按照用户的使用习惯生成的，所以推荐应用列表中的应用必然是符合用户使用期望的，如果这个应用在历史时期很少被使用，就不可能出现在推荐应用列表中。而如果这个应用在历史时期经常被使用，所以出现在了推荐应用列表中，但是后续一直没有被使用，这种情况就太突兀了，因为用户的使用习惯是不会骤变的。此外，即使这种情况发生了，也说明这个应用不再是符合用户使用需求的应用(之后一次都没启动过，就说明不满足用户使用期望了)，那就更没有固定到任务栏中的必要了，而且等下一次的推荐应用列表生成的时候这个应用也会从列表中消失。简而言之，本申请是基于推荐应用方案来进一步解决怎样固定应用的问题，所以不会因为上述这种特殊情况影响整体技术方案的效果。

但是如果是跳出推荐应用这一场景，例如就是宽泛的希望将任意应用都能固定到任务栏中，那么就不需要执行按照推荐应用列表来存储应用信息的操作了，而必须借助于上述监听所有电子设备中的应用的方式来存储所有应用的应用信息，以及当接收到任意一个应用的固定操作的指示的时候，就去读取这个应用的存储的全路径信息以及将其固定在任务栏中。显然，这种场景下，对于一直没有启动过的应用，用户是无法实现对其固定的。

简而言之，由于本申请是基于推荐应用列表来存储和获取应用信息，所以只要是出现在推荐应用列表中的应用都是满足用户期望的，不会出现某个应用满足用户期望却因为没有启动过而无法固定的情况。

S202、根据推荐应用列表中每个应用的全路径信息，将推荐应用列表中的应用固定到任务栏。

在Windows这类操作系统中，固定应用到任务栏必须要用到全路径，也就是绝对路径。传统方案获取全路径的方式是在安装应用的时候会将应用的安装路径(此处是全路径)保存到注册表中，那么在固定应用的时候就可以从注册表中读取出全路径进行固定了。但是实际中发现，有些应用的安装路径并没有在注册表中保存下来，所以就会导致这些没有被保存的应用是无法获取到其全路径信息的，所以在固定的时候也就无法固定成功。但对于安卓系统，由于固定方式不同，就不存在这种在固定的时候因为全路径信息无法获取导致固定失败的问题了。

应理解，步骤S202是在基于推荐应用列表来固定应用，而不是针对某个特定应用去固定。也就是说，在执行步骤S202的时候，固定的应用的数量是不确定的，可能是一个，也可能是多个。

在一种实现方式中，可以将任务栏中没有但推荐应用列表中有的应用固定到任务栏中。也就是说，S202可以包括：当任务栏中不包括推荐应用列表中的第一应用时，根据第一应用的全路径信息，将第一应用固定到任务栏。这种方式能够使得满足用户期望的应用优先被固定。此处对第一应用到底是推荐应用列表中的哪个应用不存在限定，只要是列表中有但任务栏中没有的，都可以称之为第一应用。

在另一种实现方式中，对于任务栏中存在的不再推荐的应用还可以进行删除。也就是说，上述方法还包括：当推荐应用列表中不包括任务栏中的第二应用时，将第二应用从任务栏中删除。这种方式删除不再符合用户期望的应用，使得任务栏中的应用都是满足用户期望的。此处对第二应用到底是任务栏中的哪个应用不不存在限定，只要是任务栏中有但列表中没有的，都可以称之为第二应用。

上述增加第一应用和删除第二应用这两种实现方式的结合，就能够实现最小代价(最小变化原则)更新任务栏中固定的应用的目的。

在又一种实现方式中，被固定到任务栏中的推荐应用列表中的应用的图标还包括角标，角标用于表示该图标对应的应用是包含于推荐应用列表的。换而言之，就是为基于推荐应用方案固定的应用打上标记，跟用户自行通过任务栏管理或者右击应用图标选择相应选项的方式这种传统固定方式固定的应用加以区分。

应理解，上述角标与应用的原始图标的相对位置和具体形态不存在限定。例如，可以是位于图标右下角、左上角、左下角或右上角。角标相对于原始图标的大小也不存在限定，只要合适即可，也就是能便于用户分辨但又不会太大的合适大小。角标可以是字母、数字或者形状、图形，只要能够表示出这是通过推荐应用的方式生成的即可。

在一个例子中，可以从全路径信息中提取应用进程的原始图标，并基于该原始图标为该应用创建一个用于固定到任务栏的图标，该创建的图标包括上述角标。

在另一个例子中可以利用目前电子设备最常用的图形设备接口(Gdi)来绘制，也就是再原始图标的基础上绘制出一个角标。

在进行固定的时候，可以利用任务栏COM对象来将这个创建的图标进行固定。

图2所示方法，主要通过从预存储了推荐应用列表中每个应用的全路径信息的数据库中获取全路径信息和固定应用，使得任意被推荐的应用都能够固定到任务栏中，提升用户使用体验。

图3是本申请实施例的一种在任务栏中固定应用的方案的执行过程的示意性框架图。图3可以看成是执行图2所示方法的一种框架示例，但应理解，图2所示方法只占据图3所示框架中的一部分，也就是图2所示方法是针对固定应用的时候怎样固定的这部分。如图3所示，该框架可以看成是一个推荐应用的完整方案的执行框架，也就是为了真正实现为用户推荐满足期望的应用并固定在任务栏这一业务的整个执行过程的框架。该框架包括数据采集模块、模型推荐模块和应用固定模块。本申请所述方案主要发生在应用固定模块中。

数据采集模块用于获取用户对应用的操作，并且将该操作作为模型推荐模块中推荐模型的训练数据，来更新推荐模型的参数，从而使得模型推荐模块输出的推荐应用列表能够随着用户对于各个应用的使用而不断更新。

数据采集模块主要是获取用户的应用创建(即启动应用)的操作和应用切换(即切换应用的操作)，并将切换应用的操作发送给模型推荐模块的数据库#1，作为训练数据来不断更新推荐模型。

在本申请中，可以利用数据采集模块来获取应用信息，图3中以应用信息包括进程名称和全路径，数据采集模块将获取的应用信息存储到数据库#2为例。

模型推荐模块则利用来自于数据采集模块的进程切换信息，对推荐模型进行训练，训练完成后，推送新的推荐列表。图3中的应用过滤可以看成是更新推荐列表的示例，也就是如果某个应用在推荐列表中已经有了就不用增加(即所谓应用过滤)，没有的则新增。

应用固定模块从模型推荐模块接收推荐列表，以及从数据采集模块获取全路径信息。应用固定模块从全路径信息中提取应用进程的原始图标，并基于该原始图标为该应用创建一个用于固定到任务栏的图标，之后利用任务栏COM对象，在任务栏中增加图标和/或删除(取消固定)任务栏中已有图标。

如图3所示，数据采集模块执行S301，在发生应用切换的操作时，采集该切换操作，并发送给模型推荐模块。模型推荐模块在接收到切换操作的应用切换信息后，执行S302，将应用切换信息存储到数据库#1。当数据库#1中存储的应用切换信息足够进行一次训练时，模型推荐模块执行S303利用这些应用切换信息对推荐模型进行训练，也就是更新推荐模型。模型推荐模块利用推荐模型执行S304，进行应用过滤，也就是将当前次的应用切换操作的这个应用更新至推荐列表，该更新操作包括判断原推荐列表中是否存在这个应用，如果已经存在就过滤掉，如果没有就将该应用增加到推荐列表中，并将更新后的推荐列表发送到应用固定模块。数据采集模块还执行S305，在发生应用构建时，采集该启动应用的应用信息。之后数据采集模型执行S306将采集到的应用信息存储至数据库#2。

应用固定模块执行S307从模型推荐模块接收推荐列表，然后基于推荐列表执行S308从数据库#2中获取全路径信息，之后执行S309创建推荐列表中各个应用的待固定图标，然后执行S310利用任务栏COM对象固定或取消固定任务栏中的应用。S308可以看成是S201的一个示例，S309-S310可以看成是S202的一个示例。S305-S306可以看成是数据库怎么存储应用信息的示例。S301-S307可以看成是推荐列表的来源的示例。

图4是本申请实施例的一种电子设备的软件架构示意图。如图4所示，该软件架构包括应用层、架构层、系统层(图中用OS表示)和硬件层。其中应用层包括管理应用的功能入口和交互界面，可以理解为本申请的固定方案和/或整个推荐应用方案的执行入口和交互界面。例如该管理应用可能是电脑管家。

架构层包括能够用于应用推荐服务的各个模块，例如可以是图3所示各个模块，也就是可以包括数据采集模块、模型推荐模块和应用固定模块。

系统层可以包括任务栏固定模块(也可以称之为任务栏COM对象)，可以理解为执行将应用图标固定到任务栏这一操作的系统库。

硬件层可以包括各类硬件驱动。

应理解，图4只是给出了各层与本申请方案相关的一些单元/模块的示例，还可以存在其它结构形式，不存在限定。

图5是本申请实施例的一种存储应用信息的执行过程的示意性流程图。图5可以看成是上述将推荐应用列表中每个应用的应用信息存储到第一数据库的执行过程的一个示例。

S501、监听应用焦点进程的创建。

此处的应用即为推荐应用列表中的应用，而焦点进程可以认为是推荐应用列表中的应用的启动进程。焦点进程的创建事件发生就说明这个应用启动了。

可以通过设置白名单的方式，对推荐应用列表中的这些期望推荐的应用进行监听。

S501可以看成是上述“监听推荐应用列表中每个应用是否启动”这一步骤的示例。

S502、获取当前系统的全量进程信息表。

全量进程信息表中包括所有系统正在运行的应用的应用信息。也就是说，执行S502时，只要是已经启动的，也就是正在运行的应用，都可以获取其应用信息，或者说，正在运行的应用的应用信息都会包含在全量进程信息表中。该应用信息可以包括进程名称、进程标识和全路径等信息。

S503、根据焦点进程名称在全量进程信息表中查找出该焦点进程对应的全路径。

也就是说，全量进程信息表中包含的是所有正在运行的应用的应用信息，而步骤S503只从中筛选出推荐应用列表中的应用的应用信息。

由于焦点进程已经创建，应用属于启动状态，所以可以直接在全量进程信息表中查找到焦点进程对应的全路径。

S502和S503可以看成是上述步骤“当监听到推荐应用列表中的至少一个应用启动时，获取启动的这至少一个应用的应用信息，该应用信息包括全路径信息”的一个示例。

S504、将焦点进程的应用信息更新到数据库中。

在存储时，可以将所有应用信息都存储，也可以只存储进程的名称和全路径，还可以只存储进程标识和全路径。

S504可以看成是上述步骤“将监听到的应用信息存储到第一数据库中”的一个示例。

可以看出，此处的存储是只针对推荐应用列表中的应用的，也或者说只针对上述焦点进程，对于其他也在启动状态的应用并不会存储。也就是说，此处是按照推荐应用列表存储应用信息，可以看成是上述第一种实现方式的存储(也就是只存储推荐应用列表中应用的应用信息)和第三种实现方式的存储(虽然按照推荐应用列表来存储推荐应用列表中应用的应用信息，但对于已经存储在数据库中的应用信息不会删除)的执行过程的示例。

在一种实现方式中，S504可以包括：

当数据库中不包括焦点进程的应用信息时，将焦点进程的应用信息存储到数据库中；或者，

当数据库中包括焦点进程的应用信息时，将数据库中已存储的焦点进程的应用信息替换为此次监听到的应用信息。

直接替换成新监听到的应用信息，就不需要再去比较新旧应用信息有没有变化了，更快速，而且也实现了实时更新。但应理解，也可以是判断焦点进程的全路径信息是否发生变化，例如安装位置发生了变化，当发生变化时才将该焦点进程已经存储的全路径信息替换成新监听到的。这种方式增加了判断比较的步骤，但是也减少了修改次数。两种处理方式各有优势。

图6是本申请实施例的一种在任务栏固定应用的执行过程的示意图。图6可以看成是图2所示方法的一个示例。

S601、接收推荐应用列表。

该推荐应用列表可以是通过推荐模型推荐的或模型推荐模块输出的。

S602、循环遍历推荐应用列表，在存储有应用信息的数据库中查找每个应用的全路径信息。

S602可以看成是上述步骤“通过遍历推荐应用列表中每个应用的方式，依次从第一数据库中查找并读取每个应用的全路径信息”的一个示例。

S601-S602可以看成是S201的一个示例。

S603、根据全路径信息获取应用的原始图标，并在其基础上绘制出待固定到任务栏的图标。

例如，可以根据待固定应用的全路径信息，得到该应用的原始图标，然后利用Gdi给原始图标绘制出一个角标，带有角标的新图标就是上述待固定到任务栏的图标。

S604、将待固定到任务栏的图标更新到任务栏中。

可选地，可以以最小化变化原则进行更新，假设上一次在任务栏固定的应用列表为列表A，本次推荐应用列表为列表B。最小化原则是指首先取消在列表A但不在列表B中的应用的固定，再固定不在列表A但在列表B中的应用，保证两个列表之间相同的应用固定不变。

在固定或取消固定的时候，可以基于任务栏的COM对象去实现。

S603-S604可以看成是S202的一个示例。

图7是本申请实施例的一种在任务栏固定应用的执行结果的示意图。

如图7所示，在界面701中任务栏固定了ABCD四个应用的图标，其中BCD是通过推荐应用的方式固定的，所以具有一个角标。图7以角标为“YO”字样为例，但应理解，指示中也可以是其他角标形式。可以将界面701看成是第i次执行本申请实施例的方案后的结果展示，i为正整数。

当第i+1次执行了本申请实施例的方案后，生成了界面702中任务栏所呈现的情况，界面702的任务栏固定了BCE三个应用的图标，且BCE都是带有角标的，表示这三个应用都是通过推荐应用的方式生成的，也就是基于推荐应用列表生成的。

也就是说，界面701对应的推荐应用列表中包括ABCD四个应用，当往任务栏固定的时候，需要获取这四个应用的全路径信息，并且，在固定的时候，由于A应用已经在任务栏中了，所以不需要执行固定操作，而BCD因为没有在任务栏中，所以将这三个应用固定到了任务栏，并且都带有角标。界面702对应的推荐应用列表中则包括的是BCE三个应用，当往任务栏固定的时候，需要获取这三个应用的全路径信息，并且，在固定的时候，由于BC已经在任务栏中了，所以不需要执行固定操作，而E因为没有在任务栏中，所以将E应用固定到了任务栏，此外由于A不在推荐应用列表中，所以从任务栏中删除。

应理解，图7只是本申请实施例的执行结果的一个示例，在实际使用时，可能会存在其他情况，不再逐一示例。例如任务栏可能还包括其他元素，或者任务栏不是位于屏幕下方的，而是位于屏幕左侧，或者角标的样式是图形而不是此处的字样等等。

上文主要结合附图对本申请实施例的方法进行了介绍。应理解，虽然如上所述的各实施例所涉及的流程图中的各个步骤依次显示，但是这些步骤并不是必然按照图中所示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。下面结合附图对本申请实施例的装置进行介绍。

图8是本申请实施例的一种在任务栏固定应用的装置的示意图。如图8所示，该装置2000包括获取单元2001和处理单元2002。该装置2000可以是集成在上书任意一种电子设备中。

该装置2000能够用于执行上文任意一种在任务栏固定应用的方法。例如，获取单元2001可用于执行步骤S201，处理单元2002用于执行步骤S202。又例如，获取单元2001可用于执行步骤S501-S503，处理单元2002可用于执行步骤S504。又例如，获取单元2001可用于执行步骤S601-S602，处理单元2002可用于执行步骤S603-S604。

在一种实现方式中，装置2000还可以包括存储单元，该存储单元中包括上述第一数据库。该存储单元可以是集成在上述任意一个单元中，也可以是独立于上述所有单元之外的单元。

图9是本申请实施例的另一种电子设备的硬件结构示意图。如图9所示，该电子设备3000包括：至少一个处理器3001(图9中仅示出一个)处理器、存储器3002以及存储在所述存储器3002中并可在所述至少一个处理器3001上运行的计算机程序3003，所述处理器3001执行所述计算机程序3003时实现上述任意一种方法中的步骤。

本领域技术人员可以理解，图9仅仅是电子设备的举例，并不构成对电子设备限定，实际中电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。

处理器3001可以是中央处理单元(central processing unit，CPU)，其他通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(applicationspecific integrated circuit，ASIC)、现成可编程门阵列(field-programmable gatearray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器3002在一些实施例中可以是电子设备3000的内部存储单元，例如电子设备3000的硬盘或内存。存储器3002在另一些实施例中也可以是电子设备3000的外部存储设备，例如电子设备3000上配备的插接式硬盘，智能存储卡(smart media card,SMC)，安全数字(secure digital,SD)卡，闪存卡(flash card)等。可选地，存储器3002还可以既包括电子设备3000的内部存储单元也包括外部存储设备。存储器3002用于存储操作系统、应用程序、引导装载程序、数据以及其他程序等，例如所述计算机程序的程序代码等。存储器3002还可以用于暂时地存储已经输出或者将要输出的数据。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请实施例还提供了一种电子设备，该电子设备包括：至少一个处理器、存储器以及存储在所述存储器中并可在所述至少一个处理器上运行的计算机程序，所述处理器执行所述计算机程序时可实现上述任意方法中的步骤。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，该计算机程序产品包括计算机程序，当计算机程序被处理器执行时可实现上述各个方法实施例中的步骤。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/电子设备的任何实体或装置、记录介质、计算机存储器、只读存储器(read-only memory，ROM)、随机存取存储器(random accessmemory，RAM)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种在任务栏固定应用的方法，其特征在于，包括：

监听推荐应用列表中每个应用是否启动；

当监听到所述推荐应用列表中的至少一个应用启动时，获取启动的至少一个应用的应用信息，所述应用信息包括全路径信息；

将监听到的应用信息存储到第一数据库中；

从第一数据库中获取推荐应用列表中每个应用的全路径信息；所述第一数据库中存储有多个应用的全路径信息，所述多个应用包括所述推荐应用列表中的所有应用；所述推荐应用列表是根据用户使用应用的习惯生成的，所述推荐应用列表中包括至少一个应用；

根据推荐应用列表中每个应用的全路径信息，将所述推荐应用列表中的应用固定到任务栏。

2.根据权利要求1所述的方法，其特征在于，所述将监听到的应用信息存储到所述第一数据库中，包括：

当所述第一数据库中不包括被监听应用的应用信息时，将监听到的该被监听应用的应用信息存储到所述第一数据库中；或者，

当所述第一数据库中包括被监听应用的应用信息时，将所述第一数据库中已存储的该被监听应用的应用信息替换为监听到的应用信息；或者，当所述第一数据库中已存储的该被监听应用的应用信息与监听到的应用信息不同的时候，将所述第一数据库中已存储的该被监听应用的应用信息替换为监听到的应用信息。

3.根据权利要求1所述的方法，其特征在于，所述应用信息还包括应用的启动进程名称和/或应用的启动进程标识。

4.根据权利要求1所述的方法，其特征在于，所述从所述第一数据库中读取所述推荐应用列表中每个应用的全路径信息，包括：

通过遍历所述推荐应用列表中每个应用的方式，依次从所述第一数据库中查找并读取每个应用的全路径信息。

5.根据权利要求1所述的方法，其特征在于，所述根据推荐应用列表中每个应用的全路径信息，将所述推荐应用列表中的应用固定到任务栏，包括：

当任务栏中不包括所述推荐应用列表中的第一应用时，根据所述第一应用的全路径信息，将所述第一应用固定到任务栏。

6.根据权利要求1至5中任一项所述的方法，其特征在于，所述方法还包括：

当所述推荐应用列表中不包括任务栏中的第二应用时，将所述第二应用从任务栏中删除。

7.根据权利要求1至5中任一项所述的方法，其特征在于，被固定到任务栏中的所述推荐应用列表中的应用的图标还包括角标，所述角标用于表示该图标对应的应用是包含于所述推荐应用列表的。

8.一种在任务栏固定应用的装置，其特征在于，包括：

获取单元，用于监听推荐应用列表中每个应用是否启动；当监听到所述推荐应用列表中的至少一个应用启动时，获取启动的至少一个应用的应用信息，所述应用信息包括全路径信息；将监听到的应用信息存储到第一数据库中；从第一数据库中获取推荐应用列表中每个应用的全路径信息；所述推荐应用列表是根据用户对电子设备中应用的使用习惯生成的，所述推荐应用列表中包括至少一个应用；

处理单元，用于根据所述全路径信息，将所述推荐应用列表中的应用固定到任务栏。

9.一种电子设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的方法。