CN117707753A - 资源更新控制方法、电子设备及芯片系统 - Google Patents

Abstract

本申请实施例公开了一种资源更新控制方法、电子设备及芯片系统，适用于计算机技术领域，该方法包括：在检测到对应用程序的目标操作时，确定出目标操作关联的若干个待更新资源。分析在目标操作下，各个待更新资源的内容是否会发生变化。对于待更新资源中内容不会发生变化的资源，不进行资源更新。对于待更新资源中内容会发生变化的资源，进行资源更新。本申请实施例可以减少在响应对应用程序的操作过程中，更新资源所给处理器带来的负载。

Description

资源更新控制方法、电子设备及芯片系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种资源更新控制方法、电子设备及芯片系统。

背景技术

电子设备在检测到对应用程序的特定操作(以下简称为操作)时，会对该操作进行响应处理，并同时更新与操作关联的特定资源，从而实现对资源内容的更新维护。而资源更新的操作会增加一定的处理器负载。

因此，实际应用中需要一种可以降低电子设备处理器负载的方法。

发明内容

有鉴于此，本申请实施例提供了资源更新控制方法、电子设备及芯片系统，可以降低资源更新给电子设备带来的处理器负载。

本申请实施例的第一方面提供了一种资源更新控制方法，包括：

在检测到对应用程序的目标操作时，确定出目标操作关联的若干个待更新资源，并分析在目标操作下，各个待更新资源的内容是否会发生变化。

对于待更新资源中内容不会发生变化的资源，不进行资源更新。

对于待更新资源中内容会发生变化的资源，进行资源更新。

本申请实施例可以实现对目标操作关联的一个或多个待更新资源的更新控制。针对其中资源内容会发生变化的待更新资源继续进行正常更新，从而保障待更新资源的时效性。针对资源内容不会发生变化的待更新资源，则可以选择不对进行更新，从而避免对这部分待更新资源的无意义更新。因此，从所有待更新资源的整体角度而言，本申请实施例避免其中大量对无内容更新的待更新资源的更新，实现对局部资源的针对性更新。因此可以避免因对这部分无意义更新给处理器带来的负载，降低整体资源更新带来的负载，从而有效降低电子设备处理器负载，同时降低对电子设备造成的功耗。

在第一方面的第一种可能的实现方式中，待更新资源为列表资源，第一列表为任一待更新资源。

分析在目标操作下，各个待更新资源的内容是否会发生变化的操作中，包括：

分析在响应目标操作的过程中，第一列表中记录的数据是否会发生数据变化，数据变化包括：删除数据、新增数据以及替换数据。

本申请实施例可以实现在响应对应用程序的操作过程中，列表资源是否会发生内容的针对性识别。

在第一方面的第二种可能的实现方式中，待更新资源为目标组件列表。

在检测到对应用程序的目标操作时，确定出目标操作关联的若干个待更新资源，包括：

在检测到对应用程序的目标操作时，确定出目标操作关联的若干个预设服务。

确定出各个预设服务下属的目标组件列表。

在本申请实施例中，以目标操作关联预设服务的方式来确定出目标操作实际可能涉及的目标组件列表，从而可以实现对目标组件列表的精确定位。

在第一方面的第三种可能的实现方式中，预设服务包括：无障碍管理服务、搜索管理服务和账户与同步管理服务中的任意服务。

经分析和测试发现，无障碍管理服务、搜索管理服务和账户与同步管理服务这三种服务在响应目标操作更新组件列表时，存在大量无意义的组件列表更新操作。即很多组件列表内容并未发生变化，但仍进行了刷新。因此，在本申请实施例中，将无障碍管理服务、搜索管理服务和账户与同步管理服务中的任意服务做为预设服务进行处理，可以有效减少这些服务对应的组件列表的更新操作，从而减少对应的处理器负载。

作为本申请的一个实施例，对于无障碍管理服务，其下属的目标组件列表可以包括：无障碍服务组件列表。

作为本申请的一个实施例，对于搜索管理服务，其下属的目标组件列表可以包括：本地搜索服务组件列表、全局搜索服务组件列表以及在线搜索服务组件列表。

作为本申请的一个实施例，对于账户与同步管理服务，其下属的目标组件列表可以包括：账户认证服务组件列表和账户同步服务组件列表。

在第一方面的第四种可能的实现方式中，目标操作为安装操作、更新操作或卸载操作。

由于安装操作、更新操作或卸载操作是对应用程序极为常见且高频的操作，因此针对这些操作进行资源更新控制的处理，可以有效提升电子设备实际使用过程中，资源更新带来的处理器负载，从而提升本申请实施例的有效性和实用性。

在第一方面的第五种可能的实现方式中，第一组件列表为任一目标组件列表。分析在目标操作下，各个待更新资源的内容是否会发生变化，包括：

当目标操作为安装操作时，分析应用程序的程序包中是否包含有第一组件列表所需记录的组件。

当程序包中未包含有第一组件列表所需记录的组件时，判定为第一组件列表的内容不会发生变化。

实际应用中，对于安装操作，当应用程序的程序包中包含该特定组件时，则说明此次安装操作下，第一组件列表的内容需要新增记录应用程序的特定组件信息。因此本申请实施例可以实现针对安装操作下待更新资源的内容是否会发生变化的简单、精确且快速的识别。

作为本申请的一个实施例，针对无障碍管理服务而言，此时可以查询应用程序的程序包中是否包含无障碍服务组件。若程序包中是否包含无障碍服务组件，则说明此次更新操作下，无障碍服务组件列表中需要新增该应用程序的无障碍服务组件的信息。

针对搜索管理服务，则查询应用程序的程序包中是否包含本地搜索服务组件、全局搜索服务组件以及在线搜索服务组件。若程序包中包含其中任意组件，则说明此次更新操作下，搜索管理服务下属的组件列表中需要新增该应用程序的组件信息。

针对账户与同步管理服务，则查询应用程序的程序包中是否包含账户认证服务组件和账户同步服务组件。若程序包中包含其中任意组件，则说明此次更新操作下，账户与同步管理服务下属的组件列表中需要新增该应用程序的组件信息。

在第一方面的第六种可能的实现方式中，第一组件列表为任一目标组件列表。分析在目标操作下，各个待更新资源的内容是否会发生变化，包括：

当目标操作为卸载操作时，分析第一组件列表中是否记录有应用程序的组件信息。

当第一组件列表中未记录应用程序的组件信息时，判定为第一组件列表的内容不会发生变化。

实际应用中，卸载操作是将应用程序移除电子设备，因此在第一组件列表中未记录应用程序的组件信息时，说明卸载后无需清除第一组件列表中应用程序A的组件信息，即第一组件列表内容不会发生变化。因此本申请实施例可以实现针对卸载操作下待更新资源的内容是否会发生变化的简单、精确且快速的识别。

在第一方面的第七种可能的实现方式中，第一组件列表为任一目标组件列表。分析在目标操作下，各个待更新资源的内容是否会发生变化，包括：

当目标操作为更新操作时，分析应用程序的程序包中是否包含有第一组件列表所需记录的组件，并分析第一组件列表中是否记录有应用程序的组件信息。

当程序包中未包含有第一组件列表所需记录的组件，且第一组件列表中未记录应用程序的组件信息时，判定为第一组件列表的内容不会发生变化。

作为本申请的一个实施例，更新操作包括：版本更新操作、内容更新操作以及权限更新操作。

实际应用中，更新操作的具体操作情况较为复杂，而本申请实施例可以兼容这些具体更新操作下可能出现的情况，实现在目标组件列表内容需要变化时能够及时更新组件列表，而在目标组件列表无需内容变化时又不进行组件列表更新。

作为本申请的一个实施例，当目标操作为更新操作中的版本更新操作时，对程序包的操作，均为对新版本程序包的操作。例如“分析当前应用程序的程序包中是否包含有第一组件列表所需记录的组件”，可以具体化为：分析应用程序新版本的程序包中是否包含有第一组件列表所需记录的组件。即本申请实施例针对新版本的程序部来判断是否会有所需记录的组件，若有，说明需要更新第一组件列表中的组件信息。

在第一方面的第八种可能的实现方式中，当检测到应用程序关联的广播时，确定广播对应的操作事件。

当确定出的操作事件为目标操作对应的操作事件时，判定为检测到对应用程序的目标操作。

本申请实施例可以通过广播事件的方式，快速准确地确定出当前对应用程序的目标操作。

作为本申请的一个实施例，针对安装操作，可以设置为当检测到ACTION_PACKAGE_ADDED广播或者检测到ACTION_PACKAGE_ADDED广播和ACTION_PACKAGE_CHANGED广播时，判定为检测到对应用程序的安装操作。针对更新操作可以设置为当检测到ACTION_PACKAGE_CHANGED广播时，判定为检测到对应用程序的更新操作。针对卸载操作可以设置为当检测到ACTION_PACKAGE_REMOVED广播时，判定为检测到对应用程序的卸载操作。

本申请实施例的第二方面提供了一种资源更新控制装置，包括：

资源确定模块，用于在检测到对应用程序的目标操作时，确定出目标操作关联的若干个待更新资源。

分析模块，用于分析在目标操作下，各个待更新资源的内容是否会发生变化。

停止更新模块，用于对于待更新资源中内容不会发生变化的资源，不进行资源更新。

资源更新模块，用于对于待更新资源中内容会发生变化的资源，进行资源更新。

作为本申请的一个可选实施例，资源更新控制装置可以作为执行主体，实现上述第一方面任一项的方法。

第三方面，本申请实施例提供一种电子设备，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述第一方面任一项的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现如上述第一方面任一项的方法。

第五方面，本申请实施例提供一种芯片系统，该芯片系统包括处理器，处理器与存储器耦合，处理器执行存储器中存储的计算机程序，以实现如上述第一方面任一项所述的方法。该芯片系统可以为单个芯片，或者多个芯片组成的芯片模组。

第六方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行上述第一方面任一项所述的方法。

可以理解的是，上述第二方面至第六方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1A为本申请实施例提供的手机的硬件结构示意图；

图1B为本申请实施例提供的电子设备的软件结构框图；

图2为本申请实施例提供的资源更新控制方法的实现流程图；

图3为本申请实施例提供的资源更新控制方法的另一实现流程图；

图4A为本申请实施例提供的安装应用程序时，android.bg线程下各个事件的时序图；

图4B为本申请实施例提供的禁用应用程序组件时，android.bg线程下各个事件的时序图；

图4C为本申请实施例提供的卸载应用程序时，android.bg线程下各个事件的时序图；

图5为本申请实施例提供的资源更新控制方法的又一实现流程图；

图6为本申请实施例提供的资源更新控制方法的又一实现流程图；

图7为本申请实施例提供的资源更新控制装置的结构示意图；

图8为本申请实施例提供的电子设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

电子设备在检测到对应用程序的特定操作(以下简称为操作)时，会对该操作进行响应处理，并同时更新与操作关联的特定资源，从而实现对资源内容的更新维护。而资源更新的操作会增加一定的处理器负载，且可能会引起处理器阻塞的情况。同时，资源更新还会增加电子设备的功耗。

以安装有安卓(Android)系统的电子设备为例，进行举例说明：

在安卓系统中，对应用程序的常见操作一般包括：安装操作、更新操作和卸载操作等操作，其中更新操作包括对应用程序的版本更新操作、内容更新操作以及权限更新操作(如禁用或恢复组件)等操作。这些常见操作可以由用户的手动操作触发后执行，亦可以是电子设备自行执行。例如用户手动更新应用程序或者电子设备自动更新电子设备，以实现对应用程序的更新操作。

在执行这些操作的时候，电子设备会触发多个关联的服务。这些服务则会在触发后对各自下属的一个或多个服务组件列表(以下简称为组件列表，此时组件列表即为资源)进行更新，以维护这些组件列表的有效性。从而导致在操作被触发时，电子设备会同步更新多个组件列表。

例如对于安装操作而言，电子设备会触发关联的多个服务，包括但不限于如无障碍管理服务、搜索管理服务和账户与同步管理服务等。其中，每个服务在触发后又会对自身下属的组件列表进行更新。例如对于无障碍管理服务而言，在触发后会根据所安装的应用程序情况，来对自身对应的无障碍服务组件列表(以下简称为无障碍列表)进行内容更新。具体而言，可以查询该应用程序包中是否有无障碍组件(即是否支持无障碍服务，若有无障碍组件则支持无障碍服务，如支持盲人模式相关功能等)。若该应用程序支持无障碍服务，则将无障碍组件加入至无障碍列表中，若不支持，则会刷新无障碍列表。以此来实现对支持无障碍服务的应用程序的及时记录，实现对无障碍列表的更新维护。又例如对于搜索管理服务而言，在触发后会根据所安装的应用程序情况，来对自身下属的本地搜索组件列表、全局搜索组件列表以及在线搜索组件列表进行内容更新。具体而言，可以查询该应用程序包是否包含有搜索组件，若包含有搜索组件(即支持搜索服务)，则将搜索组件加入至本地搜索组件列表、全局搜索组件列表以及在线搜索组件列表中，若不包含搜索组件，则会刷新无障碍列表。以此来实现对支持搜索服务的应用程序的及时记录。

然而在实际应用发现，并非每次对应用程序的操作都会涉及到相关资源内容的变化，甚至对于某些资源而言，很多情况下的操作都是不涉及资源内容变化的。例如对于上述的无障碍服务而言，很多应用程序都是不支持无障碍服务的。因此对于这些并不支持无障碍服务的应用程序而言，其应用程序的安装、更新和卸载，虽然都会触发无障碍管理服务并更新无障碍列表。但此时的更新无障碍列表实质都是刷新无障碍列表，并不会对无障碍列表加入或删除信息，即并不会导致无障碍列表内容发生变化。对于操作并不涉及资源内容变化的情况而言，此时对资源的更新操作并无太大实际意义，反而会增加无效的处理器负载，造成无谓的功耗。例如对于安装安卓系统的电子设备而言，各类服务在构建服务列表(包括对服务列表的更新)的过程中，需要解析每个组件的元(meta)数据，需要跨包访问应用资源包，这整个过程耗费繁琐且耗时。但对于未涉及组件列表内容变化的操作而言，此时响应于操作来更新组件列表，则会导致对组件列表的无意义更新，且该更新操作还会增加无谓的处理器负载，带来无谓的功耗。

为了降低对应用程序操作引发的资源更新给电子设备带来的处理器负载，在本申请实施例中，电子设备在检测到预设操作后，并不会直接对预设操作关联的资源进行更新操作，而是先分析该预设操作是否可能会导致各个关联资源的内容变化。如是否会导致某个资源内容的新增或删除等。对于会有内容变化的资源，则正常进行资源更新操作。对于没有内容变化的资源，则终止此次的资源更新操作。

由于本申请实施例可以在需要预设操作发生后，及时判断与操作关联的各个资源的内容是否会发生可能变化，并终止对无内容变化的资源的更新。因此本申请实施例可以有效避免实际应用中部分对资源进行无效更新的操作，即可以避免这部分资源更新操作所带来的处理器负载，从而降低电子设备处理器负载，同时降低对电子设备造成的功耗。

本申请实施例提供的资源更新控制方法可以应用于手机、平板电脑、可穿戴设备、个人电脑和服务器等电子设备上，此时电子设备即为本申请实施例提供的资源更新控制方法的执行主体，本申请实施例对电子设备的具体类型不作任何限制。同时本申请实施例不对电子设备所安装运行的操作系统做任何限定，具体可根据实际应用情况确定。例如，当电子设备为手机、平板电脑等终端设备时，操作系统可以安卓系统、IOS系统或Windows系统等。而当电子设备为个人电脑、服务器等非终端设备类的设备时，操作系统可以是Windows系统、Mac OS系统、Linux系统或UNIX系统等。

下文以电子设备是手机为例，图1A示出了手机100的结构示意图。

手机100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及SIM卡接口195等。其中传感器模块180可以包括陀螺仪传感器180A，加速度传感器180B，气压传感器180C，磁传感器180D，环境光传感器180E，距离传感器180F，接近光传感器180G、指纹传感器180H，温度传感器180J，触摸传感器180K(当然，手机100还可以包括其它传感器，比如温度传感器，压力传感器、气压传感器、骨传导传感器等，图中未示出)。

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

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(Neural-network Processing Unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。其中，控制器可以是手机100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

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

处理器110可以运行本申请实施例提供的资源更新控制，以便于降低资源更新对处理器带来的负载，提升用户的体验。处理器110可以包括不同的器件，比如集成CPU和GPU时，CPU和GPU可以配合执行本申请实施例提供的资源更新控制，比如资源更新控制中部分算法由CPU执行，另一部分算法由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)等。在一些实施例中，手机100可以包括1个或N个显示屏194，N为大于1的正整数。显示屏194可用于显示由用户输入的信息或提供给用户的信息以及各种图形用户界面(graphical user interface，GUI)。例如，显示屏194可以显示照片、视频、网页、或者文件等。再例如，显示屏194可以显示图形用户界面。其中图形用户界面上包括状态栏、可隐藏的导航栏、时间和天气小组件(widget)、以及应用的图标，例如浏览器图标等。状态栏中包括运营商名称(例如中国移动)、移动网络(例如4G)、时间和剩余电量。导航栏中包括后退(back)键图标、主屏幕(home)键图标和前进键图标。此外，可以理解的是，在一些实施例中，状态栏中还可以包括蓝牙图标、Wi-Fi图标、外接设备图标等。还可以理解的是，在另一些实施例中，图形用户界面中还可以包括Dock栏，Dock栏中可以包括常用的应用图标等。当处理器检测到用户的手指(或触控笔等)针对某一应用图标的触摸事件后，响应于该触摸事件，打开与该应用图标对应的应用的用户界面，并在显示屏194上显示该应用的用户界面。

在本申请实施例中，显示屏194可以是一个一体的柔性显示屏，也可以采用两个刚性屏以及位于两个刚性屏之间的一个柔性屏组成的拼接显示屏。当处理器110运行本申请实施例提供的资源更新控制后，处理器110可以控制外接的音频输出设备切换输出的音频信号。

摄像头193(前置摄像头或者后置摄像头，或者一个摄像头既可作为前置摄像头，也可作为后置摄像头)用于捕获静态图像或视频。通常，摄像头193可以包括感光元件比如镜头组和图像传感器，其中，镜头组包括多个透镜(凸透镜或凹透镜)，用于采集待拍摄物体反射的光信号，并将采集的光信号传递给图像传感器。图像传感器根据所述光信号生成待拍摄物体的原始图像。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行手机100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，应用程序(比如相机应用，微信应用等)的代码等。存储数据区可存储手机100使用过程中所创建的数据(比如相机应用采集的图像、视频等)等。

内部存储器121还可以存储本申请实施例提供的资源更新控制对应的一个或多个计算机程序。该一个或多个计算机程序被存储在上述存储器121中并被配置为被该一个或多个处理器110执行，该一个或多个计算机程序包括指令，上述指令可以用于执行如图2至图6相应实施例中的各个步骤，该计算机程序可以包括帐号验证模块、优先级比较模块。其中，帐号验证模块，用于对局域网内的其它电子设备的系统认证帐号进行认证；优先级比较模块，可用于比较音频输出请求业务的优先级和音频输出设备当前输出业务的优先级。状态同步模块，可用于将电子设备当前接入的音频输出设备的设备状态同步至其它电子设备，或者将其它设备当前接入的音频输出设备的设备状态同步至本地。当内部存储器121中存储的资源更新控制的代码被处理器110运行时，处理器110可以控制电子设备进行资源更新的控制。

此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

当然，本申请实施例提供的资源更新控制的代码还可以存储在外部存储器中。这种情况下，处理器110可以通过外部存储器接口120运行存储在外部存储器中的资源更新控制的代码，处理器110可以控制电子设备进行资源更新的控制。

下面介绍传感器模块180的功能。

陀螺仪传感器180A，可以用于确定手机100的运动姿态。在一些实施例中，可以通过陀螺仪传感器180A确定手机100围绕三个轴(即，x，y和z轴)的角速度。即陀螺仪传感器180A可以用于检测手机100当前的运动状态，比如抖动还是静止。

当本申请实施例中的显示屏为可折叠屏时，陀螺仪传感器180A可用于检测作用于显示屏194上的折叠或者展开操作。陀螺仪传感器180A可以将检测到的折叠操作或者展开操作作为事件上报给处理器110，以确定显示屏194的折叠状态或展开状态。

加速度传感器180B可检测手机100在各个方向上(一般为三轴)加速度的大小。即陀螺仪传感器180A可以用于检测手机100当前的运动状态，比如抖动还是静止。当本申请实施例中的显示屏为可折叠屏时，加速度传感器180B可用于检测作用于显示屏194上的折叠或者展开操作。加速度传感器180B可以将检测到的折叠操作或者展开操作作为事件上报给处理器110，以确定显示屏194的折叠状态或展开状态。

接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。发光二极管可以是红外发光二极管。手机通过发光二极管向外发射红外光。手机使用光电二极管检测来自附近物体的红外反射光。当检测到充分的反射光时，可以确定手机附近有物体。当检测到不充分的反射光时，手机可以确定手机附近没有物体。当本申请实施例中的显示屏为可折叠屏时，接近光传感器180G可以设置在可折叠的显示屏194的第一屏上，接近光传感器180G可根据红外信号的光程差来检测第一屏与第二屏的折叠角度或者展开角度的大小。

陀螺仪传感器180A(或加速度传感器180B)可以将检测到的运动状态信息(比如角速度)发送给处理器110。处理器110基于运动状态信息确定当前是手持状态还是脚架状态(比如，角速度不为0时，说明手机100处于手持状态)。

指纹传感器180H用于采集指纹。手机100可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。

触摸传感器180K，也称“触控面板”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于手机100的表面，与显示屏194所处的位置不同。

示例性的，手机100的显示屏194显示主界面，主界面中包括多个应用(比如相机应用、微信应用等)的图标。用户通过触摸传感器180K点击主界面中相机应用的图标，触发处理器110启动相机应用，打开摄像头193。显示屏194显示相机应用的界面，例如取景界面。

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

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

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

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在手机100上的包括无线局域网(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转为电磁波辐射出去。本申请实施例中，无线通信模块160可以用于接入接入点设备，向其它电子设备发送和接收消息。

另外，手机100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。手机100可以接收按键190输入，产生与手机100的用户设置以及功能控制有关的键信号输入。手机100可以利用马达191产生振动提示(比如来电振动提示)。手机100中的指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。手机100中的SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和手机100的接触和分离。

应理解，在实际应用中，手机100可以包括比图1A所示的更多或更少的部件，本申请实施例不作限定。图示手机100仅是一个范例，并且手机100可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

电子设备的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的安卓(Android)系统为例，示例性说明电子设备的软件结构。图1B是本申请实施例的电子设备的软件结构框图。

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

应用程序层可以包括一系列应用程序包以及对应用程序的管理(即应用管理)。

如图1B所示，应用程序包可以包括桌面、设置和应用商店等应用程序。应用管理可以包括应用安装、应用更新、应用卸载和应用禁用/恢复等管理功能。

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

如图1B所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器、无障碍管理服务(AccessibilityManagerService)、搜索管理服务(SearchManagerService)和账户与同步管理服务(RegisteredServicesCache)等。

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

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

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供电子设备的通信功能。例如通话状态的管理(包括接通，挂断等)。

资源管理器(ResourceManager)为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。资源管理器可以获取资源(Resources)对象以及应用程序包资源(ApkAssets)等。

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

无障碍管理服务用于管理电子设备中的无障碍服务(管理支持无障碍服务的应用程序)，如可以构建无障碍服务的服务组件列表，以记录电子设备中各个支持无障碍服务的应用程序情况。

搜索管理服务用于管理电子设备中的搜索服务，如可以构建具有搜索服务能力(如本地搜索、全局搜索以及在线搜索)的服务组件列表，以记录电子设备中各个支持搜索服务的应用程序情况。

账户与同步管理服务用于管理电子设备中的账户认证服务和账户同步服务，如可以构建账户认证服务和账户同步服务的服务组件列表，以记录电子设备中各个支持账户同步服务的应用程序情况。

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

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

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

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.164，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

下面结合手机100进行资源更新控制的场景，示例性说明手机100软件以及硬件的工作流程。

当触摸传感器180K接收到触摸操作，相应的硬件中断被发给内核层。内核层将触摸操作加工成原始输入事件，原始输入事件被存储在内核层。应用程序框架层从内核层获取原始输入事件，通过调用应用程序框架层中的各项服务(如无障碍管理服务、搜索管理服务和账户与同步管理服务等)来更新手机中的服务组件列表，以实现对服务组件列表的维护。

本申请实施例可以适用于任意由于对电子设备应用程序的操作，引发关联资源更新的情况，以降低资源更新带来的处理器负载。相应的，根据实际的应用场景不同，“资源”的具体代指情况也可以存在差异。例如，在一些应用场景中，资源可以是指应用程序自身或相关联的音频、视频、图片、组件或插件等数据资源。此时资源的内容即是指这些数据资源本身包含的具体数据内容，如音频中包含的具体音频内容或视频中包含的具体视频内容等。而在另一些可选实施例中，资源亦可以是指：用于记录应用程序的音频、视频、图片、组件或插件等数据的信息清单或列表(以下称为列表资源，并将列表资源用于记录的数据对象称为目标数据)。此时资源的内容即是指这些列表资源内记录的目标数据的信息内容，如目标数据的数据标识等。

为了说明本申请所述的技术方案，下面通过具体实施例来进行说明。

应当说明地，实际应用中，单个操作关联的资源数量可能为一个或多个。在本申请实施例中，对每个资源是否更新的处理方式相同。因此此处先以单个资源为例进行示例说明。图2示出了本申请实施例一提供的资源更新控制方法的实现流程图，详述如下：

S101，电子设备在检测到对应用程序的目标操作时，确定出目标操作关联的待更新资源。

实际应用中，对电子设备的操作类型可以有多种，且每种操作所关联的资源情况也可能各不相同。因此在本申请实施例中，技术人员可以根据实际需求选取一种或多种操作，作为本申请实施例针对处理的操作(即目标操作)。例如，在一些实施例中，目标操作可以包括对应用程序的安装操作、更新操作和卸载操作中的任意操作。同时，对于每种目标操作而言，其关联的资源也可以有多种。在本申请实施例中，亦可以根据实际需求从各个目标操作所关联的资源中，选取出一种或多种资源作为本申请实施例处理的资源对象。例如在一些可选实施例中，可以将目标操作关联的所有可能会随着目标操作进行更新的资源，均作为本申请实施例中处理的资源对象。例如，假设实际应用中，对应用程序进行安装操作时，可能会触发对资源A、资源B和资源C的更新，此时则可以选择将资源A、资源B和资源C均作为本申请实施例中处理的资源对象，亦可以选择将其中部分资源作为本申请实施例中处理的资源对象。应当说明地，针对每种目标操作，其均可以独立选取一种或多种资源来作为本申请实施例中处理的资源对象。

在预先设置好目标操作包含的具体操作，以及每种目标操作各自关联的资源对象的情况下。电子设备在运行过程中可以检测是否有对应用程序的操作，并确定该操作是否属于目标操作。当检测到对应用程序的目标操作时，则再确定出该目标操作实际关联的资源对象，并作为本申请实施例中的待更新资源。其中，本申请实施例不对具体目标操作的检测方式做过多限定，可以根据实际应用情况确定。例如，在一些可选实施例中，可以通过检测操作事件的方式来检测是否有对应用程序的操作，并根据操作事件的事件类型，来判断该操作是否为目标操作。由于本申请实施例针对的是单个资源进行说明，因此此时确定出的待更新资源，可以是该目标操作实际关联的任意一个资源对象。

S102，电子设备分析在对应用程序进行目标操作下，待更新资源的资源内容是否会发生变化。

在确定好目标操作和待更新资源的情况下，本申请实施例可以继续分析对应用程序进行目标操作，是否会导致待更新资源的资源内容发生变化。即电子设备在正常响应目标操作的过程中，是否会涉及到对该待更新资源的内容改变，如是否会导致待更新资源内容增加、删除或替换等。其中，本申请实施例不对待更新资源的资源内容是否会发生变化的具体分析方式做过多限定，可由技术人员根据实际需求设定。

例如，在一些可选实施例中，假设待更新资源为数据资源(如音频数据等)。此时电子设备可以判断在响应目标操作的过程中，是否会对已有的该待更新资源删除部分或全部内容，是否会替换掉该待更新资源的内容。以及若电子设备内当前尚无该待更新资源时，是否会新增该待更新资源等。若可能会出现这些情况，则可以判定为该待更新资源的资源内容会发生变化。

又例如，在另一些可选实施例中，假设待更新资源为列表资源(如组件列表等)。此时电子设备则可以判断在响应目标操作过程中，是否会导致该列表资源内记录的目标数据发生改变。如当是否会删除、更新或替换已有的目标数据，是否会新增目标数据等。若可能出现这些情况，则可以判定为该待更新资源的资源内容会发生变化(即列表资源中记录的目标数据的信息会发生变化)。

S103，若分析结果为待更新资源的资源内容会发生变化，则电子设备对待更新资源进行更新。

S104，若分析结果为待更新资源的资源内容不发生变化，则电子设备不对待更新资源进行更新。

当分析结果为待更新资源的资源内容会发生变化时，则说明此时对待更新资源进行更新是电子设备的真实需求行为。因此此时本申请实施例可以继续正常更新待更新资源，以维护待更新资源的有效性。反之，当分析结果为待更新资源的资源内容不会发生变化时，则说明此时若对待更新资源进行更新，大概率是进行数据刷新等不涉及实质内容变化的更新操作。即此时的待更新资源更新操作大概率无实际意义。因此此时本申请实施例则不继续对待更新资源进行后续更新操作，或者亦可以描述为停止对待更新资源的更新操作。其中，本申请实施例不对待更新资源的具体更新操作做过多限定，可根据电子设备实际情况确定。例如，可以删除待更新资源的部分或全部内容，亦可以是替换或新增部分内容等。

应当理解地，本申请实施例在决定是否对待更新资源进行更新操作时，无论最终是否对待更新资源进行更新，均不会影响电子设备对目标操作的其他正常响应。

以一实例进行举例说明，假设目标操作为对应用程序A的卸载操作，待更新资源为应用程序下载的多媒体资源A(包括应用程序A的音频数据、视频数据和图片数据)。且假设正常情况下，电子设备在响应对应用程序A的卸载操作时，一方面会正常卸载应用程序A，另一方面会清空应用程序缓存的多媒体资源。在结合本申请实施例应用时，电子设备在正常卸载应用程序A的同时，若分析结果为多媒体资源A的资源内容会发生变化，则此时电子设备可以继续正常删除多媒体资源A。反之，若分析结果为多媒体资源A的资源内容不会发生变化，则电子设备可以正常卸载应用程序A，但不会继续删除多媒体资源A。

又例如，以一实例进行举例说明，假设目标操作为对应用程序A的安装操作，待更新资源为用于记录各个应用程序中支持功能A的组件列表A(当某一应用程序中包含功能A对应的组件A，则可认为该应用程序支持功能A)。同时假设正常情况下，电子设备在检测到对应用程序A的安装操作时，一方面会正常安装应用程序A，另一方面则根据应用程序A包含的组件情况来更新组件列表A。若应用程序A包含组件A，则在组件列表A中添加应用程序A的组件信息。若应用程序A不包含组件A，则刷新一下组件列表A。在结合本申请实施例应用时，电子设备在正常安装应用程序A的同时，还可以检测应用程序A内是否包含组件A。若应用程序A包含组件A，则可以判定分析结果为为待更新资源的资源内容会发生变化，此时则可以对组件列表A进行更新，加入应用程序A的组件信息。反之若应用程序A未包含组件A，则可以判定分析结果为为待更新资源的资源内容不会发生变化，此时则可以不对组件列表A进行更新。

在本申请实施例中，针对与目标操作相关联的任意待更新资源，可以实现是否会发生资源内容变化的针对性分析。针对资源内容会发生变化的情况，可以继续对该待更新资源进行正常更新，从而保障待更新资源的时效性。针对资源内容不会发生变化的情况，则可以选择不对该待更新资源进行更新，从而避免对待更新资源的无意义更新。因此，从单个待更新资源的角度而言，本申请实施例可以实现避免对无内容更新的待更新资源的更新，因此可以避免因对这部分无意义更新给处理器带来的负载，从而有效降低电子设备处理器负载，同时降低对电子设备造成的功耗。

考虑到实际应用中对应用程序的操作往往会涉及到多个资源，即实际应用中目标操作往往会关联多个待更新资源。因此在实际应用中，针对单个应用程序目标操作的处理过程中，往往是同步处理多个待更新资源的更新判断和控制等流程。基于此，在图2所示实施例的基础上，从可能有多个待更新资源的角度进行说明，此时可以参考图3，是本申请实施例提供的另一个资源更新控制方法的实现流程图，详述如下：

S201，电子设备在检测到对应用程序的目标操作时，确定出目标操作关联的一个或多个待更新资源。

S201是对S101的情况扩展，即S101中确定出的是目标操作关联的一个待更新资源，而S201中确定出的是目标操作关联的若干个待更新资源。因此对S201的说明均可以参考S101中的相关说明，此处不予赘述。以下对S201与S101的区别之处进行说明：

在预先设置好目标操作包含的具体操作，以及每种目标操作各自关联的资源对象的情况下。电子设备在运行过程中可以检测是否有对应用程序的操作，并确定该操作是否属于目标操作。当检测到对应用程序的目标操作时，可以把该目标操作关联的部分或全部资源对象，作为本申请实施例中的待更新资源。例如，假设实际应用中，对应用程序进行安装操作时，可能会触发对资源A、资源B、资源C和资源D的更新，并将其中的资源A、资源B和资源C均作为本申请实施例中处理的资源对象。在此基础上，本申请实施例在目标操作为安装操作时，可以将资源A、资源B和资源C中任意一项或多项资源作为本申请实施例中的待更新资源。

S202，电子设备分析在目标操作下，各个待更新资源的资源内容是否会发生变化。

同理，S202是对S102的情况扩展，即此时电子设备会针对各个待更新资源均判断是否其资源内容会发生变化。由于对每个待更新资源是否会发生变化的判断逻辑相同，因此可以参考S102中的相关说明，来实现对各个待更新资源的处理。

在本申请实施例中，可以将任意单个待更新资源称为第一资源。当待更新资源为列表资源时，则第一资源亦可称为第一列表。

S203，对于分析结果为资源内容会发生变化的待更新资源，电子设备对该待更新资源进行更新。

S204，对于分析结果为资源内容不发生变化的待更新资源，则不进行更新。

S103和S104都是针对单个待更新资源而言的处理方式，当有多个待更新资源时，其中的每个待更新资源的分析结果均可能为“资源内容会发生变化”或者“资源内容不会发生变化”。因此相应的，本申请实施例在S103和S104的基础上，针对有多个待更新资源的情况，可以选择对其中会发生资源内容变化的资源正常进行更新，而对于资源内容不会发生变化的资源，则不再继续进行更新。其中，具体对单个待更新资源的操作可以参考对S103和S104的说明，此处不予赘述。

在图2所示实施例的基础上，本申请实施例可以实现对目标操作关联的多个待更新资源的更新控制。针对其中资源内容会发生变化的待更新资源继续进行正常更新，从而保障待更新资源的时效性。针对资源内容不会发生变化的待更新资源，则可以选择不对进行更新，从而避免对这部分待更新资源的无意义更新。因此，从所有待更新资源的整体角度而言，本申请实施例避免其中大量对无内容更新的待更新资源的更新。因此可以避免因对这部分无意义更新给处理器带来的负载，降低整体资源更新带来的负载，从而有效降低电子设备处理器负载，同时降低对电子设备造成的功耗。

作为本申请的一个实施例，以下以目标操作包括：安装操作、更新操作和卸载操作，资源包括服务组件列表为例，进行实施例说明。

在对应用程序进行安装操作、更新操作和卸载操作等操作时，电子设备内会触发关联的服务，再构建相关的服务组件列表。以下先对本申请实施例主要涉及到的几种服务进行说明，参考表1，是本申请实施例提供的几种服务的相关信息说明：

表1

其中，触发因素是指可以触发对应服务的一些因素。例如对于无障碍管理服务而言，可以在电子设备内发生开机广播、解锁广播、切换用户，以及应用程序安装、卸载和更新等广播事件时(即包安装卸载更新广播)，触发运行无障碍管理服务。在本申请实施例中，对于账户与同步管理服务，可以有至少两种具体实现场景：同步适配服务(SyncAdaptersCache)和账户验证服务(AccountAuthenticatorCache)。

以下以安卓系统的电子设备为例，对服务进行服务组件列表更新的流程进行示例说明：

一、应用程序的安装操作：

在通过应用市场或其他来源安装应用程序时，电子设备内的包管理系统服务(PackageManagerService，PMS)会发送ACTION_PACKAGE_ADDED广播和ACTION_PACKAGE_CHANGED广播，并由android.bg线程来处理广播。具体而言，android.bg线程在处理广播时，触发无障碍管理服务、搜索管理服务、账户与同步管理服务以及其他相关服务。此时这些服务则会开始更新各自对应的服务组件列表，由于在构建服务组件列表过程中，需要跨包访问应用程序资源包，解析每个组件的元数据。从而使得整个android.bg线程耗时较长。

例如可以参考图4A，是本申请实施例提供的一种在应用市场下载并安装应用程序A(未采用本申请实施例中的资源更新控制方法)时，android.bg线程下各个示意事件的时序图。在本申请实施例中，将安装操作下无障碍管理服务、搜索管理服务、账户与同步管理服务以及其他相关服务各自对应的事件分别称为：事件A1、事件B1、事件C1以及事件D1。其中，各个事件又是由多个更小单位的事件构成(即包含更小的事件)，例如事件A1可以包括事件a1，而事件a1又可以包括事件a2，事件a2可以包括事件a3等。同理，事件B1可以包括事件b1，事件b1可以包括事件b2等。其中，在处理这些事件的过程中，android.bg线程处理事件的状态至少包括：运行中(Running)、排队等待(Runnable)、不间断休眠IO(Uninterruptible Sleep(IO))、排队等待(抢占)(Runnable(Preempted))、休眠中(Sleeping)以及不间断休眠非IO(Uninterruptible Sleep(non-IO))。

作为本申请的一个具体实施例，在本申请实施例中，各类状态的相关参数：持续时间(Wall duration)、平均持续时间(Avg Wall duration)以及次数(Occurrences)如下表2：

表2

二、应用程序的更新操作：

在对应用程序进行手动/自动版本更新、内容更新或者权限更新等更新操作时，PMS会发出ACTION_PACKAGE_CHANGED广播，并由android.bg线程来处理广播。具体而言，android.bg线程在处理广播时，触发无障碍管理服务、搜索管理服务、账户与同步管理服务以及其他相关服务。此时这些服务则会开始更新各自对应的服务组件列表。

例如可以参考图4B，是本申请实施例提供的一种禁用应用程序A某个组件(未采用本申请实施例中的资源更新控制方法)时，android.bg线程下各个示意事件的时序图。在本申请实施例中，将更新操作下无障碍管理服务、搜索管理服务、账户与同步管理服务以及其他相关服务各自对应的事件分别称为：事件A2、事件B2、事件C2以及事件D2。其中，各个事件又是由多个更小单位的事件构成，例如事件A2可以包括事件a11，而事件a11又可以包括事件a21，事件a21可以包括事件a31等。同理，事件B2可以包括事件b11，事件b11可以包括事件b21等。

作为本申请的一个具体实施例，在本申请实施例中，在处理这些事件的过程中，android.bg线程处理事件的各个状态相关参数如下表3：

表3

三、应用程序的卸载操作：

在对应用程序进行卸载操作时，PMS发出ACTION_PACKAGE_REMOVED广播，并由android.bg线程来处理广播。具体而言，android.bg线程在处理广播时，触发无障碍管理服务、搜索管理服务、账户与同步管理服务以及其他相关服务。此时这些服务则会开始更新各自对应的服务组件列表。

例如可以参考图4C，是本申请实施例提供的一种卸载应用程序A(未采用本申请实施例中的资源更新控制方法)时，android.bg线程下各个示意事件的时序图。在本申请实施例中，将卸载操作下无障碍管理服务、搜索管理服务、账户与同步管理服务以及其他相关服务各自对应的事件分别称为：事件A3、事件B3、事件C3以及事件D3。其中，各个事件又是由多个更小单位的事件构成(及包含更小的事件)，例如事件A3可以包括事件a12，而事件a12又可以包括事件a22，事件a22可以包括事件a32等。同理，事件B3可以包括事件b12，事件b12可以包括事件b22等。

作为本申请的一个具体实施例，在本申请实施例中，在处理这些事件的过程中，android.bg线程处理事件的各个状态相关参数如下表4：

表4

为了减少上述目标操作过程中的耗时，在一些可选实现方式中，可以选择将可能使用到的资源均进行实时缓存，从而使得电子设备可以在需要时及时调用资源。但实际应用中发现，资源实时缓存对系统内存的消耗极大，从而可能会导致系统内存不足，电子设备运行出现问题的情况。例如实际应用中发现一个应用程序资源(apkAssets)对象在实时缓存时，所需占用的系统内存大约1M。当系统需要缓存较多应用程序资源时，则会导致系统内存被长期大量占用，从而容易导致电子设备运行卡顿。因此，此种方式仍存在一定的缺陷，实用性较低。

在图3所示实施例的基础上，可以参考图5，是本申请实施例提供的一种资源更新控制方法的实现流程图。在本申请实施例中，目标操作至少包括：安装操作、更新操作和卸载操作，资源包括服务组件列表。在本申请实施例中，S201可以被替换为S301，S202可以被替换为S302，S203可以被替换为S3030，S204可以被替换为S304。详述如下：

S301，电子设备在检测到对应用程序的目标操作时，确定出目标操作关联的若干个预设服务，以及各个预设服务下属的目标组件列表。

在本申请实施例中，将进行组件列表更新控制的操作统称为目标操作，目标操作具体包含的操作类型可由技术人员设定。例如在一些实施例中，目标操作可以包括安装操作、更新操作和卸载操作中的任意操作。在此基础上，当检测到安装操作、更新操作或卸载操作时，均可以触发S301流程。

由于每种操作关联的服务数量均可能是一种或多种，其中每种服务的具体情况各异。例如有些服务会在目标操作发生时进行组件列表更新，有些则不会。又例如，实际应用中发现，即使是会对组件列表更新的服务，根据服务类型不同，不同服务在更新组件列表时给处理器带来的额外负载程度也不尽相同。因此，在实际应用中，可以跟需求从目标操作关联的所有服务中，选取出目标操作触发的部分或全部服务来作为本申请实施例中的预设服务。

作为本申请的一个可选实施例，实际应用中发现，无障碍管理服务、搜索管理服务和账户与同步管理服务，这三种服务在响应安装操作、更新操作和卸载操作等目标操作时，往往会构建或更新对应的组件列表。且经分析和测试发现，这三种服务在响应目标操作更新组件列表时，存在大量无意义的组件列表更新操作。即很多组件列表内容并未发生变化，但仍进行了刷新。因此，在本申请实施例中，将无障碍管理服务、搜索管理服务和账户与同步管理服务，均作为预设服务。此时，在检测到目标操作时，即可将无障碍管理服务、搜索管理服务和账户与同步管理服务作为关联的预设服务。作为本申请的另一个可选实施例，亦可将上述三种服务中任意一种或多种作为预设服务。即在本申请实施例中，预设服务包括：无障碍管理服务、搜索管理服务和账户与同步管理服务中的任意一项或多种服务。

由于每种预设服务下属均有至少一个组件列表，其中每个组件列表的情况亦存在一定的差异。例如，不同的组件列表用于记录的组件类型不同，如组件列表A可以是用于记录具有组件a(即支持组件a对应的服务a)的应用程序的信息，而组件列表B则可以是用于记录支持组件b(即支持组件b对应的服务b)的应用程序的信息。因此实际应用中，亦可以实际需要来独立选取每一种预设服务下具体控制是否更新的组件列表(本申请实施例中将这些选取的组件列表亦称为目标组件列表)。在此基础上，电子设备实际运行过程中，则可以根据这些选取设置，来选取每一个预设服务下，分别对应的目标组件列表。

作为本申请的一个可选实施例，可以将预设服务下属的所有组件列表均作为目标组件列表，从而实现对这些预设服务最大程度地减小组件列表更新所带来的处理器负载。

以一实例进行举例说明，在本申请实施例中，针对无障碍管理服务，其下属的目标组件列表可以包括：无障碍服务组件列表。对于搜索管理服务，其下属的目标组件列表可以包括：本地搜索服务组件列表、全局搜索服务组件列表以及在线搜索服务组件列表。而对于账户与同步管理服务，其下属的目标组件列表则可以包括：账户认证服务组件列表和账户同步服务组件列表。在另一些可选实施例中，上述三种服务下所包含的组件列表，亦可以是独立设置。

在预先设定好目标操作、预设服务和目标组件列表的情况下，本申请实施例不对具体目标操作的检测方式做过多限定。例如在一些可选实施例中，可以通过是否检测到目标操作对应的特定事件的方式，来判断是否检测到目标操作。如当检测到目标操作A对应的广播A时，可以判定为检测到目标操作A。

作为本申请的一个具体实施例，针对安装操作，可以设置为当检测到ACTION_PACKAGE_ADDED广播或者检测到ACTION_PACKAGE_ADDED广播和ACTION_PACKAGE_CHANGED广播时，判定为检测到对应用程序的安装操作。针对更新操作可以设置为当检测到ACTION_PACKAGE_CHANGED广播时，判定为检测到对应用程序的更新操作。针对卸载操作可以设置为当检测到ACTION_PACKAGE_REMOVED广播时，判定为检测到对应用程序的卸载操作。其中，这些广播均可以视为对应用程序的程序包操作事件(handlePackageEvent)，即对应用程序进行了操作。

S302，电子设备分析在目标操作下，各个目标组件列表的内容是否会发生变化。

在确定出所需更新控制的目标组件列表后，本申请实施例开始分析各个目标组件列表在目标操作下是否可能会发生内容变化。

作为本申请的一个可选实施例，其中，对于每个目标组件列表分析的方式相同，因此此处仅以单个目标组件列表为例来进行说明。设当前处理的目标组件列表为第一组件列表(第一组件列表为任意目标组件列表)，针对目标操作包括：安装操作、卸载操作和更新操作为例。此时S302可以被替换为：S3021至S3023，说明如下：

S3021，当目标操作为安装操作时，分析当前应用程序的程序包中是否包含有第一组件列表所需记录的组件。若程序包中包含有第一组件列表中所需记录的组件，则判定为第一组件列表的内容会发生变化。若程序包中不包含第一组件列表所需记录的组件时，则说明此次更新操作并不会导致第一组件列表内容发生变化。

设当前操作的应用程序为应用程序A。当在进行应用程序A安装操作时，可以查询应用程序A的程序包中是否包含第一组件列表所需记录的组件，即判断该应用程序A是否支持第一组件列表所需记录的特定功能。当程序包中包含该特定组件时，则说明此次安装操作下，第一组件列表的内容需要新增记录应用程序A的特定组件信息。

例如，针对无障碍管理服务而言，此时可以判断应用程序A是否支持无障碍服务功能，即查询应用程序A的程序包中是否包含无障碍服务组件。若程序包中是否包含无障碍服务组件，则说明此次更新操作下，无障碍服务组件列表中需要新增该应用程序A的无障碍服务组件的信息。

针对搜索管理服务，则查询应用程序A的程序包中是否包含本地搜索服务组件、全局搜索服务组件以及在线搜索服务组件。若程序包中包含其中任意组件，则说明此次更新操作下，搜索管理服务下属的组件列表中需要新增该应用程序A的组件信息。例如，当程序包中包含本地搜索服务组件时，则说明本地搜索服务组件列表中需要新增该应用程序A的本地搜索服务组件信息。当程序包中包含全局搜索服务组件时，则说明全局搜索服务组件列表中需要新增该应用程序A的全局搜索服务组件信息。

针对账户与同步管理服务，则查询应用程序A的程序包中是否包含账户认证服务组件和账户同步服务组件。若程序包中包含其中任意组件，则说明此次更新操作下，账户与同步管理服务下属的组件列表中需要新增该应用程序A的组件信息。例如，当程序包中包含账户认证服务组件时，则说明账户认证服务组件列表中需要新增该应用程序A的账户认证服务组件信息。当程序包中包含账户同步服务组件时，则说明账户同步服务组件列表中需要新增该应用程序A的账户同步服务组件信息。

S3022，当目标操作为卸载操作时，分析第一组件列表是否记录有当前应用程序的组件信息。若第一组件列表中记录有当前应用程序的组件信息，则判定为第一组件列表内容会发生变化。若第一组件列表中未记录当前应用程序的组件信息，则判定为第一组件列表内容不会发生变化。

与安装操作情况相对应的，卸载操作是将应用程序A移除电子设备。因此此时本申请实施例所需分析的是本地已有的第一组件列表中，是否记录有应用程序A的组件信息。当记录有应用程序A的组件信息时，说明卸载后需要清除第一组件列表中应用程序A的组件信息，即第一组件列表内容需要发生变化。反之，则说明卸载后无需清除第一组件列表中应用程序A的组件信息，即第一组件列表内容无需发生变化。

作为本申请的一个可选实施例，针对第一组件列表分别属于无障碍管理服务、搜索管理服务和账户与同步管理服务下的具体操作细节，与安装操作时基本类似。其差别之处在于查询的对象为第一组件列表，查询的内容为第一组件列表中是否包含应用程序A的组件信息。因此可以参考上述S3021中的相关说明，此处不予赘述。

由于第一组件列表可以是缓存的形式存储于电子设备中，因此在一些实施例中，可以通过遍历全局缓存的第一组件列表的方式，来实现对第一组件列表的分析或查询。

S3023，当目标操作为更新操作时，分析当前应用程序的程序包中是否包含有第一组件列表所需记录的组件，以及第一组件列表是否记录有当前应用程序的组件信息。若程序包中包含有第一组件列表中所需记录的组件，和/或第一组件列表中记录有当前应用程序的组件信息，则判定为第一组件列表内容会发生变化。

实际应用中，更新操作的具体操作情况较为复杂，如可以是版本更新操作、内容更新操作或者权限更新操作等。不同操作可能涉及到的内容也会存在一定的差异。因此为了可以兼容这些具体更新操作下可能出现的情况，实现在目标组件列表内容需要变化时能够及时更新组件列表，而在目标组件列表无需内容变化时又不进行组件列表更新。在本申请实施例中，可以同时考虑应用程序A程序包中包含的组件情况，以及第一组件列表中已记录的组件信息的情况。其中，当应用程序A的程序包中包含有第一组件列表中所需记录的组件时，说明可能需要将第一组件列表中的组件信息更新为程序包中记录的组件信息。而当第一组件列表中记录有当前应用程序的组件信息时，此时更新操作可能会导致该记录的组件信息需要被删除或者替换。因此本申请实施例在发生这两类情况中的任意一种或两种情况时，均可以判定为第一组件列表内容需要发生变化。反之，若两种情况均不存在，即程序包中不包含第一组件列表中所需记录的组件，且第一组件列表中未记录当前应用程序的组件信息。则说明此次更新操作与第一组件列表的关系并不大，因此极大概率是不会导致第一组件列表发生内容变化的。

作为本申请的一个实施例，当目标操作为更新操作中的版本更新操作时，对程序包的操作，均为对新版本程序包的操作。例如“分析当前应用程序的程序包中是否包含有第一组件列表所需记录的组件”，可以具体化为：分析应用程序新版本的程序包中是否包含有第一组件列表所需记录的组件。即本申请实施例针对新版本的程序部来判断是否会有所需记录的组件，若有，说明需要更新第一组件列表中的组件信息。

S303，电子设备对于目标组件列表中内容会发生变化的组件列表进行更新。

S304，电子设备对于目标组件列表中内容不发生的组件列表，则不进行更新。

在确定出各个目标组件列表的内容是否会变化时，针对内容会发生变化的目标组件列表，可以正常进行更新。其中具体的组件列表更新细节此处不做过多限定，可根据实际应用情况确定。而针对内容不会发生变化的目标组件列表，则可以选择不进行此次的更新。从而避免对这些内容不会发生变化的目标组件列表的无意义更新操作，减少这部分更新操作给处理器带来的负载。

应当理解地，实际应用中，针对每个目标组件列表的更新控制可以是相互独立的，或者相互联动的，具体可根据实际目标组件列表情况来确定。因此S302至S304的操作，可以是在每次确定出单个目标组件列表的内容是否会变化后，对该目标组件列表进行更新控制。亦可以是在确定出多个目标组件列表的内容是否会变化后，对这些目标组件列表的更新进行批量控制。此处不做过多限定。

作为本申请的一个可选实施例，实际应用中，可以通过在默认的组件列表更新流程的组件列表更新步骤之前嵌入上述各个本申请实施例，从而实现对组件列表是否进行更新的控制。例如可以在更新组件列表的接口之前嵌入一个过滤器，该过滤器用于实现上述各个本申请实施例。在过滤器需要对组件列表进行更新时，再正常通过更新组件列表的接口来实现对组件列表的更新。

上述各个本申请实施例至少具有以下有益效果：

1、在本申请实施例中，针对与目标操作相关联的任意待更新资源，可以实现是否会发生资源内容变化的针对性分析。针对资源内容会发生变化的情况，可以继续对该待更新资源进行正常更新，从而保障待更新资源的时效性。针对资源内容不会发生变化的情况，则可以选择不对该待更新资源进行更新，从而避免对待更新资源的无意义更新。因此，从单个待更新资源的角度而言，本申请实施例可以实现避免对无内容更新的待更新资源的更新，因此可以避免因对这部分无意义更新给处理器带来的负载，从而有效降低电子设备处理器负载，同时降低对电子设备造成的功耗。

2、在有多个待更新资源时，本申请实施例可以实现对目标操作关联的多个待更新资源的更新控制。针对其中资源内容会发生变化的待更新资源继续进行正常更新，从而保障待更新资源的时效性。针对资源内容不会发生变化的待更新资源，则可以选择不对进行更新，从而避免对这部分待更新资源的无意义更新。因此，从所有待更新资源的整体角度而言，本申请实施例避免其中大量对无内容更新的待更新资源的更新，实现对局部资源的针对性更新。因此可以避免因对这部分无意义更新给处理器带来的负载，降低整体资源更新带来的负载，从而有效降低电子设备处理器负载，同时降低对电子设备造成的功耗。

3、针对日常出现频率较高的安装操作、更新操作和卸载操作，以及这些目标操作下关联存在较多组件列表无意义更新的实际场景，本申请实施例可以针对性的进行组件列表的更新控制。即在检测到这些目标操作时，可以针对这些预设服务的目标组件列表进行内容是否会发生变化的针对性分析，并仅对其中会发生内容变化的目标组件列表继续进行更新，停止对没有内容变化的目标组件列表的更新。因此本申请实施例可以有效降低对应用程序进行操作时，组件列表更新给处理器所带来的负载，降低系统功耗。

实际应用中，以安卓系统的电子设备为例进行测试为例，结合图5所示实施例进行组件列表更新控制。实际测试中，本申请实施例系统服务(SystemServer)的android.bg线程的处理器运行中(Running)负载能够降低40％。即在结合表2至表4相关实施例应用时，处理器在运行中状态下的负载可以降低40％。

在图5所示实施例的基础上，作为本申请的一个具体实施例，可以参考参考图6，是本申请实施例提供的一种资源更新控制方法的流程示意图。在本申请实施例中，目标操作包括安装操作、更新操作和卸载操作，以预设服务是账户与同步管理服务，目标组件列表包括：账户认证服务组件列表和账户同步服务组件列表。本申请实施例在接口generateServicesMap前增加了一个过滤器，该过滤器用于实现图5所示实施例。详述如下。

在接收到对应用程序安装操作对应的广播、卸载操作对应的广播或者更新操作对应的广播(本申请实施例中可简称为安装广播、卸载广播和更新广播)时，均可以判定为检测到了对应用程序的程序包的操作事件(handlePackageEvent)。

获取当前被操作的应用程序的程序包包名。

获取当前广播的类型，以确定出具体的目标操作时安装操作、更新操作还是卸载操作。

针对安装操作，判断当前程序包内是否包含账户与同步管理服务相关的组件。若包含组件，则继续对账户认证服务组件列表和账户同步服务组件列表的更新。若不包含，则停止对账户认证服务组件列表和账户同步服务组件列表的更新。

针对卸载操作，遍历缓存的账户认证服务组件列表和账户同步服务组件列表，判断是否记录有程序包中的组件信息。若有组件信息，则继续对账户认证服务组件列表和账户同步服务组件列表的更新。若没有组件信息，则停止对账户认证服务组件列表和账户同步服务组件列表的更新。

针对更新操作，判断当前程序包内是否包含账户与同步管理服务相关的组件，同时遍历缓存的账户认证服务组件列表和账户同步服务组件列表，判断是否记录有程序包中的组件信息(即判断两者是否和/或存在)。若满足其中任意条件，则继续对账户认证服务组件列表和账户同步服务组件列表的更新。若当前程序包内不包含账户与同步管理服务相关的组件，且账户认证服务组件列表和账户同步服务组件列表中没有记录有程序包中的组件信息，则停止对账户认证服务组件列表和账户同步服务组件列表的更新。

在继续对组件列表进行更新的情况下，可以调用更新组件列表的接口generateServicesMap。再查询程序包中账户认证服务组件和账户同步服务组件。最后基于查询出的组件，对账户认证服务组件列表和账户同步服务组件列表进行遍历更新，从而实现对缓存的组件列表的更新。

本申请实施例的具体实现细节、原理和效果等，可参考上述图2至图5相关的实施例说明，此处不予赘述。

对应于上文实施例所述的资源更新控制方法，图7示出了本申请实施例提供的资源更新控制装置的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图7，该资源更新控制装置包括：

资源确定模块71，用于在检测到对应用程序的目标操作时，确定出目标操作关联的若干个待更新资源。

分析模块72，用于分析在目标操作下，各个待更新资源的内容是否会发生变化。

停止更新模块73，用于对于待更新资源中内容不会发生变化的资源，不进行资源更新。

资源更新模块74，用于对于待更新资源中内容会发生变化的资源，进行资源更新。

本申请实施例提供的资源更新控制装置中各模块实现各自功能的过程，具体可参考前述图2至图6所示实施例以及其他相关方法实施例的描述，此处不再赘述。

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

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

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

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

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

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。还应理解的是，虽然术语“第一”、“第二”等在文本中在一些本申请实施例中用来描述各种元素，但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如，第一表格可以被命名为第二表格，并且类似地，第二表格可以被命名为第一表格，而不背离各种所描述的实施例的范围。第一表格和第二表格都是表格，但是它们不是同一表格。

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

本申请实施例提供的资源更新控制方法可以应用于手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等电子设备上，本申请实施例对电子设备的具体类型不作任何限制。

例如，所述电子设备可以是WLAN中的站点(STATION，ST)，可以是蜂窝电话、无绳电话、会话启动协议(Session InitiationProtocol，SIP)电话、无线本地环路(WirelessLocal Loop，WLL)站、个人数字处理(Personal Digital Assistant，PDA)设备、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、车联网终端、电脑、膝上型计算机、手持式通信设备、手持式计算设备、卫星无线设备、无线调制解调器卡、电视机顶盒(set top box，STB)、用户驻地设备(customer premise equipment，CPE)和/或用于在无线系统上进行通信的其它设备以及下一代通信系统，例如，5G网络中的电子设备或者未来演进的公共陆地移动网络(Public Land Mobile Network，PLMN)网络中的电子设备等。

作为示例而非限定，当所述电子设备为可穿戴设备时，该可穿戴设备还可以是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上，或是整合到用户的衣服或配件的一种便携式设备。可穿戴设备不仅仅是一种硬件设备，更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能，如智能手表或智能眼镜等，以及只专注于某一类应用功能，需要和其它设备如智能手机配合使用，如各类进行体征监测的智能手环、智能首饰等。

图8是本申请一实施例提供的电子设备的结构示意图。如图8所示，该实施例的电子设备8包括：至少一个处理器80(图8中仅示出一个)、存储器81，所述存储器81中存储有可在所述处理器80上运行的计算机程序82。所述处理器80执行所述计算机程序82时实现上述各个资源更新控制方法实施例中的步骤，例如图2所示的步骤101至104。或者，所述处理器80执行所述计算机程序82时实现上述各装置实施例中各模块/单元的功能，例如图7所示模块71至74的功能。

所述电子设备8可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述电子设备可包括，但不仅限于，处理器80、存储器81。本领域技术人员可以理解，图8仅仅是电子设备8的示例，并不构成对电子设备8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述电子设备还可以包括输入发送设备、网络接入设备、总线等。

所称处理器80可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器81在一些实施例中可以是所述电子设备8的内部存储单元，例如电子设备8的硬盘或内存。所述存储器81也可以是所述电子设备8的外部存储设备，例如所述电子设备8上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(SecureDigital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器81还可以既包括所述电子设备8的内部存储单元也包括外部存储设备。所述存储器81用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器81还可以用于暂时地存储已经发送或者将要发送的数据。

另外，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

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

本申请实施例提供了一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行时可实现上述各个方法实施例中的步骤。

本申请实施例还提供了一种芯片系统，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述各个方法实施例中的步骤。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读存储介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。

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

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

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

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

Claims (11)

1.一种资源更新控制方法，其特征在于，所述方法包括：

在检测到对应用程序的目标操作时，确定出所述目标操作关联的若干个待更新资源；

分析在所述目标操作下，各个所述待更新资源的内容是否会发生变化；

对于所述待更新资源中内容不会发生变化的资源，不进行资源更新；

对于所述待更新资源中内容会发生变化的资源，进行资源更新。

2.根据权利要求1所述的资源更新控制方法，其特征在于，所述待更新资源为列表资源，第一列表为任一所述待更新资源；

所述分析在所述目标操作下，各个所述待更新资源的内容是否会发生变化的操作中，包括：

分析在响应所述目标操作的过程中，所述第一列表中记录的数据是否会发生数据变化，所述数据变化包括：删除数据、新增数据以及替换数据。

3.根据权利要求1或2所述的资源更新控制方法，其特征在于，所述待更新资源为目标组件列表；

所述在检测到对应用程序的目标操作时，确定出所述目标操作关联的若干个待更新资源，包括：

在检测到对所述应用程序的所述目标操作时，确定出所述目标操作关联的若干个预设服务；

确定出各个所述预设服务下属的所述目标组件列表。

4.根据权利要求3所述的资源更新控制方法，其特征在于，所述预设服务包括：无障碍管理服务、搜索管理服务和账户与同步管理服务中的任意服务。

5.根据权利要求3所述的资源更新控制方法，其特征在于，所述目标操作为安装操作、更新操作或卸载操作。

6.根据权利要求5所述的资源更新控制方法，其特征在于，第一组件列表为任一所述目标组件列表；所述分析在所述目标操作下，各个所述待更新资源的内容是否会发生变化，包括：

当所述目标操作为安装操作时，分析所述应用程序的程序包中是否包含有所述第一组件列表所需记录的组件；

当所述程序包中未包含有所述第一组件列表所需记录的组件时，判定为所述第一组件列表的内容不会发生变化。

7.根据权利要求5所述的资源更新控制方法，其特征在于，第一组件列表为任一所述目标组件列表；所述分析在所述目标操作下，各个所述待更新资源的内容是否会发生变化，包括：

当所述目标操作为卸载操作时，分析所述第一组件列表中是否记录有所述应用程序的组件信息；

当所述第一组件列表中未记录所述应用程序的组件信息时，判定为所述第一组件列表的内容不会发生变化。

8.根据权利要求5所述的资源更新控制方法，其特征在于，第一组件列表为任一所述目标组件列表；所述分析在所述目标操作下，各个所述待更新资源的内容是否会发生变化，包括：

当所述目标操作为更新操作时，分析所述应用程序的程序包中是否包含有所述第一组件列表所需记录的组件，并分析所述第一组件列表中是否记录有所述应用程序的组件信息；

当所述程序包中未包含有所述第一组件列表所需记录的组件，且所述第一组件列表中未记录所述应用程序的组件信息时，判定为所述第一组件列表的内容不会发生变化。

9.根据权利要求5所述的资源更新控制方法，其特征在于，所述更新操作包括：版本更新操作、内容更新操作以及权限更新操作。

10.一种电子设备，其特征在于，所述电子设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至9任一项所述资源更新控制方法。

11.一种芯片系统，其特征在于，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现如权利要求1至7任一项所述的资源更新控制方法。