CN119556836A - 一种卡片显示方法及电子设备 - Google Patents

Abstract

本申请实施例公开了一种卡片显示方法及电子设备，涉及电子设备领域，能够优化电子设备显示应用程序的通知信息的过程。具体方案为：响应于电子设备中的第一应用程序的业务发生变化，电子设备确定第一应用程序的第一卡片的第一视图；电子设备根据第一视图，创建第二应用程序对应的第一嵌入式窗口图层；响应于切换至第二应用程序的第一操作，电子设备显示第一界面，第一界面中包括第二应用程序的嵌入式窗口，其中，在第二应用程序的嵌入式窗口内显示第一嵌入式窗口图层，以在第一界面内显示包括第一视图的第一卡片。

Description

一种卡片显示方法及电子设备

技术领域

本申请涉及电子设备领域，尤其涉及一种卡片显示方法及电子设备。

背景技术

目前，电子设备(如，手机等)通常采用卡片的形式向用户展示某个应用程序的通知信息。其中，通知信息可以是具有通知权限的应用程序的通知信息，例如，短信、行程信息、打车信息、外卖配送信息等。

发明内容

本申请实施例提供一种卡片显示方法及电子设备，能够优化电子设备显示应用程序的通知信息的过程。

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

第一方面，本申请实施例提供一种卡片显示方法，应用于电子设备，该卡片显示方法可以包括：响应于电子设备中的第一应用程序的业务发生变化，电子设备确定第一应用程序的第一卡片的第一视图；电子设备根据第一视图，创建第二应用程序对应的第一嵌入式窗口图层；响应于切换至第二应用程序的第一操作，电子设备显示第一界面，第一界面中包括第二应用程序的嵌入式窗口，其中，在第二应用程序的嵌入式窗口内显示第一嵌入式窗口图层，以在第一界面内显示包括第一视图的第一卡片。

基于第一方面所述的方法，在电子设备中的第一应用程序的业务发生变化时，响应于第一应用程序的业务发生变化，电子设备可以确定第一应用程序的第一卡片的第一视图，并根据第一视图，创建第二应用程序对应的第一嵌入式窗口图层，这样电子设备可以将第一嵌入式窗口图层嵌入至第二应用程序的嵌入式窗口。之后，在电子设备接收到切换至第二应用程序的第一操作时，响应于第一操作，电子设备可以显示第二应用程序对应的第一界面。由于电子设备显示第二应用程序的第一界面中包括第二应用程序的嵌入式窗口，因此，在电子设备显示第二应用程序对应的第一界面的同时，可以显示第二应用程序的嵌入式窗口内嵌入的第一嵌入式窗口图层，进而可以在第一界面中显示包括第一视图的第一卡片。也就是说，在电子设备的第二应用程序显示第一卡片时，可以通过显示第二应用程序的嵌入式窗口的方式显示第一卡片，而不是直接显示第一卡片。这样一来，电子设备可以根据第一应用程序的业务类型，确定第一卡片的第一视图，进而通过在第一界面显示包括第一视图的第一卡片，能够更有效、更直观地展示第一应用程序的业务状态，用户体验更好。

结合第一方面，在另一种可能的实现方式中，上述卡片显示方法还可以包括：响应于电子设备中的第一应用程序的业务发生变化，电子设备确定第一应用程序的第一卡片的第二视图，第二视图与第一视图不同；电子设备根据第二视图，创建第三应用程序对应的第二嵌入式窗口图层；在上述响应于切换至第二应用程序的第一操作，电子设备显示第一界面之后，上述卡片显示方法还可以包括：响应于切换至第三应用程序的第二操作，显示第二界面，第二界面中包括第三应用程序的嵌入式窗口，其中，在第三应用程序的嵌入式窗口内显示第二嵌入式窗口图层，以在第二界面内显示包括第二视图的第一卡片。

基于该可能的实现方式，在电子设备中的第一应用程序的业务发生变化时，响应于第一应用程序的业务发生变化，电子设备可以确定第一应用程序的第一卡片的第二视图，并根据第二视图，创建第三应用程序对应的第二嵌入式窗口图层，这样电子设备可以将第二嵌入式窗口图层嵌入至第三应用程序的嵌入式窗口。也就是说，在第一应用程序的业务发生变化时，电子设备可以针对不同应用程序的特点，确定可在各应用程序显示的卡片视图。进而，在电子设备接收到切换至第三应用程序的第二操作时，响应于第二操作，电子设备的显示界面可以由第二应用程序对应的第一界面切换为第三应用程序对应的第二界面。并且，由于电子设备显示第三应用程序的第二界面中包括第三应用程序的嵌入式窗口。因此，在电子设备的显示界面由第二应用程序对应的第一界面切换为第三应用程序对应的第二界面的同时，电子设备的显示界面中的第一卡片由包括第一视图的第一卡片切换为包括第二视图的第一卡片。也就是说，电子设备可以针对不同应用程序的特点，显示与各应用程序相适配的第一卡片，进而保证在电子设备的不同应用程序显示的第一卡片均具有良好的显示效果。

结合第一方面，在另一种可能的实现方式中，上述第一视图包括进度条，进度条用于指示第一应用程序的业务的进度状态；进度条包括第一图标、第二图标、和第三图标，其中，第一图标用于指示第一应用程序的业务的执行起点，第二图标用于指示第一应用程序的业务的执行终点；第三图标用于指示第一应用程序的业务的进度状态发生变化，且在第一应用程序的业务的进度状态发生变化时，第三图标在第一图标与第二图标之间的位置相应发生变化。

基于该可能的实现方式，第一视图可以包括用于指示第一应用程序的业务的进度状态的进度条，这样在电子设备在第一界面显示包括第一视图的第一卡片时，通过第一视图中的进度条可以更直观地展示第一应用程序的业务的进度状态，用户体验更好。

结合第一方面，在另一种可能的实现方式中，上述第一应用程序的业务阶段包括第一业务阶段和第二业务阶段；第一视图包括分段进度条，分段进度条用于指示第一应用程序的业务在不同的业务阶段的进度状态；分段进度条包括第四图标、第五图标、位于第四图标与第五图标之间的第六图标和第七图标；其中，第四图标用于指示第一应用程序的第一业务阶段的执行起点；第五图标用于指示第一应用程序的第二业务阶段的执行终点；第六图标用于指示第一应用程序的第一业务阶段的执行终点，且第一应用程序的第二业务阶段的执行起点；第七图标用于指示第二应用程序的业务进度发生变化，且当第二应用程序的业务在第一业务阶段发生进度变化时，第七图标在第四图标与第六图标之间的位置相应发生变化；或者，当第二应用程序的业务在第二业务阶段发生进度变化时，第七图标在第六图标与第五图标之间的位置相应发生变化。

基于该可能的实现方式，第一视图可以包括用于指示第一应用程序的业务在不同的业务阶段的进度状态的分段进度条，这样在电子设备在第一界面显示包括第一视图的第一卡片时，通过第一视图中的分段进度条可以更直观地展示第一应用程序的业务当前所处的业务阶段，以及该业务阶段对应的进度状态，用户体验更好。

结合第一方面，在另一种可能的实现方式中，上述电子设备确定第一应用程序的第一卡片的第一视图，可以包括：电子设备获取第二应用程序的标识信息；电子设备根据第二应用程序的标识信息，确定第一视图的标识信息；电子设备根据第一视图的标识信息，确定第一视图。

基于该可能的实现方式，电子设备可以预先创建各应用程序对应的第一卡片的卡片视图，这样一来，在电子设备确定第一视图时，电子设备可以根据第二应用程序的标识信息，确定第一视图的标识信息，并根据第一视图的标识信息，确定第一视图，能够快速获取卡片视图，提升电子设备的处理效率。

结合第一方面，在另一种可能的实现方式中，在上述电子设备确定第一应用程序的第一卡片的第一视图之前，上述卡片显示方法还可以包括：电子设备根据第二应用程序的卡片尺寸信息，生成占位视图；电子设备根据占位视图，创建占位视图对应的占位嵌入式窗口图层；电子设备将占位嵌入式窗口图层挂载至第二应用程序的嵌入式窗口。

基于该可能的实现方式，在电子设备确定第一应用程序的第一卡片的第一视图之前，电子设备可以根据第二应用程序的卡片尺寸信息生成占位视图，并根据占位视图创建占位视图对应的占位嵌入式窗口图层，以在第二应用程序的嵌入式窗口挂载占位嵌入式窗口图层，这样可以避免在电子设备确定第一应用程序的第一卡片的卡片视图的过程中，电子设备显示除第一应用程序以外的其他应用程序的卡片。

结合第一方面，在另一种可能的实现方式中，上述电子设备根据占位视图，创建占位视图对应的占位嵌入式窗口图层，可以包括：在电子设备中存储有第三嵌入式窗口图层的情况下，获取第三嵌入式窗口图层的状态信息，其中，第三嵌入式窗口图层为根据第一应用程序的第二卡片的卡片视图创建的嵌入式窗口图层，第二卡片与第一卡片指示的第一应用程序的业务的进度状态不同；在状态信息指示第三嵌入式窗口图层有效的情况下，将第三嵌入式窗口图层中的第二卡片的卡片视图更新为占位视图，以得到占位嵌入式窗口图层。

基于该可能的实现方式，在电子设备的缓存中存储有第三嵌入式窗口图层时，电子设备可以将第三嵌入式窗口图层中的第二卡片的卡片视图更新为占位视图，以得到占位嵌入式窗口图层，这样不需要重新创建占位嵌入式窗口图层，可以提高电子设备的处理效率。

结合第一方面，在另一种可能的实现方式中，上述电子设备根据第一视图，创建第二应用程序对应的第一嵌入式窗口图层，可以包括：将占位嵌入式窗口图层中的占位视图更新为第一视图，以得到第二应用程序对应的第一嵌入式窗口图层。

基于该可能的实现方式，电子设备可以将占位嵌入式窗口图层中的占位视图更新为第一视图，以得到第二应用程序对应的第一嵌入式窗口图层，这样不需要重新创建第一嵌入式窗口图层，可以提高电子设备的处理效率。

结合第一方面，在另一种可能的实现方式中，上述第二视图对应的显示内容与上述第一视图对应的显示内容不同，和/或，上述第二视图对应的显示尺寸与上述第一视图对应的显示尺寸不同。

基于该可能的实现方式，在第一应用程序的业务发生变化时，电子设备可以针对不同应用程序的特点，生成各应用程序对应的卡片视图，其中，不同应用程序对应的卡片视图的显示内容和/或显示尺寸不同。这样一来，电子设备可以针对不同应用程序的特点，生成与各应用程序相适配的第一卡片，进而在电子设备切换到任一应用程序时，可以显示该应用程序对应的界面，并在该应用程序对应的界面显示包括该应用程序对应的卡片视图的第一卡片，这样能够保证在电子设备的不同应用程序显示的第一卡片均具有良好的显示效果。

结合第一方面，在另一种可能的实现方式中，上述第二应用程序为桌面、通知中心、锁屏、息屏、负一屏或者横幅通知；上述第三应用程序为桌面、通知中心、锁屏、息屏、负一屏或者横幅通知。

基于该可能的实现方式，在电子设备的前台运行的应用程序在桌面、通知中心、锁屏、息屏、负一屏或者横幅通知之间切换时，可以显示包括不同卡片视图的第一卡片，这样能够保证在桌面、通知中心、锁屏、息屏、负一屏或者横幅通知显示的第一卡片均具有较好的显示效果。

结合第一方面，在另一种可能的实现方式中，上述第二视图对应的显示尺寸与上述第一视图对应的显示尺寸不同，显示尺寸包括显示高度和显示宽度；其中，上述第二应用程序为桌面，上述第三应用程序为通知中心，第二视图对应的显示高度小于第一视图对应的显示高度。

基于该可能的实现方式，在电子设备的前台运行的应用程序由桌面切换为通知中心时，可以在通知中心显示包括第二视图的第一卡片，且第二视图对应的显示高度小于第一视图对应的显示高度，这样可以减小第一卡片所占的空间，使得电子设备的通知中心可以显示更多的通知信息卡片，用户不需要通过翻阅操作即可查看所有通知信息卡片，能够提高人机交互效率。

结合第一方面，在另一种可能的实现方式中，上述第二视图对应的显示尺寸与上述第一视图对应的显示尺寸不同，显示尺寸包括显示高度和显示宽度；其中，上述第二应用程序为桌面，上述第三应用程序为锁屏，第二视图对应的显示宽度小于第一视图对应的显示宽度，第二视图对应的显示高度小于第一视图对应的显示高度。

基于该可能的实现方式，在电子设备的前台运行的应用程序由桌面切换为锁屏时，可以在通知中心显示包括第二视图的第一卡片，且第二视图对应的显示宽度小于第一视图对应的显示宽度，第二视图对应的显示高度小于第一视图对应的显示高度，这样可以减小第一卡片所占的空间，使得电子设备的锁屏可以显示更多的通知信息卡片，用户不需要通过翻阅操作即可查看所有通知信息卡片，能够提高人机交互效率。

结合第一方面，在另一种可能的实现方式中，上述第二视图对应的显示尺寸与上述第一视图对应的显示尺寸不同，显示尺寸包括显示高度和显示宽度；其中，上述第二应用程序为锁屏，上述第三应用程序为息屏，第二视图对应的显示宽度小于第一视图对应的显示宽度，第二视图对应的显示高度小于第一视图对应的显示高度。

基于该可能的实现方式，由于电子设备的息屏界面的显示空间有限，因此，在电子设备的前台运行的应用程序由锁屏切换为息屏时，可以在息屏界面显示包括第二视图的第一卡片，且第二视图对应的显示宽度小于第一视图对应的显示宽度，第二视图对应的显示高度小于第一视图对应的显示高度，这样可以缩小第一卡片的显示尺寸，进而可以最大限度减小第一卡片所占的空间，避免第二应用程序对应的卡片无法完整显示。另外，由于电子设备的息屏界面处于常亮状态，在息屏界面显示尺寸较小的第一卡片，可以降低电子设备的功耗。

第二方面，本申请实施例提供一种卡片显示装置，该卡片显示装置可以应用于电子设备，用于实现上述第一方面中的方法。该卡片显示装置的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，例如，确定模块、创建模块和显示模块等。

其中，确定模块，可以用于响应于电子设备中的第一应用程序的业务发生变化，确定第一应用程序的第一卡片的第一视图。

创建模块，可以用于根据第一视图，创建第二应用程序对应的第一嵌入式窗口图层。

显示模块，可以用于响应于切换至第二应用程序的第一操作，显示第一界面，第一界面中包括第二应用程序的嵌入式窗口，其中，在第二应用程序的嵌入式窗口内显示第一嵌入式窗口图层，以在第一界面内显示包括第一视图的第一卡片。

第三方面，提供了一种电子设备，该电子设备具有实现上述第一方面所述的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

第四方面，提供了一种电子设备，包括：处理器和存储器；该存储器用于存储计算机执行指令，当该电子设备运行时，该处理器执行该存储器存储的该计算机执行指令，以使该电子设备执行如上述第一方面中任一项所述的卡片显示方法。

第五方面，提供了一种电子设备，包括：处理器；所述处理器用于与存储器耦合，并读取存储器中的指令之后，根据所述指令执行如上述第一方面中任一项所述的卡片显示方法。

第六方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序指令。当计算机程序指令被电子设备执行时，使得电子设备实现如第一方面或第一方面的可能的实现方式中任一项所述的卡片显示方法。

第七方面，本申请实施例提供一种计算机程序产品，包括计算机可读代码，当所述计算机可读代码在电子设备中运行时，使得电子设备实现如第一方面或第一方面的可能的实现方式中任一项所述的卡片显示方法。

第八方面，提供了一种装置(例如，该装置可以是芯片系统)，该装置包括处理器，用于支持电子设备实现上述第一方面中所涉及的功能。在一种可能的设计中，该装置还包括存储器，该存储器，用于保存电子设备必要的程序指令和数据。该装置是芯片系统时，可以由芯片构成，也可以包含芯片和其他分立器件。

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

附图说明

图1为相关技术中一种电子设备的软件结构示意图；

图2为相关技术中一种电子设备显示卡片的场景示意图；

图3为本申请实施例提供的一种电子设备的硬件结构示意图；

图4为本申请实施例提供的一种电子设备的软件结构示意图之一；

图5为本申请实施例提供的一种电子设备的软件结构示意图之二；

图6为本申请实施例提供的一种电子设备的软件结构示意图之三；

图7为本申请实施例提供的一种进度条的示意图之一；

图8为本申请实施例提供的一种卡片显示方法的场景示意图之一；

图9为本申请实施例提供的一种卡片显示方法的场景示意图之二；

图10为本申请实施例提供的一种进度条的示意图之二；

图11为本申请实施例提供的一种卡片显示方法的场景示意图之三；

图12为本申请实施例提供的一种卡片显示方法的场景示意图之四；

图13为本申请实施例提供的一种进度条的示意图之三；

图14为本申请实施例提供的一种卡片显示方法的场景示意图之五；

图15为本申请实施例提供的一种卡片显示方法的场景示意图之六；

图16为本申请实施例提供的一种卡片显示方法的流程示意图之一；

图17为本申请实施例提供的一种卡片显示方法的流程示意图之二。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

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

目前，为了更直观地向用户展示某个应用程序对应的通知信息，电子设备(如，手机等)可以在显示界面上通过卡片(或称为widget、微件、部件、组件等)的形式向用户展示该应用程序(application，APP)对应的通知信息。

通过卡片的形式向用户展示通知信息的应用程序可以是电子设备中需要发布通知信息的应用程序。该应用程序可以是电子设备自带的应用程序，也可以是第三方应用程序。

在电子设备显示应用程序对应的卡片时，电子设备可以按照预先定义的原生卡片元素创建该应用程序的通知信息对应的卡片，并显示应用程序的通知信息对应的卡片。其中，原生卡片元素通常是根据原生安卓卡片框架而预先定义的界面元素。也就是说，对于任一应用程序，在电子设备显示该应用程序对应的卡片时，该应用程序对应的卡片仅可以包括原生卡片元素，无法承载该应用程序的自定义卡片元素。

然而，原生安卓卡片框架所支持的原生卡片元素有限，如原生安卓卡片框架支持的原生卡片元素包括文本元素和图片元素。因此，在电子设备按照原生卡片元素创建某一应用程序的通知信息对应的卡片时，电子设备可以根据该应用程序的通知信息创建包括不同文本元素和图片元素的卡片，进而通过卡片上显示的文本元素和图片元素向用户展示应用程序的通知信息。但是，电子设备无法根据该应用程序的通知信息创建包括自定义卡片元素的卡片，即电子设备的应用程序无法根据需求创建包括不同的卡片，进而难以有效、直观地向用户展示应用程序的通知信息。

下面，结合图1对电子设备按照原生卡片元素显示应用程序的通知信息对应的卡片的过程进行说明。

以电子设备为手机，通知信息为打车应用程序的通知信息为例进行示意说明。如图1所示，在电子设备显示打车应用程序的通知信息对应的卡片时，电子设备运行的打车应用程序按照原生卡片元素，创建打车应用程序的通知信息对应的卡片(view)，并按照预设规则对打车应用程序的通知信息对应的卡片进行序列化处理，得到打车应用程序的通知信息对应的卡片(view)的卡片数据(view data)。

电子设备运行的打车应用程序可以向电子设备的宿主应用程序发送打车应用程序的通知信息对应的卡片(view)的卡片数据(view data)。其中，宿主应用程序可以是电子设备上能够显示卡片的应用程序，如电子设备的桌面、通知中心、横幅通知、锁屏、息屏或负一屏等。

电子设备的宿主应用程序接收打车应用程序的通知信息对应的卡片(view)的卡片数据(view data)后，根据卡片数据(view data)创建并显示打车应用程序的通知信息对应的卡片(view)。其中，该打车应用程序的通知信息对应的卡片(view)仅可以包括原生安卓卡片框架所支持的原生卡片元素(如，文本元素和图片元素)。

另外，如图1所示，电子设备的打车应用程序可以调用预先定义的函数，如设置文本(set text)函数和设置偏移(set translation)函数等。相应地，电子设备的宿主应用程序也可以调用预先定义的函数，如设置文本(set text)函数和设置偏移(settranslation)函数等。其中，电子设备可以预先建立打车应用程序可调用的设置文本(settext)函数与宿主应用程序可调用的设置文本(set text)函数之间的对应关系，以及预先建立打车应用程序可调用的设置偏移(set translation)函数与宿主应用程序可调用的设置偏移(set translation)函数之间的对应关系。

这样一来，电子设备的打车应用程序可以调用打车应用程序的设置文本(settext)函数对卡片(view)中的文本元素进行更新。在电子设备的打车应用程序调用打车应用程序的设置文本(set text)函数对卡片(view)中的文本元素进行更新时，基于预先建立的对应关系，可以先确定与打车应用程序的设置文本(set text)函数对应的宿主应用程序可调用的设置文本(set text)函数。从而电子设备的宿主应用程序可以调用宿主应用程序对应的设置文本(set text)函数，对卡片(view)中的文本元素进行更新。

下面以打车应用程序的通知信息对应的卡片包括文本元素和图片元素，宿主应用程序为电子设备的通知中心为例，结合图2对电子设备显示的打车应用程序的通知信息对应的卡片包括的文本元素的更新，进行示意说明。

在电子设备的打车应用程序产生打车订单后，电子设备的打车应用程序会发布打车任务，并等待司机接单。当电子设备从打开应用回到桌面时，如图2中的(a)所示，电子设备可以在通知中心10中显示打车应用程序对应的卡片11，卡片11可以用于提示用户打车应用程序的打车订单已产生，正在等待司机接单。结合图2中的(a)所示，卡片11可以包括打车应用程序的图标111以及“等待司机接单”的文本112。

之后，在电子设备的打车应用程序监测到司机已接单，并按照打车订单驶向用户所在的出发地时，如图2中的(b)所示，电子设备可以在通知中心10中显示打车应用程序对应的卡片12，卡片12可以用于提示用户司机已接单，并正在驶向出发地。结合图2中的(b)所示，卡片12可以包括打车应用程序的图标121以及“司机已接单，正在赶来”的文本122。

之后，在电子设备的打车应用程序监测到司机到达出发地时，如图2中的(c)所示，电子设备可以在通知中心10中显示打车应用程序对应的卡片13，卡片13可以用于提示用户司机已到达出发地，等待用户上车。结合图2中的(c)所示，卡片13可以包括打车应用程序的图标131以及“司机已到达，请上车”的文本132。

之后，在司机接到用户之后，司机按照打车订单行驶至目的地时，如图2中的(d)所示，电子设备可以在通知中心10中显示打车应用程序对应的卡片14，卡片14可以用于提示用户现在将向目的地行驶。结合图2中的(d)所示，卡片14可以包括打车应用程序的图标141以及“正在驶向目的地”的文本142。

也就是说，在打车应用程序对应的卡片包括的文本元素更新时，电子设备的通知中心中显示的打车应用程序对应的卡片包括的文本元素进行更新。

当然地，电子设备的打车应用程序也可以调用打车应用程序的设置偏移(settranslation)函数对卡片(view)的显示位置进行更新。在电子设备的打车应用程序调用打车应用程序的设置偏移(set translation)函数更新卡片(view)的显示位置时，基于预先建立的对应关系，可以先确定与打车应用程序的设置偏移(set translation)函数对应的宿主应用程序可调用的设置偏移(set translation)函数。从而电子设备的宿主应用程序可以调用宿主应用程序对应的设置偏移(set translation)函数，对卡片(view)中的显示位置进行更新。

但是，在电子设备显示打车应用程序的通知信息对应的卡片时，电子设备仅可以按照原生安卓卡片框架所支持的原生卡片元素显示打车应用程序的通知信息对应的卡片。这种方式显示的卡片的样式较为单一，难以直观、有效地向用户展示打车应用程序的通知信息。

综上可见，相关技术中，电子设备仅可以按照原生安卓卡片框架所支持的原生卡片元素显示应用程序对应的卡片，无法根据应用程序的通知信息显示包括自定义卡片元素的卡片，所显示的卡片的样式较为单一，难以直观、有效地向用户展示应用程序的通知信息，导致用户的使用体验较低。

针对上述问题，本申请实施例提供一种卡片显示方法，应用于电子设备，在电子设备通过卡片的形式显示应用程序的通知信息时，电子设备运行的应用程序可以创建卡片视图，并根据卡片视图生成卡片对应的嵌入式窗口图层，以及将卡片对应的嵌入式窗口图层发送给电子设备的宿主应用程序，以使电子设备的宿主应用程序显示卡片对应的嵌入式窗口图层。也就是说，在电子设备的宿主应用程序通过卡片的形式显示应用程序的通知信息时，电子设备的宿主应用程序显示的是其自身下挂的嵌入式窗口图层，而不是直接显示卡片视图。因此，电子设备的应用程序可以根据需求创建包括自定义卡片元素的卡片视图，并根据卡片视图生成包括自定义卡片元素的嵌入式窗口图层，从而在电子设备的宿主应用程序显示应用程序的通知信息时，电子设备的宿主应用程序可以显示包括不同自定义卡片元素的卡片视图，这样能够更有效、更直观地向用户展示应用程序的通知信息。

再者，在电子设备显示应用程序对应的卡片时，基于嵌入式窗口图层显示应用程序对应的卡片，可以提高跨进程数据传输速度，能够实现应用程序对应的卡片的实时刷新，进而保证应用程序的通知信息的时效性，用户体验更好。

下面对本申请实施例提供的卡片显示方法进行描述。

本申请实施例提供的卡片显示方法可以应用于电子设备。在一些实施例中，上述电子设备可以是手机、平板电脑、手持计算机，个人计算机(personal computer，PC)，蜂窝电话，个人数字助理(personal digital assistant，PDA)，可穿戴式设备等应用程序的电子设备。本申请实施例在此对电子设备的具体形态不做限制。

示例性地，以电子设备为手机为例，图3示出了本申请实施例提供的一种电子设备的结构示意图。

如图3所示，电子设备可以包括处理器310，外部存储器接口320，内部存储器321，通用串行总线(universal serial bus，USB)接口330，充电管理模块340，电源管理模块341，电池342，天线1，天线2，移动通信模块350，无线通信模块360，音频模块370，扬声器370A，受话器370B，麦克风370C，耳机接口370D，传感器模块380，按键390，马达391，指示器392，摄像头393，显示屏394，以及用户标识模块(subscriber identification module，SIM)卡接口395等。其中，传感器模块380可以包括压力传感器380A，陀螺仪传感器380B，气压传感器380C，磁传感器380D，加速度传感器380E，距离传感器380F，接近光传感器380G，指纹传感器380H，温度传感器380J，触摸传感器380K，环境光传感器380L，骨传导传感器380M等。

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

本申请实施例中，显示屏394可用于显示图8、图9、图11、图12、图14和图15的电子设备显示界面。

当然，可以理解的，上述图3所示仅仅为电子设备的形态为手机时的示例性说明。若电子设备是平板电脑，手持计算机，PC，PDA，可穿戴式设备(如：智能手表、智能手环)等其他设备形态时，电子设备的结构中可以包括比图3中所示更少的结构，也可以包括比图3中所示更多的结构，在此不作限制。

可以理解的是，一般而言，电子设备功能的实现除了需要硬件的支持外，还需要软件的配合。

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

图4是本申请实施例提供的电子设备的软件结构框图。

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

在一些示例中，为了实现本申请实施例提供的卡片显示方法，应用程序层还可以包括宿主应用程序(如电子设备的桌面、负一屏、通知中心、横幅通知、息屏、锁屏等)和提供卡片的应用程序。提供卡片的应用程序即电子设备中能够提供卡片的应用程序，可以为第三方应用程序，如，电子设备中的出行应用程序(如打车应用程序、地图应用程序等)、配送应用程序(如外卖应用程序、快递应用程序等)等。提供卡片的应用程序，也可以为电子设备的系统的应用程序。

以下结合图5对本申请实施例提供的卡片显示方法的进行示意说明。需要说明的是，本申请实施例中所提到的具体应用程序为例仅是为了便于技术方案的说明，并不代表其对本申请的方案范围的限制。

例如，以提供卡片的应用程序为打车应用程序为例，如图5所示，本申请实施例提供的卡片显示方法包括以下过程：在电子设备显示打车应用程序的通知信息对应的卡片时，电子设备的打车应用程序可以根据打车应用程序的通知信息对应的卡片视图(即view)，生成卡片视图对应的嵌入式窗口(即SurfaceControlViewHost)图层，该嵌入式窗口图层包括SurfaceControl图层。

之后，电子设备的打车应用程序可以对卡片视图对应的嵌入式窗口图层进行封装，得到卡片视图对应的嵌入式窗口图层的数据包(即SurfacePackage)，并将卡片视图对应的嵌入式窗口图层的数据包跨进程传输给电子设备的宿主应用程序。

在电子设备的宿主应用程序接收到卡片视图对应的嵌入式窗口图层的数据包后，电子设备的宿主应用程序可以根据卡片视图对应的嵌入式窗口图层的数据包，得到卡片视图对应的嵌入式窗口图层。电子设备的宿主应用程序可以将卡片视图对应的嵌入式窗口图层挂载(或称为嵌入)在其自身的宿主图层(即SurfaceView)上，即电子设备的宿主应用程序可以将SurfaceControl图层嵌入其自身的宿主图层。也就是说，电子设备的宿主应用程序的宿主图层中实际嵌入的SurfaceControl图层和电子设备的打车应用程序生成的嵌入式窗口图层中包括的SurfaceControl图层是同一个图层，换句话说，电子设备的宿主应用程序的宿主图层与电子设备的打车应用程序的嵌入式窗口图层均指向高性能渲染(graphic)图层(即SurfaceControl图层)。因此，电子设备的宿主应用程序和电子设备的打车应用程序显示的是同一个对象，即电子设备的宿主应用程序可以显示打车应用程序的通知信息对应的卡片。

再者，结合图5所示，由于在电子设备显示打车应用程序的通知信息对应的卡片时，电子设备的宿主应用程序显示的是其自身的宿主图层中嵌入的SurfaceControl图层(即打车应用程序生成的嵌入式窗口图层)，因此，在电子设备的打车应用程序生成嵌入式窗口图层时，电子设备的打车应用程序可以生成包括自定义卡片元素的卡片视图，并根据卡片视图，生成包括自定义卡片元素的卡片视图对应的嵌入式窗口图层，这样使得电子设备的宿主应用程序可以显示包括自定义卡片元素的卡片视图对应的嵌入式窗口图层，即电子设备的宿主应用程序可以显示包括自定义卡片元素的打车应用程序卡片。

以及，由于电子设备运行的打车应用程序的通知信息对应的卡片视图是在打车应用程序的进程中创建。因此，在电子设备运行的打车应用程序的通知信息发生变化(即打车应用程序的业务发生变化)时，打车应用程序可以调用相关函数对打车应用程序的通知信息对应的卡片视图进行调整，并且卡片视图对应的SurfaceControl图层可以根据调整后的卡片视图同步更新，即卡片视图对应的嵌入式窗口图层可以根据调整后的卡片视图同步更新。又由于电子设备的宿主应用程序的宿主图层中实际嵌入的SurfaceControl图层和电子设备的打车应用程序生成的嵌入式窗口图层中包括的SurfaceControl图层是同一个图层，因此，电子设备的宿主应用程序显示的SurfaceControl图层也随之更新，即电子设备的宿主应用程序显示的打车应用程序对应的卡片也会随之更新。

在一些示例中，为了实现本申请实施例提供的卡片显示方法，如图6所示，应用程序层还可以包括应用程序对应的管理插件，具体可以包括提供卡片的应用程序对应的管理插件以及宿主应用程序对应的管理插件。

应用程序对应的管理插件，可以为AAR(android archive)，也可以为JAR(JavaArchive)。本申请实施例中对应用程序对应的管理插件的具体类型并不进行限定，本申请实施例中是以应用程序对应的管理插件为AAR为例进行示意说明。

AAR可以包括提供卡片的应用程序对应的AAR和宿主应用程序对应的AAR。

提供卡片的应用程序对应的AAR(也可以称为卡片kit)可以作为电子设备的提供卡片的应用程序和卡片管理服务之间进行交互的桥梁。即卡片kit可以集成卡片显示的相关接口，使得提供卡片的应用程序可以通过卡片kit集成的卡片显示的相关接口与卡片管理服务建立通信连接，进而通过卡片kit与卡片管理服务进行交互。也就是说，提供卡片的应用程序不需要了解电子设备的卡片管理服务，仅通过调用卡片kit提供的相关接口，即可以实现卡片接入、定时刷新、卡片缓存、获取卡片和卡片销毁等功能。

需要说明的是，卡片kit可以集成在电子设备的提供卡片的应用程序中，即电子设备中提供卡片的应用程序均可以集成卡片kit。例如，电子设备的打车应用程序可以集成卡片kit。又如，电子设备的外卖应用程序也可以集成卡片kit。

宿主应用程序对应的AAR(也可以称为Host AAR)可以作为电子设备的宿主应用程序与卡片管理服务之间进行交互的桥梁。即Host AAR可以集成卡片显示的相关接口，使得宿主应用程序可以通过Host AAR集成的卡片显示的相关接口与卡片管理服务建立通信连接。这样一来，宿主应用程序可以通过Host AAR快速接入卡片管理服务，以帮助宿主应用程序实现宿主接入、请求显示/隐藏、获取HostView(宿主视图)、大小变更、配置(config)变化等功能。

需要说明的是，Host AAR可以集成在电子设备的宿主应用程序中，即电子设备的各宿主应用程序均可以集成Host AAR。例如，电子设备的桌面可以集成Host AAR。又如，电子设备的通知中心可以集成Host AAR。还如，电子设备的负一屏可以集成Host AAR。

如图6所示，应用程序框架层还可以包括卡片显示服务(DisplayService)、卡片管理服务(LiveClipManagerService)和系统服务(Service)等。

卡片显示服务可以作为卡片显示的相关指令的发起方。卡片显示服务用于接收决策中台(即电子设备自带的应用程序)发送的控制宿主应用程序进行卡片显示的相关通知，响应于控制宿主应用程序进行卡片显示的相关通知，通知宿主应用程序显示卡片、隐藏卡片或者销毁卡片。

卡片管理服务可以是连接卡片进程和宿主进程的桥梁。即卡片管理服务可以实现卡片生命周期管理、功耗控制、数据缓存、异常恢复等功能。卡片管理服务可以用于获取宿主应用程序的卡片显示的相关通知，并利用系统服务向卡片kit发送卡片显示的相关通知，以通知卡片kit从提供卡片的应用程序获取卡片视图对应的嵌入式窗口图层。卡片管理服务还可以用于利用系统服务与Host AAR建立通信连接，并通过Host AAR向宿主应用程序发送获取到的卡片视图对应的嵌入式窗口图层，以供宿主应用程序显示卡片。

系统服务具有安卓原生服务基础能力，即系统服务可以提供跨进程数据传输通道。

下面结合图6，以提供卡片的应用程序为打车应用程序为例继续对本申请实施例提供的卡片显示方法进行示意说明。

如图6所示，本申请一个实施例提供的卡片显示方法可以包括S601-S609。

S601、在接收到电子设备的打车应用程序发送的业务通知的情况下，电子设备的卡片显示服务向电子设备的宿主应用程序发送卡片显示通知。

其中，业务通知用于指示电子设备的打车应用程序的业务发生变化(如司机接单)，卡片显示通知用于指示宿主应用程序显示打车应用程序卡片。宿主应用程序可以包括电子设备的桌面、负一屏、通知中心、横幅通知、息屏、锁屏等。

在电子设备开机后，宿主应用程序(桌面、负一屏、通知中心、横幅通知、息屏和锁屏等)对打车应用程序的业务变更进行注册(图中未示出)，当打车应用程序的发生业务变更时，卡片显示服务向这些宿主应用程序发送卡片显示通知，以通知电子设备的各宿主应用程序当前需要显示打车应用程序卡片。

例如，在用户使用电子设备的打车应用程序下单打车订单后，在打车应用程序的业务发生变化(如司机接单)时，打车应用程序可以向电子设备的卡片显示服务发送业务通知，即打车应用程序通知卡片显示服务当前需要显示打车应用程序卡片。电子设备的卡片显示服务接收到打车应用程序发送的业务通知后，可以向电子设备的宿主应用程序(如桌面、负一屏、通知中心、横幅通知、息屏、锁屏)发送卡片显示通知，以通知电子设备的宿主应用程序需要显示打车应用程序卡片。从而当电子设备切换为桌面时，电子设备的桌面可以显示打车应用程序卡片。当电子设备切换为通知中心时，电子设备的通知中心可以显示打车应用程序卡片。

S602、电子设备的宿主应用程序接收卡片显示通知，并向宿主应用程序对应的Host AAR发送第一请求，该第一请求用于请求显示打车应用程序卡片。

需要说明的是，由于电子设备的卡片显示服务可以向电子设备所有注册打车应用程序的业务变更的宿主应用程序发送卡片显示通知，因此，在所有注册打车应用程序的业务变更的宿主应用程序中各宿主应用程序接收到卡片显示服务发送的卡片显示通知后，各宿主应用程序可以向该宿主应用程序对应的Host AAR发送第一请求。

S603、宿主应用程序对应的Host AAR接收第一请求，并向电子设备的卡片管理服务发送第二请求，该第二请求用于请求显示打车应用程序卡片。

在宿主应用程序对应的Host AAR接收第一请求后，宿主应用程序对应的Host AAR利用电子设备的系统服务与电子设备的卡片管理服务建立跨进程通信，并向电子设备的卡片管理服务发送第二请求，以向电子设备的卡片管理服务请求显示打车应用程序卡片。

需要说明的是，由于所有注册打车应用程序的业务变更的宿主应用程序中各宿主应用程序在接收到卡片显示服务发送的卡片显示通知后，各宿主应用程序可以向该宿主应用程序对应的Host AAR发送第一请求，因此，在各宿主应用程序对应的Host AAR接收第一请求后，各宿主应用程序对应的Host AAR均可以向电子设备的卡片管理服务发送第二请求。

S604、卡片管理服务接收第二请求，并向打车应用程序对应的卡片kit发送第三请求，该第三请求用于请求获取打车应用程序卡片对应的嵌入式窗口图层。

在电子设备的卡片管理服务接收第二请求后，卡片管理服务可以利用电子设备的系统服务与打车应用程序对应的卡片kit建立跨进程通信，并向打车应用程序对应的卡片kit发送第三请求，以从打车应用程序对应的卡片kit获取打车应用程序卡片对应的嵌入式窗口图层。

需要说明的是，由于各宿主应用程序对应的Host AAR均可以向电子设备的卡片管理服务发送第二请求，因此，在卡片管理服务接收到每个宿主应用程序对应的Host AAR发送的第二请求后，卡片管理服务均可以向打车应用程序对应的卡片kit发送第三请求。

S605、打车应用程序对应的卡片kit接收第三请求，并向打车应用程序发送第四请求，第四请求用于请求获取打车应用程序卡片对应的卡片视图。

其中，第四请求包括卡片视图标识(即view id)。卡片视图标识可以唯一标识宿主应用程序可显示的卡片中的卡片视图。

在电子设备的宿主应用程序显示卡片时，电子设备前台运行的宿主应用程序可以发生变化，因此，可以根据宿主应用程序的显示内容显示相适应的卡片视图。也就是说，针对打车应用程序的同一业务，在不同的宿主应用程序显示打车应用程序卡片时，不同宿主应用程序显示的打车应用程序卡片的卡片视图不同，并且不同卡片视图的卡片视图标识不同。

例如，继续以电子设备的宿主应用程序可以包括桌面、通知中心、锁屏、息屏、负一屏、横幅通知为例，针对打车应用程序的同一业务(如司机接单)，桌面对应的打车应用程序卡片的卡片视图的view id为1，通知中心对应的打车应用程序卡片的卡片视图的view id为2，锁屏对应的打车应用程序卡片的卡片视图的view id为3，息屏对应的打车应用程序卡片的卡片视图的view id为4，负一屏对应的打车应用程序卡片的卡片视图的view id为5，横幅通知对应的打车应用程序卡片的卡片视图的view id为6。

需要说明的是，由于卡片管理服务在接收到每个宿主应用程序对应的Host AAR发送的第二请求后，均可以向打车应用程序对应的卡片kit发送第三请求，因此，在打车应用程序对应的卡片kit接收到卡片管理服务在接收到一个宿主应用程序对应的Host AAR发送的第二请求时发送的第三请求后，打车应用程序对应的卡片kit可以向打车应用程序发送第四请求，第四请求包括该宿主应用程序对应的卡片视图标识。

S606、打车应用程序接收第四请求，并根据卡片视图标识，获取打车应用程序卡片对应的卡片视图，以及向打车应用程序对应的卡片kit发送打车应用程序卡片对应的卡片视图。

S607、打车应用程序对应的卡片kit接收打车应用程序卡片对应的卡片视图，并根据打车应用程序卡片对应的卡片视图，生成打车应用程序卡片对应的嵌入式窗口图层，以及向卡片管理服务发送打车应用程序卡片对应的嵌入式窗口图层。

在接收打车应用程序卡片对应的卡片视图后，打车应用程序对应的卡片kit可以根据打车应用程序卡片对应的卡片视图，生成打车应用程序卡片对应的嵌入式窗口图层。以及，打车应用程序对应的卡片kit可以对打车应用程序卡片对应的嵌入式窗口图层进行封装，得到打车应用程序卡片对应的嵌入式窗口图层的数据包，并利用电子设备的系统服务提供的跨进程通道，向卡片管理服务发送打车应用程序卡片对应的嵌入式窗口图层的数据包。

S608、卡片管理服务接收打车应用程序卡片对应的嵌入式窗口图层，并向宿主应用程序对应的Host AAR发送打车应用程序卡片对应的嵌入式窗口图层。

在电子设备的卡片管理服务接收打车应用程序卡片对应的嵌入式窗口图层的数据包后，卡片管理服务利用电子设备的系统服务提供的跨进程通道，向宿主应用程序对应的Host AAR发送打车应用程序卡片对应的嵌入式窗口图层的数据包。

S609、宿主应用程序对应的Host AAR接收打车应用程序卡片对应的嵌入式窗口图层，并向宿主应用程序发送打车应用程序卡片对应的嵌入式窗口图层。

宿主应用程序对应的Host AAR可以向电子设备的宿主应用程序发送打车应用程序卡片对应的嵌入式窗口图层的数据包。电子设备的宿主应用程序接收打车应用程序卡片对应的嵌入式窗口图层的数据包后，可以将打车应用程序卡片对应的嵌入式窗口图层挂载在其自身的宿主图层(即SurfaceView)上。之后，在电子设备运行宿主应用程序时，电子设备的宿主应用程序可以显示打车应用程序卡片对应的嵌入式窗口图层，即电子设备的宿主应用程序显示打车应用程序卡片。

由于在电子设备显示提供卡片的应用程序对应的卡片时，电子设备运行的提供卡片的应用程序可以创建卡片视图，并根据卡片视图生成卡片对应的嵌入式窗口图层，以及将卡片对应的嵌入式窗口图层发送给电子设备的宿主应用程序，以使电子设备的宿主应用程序显示卡片对应的嵌入式窗口图层。也就是说，在电子设备的宿主应用程序显示提供卡片的应用程序对应的卡片时，电子设备的宿主应用程序显示的是其自身下挂的嵌入式窗口图层，而不是直接显示提供卡片的应用程序对应的卡片。因此，电子设备的应用程序可以根据需求创建包括自定义卡片元素的卡片视图，并根据卡片视图生成包括自定义卡片元素的嵌入式窗口图层，从而在电子设备的宿主应用程序显示应用程序的通知信息时，电子设备的宿主应用程序可以显示包括不同自定义卡片元素的卡片视图。

在一些示例中，在提供卡片的应用程序为出行应用程序(如打车应用程序、地图应用程序等)或者配送应用程序(如外卖应用程序、快递应用程序等)时，自定义卡片元素可以包括进度条，该进度条可以用于提示出行应用程序或者配送应用程序的订单的处理进度。

下面结合附图7，以在电子设备的锁屏显示的打车应用程序卡片为例，对上述进度条进行示意说明。

在电子设备的打车应用程序产生下单打车订单后，电子设备的锁屏界面可以显示打车应用程序卡片。如图7所示，打车应用程序卡片20可以包括进度条21。进度条21可以用于提示用户打车订单的处理进度。进度条21可以包括第一标识01和第二标识02。第一标识01可以用于表示起始点(即司机接单时的接单车辆所在的位置)，即第一标识01可以用于指示打车订单开始执行。第二标识02可以用于表示打车订单的目的地，即第二标识02可以用于指示打车订单执行完成。进度条21还可以包括第一标识01与第二标识02的连接线03，通过在连接线03上显示的车辆标识04，可以指示已有司机接单。以及，在司机接单后，通过车辆标识04与第二标识02之间的距离可以指示接单车辆距离打车订单的目的地的远近，即指示打车订单的处理进度。

需要说明的是，第一标识01和第二标识02可以分别位于进度条21的左右两端。例如，如图7所示，第一标识01可以位于进度条21的左端，第二标识02可以位于进度条21的右端。当然地，第一标识01也可以位于进度条21的右端，第二标识02也可以位于进度条21的左端。

另外，由于打车订单对应的行驶路径的拥堵情况不同，第一标识01与第二标识02之间的连接线03的颜色可以不同，从而不同的颜色可以提示用户不同的拥堵情况。例如，第一标识01与第二标识02的连接线03中某一段的颜色可以为红色，该红色的线段可以表示与该线段对应的行驶路段严重拥堵。又如，第一标识01与第二标识02的连接线03中某一段的颜色可以为黄色，该黄色的线段可以表示与该线段对应的行驶路段较为拥堵。再如，第一标识01与第二标识02的连接线中某一段的颜色可以为绿色，该绿色的线段可以表示与该线段对应的行驶路段严重拥堵较为通畅。

下面结合图8和图9，以提供卡片的应用程序为打车应用程序，宿主应用程序为锁屏，打车应用程序卡片包括进度条为例，对本申请实施例的卡片显示过程进行示意说明。

例如，在用户打开电子设备的打车应用程序后，如图8中的(a)所示，电子设备显示打车应用程序对应的界面31。打车应用程序对应的界面31可以包括出发地输入框32和目的地输入框33。用户可以分别在出发地输入框32和目的地输入框33输入出发地和目的地。在电子设备接收到用户输入的出发地和目的地之后，如图8中的(b)所示，电子设备显示车辆呼叫界面34。车辆呼叫界面34可以包括车型选择控件35、出发时间选择控件36、乘车人数选择控件37、支付方式选择控件38、以及呼叫控件39。用户可以通过车型选择控件35设置接单车辆的类型，如用户可以选择车型A。用户可以通过出发时间选择控件36设置出发时间，如用户可以设置出发时间为当前时间。用户可以通过乘车人数选择控件37设置乘车人数，如用户可以选择2人乘车。用户可以通过支付方式选择控件38选择支付方式，如用户选择线上支付。在用户选择车辆、出发时间、乘车人数、支付方式之后，用户可以点击呼叫控件39。在电子设备接收到用户对呼叫控件39的触发操作时，作为响应，电子设备的打车应用程序产生打车订单，并发布打车订单，以等待司机接单。

在电子设备的打车应用程序监测到司机还未接单时，如图9中的(a)所示，电子设备可以在锁屏界面40中显示打车应用程序卡片41，打车应用程序卡片41可以包括打车应用程序的图标411和“等待司机接单”的文本412。结合图9中的(a)所示，打车应用程序卡片41还可以包括进度条413。进度条413可以包括第一标识01、第二标识02、以及第一标识01与第二标识02的连接线03。其中，第一标识01可以用于表示起始点(即司机接单时的接单车辆所在的位置)，即第一标识01可以用于指示打车订单开始执行。第二标识02可以用于表示打车订单的目的地，即第二标识02可以用于指示打车订单执行完成。此时，第一标识01与第二标识02的连接线03上未显示车辆标识，以提示用户司机还未接单。

在电子设备的打车应用程序监测到司机已接单时，如图9中的(b)所示，电子设备可以在锁屏界面40中显示打车应用程序卡片42。打车应用程序卡片42可以包括打车应用程序的图标421和“司机已接单”的文本422。结合图9中的(b)所示，打车应用程序卡片42还可以包括进度条423。进度条423可以包括第一标识01、第二标识02、以及第一标识01与第二标识02的连接线03。与图9中的(a)所示的进度条413相比，打车应用程序卡片42中的进度条423还可以包括用于车辆标识04，车辆标识04位于第一标识01与第二标识02的连接线03上，且车辆标识04靠近第一标识01。也就是说，通过在第一标识01与第二标识02的连接线03上靠近第一标识01的位置显示车辆标识04，以提示司机已接单。

之后，司机前往出发地接用户，此时，如图9中的(c)所示，电子设备可以在锁屏界面40中显示打车应用程序卡片43。打车应用程序卡片43可以包括打车应用程序的图标431、“车牌号XXX·约2分钟到达”的文本432和“张师傅·白色”文本433。结合图9中的(c)所示，打车应用程序卡片43还可以包括进度条434。进度条434可以包括第一标识01、第二标识02、第一标识01与第二标识02的连接线03、以及位于连接线03上的车辆标识04。与图9中的(b)所示的进度条423相比，进度条434中的车辆标识04朝向第二标识02移动一段距离，说明接单车辆已行驶一段距离，即通过进度条434中的车辆标识04与第二标识02之间的距离的变化，可以提示接单车辆正在驶向用户所在的出发地。例如，车辆标识04与第二标识02之间的距离越短，接单车辆越接近用户所在的出发地。

之后，在电子设备的打车应用程序监测到司机到达出发地时，如图9中的(d)所示，电子设备可以在锁屏界面40中显示打车应用程序卡片44。打车应用程序卡片44可以包括打车应用程序的图标441、“司机已到达”的文本442和“张师傅·白色”文本443。结合图9中的(d)所示，打车应用程序卡片44还可以包括进度条444。进度条444可以包括第一标识01、第二标识02、第一标识01与第二标识02的连接线03、以及位于连接线03上的车辆标识04。与图9中的(c)所示的进度条434相比，进度条444中的车辆标识04继续朝向第二标识02移动一段距离，且车辆标识04的位置保持不变，即通过进度条444中的车辆标识04与第二标识02之间的距离和车辆标识04的移动状态，可以提示司机已到达，请用户尽快上车。

之后，在司机接到用户之后，司机按照打车订单行驶至目的地时，如图9中的(e)所示，电子设备可以在锁屏界面40中显示打车应用程序卡片45。打车应用程序卡片45可以包括打车应用程序的图标451、“驶向目的地·约20分钟到达”的文本452和“张师傅·白色”文本453。结合图9中的(e)所示，打车应用程序卡片45还可以包括进度条454。进度条454可以包括第一标识01、第二标识02、第一标识01与第二标识02的连接线03、以及位于连接线03上的车辆标识04。与图9中的(d)所示的进度条444相比，进度条454中的车辆标识04继续朝向第二标识02移动一段距离，且车辆标识04与第二标识02之间的距离逐渐缩短，即通过进度条454中的车辆标识04与第二标识02之间的距离逐渐缩短，可以提示接单车辆正在驶向目的地。

之后，在打车应用程序监测到用户到达目的地时，如图9中的(f)所示，电子设备可以在锁屏界面40中显示打车应用程序卡片46。打车应用程序卡片46可以包括打车应用程序的图标461和“已到达目的地”的文本462。结合图9中的(f)所示，打车应用程序卡片46还可以包括进度条463。进度条463可以包括第一标识01、第二标识02、第一标识01与第二标识02的连接线03、以及位于第一标识01与第二标识02的连接线03上的车辆标识04。与图9中的(e)所示的打车应用程序卡片45相比，打车应用程序卡片46的进度条463中的车辆标识04移动至第二标识02的位置，以提示接单车辆已到达目的地，打车订单已完成。

也就是说，在打车应用程序的业务发生变化(如打车订单的处理进度发生变化)时，电子设备的锁屏界面中显示的打车应用程序卡片包括的进度条同步更新。

在该示例中，电子设备运行的打车应用程序可以生成包括进度条的卡片视图，并将包括进度条的卡片视图对应的嵌入式窗口图层发送给宿主应用程序，从而电子设备的宿主应用程序可以显示包括进度条的卡片视图对应的嵌入式窗口图层，即电子设备的宿主应用程序可以显示包括进度条的打车应用程序卡片。进而，通过进度条可以更直观、更有效地向用户展示打车订单的处理进度，显示效果更好。再者，根据打车订单的处理进度实时更新进度条，能够保证打车应用程序的通知信息的时效性，用户体验更好。

在一些示例中，进度条可以是分段进度条。例如，继续以在电子设备的锁屏显示的打车应用程序卡片为例，对上述分段进度条进行示意说明，如图10所示，打车应用程序卡片50可以包括分段进度条51。分段进度条51可以用于提示用户打车订单的处理进度。分段进度条51可以包括第一标识01、第二标识02和第三标识05。第一标识01可以用于表示起始点(即司机接单时的接单车辆所在的位置)，即第一标识01可以用于指示打车订单开始执行。第二标识02可以用于表示打车订单的目的地，即第二标识02可以用于指示打车订单执行完成。第三标识05可以用于指示下单的用户所在的出发地。第三标识03位于第一标识01和第二标识02之间，第三标识05可以将第一标识01与第二标识02之间的连接线划分为两段，即第三标识05可以将打车订单的处理过程划分为两个阶段。也就是说，第一标识01与第三标识05的第一连接线06，可以用于指示接单车辆由起始点驶向用户所在的出发地。第三标识05与第二标识02的第二连接线07，可以用于指示接单车辆由用户所在的出发地驶向目的地。如图10所示，分段进度条51还可以包括车辆标识04。当车辆标识04位于第一连接线06上时，说明接单车辆正在由起始点驶向用户所在的出发地。当车辆标识04位于第一连接线07上时，说明接单车辆已接到用户，接单车辆正在由用户所在的出发地驶向目的地。

需要说明的是，可以通过连接线的线型指示打车订单当前所处的处理阶段。例如，在第一连接线06和第二连接线07均为虚线时，指示司机还未接单。在第一连接线06为实线，第二连接线07为虚线时，指示接单车辆正在由起始点驶向用户所在的出发地，即打车订单当前所处的处理阶段为司机接用户的阶段，也即司机还未接到用户，还未进入司机将用户送至目的地的阶段。在第二连接线07为实线时，指示接单车辆正在由用户所在的出发地驶向目的地，即打车订单当前所处的处理阶段进入司机将用户送至目的地的阶段。

第一标识01和第二标识02可以分别位于分段进度条51的左右两端。例如，如图10所示，第一标识01可以位于分段进度条51的左端，第二标识02可以位于分段进度条51的右端。当然地，第一标识01也可以位于分段进度条51的右端，第二标识02也可以位于分段进度条51的左端。

另外，由于打车订单对应的行驶路径的拥堵情况不同，第一标识01与第三标识05的第一连接线06的颜色可以不同，第三标识05与第二标识02的第二连接线07的颜色也可以不同，从而不同的颜色可以提示用户不同的拥堵情况。

下面结合图11，以提供卡片的应用程序为打车应用程序，宿主应用程序为锁屏，打车应用程序卡片包括分段进度条为例，对本申请实施例的卡片显示过程进行示意说明。

在用户使用电子设备的打车应用程序下单打车订单之后，当电子设备的打车应用程序监测到司机还未接单时，如图11中的(a)所示，电子设备可以在锁屏界面60中显示打车应用程序卡片61，打车应用程序卡片61可以包括打车应用程序的图标611和“等待司机接单”的文本612。结合图11中的(a)所示，打车应用程序卡片61还可以包括进度条613。进度条613可以包括第一标识01、第二标识02、和位于第一标识01和第二标识02之间的第三标识05。第一标识01可以用于表示起始点(即在司机接单时接单车辆所在的位置)，即第一标识01可以用于指示打车订单开始执行。第二标识02可以用于表示打车订单的目的地，即第二标识02可以用于指示打车订单执行完成。第三标识05可以用于指示下单的用户所在的出发地。分段进度条613还包括第一标识01与第三标识05的第一连接线06、第三标识05与第二标识02的第二连接线07。此时，第一连接线06和第二连接线07均为虚线，且第一连接线06上未显示车辆标识，以提示用户司机还未接单。

之后，当电子设备的打车应用程序监测到司机已接单时，如图11中的(b)所示，电子设备可以在锁屏界面60中显示打车应用程序卡片62。打车应用程序卡片62可以包括打车应用程序的图标621和“司机已接单”的文本622。结合图11中的(b)所示，打车应用程序卡片62还可以包括分段进度条623。分段进度条623可以包括第一标识01、第二标识02、和位于第一标识01和第二标识02之间的第三标识05。分段进度条613还包括第一标识01与第三标识05的第一连接线06、第三标识05与第二标识02的第二连接线07和车辆标识04。与图11中的(a)所示的分段进度条613相比，第一连接线06为实线，且车辆标识04位于第一连接线06上，即通过将第一连接线06的线型由虚线更新为实线，以及在第一连接线06上显示车辆标识04，可以提示司机已接单，准确前往出发地接用户。

之后，司机驶向出发地接用户，此时，如图11中的(c)所示，电子设备可以在锁屏界面60中显示打车应用程序卡片63。打车应用程序卡片63可以包括打车应用程序的图标631、“车牌号XXX·约2分钟到达”的文本632和“张师傅·白色”文本633。结合图11中的(c)所示，打车应用程序卡片63还可以包括分段进度条634。分段进度条634可以包括第一标识01、第二标识02、和位于第一标识01和第二标识02之间的第三标识05。分段进度条634还包括第一标识01与第三标识05的第一连接线06、第三标识05与第二标识02的第二连接线07、以及位于第一连接线06上的车辆标识04。与图11中的(b)所示的分段进度条623相比，分段进度条634中的车辆标识04朝向第三标识05移动一段距离，且靠近第三标识05，即通过分段进度条634中车辆标识04的移动方向和车辆标识04与第三标识05之间的距离的变化，可以提示接单车辆即将到达出发地，请用户尽快前往出发地。

之后，在司机接到用户，并驶向目的地时，如图11中的(d)所示，电子设备可以在锁屏界面60中显示打车应用程序卡片64。打车应用程序卡片64可以包括打车应用程序的图标641、“驶向目的地·约20分钟到达”的文本642和“张师傅·白色”文本643。结合图11中的(d)所示，打车应用程序卡片64还可以包括分段进度条644。分段进度条644可以包括第一标识01、第二标识02、和位于第一标识01和第二标识02之间的第三标识05。分段进度条644还包括第一标识01与第三标识05的第一连接线06、第三标识05与第二标识02的第二连接线07、和车辆标识04。与图11中的(c)所示的分段进度条634相比，分段进度条644中的第二连接线07为实线，且车辆标识04位于第二连接线07上，说明接单车辆已接到用户，接单车辆正在由用户所在的出发地驶向目的地，即通过将第二连接线07的线型由虚线更新为实线，以及在第二连接线07上显示车辆标识04，可以提示司机已接到用户，并前往目的地。

之后，在接单车辆行驶至目的地时，如图11中的(e)所示，电子设备可以在锁屏界面60中显示打车应用程序卡片65。打车应用程序卡片65可以包括打车应用程序的图标651和“已到达目的地”的文本652。结合图11中的(e)所示，打车应用程序卡片65还可以包括分段进度条653。与图11中的(d)所示的分段进度条644相比，分段进度条653可以包括第一标识01和第二标识02，即分段进度条653不包括第三标识。分段进度条653还可以包括第一标识01与第二标识02的连接线03，且该连接线03为实线，即通过取消显示分段进度条654中的第三标识和车辆标识，并显示的第一标识01与第二标识02的连接线03，可以提示接单车辆已到达目的地，打车订单已完成。

也就是说，在打车应用程序的业务发生变化(打车订单的处理进度发生变化)时，电子设备的锁屏界面中显示的打车应用程序卡片包括的分段进度条同步更新。

在该示例中，电子设备运行的打车应用程序可以生成包括分段进度条的卡片视图，并将包括分段进度条的卡片视图对应的嵌入式窗口图层发送给宿主应用程序，从而电子设备的宿主应用程序可以显示包括分段进度条的卡片视图对应的嵌入式窗口图层，即电子设备的宿主应用程序可以显示包括分段进度条的打车应用程序卡片。进而，通过分段进度条可以更直观、更有效地向用户展示打车订单的处理进度，显示效果更好。再者，根据打车订单的处理进度实时更新分段进度条，能够保证打车应用程序的通知信息的时效性，用户体验更好。

在一些示例中，在提供卡片的应用程序为打车应用程序时，打车应用程序可以包括第一进度条和第二进度条，第一进度条用于指示接单车辆由起始点(即在司机接单时接单车辆所在的位置)驶向用户所在的出发地，第二进度条用于指示接单车辆由用户所在的出发地驶向目的地。

下面结合图12，继续以提供卡片的应用程序为打车应用程序，宿主应用程序为锁屏，打车应用程序卡片包括第一进度条和第二进度条为例，对本申请实施例的卡片显示过程进行示意说明。

在用户使用电子设备的打车应用程序下单打车订单之后，当电子设备的打车应用程序监测到司机还未接单时，如图12中的(a)所示，电子设备可以在锁屏界面70中显示打车应用程序卡片71，打车应用程序卡片71可以包括打车应用程序的图标711和“等待司机接单”的文本712。结合图12中的(a)所示，打车应用程序卡片71还可以包括第一进度条713。第一进度条713可以包括第一标识01、第三标识05、和第一标识01与第三标识05之间的第一连接线06。第一标识01可以用于表示起始点(即在司机接单时接单车辆所在的位置)，即第一标识01可以用于指示打车订单开始执行。第三标识05可以用于指示下单的用户所在的出发地。此时，第一标识01与第三标识05之间的第一连接线06上未显示车辆标识，以提示用户司机还未接单。

在用户使用电子设备的打车应用程序下单打车订单之后，当电子设备的打车应用程序监测到司机已接单时，如图12中的(b)所示，电子设备可以在锁屏界面70中显示打车应用程序卡片72。打车应用程序卡片72可以包括打车应用程序的图标721和“司机已接单”的文本722。结合图12中的(b)所示，打车应用程序卡片72还可以包括第一进度条723。第一进度条723可以包括第一标识01、第三标识05、和第一标识01与第三标识05的第一连接线06。与图12中的(a)所示的第一进度条713相比，第一进度条723还可以包括第一标识01与第三标识05的第一连接线06上显示的车辆标识04，且车辆标识04靠近第一标识01，即通过在第一标识01与第二标识02的第一连接线06上靠近第一标识01的位置显示车辆标识04，可以提示司机已接单，准确前往出发地接用户。

之后，司机驶向出发地接用户，此时，如图12中的(c)所示，电子设备可以在锁屏界面70中显示打车应用程序卡片73。打车应用程序卡片73可以包括打车应用程序的图标731、“车牌号XXX·约2分钟到达”的文本732和“张师傅·白色”文本733。结合图12中的(c)所示，打车应用程序卡片73还可以包括第一进度条734。第一进度条734可以包括第一标识01、第三标识05、第一标识01与第三标识05的第一连接线06、和车辆标识04。与图12中的(b)所示的第一进度条723相比，第一进度条734中的车辆标识04朝向第三标识05移动一段距离，即接单车辆向用户所在的出发地行驶一段距离，也就是说，通过第一进度条734中车辆标识04与第三标识05之间的距离的变化，可以提示接单车辆即将到达出发地，请用户尽快前往出发地。

之后，在司机到达出发地时，如图12中的(d)所示，电子设备可以在锁屏界面70中显示打车应用程序卡片74。打车应用程序卡片74可以包括打车应用程序的图标741、“司机已到达”的文本742和“张师傅·白色”文本743。结合图12中的(d)所示，打车应用程序卡片74还可以包括第一进度条744。第一进度条744可以包括第一标识01、第三标识05、第一标识01与第三标识05的第一连接线06、和车辆标识04。与图12中的(c)所示的第一进度条734相比，第一进度条744中的车辆标识04移动至第三标识05所在的位置，即通过第一进度条734中车辆标识04与第三标识05之间的距离的变化，提示司机到达出发地，等待用户上车。

之后，在司机接到用户，并驶向目的地时，如图12中的(e)所示，电子设备可以在锁屏界面70中显示打车应用程序卡片75。打车应用程序卡片75可以包括打车应用程序的图标751、“驶向目的地·约20分钟到达”的文本752和“张师傅·白色”文本753。结合图12中的(e)所示，打车应用程序卡片75还可以包括第二进度条754。第二进度条754可以包括第三标识05、第二标识02、第三标识05与第二标识02的第二连接线07、以及位于第三标识05与第二标识02的第二连接线07上的车辆标识04。与图12中的(d)所示的打车应用程序卡片74相比，打车应用程序卡片75的进度条更新为第二进度条754，第二进度条用于指示接单车辆由用户所在的出发地驶向目的地，也就是说，通过将打车应用程序卡片75中的进度条更新为第二进度条74，并在第二进度条74上显示车辆标识04，可以提示司机已接到用户，并准备驶向目的地。

之后，在打车应用程序监测到用户到达目的地时，如图12中的(f)所示，电子设备可以在锁屏界面70中显示打车应用程序卡片76。打车应用程序卡片76可以包括打车应用程序的图标761和“已到达目的地”的文本762。结合图12中的(f)所示，打车应用程序卡片76还可以包括第二进度条763。第二进度条763可以包括第三标识05、第二标识02、第三标识05与第二标识02的第二连接线07、以及位于第三标识05与第二标识02的第二连接线07上的车辆标识04。与图12中的(e)所示的打车应用程序卡片75相比，打车应用程序卡片76的第二进度条763中的车辆标识04移动至第二标识02的位置，以提示接单车辆已到达目的地，打车订单已完成。

也就是说，在打车应用程序的业务发生变化(打车订单的处理进度发生变化)时，电子设备的锁屏界面中显示的打车应用程序卡片包括的进度条同步更新。

在该示例中，电子设备运行的打车应用程序可以生成包括进度条的卡片视图，并将包括进度条的卡片视图对应的嵌入式窗口图层发送给宿主应用程序，从而电子设备的宿主应用程序可以显示包括进度条的卡片视图对应的嵌入式窗口图层，即电子设备的宿主应用程序可以显示包括进度条的打车应用程序卡片。进而，通过进度条可以更直观、更有效地向用户展示打车订单的处理进度，显示效果更好。再者，根据打车订单的处理进度实时更新进度条，能够保证打车应用程序的通知信息的时效性，用户体验更好。

在一些示例中，在电子设备显示其他应用程序对应的卡片时，也可以显示包括进度条的卡片。以在电子设备的锁屏显示的打外卖应用程序卡片为例，对上述分段进度条进行示意说明。

如图13所示，外卖应用程序卡片80可以包括分段进度条81。分段进度条81可以用于提示用户外卖订单的处理进度。分段进度条81可以包括第四标识08、第五标识09和第六标识010。第四标识08可以用于表示起始点(即骑手接单时所在的位置)，即第四标识08可以用于指示外卖订单开始执行。第五标识09可以用于表示外卖订单的下单用户的所在地，即第五标识09可以用于指示外卖订单执行完成。第六标识010可以用于指示外卖订单对应的商家所在的位置。第六标识010位于第四标识08和第五标识09之间，第六标识010可以将第四标识08与第五标识09的连接线划分为两段，即第六标识010可以将外卖订单的处理过程划分为两个阶段。也就是说，第四标识08与第六标识010的第三连接线011，第三连接线011可以用于指示骑手由起始点至商家所在的位置，即第三连接线011可以用于指示商家接单的阶段。第六标识010与第五标识09的第四连接线012，第四连接线012可以用于指示骑手由商家所在的位置至用户所在地，即第四连接线012可以用于指示骑手送单的阶段。如图13所示，分段进度条81还可以包括骑手标识013。当骑手标识013位于第三连接线011上时，说明骑手由起始点至商家所在的位置，即外卖订单处于商家接单的阶段。当骑手标识013位于第四连接线012上时，说明骑手由商家所在的位置至用户所在地，即外卖订单处于骑手送单的阶段。

下面结合图14，以提供卡片的应用程序为外卖应用程序，宿主应用程序为通知中心，外卖应用程序卡片包括分段进度条为例，对本申请实施例的卡片显示过程进行示意说明。

在用户使用电子设备的外卖应用程序下单外卖订单之后，当电子设备的外卖应用程序监测到骑手还未接单时，如图14中的(a)所示，电子设备可以在通知中心90中显示外卖应用程序卡片91，外卖应用程序卡片91可以包括外卖应用程序的图标911和“等待商家接单”的文本912。结合图14中的(a)所示，外卖应用程序卡片91还可以包括分段进度条913。分段进度条913可以包括第四标识08、第五标识09、和位于第四标识08和第五标识09之间的第六标识010。第四标识08可以用于表示起始点(即骑手接单时所在的位置)，即第四标识08可以用于指示外卖订单开始执行。第五标识09可以用于表示外卖订单的下单用户的所在地，即第五标识09可以用于指示外卖订单执行完成。第六标识010可以用于指示外卖订单对应的商家所在的位置。结合图14中的(a)所示，分段进度条913还包括第四标识08与第六标识010的第三连接线011、第六标识010与第五标识09的第四连接线012。此时，第三连接线011和第四连接线012均为虚线，以提示用户商家还未接单。

之后，当电子设备的外卖应用程序监测到商家已接单时，如图14中的(b)所示，电子设备可以在通知中心90中显示外卖应用程序卡片92。外卖应用程序卡片92可以包括外卖应用程序的图标921、“商家已接单”的文本922和“预计12:42送达”的文本923。结合图14中的(b)所示，外卖应用程序卡片92还可以包括分段进度条924。分段进度条924可以包括第四标识08、第五标识09、和位于第四标识08和第五标识09之间的第六标识010。分段进度条924还包括第四标识08与第六标识010的第三连接线011、第六标识010与第五标识09的第四连接线012。图14中的(a)所示的分段进度条913相比，第三连接线011为实线，第四连接线012为虚线，即通过将第三连接线011的线型由虚线更新为实线，可以提示商家已接单，正在准确外卖，等待骑手接单。

之后，在骑手接单，并前往商家取单时，如图14中的(c)所示，电子设备可以在通知中心90中显示外卖应用程序卡片93。外卖应用程序卡片93可以包括外卖应用程序的图标931、“骑手已接单”的文本932和“距离商家1千米，1分钟到达”文本933。结合图14中的(c)所示，外卖应用程序卡片93还可以包括分段进度条934。分段进度条934可以包括第四标识08、第五标识09、和位于第四标识08和第五标识09之间的第六标识010。分段进度条934还可以包括第四标识08与第六标识010的第三连接线011、第六标识010与第五标识09的第四连接线012。与图14中的(b)所示的分段进度条924相比，分段进度条934还可以包括在第三连接线011上显示的骑手标识013，即通过在分段进度条934中的第三连接线011上显示的骑手标识013，可以提示骑手已接单，并正在前往商家取单。

之后，在骑手从商家取到外卖，并给用户配送外卖时，如图14中的(d)所示，电子设备可以在通知中心90中显示外卖应用程序卡片94。外卖应用程序卡片94可以包括外卖应用程序的图标941、“骑手正在送货”的文本942和“距你602米，预计8分钟送达”文本943。结合图14中的(d)所示，外卖应用程序卡片94还可以包括分段进度条944。分段进度条944可以包括第四标识08、第五标识09、和位于第四标识08和第五标识09之间的第六标识010。分段进度条944还包括第四标识08与第六标识010的第三连接线011、第六标识010与第五标识09的第四连接线012、以及骑手标识013。与图14中的(c)所示的分段进度条934相比，第三连接线011和第四连接线012均为实线，且骑手标识013位于第四连接线012上，说明骑手已从商家取到外卖，骑手由商家所在位置前往用户所在地，即通过第四连接线012的线型由虚线更新为实线，以及在第四连接线012上显示骑手标识013，可以提示骑手已从商家取到外卖，并正在给用户配送外卖。

之后，在骑手已将外卖送至目的地时，如图14中的(e)所示，电子设备可以在通知中心90中显示外卖应用程序卡片95。外卖应用程序卡片95可以包括外卖应用程序的图标951、“订单已送达”的文本952和“欢迎再次光临”的文本953。结合图14中的(e)所示，外卖应用程序卡片95还可以包括分段进度条954。与图14中的(d)所示的分段进度条944相比，分段进度条954可以包括第四标识08和第五标识09，而不包括第六标识。并且，分段进度条954还可以包括第四标识08与第五标识09的连接线014，且该第四标识08与第五标识09的连接线014为实线，即通过取消显示分段进度条954中的第六标识和骑手标识，并显示的第四标识08与第五标识09的连接线014，可以提示外卖已送达，外卖订单已完成。

也就是说，在外卖应用程序的业务发生变化(外卖订单的处理进度发生变化)时，电子设备的通知中心中显示的外卖应用程序卡片包括的分段进度条同步更新。

在该示例中，电子设备运行的外卖应用程序可以生成包括分段进度条的卡片视图，并将包括分段进度条的卡片视图对应的嵌入式窗口图层发送给宿主应用程序，从而电子设备的宿主应用程序可以显示包括分段进度条的卡片视图对应的嵌入式窗口图层，即电子设备的宿主应用程序可以显示包括分段进度条的外卖应用程序卡片。进而，通过分段进度条可以更直观、更有效地向用户展示外卖订单的处理进度，显示效果更好。再者，根据外卖订单的处理进度实时更新分段进度条，能够保证外卖应用程序的通知信息的时效性，用户体验更好。

需要说明的是，在电子设备的宿主应用程序显示卡片时，电子设备前台运行的宿主应用程序可以发生变化，对于不同的宿主应用程序，电子设备的界面所要显示的内容不同，因此，可以根据宿主应用程序的显示内容显示相适应的卡片。也就是说，在不同的宿主应用程序显示提供卡片的应用程序对应的卡片时，提供卡片的应用程序对应的卡片的显示方式不同。其中，提供卡片的应用程序对应的卡片的显示方可以包括显示内容、显示尺寸和显示位置中的至少一项。

下面结合图15，以提供卡片的应用程序为打车应用程序为例，对本申请实施例的卡片显示过程进行示意说明。

在用户需要打车时，可以使用电子设备的打车应用程序下单打车订单。之后，在电子设备显示桌面的情况下，当打车应用程序的业务发生变化(如司机接单)时，如图15中的(a)所示，在电子设备的桌面110的顶部可以显示打车应用程序卡片111。打车应用程序卡片111可以用于提示司机已接单。结合图15中的(a)所示，打车应用程序卡片111可以包括打车应用程序的图标112、“车牌号XXX·约2分钟到达”的文本113、“张师傅·白色”的文本114。打车应用程序卡片111还可以包括呼叫控件115，呼叫控件115可以用于联系接单司机。其中，打车应用程序卡片111的显示高度为h1，打车应用程序卡片111的显示宽度为d1。

电子设备的桌面110显示打车应用程序卡片111之后，在电子设备接收到用户在显示屏的顶部状态栏的下拉操作时，作为响应，如图15中的(b)所示，电子设备显示通知中心120，并在通知中心120显示打车应用程序卡片121。结合图15中的(b)所示，打车应用程序卡片121可以包括打车应用程序的图标122、“车牌号XXX·约2分钟到达”的文本123、“张师傅·白色”的文本124。与图15中的(a)所示的打车应用程序卡片111相比，打车应用程序卡片121还可以包括进度条125。进度条125可以更直观地向用户提示打车订单的处理进度。以及，打车应用程序卡片121的显示高度为h2，打车应用程序卡片121的显示宽度为d2。其中，打车应用程序卡片121的显示高度h2小于打车应用程序卡片111的显示高度h1。打车应用程序卡片121的显示宽度d2可以与打车应用程序卡片111的显示宽度d1相等。可见，在电子设备前台运行的宿主应用程序由桌面切换为通知中心时，可以缩小打车应用程序卡片的显示尺寸，能够减小打车应用程序卡片所占的空间，使得电子设备可以显示更多的其他通知信息卡片，进而用户不需要通过翻阅操作即可查看更多的通知信息卡片，能够提高人机交互效率。

电子设备的桌面110显示打车应用程序卡片111之后，在电子设备接收到用户的锁屏操作(如按压锁屏键)时，电子设备进入锁屏状态。在电子设备处于锁屏状态时，响应于用户对电子设备的显示屏的触控操作，如图15中的(c)所示，电子设备显示锁屏界面130，并在锁屏界面130显示打车应用程序卡片131。结合图15中的(c)所示，打车应用程序卡片131可以包括打车应用程序的图标132、“车牌号XXX·约2分钟到达”的文本133、“张师傅·白色”的文本134。与图15中的(a)所示的打车应用程序卡片111和图15中的(b)所示的打车应用程序卡片121相比，打车应用程序卡片131还可以包括进度条135。进度条135可以更直观地向用户提示打车订单的处理进度。以及，打车应用程序卡片131的显示高度为h3，打车应用程序卡片131的显示宽度为d3。其中，打车应用程序卡片131的显示高度h3小于打车应用程序卡片121的显示高度h2。打车应用程序卡片131的显示宽度d3可以与打车应用程序卡片111的显示宽度d1相等。另外，打车应用程序卡片131位于锁屏界面130的下侧，而打车应用程序卡片111位于桌面110的顶部，即打车应用程序卡片131的显示位置与打车应用程序卡片111的显示位置不同。可见，在电子设备前台运行的宿主应用程序由桌面切换为锁屏时，可以缩小打车应用程序卡片的显示尺寸，能够减小打车应用程序卡片所占的空间，使得电子设备可以显示更多的其他通知信息卡片，进而用户不需要通过翻阅操作即可查看更多的通知信息卡片，能够提高人机交互效率。

电子设备的桌面110显示打车应用程序卡片111之后，在电子设备接收到用户的锁屏操作(如按压锁屏键)时，如图15中的(d)所示，电子设备显示息屏(always on display，AOD)界面140，并在息屏界面140显示打车应用程序卡片141。与图15中的(a)所示的打车应用程序卡片111相比，打车应用程序卡片141为卡片胶囊，在电子设备接收到用户对打车应用程序卡片141(即卡片胶囊)的触控操作(如滑动操作)，电子设备打开打车应用程序。并且，由于电子设备的息屏界面的空间有限，因此，打车应用程序卡片141(即卡片胶囊)的显示高度h4小于打车应用程序卡片111的显示高度h1，打车应用程序卡片141(即卡片胶囊)的显示宽度d3小于打车应用程序卡片111的显示宽度d1，这样在电子设备的前台运行的宿主应用程序切换为息屏时，可以最大限度减小打车应用程序卡片所占的空间，避免打车应用程序卡片无法完整显示。另外，结合图15中的(d)所示，由于打车应用程序卡片141(即卡片胶囊)的显示尺寸较小，打车应用程序卡片141(即卡片胶囊)可以包括部分打车订单的相关信息(如打车应用程序的图标142、“车牌号XXX”的文本143)，这样用户不需要打开打车应用程序，即可以获知打车应用程序的部分信息，使用更便捷。

在该示例中，在电子设备的宿主应用程序显示卡片时，针对不同宿主应用程序，卡片的显示方式可以不同，可以保证在不同宿主应用程序显示的卡片均具有较好的显示效果。再者，针对不同宿主应用程序所要显示的内容和用户的使用习惯，可以有侧重点的设置卡片所承载的内容信息，以达到通知用户的目的，还能够提高人机交互效率，进而提升用户体验。

以下实施例中的方法均可以在具有上述硬件结构或软件结构的电子设备中实现。

由于在电子设备开机后，宿主应用程序(桌面、负一屏、通知中心、横幅通知、息屏和锁屏等)对打车应用程序的业务变更进行注册(图中未示出)，因此，当打车应用程序的发生业务变更时，电子设备可以生成所有注册打车应用程序的业务变更的宿主应用程序中各宿主应用程序对应的打车应用程序卡片的卡片视图，并当某一宿主应用程序在电子设备的前台运行时，显示该宿主应用程序对应的打车应用程序卡片的卡片视图，即显示该宿主应用程序对应的打车应用程序卡片。

下面以卡片提供应用程序为打车应用程序，宿主应用程序为第一宿主应用程序为例，结合图16，对本申请实施例提供的一种卡片显示方法进行详细说明。图16为本申请实施例提供的一种卡片显示方法的流程示意图。如图16所示，该卡片显示方法可以包括下述S1601-S1630。

S1601、打车应用程序产生打车订单。

在一些示例中，电子设备的打车应用程序可以接收用户的下单操作，响应于下单操作，电子设备的打车应用程序产生打车订单。具体地，在用户使用电子设备的打车应用程序下单打车订单时，用户可以启动电子设备的打车应用程序，并在打车应用程序上执行相应的下单操作，即电子设备的打车应用程序可以接收用户的下单操作。然后，电子设备的打车应用程序响应于用户的下单操作，电子设备的打车应用程序产生打车订单。

其中，上述下单操作可以包括一个操作，也可以包括多个操作。

示例性地，在下单操作包括多个操作时，下单操作可以包括输入打车订单相关信息的操作和触发产生打车订单的操作。例如，输入打车订单相关信息的操作可以包括输入出发地信息、目的地信息、出发时间信息、车辆类型信息的操作。触发生成打车订单的操作可以是对下单控件的点击操作。如下单控件可以是如图8中的(b)所示的呼叫控件39。

S1602、打车应用程序向决策中台发送卡片UUID和卡片实例信息。

在打车应用程序产生打车订单后，打车应用程序可以产生与打车订单对应的卡片实例信息(即cardInstanceId)。在电子设备的打车应用程序生成打车订单对应的cardInstanceId后，打车应用程序可以向决策中台发送打车订单对应的cardInstanceId。

卡片实例信息可以用于指示打车应用程序产生的打车订单，即一个打车订单对应生成一个唯一的卡片实例信息。

例如，在用户使用打车应用程序下单两个打车订单(如订单A和订单B)时，可以生成与订单A对应的卡片实例信息1，以及生成与订单B对应的卡片实例信息2。在订单A的处理进度发生变化时，打车应用程序可以根据卡片实例信息1，确定电子设备所要显示的打车应用程序卡片为订单A对应的打车应用程序卡片。在订单B的处理进度发生变化时，打车应用程序可以根据卡片实例信息2，确定电子设备所要显示的打车应用程序卡片为生成订单B对应的打车应用程序卡片。

以及，在电子设备的打车应用程序产生打车订单之后，当打车订单的处理进度发生变化(如司机接单)时，打车应用程序可以生成卡片UUID，并向电子设备的决策中台发送卡片UUID，以通知决策中台当前需要显示卡片UUID对应的打车应用程序卡片(即打车应用程序的通知信息对应的卡片)。

卡片UUID可以用于唯一标识与打车应用程序的业务(即打车订单的处理进度)对应的一组卡片。也就是说，在打车订单的处理进度发生变化时，打车应用程序向决策中台发送卡片UUID。

具体地，在电子设备的宿主应用程序显示卡片时，电子设备前台运行的宿主应用程序可以发生变化，对于不同的宿主应用程序，电子设备的界面所要显示的内容不同，也就是说，对于打车应用程序的同一个业务(如司机接单)，在电子设备的不同宿主应用程序显示的打车应用程序卡片不同。因此，卡片UUID可以用于唯一标识打车应用程序的一个业务对应的一组卡片，即电子设备的桌面对应打车应用程序卡片、电子设备的锁屏对应打车应用程序卡片、电子设备的通知中心对应打车应用程序卡片、电子设备的横幅通知(或称为状态栏)对应打车应用程序卡片、电子设备的息屏对应打车应用程序卡片、电子设备的负一屏对应打车应用程序卡片。

例如，在电子设备的打车应用程序产生打车订单后，电子设备的打车应用程序会发布打车任务，并等待司机接单。在司机接单后，打车应用程序可以生成用于标识一组指示司机已接单的卡片对应的卡片UUID(如a8146578-c7b1-4a19-92eb-f91ae4542779)，并向电子设备的决策中台发送该卡片UUID，以通知决策中台当前需要显示指示司机已接单的卡片。

S1603、决策中台向卡片显示服务发送卡片创建通知，该卡片创建通知包括卡片UUID和cardInstanceId，该卡片创建通知用于指示卡片显示服务创建打车应用程序卡片。

电子设备的决策中台接收打车应用程序发送的卡片UUID后，决策中台可以根据卡片UUID，获取打车应用程序的业务对应的AppClipInfo(如打车应用程序的包名等)。决策中台可以根据AppClipInfo，判断打车应用程序是否具有卡片显示权限。例如决策中台可以将打车应用程序的包名与电子设备存储的白名单进行比对，当打车应用程序的包名在电子设备存储的白名单中，即确定打车应用程序具有卡片显示权限。在决策中台确定打车应用程序具有卡片显示权限之后，决策中台可以确定打车应用程序为满足紧急条件的应用程序，进而决策中台可以向卡片显示服务发送卡片创建通知，以通知卡片显示服务创建打车应用程序卡片(即打车应用程序的通知信息对应的卡片)。

需要说明的是，满足紧急条件的应用程序可以为预设应用程序。预设应用程序可以包括与时间信息相关的应用程序(如打车应用程序、外卖应用程序、地图应用程序、快递应用程序等)、与财产信息相关的应用程序(如支付应用程序)与财产信息相关的应用程序(如支付应用程序、财务应用程序等)、与人身安全信息相关的应用程序(如运动监测应用程序、紧急呼叫应用程等)。

S1604、卡片显示服务向电子设备的第一宿主应用程序发送卡片显示通知，该卡片显示通知可以包括卡片UUID和cardInstanceId，该卡片显示通知用于通知电子设备的第一宿主应用程序显示打车应用程序卡片。

其中，卡片UUID可以是从打车应用程序获取的。具体地，在电子设备的打车应用程序产生打车订单之后，当打车订单的处理进度发生变化时，打车应用程序生成并向电子设备的决策中台发送卡片UUID，决策中台在接收到卡片UUID后，决策中台向电子设备的卡片显示服务发送携带卡片UUID的卡片创建通知。

cardInstanceId可以是从打车应用程序获取的。具体地，在电子设备的打车应用程序产生打车订单后，打车应用程序生成打车订单对应的cardInstanceId。在电子设备的打车应用程序生成打车订单对应的cardInstanceId后，打车应用程序可以向决策中台发送打车订单对应的cardInstanceId，在决策中台接收到cardInstanceId后，决策中台可以向电子设备的卡片显示服务发送携带cardInstanceId的卡片创建通知，进而卡片显示服务可以向电子设备的第一宿主应用程序发送携带cardInstanceId的卡片显示通知。

在一种示例中，在电子设备开机后，宿主应用程序(桌面、负一屏、通知中心、横幅通知、息屏和锁屏等)可以对打车应用程序的业务变更进行注册(图中未示出)，当打车应用程序的发生业务变更时，卡片显示服务向这些宿主应用程序发送卡片显示通知，以通知电子设备的各宿主应用程序当前需要显示打车应用程序卡片。在电子设备的各宿主应用程序接收到卡片显示服务发送的卡片显示通知后，电子设备的各宿主应用程序可以向该宿主应用程序对应的Host AAR发送卡片显示通知，以通知该宿主应用程序对应的Host AAR当前需要显示打车应用程序卡片。

上述注册过程还可以在其他时机进行，例如，在电子设备安装打车应用程序时，电子设备更新打车应用程序时，本申请对此不进行限定。

也就是说，在电子设备的卡片显示服务接收到决策中台发送的卡片创建通知之后，卡片显示服务可以分别向上述注册打车应用程序的业务变更的宿主应用程序发送卡片显示通知。上述注册打车应用程序的业务变更的宿主应用程序包括上述第一宿主应用程序，即该第一宿主应用程序可以是桌面、负一屏、通知中心、横幅通知、息屏或者锁屏中的任意一个应用程序。需要说明的是，卡片显示服务向注册打车应用程序的业务变更的多个宿主应用程序发送卡片显示通知的具体实现过程，可以是以S1604(即卡片显示服务向第一宿主应用程序发送卡片显示通知的具体实现过程)为例进行示意说明。

S1605、第一宿主应用程序向第一宿主应用程序对应的Host AAR发送卡片显示通知，该卡片显示通知可以包括卡片UUID和cardInstanceId。

在第一宿主应用程序接收到卡片显示服务发送的卡片显示通知后，第一宿主应用程序可以向第一宿主应用程序对应的Host AAR发送卡片显示通知，以通知第一宿主应用程序对应的Host AAR当前需要显示打车应用程序卡片。

需要说明的是，由于在电子设备的卡片显示服务接收到决策中台发送的卡片创建通知之后，卡片显示服务可以分别向所有注册打车应用程序的业务变更的宿主应用程序发送卡片显示通知，因此，在所有注册打车应用程序的业务变更的宿主应用程序中各宿主应用程序接收到卡片显示服务发送的卡片显示通知后，各宿主应用程序可以向该宿主应用程序对应的Host AAR发送卡片显示通知。其中，各宿主应用程序向该宿主应用程序对应的Host AAR发送卡片显示通知的具体实现过程，可以是以S1605(即第一宿主应用程序向第一宿主应用程序对应的Host AAR发送卡片显示通知的具体实现过程)为例进行示意说明。

S1606、第一宿主应用程序对应的Host AAR向卡片管理服务发送卡片UUID、cardInstanceId、第一宿主应用程序对应的hostinfo和第一宿主应用程序对应的size。

在第一宿主应用程序对应的Host AAR接收第一宿主应用程序发送的包括卡片UUID和cardInstanceId后，第一宿主应用程序对应的Host AAR可以向卡片管理服务发送卡片UUID和cardInstanceId。

第一宿主应用程序对应的标识信息(即hostinfo)和第一宿主应用程序对应的卡片尺寸信息(即size)可以是第一宿主应用程序预先生成的。示例性地，在电子设备开机后，第一宿主应用程序可以对打车应用程序的业务变更进行注册，在第一宿主应用程序对打车应用程序的业务变更进行注册后，第一宿主应用程序可以生成第一宿主应用程序对应的hostinfo和第一宿主应用程序对应的size，并通过第一宿主应用程序对应的Host AAR向卡片管理服务发送第一宿主应用程序对应的hostinfo和第一宿主应用程序对应的size。

在介绍第一宿主应用程序对应的hostinfo之前，先对宿主应用程序的hostinfo进行说明。

宿主应用程序的hostinfo可以包括宿主应用程序对应的宿主标识(即host id)和宿主应用程序对应的卡片视图标识(即view id)。

其中，宿主标识可以用于唯一标识电子设备的宿主应用程序，即电子设备的不同宿主应用程序对应不同的宿主标识。

例如，以电子设备的宿主应用程序包括桌面、通知中心、锁屏、息屏、负一屏、横幅通知为例，桌面对应的host id为1，通知中心对应的host id为2，锁屏对应的host id为3，息屏对应的host id为4，负一屏对应的host id为5，横幅通知对应的host id为6。

卡片视图标识可以唯一标识宿主应用程序所要显示的卡片对应的卡片视图(即view)。

例如，继续以电子设备的宿主应用程序包括桌面、通知中心、锁屏、息屏、负一屏、横幅通知为例，针对打车应用程序的同一业务(如司机接单)，桌面对应的打车应用程序卡片的卡片视图的view id为1，通知中心对应的打车应用程序卡片的卡片视图的view id为2，锁屏对应的打车应用程序卡片的卡片视图的view id为3，息屏对应的打车应用程序卡片的卡片视图的view id为4，负一屏对应的打车应用程序卡片的卡片视图的view id为5，横幅通知对应的打车应用程序卡片的卡片视图的view id为6。

需要说明的是，由于不同宿主应用程序对应的同一个打车应用卡片的卡片视图标识不同。因此，在电子设备的宿主应用程序显示打车应用程序卡片时，电子设备可以根据宿主应用程序对应的host id，确定宿主应用程序对应的view id，进而可以根据宿主应用程序对应的view id从打车应用程序获取打车应用程序卡片的卡片视图。

下面对第一宿主应用程序对应的hostinfo进行说明。

上述第一宿主应用程序的hostinfo可以包括第一宿主应用程序对应的host id和第一宿主应用程序对应的view id。

第一宿主应用程序对应的host id可以用于唯一标识第一宿主应用程序。例如，第一宿主应用程序为桌面，则第一宿主应用程序对应的host id为1。又如，第一宿主应用程序为通知中心，则第一宿主应用程序对应的host id为2。

第一宿主应用程序对应的view id为第一宿主应用程序所要显示的卡片对应的卡片视图的标识信息。例如，第一宿主应用程序为桌面，则第一宿主应用程序对应的view id为1。又如，第一宿主应用程序为通知中心，则第一宿主应用程序对应的view id为2。

宿主应用程序对应的卡片尺寸信息可以是宿主应用程序所允许显示的卡片对应的卡片视图的尺寸信息，即提供卡片的应用程序(如打车应用程序)生成的卡片视图的尺寸信息。宿主应用程序对应的卡片尺寸信息可以包括显示高度和显示宽度。

上述第一宿主应用程序对应的卡片尺寸信息，即第一宿主应用程序所允许显示的卡片对应的卡片视图的尺寸信息。例如，第一宿主应用程序为桌面，则第一宿主应用程序对应的卡片尺寸信息可以包括显示高度h1和显示宽度d1。又如，第一宿主应用程序为息屏，则第一宿主应用程序对应的卡片尺寸信息可以包括显示高度h4和显示宽度d4，显示高度h4小于显示高度h1，显示宽度d4小于显示宽度d1。

需要说明的是，由于注册打车应用程序的业务变更的宿主应用程序(如桌面、负一屏、通知中心、横幅通知、息屏和锁屏等)中各宿主应用程序均可以向该宿主应用程序对应的Host AAR发送卡片显示通知，因此，在各宿主应用程序对应的Host AAR接收卡片显示通知后，各宿主应用程序对应的Host AAR均可以向卡片管理服务发送卡片UUID、cardInstanceId、该宿主应用程序对应的hostinfo和该宿主应用程序对应的size。其中，各宿主应用程序向卡片管理服务发送卡片UUID、cardInstanceId、该宿主应用程序对应的hostinfo和该宿主应用程序对应的size的具体实现过程，可以是以S1606(即第一宿主应用程序对应的Host AAR向卡片管理服务发送卡片UUID、cardInstanceId、第一宿主应用程序对应的hostinfo和第一宿主应用程序对应的size的具体实现过程)为例进行示意说明。

S1607、卡片管理服务根据卡片UUID，获取打车应用程序的业务对应的AppClipInfo。

打车应用程序的业务对应的AppClipInfo可以包括打车应用程序的包名、打车应用程序的业务对应的具体实现的类名等。

具体地，在电子设备的卡片管理服务接收到第一宿主应用程序对应的Host AAR发送的卡片UUID后，卡片管理服务可以通过软件包管理服务(package manager service，PMS)，根据卡片UUID，获取打车应用程序的业务对应的AppClipInfo。

由于卡片UUID可以用于唯一标识与打车应用程序的业务(即打车订单的处理进度)对应的一组卡片，因此，卡片管理服务可以根据卡片UUID，获取打车应用程序的业务对应的AppClipInfo，进而根据该AppClipInfo，确定并调用打车应用程序对应的卡片kit。打车应用程序对应的卡片kit可以根据该AppClipInfo，确定打车应用程序的业务对应的TaxiProvider，进而打车应用程序对应的卡片kit可以从打车应用程序的业务对应的TaxiProvider获取打车应用程序卡对应的卡片视图。

S1608、卡片管理服务向打车应用程序对应的卡片kit发送AppClipInfo、cardInstanceId、第一宿主应用程序对应的hostinfo和第一宿主应用程序对应的size。

在卡片管理服务根据卡片UUID，获取打车应用程序的业务对应的AppClipInfo后，卡片管理服务可以根据打车应用程序的业务对应的AppClipInfo，确定打车应用程序对应的卡片kit，并向打车应用程序对应的卡片kit发送打车应用程序的业务对应的AppClipInfo、cardInstanceId、第一宿主应用程序对应的hostinfo和第一宿主应用程序对应的size。

需要说明的是，由于注册打车应用程序的业务变更的宿主应用程序(如桌面、负一屏、通知中心、横幅通知、息屏和锁屏等)中各宿主应用程序均可以向卡片管理服务发送卡片UUID、cardInstanceId、该宿主应用程序对应的hostinfo和该宿主应用程序对应的size，因此，在卡片管理服务接收任一宿主应用程序发送的卡片管理服务发送卡片UUID、cardInstanceId、该宿主应用程序对应的hostinfo和该宿主应用程序对应的size后，卡片管理服务可以根据卡片UUID获取AppClipInfo，在卡片管理服务根据卡片UUID获取AppClipInfo后，卡片管理服务根据该AppClipInfo，确定并向打车应用程序对应的卡片kit发送该AppClipInfo、cardInstanceId、该宿主应用程序对应的hostinfo和该宿主应用程序对应的size。

本申请实施例中，在打车应用程序对应的卡片kit接收到卡片管理服务发送的打车应用程序的业务对应的AppClipInfo、cardInstanceId、第一宿主应用程序对应的hostinfo和第一宿主应用程序对应的size后，打车应用程序对应的卡片kit可以根据该AppClipInfo，确定打车应用程序的业务对应的Taxi Provider，进而打车应用程序对应的卡片kit可以从打车应用程序的业务对应的Taxi Provider获取打车应用程序卡对应的卡片视图。在打车应用程序对应的卡片kit获取打车应用程序卡对应的卡片视图后，打车应用程序对应的卡片kit可以根据打车应用程序卡对应的卡片视图，生成打车应用程序卡片对应的嵌入式窗口图层。在打车应用程序对应的卡片kit生成打车应用程序卡片对应的嵌入式窗口图层后，打车应用程序对应的卡片kit可以向第一宿主应用程序发送打车应用程序卡片对应的嵌入式窗口图层，以使第一宿主应用程序显示打车应用程序卡片对应的嵌入式窗口图层，即第一宿主应用程序显示打车应用程序卡片。

在一些示例中，为了避免在打车应用程序对应的卡片kit从TaxiProvider获取打车应用程序卡片对应的卡片视图，并根据卡片视图生成打车应用程序卡片对应的嵌入式窗口图层的过程中，电子设备的第一宿主应用程序显示其他应用程序的卡片，在打车应用程序对应的卡片kit从TaxiProvider获取打车应用程序卡片对应的卡片视图之前，打车应用程序对应的卡片kit可以生成用于占位的未添加打车应用程序卡片对应的卡片视图的嵌入式窗口图层(即占位嵌入式窗口图层)，并向第一宿主应用程序对应的Host AAR发送占位嵌入式窗口图层，以使第一宿主应用程序对应的Host AAR在占位嵌入式窗口图层中添加占位视图，进而第一宿主应用程序对应的Host AAR可以向第一宿主应用程序发送添加占位视图的占位嵌入式窗口图层，这样使得第一宿主应用程序可以将添加占位视图的占位嵌入式窗口图层挂载至第一宿主应用程序自身的宿主图层进行占位。

具体地，打车应用程序对应的卡片kit生成占位嵌入式窗口图层的具体实现过程参见S1609-S1615。

在一些示例中，在电子设备的缓存中存在已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包的情况下，在打车应用程序对应的卡片kit创建占位嵌入式窗口图层时，打车应用程序对应的卡片kit可以获取已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包(即SurfacePackage)的状态信息。在状态信息指示已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包有效的情况下，打车应用程序对应的卡片kit可以将已创建的打车应用程序卡片对应的嵌入式窗口图层，作为占位嵌入式窗口图层(即用于占位的未添加打车应用程序卡片对应的卡片视图的嵌入式窗口图层)。

具体地，打车应用程序对应的卡片kit可以将已创建的打车应用程序卡片对应的嵌入式窗口图层，作为占位嵌入式窗口图层的具体实现过程参见S1609-S1611。

在状态信息指示已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包无效的情况下，打车应用程序对应的卡片kit可以创建占位嵌入式窗口图层(即用于占位的未添加打车应用程序卡片对应的卡片视图的嵌入式窗口图层)。

在一些示例中，在电子设备的缓存中不存在已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包的情况下，打车应用程序对应的卡片kit可以创建占位嵌入式窗口图层。

具体地，打车应用程序对应的卡片kit创建占位嵌入式窗口图层的具体实现过程参见S1612-S1615。

下面对打车应用程序对应的卡片kit生成占位嵌入式窗口图层的具体实现过程进行示意说明。

S1609、打车应用程序对应的卡片kit获取已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包。

打车应用程序对应的卡片kit可以从电子设备的缓存中获取已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包，并确定已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包的状态信息。

S1610、在状态信息指示已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包有效的情况下，打车应用程序对应的卡片kit回调OnSurfacePackageChanged函数。

在状态信息指示已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包有效的情况下，打车应用程序对应的卡片kit可以通过回调OnSurfacePackageChanged函数，将已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包返回给卡片管理服务。

示例性地，在已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包(即SurfacePackage)的状态信息的返回值为第一值(如1)的情况下，打车应用程序对应的卡片kit确定已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包(即SurfacePackage)有效。

S1611、卡片管理服务回调OnSurfacePackageChanged函数。

卡片管理服务可以通过回调OnSurfacePackageChanged函数，将已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包返回给电子设备的第一宿主应用程序对应的Host AAR。第一宿主应用程序对应的Host AAR在接收到已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包后，可以根据已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包，得到已创建的打车应用程序卡片对应的嵌入式窗口图层，并将已创建的打车应用程序卡片对应的嵌入式窗口图层，作为占位嵌入式窗口图层。在得到占位嵌入式窗口图层之后，第一宿主应用程序对应的Host AAR可以在占位嵌入式窗口图层中添加占位视图。即在S1611之后，执行S1616。

在一些示例中，在状态信息指示已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包无效的情况下，打车应用程序对应的卡片kit可以创建占位嵌入式窗口图层，并将占位嵌入式窗口图层的数据包返回给第一宿主应用程序对应的Host AAR，以使第一宿主应用程序对应的Host AAR在占位嵌入式窗口图层中添加占位视图。即在状态信息指示已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包无效的情况下，执行S1612-S1615。

示例性地，在已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包的状态信息的返回值为第二值(如0)的情况下，打车应用程序对应的卡片kit确定已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包无效。

S1612、打车应用程序对应的卡片kit创建占位嵌入式窗口图层。

S1613、打车应用程序对应的卡片kit创建监听事件，监听事件用于监听占位嵌入式窗口图层是否创建完成。

S1614、在占位嵌入式窗口图层创建完成的情况下，打车应用程序对应的卡片kit回调OnSurfacePackageCreated函数。

在占位嵌入式窗口图层创建完成的情况下，打车应用程序对应的卡片kit可以通过回调OnSurfacePackageCreated函数，将占位嵌入式窗口图层的数据包返回给卡片管理服务。

S1615、卡片管理服务回调OnSurfacePackageCreated函数。

卡片管理服务可以通过回调OnSurfacePackageCreated函数，将占位嵌入式窗口图层的数据包返回给第一宿主应用程序对应的Host AAR，以使第一宿主应用程序对应的Host AAR在占位嵌入式窗口图层中添加占位视图。

在第一宿主应用程序对应的Host AAR接收到卡片管理服务发送的占位嵌入式窗口图层之后，第一宿主应用程序对应的Host AAR可以创建占位视图，并将占位视图添加至占位嵌入式窗口图层，进而第一宿主应用程序对应的Host AAR可以向第一宿主应用程序发送添加占位视图的占位嵌入式窗口图层，这样使得第一宿主应用程序可以将添加占位视图的占位嵌入式窗口图层挂载至第一宿主应用程序自身的宿主图层进行占位。具体地，第一宿主应用程序对应的Host AAR创建占位视图，并将占位视图添加至占位嵌入式窗口图层的具体实现过程参见S1616-S1618。

S1616、第一宿主应用程序对应的Host AAR根据第一宿主应用程序对应的卡片尺寸信息(即size)，创建占位视图。

第一宿主应用程序对应的Host AAR可以根据第一宿主应用程序的卡片尺寸信息，创建占位视图。示例性地，占位视图可以是可复用的DynamicCardHostView对象。

S1617、第一宿主应用程序对应的Host AAR将占位视图添加至占位嵌入式窗口图层。

在第一宿主应用程序对应的Host AAR接收到卡片管理服务发送的占位嵌入式窗口图层的数据包后，第一宿主应用程序对应的Host AAR可以根据占位嵌入式窗口图层的数据包，得到占位嵌入式窗口图层。在第一宿主应用程序对应的Host AAR创建占位视图之后，第一宿主应用程序回调onCardViewCreated{cardInstanceId,view}函数，以将占位视图(即DynamicCardHostView对象)添加至占位嵌入式窗口图层。

在一些示例中，在第一宿主应用程序对应的Host AAR接收到已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包之后，第一宿主应用程序对应的Host AAR根据已创建的打车应用程序卡片对应的嵌入式窗口图层的数据包，得到已创建的打车应用程序卡片对应的嵌入式窗口图层。在第一宿主应用程序对应的Host AAR创建占位视图之后，第一宿主应用程序对应的Host AAR可以调用onCardViewCreated{cardInstanceId,view}函数，以将已创建的打车应用程序卡片对应的嵌入式窗口图层中的卡片视图更新为占位视图。之后，第一宿主应用程序对应的Host AAR将添加占位视图的嵌入式窗口图层发送给第一宿主应用程序，以使第一宿主应用程序将添加占位视图的占位嵌入式窗口图层挂载至第一宿主应用程序对应的宿主图层。

在一些示例中，在第一宿主应用程序对应的Host AAR接收到占位嵌入式窗口图层的数据包之后，第一宿主应用程序对应的Host AAR根据占位嵌入式窗口图层的数据包，得到占位嵌入式窗口图层。在第一宿主应用程序对应的Host AAR创建占位视图之后，第一宿主应用程序对应的Host AAR可以调用onCardViewCreated{cardInstanceId,view}函数，以在占位嵌入式窗口图层中添加占位视图。之后，第一宿主应用程序对应的Host AAR可以将添加占位视图的占位嵌入式窗口图层发送给第一宿主应用程序，以使第一宿主应用程序将添加占位视图的占位嵌入式窗口图层挂载至第一宿主应用程序对应的宿主图层。

S1618、第一宿主应用程序对应的Host AAR向第一宿主应用程序发送添加占位视图的占位嵌入式窗口图层，以使第一宿主应用程序将添加占位视图的占位嵌入式窗口图层挂载至第一宿主应用程序对应的宿主图层。

在第一宿主应用程序接收到第一宿主应用程序对应的Host AAR发送的添加占位视图的占位嵌入式窗口图层之后，第一宿主应用程序将添加占位视图的占位嵌入式窗口图层挂载至第一宿主应用程序对应的宿主图层，即第一宿主应用程序将占位视图嵌入第一宿主应用程序的视窗中。

需要说明的是，由于在卡片管理服务接收任一宿主应用程序发送的卡片管理服务发送卡片UUID、卡片实例信息、该宿主应用程序对应的标识信息和该宿主应用程序对应的卡片尺寸信息后，卡片管理服务可以根据卡片UUID获取AppClipInfo，在卡片管理服务根据卡片UUID获取AppClipInfo后，卡片管理服务根据该AppClipInfo，确定并向打车应用程序对应的卡片kit发送该AppClipInfo、卡片实例信息、该宿主应用程序对应的标识信息和该宿主应用程序对应的卡片尺寸信息，也就是说，打车应用程序对应的卡片kit可以从TaxiProvider获取注册打车应用程序的业务变更的宿主应用程序中各宿主应用程序对应的打车应用程序卡片对应的卡片视图(即view)。因此，在打车应用程序对应的卡片kit可以从TaxiProvider获取注册打车应用程序的业务变更的宿主应用程序中各宿主应用程序对应的打车应用程序卡片对应的卡片视图(即view)之前，各宿主应用程序均可以将添加占位视图的占位嵌入式窗口图层挂载至第一宿主应用程序自身的宿主图层进行占位。其中，各宿主应用程序将添加占位视图的占位嵌入式窗口图层挂载至第一宿主应用程序自身的宿主图层进行占位的具体实现过程，可以是以S1609-S1618(即第一宿主应用程序添加占位视图的占位嵌入式窗口图层挂载至第一宿主应用程序自身的宿主图层进行占位)为例进行示意说明的。

S1619、打车应用程序对应的卡片kit根据该AppClipInfo，确定打车应用程序的业务对应的Taxi Provider，并向打车应用程序的业务对应的Taxi Provider发送cardInstanceId。

在打车应用程序对应的卡片kit接收到打车应用程序的业务对应的AppClipInfo、cardInstanceId、第一宿主应用程序对应的hostinfo后，打车应用程序对应的卡片kit可以根据该AppClipInfo，确定打车应用程序的业务对应的Taxi Provider，并向打车应用程序的业务对应的Taxi Provider发送绑定服务请求。

在打车应用程序的业务对应的Taxi Provider接收到打车应用程序对应的卡片kit发送的绑定服务请求后，打车应用程序的业务对应的Taxi Provider进行初始化操作。在打车应用程序的业务对应的Taxi Provider进行初始化操作后，打车应用程序的业务对应的Taxi Provider可以与打车应用程序对应的卡片kit绑定服务，即打车应用程序的业务对应的Taxi Provider与打车应用程序对应的卡片kit建立通信连接。在打车应用程序的业务对应的Taxi Provider与打车应用程序对应的卡片kit绑定服务后，打车应用程序的业务对应的Taxi Provider可以向打车应用程序对应的卡片kit发送绑定服务创建成功的通知。

在打车应用程序对应的卡片kit接收到打车应用程序的业务对应的TaxiProvider发送的绑定服务创建成功的通知后，打车应用程序对应的卡片kit可以向打车应用程序的业务对应的Taxi Provider发送打车应用程序的业务对应的cardInstanceId，以使打车应用程序的业务对应的Taxi Provider根据cardInstanceId，确定所要显示的打车应用程序卡片对应的打车订单，并根据第一宿主应用程序对应的hostinfo，获取打车订单对应的打车应用程序卡片的卡片视图，即打车应用程序的业务对应的Taxi Provider根据第一宿主应用程序对应的hostinfo，获取第一宿主应用程序对应的打车应用程序卡片的卡片视图。

其中，打车应用程序可以包括多个Taxi Provider，一个打车应用程序的业务(即打车订单的处理进度)对应一个Taxi Provider，Taxi Provider可以用于生成与打车应用程序的业务(如司机接单)对应的卡片视图。需要说明的是，打车应用程序的业务对应的Taxi Provider可以集成在打车应用程序中。

需要说明的是，在打车应用程序对应的卡片kit将已创建的打车应用程序卡片对应的嵌入式窗口图层，作为占位嵌入式窗口图层的情况下，S1619可以在S1609之前执行，S1619也可以与S1609同时执行，这里对S1619和S1609的执行顺序不做具体限定。

以及，在打车应用程序对应的卡片kit创建占位嵌入式窗口图层的情况下，S1619可以在S1612之前执行，S1619也可以与S1612同时执行，这里对S1619和S1612的执行顺序不做具体限定。

S1620、打车应用程序的业务对应的Taxi Provider根据打车应用程序的业务对应的cardInstanceId，确定所要显示的打车应用程序卡片对应的打车订单。

例如，在用户使用打车应用程序下单两个打车订单(如订单A和订单B)时，可以生成与订单A对应的卡片实例信息1，以及生成与订单B对应的卡片实例信息2。打车应用程序的业务(即打车订单的处理进度)对应的Taxi Provider可以根据卡片实例信息1，确定所要显示的打车应用程序卡片为订单A对应的打车应用程序卡片。打车应用程序的业务(即打车订单的处理进度)对应的Taxi Provider可以根据卡片实例信息2，确定所要显示的打车应用程序卡片为订单B对应的打车应用程序卡片。

S1621、打车应用程序对应的卡片kit调用getview(hostinfo)函数，以向打车应用程序的业务对应的Taxi Provider发送第一宿主应用程序对应的hostinfo。

在打车应用程序的业务对应的Taxi Provider根据打车应用程序的业务对应的cardInstanceId，确定所要显示的打车应用程序卡片对应的打车订单之后，打车应用程序对应的卡片kit可以向打车应用程序的业务对应的Taxi Provider发送第一宿主应用程序对应的hostinfo，即打车应用程序对应的卡片kit可以向打车应用程序的业务对应的TaxiProvider发送第一宿主应用程序对应的view id。

需要说明的是，在卡片管理服务接收任一宿主应用程序发送的卡片管理服务发送卡片UUID、卡片实例信息、该宿主应用程序对应的标识信息和该宿主应用程序对应的卡片尺寸信息后，卡片管理服务可以根据卡片UUID获取AppClipInfo，并向打车应用程序对应的卡片kit发送该AppClipInfo、卡片实例信息、该宿主应用程序对应的标识信息和该宿主应用程序对应的卡片尺寸信息，因此，在打车应用程序对应的卡片kit接收到AppClipInfo、卡片实例信息、该宿主应用程序对应的标识信息后，打车应用程序对应的卡片kit可以根据AppClipInfo确定打车应用程序的业务对应的Taxi Provider，并向打车应用程序的业务对应的Taxi Provider发送卡片实例信息、该宿主应用程序对应的标识信息。

S1622、打车应用程序的业务对应的Taxi Provider根据第一宿主应用程序对应的hostinfo，创建第一宿主应用程序对应的打车应用程序卡片的卡片视图。

在打车应用程序的业务对应的Taxi Provider接收打车应用程序对应的卡片kit发送的第一宿主应用程序对应的hostinfo之后，打车应用程序的业务对应的TaxiProvider可以根据第一宿主应用程序对应的hostinfo，确定第一宿主应用程序对应的viewid，并根据第一宿主应用程序对应的view id，获取第一宿主应用程序对应的打车应用程序卡片的卡片视图。该打车应用程序卡片的卡片视图是与目标打车订单对应的与打车应用程序卡片的卡片视图。该打车应用程序卡片的卡片视图可以用于指示打车应用程序的业务发生的变化，即用于指示目标订单的处理进度。其中，目标打车订单是根据打车应用程序的业务对应的cardInstanceId确定的打车订单。

例如，继续以电子设备的宿主应用程序包括桌面、通知中心、锁屏、息屏、负一屏、横幅通知为例，针对打车应用程序的同一业务(如司机接单)，在第一宿主应用程序为桌面时，第一宿主应用程序对应的卡片视图标识为1，打车应用程序的业务对应的TaxiProvider可以根据卡片视图标识1，获取桌面对应的打车应用程序卡片的卡片视图。在第一宿主应用程序为通知中心时，第一宿主应用程序对应的卡片视图标识为2，打车应用程序的业务对应的Taxi Provider可以根据卡片视图标识2，获取通知中心对应的打车应用程序卡片的卡片视图。在第一宿主应用程序为锁屏时，第一宿主应用程序对应的卡片视图标识为3，打车应用程序的业务对应的Taxi Provider可以根据卡片视图标识3，获取锁屏对应的打车应用程序卡片的卡片视图。在第一宿主应用程序为息屏时，第一宿主应用程序对应的卡片视图标识为4，打车应用程序的业务对应的Taxi Provider可以根据卡片视图标识4，获取息屏对应的打车应用程序卡片的卡片视图。在第一宿主应用程序为负一屏时，第一宿主应用程序对应的卡片视图标识为5，打车应用程序的业务对应的Taxi Provider可以根据卡片视图标识5，获取负一屏对应的打车应用程序卡片的卡片视图。在第一宿主应用程序为横幅通知时，第一宿主应用程序对应的卡片视图标识为6，打车应用程序的业务对应的TaxiProvider可以根据卡片视图标识6，获取横幅通知对应的打车应用程序卡片的卡片视图。

需要说明的是，由于打车应用程序对应的卡片kit可以向打车应用程序的业务对应的Taxi Provider发送注册打车应用程序的业务变更的宿主应用程序中各宿主应用程序对应的宿主应用程序的hostinfo，因此，打车应用程序对应的卡片kit可以根据注册打车应用程序的业务变更的宿主应用程序中每个宿主应用程序对应的hostinfo，确定每个宿主应用程序对应的view id，并根据每个宿主应用程序对应的view id，获取每个宿主应用程序对应的卡片视图。

其中，对于不同的宿主应用程序，宿主应用程序对应的界面所要显示的内容不同，因此，针对打车应用程序的同一业务，在不同的宿主应用程序显示打车应用程序卡片时，不同宿主应用程序显示的打车应用程序卡片的卡片视图不同。

示例性地，不同宿主应用程序显示的打车应用程序卡片的卡片视图不同，可以是指不同宿主应用程序显示的打车应用程序卡片的卡片视图的卡片内容不同。

例如，以电子设备的宿主应用程序可以包括桌面、通知中心、锁屏、息屏、负一屏、横幅通知为例，针对打车应用程序的同一业务(如司机接单)，如图15中的(a)所示，电子设备的桌面110可以显示打车应用程序卡片111。打车应用程序卡片111可以包括打车应用程序的图标112、“车牌号XXX·约2分钟到达”的文本113、“张师傅·白色”的文本114、呼叫控件115。

如图15中的(b)所示，电子设备的通知中心120可以显示打车应用程序卡片121。打车应用程序卡片121可以包括打车应用程序的图标122、“车牌号XXX·约2分钟到达”的文本123、“张师傅·白色”的文本124。与图15中的(a)所示的打车应用程序卡片111相比，打车应用程序卡片121还可以包括进度条125。

如图15中的(c)所示，电子设备的锁屏界面130可以显示打车应用程序卡片131。打车应用程序卡片131可以包括打车应用程序的图标132、“车牌号XXX·约2分钟到达”的文本133、“张师傅·白色”的文本134。与图15中的(a)所示的打车应用程序卡片111相比，打车应用程序卡片131还可以包括进度条135。

如图15中的(d)所示，电子设备的息屏界面140可以显示打车应用程序卡片141。与图15中的(a)所示的打车应用程序卡片111相比，打车应用程序卡片141为卡片胶囊。打车应用程序卡片141(即卡片胶囊)可以包括部分打车订单的相关信息(如打车应用程序的图标142、“车牌号XXX”的文本143)。

需要说明的是，上述进度条可以是分段进度条。

示例性地，不同宿主应用程序显示的打车应用程序卡片的卡片视图不同，可以是指不同宿主应用程序显示的打车应用程序卡片的卡片视图的卡片尺寸不同。

例如，继续以电子设备的宿主应用程序可以包括桌面、通知中心、锁屏、息屏、负一屏、横幅通知为例，针对打车应用程序的同一业务(如司机接单)，如图15中的(a)所示，电子设备的桌面110可以显示打车应用程序卡片111。该打车应用程序卡片111的显示高度为h1，打车应用程序卡片111的显示宽度为d1。

如图15中的(b)所示，电子设备的通知中心120可以显示打车应用程序卡片121。该打车应用程序卡片121的显示高度为h2，打车应用程序卡片121的显示宽度为d2。打车应用程序卡片121的显示高度h2小于打车应用程序卡片111的显示高度h1。

如图15中的(c)所示，电子设备的锁屏界面130可以显示打车应用程序卡片131。该打车应用程序卡片131的显示高度为h3，打车应用程序卡片131的显示宽度为d3。打车应用程序卡片131的显示高度h3小于打车应用程序卡片121的显示高度h2。

如图15中的(d)所示，电子设备的息屏界面140可以显示打车应用程序卡片141。该打车应用程序卡片141的显示高度为h4，打车应用程序卡片141的显示宽度为d4。打车应用程序卡片141的显示高度h4小于打车应用程序卡片111的显示高度h2，且打车应用程序卡片141的显示宽度d4小于打车应用程序卡片111的显示宽度d1。

也就是说，针对打车应用程序的同一业务(如司机接单)，在电子设备的桌面、通知中心、锁屏界面、息屏界面显示的打车应用程序卡片不同，即不同宿主应用程序显示的打车应用程序卡片的卡片视图(即view)不同，也即不同宿主应用程序对应的打车应用程序卡片的卡片视图的卡片视图标识不同。

在本申请实施例中，在根据第一宿主应用程序对应的卡片视图标识，获取第一宿主应用程序对应的打车应用程序卡片的卡片视图之前，打车应用程序的业务对应的TaxiProvider可以根据第一宿主应用程序对应的卡片尺寸信息和打车业务数据，生成第一宿主应用程序对应的打车应用程序卡片的卡片视图。

S1623、打车应用程序的业务对应的Taxi Provider向打车应用程序对应的卡片kit发送第一宿主应用程序对应的打车应用程序卡片的卡片视图。

需要说明的是，由于打车应用程序的业务对应的Taxi Provider可以根据注册打车应用程序的业务变更的宿主应用程序中每个宿主应用程序对应的hostinfo，确定每个宿主应用程序对应的view id，并根据每个宿主应用程序对应的view id，获取每个宿主应用程序对应的卡片视图，因此，打车应用程序的业务对应的Taxi Provider可以向打车应用程序对应的卡片kit发送注册打车应用程序的业务变更的宿主应用程序中各宿主应用程序对应的卡片视图。

S1624、打车应用程序对应的卡片kit将第一宿主应用程序对应的打车应用程序卡片的卡片视图添加到嵌入式窗口图层中。

打车应用程序对应的卡片kit接收第一宿主应用程序对应的打车应用程序卡片的卡片视图后，打车应用程序对应的卡片kit可以将第一宿主应用程序对应的打车应用程序卡片的卡片视图添加到嵌入式窗口(即SurfaceControlViewHost或者ViewHost)图层中。即打车应用程序对应的卡片kit根据第一宿主应用程序对应的打车应用程序卡片的卡片视图，生成打车应用程序卡片对应的嵌入式窗口图层。

其中，在一些示例中，嵌入式窗口图层可以是上述上述S1609中获取的已创建的打车应用程序卡片对应的嵌入式窗口图层，即，打车应用程序对应的卡片kit可以将第一宿主应用程序对应的打车应用程序卡片的卡片视图添加到嵌入式窗口图层中，可以是打车应用程序对应的卡片kit可以将已创建的打车应用程序卡片对应的嵌入式窗口图层中的卡片视图更新为第一宿主应用程序对应的打车应用程序卡片的卡片视图。

在一些示例中，嵌入式窗口图层可以是S1612中打车应用程序对应的卡片kit创建的占位嵌入式窗口图层，即，打车应用程序对应的卡片kit可以将第一宿主应用程序对应的打车应用程序卡片的卡片视图添加到嵌入式窗口图层中，可以是打车应用程序对应的卡片kit可以将第一宿主应用程序对应的打车应用程序卡片的卡片视图添加到占位嵌入式窗口图层中。

需要说明的是，由于打车应用程序的业务对应的Taxi Provider可以向打车应用程序对应的卡片kit发送注册打车应用程序的业务变更的宿主应用程序中各宿主应用程序对应的卡片视图，因此，打车应用程序对应的卡片kit可以将各宿主应用程序对应的打车应用程序卡片的卡片视图添加到嵌入式窗口图层中，即打车应用程序对应的卡片kit可以根据各宿主应用程序对应的打车应用程序卡片的卡片视图，生成各宿主应用程序对应的打车应用程序卡片对应的嵌入式窗口图层。

S1625、打车应用程序对应的卡片kit回调onSurfaceViewRendered函数。

在打车应用程序对应的卡片kit监听打车应用程序卡片对应的嵌入式窗口图层是否渲染完成，即打车应用程序对应的卡片kit监听占位嵌入式窗口图层中的卡片视图是否更新为第一宿主应用程序对应的打车应用程序卡片的卡片视图。在打车应用程序对应的卡片kit监听到打车应用程序卡片对应的嵌入式窗口图层渲染完成后，打车应用程序对应的卡片kit可以回调onSurfaceViewRendered函数，以向卡片管理服务通知打车应用程序卡片对应的嵌入式窗口图层渲染完成。

S1626、卡片管理服务回调onSurfaceViewRendered函数。

电子设备的卡片管理服务回调onSurfaceViewRendered函数，以向第一宿主应用程序对应的Host AAR通知打车应用程序卡片对应的嵌入式窗口图层渲染完成。

S1627、第一宿主应用程序对应的Host AAR回调onSurfaceViewRendered函数。

第一宿主应用程序对应的Host AAR回调onSurfaceViewRendered函数，以向第一宿主应用程序通知打车应用程序卡片对应的嵌入式窗口图层渲染完成。

S1628、第一宿主应用程序将占位嵌入式窗口图层中添加的占位视图更新为第一宿主应用程序对应的打车应用程序卡片的卡片视图。

在第一宿主应用程序对应的Host AAR回调onSurfaceViewRendered函数后，第一宿主应用程序将占位嵌入式窗口图层中添加的占位视图更新为第一宿主应用程序对应的打车应用程序卡片的卡片视图，即第一宿主应用程序去掉第一宿主应用程序对应的宿主图层中挂载(或称为嵌入)的嵌入式窗口图层中的占位视图对应的占位符，并在第一宿主应用程序对应的宿主图层中挂载的嵌入式窗口图层中添加第一宿主应用程序对应的打车应用程序卡片的卡片视图，也即第一宿主应用程序将挂载至第一宿主应用程序对应的宿主图层的嵌入式窗口图层中的占位视图更新为第一宿主应用程序对应的打车应用程序卡片的卡片视图。

需要说明的是，由于打车应用程序对应的卡片kit根据各宿主应用程序对应的打车应用程序卡片的卡片视图，生成各宿主应用程序对应的打车应用程序卡片对应的嵌入式窗口图层，因此，各宿主应用程序可以将挂载至该宿主应用程序对应的宿主图层的嵌入式窗口图层中的占位视图更新为该宿主应用程序对应的打车应用程序卡片的卡片视图。其中，各宿主应用程序可以将挂载至该宿主应用程序对应的宿主图层的嵌入式窗口图层中的占位视图更新为该宿主应用程序对应的打车应用程序卡片的卡片视图的具体实现过程，可以是以S1628(即第一宿主应用程序将占位嵌入式窗口图层中添加的占位视图更新为第一宿主应用程序对应的打车应用程序卡片的卡片视图的具体实现过程)为例进行示意说明。

S1629、第一宿主应用程序接收用户输入的切换操作。

切换操作可以用于打开电子设备的第一宿主应用程序。例如，第一宿主应用程序为桌面，则切换操作可以为用户在电子设备的显示屏的底部的上滑操作。又如，第一宿主应用程序为通知中心，则切换操作可以为用户在显示屏的顶部状态栏的下拉操作。还如，第一宿主应用程序为锁屏，则切换操作可以为在电子设备处于锁屏状态时，用户对电子设备的显示屏的点击操作。

S1630、响应于切换操作，第一宿主应用程序显示第一宿主应用程序对应的界面，该第一宿主应用程序对应的界面包括第一宿主应用程序对应的打车应用程序卡片。

由于第一宿主应用程序将挂载至第一宿主应用程序对应的宿主图层的嵌入式窗口图层中包括第一宿主应用程序对应的打车应用程序卡片的卡片视图，因此，响应于切换操作，第一宿主应用程序显示第一宿主应用程序对应的界面，且在第一宿主应用程序对应的界面中显示第一宿主应用程序对应的打车应用程序卡片的卡片视图，即第一宿主应用程序对应的界面包括第一宿主应用程序对应的打车应用程序卡片。

例如，以第一宿主应用程为桌面为例，响应于切换操作，在电子设备的桌面110的顶部可以显示打车应用程序卡片111。打车应用程序卡片111可以用于提示司机已接单。结合图15中的(a)所示，打车应用程序卡片111可以包括打车应用程序的图标112、“车牌号XXX·约2分钟到达”的文本113、“张师傅·白色”的文本114。打车应用程序卡片111还可以包括呼叫控件115，呼叫控件115可以用于联系接单司机。其中，打车应用程序卡片111的显示高度为h1，打车应用程序卡片111的显示宽度为d1。

又如，以第一宿主应用程序为通知中心为例，在电子设备接收到用户的锁屏操作(如按压锁屏键)时，如图15中的(d)所示，电子设备显示息屏界面140，并在息屏界面140显示打车应用程序卡片141。打车应用程序卡片141为卡片胶囊，在电子设备接收到用户对打车应用程序卡片141(即卡片胶囊)的触控操作(如滑动操作)，电子设备打开打车应用程序。以及，打车应用程序卡片141的显示高度h4小于打车应用程序卡片111的显示高度h1，打车应用程序卡片141的显示宽度d3小于打车应用程序卡片111的显示宽度d1。

需要说明的是，由于在电子设备开机后，宿主应用程序(桌面、负一屏、通知中心、横幅通知、息屏和锁屏等)对打车应用程序的业务变更进行注册，因此，当打车应用程序的发生业务变更时，电子设备可以生成所有注册打车应用程序的业务变更的宿主应用程序中各宿主应用程序对应的打车应用程序卡片的卡片视图，并当某一宿主应用程序在电子设备的前台运行时，显示该宿主应用程序对应的打车应用程序卡片的卡片视图，即显示该宿主应用程序对应的打车应用程序卡片。上述示例是以第一宿主应用程序(如桌面)为例进行示意说明的是，也就是说，所有注册打车应用程序的业务变更的宿主应用程序中各宿主应用程序均可以执行上述S1604-S1628。

本申请的方案，在电子设备通过卡片的形式显示应用程序的通知信息时，电子设备运行的应用程序可以创建卡片视图，并根据卡片视图生成卡片对应的嵌入式窗口图层，以及将卡片对应的嵌入式窗口图层发送给电子设备的宿主应用程序，以使电子设备的宿主应用程序显示卡片对应的嵌入式窗口图层。也就是说，在电子设备的宿主应用程序通过卡片的形式显示应用程序的通知信息时，电子设备的宿主应用程序显示的是其自身下挂的嵌入式窗口图层，而不是直接显示卡片视图。因此，电子设备的应用程序可以根据需求创建包括自定义卡片元素的卡片视图，并根据卡片视图生成包括自定义卡片元素的嵌入式窗口图层，从而在电子设备的宿主应用程序显示应用程序的通知信息时，电子设备的宿主应用程序可以显示包括不同自定义卡片元素的卡片视图，这样能够更有效、更直观地向用户展示应用程序的通知信息。

再者，在电子设备显示应用程序对应的卡片时，基于嵌入式窗口图层显示应用程序对应的卡片，可以提高跨进程数据传输速度，能够实现应用程序对应的卡片的实时刷新，进而保证应用程序的通知信息的时效性，用户体验更好。

为了便于理解，下面结合附图17对本申请实施例提供的卡片显示方法进行说明。如图17所示，该卡片显示方法可以包括以下S1701-S1703。

S1701、响应于电子设备中的第一应用程序的业务发生变化，电子设备确定第一应用程序的第一卡片的第一视图。

本申请实施例中电子设备可以包括多个应用程序，如第一应用程序。在一些示例中，第一应用程序可以为出行应用程序(如打车应用程序、地图应用程序等)或者配送应用程序(如外卖应用程序、快递应用程序等)等，本申请实施例中对第一应用程序的具体类型并不进行限定。示例性地，上述第一应用程序可以是上述图6示出的提供卡片的应用程序。

电子设备还可以包括第二应用程序。第二应用程序可以是对电子设备包括的第一应用程序的业务变更进行注册的应用程序。也就是说，在第一应用程序的业务发生变化时，第二应用程序可以显示第一应用程序的第一卡片。在一些示例中，第二应用程序可以为桌面、通知中心、锁屏、息屏、负一屏或者横幅通知。示例性地，上述第二应用程序可以是上述S601-S609中的宿主应用程序。示例性地，上述第二应用程序也可以是上述S1604-S1608，或者上述S1616-S1618，或者上述S1621-S1630中的第一宿主应用程序。

上述第一卡片可以是第一应用程序对应的卡片，即第一卡片可以用于表示第一应用程序的业务变化。例如，以第一应用程序为打车应用程序为例，第一卡片可以是上述S606-S609，或者上述S1623-S1624中打车应用程序卡片。

在本申请实施例中，在电子设备的不同应用程序(如桌面、通知中心、锁屏、息屏、负一屏或者横幅通知)显示的第一卡片时，第一卡片的卡片视图可以根据电子设备的应用程序的显示内容进行调整。也就是说，针对第一应用程序的同一业务，电子设备的不同应用程序显示的第一卡片的卡片视图可以不同。基于此，响应于电子设备中的第一应用程序的业务发生变化，电子设备可以确定第一应用程序的第一卡片的多个卡片视图，其中，多个卡片视图分别对应电子设备包括的不同应用程序(如桌面、通知中心、锁屏、息屏、负一屏或者横幅通知)。

上述第一视图可以是第二应用程序可显示的第一卡片的卡片视图。上述第一视图可以是上述S604-S607，或者上述S1622-S1623中的卡片视图。

在一些示例中，第一视图中可以包括自定义卡片元素。自定义卡片元素可以是进度条或者分段进度条。

示例性地，第一视图包括进度条，进度条可以用于指示第一应用程序的业务的进度状态。该进度条可以包括第一图标、第二图标、和第三图标，其中，第一图标可以用于指示第一应用程序的业务的执行起点，第二图标可以用于指示第一应用程序的业务的执行终点；第三图标用于指示第一应用程序的业务的进度状态发生变化，且在第一应用程序的业务的进度状态发生变化时，第三图标在第一图标与第二图标之间的位置相应发生变化。这样一来，在电子设备在第一界面显示包括第一视图的第一卡片时，通过第一视图中的进度条可以更直观地展示第一应用程序的业务的进度状态，用户体验更好。

例如，以第一应用程序为打车应用程序为例，第一图标可以用于指示起始点(即司机接单时的接单车辆所在的位置)，即第一图标可以用于指示打车订单的执行起点。第二图标可以用于表示打车订单的目的地，即第二图标可以用于指示打车订单的执行终点。具体地，进度条可以是上述图7示出的进度条21。第一图标可以是上述图7示出的第一标识01。第二图标可以是上述图7示出的第二标识02。第三图标可以是上述图7示出的车辆标识04。

示例性地，第一应用程序的业务阶段包括第一业务阶段和第二业务阶段；第一视图包括分段进度条，分段进度条用于指示第一应用程序的业务在不同的业务阶段的进度状态。

该分段进度条可以包括第四图标、第五图标、位于第四图标与第五图标之间的第六图标和第七图标。其中，第四图标可以用于指示第一应用程序的第一业务阶段的执行起点。第五图标可以用于指示第一应用程序的第二业务阶段的执行终点。第六图标用于指示第一应用程序的第一业务阶段的执行终点，且第一应用程序的第二业务阶段的执行起点。

第七图标可以用于指示第二应用程序的业务进度发生变化，且当第二应用程序的业务在第一业务阶段发生进度变化时，第七图标在第四图标与第六图标之间的位置相应发生变化；或者，当第二应用程序的业务在第二业务阶段发生进度变化时，第七图标在第六图标与第五图标之间的位置相应发生变化。

这样一来，在电子设备在第一界面显示包括第一视图的第一卡片时，通过第一视图中的分段进度条可以更直观地展示第一应用程序的业务当前所处的业务阶段，以及该业务阶段对应的进度状态，用户体验更好。

例如，以第一应用程序为打车应用程序为例，第四图标可以用于指示起始点(即司机接单时的接单车辆所在的位置)，即第四图标可以用于指示打车订单的执行起点。第五图标可以用于表示打车订单的目的地，即第五图标可以用于指示打车订单的执行终点。第六图标可以用于指示下单的用户所在的出发地。第六图标位于第四图标和第五图标之间，第六图标可以将第四图标与第五图标之间的连接线划分为两段，即第六图标可以将打车订单的处理过程划分为两个阶段，即第一业务阶段和第二业务阶段。当第七图标位于第四图标和第六图标之间时，说明接单车辆正在由起始点驶向用户所在的出发地。当第七图标位于第六图标和第五图标之间时，说明接单车辆已接到用户，接单车辆正在由用户所在的出发地驶向目的地。

具体地，分段进度条可以是上述图10示出的分段进度条51。第四图标可以是上述图10示出的第一标识01。第五图标可以是上述图10示出的第二标识02。第六图标可以是上述图10示出的第三标识03。第七图标可以是上述图10示出的车辆标识04。

在一些示例中，电子设备确定第一应用程序的第一卡片的第一视图，可以包括：电子设备根据第二应用程序对应的卡片尺寸信息和第一应用程序的业务数据，确定第一应用程序的第一卡片的第一视图。

在一些示例中，电子设备确定第一应用程序的第一卡片的第一视图，可以包括：电子设备获取第二应用程序的标识信息；电子设备根据第二应用程序的标识信息，确定第一视图的标识信息；电子设备根据第一视图的标识信息，确定第一视图。

示例性地，上述第二应用程序的标识信息可以是上述S1622中的宿主应用程序的宿主标识(即host id)。上述第一视图的标识信息可以是上述S606，或者上述S1622中的卡片视图标识(即view id)。

在该示例中，电子设备可以预先创建各应用程序对应的第一卡片的卡片视图，这样一来，在电子设备确定第一视图时，电子设备可以根据第二应用程序的标识信息，确定第一视图的标识信息，并根据第一视图的标识信息，确定第一视图，能够快速获取卡片视图，提升电子设备的处理效率。

具体地，上述示例中电子设备确定第一应用程序的第一卡片的第一视图的具体实施方式，可以参考上述S606，或者上述S1622中的具体实施方式，本申请实施例中对此不再赘述。

在一些实施例中，为了避免在电子设备确定第一应用程序的第一卡片的卡片视图的过程中，电子设备显示除第一应用程序以外的其他应用程序的卡片，在电子设备确定第一应用程序的第一卡片的卡片视图之前，电子设备可以创建占位视图对应的占位嵌入式窗口图层，并将占位嵌入式窗口图层挂载至第二应用程序的嵌入式窗口进行占位。

在一些示例中，在电子设备确定第一应用程序的第一卡片的第一视图之前，该卡片显示方法还可以包括：电子设备根据第二应用程序的卡片尺寸信息，生成占位视图；电子设备根据占位视图，创建占位视图对应的占位嵌入式窗口图层；电子设备将占位嵌入式窗口图层挂载至第二应用程序的嵌入式窗口。

上述第二应用程序的卡片尺寸信息，可以是第二应用程序所允许显示的卡片的卡片视图的尺寸信息。示例性地，第二应用程序的卡片尺寸信息可以包括显示高度和显示宽度。

示例性地，上述占位视图可以是可复用的DynamicCardHostView对象。

具体地，上述示例中电子设备根据第二应用程序的卡片尺寸信息，生成占位视图的具体实施方式，可以参考上述S1616中的具体实施方式，本申请实施例中对此不再赘述。

在一些示例中，电子设备根据占位视图，创建占位视图对应的占位嵌入式窗口图层，可以包括：在电子设备中存储有第三嵌入式窗口图层的情况下，获取第三嵌入式窗口图层的状态信息；在状态信息指示第三嵌入式窗口图层有效的情况下，将第三嵌入式窗口图层中的第二卡片的卡片视图更新为占位视图，以得到占位嵌入式窗口图层。

其中，第三嵌入式窗口图层为根据第一应用程序的第二卡片的卡片视图创建的嵌入式窗口图层。第二卡片与第一卡片指示的第一应用程序的业务的进度状态不同。示例性地，继续以第一应用程序为打车应用程序为例，第三嵌入式窗口图层可以是上述S1609-S1611中的已创建的打车应用程序卡片对应的嵌入式窗口图层。

第三嵌入式窗口图层的状态信息可以用于指示第三嵌入式窗口图层是否有效，即第三嵌入式窗口图层的状态信息可以用于指示第三嵌入式窗口图层对应的数据包是否有效。示例性地，在第三嵌入式窗口图层的状态信息为第一值(如1)的情况下，第三嵌入式窗口图层对应的数据包有效，即第三嵌入式窗口图层有效。在第三嵌入式窗口图层的状态信息为第二值(如0)的情况下，第三嵌入式窗口图层对应的数据包无效，即第三嵌入式窗口图层无效。

具体地，上述示例中在电子设备中存储有第三嵌入式窗口图层的情况下，获取第三嵌入式窗口图层的状态信息；在状态信息指示第三嵌入式窗口图层有效的情况下，将第三嵌入式窗口图层中的第二卡片的卡片视图更新为占位视图，以得到占位嵌入式窗口图层的具体实施方式，可以参考上述S1609-S1611中的具体实施方式，本申请实施例中对此不再赘述。

在一些示例中，电子设备根据占位视图，创建占位视图对应的占位嵌入式窗口图层，可以包括：在电子设备中未存储第三嵌入式窗口图层或者第三嵌入式窗口图层的状态信息指示第三嵌入式窗口图层无效的情况下，电子设备根据占位视图，创建占位嵌入式窗口图层。

具体地，上述示例中电子设备根据占位视图，创建占位嵌入式窗口图层的的具体实施方式，可以参考上述S1612-S1615中的具体实施方式，本申请实施例中对此不再赘述。

S1702、电子设备根据第一视图，创建第二应用程序对应的第一嵌入式窗口图层。

在电子设备确定第一应用程序的第一卡片的第一视图之后，电子设备可以根据第一视图创建第二应用程序对应的第一嵌入式窗口图层。电子设备可以将第一嵌入式窗口图层嵌入第二应用程序的嵌入式窗口(即第二应用程序的宿主图层)，这样在电子设备显示第二应用程序对应的第一界面时，可以显示第二应用程序的嵌入式窗口，进而可以显示嵌入第二应用程序的嵌入式窗口的第一嵌入式窗口图层，即在第一界面内显示包括第一视图的第一卡片。

第一嵌入式窗口图层可以是能够嵌入第二应用程序的嵌入式窗口的图层。示例性地，第一嵌入式窗口图层可以是上述S607，或者上述S1624中的嵌入式窗口图层。

在一些示例中，电子设备根据第一视图，创建第二应用程序对应的第一嵌入式窗口图层，可以包括：将占位嵌入式窗口图层中的占位视图更新为第一视图，以得到第二应用程序对应的第一嵌入式窗口图层。这样不需要重新创建第一嵌入式窗口图层，可以提高电子设备的处理效率。

具体地，上述示例中电子设备根据第一视图，创建第二应用程序对应的第一嵌入式窗口图层的具体实施方式，可以参考上述S607，或者上述S1624中的具体实施方式，本申请实施例中对此不再赘述。

S1703、响应于切换至第二应用程序的第一操作，电子设备显示第一界面，第一界面中包括第二应用程序的嵌入式窗口，其中，在第二应用程序的嵌入式窗口内显示第一嵌入式窗口图层，以在第一界面内显示包括第一视图的第一卡片。

其中，上述第一操作可以是用于打开电子设备的第二应用程序的操作。例如，第二应用程序为桌面，则第一操作可以为用户在电子设备的显示屏的底部的上滑操作。又如，第二应用程序为通知中心，则第一操作可以为用户在显示屏的顶部状态栏的下拉操作。还如，第二应用程序为锁屏，则第一操作可以为在电子设备处于锁屏状态时，用户对电子设备的显示屏的点击操作。示例性地，第一操作可以是上述S1629中的切换操作。第一界面可以是第二应用程序对应的显示界面。

在电子设备根据第一视图，创建第二应用程序对应的第一嵌入式窗口图层之后，电子设备可以将第一嵌入式窗口图层嵌入第二应用程序的嵌入式窗口。之后，在电子设备接收到切换至第二应用程序的第一操作时，响应于第一操作，电子设备可以显示第二应用程序对应的第一界面，第一界面中可以包括第二应用程序的嵌入式窗口，这样电子设备在显示第二应用程序对应的第一界面的同时，可以在第一界面中显示包括第一视图的第一卡片。

具体地，上述示例中响应于切换至第二应用程序的第一操作，电子设备显示第一界面的具体实施方式，可以参考上述S1630中的具体实施方式，本申请实施例中对此不再赘述。

在一些示例中，该卡片显示方法还可以包括：响应于电子设备中的第一应用程序的业务发生变化，电子设备确定第一应用程序的第一卡片的第二视图，第二视图与第一视图不同；电子设备根据第二视图，创建第三应用程序对应的第二嵌入式窗口图层。

在本申请实施例中，电子设备还可以包括第三应用程序。第三应用程序也可以是对电子设备包括的第一应用程序的业务变更进行注册的应用程序。也就是说，在第一应用程序的业务发生变化时，第三应用程序也可以显示第一应用程序的第一卡片。在一些示例中，第三应用程序可以为桌面、通知中心、锁屏、息屏、负一屏或者横幅通知。示例性地，上述第二应用程序可以是上述S601-S609中的宿主应用程序。示例性地，上述第二应用程序也可以是上述S1604-S1608，或者上述S1616-S1618，或者上述S1621-S1630中的第一宿主应用程序。

需要说明的是，第三应用程序与第二应用程序可以不同。如第二应用程序为桌面，第三应用程序为通知中心。如第二应用程序为桌面，第三应用程序为锁屏。如第二应用程序为锁屏，第三应用程序为息屏。如第二应用程序为桌面，第三应用程序为息屏。

上述第二视图可以是第三应用程序可显示的第一卡片的卡片视图。上述第二视图可以是上述S604-S607，或者上述S1622-S1623中的卡片视图。

在一些示例中，电子设备确定第一应用程序的第一卡片的第二视图，可以包括：电子设备根据第三应用程序对应的卡片尺寸信息和第一应用程序的业务数据，确定第一应用程序的第一卡片的第二视图。

在一些示例中，电子设备确定第一应用程序的第一卡片的第二视图，可以包括：电子设备获取第三应用程序的标识信息；电子设备根据第三应用程序的标识信息，确定第二视图的标识信息；电子设备根据第二视图的标识信息，确定第二视图。

示例性地，上述第三应用程序的标识信息可以是上述S1622中的宿主应用程序的宿主标识(即host id)。上述第二视图的标识信息可以是上述S606，或者上述S1622中的卡片视图标识(即view id)。

具体地，上述示例中电子设备确定第一应用程序的第一卡片的第二视图的具体实施方式，也可以参考上述S606，或者上述S1622中的具体实施方式，本申请实施例中对此不再赘述。

示例性地，上述第二嵌入式窗口图层可以是能够嵌入第三应用程序的嵌入式窗口的图层。示例性地，第二嵌入式窗口图层可以是上述S607，或者上述S1624中的嵌入式窗口图层。

在一些示例中，电子设备根据第二视图，创建第三应用程序对应的第二嵌入式窗口图层，可以包括：将占位嵌入式窗口图层中的占位视图更新为第二视图，以得到第三应用程序对应的第二嵌入式窗口图层。

具体地，上述示例中电子设备根据第二视图，创建第三应用程序对应的第二嵌入式窗口图层的具体实施方式，可以参考上述S607，或者上述S1624中的具体实施方式，本申请实施例中对此不再赘述。

在电子设备根据第二视图，创建第三应用程序对应的第二嵌入式窗口图层之后，电子设备可以将第二嵌入式窗口图层嵌入第三应用程序的嵌入式窗口(即第三应用程序的宿主图层)，这样在电子设备显示第三应用程序对应的第二界面时，可以显示第三应用程序的嵌入式窗口，进而可以显示嵌入第三应用程序的嵌入式窗口的第二嵌入式窗口图层，即在第二界面内显示包括第二视图的第一卡片。

在一些示例中，第二视图与第一视图不同，可以是第二视图对应的显示内容与第一视图对应的显示内容不同。

在一些示例中，第二视图与第一视图不同，可以是第二视图对应的显示尺寸与第一视图对应的显示尺寸不同。其中，显示尺寸可以包括显示高度和显示宽度。

示例性地，第二应用程序为桌面，第三应用程序为通知中心，第二视图对应的显示高度小于第一视图对应的显示高度。这样一来，在电子设备的前台运行的应用程序由桌面切换为通知中心时，可以在通知中心显示包括第二视图的第一卡片，且第二视图对应的显示高度小于第一视图对应的显示高度，这样可以减小第一卡片所占的空间，使得电子设备的通知中心可以显示更多的通知信息卡片，用户不需要通过翻阅操作即可查看所有通知信息卡片，能够提高人机交互效率。

示例性地，第二应用程序为桌面，第三应用程序为锁屏，第二视图对应的显示宽度小于第一视图对应的显示宽度，第二视图对应的显示高度小于第一视图对应的显示高度。这样一来，在电子设备的前台运行的应用程序由桌面切换为锁屏时，可以在通知中心显示包括第二视图的第一卡片，且第二视图对应的显示宽度小于第一视图对应的显示宽度，第二视图对应的显示高度小于第一视图对应的显示高度，这样可以减小第一卡片所占的空间，使得电子设备的锁屏可以显示更多的通知信息卡片，用户不需要通过翻阅操作即可查看所有通知信息卡片，能够提高人机交互效率。

示例性地，第二应用程序为锁屏，第三应用程序为息屏，第二视图对应的显示宽度小于第一视图对应的显示宽度，第二视图对应的显示高度小于第一视图对应的显示高度。在该示例中，由于电子设备的息屏界面的显示空间有限，因此，在电子设备的前台运行的应用程序由锁屏切换为息屏时，可以在息屏界面显示包括第二视图的第一卡片，且第二视图对应的显示宽度小于第一视图对应的显示宽度，第二视图对应的显示高度小于第一视图对应的显示高度，这样可以缩小第一卡片的显示尺寸，进而可以最大限度减小第一卡片所占的空间，避免第二应用程序对应的卡片无法完整显示。另外，由于电子设备的息屏界面处于常亮状态，在息屏界面显示尺寸较小的第一卡片，可以降低电子设备的功耗。

需要说明的是，第一视图对应的显示尺寸可以是上述第二应用程序的卡片尺寸信息。第二视图对应的显示尺寸可以是上述第三应用程序的卡片尺寸信息。

在一些示例中，第二视图与第一视图不同，可以是第二视图对应的显示内容与第一视图对应的显示内容不同、且第二视图对应的显示尺寸与第一视图对应的显示尺寸不同。

在该示例中，在第一应用程序的业务发生变化时，电子设备可以针对不同应用程序的特点，生成各应用程序对应的卡片视图，其中，不同应用程序对应的卡片视图的显示内容和/或显示尺寸不同。这样一来，电子设备可以针对不同应用程序的特点，生成与各应用程序相适配的第一卡片，进而在电子设备切换到任一应用程序时，可以显示该应用程序对应的界面，并在该应用程序对应的界面显示包括该应用程序对应的卡片视图的第一卡片，这样能够保证在电子设备的不同应用程序显示的第一卡片均具有良好的显示效果。

在一些示例中，在响应于切换至第二应用程序的第一操作，电子设备显示第一界面之后，该卡片显示方法还可以包括：响应于切换至第三应用程序的第二操作，电子设备显示第二界面，第二界面中包括第三应用程序的嵌入式窗口，其中，在第三应用程序的嵌入式窗口内显示第二嵌入式窗口图层，以在第二界面内显示包括第二视图的第一卡片。

上述第二操作可以是用于打开电子设备的第三应用程序的操作。例如，第三应用程序为桌面，则第二操作可以为用户在电子设备的显示屏的底部的上滑操作。又如，第三应用程序为通知中心，则第二操作可以为用户在显示屏的顶部状态栏的下拉操作。还如，第三应用程序为锁屏，则第二操作可以为在电子设备处于锁屏状态时，用户对电子设备的显示屏的点击操作。示例性地，第二操作可以是上述S1629中的切换操作。第二界面可以是第三应用程序对应的显示界面。

在电子设备显示第一界面之后，在电子设备接收到切换至第三应用程序的第二操作时，响应于第二操作，电子设备可以显示第三应用程序对应的第二界面，第二界面中可以包括第三应用程序的嵌入式窗口，这样电子设备由显示第二应用程序对应的第一界面切换为第三应用程序对应的第二界面的同时，可以在第二界面中显示包括第二视图的第一卡片。

具体地，上述示例中响应于切换至第三应用程序的第二操作，电子设备显示第二界面的具体实施方式，可以参考上述S1630中的具体实施方式，本申请实施例中对此不再赘述。

在该示例中，在电子设备中的第一应用程序的业务发生变化时，响应于第一应用程序的业务发生变化，电子设备可以确定第一应用程序的第一卡片的第二视图，并根据第二视图，创建第三应用程序对应的第二嵌入式窗口图层，这样电子设备可以将第二嵌入式窗口图层嵌入至第三应用程序的嵌入式窗口。也就是说，在第一应用程序的业务发生变化时，电子设备可以针对不同应用程序的特点，确定可在各应用程序显示的卡片视图。进而，在电子设备接收到切换至第三应用程序的第二操作时，响应于第二操作，电子设备的显示界面可以由第二应用程序对应的第一界面切换为第三应用程序对应的第二界面。并且，由于电子设备显示第三应用程序的第二界面中包括第三应用程序的嵌入式窗口。因此，在电子设备的显示界面由第二应用程序对应的第一界面切换为第三应用程序对应的第二界面的同时，电子设备的显示界面中的第一卡片由包括第一视图的第一卡片切换为包括第二视图的第一卡片。也就是说，电子设备可以针对不同应用程序的特点，显示与各应用程序相适配的第一卡片，进而保证在电子设备的不同应用程序显示的第一卡片均具有良好的显示效果。

本申请的方案，在电子设备中的第一应用程序的业务发生变化时，响应于第一应用程序的业务发生变化，电子设备可以确定第一应用程序的第一卡片的第一视图，并根据第一视图，创建第二应用程序对应的第一嵌入式窗口图层，这样电子设备可以将第一嵌入式窗口图层嵌入至第二应用程序的嵌入式窗口。之后，在电子设备接收到切换至第二应用程序的第一操作时，响应于第一操作，电子设备可以显示第二应用程序对应的第一界面。由于电子设备显示第二应用程序的第一界面中包括第二应用程序的嵌入式窗口，因此，在电子设备显示第二应用程序对应的第一界面的同时，可以显示第二应用程序的嵌入式窗口内嵌入的第一嵌入式窗口图层，进而可以在第一界面中显示包括第一视图的第一卡片。也就是说，在电子设备的第二应用程序显示第一卡片时，可以通过显示第二应用程序的嵌入式窗口的方式显示第一卡片，而不是直接显示第一卡片。这样一来，电子设备可以根据第一应用程序的业务类型，确定第一卡片的第一视图，进而通过在第一界面显示包括第一视图的第一卡片，能够更有效、更直观地展示第一应用程序的业务状态，用户体验更好。

应理解以上装置中单元或模块(以下均称为单元)的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且装置中的单元可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分单元以软件通过处理元件调用的形式实现，部分单元以硬件的形式实现。

例如，各个单元可以为单独设立的处理元件，也可以集成在装置的某一个芯片中实现，此外，也可以以程序的形式存储于存储器中，由装置的某一个处理元件调用并执行该单元的功能。此外这些单元全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件又可以称为处理器，可以是一种具有信号的处理能力的集成电路。在实现过程中，上述方法的各步骤或以上各个单元可以通过处理器元件中的硬件的集成逻辑电路实现或者以软件通过处理元件调用的形式实现。

在一个例子中，以上装置中的单元可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个ASIC，或，一个或多个DSP，或，一个或者多个FPGA，或这些集成电路形式中至少两种的组合。

再如，当装置中的单元可以通过处理元件调度程序的形式实现时，该处理元件可以是通用处理器，例如CPU或其它可以调用程序的处理器。再如，这些单元可以集成在一起，以片上系统SOC的形式实现。

在一种实现中，以上装置实现以上方法中各个对应步骤的单元可以通过处理元件调度程序的形式实现。例如，该装置可以包括处理元件和存储元件，处理元件调用存储元件存储的程序，以执行以上方法实施例所述的方法。存储元件可以为与处理元件处于同一芯片上的存储元件，即片内存储元件。

在另一种实现中，用于执行以上方法的程序可以在与处理元件处于不同芯片上的存储元件，即片外存储元件。此时，处理元件从片外存储元件调用或加载程序于片内存储元件上，以调用并执行以上方法实施例所述的方法。

例如，本申请实施例还可以提供一种装置，如：电子设备，可以包括：处理器，用于存储该处理器可执行指令的存储器。该处理器被配置为执行上述指令时，使得该电子设备实现如前述实施例所述的卡片显示方法。该存储器可以位于该电子设备之内，也可以位于该电子设备之外。且该处理器包括一个或多个。

在又一种实现中，该装置实现以上方法中各个步骤的单元可以是被配置成一个或多个处理元件，这些处理元件可以设置于对应上述的电子设备上，这里的处理元件可以为集成电路，例如：一个或多个ASIC，或，一个或多个DSP，或，一个或者多个FPGA，或者这些类集成电路的组合。这些集成电路可以集成在一起，构成芯片。

例如，本申请实施例还提供一种芯片，该芯片可以应用于上述电子设备。芯片包括一个或多个接口电路和一个或多个处理器；接口电路和处理器通过线路互联；处理器通过接口电路从电子设备的存储器接收并执行计算机指令，以实现以上方法实施例中所述的方法。

本申请实施例还提供一种计算机程序产品，包括如上述电子设备运行的计算机指令。

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

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

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

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

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

例如，本申请实施例还可以提供一种计算机可读存储介质，其上存储有计算机程序指令。当计算机程序指令被电子设备执行时，使得电子设备实现如前述方法实施例中所述的卡片显示方法。

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

Claims (15)

1.一种卡片显示方法，其特征在于，应用于电子设备，所述方法包括：

响应于所述电子设备中的第一应用程序的业务发生变化，所述电子设备确定所述第一应用程序的第一卡片的第一视图；

所述电子设备根据所述第一视图，创建第二应用程序对应的第一嵌入式窗口图层；

响应于切换至所述第二应用程序的第一操作，所述电子设备显示第一界面，所述第一界面中包括所述第二应用程序的嵌入式窗口，其中，在所述第二应用程序的嵌入式窗口内显示所述第一嵌入式窗口图层，以在所述第一界面内显示包括所述第一视图的所述第一卡片。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

响应于所述电子设备中的第一应用程序的业务发生变化，所述电子设备确定所述第一应用程序的第一卡片的第二视图，所述第二视图与所述第一视图不同；

所述电子设备根据所述第二视图，创建第三应用程序对应的第二嵌入式窗口图层；

在所述响应于切换至所述第二应用程序的第一操作，所述电子设备显示第一界面之后，所述方法还包括：

响应于切换至所述第三应用程序的第二操作，显示第二界面，所述第二界面中包括所述第三应用程序的嵌入式窗口，其中，在所述第三应用程序的嵌入式窗口内显示所述第二嵌入式窗口图层，以在所述第二界面内显示包括所述第二视图的所述第一卡片。

3.根据权利要求1所述的方法，其特征在于，所述第一视图包括进度条，所述进度条用于指示所述第一应用程序的业务的进度状态；

所述进度条包括第一图标、第二图标、和第三图标，其中，所述第一图标用于指示所述第一应用程序的业务的执行起点，所述第二图标用于指示所述第一应用程序的业务的执行终点；

所述第三图标用于指示所述第一应用程序的业务的进度状态发生变化，且在所述第一应用程序的业务的进度状态发生变化时，所述第三图标在所述第一图标与所述第二图标之间的位置相应发生变化。

4.根据权利要求1所述的方法，其特征在于，所述第一应用程序的业务阶段包括第一业务阶段和第二业务阶段；所述第一视图包括分段进度条，所述分段进度条用于指示所述第一应用程序的业务在不同的业务阶段的进度状态；

所述分段进度条包括第四图标、第五图标、位于所述第四图标与所述第五图标之间的第六图标和第七图标；其中，所述第四图标用于指示所述第一应用程序的所述第一业务阶段的执行起点；所述第五图标用于指示所述第一应用程序的所述第二业务阶段的执行终点；所述第六图标用于指示所述第一应用程序的所述第一业务阶段的执行终点，且所述第一应用程序的所述第二业务阶段的执行起点；

所述第七图标用于指示所述第二应用程序的业务进度发生变化，且当所述第二应用程序的业务在所述第一业务阶段发生进度变化时，所述第七图标在所述第四图标与所述第六图标之间的位置相应发生变化；或者，当所述第二应用程序的业务在所述第二业务阶段发生进度变化时，所述第七图标在所述第六图标与所述第五图标之间的位置相应发生变化。

5.根据权利要求1所述的方法，其特征在于，所述电子设备确定所述第一应用程序的第一卡片的第一视图，包括：

所述电子设备获取所述第二应用程序的标识信息；

所述电子设备根据所述第二应用程序的标识信息，确定所述第一视图的标识信息；

所述电子设备根据所述第一视图的标识信息，确定所述第一视图。

6.根据权利要求1所述的方法，其特征在于，在所述电子设备确定所述第一应用程序的第一卡片的第一视图之前，所述方法还包括：

所述电子设备根据所述第二应用程序的卡片尺寸信息，生成占位视图；

所述电子设备根据所述占位视图，创建所述占位视图对应的占位嵌入式窗口图层；

所述电子设备将所述占位嵌入式窗口图层挂载至所述第二应用程序的嵌入式窗口。

7.根据权利要求6所述的方法，其特征在于，所述电子设备根据所述占位视图，创建所述占位视图对应的占位嵌入式窗口图层，包括：

在所述电子设备中存储有第三嵌入式窗口图层的情况下，获取所述第三嵌入式窗口图层的状态信息，其中，所述第三嵌入式窗口图层为根据所述第一应用程序的第二卡片的卡片视图创建的嵌入式窗口图层，所述第二卡片与所述第一卡片指示的所述第一应用程序的业务的进度状态不同；

在所述状态信息指示所述第三嵌入式窗口图层有效的情况下，将所述第三嵌入式窗口图层中的所述第二卡片的卡片视图更新为所述占位视图，以得到所述占位嵌入式窗口图层。

8.根据权利要求6所述的方法，其特征在于，所述电子设备根据所述第一视图，创建第二应用程序对应的第一嵌入式窗口图层，包括：

将所述占位嵌入式窗口图层中的所述占位视图更新为所述第一视图，以得到所述第二应用程序对应的第一嵌入式窗口图层。

9.根据权利要求2所述的方法，其特征在于，所述第二视图对应的显示内容与所述第一视图对应的显示内容不同，和/或，所述第二视图对应的显示尺寸与所述第一视图对应的显示尺寸不同。

10.根据权利要求2所述的方法，其特征在于，所述第二应用程序为桌面、通知中心、锁屏、息屏、负一屏或者横幅通知；

所述第三应用程序为桌面、通知中心、锁屏、息屏、负一屏或者横幅通知。

11.根据权利要求10所述的方法，其特征在于，所述第二视图对应的显示尺寸与所述第一视图对应的显示尺寸不同，所述显示尺寸包括显示高度和显示宽度；

其中，所述第二应用程序为所述桌面，所述第三应用程序为所述通知中心，所述第二视图对应的显示高度小于所述第一视图对应的显示高度。

12.根据权利要求10所述的方法，其特征在于，所述第二视图对应的显示尺寸与所述第一视图对应的显示尺寸不同，所述显示尺寸包括显示高度和显示宽度；

其中，所述第二应用程序为所述桌面，所述第三应用程序为所述锁屏，所述第二视图对应的显示宽度小于所述第一视图对应的显示宽度，所述第二视图对应的显示高度小于所述第一视图对应的显示高度。

13.根据权利要求10所述的方法，其特征在于，所述第二视图对应的显示尺寸与所述第一视图对应的显示尺寸不同，所述显示尺寸包括显示高度和显示宽度；

其中，所述第二应用程序为所述锁屏，所述第三应用程序为所述息屏，所述第二视图对应的显示宽度小于所述第一视图对应的显示宽度，所述第二视图对应的显示高度小于所述第一视图对应的显示高度。

14.一种电子设备，其特征在于，所述电子设备包括处理器，用于存储所述处理器可执行指令的存储器；所述处理器被配置为执行所述指令时，使得所述电子设备实现如权利要求1至13中任一项所述的方法。

15.一种计算机可读存储介质，其上存储有计算机程序指令；其特征在于，

当所述计算机程序指令被电子设备执行时，使得电子设备实现如权利要求1至13中任一项所述的方法。