CN112988213B - 一种程序数据更新方法、电子设备及计算机存储介质 - Google Patents

Abstract

本申请提供一种程序数据更新方法、电子设备及计算机存储介质，涉及互联网技术领域，解决了应用程序更新时出现程序闪退的问题。具体方案为：在第一应用处于正在使用状态，且需要对第一程序数据进行更新的情况下，将第一程序数据对应的升级任务放入等待列表；获取第一应用的使用状态；在第一应用处于未使用状态的情况下，将升级任务从所述等待列表中取出；在升级任务的指示下，解析安装第一程序数据的更新数据包；或，在升级任务的指示下，根据第二程序数据更新所述第一程序数据；其中，第二程序数据是在第二存储区域内解析安装第一程序数据的更新数据包后得到的数据；第二存储区域与用于存储第一程序数据的第一存储区域不同。

Description

一种程序数据更新方法、电子设备及计算机存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种程序数据更新方法、电子设备及计算机存储介质。

背景技术

应用程序通过与用户的交互，向用户提供多样化的服务，丰富了用户的生活。随着互联网技术纵深发展，应用程序需要快速迭代（比如，版本的更新），以适应市场的变化节奏。

然而，在一些场景下，应用程序更新过程中，会出现程序闪退的问题，而程序闪退也会直接造成中断向用户提供相关服务。以升级安装于手机内的聊天应用举例。如图1中的（a）所示，手机显示聊天应用的聊天窗口，用户正通过该聊天窗口与联系人聊天，如果此时升级该聊天应用，则可能突然出现短暂的卡顿，聊天应用所提供的服务被中断，聊天应用会闪退，如图1中的（b）所示，手机会显示桌面。在用户需再次使用聊天应用时，可重新开启聊天应用，手机可重新显示聊天应用的聊天窗口，如图1中的（c）所示，但原编辑聊天内容会丢失。

可见，应用程序更新时出现程序闪退，不仅影响用户的使用体验，还会影响用户对系统及应用程序稳定性能的评估。

发明内容

本申请提供一种程序数据更新方法、电子设备及计算机存储介质，程序更新过程避开了应用程序被使用期间。保障程序更新需求的同时，提高应用程序运行的稳定性。增强用户的使用体验。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请实施例提供一种程序数据更新方法，所述方法包括：在第一应用处于正在使用状态，且需要对第一程序数据进行更新的情况下，将所述第一程序数据对应的升级任务放入等待列表；获取所述第一应用的使用状态；所述第一程序数据是所述第一应用的程序文件，或是所述第一应用的公共组件的程序文件；在所述第一应用处于未使用状态的情况下，将所述升级任务从所述等待列表中取出；在所述升级任务的指示下，解析安装所述第一程序数据的更新数据包，以更新所述第一程序数据；或，在所述升级任务的指示下，根据第二程序数据更新所述第一程序数据；其中，所述第二程序数据是在第二存储区域内解析安装所述第一程序数据的更新数据包后得到的数据；所述第二存储区域与所述第一存储区域不同；所述第一存储区域为用于存储所述第一程序数据的存储区域。

在上述实施例中，在第一程序数据所对应的关联应用（也即，第一应用）处于正在使用状态的情况下，暂缓对第一程序数据的数据实体进行更新。在第一程序数据所对应的所有关联应用均处于未使用状态时，才执行第一程序数据的数据实体进行更新。从而，避免了程序数据升级与应用程序使用之间产生冲突。也改善了应用程序使用过程中受程序升级影响导致闪退的问题。提高用户的使用体验。

示例性地，可以在关联应用处于未使用状态的情况下，将对应的升级任务从等待列表中取出。然而，按照升级任务的指示下，解析安装第一程序数据的更新数据包，以更新第一程序数据。避免解析安装更新数据包时出现关闭关联应用的应用进程的现象。

示例性地，还可以在关联应用处于未使用状态的情况下，利用第二存储区域内已有的第二程序数据更新第一存储区域内的第一程序数据。也即，在关联应用处于未使用状态的情况下，直接利用已有的第二程序数据更替第一程序数据的数据实体，避免出现关闭关联应用的应用进程的现象。

结合第一方面，在一种可能的实现方式中，所述解析安装所述第一程序数据的更新数据包，包括：根据升级任务，获取所述第一程序数据的更新数据包；在第一存储区域内解析安装所述第一程序数据的更新数据包，以替换所述第一程序数据。

结合第一方面，在另一种可能的实现方式中，在第一应用处于正在使用状态，且需要对第一程序数据进行更新的情况下，所述方法还包括：在所述第二存储区域内解析安装所述第一程序数据的更新数据包，以得到所述第二程序数据。

在上述实施例中，通过预先在第二存储区域内解压第一程序数据的更新数据包，缩短更新第一程序数据的时耗。提高升级效率。

结合第一方面，在另一种可能的实现方式中，在所述更新数据包为全量数据包的情况下，所述根据第二程序数据更新所述第一程序数据，包括：采用所述第二程序数据，替换所述第一程序数据。

结合第一方面，在另一种可能的实现方式中，在所述更新数据包为增量数据包的情况下，所述根据第二程序数据更新所述第一程序数据，包括：将所述第二程序数据存储至所述第一存储区域，并与所述第一程序数据融合。

结合第一方面，在另一种可能的实现方式中，在所述更新数据包为全量数据包的情况下，所述根据第二程序数据更新所述第一程序数据，包括：

将所述第一程序数据的加载地址由所述第一存储区域的地址变更为所述第二存储区域的地址。

在上述实施例中，使更新第一程序数据的过程更加简单快速。提升了更新效率，避免长时间影响用户使用关联应用。

结合第一方面，在另一种可能的实现方式中，在所述更新数据包为增量数据包的情况下，所述根据第二程序数据更新所述第一程序数据，包括：将所述第一程序数据镜像至所述第二存储区域，并与所述第二程序数据融合；将所述第一程序数据的加载地址由所述第一存储区域的地址变更为所述第二存储区域的地址。

结合第一方面，在另一种可能的实现方式中，上述方法还包括：将第一存储区域内的所述第一程序数据删除。

在上述实施例中，有效地减少电子设备内数据的冗余。

结合第一方面，在另一种可能的实现方式中，将第一存储区域内的所述第一程序数据删除，包括：

所述第一应用在加载地址变更后的预设时长内未出现运行异常的情况下，删除所述第一存储区域内的所述第一程序数据。

结合第一方面，在另一种可能的实现方式中，所述方法还包括：

所述第一应用在加载地址变更后的预设时长内出现运行异常的情况下，将加载所述第一程序数据的加载地址恢复为所述第一存储区域的地址；清空所述第二存储区域。

在上述实施例中，实现异常回退保护，提升了应用程序的稳定性能。

结合第一方面，在另一种可能的实现方式中，获取所述第一应用的使用状态，包括：

周期性地重启获取所述第一应用的使用状态，直至所述第一程序数据的所有第一应用都处于未使用状态。

结合第一方面，在另一种可能的实现方式中，获取所述第一应用的使用状态，包括：

在检测到任一应用程序从正在使用状态切换为未使用状态的情况下，重启获取所述第一应用的使用状态。

结合第一方面，在另一种可能的实现方式中，在更新所述第一程序数据的过程中，所述方法还包括：

在所述第一应用的桌面图标上显示提示信息；或，在接收到用户对所述第一应用的图标的操作后，显示提示信息；

其中，所述提示信息用于提示以下信息中的至少一个：更新状态、更新进度、更新版本、更新发布时间。

在上述实施例中，通过提醒，改善用户在第一程序升级期间误操作关联应用的问题。也使用户能够更加了解更新信息。

结合第一方面，在另一种可能的实现方式中，所述方法还包括：在对第一程序数据升级完毕后，取消在所述第一应用的桌面图标上显示提示信息；或，在接收到用户对所述第一应用的图标的操作后，取消显示提示信息。

结合第一方面，在另一种可能的实现方式中，获取所述第一应用的使用状态，包括：

根据所述第一应用的运行状态，确定所述使用状态；

其中，所述运行状态包括前台运行，后台运行和停止运行；

在所述运行状态为所述前台运行的情况下，所述使用状态为正在使用状态；

在所述运行状态为所述停止运行的情况下，所述使用状态为未使用状态；

在所述运行状态为所述后台运行且显示多任务界面，或所述运行状态为所述后台运行且接收到用户对所述多任务界面中所述第一应用的界面的操作的情况下，所述使用状态为正在使用状态。

第二方面，本申请实施例提供一种电子设备，该电子设备包括一个或多个处理器和存储器；存储器与处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，所述一个或多个处理器，用于在第一应用处于正在使用状态，且需要对第一程序数据进行更新的情况下，将所述第一程序数据对应的升级任务放入等待列表；获取所述第一应用的使用状态；所述第一程序数据是所述第一应用的程序文件，或是所述第一应用的公共组件的程序文件；在所述第一应用处于未使用状态的情况下，将所述升级任务从所述等待列表中取出；在所述升级任务的指示下，解析安装所述第一程序数据的更新数据包，以更新所述第一程序数据；或，在所述升级任务的指示下，根据第二程序数据更新所述第一程序数据；其中，所述第二程序数据是在第二存储区域内解析安装所述第一程序数据的更新数据包后得到的数据；所述第二存储区域与所述第一存储区域不同；所述第一存储区域为用于存储所述第一程序数据的存储区域。

结合第二方面，在一种可能的实现方式中，所述一个或多个处理器，用于所述解析安装所述第一程序数据的更新数据包，包括：根据升级任务，获取所述第一程序数据的更新数据包；在第一存储区域内解析安装所述第一程序数据的更新数据包，以替换所述第一程序数据。

结合第二方面，在另一种可能的实现方式中，在第一应用处于正在使用状态，且需要对第一程序数据进行更新的情况下，所述一个或多个处理器，还用于：在所述第二存储区域内解析安装所述第一程序数据的更新数据包，以得到所述第二程序数据。

结合第二方面，在另一种可能的实现方式中，在所述更新数据包为全量数据包的情况下，所述一个或多个处理器，用于所述根据第二程序数据更新所述第一程序数据，包括：采用所述第二程序数据，替换所述第一程序数据。

结合第二方面，在另一种可能的实现方式中，在所述更新数据包为增量数据包的情况下，所述一个或多个处理器，用于所述根据第二程序数据更新所述第一程序数据，包括：将所述第二程序数据存储至所述第一存储区域，并与所述第一程序数据融合。

结合第二方面，在另一种可能的实现方式中，在所述更新数据包为全量数据包的情况下，所述一个或多个处理器，用于所述根据第二程序数据更新所述第一程序数据，包括：

将所述第一程序数据的加载地址由所述第一存储区域的地址变更为所述第二存储区域的地址。

结合第二方面，在另一种可能的实现方式中，在所述更新数据包为增量数据包的情况下，所述一个或多个处理器，用于所述根据第二程序数据更新所述第一程序数据，包括：将所述第一程序数据镜像至所述第二存储区域，并与所述第二程序数据融合；将所述第一程序数据的加载地址由所述第一存储区域的地址变更为所述第二存储区域的地址。

结合第二方面，在另一种可能的实现方式中，所述一个或多个处理器，还用于：将第一存储区域内的所述第一程序数据删除。

结合第二方面，在另一种可能的实现方式中，所述一个或多个处理器，用于将第一存储区域内的所述第一程序数据删除，包括：

所述第一应用在加载地址变更后的预设时长内未出现运行异常的情况下，删除所述第一存储区域内的所述第一程序数据。

结合第二方面，在另一种可能的实现方式中，所述一个或多个处理器，还用于：

所述第一应用在加载地址变更后的预设时长内出现运行异常的情况下，将加载所述第一程序数据的加载地址恢复为所述第一存储区域的地址；清空所述第二存储区域。

结合第二方面，在另一种可能的实现方式中，所述一个或多个处理器，用于获取所述第一应用的使用状态，包括：

周期性地重启获取所述第一应用的使用状态，直至所述第一程序数据的所有第一应用都处于未使用状态。

结合第二方面，在另一种可能的实现方式中，所述一个或多个处理器，用于获取所述第一应用的使用状态，包括：

在检测到任一应用程序从正在使用状态切换为未使用状态的情况下，重启获取所述第一应用的使用状态。

结合第二方面，在另一种可能的实现方式中，在更新所述第一程序数据的过程中，所述一个或多个处理器，还用于：

在所述第一应用的桌面图标上显示提示信息；或，在接收到用户对所述第一应用的图标的操作后，显示提示信息；

其中，所述提示信息用于提示以下信息中的至少一个：更新状态、更新进度、更新版本、更新发布时间。

结合第二方面，在另一种可能的实现方式中，所述一个或多个处理器，还用于：在对第一程序数据升级完毕后，取消在所述第一应用的桌面图标上显示提示信息；或，在接收到用户对所述第一应用的图标的操作后，取消显示提示信息。

结合第二方面，在另一种可能的实现方式中，所述一个或多个处理器，用于获取所述第一应用的使用状态，包括：

根据所述第一应用的运行状态，确定所述使用状态；

其中，所述运行状态包括前台运行，后台运行和停止运行；

在所述运行状态为所述前台运行的情况下，所述使用状态为正在使用状态；

在所述运行状态为所述停止运行的情况下，所述使用状态为未使用状态；

在所述运行状态为所述后台运行且显示多任务界面，或所述运行状态为所述后台运行且接收到用户对所述多任务界面中所述第一应用的界面的操作的情况下，所述使用状态为正在使用状态。

第三方面，本申请实施例提供一种计算机存储介质，该计算机存储介质包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如第一方面及其任一种可能的设计方式所述的方法。

第四方面，本申请实施例提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如第一方面及其任一种可能的设计方式所述的方法。

可以理解地，上述提供的第二方面及其任一种可能的设计方式所述的电子设备，第三方面所述的计算机存储介质，以及第四方面所述的计算机程序产品均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

附图说明

图1为相关技术中应用更新过程中，出现闪退的示例图；

图2为本申请实施例提供的手机的结构示意图；

图3为本申请实施例提供的手机的软件结构框图；

图4为本申请实施例提供的程序数据更新方法的步骤流程图之一；

图5为本申请实施例提供中单个应用程序处于前台运行的示例图；

图6为本申请实施例提供中多个应用程序处于前台运行的示例图之一；

图7为本申请实施例提供中多个应用程序处于前台运行的示例图之二；

图8为本申请实施例提供的触发开启多任务界面的方式示例图；

图9为本申请实施例提供的通过桌面图标显示提示信息的示例图之一；

图10为本申请实施例提供的通过桌面图标显示提示信息的示例图之二；

图11为本申请实施例提供的通过接收到用户对所述第一应用的图标的操作后，显示提示信息的示例图；

图12为本申请实施例提供的程序数据更新方法的步骤流程图之二；

图13为本申请实施例提供的程序数据更新方法的步骤流程图之三；

图14为本申请实施例提供的一种芯片系统的组成示意图。

具体实施方式

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

下面将结合附图对本实施例的实施方式进行详细描述。

本申请实施例提供一种程序数据更新方法，可以应用于电子设备内的程序更新过程中。

上述程序更新可以是对电子设备内的应用程序（application，APP）的程序文件进行更新。以电子设备为图1中的（b）所示的手机为例，手机内安装有地图APP、视频APP、打车APP等。那么上述程序更新可以是指对地图APP、视频APP或打车APP的程序文件进行更新。

上述程序更新还可以是对公共组件的程序文件进行更新。其中，上述公共组件可以是为电子设备中不同应用程序提供服务支持的程序组件。以常见的公共组件：谷歌移动服务（Google Mobile Service，gms）组件、webview组件、银联支付组件等举例，gms组件可以为图1中的（b）示出的手机内的地图APP、视频APP、打车APP等多类应用程序提供应用内购买、支付、位置信息、推送服务、广告、应用开发等服务支持。再比如，webview组件可以为手机内的地图APP、视频APP、打车APP等多类应用程序提供网页视图加载服务支持。再比如，银联支付组件可以为手机内的交易类APP提供支付服务支持。

上述应用程序和公共组件的程序文件，均可以称为程序数据。可以理解的，上述程序数据运行、更新都可以影响到至少一个应用程序。例如，应用程序的程序文件可以影响到该应用程序本身。再例如，公共组件的程序文件可以影响到所有使用了该公共组件的应用程序。

为了方便描述，可以将受程序数据影响的应用程序简称为该程序数据的关联应用。

相关技术下，在程序更新过程中，会强制关闭关联应用的应用进程。显然地，一旦关联应用的应用进程被关闭，关联应用向用户提供的服务将被中断。如果此时用户正在使用该关联应用，那么将会发生应用闪退，中断用户的使用，影响用户的使用体验。

换句话说，就是应用使用和程序更新之间发生了冲突。

为了解决应用使用和程序更新之间的冲突。避免用户正使用应用的过程中，由程序更新导致闪退。在本申请实施例提供的程序数据更新方法，通过将“程序数据的解析安装”和“关联应用的使用”错位进行，从而，降低程序更新与应用使用之间产生冲突的可能，提升应用程序的使用稳定性，也能增加用户对系统和应用程序的稳定性的认可。

在一些实施例中，上述“错位进行”可以是时间维度上的错位。也就是，将程序更新中的解析安装时间段与关联应用的使用时间段错开，从时间维度避免程序更新和应用使用之间出现冲突。

在另一些实施例中，上述“错位进行”还可以是空间维度的错位。上述空间可以是指存储空间。将程序更新中解析安装阶段所操作的存储空间和正在运行的程序数据的存储空间分开，避免文件覆盖现象而出现冲突，从而实现空间维度的错位进行。

可见，通过错位的方式进行更新，无需关闭用户正在使用的应用程序的进程。在保障用户体验的前提下，实现程序更新。

示例性的，本申请实施例中的电子设备可以是智能音箱、智能电视机、冰箱、洗衣机、空调、空气净化器、厨卫用品等家居设备。本申请实施例中的电子设备还可以是便携式计算机（如手机）、平板电脑、桌面型、膝上型、手持计算机、笔记本电脑、超级移动个人计算机（ultra-mobile personal computer，UMPC）、上网本，以及蜂窝电话、个人数字助理（personal digital assistant，PDA）、增强现实（augmented reality，AR）\虚拟现实（virtual reality，VR）设备、媒体播放器等设备，本申请实施例对该电子设备的具体形态不作特殊限制。

以电子设备为手机举例，图2示出了手机的结构示意图。

手机可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180等。

可以理解的是，本申请实施例示意的结构并不构成对手机的具体限定。在本申请另一些实施例中，手机可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

手机的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。手机中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在手机上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(lownoise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

无线通信模块160可以提供应用在手机上的包括无线局域网(wireless localarea networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequencymodulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，手机的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得手机可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(code divisionmultiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC ，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system ，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidounavigation satellite system，BDS)，准天顶卫星系统(quasi-zenith satellitesystem，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。

手机通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，手机可以包括1个或N个显示屏194，N为大于1的正整数。

手机可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。

摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，手机可以包括1个或N个摄像头193，N为大于1的正整数。

数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当手机在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

视频编解码器用于对数字视频压缩或解压缩。手机可以支持一种或多种视频编解码器。这样，手机可以播放或录制多种编码格式的视频，例如：动态图像专家组(movingpicture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展手机的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行手机的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储手机使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

手机可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。手机可以通过扬声器170A收听音乐，或收听免提通话。

受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当手机接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。

麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。手机可以设置至少一个麦克风170C。在另一些实施例中，手机可以设置两个麦克风170C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，手机还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准接口。

传感器模块180中可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等。

当然，手机还可以包括充电管理模块、电源管理模块、电池、按键、指示器以及1个或多个SIM卡接口等，本申请实施例对此不做任何限制。

上述手机的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明手机的软件结构。

图3是本申请实施例的手机的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图3所示，应用程序层中可以包括：通话，备忘录，浏览器，联系人，相机，图库，日历，地图，蓝牙，音乐，视频，短信息、桌面等APP（应用，application）。其中，上述应用可以是系统级应用；也可以是第三方应用。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图3所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，更新管理服务，资源管理器，通知管理器等。

其中，上述窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

上述内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

上述视图系统可用于构建应用程序的显示界面。每个显示界面可以由一个或多个控件组成。一般而言，控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、微件（Widget）等界面元素。

上述更新管理服务用来管理应用升级，为电子设备内安装的应用程序提供升级服务。上述更新管理服务是基于程序数据更新方法所创建的服务。上述更新管理服务工作于独立线程，上述更新管理服务由WorkManger管理后台任务，也即，后台状态下，在系统进程中运行。

上述资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

上述通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，振动，指示灯闪烁等。

如图3所示，系统库可以包括多个功能模块。例如：图层整合器(SurfaceFlinger)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。SurfaceFlinger用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如: MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2D图形引擎是2D绘图的绘图引擎。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

内核层是硬件和软件之间的层。内核层至少包含摄像头驱动，音频驱动，传感器驱动等，本申请实施例对此不做任何限制。

本申请实施例提供的程序数据更新方法可以在电子设备中实现，例如，由图2、图3示出的手机实现。

示例性地，如图4所示，上述程序数据更新方法可以包括以下步骤：

S101，获取第一程序数据对应的关联应用的运行状态。

在一些实施例中，电子设备侦测到程序更新需求的情况下，可以确定出具有更新需求的程序数据（也即，第一程序数据）。

示例性地，可以是电子设备检测到升级任务时，判定出现程序更新需求。其中，升级任务是用于指示更新的事项。升级任务中包括具有更新需求的程序数据的标签。（比如，包名）。不同的程序数据所对应的标签也不同，通过升级任务中携带的程序数据的标签，即可确定出第一程序数据。

当然，电子设备内可以同时存在多个升级任务。多个升级任务也可以确定出多个第一程序数据。然而，对于每一个第一程序数据的更新原理都相同。因此，为了方便描述，后续实施例主要以一个升级任务为例进行说明。

通常升级任务的生成与更新服务器是否发布更新数据包有关。可以理解的，上述更新服务器可以是用于发布更新数据包的服务器。示例性地，上述更新服务器可以是云端服务器，用于发布系统级程序（比如，系统级应用、公共组件）的更新数据包。示例性地，上述更新服务器还可以是第三服务器，用于发布第三方程序数据的更新数据包。

而上述更新数据包则是用于更新第一程序数据的数据包。在更新服务器发布了新的更新数据包的情况下，可以广播程序更新通知。其中，上述程序更新通知中可以包括第一标识，第一标识可以是第一程序数据的标签。

在一些实施例中，电子设备开启自动升级功能的情况下，若侦听到更新服务器发布的程序更新通知，则根据程序更新通知携带的第一标识，创建对应的升级任务。

在其他实施例中，电子设备未开启自动升级功能的情况下，电子设备也可以侦听更新服务器发布的通知。若侦听到程序更新通知，则由电子设备显示程序更新提醒，以征询用户是否具有更新意愿。如果用户通过交互操作向电子设备反馈了确认更新的指示，那么电子设备可以根据程序更新通知的第一标识，创建对应的升级任务。

示例性地，在可能的实施例中，还可以通过其他方式确定是否存在程序更新需求。

比如，电子设备内预先设定各个程序文件的升级周期，进入每个升级周期都会自触发程序更新需求。如此，只要检测到进入新的升级周期，即可判定具有程序更新需求。此外，确定具有程序更新需求后，向更新服务器请求升级。电子设备在接收到更新服务器反馈的更新数据包后，创建升级任务。

再比如，电子设备检测到程序文件多次运行异常的情况下，判定具有程序更新需求。此外，确定具有程序更新需求后，电子设备还需向更新服务器发送升级请求。其中，上述升级请求可以包括异常描述信息。电子设备在接收到更新服务器针对升级请求反馈的更新数据包后，创建升级任务。

创建升级任务之后，电子设备还可以获取第一程序数据所对应的关联应用（又可称为第一程序数据的第一应用）的运行状态。例如，第一程序数据为聊天APP的程序文件，那么获取聊天APP的运行状态。再例如，第一程序数据为gms组件的程序文件，电子设备中使用gms组件的应用程序包括地图APP、视频APP、打车APP，那么电子设备还获取地图APP、视频APP、打车APP的运行状态。

上述运行状态是指应用程序在电子设备中的实际工作状态，比如，上述运行状态可以分为前台运行、后台运行及停止运行。

其中，在电子设备内，前台运行和后台运行的应用程序都有对应的应用进程，而停止运行的应用程序却没有。

因此，可以通过检测关联应用是否具有进程，判定该关联应用的运行状态是否属于停止运行。

在一些实施例中，在判定关联应用的运行状态不是停止运行的情况下，还需分辨关联应用处于前台运行还是后台运行。而分辨关联应用处于前台运行还是后台运行，可以采用电子设备中已有的服务实现。比如，通过UsageStatsManager实现。

另外，处于前台运行的应用程序，可以直接向用户提供相应的服务。

以图5为例，图5中电子设备以手机的形态示出，在手机中的视频APP处于前台运行的情况下，用户可以直接观看视频APP所提供的视频播放服务。

再例如，电子设备是智能音箱情况下，音乐APP处于前台运行的情况下，智能音箱可以通过音乐APP向用户播放音乐。

此外，电子设备内可以存在一个或多个处于前台运行的应用程序。

比如，图6示出的场景，手机中的音乐APP正在播放音乐，同时，手机的显示屏展示着阅读APP提供的阅读内容。在此场景下，手机内的音乐APP和阅读APP都是处于前台运行的应用程序。

再比如，图7示出的场景，手机中聊天APP向用户提供聊天服务，同时，手机还在显示屏内开辟小窗口展示视频APP提供的视频内容。在此场景下，手机内的聊天APP和阅读APP都是处于前台运行的应用程序。

基于以上描述的前台运行的运行特点，在另一些实施例中，在判定关联应用的运行状态不是停止运行的情况下，还可以通过捕获关联应用的输出动作，结合关联应用提供的服务类型，分析关联应用是否处于前台运行。

示例性地，通过分析关联应用是否调用输出驱动（比如，音频驱动）、输出类服务（比如，视图系统），结合关联应用的服务特点，分析关联应用是否属于前台运行。

比如，对于画面输出类的应用程序，诸如聊天APP、视频APP一类应用程序，检测到该类应用程序调用了视图系统，在电子设备的显示屏渲染了应用界面，那么判断该类应用程序处于前台运行。

再如，对于输出声音类的应用程序，诸如音乐APP一类应用程序，检测到该类应用程序调用了音频系统，那么判断该类应用程序处于前台运行。

S102，根据关联应用的运行状态，确定对应的使用状态。

在一些实施例中，关联应用的使用状态可以通过关联应用的运行状态分析得到。

与运行状态不同，上述使用状态是表征应用程序向用户提供服务的状态。示例性地，使用状态可以分为未使用状态和正在使用状态。在一个应用程序处于正在使用状态时，表征用户当前对该应用程序具有使用需求。在一个应用程序处于未使用状态时，表征用户当前对该应用程序不具有使用需求。

可以理解的，前台运行的应用程序，实际上也处于正在向用户提供相应的服务的状态。故，可以将处于前台运行的关联应用判定为处于正在使用状态。

此外，应用程序处于停止运行时，没有对应的应用进程，也无法向用户提供相应的服务的状态。故，可以将处于停止运行的关联应用判定为处于未使用状态。

示例性地，根据运行状态，分析关联应用的使用状态的方式可以包括以下几种：

方式一，可以在关联应用的运行状态为停止运行的情况下，判定关联应用处于未使用状态。在关联应用的运行状态为前台运行或后台运行的情况下，判定关联应用处于正在使用状态。

方式二，可以在关联应用的运行状态为停止运行或后台运行的情况下，判定关联应用处于未使用状态。在关联应用的运行状态为前台运行的情况下，判定关联应用处于正在使用状态。

其中，方式一考虑到处于后台运行的应用程序（简称：后台应用）随时可能被切换到前台运行。示例场景，用户正在使用电子设备内的游戏APP的过程中，临时切入聊天APP看朋友所发信息内容。此时，游戏APP将暂时的被切换到后台运行。待用户看完信息内容后，会立刻切回游戏APP中，使游戏APP再次恢复到前台运行。在此过程中，游戏APP从后台运行切换到前台运行之间的时耗较短。

而，方式二考虑到后台应用当前并没有提供服务，并且大部分后台应用会被用户长时间滞留后台，导致后台应用处于长时间不被使用。示例场景，用户使用完电子设备内的阅读APP后，并未彻底关闭阅读APP，而是让他进入后台运行。此后，用户使用电子设备中的其他APP，接受其他APP所提供的服务，不再切回阅读APP。从而使阅读APP长期处于后台运行，使阅读APP长期不被使用。

显然，方式一和方式二是基于不同的角度所设计的判定规则，各具优势。本领域技术人员在实际使用过程中，可以根据实际情况进行选择。

此外，为了提高对后台应用的使用状态的准确判断，根据运行状态分析使用状态的方式还可以包括：

方式三，可以在关联应用的运行状态为停止运行情况下，判定关联应用处于未使用状态。在关联应用进入后台运行的时长超过指定值时，判定关联应用处于未使用状态。在关联应用进入后台运行的时长不超过指定值时，判定关联应用处于正在使用状态。在关联应用的运行状态为前台运行情况下，判定关联应用处于正在使用状态。

在一些实施例中，上述指定值的取值可以是预设的经验值。

方式四，在关联应用的运行状态为停止运行情况下，判定关联应用处于未使用状态。在关联应用的运行状态为前台运行情况下，判定关联应用处于正在使用状态。在关联应用的运行状态为后台运行时，判断用户是否正在查看后台应用。在判定用户正在查看后台应用的情况下，判定关联应用处于正在使用状态。反之，则判定处于未使用状态。

在一些实施例中，电子设备判断用户是否正在查看后台应用的方式可以是以下之一或之间的组合：

（1）在电子设备接收到后台查看触发操作时，判定用户正在查看后台应用。比如，在桌面上做出上滑是查看后台的操作。如图8中的（a）所示，电子设备在接收到用户在桌面上做出上滑操作后，可判定用户正在查看后台应用。

（2）在显示屏上展示多任务界面期间，判定用户正在查看后台应用。多任务界面中包括在电子设备后台运行的应用程序的界面。多任务界面后台应用的界面可以是界面缩略图。比如，界面缩略图可以是上述后台应用进入后台运行前显示的最后一帧界面。比如，结合图8中的（a）中所示的示例，作为对上滑操作的响应，如图8中的（b）所示，电子设备可以显示多任务界面，在电子设备显示多任务界面期间，可判定用户正在查看后台应用。

（3）在电子设备接收到滑动后台应用的界面缩略图的操作时，判定用户正在查看后台应用。

以上基于运行状态分析使用状态的方式，本领域技术人员可以根据实际需求选择。

除了基于运行状态分析对应的使用状态之外，在其他实施例中，还可以结合电子设备的设备状态分析关联应用的使用状态。

示例性地，上述设备状态可以包括待机状态和息屏状态。其中，上述待机状态可以是电子设备处于开机但是不进行任何实质性工作（即不对文件和程序的各种操作）的状态。上述息屏状态可以是电子设备的显示屏不显示任何实质性图像内容的状态。比如，在显示屏显示黑屏界面、白屏界面或者屏保图像的情况下，判定电子设备处于息屏状态。

在一些实施例中，若电子设备处于待机状态和/或息屏状态，可以将电子设备中的所有应用程序所对应的使用状态为未使用状态，也即，关联应用处于未使用状态。反之，可以根据运行状态，判定关联应用所处的使用状态。

在其他实施例中，在需要对第一程序数据进行更新的情况下，也可以不按照上述S101和S102获取关联应用的使用状态。而是，直接获取到关联应用的使用状态。例如，向用户询问是否使用关联应用的方式确定关联应用的使用状态。再例如，还可以从其他程序获取关联应用的使用状态。其中，其他程序为用于监控电子设备内应用程序的使用状态的程序。

S103，在第一程序数据的至少一个关联应用处于正在使用状态时，按照错位升级策略，对第一程序数据进行更新升级。

示例性地，第一程序数据为应用程序的程序文件的情况下，可以是在该应用程序自身还处于正在使用状态时，按照错位升级策略，利用更新数据包对第一程序数据进行更新升级。比如，第一程序数据为聊天APP的程序文件，在聊天APP还处于正在使用状态时，按照错位升级策略，利用更新数据包对第一程序数据进行更新升级。

示例性地，第一程序数据为公共组件的程序文件的情况下，可以是在使用了该公共组件的应用程序中至少一个处于正在使用状态时，按照错位升级策略，利用更新数据包对第一程序数据进行更新升级。比如，第一程序数据为gms组件的程序文件，且电子设备中使用gms组件的应用程序包括地图APP、视频APP、打车APP。在地图APP、视频APP、打车APP中至少一个还处于正在使用状态时，按照错位升级策略，利用更新数据包对第一程序数据进行更新升级。

其中，上述更新数据包可以由更新服务器提供。在一些实施例中，电子设备可以创建升级任务后，从更新服务器中下载对应的更新数据包。

在关联应用处于正在使用状态，且需要对第一程序数据进行更新的情况下，如果按照相关技术，直接对第一程序数据进行更新，会影响到用户对关联应用的使用，导致关联应用出现闪退。

而本申请实施例中，在关联应用处于正在使用状态，且需要对第一程序数据进行更新的情况下，按照错位升级策略对第一程序数据进行更新，从而避免处于正在使用状态的关联应用受升级的影响。

可以采用多种方式实现“错位升级策略”。当然，无论采用何种方式实现，更新第一程序数据的数据实体的前提是：已判定关联应用都进入了未使用状态。故，实现“错位升级策略”会涉及到将对应的升级任务放入等待列表中，重新获取关联应用的使用状态。在关联应用处于未使用状态的情况下，才对第一程序数据的数据实体进行更新。

在一些实施例中，上述错位升级策略可以是：按照时间错位的方式对第一程序数据进行更新。

示例性地，上述按照时间错位的方式对第一程序数据进行更新的过程可以是：将第一程序数据对应的升级任务放入等待列表中。将从更新服务器中获取到的更新数据包缓存。在第一程序数据对应的关联应用都变为未使用状态的情况下，将第一程序数据所对应的升级任务从等待列表中取出。依据升级任务的指示，获取缓存的更新数据包并进行解析安装处理，以更新第一程序数据。

可理解地，升级任务中具有第一程序数据的第一标识。同时，由于更新数据包用于更新第一程序数据，其也可以携带第一程序数据的标识。可见，升级任务与更新数据包之间存在关联。通过升级任务中第一标识即可从电子设备内查询到对应的更新数据包。

另外，对更新数据包进行解析安装处理可以是在存储区域1（也即，第一存储区域）中直接对更新数据包进行解析安装。

此外，在第一程序数据更新期间，还需提醒用户暂时不要使用关联应用。

在一些实施例中，可以通过广播报文1通知桌面，刷新关联应用的桌面图标，以使刷新后的桌面图标可以提示用户暂停使用。也即，通过关联应用的桌面图标显示提示信息。

其中，广播报文1包括第一程序数据的更新提示参数。

此外，还可以根据广播报文1，关闭关联应用的启动触发接口，使关联应用不能被点开，避免用户在第一程序数据更新过程中误开启关联应用。

在一些实施例中，广播报文1可以设置有系统访问权限，以使作为系统级应用的桌面才有权限读取广播报文1。避免广播报文1对其他应用程序产生影响。

另外，示例性地，更新提示参数可以是表征第一程序数据处于正在更新状态的参数。待桌面接收到该广播报文1后，将关联应用的桌面图标上增加更新标识（也即，提示信息）。比如，图9所示，图9中的聊天APP是第一程序数据的关联应用，在桌面接收到关于第一程序数据的广播报文1后，聊天APP的桌面图标刷新为添加有更新标识的桌面图标。

示例性地，更新提示参数还可以是包括第一程序数据的更新进度。上述通过广播报文1通知桌面可以是：周期性地根据第一程序数据的更新进度创建广播报文1，并广播。桌面每接收到一广播报文1，便根据广播报文1，在关联应用的桌面图标上增加更新进度（也即，提示信息）。比如，图10所示，图10中的视频APP是第一程序数据的关联应用。第一程序数据在第一时刻下，更新进度达到20%。在桌面接收到第一时刻创建的广播报文1后，在视频APP的桌面图标下会显示更新进度为20%。第一程序数据在第二时刻下，更新进度达到80%。在桌面接收到第二时刻创建的广播报文1后，在视频APP的桌面图标下会显示更新进度为80%。

在另一些实施例中，在通过广播报文1通知桌面后，也可以不对桌面图标的形态进行改变。在接到广播报文1后，关闭关联应用的启动触发接口，使关联应用不能被点开。之后，侦测到关联应用的桌面图标被用户点击，可以弹出通知框。通过通知框向用户展示广播报文1中的更新提示参数。

也即，接收到用户对所述第一应用的图标的操作后，显示提示信息。

其中，上述更新提示参数可以包括但不限于包括正在更新状态、更新进度、更新版本、更新发布时间等信息之一或之间的组合。比如，图11中的（a）所示出的支付APP是第一程序数据的关联应用。在桌面接收到广播报文1后，侦测到用户点击支付APP，那么如图11中的（b）所示弹出通知框，展示对应的更新提示参数。

显然地，在更新提示参数中的更新进度是一个动态变化的量。上述更新进度可以是侦测到用户点击关联应用时第一程序数据的更新进度。当然，第一程序数据的更新进度的采集时间点和用户点击关联应用的时间点也可以不是绝对的对齐。比如，更新进度的采集时间点可以稍晚于用户点击关联应用的时间点。

当然，也为了避免第一程序数据更新结束后，关联应用持续受广播报文1的影响。待第一程序数据完成更新后，还可以通过广播报文2通知桌面，取消对关联应用的桌面图标的变更。比如，取消关联应用的桌面图标上的更新标识。再比如，取消点击关联应用弹出通知框。再比如，恢复关联应用的启动触发接口，使用户可以通过点击桌面图标启动使用关联应用。

也即，如图12所示，在图4所示的程序数据更新方法的基础上，上述S103可以包括：

S103-1，将第一程序数据对应的升级任务放入等待列表。暂不执行第一程序数据对应的升级任务。

S103-2，监测第一程序数据的关联应用是否都处于未使用状态。

如果第一程序数据的关联应用都处于未使用状态，流程进入S103-3。如果第一程序数据的关联应用不是全处于未使用状态，那么继续监测第一程序数据的关联应用所处的使用状态。

S103-3，在判定第一程序数据对应的关联应用处于未使用状态的情况下，将升级任务从等待列表中取出，并执行。

在一些实施例中，执行升级任务过程可以是：依据升级任务中的第一标识，从缓存区域中获取第一程序数据所对应的更新数据包。并在存储区域1中对更新数据包进行解析安装，实现对第一程序数据的更新。

在一些实施例中，在启动对升级任务的执行时，流程进入S103-4。

S103-4，通知桌面变更关联应用的桌面图标。

在一些实施例中，可以是通过广播报文通知桌面将关联应用的桌面图标进行变更。具体可参照前述实施例中的描述。

总体而言，按照时间错位的方式进行分为两个阶段。其中，第一阶段为对更新数据包进行解析安装之前，需等待关联应用都切换至未使用状态。第二阶段为更新数据包的解析安装过程中，避免用户在解析安装期间使用关联应用。

实现时间错位的关键在于第一阶段。也即，在对更新数据包进行解析安装之前，第一程序数据对应的关联应用都需要处于未使用状态。

作为一种实现方式，可以通过定期查询的方式，判断第一程序数据对应的关联应用是否处于未使用状态。

在等待列表中存在多个升级任务的情况下，可以循环遍历等待列表中的每一个升级任务。在循环遍历的过程中，每遍历到一个升级任务，依据该升级任务指示的第一程序数据，获取对应的关联应用的使用状态。从而判定第一程序数据对应的关联应用是否处于未使用状态。

作为另一种实现方式，对电子设备内处于正在使用状态的应用程序进行监控。在处于正在使用状态的应用程序切换为未使用状态的情况下，触发检测第一程序数据所对应的关联应用是否都处于未使用状态。

除了按照时间错位的方式更新第一程序数据外，为了提高更新效率，在本申请实施例中，上述错位升级策略可以是按照存储空间错位的方式对第一程序数据进行更新。

示例性地，上述按照存储空间错位的方式对第一程序数据进行更新的过程可以是：

将第一程序数据对应的升级任务放入等待列表中。

在存储区域2（又称为第二存储区域）内，对第一程序数据对应的更新数据包进行解析安装。通过解析安装创建临时安装目录。其中，临时安装目录内存放有更新程序数据，又称为第二程序数据。上述更新程序数据用于更替第一程序数据的数据实体。

需说明的是，上述存储区域2与存储区域1不同。其中，存储区域1是用于存储第一程序数据的存储空间。在一些实施例中，第一程序数据可以存放在存储区域1中的固定安装目录下。

示例性地，固定安装目录和临时安装目录都可以包括命名为“/data/dalvik-cache”、“package.xml”、“package.list”等子目录。其中，子目录/data/dalvik-cache用于存放应用代码执行文件（如dex、oat文件），子目录package.xml用于存放应用申请的权限、签名和代码所在的位置等信息。子目录package.list用于记录应用安装位置等信息。

在一些实施例中，上述存储区域2可以是预先为第一程序数据分配的备用存储区域。在另一些实施例中，上述存储区域2还可以是执行升级任务时，从空闲的存储空间中为第一程序数据划分出的存储区域。

由于存储区域1和存储区域2是不同的存储空间，因此，在解析安装更新数据包时，无需强制关闭关联应用的应用进程。从而，避免更新数据包的解析安装过程影响到用户使用关联应用。

在更新数据包解析安装于存储区域2后，将得到的临时安装目录与第一程序数据关联上。例如，通过用户身份证明（User Identification，UID）将临时安装目录与第一程序数据关联。如此，也使临时安装目录下的更新程序数据与第一程序数据关联上。同时，升级任务与第一程序数据之间也存在对应关系。故，升级任务与临时安装目录下的更新程序数据之间也就建立起对应关系。

之后，还需要监控第一程序数据对应的关联应用是否都切换到未使用状态，也即，重复获取关联应用的使用状态。若第一程序数据对应的关联应用都切换到未使用状态，将对应的升级任务从等待列表中取出。依据升级任务的指示，获取与第一程序数据关联的更新程序数据。再利用更新程序数据替换第一程序数据的数据实体。从而，完整地完成对第一程序数据的更新。

也就是，本申请实施例中，可以是在第一程序数据对应的关联应用都切换到未使用状态的时刻，对第一程序数据的数据实体进行更新。

在一些实施例中，可以周期性地重启对关联应用的使用状态的判断，直至第一程序数据的所有关联应用都处于未使用状态。

在另一些实施例中，也可以是受电子设备内出现应用程序从正在使用状态切换为未使用状态的触发，检测第一程序数据的关联应用是否都处于未使用状态。

此外，在一些实施例中，采用更新程序数据更替第一程序数据的数据实体的方式可以是将更新程序数据存储至存储区域1，并覆盖第一程序数据。另外，更新程序数据转移后，存储区域2也随之清空。

上述覆盖式更新，适用于更新数据包为全量数据包的场景。在更新数据包为增量数据包的情况下，将更新数据包解析后，也可得到更新程序数据。但，此场景下的更新程序数据又可成为增量程序数据。

此情况下，上述更替第一程序数据的数据实体的方式还可以是：将增量程序数据移动至存储区域1，与第一程序数据进行融合，以完成对第一程序数据的更新。

其中，全量数据包被解析后可以得到完全替代第一程序数据的更新数据。而增量数据包是解析后需要与原第一程序数据融合，才能得到完全替代第一程序数据的更新数据。

在一些实施例中，将增量程序数据与原第一程序数据进行融合可以理解为利用增量程序数据对原第一程序数据进行增、删和替换中的至少一项操作。概念性地示例，如果增量程序数据指示对原第一程序数据中部分数据的修改，那么将增量程序数据替换原第一程序数据中被修改的部分数据。如果增量程序数据指示增加原第一程序数据的数据内容，那么将增量程序数据并入第一程序数据。如果增量程序数据是指示对原第一程序数据中部分数据进行删除，那么将被指示的部分数据从第一程序数据中删除。

在利用更新程序数据更新第一程序数据的数据实体的过程中，由于需要对第一程序数据的数据实体处理，故，处理期间也需要提示用户暂停使用关联应用。提醒用户暂停使用关联应用的方式，可以是参考前述实施例中提到的广播报文通知的方式，在此不再赘述。

除此之外，待第一程序数据完成更新后，也可以通过广播报文2通知桌面，取消对关联应用的暂停使用提示。具体实现可参考前述实施例中的描述。

当然，在另一些实施例中，为了缩短用户需要等待第一程序数据的数据实体被更新的时长，在更新数据包为全量数据包的情况下，将更新数据包解析安装于存储区域2后，直接将关联应用加载第一程序数据的加载地址更换为存储区域2的地址。如此，下一次启动关联应用则可以直接加载存储区域2中的更新程序数据。换句话说，再次启动关联应用时，原来的临时安装目录变为新的固定安装目录。

在更新数据包为增量数据包的情况下，将更新数据包解析安装于存储区域2后，还需要将第一程序数据镜像到存储区域2，并与增量数据包融合。完成数据融合之后，再将关联应用加载第一程序数据的加载地址更换为存储区域2的地址。

此后，还可以将原来的固定安装目录删除，以释放出冗余的存储空间。

当然，在一些其他的实施例中，变更加载地址后，还可以将原来的固定安装目录的第一程序数据保留指定时长。在指定时长内，持续监测关联应用是否运行异常。

其中，上述运行异常可以是加载第一程序数据时出现的异常。比如，第一程序数据为应用程序的程序文件时，若关联应用出现程序无法启动或者程序报错次数超过预设值，则判定出现运行异常。再比如，第一程序数据为公共组件的程序文件时，若出现关联应用调用公共组件时出现异常，则判定出现运行异常。

如果指定时长内关联应用存在运行异常的问题，那么再将关联应用加载第一程序数据的加载地址恢复为存储区域1的地址，并清除存储区域2内的程序数据。

如果指定时长内关联应用未出现运行异常，那么将第一存储区域下的第一程序数据删除。

作为一个示例，如图13所示，在图4所示的程序数据更新方法的基础上，上述S103可以包括：

S103-5，在存储区域2内，解析安装更新数据包。通过解析安装更新数据包，得到更新程序数据。

S103-6，将更新程序数据与第一程序数据关联。

S103-7，监控第一程序数据的关联应用的使用状态。

在第一程序数据的关联应用都处于未使用状态的情况，流程进入S103-8。否则，继续执行S103-7。

S103-8，利用关联的更新程序数据更新第一程序数据的数据实体。

此外，在执行S103-8期间，还需要执行S103-9。

S103-9，通知桌面变更关联应用的桌面图标。

在一些实施例中，S103-8与S103-4的原理相同，在此不再赘述。

显然地，无论采取何种错位升级策略，都避免了关闭处于正在使用状态下的关联应用。避免关联应用在用户使用期间出现闪退。从而，解决了应用使用和程序更新之间的冲突。

S104，在关联应用处于未使用状态时，基于更新数据包，直接对第一程序数据进行更新。

在一些实施例中，可以是直接将更新数据包解析安装到存储区域1，用于更新固定安装目录中的第一程序数据。在解析安装期间，也可以通过广播报文1，提醒用户暂停使用关联应用。同样地，在第一程序数据更新结束后，也可以通过广播报文2，取消暂停使用提醒。

另外，无论是S103中按照错位升级策略对第一程序数据进行更新，还是S104中直接对第一程序数据进行更新，还需要考虑电子设备的自身条件是否适合进行更新。

示例性地，执行S103或S104之前，可以查看电子设备是否具有更新的存储空间要求。如果满足，继续执行S103或S104。反之，则不执行。

示例性地，执行S103或S104之前，还可以查看电子设备的剩余电量是否支持完成更新。如果剩余电量足够支持完成更新，那么继续执行S103或S104。反之，则不执行。当然，判定电子设备的剩余电量是否支持完成更新的方式，可以是将剩余电量与升级电量下限值进行比较。如果剩余电量低于预设的电量下限值，那么判定剩余电量不支持完成更新。如果剩余电量不低于预设的电量下限值，那么判定剩余电量支持完成更新。

示例性地，执行S103和S104之前，还可以查看电子设备是否处于充电状态。如果处于充电状态，那么继续执行S103或S104。反之，则不执行。

本申请实施例还提供一种电子设备，该电子设备可以包括：显示屏、存储器和一个或多个处理器。该显示屏、存储器和处理器耦合。该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令。当处理器执行计算机指令时，可使得电子设备执行上述实施例中手机执行的各个步骤。当然，该电子设备包括但不限于上述显示屏、存储器和一个或多个处理器。例如，该电子设备的结构可以参考图2所示的手机的结构。

本申请实施例还提供一种芯片系统，该芯片系统可以应用于前述实施例中的电子设备。如图14所示，该芯片系统包括至少一个处理器2201和至少一个接口电路2202。该处理器2201可以是上述电子设备中的处理器。处理器2201和接口电路2202可通过线路互联。该处理器2201可以通过接口电路2202从上述电子设备的存储器接收并执行计算机指令。当计算机指令被处理器2201执行时，可使得电子设备执行上述实施例中手机执行的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。

Claims (21)

1.一种程序数据更新方法，其特征在于，所述方法包括：

获取公共组件的更新数据包，所述公共组件包括谷歌移动服务组件、webview组件、银联支付组件；

确定与所述公共组件相关联的多个第一应用，其中，所述相关联的应用程序是指调用所述公共组件的应用程序；

获取所述多个第一应用的运行状态，所述运行状态包括前台运行，后台运行和停止运行；依据所述运行状态，获取所有的所述第一应用的使用状态；其中，所述使用状态包括：正在使用状态和未使用状态；在所述运行状态为所述前台运行的情况下，所述使用状态为正在使用状态；在所述运行状态为所述后台运行且显示多任务界面，或所述运行状态为所述后台运行且接收到用户对所述多任务界面中所述第一应用的界面的操作的情况下，所述使用状态为正在使用状态；

在至少一个所述第一应用处于正在使用状态的情况下，将所述公共组件对应的升级任务放入等待列表；

再次获取所有的所述第一应用的使用状态；

在所有的所述第一应用处于未使用状态的情况下，基于所述公共组件的更新数据包，对公共组件进行升级；所述对公共组件进行升级包括：解析安装所述公共组件的更新数据包，以更新所述公共组件；或，根据第二程序数据更新所述公共组件；其中，所述第二程序数据是在第二存储区域内解析安装所述公共组件的更新数据包后得到的数据；所述第二存储区域与第一存储区域不同；所述第一存储区域为用于存储所述公共组件的存储区域。

2.如权利要求1所述的方法，其特征在于，所述解析安装所述公共组件的更新数据包，包括：

在第一存储区域内解析安装所述更新数据包，以替换所述公共组件。

3.如权利要求1所述的方法，其特征在于，在第一应用处于正在使用状态，且获取到公共组件的更新数据包的情况下，所述方法还包括：

在所述第二存储区域内解析安装所述更新数据包，以得到所述第二程序数据。

4.如权利要求1所述的方法，其特征在于，在所述更新数据包为全量数据包的情况下，所述根据第二程序数据更新所述公共组件，包括：

采用所述第二程序数据，替换所述公共组件。

5.如权利要求1所述的方法，其特征在于，在所述更新数据包为增量数据包的情况下，所述根据第二程序数据更新所述公共组件，包括：

将所述第二程序数据存储至所述第一存储区域，并与所述公共组件融合。

6.如权利要求1所述的方法，其特征在于，在所述更新数据包为全量数据包的情况下，所述根据第二程序数据更新所述公共组件，包括：

将所述公共组件的加载地址由所述第一存储区域的地址变更为所述第二存储区域的地址。

7.如权利要求1所述的方法，其特征在于，在所述更新数据包为增量数据包的情况下，所述根据第二程序数据更新所述公共组件，包括：

将所述公共组件镜像至所述第二存储区域，并与所述第二程序数据融合；

将所述公共组件的加载地址由所述第一存储区域的地址变更为所述第二存储区域的地址。

8.如权利要求6或7所述的方法，其特征在于，所述方法还包括：

所述第一应用在加载地址变更后的预设时长内未出现运行异常的情况下，删除所述第一存储区域内的所述公共组件。

9.如权利要求6或7所述的方法，其特征在于，所述方法还包括：

所述第一应用在加载地址变更后的预设时长内出现运行异常的情况下，将加载所述公共组件的加载地址恢复为所述第一存储区域的地址；

清空所述第二存储区域。

10.如权利要求1-7任意一项所述的方法，其特征在于，在更新所述公共组件的过程中，所述方法还包括：

在所述第一应用的桌面图标上显示提示信息；或，

在接收到用户对所述第一应用的图标的操作后，显示提示信息；

其中，所述提示信息用于提示以下信息中的至少一个：更新状态、更新进度、更新版本、更新发布时间。

11.一种电子设备，其特征在于，电子设备包括一个或多个处理器和存储器；存储器与处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，

所述一个或多个处理器，用于获取公共组件的更新数据包，所述公共组件包括谷歌移动服务组件、webview组件、银联支付组件；确定与所述公共组件相关联的多个第一应用，其中，所述相关联的应用程序是指调用所述公共组件的应用程序；获取所述多个第一应用的运行状态，所述运行状态包括前台运行，后台运行和停止运行；依据所述运行状态，获取所有的所述第一应用的使用状态；其中，所述使用状态包括：正在使用状态和未使用状态；在所述运行状态为所述前台运行的情况下，所述使用状态为正在使用状态；在所述运行状态为所述后台运行且显示多任务界面，或所述运行状态为所述后台运行且接收到用户对所述多任务界面中所述第一应用的界面的操作的情况下，所述使用状态为正在使用状态；在至少一个所述第一应用处于正在使用状态的情况下，将所述公共组件对应的升级任务放入等待列表；再次获取所有的所述第一应用的使用状态；在所有的所述第一应用处于未使用状态的情况下，基于所述公共组件的更新数据包，对公共组件进行升级；所述对公共组件进行升级包括：解析安装所述公共组件的更新数据包，以更新所述公共组件；或，根据第二程序数据更新所述公共组件；其中，所述第二程序数据是在第二存储区域内解析安装所述公共组件的更新数据包后得到的数据；所述第二存储区域与第一存储区域不同；所述第一存储区域为用于存储所述公共组件的存储区域。

12.如权利要求11所述的电子设备，其特征在于，所述一个或多个处理器，用于所述解析安装所述公共组件的更新数据包，包括：

在第一存储区域内解析安装所述公共组件的更新数据包，以替换所述公共组件。

13.如权利要求11所述的电子设备，其特征在于，在第一应用处于正在使用状态，且获取到所述公共组件的更新数据包的情况下，所述一个或多个处理器，还用于：

在所述第二存储区域内解析安装所述公共组件的更新数据包，以得到所述第二程序数据。

14.如权利要求11所述的电子设备，其特征在于，在所述更新数据包为全量数据包的情况下，所述一个或多个处理器，用于所述根据第二程序数据更新所述公共组件，包括：

采用所述第二程序数据，替换所述公共组件。

15.如权利要求11所述的电子设备，其特征在于，在所述更新数据包为增量数据包的情况下，所述一个或多个处理器，用于所述根据第二程序数据更新所述公共组件，包括：

将所述第二程序数据存储至所述第一存储区域，并与所述公共组件融合。

16.如权利要求11所述的电子设备，其特征在于，在所述更新数据包为全量数据包的情况下，所述一个或多个处理器，用于所述根据第二程序数据更新所述公共组件，包括：

将所述公共组件的加载地址由所述第一存储区域的地址变更为所述第二存储区域的地址。

17.如权利要求11所述的电子设备，其特征在于，在所述更新数据包为增量数据包的情况下，所述一个或多个处理器，用于所述根据第二程序数据更新所述公共组件，包括：

将所述公共组件镜像至所述第二存储区域，并与所述第二程序数据融合；

将所述公共组件的加载地址由所述第一存储区域的地址变更为所述第二存储区域的地址。

18.如权利要求16或17所述的电子设备，其特征在于，所述一个或多个处理器，还用于：

所述第一应用在加载地址变更后的预设时长内未出现运行异常的情况下，删除所述第一存储区域内的所述公共组件。

19.如权利要求16或17所述的电子设备，其特征在于，所述一个或多个处理器，还用于：

所述第一应用在加载地址变更后的预设时长内出现运行异常的情况下，将加载所述公共组件的加载地址恢复为所述第一存储区域的地址；

清空所述第二存储区域。

20.如权利要求11-17任意一项所述的电子设备，其特征在于，在更新所述公共组件的过程中，所述一个或多个处理器，还用于：

在所述第一应用的桌面图标上显示提示信息；或，

在接收到用户对所述第一应用的图标的操作后，显示提示信息；

其中，所述提示信息用于提示以下信息中的至少一个：更新状态、更新进度、更新版本、更新发布时间。

21.一种计算机存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-10中任一项所述的方法。