一种应用图标更新方法及装置与流程

本申请涉及通信技术领域，尤其涉及一种应用图标更新方法及装置。

背景技术：

随着通信技术的发展，为了满足日益增长和多种多样的业务需求，终端中的应用程序也越来越多。应用程序的图标一般显示在终端的桌面(即系统界面)上，以便用户操作。

目前，当应用程序的图标需要更新时，服务端通过发布新版本的客户端，以更新客户端应用程序的图标。具体地，客户端请求从服务端下载应用程序升级包，下载完成后解析该升级包获得应用程序的图标，更新该应用程序从而在终端的桌面上显示更新后的应用程序图标。

可以看出，针对只需要更新应用程序图标而无需更新应用程序代码的情况，如果采用升级的方式更新应用程序图标，则需要下载整个应用程序的升级包，而且升级过程需要用户主动发起，才能达到更新图标的目的，操作复杂。

技术实现要素：

本申请实施例提供一种应用图标更新方法及装置，用以由服务器发起图标更新操作，以简化图标更新操作复杂度。

本申请实施例提供的应用图标更新方法，包括：

终端接收服务器发送的图标更新请求，所述图标更新请求用于指示更新第一应用的图标；

所述终端根据所述图标更新请求，通过桌面管理程序，更新所述终端的桌面上所述第一应用的图标，所述桌面管理程序用于管理终端桌面上的应用程序图标。

本申请另外的实施例提供的应用图标更新方法，包括：

服务器向终端发送图标更新请求，所述图标更新请求用于指示更新第一应用的图标。

本申请实施例提供的终端，包括：

客户端，用于接收服务器中的服务端发送的图标更新请求，并根据所述图标更新请求向所述终端的操作系统中的消息处理单元发送第一消息，所述第一消息用于请求更新所述第一应用的图标；

消息处理单元，用于根据所述第一消息，向所述终端中的桌面管理程序发送第二消息，所述第二消息用于请求更新所述第一应用的图标；其中，所述桌面管理程序用于管理终端桌面上的应用程序图标；

桌面管理程序，用于根据所述第二请求，更新所述终端的桌面上所述第一应用的图标。

本申请实施例提供的服务器，所述服务器的服务端中包括：

图标更新指示单元，用于向终端发送图标更新请求，所述图标更新请求用于指示更新第一应用的图标。

本申请另外的实施例提供的终端，包括：

存储器，用于存储计算机程序指令；

处理器，耦合到所述存储器，用于读取所述存储器存储的计算机程序指令，并作为响应，执行如下操作：

接收服务器发送的图标更新请求，所述图标更新请求用于指示更新第一应用的图标；

根据所述图标更新请求，通过所述终端中的桌面管理程序，更新所述终端的桌面上所述第一应用的图标。

本申请的上述实施例中，服务器向终端发起图标更新请求，以指示更新第一应用的图标，使该终端可根据该图标更新请求，通过该终端中的桌面管理程序，更新第一应用的图标，与现有技术相比，无需向终端发送安装包或升级包，因而也无需终端从服务器下载安装包或升级包，从而简化了应用程序图标的更新过程，并可进一步节省网络资源开销。

附图说明

图1为本申请实施例适用的网络架构；

图2为本申请实施例使用的系统架构示意图；

图3为本申请实施例提供的应用图标更新流程的示意图；

图4为本申请实施例提供的兼容android的yunos系统框架示意图；

图5为本申请实施例中基于yunos的应用图标更新过程所涉及的系统架构示意图；

图6为基于图5所示的系统架构提供的应用图标更新流程示意图；

图7为本申请实施例中基于android的应用图标更新过程所涉及的系统架构示意图；

图8为基于图7所示的系统架构提供的应用图标更新流程示意图；

图9a、9b和9c分别为本申请实施例提供的客户端设备的结构示意图；

图10为本申请实施例提供的服务端设备的结构示意图；

图11为本申请实施例提供的终端的结构示意图。

具体实施方式

下面结合附图对本申请实施例进行详细描述。

图1示例性地示出了本申请实施例适用的一种网络架构示意图。如图1所示，该网络架构中可包括终端101、服务器103，终端101的数量可以是多个，服务器103的数量也可以是多个(图中仅示出了一个)。其中，终端101以及服务器103可通过网络102进行通信。

上述架构中的终端101上有客户端应用程序(以下简称客户端)，服务器103上有服务器端应用程序(以下简称服务端)。针对某种应用或服务，其客户端和服务端进行配合，可实现该种应用或服务。在一些实施例中，终端101中的客户端为某种第三方应用的客户端，服务器103中的服务端为该第三方应用的服务端；在另一些实施例中，服务器103中的服务端为操作系统服务端，终端101中的客户端为该操作系统服务端在终端上的代理客户端，比如该服务端可以是yunos服务端，可提供yunos更新服务，该客户端可以是yunos服务端在终端上的代理。

上述网络架构中的终端101可以是移动终端或pc(个人电脑)等设备，所述移动终端可以是手机、pda(personaldigitalassistant，掌上电脑)车载终端或智能穿戴设备等。

上述网络架构中，终端101、服务器103可以通过网络进行信息交互，该网络可以是广域网、局域网或互联网，或者采用移动通信技术的互联网。终端101可通过无线方式接入互联网，服务器103通常采用有线方式与互联网连接。

可选地，终端101、服务器103可以采用云计算技术，以基于云计算技术的强大功能实现信息处理。终端101和服务器103可采用基于云计算技术的操作系统，比如yunos，从而可以整合云端和终端的资源和服务。

本申请实施例中，客户端和服务端可基于应用程序或服务组件或服务资源等实现各种应用和服务。以采用yunos操作系统为例，客户端和服务端可基于yunos中的page实现各种服务。page是对本地服务和远程服务的抽象，也即服务的基本单元，通过对数据和方法的封装，可以提供各种服务。一个服务场景可以包括多个page。举例来说，一个page可以是ui(用户界面)、拍照等服务，也可以是后台服务，如账户认证。每个page可以在yunos中被唯一标识。

为了实现应用图标的自动更新，本申请实施例中，在需要更新某应用在桌面上的图标时，可通过操作系统提供的消息传递机制进行交互，利用桌面管理程序对该应用的图标进行更新。

其中，桌面(英文为desktop)，是计算机用语。桌面是打开计算机设备并登录到系统之后看到的主屏幕区域。例如，打开手机等终端时登录之后看到的主屏幕区域称为桌面，是系统操作平台。桌面上有应用程序图标，这些图标各自对应一个应用程序，通过操作图标可以运行相应的应用程序。这些应用程序图标可包括系统应用程序的图标，也可包括第三方应用程序的图标。

桌面管理程序主要用于对桌面进行管理，比如可以对桌面上的应用程序图标进行管理，可以是第三方应用程序。桌面管理程序具体可以是桌面启动器。下面的实施例以桌面启动器作为用于对桌面进行管理的应用程序为例描述。

图2示例性地示出了本申请实施例提供的系统架构示意图。如图所示，终端101中包括客户端201、桌面启动器204，终端的操作系统框架202中包括消息处理单元203。客户端201与消息处理单元203之间可基于操作系统通信机制进行通信，桌面启动器204与消息处理单元203之间也可基于操作系统通信机制进行通信。当服务器103中的服务端将图标更新请求发送给终端101中的客户端201后，终端中的客户端201向消息处理单元203发送系统消息以请求更新图标，消息处理单元203根据该请求向桌面启动器204发送系统消息，以指示更新图标，桌面启动器204根据该指示进行图标更新。

基于图2所示的系统架构，图3示出了本申请实施例提供的图标更新流程的示意图，如图所示，该流程可包括如下步骤：

步骤301：服务器向终端发送图标更新请求，该图标更新请求用于指示更新第一应用的图标。在一些实施例中，服务器在需要更新第一应用的图标时，发送该图标更新请求。

其中，“第一应用”是出于描述方便的考虑，在这里仅表示某种应用，并不特指某个或某类应用。该第一应用可以是系统应用，也可以是第三方应用，或者是其他类型的应用，本申请实施例对此不做限制。

服务器可通过多种方式获得终端的信息(比如终端的ip地址)，从而将该图标更新请求发送给客户端。以第一应用为第三方应用为例，作为一个例子，当第一应用的客户端请求从第一应用的服务端下载第一应用的安装包或升级包时，第一应用的服务端可获得该客户端所在终端的ip地址并进行保存；作为另一个例子，有些应用的使用需要用户首先使用用户账户进行登录，该应用的服务端保存有用户账户信息以及所在终端的相关信息(比如ip地址)。服务端可根据保存的上述信息获得客户端所在终端的地址等信息，从而将该图标更新请求发送给相应的终端。

上述图标更新请求中可包括图标的相关数据。所述图标的相关数据可以是图标数据(如图片)，也可以是图标数据的存储位置，客户端可根据该存储位置获取图标数据。应用程序的图标可以是图片，一个图标可以是多张不同格式的图片的集合体，进一步还可以包含一定的透明区域。由于操作系统和显示设备的多样性，导致了图标的大小需要有多种格式。操作系统在显示一个图标时，会按照一定的标准选择图标中最适合当前显示环境和状态的图像。比如，应用图标常用格式可包括ico、png、icl、ip。

步骤302：终端接收到该图标更新请求后获取第一应用的新图标。

该步骤中，如前所述，如果图标更新请求中携带有图标数据，则终端可直接从该图标更新请求中获取到新图标；如果图标更新请求中携带的是图标数据的存储位置信息，则终端可从该存储位置获取第一应用的新图标。

步骤303：终端通过该终端中的桌面启动器，更新该终端的桌面上第一应用的图标。

如前所述，该图标更新请求可被终端中的客户端接收。终端中的客户端可以是第一应用的客户端，也可以是操作系统的服务端在终端中的代理。

该步骤中，终端中的上述客户端可向操作系统中的消息处理单元发送第一消息，该第一消息用于请求更新第一应用的图标；消息处理单元可根据第一消息向桌面启动器发送第二消息，第二消息用于请求更新所述第一应用的图标；桌面启动器可根据第二消息更新第一应用的图标。在一些实施例中，第一消息和第二消息中可包括更新的图标；在另一些实施例中，更新的图标可以缓存在终端中，第一消息和第二消息中可包括缓存该图标的缓存单元的指示信息(比如缓存单元的地址)。

其中，第一消息能被操作系统中的消息处理单元进行解析和处理，消息处理单元根据解析和处理结果，向桌面启动器发送的第二消息能被桌面启动器解析和处理。

桌面启动器在收到第二消息后，可保存该更新的图标，并用该更新的图标替换当前桌面上第一应用的图标。进一步地，还可以根据第一应用的新图标更新桌面配置信息，比如，将第一应用的图标的名称修改为该新图标的名称，或将第一应用的图标的存储地址修改为该新图标的存储地址，这样，当桌面启动器重新启动后(比如终端重启或用户通过终端中的设置功能重启桌面启动器)，第一应用的新图标可被显示在桌面上。

进一步地，考虑到应用程序图标的时效性，在一些实施例中，在更新第一应用的图标之后，当第一应用的新图标的时效期限达到后，可对第一应用的图标进行恢复。具体实施时，客户端可监控图标的时效期限，当第一应用的新图标的时效期限达到时，可向消息处理单元发送图标恢复请求，消息处理单元向启动器发送图标恢复指示，从而使客户端将第一应用的图标恢复为原来的图标。

进一步地，在另一些实施例中，服务端可向客户端发送应用程序图标恢复指示，客户端可根据该指示，对第一应用的图标进行恢复。例如，服务端在发送图标更新请求之后，在第一应用的新图标的时效期限达到时，可发送图标恢复指示；再例如，服务端在发送图标更新请求之后，若希望恢复为原来的图标，则可发送图标恢复指示，从而使客户端将第一应用的图标恢复为原来的图标。

其中，客户端在进行图标恢复时，桌面启动器在收到图标恢复指示后，可获取第一应用的安装包中的图标，将桌面配置信息中所指示的第一应用的图标更新为第一应用的安装包中的图标，并使用从该安装包中获取的图标更新桌面上第一应用的图标，从而将第一应用的图标恢复为安装包中的图标。

可选地，第一应用的图标的时效期限可以是默认设置的，也可以是由服务器指定的。具体地，服务器可将第一应用的图标的时效期限信息包含在发送给客户端的图标更新请求中。

进一步地，客户端在根据服务端发送的图标更新请求更新了第一应用的图标之后，若客户端接收到第一应用的升级通知，并从服务器下载了第一应用的安装包(升级包中包含更新的图标)并进行了安装，则将第一应用的图标更新该安装包中的图标。若该安装包中未包含更新的图标，则仍可保持第一应用的图标的配置信息不变，从而仍在桌面上显示根据服务器发送的图标更新请求所更新的图标。

通过以上描述可以看出，本发明的上述实施例中，服务器向终端发起图标更新请求，使该终端可根据该图标更新请求，通过该终端中的桌面启动器，更新第一应用的图标，与现有技术相比，无需向终端发送安装包或升级包，因而也无需终端从服务器下载安装包或升级包，从而简化了应用程序图标的更新过程，并可进一步节省网络资源开销。

考虑到有些操作系统可以兼容其他操作系统的应用程序，本申请实施例针对这种操作系统，也可实现基于不同操作系统的应用程序的图标更新。以yunos系统为例，yunos即可支持基于yunos的应用程序，也可以支持兼容基于android的应用程序，对此，本申请的上述实施例可支持基于yunos的应用程序的图标更新，也可支持基于android的应用程序的图标更新。

下面分别结合图4至图8，对基于yunos的应用程序的图标更新过程以及基于android的应用程序的图标更新过程进行详细描述。

图4示例性地示出了一种兼容android的yunos系统框架示意图。如图所示，系统框架中包括host与guest两个子系统，其中，yunos即为host子系统，android即为guest子系统，两个子系统通过container(容器)技术隔离。该框架内的硬件抽象层(hardwareabstractionlayer，hal)提供了图形显示等方面的接口和驱动服务。

host子系统中的glibc，即c运行库，是linux中最底层的api(applicationprogramminginterface，应用程序编程接口)。guest子系统中的bioric，是android的linux内核库。

libhybris为兼容层，能够使基于glibc的操作系统重用现有的android的驱动(driver)服务；在图形(graphics)处理方面，libhybris还实现了eglplatform。eglplatform这是一套后台(backend)无关的遵循egl接口的图形平台，以及多个后台(backend)实现。

gralloc模块位于硬件抽象层中，封装了对帧缓冲区的所有访问操作。

guest子系统中的inputmanageerservice(输入管理模块)主要用于对输入事件进行监控和管理。

基于yunos的应用程序的图标更新过程所涉及的系统架构，可如图5所示。如图所示，homeshell是基于yunos的桌面启动器，它与基于yunos的客户端应用程序之间，可采用intern机制，通过dpms进行通信或信息交互。其中，客户端应用以及homeshell可被看作是不同的page。page之间交互的信息可封装为称为pagelink的信息实体，即基于pagelink可以在page间传递信息。intent通信机制是一种进程间通信机制，负责程序跳转和传递数据。

图5中，dpms是dynamicpagemanagerservice的英文简称，中文称为动态page管理服务，可以被看作是服务组件管理实体，是一种系统服务。dpms可以管理page生命周期以及运行时调度，page从创建到销毁的生命周期管理，以及page间经pagelink的交互都可以通过dpms实现。其中，dpms是host子系统中的服务组件。

基于图5所示的系统架构，图6示出了应用图标更新流程。该流程仍以第一应用为例描述，此处的第一应用为基于yunos的应用。如图所示，该流程可包括如下步骤：

步骤601：服务端向客户端发送图标更新请求。所述图标更新请求中可包括第一应用的新图标。该步骤的具体实现过程可参见图3中的步骤301。

步骤602：客户端接收到该图标更新请求后获取更新的图标。该步骤的具体实现过程可参见图3中的步骤302。

步骤603：客户端向host子系统中的dpms发送第一消息；

步骤604：dpms向homeshell发送第二消息；

步骤605：homeshell根据该第二消息更新第一应用的图标。

其中，步骤603～步骤605对应于图3所示的步骤303。

其中，第一消息和第二消息均用于请求更新第一应用的图标。具体地，客户端可通过第一消息，将封装有图标相关数据的pagelink发送给dpms；dpms可通过第二消息，将封装有图标相关数据的pagelink发送给homeshell；homeshell可解析接收到的pagelink，获得图标相关数据进行第一应用程序的图标更新。

其中，由于客户端以及homeshell均是基于yunos的应用，而dpms是yunos中负责应用之间信息交互的管理实体，因此，dpms可解析客户端发送的第一消息，并可根据该第一消息生成homeshell可解析的第二消息并发送给homeshell，以使homeshell根据该第二消息进行第一应用的图标更新。

基于android的应用程序的图标更新过程所涉及的系统架构，可如图7所示。如图所示，homeshell是基于yunos的桌面启动器，它与host子系统中的dpms之间可采用基于yunos的intern机制通信。第一用于的客户端是基于android的应用，它与guest子系统中的activitymanagerservice之间可采用基于android的intent机制通信。host子系统中的dpms与guest子系统中的activitymanagerservice之间可通过进程间通信服务模块进行通信。

其中，activitymanagerservice(活动管理服务)是guest子系统中的系统服务。activitymanagerservice主要负责管理应用程序组件，具体可包括管理应用进程的生命周期以及应用进程的组件，如，activity、service、broadcast和provider等组件。

可选地，进程间通信服务模块可包括两个组成部分(即两个子模块)，其中，第一子模块位于host子系统，用于与host子系统中的服务组件(本例子中是dmps)进行通信；第二子模块位于guest子系统，用于与guest子系统中的服务组件(本例子中是activitymanagerservice)进行通信；两个子模块之间可进行通信，第一子模块可将host子系统需要发送给guest子系统的消息封装为符合guest子系统通信机制的消息，第二子模块可将guest子系统需要发送给host子系统的消息封装为符合host子系统通信机制的消息。

基于图7所示的系统架构，图8示出了应用图标更新流程。该流程仍以第一应用为例描述，此处的第一应用为基于android的应用。如图所示，该流程可包括如下步骤：

步骤801：服务端向客户端发送图标更新请求。所述图标更新请求中可包括第一应用的新图标。该步骤的具体实现过程可参见图3中的步骤301。

步骤802：客户端接收到该图标更新请求后获取更新的图标。该步骤的具体实现过程可参见图3中的步骤302。

步骤803：客户端向guest子系统的activitymanagerservice发送第一消息，第一消息用于请求更新第一应用的图标。

步骤804：activitymanagerservice向进程间通信服务单元发送第三消息，第三消息用于请求更新第一应用的图标。

步骤805：进程间通信服务单元向host子系统的dpms发送第四消息，第四消息用于请求更新第一应用的图标。

步骤806：dpms根据第四消息，向homeshell发送第二消息，第二消息用于请求更新第一应用的图标。

步骤807：homeshell根据第二消息更新第一应用的图标。

其中，步骤803～步骤807对应于图3所示的步骤303。

具体地，上述流程中，客户端可通过第一消息，将封装有图标相关数据的android系统消息发送给activitymanagerservice；activitymanagerservice可通过第三消息，将封装有图标相关数据的android系统消息发送给进程间通信服务单元；进程间通信服务单元可通过第四消息将封装有图标相关数据的pagelink发送给dpms；dpms可通过第二消息，将封装有图标相关数据的pagelink发送给homeshell；homeshell可解析接收到的pagelink，获得图标相关数据进行第一应用程序的图标更新。

需要说明的是，上述系统架构仅以兼容android的yunos为例进行说明，对于其他类型的操作系统，也可基于上述原理实现应用图标更新。

基于相同的技术构思，本申请实施例还提供了一种终端。

参见图9a，为本申请实施例提供的终端的结构示意图，该终端可实现前述实施例中的应用图标更新流程。该终端可包括：客户端901、消息处理单元902、桌面管理程序903，其中：

客户端901，用于接收服务器中的服务端发送的图标更新请求，并根据所述图标更新请求向所述终端的操作系统中的消息处理单元发送第一消息，所述第一消息用于请求更新所述第一应用的图标；

消息处理单元902，用于根据所述第一消息，向所述终端中的桌面管理程序发送第二消息，所述第二消息用于请求更新所述第一应用的图标；其中，所述桌面管理程序用于管理终端桌面上的应用程序图标；

桌面管理程序903，用于根据所述第二请求，更新所述终端的桌面上所述第一应用的图标。

可选地，桌面管理程序903具体用于：将桌面配置信息中所指示的第一应用的图标更新为所述第一应用的新图标，将所述终端桌面上所述第一应用的图标更新为新图标。

在一些实施例中，操作系统中包括第一子系统和第二子系统，所述第一应用为基于所述第一子系统的应用。这种情况下，如图9b所示，客户端901具体用于向所述第一子系统的消息处理单元902发送第一消息；第一子系统的消息处理单元9021具体用于向第一子系统的桌面管理程序903发送第二消息；第一子系统的桌面管理程序903具体用于：根据所述第二消息，更新所述终端的桌面上所述第一应用的图标。

在另外一些实施例中，操作系统中包括第一子系统和第二子系统，所述第一应用为基于所述第二子系统的应用。这种情况下，如图9c所示，客户端901具体用于向所述第二子系统的消息处理单元发送第一消息；第二子系统的消息处理单元9022具体用于向进程间通信服务单元发送第三消息，所述第三消息用于指示更新所述第一应用的图标；进程间通信服务单元904具体用于向第一子系统的消息处理单元发送第四消息，所述第四消息用于指示更新所述第一应用的图标；第一子系统的消息处理单元9021具体用于根据所述第四消息，向第一子系统的桌面管理程序发送第二消息；第一子系统的桌面管理程序903具体用于根据所述第二消息，更新所述终端的桌面上所述第一应用的图标。

可选地，桌面管理程序903还用于：更新所述第一应用的图标之后，当更新后的所述第一应用的图标的时效期限达到后，对所述第一应用的图标进行恢复：或者，根据从所述服务器接收到的图标恢复指示，对所述第一应用的图标进行恢复。可选地，桌面管理程序903具体用于：获取所述第一应用的安装包中的图标，将桌面配置信息中所指示的第一应用的图标更新为所述第一应用的安装包中的图标，使用所述第一应用的安装包中的图标更新所述终端的桌面上所述第一应用的图标。

可选地，所述图标更新请求中包括所述第一应用程序的新图标。

可选地，所述图标更新请求中还包括以下信息之一或组合：图标时效期限信息；所述第一应用的指示信息。

基于相同的技术构思，本申请实施例还提供了一种服务器。

参见图10，为本申请实施例提供的服务器的结构示意图，该服务器可实现前述实施例描述的应用程序图标更新流程，该服务器包括服务端，所述服务端中可包括图标更新指示单元1001，进一步地还可包括图标恢复指示单元1002，其中：图标更新指示单元1001，用于向终端发送图标更新请求，所述图标更新请求用于指示更新第一应用的图标；图标恢复指示单元1002，用于在向终端发送图标更新请求之后，向所述终端发送图标恢复指示，所述图标恢复指示用于指示对所述第一应用的图标进行恢复。

可选地，所述图标更新请求中包括所述第一应用程序的新图标。

可选地所述图标更新请求中还包括以下信息之一或组合：图标时效期限信息；所述第一应用的指示信息。

基于相同的技术构思，本申请实施例还提供了一种终端。

参见图11，为本申请实施例提供的终端的结构示意图，该终端可实现前述实施例描述的应用图标更新流程，该终端总体来说可包括：处理器1101，存储器1102、显示器1103。

其中，处理器1101可以是通用处理器(比如微处理器或者任何常规的处理器等)、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。存储器1102具体可包括内部存储器和/或外部存储器，比如随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质。显示器1103可包括触摸屏控制电路。

处理器1101与其他各模块之间存在数据通信连接，比如可基于总线架构进行数据通信。总线架构可以包括任意数量的互联的总线和桥，具体由处理器1101代表的一个或多个处理器和存储器1102代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。处理器1101负责管理总线架构和通常的处理，存储器1102可以存储处理器1101在执行操作时所使用的数据。

本申请实施例揭示的流程，可以应用于处理器1101中，或者由处理器1101实现。在实现过程中，各步骤可以通过处理器1101中的硬件的集成逻辑电路或者软件形式的指令完成。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。

具体地，处理器1101，耦合到存储器1102，用于读取存储器1102存储的计算机程序指令，并作为响应，执行如下操作：

接收服务器发送的图标更新请求，所述图标更新请求用于指示更新第一应用的图标；

根据所述图标更新请求，通过桌面管理程序，更新所述终端的桌面上所述第一应用的图标，所述桌面管理程序用于管理终端桌面上的应用程序图标。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。