CN117707561A - 卡片数据的更新方法、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请提供卡片数据的更新方法、电子设备及计算机可读存储介质。方法包括：电子设备获取第一应用为第一卡片设置的更新策略；其中，第一卡片由第一应用提供，更新策略包括对应于第一卡片的至少一个数据源的访问路径、以及更新条件；电子设备检测到第一卡片满足更新条件；电子设备从第一卡片对应的至少一个数据源获取更新数据，并将更新数据提供给第二应用；电子设备基于更新数据更新第一卡片。本申请方案能够实现从数据源获取更新数据来更新相应服务卡片内容的过程，无需提供相应卡片的应用程启动或者常驻运行，有利于减小卡片数据更新需运行相关应用程序所导致的系统功耗。

Description

卡片数据的更新方法、电子设备及计算机可读存储介质

技术领域

本发明涉及电子设备技术领域，具体涉及一种卡片数据的更新方法、电子设备及计算机可读存储介质。

背景技术

为了便于用户查看和使用各类应用程序(application，APP)的服务信息，不同的应用程序可以生成不同的快服务卡片，并可以将这类卡片添加在电子设备的某个显示界面上。例如将卡片添加在桌面上，从而增加桌面的功能性，便于用户查看该卡片提供的实时数据。快服务卡片可以称为应用卡片，以下简称卡片。

然而，目前电子设备显示的卡片在更新关联应用数据的过程中，电子设备需要运行该卡片关联的应用程序或者使关联应用程序保持运行状态，系统才能够将关联应用数据更新到相应的卡片上显示。如此，会导致电子设备系统功耗增加，并且保持运行状态的应用程序也会大量占用系统的运行内存，影响系统性能。

发明内容

为解决目前更新卡片数据时需要保持提供卡片服务的应用程序运行，以致系统功耗增加或者数据更新时延较大等问题，本申请提供了一种卡片数据的更新方法、电子设备及计算机可读存储介质。

第一方面，本申请提供了一种卡片数据的更新方法，应用于电子设备，电子设备包括第一应用和第二应用，该方法包括：电子设备获取第一应用为第一卡片设置的更新策略；其中，第一卡片由第一应用提供，更新策略包括对应于第一卡片的至少一个数据源的访问路径、以及更新条件；电子设备检测到第一卡片满足更新条件；电子设备从第一卡片对应的至少一个数据源获取更新数据，并将更新数据提供给第二应用；电子设备基于更新数据更新第一卡片。

例如，上述第一应用可以是卡片提供方应用程序，比如天气APP、运动健康APP、微博TMAPP等。相应地，上述第一卡片例如可以是天气卡片、运动健康卡片、微博TM热点卡片等。上述第二应用例如可以是卡片使用方应用程序，桌面APP、智慧生活APP等。上述更新策略，例如可以是卡片提供方创建卡片时设置的数据更新策略，可以用于实现对第一卡片的数据的定时更新或者在第一卡片相应的数据变化时进行更新等。具体将在下文详细介绍，在此不做赘述。

上述第一方面提供的方法，即电子设备获取卡片提供方为相应卡片设置的数据更新策略，进而电子设备可以根据该更新策略为卡片使用方获取更新数据，以更新相应卡片的内容。其中，第二应用在需要更新所显示的第一卡片对应的数据时，可以根据对应于第一卡片的更新策略，从数据源直接获取待更新数据完成更新。如此，无需第一应用运行，第二应用也可以更新卡片数据，并且可以简化数据流转过程，提高数据流转效率，有利于提高电子设备性能及用户使用体验。

在上述第一方面的一种可能的实现中，上述方法还包括：电子设备从第一卡片对应的至少一个数据源获取更新数据，包括：基于更新策略中至少一个数据源的访问路径，电子设备从至少一个数据源获取更新数据。

即电子设备可以直接根据更新策略中给出的数据源访问路径，访问数据源并读取相应数据来更新第一卡片的内容。例如，上述数据源可以是系统，也可以是云端等。其中，访问系统可以获取的相关数据例如可以是步数，用于更新运动健康卡片显示的步数等。

在上述第一方面的一种可能的实现中，电子设备检测到第一卡片满足更新条件，包括：电子设备在系统中注册监听事件，其中监听事件的监听参数包括至少一个数据源的访问路径；监听到至少一个数据源中的数据发生变化，电子设备确定第一卡片满足更新条件。

即第一卡片对应的更新条件对应限定的数据更新时机，例如可以是监听到相应数据源的相应数据发生变化时，便可以确定相应的卡片满足更新条件。例如上述第一卡片为运动健康卡片，当监听到步数发生变化时，该运动健康卡片便满足相应的更新条件。

在上述第一方面的一种可能的实现中，电子设备检测到第一卡片满足更新条件，包括：电子设备检测到系统时间到达更新条件指定的更新时间；或者，电子设备检测到第一卡片更新的时间间隔达到更新条件指定的时间间隔阈值。

即第一卡片对应的更新条件对应限定的数据更新时机，例如也可以是达到该更新条件对应限定的更新时间或者时间间隔阈值时，便可以确定相应的卡片满足更新条件。例如上述第一卡片为天气卡片，该天气卡片上的天气数据可以每隔30分钟更新一次。

第二方面，本申请提供了一种卡片数据的更新方法，应用于电子设备，电子设备包括第一应用、第二应用和卡片管理服务，方法包括：卡片管理服务获取第一应用为第一卡片设置的更新策略；其中，第一卡片由第一应用提供，更新策略包括对应于第一卡片的至少一个数据源的访问路径、以及更新条件；卡片管理服务检测到第一卡片满足更新条件；卡片管理服务从第一卡片对应的至少一个数据源获取更新数据，并向第二应用发送更新数据；第二应用基于更新数据更新第一卡片。

例如，上述第一应用是卡片提供方，上述第二应用是卡片使用方，上述卡片管理服务是电子设备的系统提供的一种用于管理卡片的服务。上述第二方面提供的方案，即卡片管理服务可以根据卡片提供方为相应卡片设置的更新策略，从该更新策略提供的数据源获取相应卡片的数据，提供给卡片使用方用于更新卡片内容。

在上述第二方面的一种可能的实现中，卡片管理服务获取第一应用为第一卡片设置的更新策略，包括：卡片管理服务响应于在第二应用的界面上添加第一卡片的添加请求，向第一应用发送运行指令；第一应用响应于运行指令，向卡片管理服务发送数据包，并向卡片管理服务设置对应于第一卡片的更新策略；卡片管理服务获取第一应用为第一卡片设置的更新策略，并向第二应用转发数据包。

上述第二应用例如可以是卡片使用方，比如桌面。上述第二方面提供的一种可能的实现方案，例如可以是电子设备通过卡片管理服务，来响应用户在桌面上添加卡片的操作请求。相应地，卡片管理服务可以发起对卡片提供方应用程序的运行请求。

在上述第二方面的一种可能的实现中，卡片管理服务从第一卡片的至少一个数据源获取更新数据，包括：基于更新策略中至少一个数据源的访问路径，卡片管理服务从至少一个数据源获取更新数据。

即电子设备可以通过卡片管理服务访问数据源获取更新数据，提供给卡片使用方用于更新卡片内容。

在上述第二方面的一种可能的实现中，卡片管理服务检测到第一卡片满足更新条件，包括：卡片管理服务向电子设备的系统注册监听事件，其中监听事件的监听参数包括至少一个数据源的访问路径；监听到至少一个数据源中的数据发生变化，卡片管理服务确定第一卡片满足更新条件。

即电子设备可以通过卡片管理服务向系统注册监听事件，来监听数据源的变化，从而在数据发生变化时，确定第一卡片满足更新条件。

在上述第二方面的一种可能的实现中，卡片管理服务检测到第一卡片满足更新条件，包括：卡片管理服务检测到系统时间到达更新条件指定的更新时间；或者，卡片管理服务检测到第一卡片更新的时间间隔达到更新条件指定的时间间隔阈值。

即电子设备可以通过卡片管理服务检测系统时间是否达到更新条件指定更新时间，或者通过卡片管理服务检测指定更新卡片数据的时间间隔是否达到更新条件指定的时间间隔阈值。

第三方面，本申请提供了一种卡片数据的更新方法，应用于电子设备，电子设备包括第一应用和第二应用，第二应用显示第一应用的第一卡片，该方法包括：电子设备基于第一卡片对应的更新策略，检测到第一应用满足更新条件，其中更新策略包括对应于第一卡片的至少一个数据源的访问路径、以及更新条件；在不运行第一应用的情况下，电子设备从至少一个数据源获取更新数据，其中，更新数据用于更新第一卡片的显示内容。

即电子设备可以直接从数据源获取更新数据，并在更新第二应用显示的第一卡片的显示内容的过程中，提供该第一卡片的第一应用可以不运行。如此，可以有利于减小系统功耗，所减小的系统功耗包括第一应用的运行功耗或启动功耗等。

第四方面，本申请提供了一种卡片数据的更新方法，应用于电子设备，电子设备包括第一应用、第二应用和卡片管理服务，方法包括：第二应用显示第一卡片，其中第一卡片由第一应用提供；卡片管理服务检测到第一卡片满足更新条件；在不运行第一应用的情况下，卡片管理服务从对应第一应用的数据源获取更新数据；第二应用基于卡片管理服务发送的更新数据更新第一卡片。

即电子设备可以通过卡片管理服务直接从数据源获取更新数据，并在更新第二应用显示的第一卡片的显示内容的过程中，提供该第一卡片的第一应用可以不运行。如此，可以有利于减小系统功耗，所减小的系统功耗包括第一应用的运行功耗或启动功耗等。

第五方面，本申请提供了一种电子设备，其特征在于，包括：一个或多个处理器；一个或多个存储器；一个或多个存储器存储有一个或多个程序，当一个或者多个程序被一个或多个处理器执行时，使得电子设备执行上述第一方面至第四方面提供的卡片数据的更新方法。

第六方面，本申请提供了一种计算机可读存储介质，其特征在于，存储介质上存储有指令，指令在计算机上执行时使计算机执行上述第一方面至第四方面提供的卡片数据的更新方法。

第七方面，本申请提供了一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现上述第一方面至第四方面提供的卡片数据的更新方法。

综上，本申请提供的卡片数据的更新方法、电子设备及计算机可读存储介质，能够在不运行提供卡片的应用程序的情况下，更新相应卡片数据，因而可以避免因卡片关联应用程序的反复启动或常驻运行导致的功耗增加问题。并且，基于本申请提供的卡片数据的更新方法，使得卡片数据更新过程得以简化，数据流转效率也较高，有利于提高电子设备性能以及用户的使用体验。

附图说明

图1所示为一种卡片数据更新场景示意图。

图2所示为一种系统软件结构示意图。

图3所示为本申请实施例提供的一种系统软件结构示意图。

图4所示为本申请实施例提供的一种卡片数据的更新方法的流程图。

图5a所示为本申请实施例提供的一种桌面示意图。

图5b所示为本申请实施例提供的一种待编辑桌面示意图。

图5c所示为本申请实施例提供的另一种桌面示意图。

图6所示为本申请实施例提供的一些运动健康卡片的显示内容样式示意图。

图7所示为本申请实施例提供的一些天气卡片的显示内容样式示意图。

图8所示为本申请实施例提供的卡片数据的更新方法在系统架构内部的实现过程示意图。

图9a所示为本申请实施例提供的一种数据更新策略对应的卡片数据的更新方法的流程图。

图9b所示为本申请实施例提供的另一种数据更新策略对应的卡片数据的更新方法的流程图。

图10所示为本申请实施例提供的一种手机100的硬件结构示意图。

图11所示为本申请实施例提供的一种手机100的系统架构示意框图。

具体实施方式

为了使本申请实施例的目的、技术方案和优点更加清楚，下面将结合说明书附图以及具体的实施方式对本申请实施例中的技术方案进行详细的说明。

还需声明的是，本申请实施例中对方法、流程中的步骤进行编号是为了便于引用，而不是限定先后顺序，各步骤之间如有先后顺序，当以文字说明为准。

卡片可理解为一种窗口小部件，在安卓TM系统中可以称为微件(widget)，而在iOSTM系统中又可称为小组件。卡片可以与某个应用关联，例如关联时钟、备忘录、运动健康、微博TM或者天气等应用。卡片具有相关应用的部分功能，用户直接与卡片进行交互即可实现该应用的部分功能。一个应用可以提供一个或多个卡片，用户可以根据个人需求在桌面添加卡片，电子设备也可以根据用户对应用程序的使用频率等主动添加一些卡片到桌面。添加到桌面的卡片便可以展示关联应用更新的推送消息、热点新闻或者更新的时钟信息、步数、天气等实时数据。

图1示出了一种卡片数据更新场景示意图。

如图1所示，该场景以手机100为例，手机100的桌面上添加有天气卡片101、运动健康卡片102以及微博TM卡片103等。这些卡片所显示内容通常需要定时更新，比如天气卡片101上可以每小时更新天气状态以及气温等；运动健康卡片102可以在检测到步数变化时，更新卡片步数；微博TM卡片103上可以定时更新实时的热搜消息或者热点新闻等；以及，日历卡片可以在新增行程时更新行程提醒、优酷TM卡片可以在热播剧集更新时更新剧集推送消息等，在此不做限制。

可以理解，当卡片数据更新时卡片显示内容便会相应更新。参考图1所示，例如手机100桌面上的天气卡片101气温可以由“29℃”更新为“31℃”，运动健康卡片102上步数可以由“500步”更新为“2413步”等。

为了便于描述，上述图1场景中显示卡片并使用该卡片关联的应用数据来更新卡片显示内容的应用程序，在本申请实施例的以下描述中将称之为“卡片使用方”，例如桌面APP智慧生活APP等应用程序。上述图1所示场景中提供卡片服务的应用程序，在本申请实施例中称之为“卡片提供方”，例如天气APP、运动健康APP、微博TMAPP等应用程序。也就是说，卡片使用方和卡片提供方都是指应用程序，卡片使用方、卡片使用方既可以是系统应用，也可以是非系统应用。其中，系统应用是指在正常使用过程中不会提供卸载选项的应用程序，非系统应用是指可以根据用户需求进行安装或卸载的应用程序。

另外，需说明的是，在本申请实施例的上下文描述中，如无特别说明，“系统”或“操作系统”，均是指实施本申请实施例提供的卡片数据的更新方法的手机等电子设备所搭载的操作系统，例如HarmonyOSTM、安卓TM系统以及iOSTM系统等，在此不做限制。

如前所述，对于上述图1所示的卡片数据更新场景，目前的卡片数据更新方案需要依赖于卡片提供方处于运行状态。例如，卡片提供方在需要更新卡片数据时启动，或者该卡片提供方需要在系统中长时间保持运行状态，才能够向所提供的卡片提供待更新数据。在一些实施例中，上述能在系统中长时间保持运行状态的应用程序，也可以称之为常驻应用，该长时间保持运行状态因此也可以称之为“常驻运行”，在此不做限制。

参考图2所示的一种系统软件结构示意图，在手机100中，卡片使用方201可以向卡片管理服务(Form manager service，FMS)202请求添加、删除或者请求更新卡片等服务。卡片管理服务202基于上述请求可以向卡片提供方203获取相应的卡片服务。而卡片提供方203在对应的应用进程创建后，可以创建卡片，以向卡片管理服务202提供卡片相关数据。卡片提供方203也可以响应于卡片管理服务202代理转发的删除请求删除卡片、或者主动向卡片管理服务202通知更新卡片数据等。

其中，卡片使用方201与卡片管理服务202之间、以及卡片管理服务202与卡片提供方203之间，可以通过通信适配器基于远程过程调用协议(Remote Procedure CallProtocol，RPC)实现通信。卡片管理服务202所提供的卡片数据托管、卡片缓存管理、卡片生命周期管理以及卡片使用对象管理等卡片管理功能，可以对卡片使用方所请求的卡片进行缓存、获取以及数据更新等。卡片管理服务202可以实现卡片使用方201与卡片提供方203之间的通信，便于卡片提供方203提供相应卡片服务。

继续参考图2，当卡片使用方201上显示的卡片需要更新数据时，卡片管理服务202通常需要向卡片提供方203请求获取卡片数据。该过程可以参考图2所述的数据流转过程“1.请求获取卡片数据”。

卡片提供方203可以响应卡片管理服务202发来的请求，基于更新后的应用数据生成待更新的卡片数据，并返回给卡片管理服务202。该过程可以参考图2所示的数据流转过程“2.返回(主动更新)卡片数据”。可以理解，卡片提供方203也可以在应用数据更新时，主动更新卡片数据，其中卡片提供方203更新的应用数据可以来自于相应的数据源，该数据源将在下文详细描述，在此不做赘述。

进而，卡片管理服务202可以基于与卡片提供方203之间的RPC通信，获取待更新的卡片数据。该过程可以参考图2所示的数据流转过程“3.获取待更新的卡片数据”。之后，卡片使用方201可以基于与卡片管理服务202之间的RPC通信，获取待更新的卡片数据。该过程可以参考图2所示的数据流转过程“4.获取卡片数据，更新卡片内容”。

可以理解，在一些实施例中，卡片提供方203上的应用数据没有更新时，卡片提供方203也可以在满足更新条件时，更新相应的卡片数据。例如卡片提供方203在满足定时更新卡片数据对应的定时条件时，可以更新相应卡片数据。

可见，在图2所示的卡片数据更新过程中，作为卡片提供方203的应用程序需要处于运行状态，例如该应用程序在系统上常驻运行。如此，会导致的系统功耗增加，并且大量占用系统内存，导致手机100等电子设备出现发热、卡顿等问题。

另外，手机100等电子设备为了降低设备功耗，通常会限制一些应用程序的常驻运行，如此，便需要在更新卡片数据时启动运行这些应用程序。而这些与卡片关联的应用程序的启动运行需要时间，也可能会导致数据更新时延较大。

为了解决上述问题，本申请实施例提供了一种数据更新方法，应用于电子设备。该方法通过在添加卡片时，由卡片提供方向操作系统中的卡片管理服务注册相应的卡片数据更新策略。该数据更新策略包括该卡片提供方提供的卡片数据的数据源以及数据更新触发条件，该数据更新策略可以根据该卡片提供方自身的应用数据更新规律确定。在卡片管理服务向卡片使用方添加卡片后，该卡片管理服务可以直接基于卡片提供方提供的上述数据更新策略，在检测到该策略提供的数据更新触发条件满足时，可以直接从数据源处获取相应数据，从而更新相应的卡片数据。

在一些实施例中，该数据更新触发条件可以是定时触发条件。例如对于天气卡片，当设定的30分钟时间间隔达到时，便可以确定该定时触发条件满足，此时则可以从提供天气数据的网站等数据源处获取天气数据，更新天气卡片。该数据更新触发条件也可以是基于监听机制的触发条件，比如检测到卡片相关的数据发生变化时进行数据更新。例如对于运行健康卡片，在检测到用户的步数数据变化时，便可以确定数据更新触发条件满足，此时则可以更新运动健康卡片上的步数。在此不做限制。

在一些实施例中，对于已添加的卡片，当卡片数据需要更新时，作为卡片提供方的应用程序无需运行，卡片使用方可以通过卡片管理服务从数据源处获取待更新数据，该待更新数据可以用于实现卡片数据的更新并更新卡片显示内容。基于此，基于本申请方案的电子设备可以避免因卡片关联应用程序的反复启动或常驻运行导致的功耗增加问题。在避免了系统功耗增加的同时，卡片使用方仍能及时更新卡片数据。与图1对应的实施例不同，由数据源提供的数据可以直接发送给卡片管理服务，再通过卡片管理服务到达卡片使用方，过程得以简化，数据流转效率也较高，有利于提高电子设备性能以及用户的使用体验。

可以理解，本申请实施例所提供的卡片数据的更新方法，所适用的电子设备可以包括但不限于手机、平板电脑、桌面型、膝上型、手持计算机、上网本，以及增强现实(augmentedreality，AR)\虚拟现实(virtual reality，VR)设备、智能电视、智能手表等可穿戴设备、服务器、移动电子邮件设备、车机设备、便携式游戏机、便携式音乐播放器、阅读器设备、其中嵌入或耦接有一个或多个处理器的电视机、或能够访问网络的其他电子设备。

图3根据本申请实施例示出了一种系统软件结构示意图。

如图3所示，手机100的软件结构中包括卡片使用方301、卡片管理服务302、卡片提供方303以及数据源304。

与上述图2所示软件结构的不同之处在于，该手机100的卡片管理服务302还可以包括数据更新策略管理模块，用于管理卡片提供方303在提供卡片服务时为所提供卡片设置的数据更新策略。可以理解，该数据更新策略管理模块管理数据更新策略，可以用于存储、调用、删除相应卡片的数据更新策略等，在此不做限制。

参考图3所示，当卡片使用方301需要添加某个应用的卡片时，卡片管理服务302可以将添加卡片的请求发送给卡片提供方303。卡片提供方303对应的应用程序运行后，便可以响应于添加卡片的请求，创建相应的卡片。应理解，卡片提供方303也可以对已经创建的卡片进行删除、以及通知卡片使用方更新卡片相关数据等功能，在此不做赘述。

卡片提供方303完成卡片创建后，可以通过RPC通信将该卡片相关数据发送给卡片管理服务302。卡片管理服务302则可以将卡片相关数据提供给卡片使用方301以完成卡片添加。

在一些实施例中，卡片提供方303创建卡片提供卡片服务时，可以对所创建卡片设置数据更新策略，并通过RPC通信将该数据更新策略设置到卡片管理服务302中。如此，卡片管理服务302则可以根据卡片提供方303设置的数据更新策略，向数据源304获取待更新数据，并转发给卡片使用方301进行数据更新。待更新数据对应的数据源304访问路径可以设置在数据更新策略中，以便于卡片管理服务302能够访问数据源304。如此，在上述数据更新过程中，卡片管理服务302无需创建卡片提供方进程，便可实现卡片数据的及时更新。并且，待更新数据直接从数据源获取，数据流转过程简化，数据的获取及更新效率也会更高。

可以理解，上述图3所示的卡片使用方301、卡片提供方303分别可以是手机100上安装的任一应用程序，例如桌面APP、天气APP、日历APP等，在此不做限制。因而，卡片使用方301、卡片提供方303可以设置于手机100系统架构的应用程序层，具体将在下文详细介绍，在此不做赘述。

上述图3所示的卡片管理服务302则可以位于手机100系统架构的应用程序框架层或者系统库中，以提供上述各种卡片管理功能服务，具体也将在下文详细介绍，在此不做赘述。另外，提供待更新数据的数据源304，可以是系统本身或者云端等，在此不做限制。

图3根据本申请实施例示出了一种卡片数据的更新方法在系统架构内部的实现过程示意图。

如图3所示，在应用了本申请的数据更新方案的手机100上，卡片使用方301在向卡片管理服务302请求添加卡片后，卡片管理服务302基于请求创建卡片提供方303的应用进程。

在一些实施例中，卡片提供方303可以在提供相应卡片服务时向卡片管理服务302设置数据更新策略。其中，该数据更新策略例如可以包括所提供卡片服务对应数据的数据源304的访问路径以及数据更新触发条件等。该数据源304例如可以是系统，比如华为移动核心服务(HUAWEI Mobile Services Core，HMS Core)；也可以是云端等。其中系统可以提供一些系统数据，例如基于加速度传感器、陀螺仪传感器等传感器数据所确定的步数等，系统中的HMS Core例如可以提供用户添加的行程、用户预定的会议等相关数据、以及位置服务等核心功能确定的步数、位置等数据。云端例如可以提供一些网络数据、以及第三方应用的云服务平台上更新的数据等，例如天气APP对应云端提供的气象数据、优酷TM云可以为优酷TM对应云端提供的视频资讯、京东TMAPP对应云端提供的优惠活动推送消息等，在此不做限制。

可以理解，在本申请实施例中，上述HMS Core作为系统的组成部分，所提供的数据也属于系统数据。在另一些实施例中，系统也可以包括其他类型的核心服务，作为提供行程、步数、位置等数据的数据源，在此不做限制。

另外，上述数据更新触发条件可以是定时触发条件。例如天气卡片可以每30分钟更新一次天气数据等。上述数据更新触发条件也可以是基于监听机制的触发条件，比如检测到数据变化即更新的触发条件。例如运行健康卡片可以在检测到步数变化时便更新步数等，在此不做限制。

继续参考图3所示，卡片管理服务302可以基于卡片提供方303设置的数据更新策略，在检测到满足数据更新触发条件时，从相应卡片的数据源304获取数据并发送给卡片使用方301进行数据更新。

下面将基于上述图1所示的场景、以及图3所示的系统架构，结合具体流程图详细介绍本申请实施例提供的数据更新方案。

图4根据本申请实施例示出了一种卡片数据的更新方法的流程图。

如图4所示，该流程包括以下步骤：

401：卡片使用方301检测到添加卡片的请求。

示例性地，卡片使用方301例如可以是桌面APP。卡片使用方301检测到添加卡片的请求，例如可以包括但不限于以下情形：

手机100在运行桌面APP时，显示的默认桌面可以包括默认添加的卡片。参考图5a所示的桌面510，例如该桌面510上默认添加的卡片可以包括图5a所示的天气卡片511和运动健康卡片512。其中，天气卡片511可以包括多个控件，例如可以包括时钟、天气以及日历等控件。可以理解，在另一些实施例中，手机100的桌面默认添加的卡片也可以是不同于图5a所示其他卡片及样式，在此不做限制。

用户可以在手机100显示的桌面上进行添加卡片的操作。参考图5b所示，例如用户在桌面上长按运动健康卡片，则手机100可以显示图5b所示的待编辑桌面520。该待编辑桌面520上可以显示可操作的弹窗521，用户点击该弹窗521中的“更多卡片服务”则可以选择需要添加到桌面上的卡片。可以理解，在另一些实施例中，用户在手机100的显示界面上添加卡片的操作也可以是其他操作，例如在桌面上“捏一捏”并选择待添加的卡片等，在此不做限制。

手机100在运行桌面APP的过程中，可以统计用户对各应用程序的使用频率，主动发起添加应用卡片到桌面的过程。参考图5c所示，例如手机100运行的桌面APP检测到用户使用微博TM应用频率较高，则可以请求添加图5c所示桌面530上的微博TM卡片531。又例如，手机100运行的桌面APP检测到用户使用微信TMAPP以及京东TMAPP的频率也较高，还可以请求添加图5c所示桌面530上的微信TM卡片532以及京东TM卡片533等。

402：卡片使用方301向卡片管理服务302发送对相应卡片的添加请求。

示例性地，卡片使用方301在检测到添加卡片的请求时，可以向卡片管理服务302发起对相应卡片的添加请求。该添加请求中可以包括执行添加的卡片对应的卡片提供方的应用识别信息(identification，ID)，以及卡片使用方301的应用ID等。例如，卡片使用方301为桌面APP时，若需要添加运动健康卡片，则桌面APP向卡片管理服务302发送的添加请求中可以包括桌面APP的识别信息以及运动健康APP的识别信息。

403：卡片管理服务302基于添加请求，确定相应卡片提供方的应用识别信息。

示例性地，卡片管理服务302接收到卡片使用方301发来的相应卡片的添加请求中，包括请求添加的卡片提供方的应用ID。因此，卡片管理服务302可以从接收到的添加请求中确定，确定相应卡片提供方的应用ID。可以理解，该卡片提供方的应用ID可以用于创建相应的应用进程，以通过该应用进程对应的应用程序来提供卡片。

404：卡片管理服务302向卡片提供方303发送运行指令以及对待添加卡片相关数据的获取请求。

示例性地，卡片管理服务302可以基于相应卡片提供方的应用ID，生成发送给相应的卡片提供方303的运行指令，以启动该卡片提供方303。例如，卡片使用方301为桌面APP，当需要添加运动健康卡片，卡片管理服务302可以向运动健康APP发送运行指令，以使手机100运行该运动健康APP。另外，卡片管理服务302还可以向该卡片提供方303发送获取待添加卡片相关数据的请求。其中，待添加卡片相关数据可以包括待添加卡片的显示样式、以及初始显示内容等数据，在此不做限制。

在另一些实施例中，上述对待添加卡片相关数据的获取请求也可以包含在运行指令中，当卡片提供方303对应的应用程序启动时，卡片提供方303可以基于运行指令向卡片管理服务302返回待添加卡片相关数据，在此不做限制。

405：卡片提供方303启动运行，并生成待添加卡片相关的初始数据包。

示例性地，卡片提供方303响应于卡片管理服务302发来的运行指令，可以向系统创建应用进程，进而生成待添加卡片相关的初始数据包。可以理解，当手机100上已经在运行作为卡片提供方的应用程序，该卡片提供方303则可以直接基于卡片管理服务302发来的获取请求，生成待添加卡片相关的初始数据包。例如，卡片提供方303为运动健康APP，则该运动健康APP启动运行后可以将当前已获取的步数数据以及卡片样式数据等作为待添加卡片相关的初始数据，生成相应初始数据包。

可以理解，上述初始数据包可以为卡片添加到卡片使用方301的界面上时提供显示数据，以显示初始的卡片内容。待卡片数据更新后，所添加的卡片则可以根据更新后的卡片数据显示相应的内容。

可以理解，同一应用程序可以是多个卡片的卡片提供方303，即一个卡片提供方303可以响应于创建卡片的请求生成多个待添加卡片以及相关初始数据包。并且，卡片提供方303在生成待添加卡片相关的初始数据包时，可以为该待添加卡片分配一个身份识别信息，作为卡片ID，以用于标识该卡片。例如，微博TMAPP可以为微博TM热点卡片、微博TM热搜卡片、微博TM活动卡片等卡片分配各自唯一的卡片ID。

406：卡片提供方303向卡片管理服务302发送所生成的初始数据包。

示例性地，卡片提供方303响应于对待添加卡片相关数据的获取请求，可以将生成的待添加卡片相关的初始数据包，发送给卡片管理服务302。

407：卡片管理服务302向卡片使用方301转发待添加卡片相关的初始数据包。

示例性地，卡片管理服务302在接收到卡片提供方303发来的初始数据包后，可以向卡片使用方301转发该初始数据包，以供卡片使用方301完成相应卡片的添加。

408：卡片使用方301基于初始数据包显示卡片内容，完成卡片添加。

示例性地，卡片使用方301基于接收到的初始数据包，可以调用系统的绘制渲染进程，完成待添加卡片显示内容的绘制渲染，并显示在相应的卡片窗口中。

例如，卡片使用方301为桌面APP时，桌面APP根据卡片管理服务302转发来的步数数据以及卡片样式数据等，调用系统的绘制渲染进程进行卡片显示内容的绘制渲染，进而在桌面上显示出相应样式的运动健康卡片以及步数。该运动健康卡片的显示内容可以参考图6所示各种样式的显示内容，该样式既可以是用户指定的样式，也可以是默认设置的样式，在此不做限制。在另一些实施例中，手机100桌面所显示的运动健康卡片的显示内容也可以是不同于图6所示的其他样式，在此不做限制。

又例如，桌面APP上所添加卡片为天气卡片时，提供该卡片的天气APP则可以向卡片管理服务302提供相应的初始数据包，该初始数据包可以包括初始天气数据以及卡片样式数据等。进而，桌面APP可以根据卡片管理服务302转发来的初始天气数据以及卡片样式数据等，在桌面上显示出相应样式的天气卡片。该天气卡片的显示内容可以参考图7所示各种样式的显示内容，该样式既可以是用户指定的样式，也可以是默认设置的样式，在此不做限制。在另一些实施例中，手机100桌面所显示的天气卡片的显示内容也可以是不同于图7所示的其他样式，在此不做限制。

409：卡片提供方303向卡片管理服务302设置卡片数据更新策略。

示例性地，该卡片数据更新策略可以包括待更新数据的卡片ID、提供待更新数据的数据源304相关信息、数据更新触发条件等。其中，该数据源304相关信息，例如可以包括数据源304的接口参数、网址等路径信息，以及其他可以从数据源304中获取待更新数据的信息，在此不做限制。数据更新触发条件，用于确定数据更新的时机，包括定时更新数据或者基于监听机制的触发条件等，在此不做限制。

可以理解，当卡片提供方303对应于不同的应用程序时，该卡片提供方303设置的数据更新策略可以有所不同。例如，当卡片提供方303为时钟APP时，时钟APP对添加到桌面的天气卡片中时钟控件设置的数据更新策略可以是：每分钟向系统获取同步时间并更新事件信息。又例如，当卡片提供方303为日历APP，日历APP设置的数据更新策略则可以是：向HMS Core注册监听事件以监听日程数据库中的数据变化，当日程数据库中发生日程数据变化时，更新日历卡片上的日程数据并在卡片上显示更新后的日程。再例如，天气APP对天气卡片设置的数据更新策略可以是：每30分钟更新一次天气数据。以及例如，运动健康APP对运动健康卡片设置的数据更新策略可以是：向HMS Core注册监听步数变化，当步数发生变化时，更新运动健康卡片的步数数据并在卡片上显示更新后的步数。在此不做枚举。

可以理解，卡片提供方303向卡片管理服务302设置的卡片数据更新策略所采用的文件格式例如可以是xml格式或者json格式等，以便于卡片管理服务302读取该数据更新策略中的相关要求，以此来控制卡片的数据更新过程。

可以理解，在另一些实施例中，本步骤409可以与上述步骤405和/或步骤406同步执行，即卡片提供方303运行时便可以向卡片管理服务302设置卡片更新策略，和/或卡片提供方303向卡片管理服务302返回初始数据包时向卡片管理服务302设置卡片更新策略，在此不做限制。

410：卡片管理服务302基于数据更新策略，从数据源304获取待更新数据。

示例性地，若该数据更新策略中限定的数据更新触发条件为定时更新数据，则卡片管理服务302可以在指定时间向数据源304获取待更新数据。例如，卡片管理服务302基于时钟APP对天气卡片上时钟控件设置的数据更新策略，可以每分钟获取一次系统时间，并将获取的系统时间发送给桌面APP。桌面APP则可以基于该系统时间更新天气卡片上的时间信息。

在另一些实施例中，若该数据更新策略中限定的数据更新触发条件为基于监听机制的触发条件，则卡片管理服务302可以在监听到相应数据变化时，向数据源304获取待更新数据。例如，卡片管理服务302基于运动健康APP设置的数据更新策略，可以在监听到HMSCore更新的步数变化时，向HMS Core获取待更新的步数数据，以发送给桌面APP更新运动健康卡片上的步数。

可以理解，卡片管理服务302向数据源304获取待更新数据，可以通过向数据源304发送数据请求的方式，也可以通过获取数据源304的数据读取权限，从数据源304读取待更新数据等，在此不做限制。例如，卡片管理服务302可以向HMS Core发送获取待更新的步数数据的请求，以获取到待更新的步数数据。又例如，卡片管理服务302可以从天气APP获取气象数据的网站或者气象服务平台上，读取待更新的气象数据等，在此不做枚举。

411：卡片管理服务302向卡片使用方301转发待更新数据。

示例性地，卡片管理服务302获取到待更新数据后，可以将该数据转发给卡片使用方301，例如转发给桌面APP。如此，卡片使用方301则可以进一步执行下述步骤412，更新卡片数据。

412：卡片使用方301将待更新数据更新至相应卡片上，并更新卡片显示内容。

示例性地，卡片使用方301在接收到卡片管理服务302转发来的待更新数据后，例如可以使用该待更新数据替换相应卡片上的卡片数据，以实现卡片数据的更新。对应的，当用户使用手机，可以看到桌面上相应卡片的显示内更新。

基于上述图4所示步骤401至411的交互过程，对于添加到桌面等卡片使用方界面上的卡片，手机等电子设备的系统能够直接从数据源304获取卡片提供方对应更新的数据。在相应的卡片提供方未运行的状态下，电子设备可以实现卡片上数据的及时更新。

如此，一方面卡片提供方不需要在系统中常驻运行，因而可以避免应用程序常驻运行所导致的能耗较大的问题，即有利于减少系统能耗。另一方面，系统也不需要在更新数据时启动或唤醒卡片提供方，而是可以直接通过卡片管理服务与数据源之间建立连接获取待更新的卡片数据，因而也能够避免应用程序启动或唤醒导致的功耗增加问题，更新卡片数据的过程也无需等待卡片提供方启动或唤醒，也有利于减少时延。而且，卡片管理服务与数据源之间建立连接直接获取数据，也可以使卡片数据更新过程得以简化，数据更新的效率也因此更高。

上述图4所示系统各结构之间的交互过程，也可以总结为图8所示的内部实现过程。

图8根据本申请实施例示出了一种卡片数据的更新方法在系统架构内部的实现过程示意图。

如图8所示，在应用了本申请的数据更新方案的手机100上，卡片使用方301在检测到添加卡片的请求时，可以向卡片管理服务302请求添加卡片，即图8所示的“1.请求添加卡片”。进而，卡片使用方301在向卡片管理服务302请求添加卡片后，卡片管理服务302基于请求创建卡片提供方303的应用进程。可以理解，卡片使用方301基于检测到的卡片管理需求，也可以请求卡片管理服务302删除卡片、或者更改卡片样式等，在此不做限制。

继续参考图8所示，卡片提供方303可以在提供相应卡片服务时向卡片管理服务302设置数据更新策略，即图8所示的“2.设置数据更新策略”。如上所述，该数据更新策略例如可以包括所提供卡片服务对应数据的数据源304的访问路径、以及数据更新触发条件等。在此不做赘述。

继续参考图8所示，进一步地，卡片管理服务302便可以基于卡片提供方303设置的数据更新策略，在检测到数据更新触发条件满足时，从相应卡片的数据源304处获取待更新数据，并发送给卡片使用方301完成卡片数据的更新。该过程可以参考图8所示的“3.获取待更新数据”。

图9a根据本申请实施例示出了一种数据更新策略对应的卡片数据的更新方法的流程图。可以理解，图9a所示流程的各步骤执行主体可以是上述手机100等电子设备。

如图9a所示，当卡片提供方设置的数据更新策略包括基于监听机制的触发条件时，该流程可以包括以下步骤：

901a：检测到添加卡片的请求。该请求可以是检测到的用户操作请求，也可以是手机100的系统基于用户对一些应用程序的使用习惯主动添加相应卡片的系统请求，在此不做限制。具体执行过程可以参考上述步骤401，在此不做赘述。

902a：运行相应应用程序并创建卡片。相应应用程序即提供卡片服务的卡片提供方，例如可以是天气APP、运动健康APP等，在此不做限制。具体执行过程可以参考上述步骤403至408所描述的过程，在此不做赘述。

903a：获取相应应用程序为所创建卡片设置的数据更新策略。该数据更新策略可以包括数据源、以及基于监听机制的触发条件等。该触发条件例如可以是监听到数据源的卡片相关数据变化，则更新对应卡片的数据的条件。具体执行过程可以参考上述步骤409至410中相关描述，在此不做赘述。

904a：基于数据更新策略中提供的数据源，监听数据源中卡片相关数据的变化。具体执行过程可以参考上述步骤409至410中相关描述，在此不做赘述。

905a：判断卡片相关数据的变化是否满足数据更新策略限定的触发条件。若判断结果为是，则执行下述步骤906a；若判断结果为否，则继续执行上述步骤904a。

906a：获取待更新数据，更新卡片内容。具体更新卡片数据的过程可以参考上述步骤410至412中相关描述，在此不做赘述。

可以理解，在另一些实施例中，手机100在执行上述步骤904a监听数据源中卡片相关数据的变化时，便可以获取待更新数据，以与当前的卡片数据进行比较，来判断是否需要更新数据。此种情形下，当比较结果满足数据更新策略限定的触发条件时，手机100则可以直接基于已获取的待更新数据更新卡片内容。

图9b根据本申请实施例示出了另一种数据更新策略对应的卡片数据的更新方法的流程图。可以理解，图9b所示流程的各步骤执行主体可以是上述手机100。

如图9b所示，当卡片提供方设置的数据更新策略为定时更新数据的策略时，该流程可以包括以下步骤：

901b：检测到添加卡片的请求。

902b：运行相应应用程序并创建卡片。

上述步骤901b至902b，与上述步骤901a至902a相同，具体执行过程可以参考上述步骤901a至902a中相关描述的，在此不做赘述。

903b：获取相应应用程序为所创建卡片设置的数据更新策略。该数据更新策略可以包括数据源、以及定时触发条件等。该定时触发条件例如可以是指定更新的时间间隔，例如每分钟更新一次天气卡片上的时钟控件数据、或者每30分钟更新一次天气卡片上的天气数据等。该定时触发条件例如也可以是指定更新时间，例如指定每天7:00更新微博TM热点卡片等，在此不做限制。具体获取数据更新策略的过程可以参考上述步骤409至410中相关描述，在此不做赘述。

904b：判断数据更新策略提供的定时触发条件是否满足。若判断结果为是，则执行下述步骤905b；若判断结果为否，则继续执行本步骤904b。

905b：基于数据更新策略提供的数据源，获取待更新数据，更新卡片内容。具体更新卡片数据的过程可以参考上述步骤410至412中相关描述，在此不做赘述。

图10根据本申请实施例示出了一种手机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，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L等。

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

处理器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的等待时间，因而提高了系统的效率。

在本申请实施例中，处理器110可以获取存储器中执行本申请实施例提供的卡片数据的更新方法的指令和数据，以执行上述图9a或图9b所示卡片数据的更新方法的各步骤，在此不做赘述。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为手机100充电，也可以用于手机100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。

可以理解的是，本发明实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对手机100的结构限定。在本申请另一些实施例中，手机100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块140用于从充电器接收充电输入。电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，显示屏194，摄像头193，和无线通信模块160等供电。

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

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

移动通信模块150可以提供应用在手机100上的包括2G/3G/4G/5G等无线通信的解决方案。无线通信模块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)等无线通信的解决方案。

在一些实施例中，手机100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得手机100可以通过无线通信技术与网络以及其他设备通信。

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

显示屏194用于显示图像，视频等。

手机100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。ISP用于处理摄像头193反馈的数据。摄像头193用于捕获静态图像或视频。

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

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

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

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

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

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

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

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

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。手机100根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，手机100根据压力传感器180A检测该触摸操作的强度。手机100也可以根据压力传感器180A的检测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。例如：当有触摸操作强度小于第一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的指令。当有触摸操作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息的指令。

陀螺仪传感器180B可以用于确定手机100的运动姿态。在一些实施例中，可以通过陀螺仪传感器180B确定手机100围绕三个轴(即，x，y和z轴)的角速度。

加速度传感器180E可检测手机100在各个方向上(一般为三轴)加速度的大小。当手机100静止时可检测出重力的大小及方向。还可以用于识别电子设备姿态，应用于横竖屏切换，计步器等应用。

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

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

按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。手机100可以接收按键输入，产生与手机100的用户设置以及功能控制有关的键信号输入。

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用(例如拍照，音频播放等)的触摸操作，可以对应不同的振动反馈效果。作用于显示屏194不同区域的触摸操作，马达191也可对应不同的振动反馈效果。不同的应用场景(例如：时间提醒，接收信息，闹钟，游戏等)也可以对应不同的振动反馈效果。触摸振动反馈效果还可以支持自定义。

指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和手机100的接触和分离。手机100可以支持1个或N个SIM卡接口，N为大于1的正整数。SIM卡接口195可以支持Nano SIM卡，Micro SIM卡，SIM卡等。同一个SIM卡接口195可以同时插入多张卡。上述多张卡的类型可以相同，也可以不同。SIM卡接口195也可以兼容不同类型的SIM卡。SIM卡接口195也可以兼容外部存储卡。手机100通过SIM卡和网络交互，实现通话以及数据通信等功能。在一些实施例中，手机100采用eSIM，即：嵌入式SIM卡。eSIM卡可以嵌在手机100中，不能和手机100分离。

图11根据本申请实施例示出了一种手机100的系统架构示意框图。

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

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

如图11所示，应用程序层可以包括一系列应用程序包。例如，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

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

应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。在本申请的一些实施例中，应用程序框架层还可以包括卡片管理服务，该服务的功能可以参考上述图2及图3相关描述，在此不做赘述。

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

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

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

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

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

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

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

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

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

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。在本申请的一些实施例中，系统库还可以包括卡片管理服务，该服务的功能可以参考上述图2及图3相关描述，在此不做赘述。

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

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

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

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

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

下面结合添加卡片的用户操作场景，示例性说明手机100软件以及硬件的工作流程。

当触摸传感器180K接收到触摸操作，相应的硬件中断被发给内核层。内核层将触摸操作加工成原始输入事件(包括触摸坐标，触摸操作的时间戳等信息)。原始输入事件被存储在内核层。应用程序框架层从内核层获取原始输入事件，识别该输入事件所对应的控件。以该触摸操作是触摸单击操作，该单击操作所对应的控件为桌面上显示的运动健康卡片为例，运动健康应用调用应用框架层的接口，启动运动健康应用，创建运动健康卡片并添加到桌面上。

之后，系统便可以调用内核层启动传感器驱动，获取加速度传感器以及陀螺仪传感器等采集的运动数据，并运算得到相应的步数数据。系统作为运动健康卡片的数据源，则可以通过卡片管理服务直接向桌面应用提供步数数据，以更新运动健康卡片上的步数。

在说明书对“一个实施例”或“实施例”的引用意指结合实施例所描述的具体特征、结构或特性被包括在根据本申请实施例公开的至少一个范例实施方案或技术中。说明书中的各个地方的短语“在一个实施例中”的出现不一定全部指代同一个实施例。

本申请实施例的公开还涉及用于执行文本中的操作装置。该装置可以专门处于所要求的目的而构造或者其可以包括被存储在计算机中的计算机程序选择性地激活或者重新配置的通用计算机。这样的计算机程序可以被存储在计算机可读介质中，诸如，但不限于任何类型的盘，包括软盘、光盘、CD-ROM、磁光盘、只读存储器(ROM)、随机存取存储器(RAM)、EPROM、EEPROM、磁或光卡、专用集成电路(ASIC)或者适于存储电子指令的任何类型的介质，并且每个可以被耦合到计算机系统总线。此外，说明书中所提到的计算机可以包括单个处理器或者可以是采用针对增加的计算能力的多个处理器涉及的架构。

另外，在本说明书所使用的语言已经主要被选择用于可读性和指导性的目的并且可能未被选择为描绘或限制所公开的主题。因此，本申请实施例公开旨在说明而非限制本文所讨论的概念的范围。

Claims (13)

1.一种卡片数据的更新方法，应用于电子设备，所述电子设备包括第一应用和第二应用，其特征在于，所述方法包括：

所述电子设备获取所述第一应用为第一卡片设置的更新策略；其中，所述第一卡片由所述第一应用提供，所述更新策略包括对应于所述第一卡片的至少一个数据源的访问路径、以及更新条件；

所述电子设备检测到所述第一卡片满足所述更新条件；

所述电子设备从所述第一卡片对应的至少一个数据源获取更新数据，并将所述更新数据提供给所述第二应用；

所述电子设备基于所述更新数据更新所述第一卡片。

2.根据权利要求1所述的方法，其特征在于，所述电子设备从所述第一卡片对应的至少一个数据源获取更新数据，包括：

基于所述更新策略中至少一个数据源的访问路径，所述电子设备从所述至少一个数据源获取所述更新数据。

3.根据权利要求1或2所述的方法，其特征在于，所述电子设备检测到所述第一卡片满足所述更新条件，包括：

所述电子设备在系统中注册监听事件，其中所述监听事件的监听参数包括所述至少一个数据源的访问路径；

监听到所述至少一个数据源中的数据发生变化，所述电子设备确定所述第一卡片满足更新条件。

4.根据权利要求1或2所述的方法，其特征在于，所述电子设备检测到所述第一卡片满足所述更新条件，包括：

所述电子设备检测到系统时间到达所述更新条件指定的更新时间；或者，

所述电子设备检测到所述第一卡片更新的时间间隔达到所述更新条件指定的时间间隔阈值。

5.一种卡片数据的更新方法，应用于电子设备，其特征在于，所述电子设备包括第一应用、第二应用和卡片管理服务，所述方法包括：

所述卡片管理服务获取所述第一应用为第一卡片设置的更新策略；其中，所述第一卡片由所述第一应用提供，所述更新策略包括对应于所述第一卡片的至少一个数据源的访问路径、以及更新条件；

所述卡片管理服务检测到所述第一卡片满足所述更新条件；

所述卡片管理服务从所述第一卡片对应的至少一个数据源获取更新数据，并向所述第二应用发送所述更新数据；

所述第二应用基于所述更新数据更新所述第一卡片。

6.根据权利要求5所述的方法，其特征在于，所述卡片管理服务获取所述第一应用为所述第一卡片设置的更新策略，包括：

所述卡片管理服务响应于在所述第二应用的界面上添加所述第一卡片的添加请求，向所述第一应用发送运行指令；

所述第一应用响应于所述运行指令，向所述卡片管理服务发送数据包，并向所述卡片管理服务设置对应于所述第一卡片的更新策略；

所述卡片管理服务获取所述第一应用为所述第一卡片设置的更新策略，并向所述第二应用转发所述数据包。

7.根据权利要求5或6所述的方法，其特征在于，所述卡片管理服务从所述第一卡片的至少一个数据源获取更新数据，包括：

基于所述更新策略中至少一个数据源的访问路径，所述卡片管理服务从所述至少一个数据源获取所述更新数据。

8.根据权利要求7所述的方法，其特征在于，所述卡片管理服务检测到所述第一卡片满足所述更新条件，包括：

所述卡片管理服务向所述电子设备的系统注册监听事件，其中所述监听事件的监听参数包括所述至少一个数据源的访问路径；

监听到至少一个数据源中的数据发生变化，所述卡片管理服务确定所述第一卡片满足更新条件。

9.根据权利要求7所述的方法，其特征在于，所述卡片管理服务检测到所述第一卡片满足更新条件，包括：

所述卡片管理服务检测到系统时间到达所述更新条件指定的更新时间；或者，

所述卡片管理服务检测到所述第一卡片更新的时间间隔达到所述更新条件指定的时间间隔阈值。

10.一种卡片数据的更新方法，应用于电子设备，所述电子设备包括第一应用和第二应用，所述第二应用显示第一应用的第一卡片，其特征在于，所述方法包括：

所述电子设备基于所述第一卡片对应的更新策略，检测到第一应用满足更新条件，其中所述更新策略包括对应于所述第一卡片的至少一个数据源的访问路径、以及所述更新条件；

在不运行所述第一应用的情况下，所述电子设备从所述至少一个数据源获取更新数据，其中，所述更新数据用于更新所述第一卡片的显示内容。

11.一种卡片数据的更新方法，应用于电子设备，所述电子设备包括第一应用、第二应用和卡片管理服务，其特征在于，所述方法包括：

所述第二应用显示第一卡片，其中所述第一卡片由所述第一应用提供；

所述卡片管理服务检测到所述第一卡片满足更新条件；

在不运行所述第一应用的情况下，所述卡片管理服务从对应所述第一应用的数据源获取更新数据；

所述第二应用基于所述卡片管理服务发送的所述更新数据更新所述第一卡片。

12.一种电子设备，其特征在于，包括：一个或多个处理器；一个或多个存储器；所述一个或多个存储器存储有一个或多个程序，当所述一个或者多个程序被所述一个或多个处理器执行时，使得所述电子设备执行权利要求1至4、权利要求5至9、权利要求10或权利要求11中任一项所述的卡片数据的更新方法。

13.一种计算机可读存储介质，其特征在于，所述存储介质上存储有指令，所述指令在计算机上执行时使所述计算机执行权利要求1至4、权利要求5至9、权利要求10或权利要求11中任一项所述的卡片数据的更新方法。