CN117724825A - 一种界面显示方法及电子设备 - Google Patents

Abstract

本申请提出一种界面显示方法及电子设备，涉及终端技术领域，用于解决电子设备的宿主APP的主线程执行加载应用小部件的过程中，宿主APP出现卡顿的现象。其中，该界面显示方法可以包括：电子设备显示第一界面的过程中，检测到用户的第一操作，第一操作用于控制电子设备显示包括应用小部件的第二界面，电子设备基于宿主APP新启动的与主线程不同的第一线程获取应用小部件的布局信息，以显示包括应用小部件的第一显示页面的第二界面，第一显示页面是基于布局信息显示的。

Description

一种界面显示方法及电子设备

技术领域

本申请实施例涉及终端技术领域，尤其涉及一种界面显示方法及电子设备。

背景技术

随着电子设备的发展，各类应用(application，APP)层出不穷，使得用户可以在电子设备上通过应用处理很多事情，为用户提供了方便。比如，用户可以通过社交类APP与朋友聊天，通过新闻类APP了解各种资讯，等等。

应用小部件，也可称为窗口部件或应用小组件等，是指能直接显示在电子设备的宿主APP(比如，桌面APP或负一屏APP，等)上的小程序。比如，电子设备将日历应用小部件、天气应用小部件或搜索应用小部件等应用小部件加载到桌面应用中使用。应用小部件的使用为用户与电子设备之间的交互提供了方便。但是，当宿主APP加载应用小部件时，可能存在由于应用小部件启动或更新迟缓等原因，导致宿主APP出现卡顿现象。

发明内容

本申请实施例提供一种界面显示方法及电子设备，能够减少宿主APP加载应用小部件的过程中，宿主APP出现卡顿的现象，提高了宿主APP运行的流畅性。

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

第一方面，提供了一种界面显示方法，该方法可以包括：电子设备显示第一界面的过程中，检测到用户的第一操作，电子设备基于宿主APP新启动的与主线程不同的第一线程获取应用小部件的布局信息，以显示包括应用小部件的第一显示页面的第二界面，第一显示页面是基于布局信息显示的。

上述第一界面可以为电子设备的主界面，也可以为负一屏，还可以为某一应用的界面，此处不做限定。第一操作用于控制电子设备显示包括应用小部件的第二界面，比如，第一操作可以为用户对宿主APP的图标的操作，也可以为对主界面的滑动操作，等等，此处也不做限定。

可以理解为，电子设备的宿主APP加载应用小部件时，宿主APP启动不同于主线程的第一线程执行获取应用小部件的布局信息的操作，宿主APP的主线程和第一线程并行执行相应的任务，缓解了宿主APP的主线程的压力，解决了宿主APP加载应用小部件的过程中出现卡顿的现象。

在第一方面的一种可能的实现方式中，电子设备基于宿主应用APP的第一线程获取应用小部件的布局信息之前，上述界面显示方法还可以包括：电子设备通过宿主APP启动第一线程。

可以理解为，电子设备通过宿主APP启动不同于主线程的第一线程，使得宿主APP采用第一线程执行获取应用小部件的布局信息的任务，减缓了宿主APP加载应用小部件时宿主APP的压力，解决了宿主APP加载应用小部件的过程中出现卡顿的现象。

在第一方面的另一种可能的实现方式中，电子设备显示第二界面之后，上述界面显示方法还可以包括：

电子设备基于宿主APP获取应用小部件的第一内容信息后，电子设备显示第三界面，第三界面包括应用小部件的第二显示页面，第二显示页面中显示有第一内容信息。

在一种可能的情况下，电子设备可以基于宿主APP的主线程获取应用小部件的第一内容信息，还可以基于宿主APP的第一线程获取应用小部件的第一内容信息，此处不做限定。

可以理解为，在宿主APP启动过程中，宿主APP加载应用小部件时，电子设备基于宿主APP的第一线程获取应用小部件的第一内容信息，避免了宿主APP启动过程中主线程堵塞导致宿主APP出现响应迟缓或不响应的问题，提高了宿主APP加载应用小部件时的流畅性。

也就是说，电子设备的宿主APP中显示应用小部件的默认布局之后，电子设备基于宿主APP获取到的应用小部件的初始视图对应的第一内容信息，宿主APP中显示应用小部件的初始视图。由此，电子设备基于宿主APP的第一线程获取应用小部件的第一内容信息，使得宿主APP的第一线程和主线程并行执行相应的任务，避免了宿主APP加载应用小部件的过程中，宿主APP出现卡顿的现象。

在宿主APP加载应用小部件时，宿主APP的第一线程执行获取默认布局的布局信息之后，宿主APP可以释放掉第一线程，宿主APP加载应用小部件的后续过程由宿主APP的主线程执行，即宿主APP的主线程执行获取应用小部件的第一内容信息的操作。由此，宿主APP及时释放第一线程，避免了第一线程占用过多的资源。

在第一方面的另一种可能的实现方式中，第一内容信息是宿主APP的第一线程获取到的；电子设备显示第三界面，可以包括：

电子设备基于宿主APP的第一线程将第一内容信息发送至宿主APP的主线程后，电子设备基于宿主APP的主线程接收到的第一内容信息，显示第三界面。

可以理解为，宿主APP的第一线程执行获取第一内容信息的操作后，将获取到的第一内容信息发送至主线程，主线程执行基于第一内容信息显示应用小部件的第二显示页面的操作。由此，宿主APP及时释放第一线程，避免了宿主APP启动的第一线程占用过多的资源。

在第一方面的另一种可能的实现方式中，电子设备显示第三界面，可以包括：

电子设备基于宿主APP的第一线程或主线程获取到的第一内容信息，显示第三界面。也就是说，宿主APP的第一线程执行获取第一内容信息的操作后，第一线程直接执行基于第一内容信息显示应用小部件的第二显示页面的操作。或者，宿主APP的主线程执行获取第一内容信息的操作后，主线程直接执行基于第一内容信息显示应用小部件的第二显示页面的操作。

在第一方面的另一种可能的实现方式中，电子设备显示第三界面之前，上述界面显示方法还可以包括：

电子设备确定宿主APP的主线程接收到至少一个更新请求后，宿主APP的主线程将至少一个更新请求存储至请求队列，更新请求用于指示更新应用小部件中的内容信息；

电子设备显示第三界面之后，电子设备基于宿主APP的主线程从请求队列中获取到的更新请求，显示第四界面，第四界面中包括应用小部件的第三显示页面，第三显示页面中显示有更新请求对应的第二内容信息。

可以理解为，在宿主APP显示应用小部件的默认布局和初始视图的过程中，宿主APP的主线程接收到对应用小部件的显示内容的更新请求，宿主APP将更新请求存储至请求队列，在宿主APP中显示应用小部件的初始视图之后，宿主APP的主线程执行更新请求，确保了请求队列中存储的每一个更新请求都可以按照预计顺序执行，避免了更新请求未被执行的情况。

在第一方面的另一种可能的实现方式中，电子设备显示第二界面之前，上述界面显示方法还可以包括：

电子设备确定宿主APP的主线程接收到至少一个更新请求后，宿主APP的主线程将至少一个更新请求存储至请求队列，更新请求用于指示更新应用小部件中的内容信息；

电子设备显示第二界面之后，电子设备基于宿主应用APP的主线程从请求队列中获取到更新请求，然后，电子设备基于宿主APP的主线程从请求队列中获取的更新请求，显示第四界面。

可以理解为，在宿主APP显示应用小部件的默认布局的过程中，宿主APP的主线程接收到对应用小部件的显示内容的更新请求，宿主APP将更新请求存储至请求队列，在宿主APP中显示应用小部件的默认布局之后，宿主APP的主线程执行更新请求，确保了请求队列中存储的每一个更新请求都可以按照预计顺序执行，避免了更新请求未被执行的情况。

此外，宿主APP中显示应用小部件的默认布局之后，直接显示应用小部件的更新后视图，提高了应用小部件的显示效率。

在第一方面的另一种可能的实现方式中，电子设备基于宿主应用APP的主线程从请求队列中获取到的更新请求，可以包括：

电子设备基于宿主APP的主线程根据至少一个更新请求存储至请求队列的存储顺序，从请求队列中依次获取到更新请求。

可以理解为，宿主APP的主线程根据请求队列中存储的更新请求的存储顺序，依次获取到更新请求，使得请求队列中存储的每一个更新请求都可以按照预计顺序执行，确保了应用小部件的更新后视图的中更新内容的显示顺序。

在第一方面的另一种可能的实现方式中，电子设备显示第三界面之前，上述界面显示方法还可以包括：

电子设备确定宿主APP的第一线程接收到至少一个更新请求后，宿主APP的第一线程将至少一个更新请求存储至请求队列，更新请求用于指示更新应用小部件中的内容信息；

电子设备显示第三界面之后，电子设备基于宿主APP的第一线程从请求队列中获取到更新请求，显示第四界面，第四界面中包括应用小部件的第三显示页面。

可以理解为，在宿主APP显示应用小部件的默认布局和初始视图的过程中，宿主APP的第一线程接收到更新请求后，将更新请求存储至请求队列，在宿主APP中显示应用小部件的初始视图之后，宿主APP的第一线程执行更新请求。由此，宿主APP的第一线程执行对应用小部件的更新过程，确保了宿主APP的主线程可以及时执行其它任务，提高了宿主APP运行的流畅性。

在第一方面的另一种可能的实现方式中，电子设备显示第二界面之前，上述界面显示方法还可以包括：

电子设备确定宿主APP的第一线程接收到至少一个更新请求后，宿主APP的第一线程将至少一个更新请求存储至请求队列，更新请求用于指示更新应用小部件中的内容信息；

电子设备显示第二界面之后，电子设备基于宿主APP的第一线程从请求队列中获取到的更新请求，显示第四界面。

可以理解为，在宿主APP显示应用小部件的默认布局的过程中，宿主APP的第一线程接收到对应用小部件的显示内容的更新请求，宿主APP将更新请求存储至请求队列，在宿主APP中显示应用小部件的默认布局之后，宿主APP的第一线程执行更新请求。由此，宿主APP的第一线程执行对应用小部件的更新过程，确保了宿主APP的主线程可以及时执行其它任务，提高了宿主APP运行的流畅性。

在第一方面的另一种可能的实现方式中，电子设备基于宿主APP的第一线程从请求队列中获取到的更新请求，可以包括：

电子设备基于宿主APP的第一线程根据至少一个更新请求存储至请求队列的存储顺序，从请求队列中依次获取到更新请求。

可以理解为，宿主APP的第一线程根据请求队列中存储的更新请求的存储顺序，依次获取到更新请求，使得请求队列中存储的每一个更新请求都可以按照预计顺序执行，确保了应用小部件的更新后视图的中更新内容的显示顺序。

在第一方面的另一种可能的实现方式中，电子设备显示第三界面之前，上述界面显示方法还可以包括：

电子设备的宿主APP接收第一任务，电子设备基于宿主APP的主线程执行第一任务，第一任务与宿主APP加载应用小部件的任务不同。

可以理解为，在宿主APP加载应用小部件的过程中，宿主APP接收到不同于加载应用小部件的任务，宿主APP的主线程可以及时的执行第一任务，避免了宿主APP出现卡顿的现象，提供了宿主APP运行的流程性。

第二方面，本申请提供了另一种界面显示方法，该方法可以包括：电子设备接收第一操作；响应于第一操作，电子设备基于宿主APP的第一线程获取应用小部件的界面信息后，电子设备根据界面信息显示应用小部件的用户界面。

上述第一操作用于控制电子设备显示应用小部件的用户界面，比如，第一操作可以为用户对宿主APP的图标的操作，也可以为对主界面的滑动操作，也可以为用户的语音控制操作，等等，此处对第一操作的具体形式不做限定。

可以理解为，在电子设备通过宿主APP加载应用小部件的过程中，宿主APP启动新的第一线程执行获取应用小部件的界面信息的操作，缓解了宿主APP的主线程执行任务的压力，提高了宿主APP加载应用小部件的流畅性。

在第二方面的一种可能的实现方式中，上述界面信息可以包括应用小部件的布局信息。电子设备根据界面信息显示应用小部件的用户界面，可以包括：

电子设备的宿主APP根据应用小部件的布局信息，显示的应用小部件的第一显示页面。

可以理解为，电子设备通过宿主APP新启动的第一线程获取应用小部件的默认布局对应的布局信息后，电子设备显示应用小部件的默认布局对应的界面。

在第二方面的另一种可能的实现方式中，上述界面信息可以包括应用小部件的布局信息和第一内容信息。电子设备根据界面信息显示应用小部件的用户界面，可以包括：

电子设备显示第三界面。第三界面中显示的应用小部件的用户界面可以为应用小部件的加载了第一内容信息的初始视图对应的界面。

可以理解为，电子设备通过宿主APP的第一线程获取到应用小部件的默认布局对应的布局信息和初始视图对应的第一内容信息后，电子设备直接显示加载了默认布局的初始视图对应的界面，从而提高了宿主APP加载应用小部件的速度。

第三方面，本申请提供一种电子设备，包括：触摸屏，触摸屏包括触摸传感器和显示屏；一个或多个处理器；存储器；其中，存储器中存储有一个或多个计算机程序，一个或多个计算机程序包括指令，当指令被电子设备执行时，使得电子设备执行如上述第一方面中任一项所述的界面显示方法。

第四方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当指令在电子设备上运行时，使得电子设备执行如第一方面中任一项所述的界面显示方法。

第五方面，本申请提供一种计算机程序产品，计算机程序产品包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行如第一方面中任一项所述的界面显示方法。

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

附图说明

图1为相关技术中应用小部件加载至宿主APP的示例图；

图2为相关技术中宿主APP加载应用小部件的时序图；

图3为相关技术中笔记应用小部件加载至宿主APP的示例图；

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

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

图6为本申请实施例提供的一种应用小部件在宿主APP中显示的示例图；

图7为本申请实施例提供的将应用小部件设置到主界面的示例图一；

图8为本申请实施例提供的将应用小部件加载至宿主APP的示例图；

图9为本申请实施例提供的将应用小部件设置到主界面的示例图二；

图10为本申请实施例提供的一种应用小部件的位置移动的示例图；

图11为本申请实施例提供的删除应用小部件的示例图；

图12为本申请实施例提供的宿主APP中加载应用小部件的时序图一；

图13为本申请实施例提供的宿主APP中加载应用小部件的时序图二；

图14为本申请实施例提供的将应用小部件加载至宿主APP的示例图；

图15为本申请实施例提供的宿主APP更新应用小部件的时序图一；

图16为本申请实施例提供的宿主APP更新应用小部件的示例图一；

图17为本申请实施例提供的宿主APP更新应用小部件的示例图二；

图18为本申请实施例提供的宿主APP更新应用小部件的时序图二；

图19为本申请实施例提供的宿主APP更新应用小部件的示例图三；

图20为本申请实施例提供的宿主APP更新应用小部件的时序图三；

图21为本申请实施例提供的宿主APP更新应用小部件的时序图四；

图22为本申请实施例提供的宿主APP更新应用小部件的时序图五；

图23为本申请实施例提供的宿主APP更新应用小部件的时序图六；

图24为本申请实施例提供的一种删除应用小部件的示例图；

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

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

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

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在电子设备将应用小部件加载至宿主APP的过程中，宿主APP的主线程首先在宿主APP的用户界面中创建应用小部件的默认布局对应的视图。然后，宿主APP的主线程获取到应用小部件待显示的初始内容信息后，将用于显示应用小部件的初始内容信息的初始视图更新到应用小部件在宿主APP的用户界面中对应的默认布局对应的视图中。

示例性的，图1为相关技术中应用小部件加载至宿主APP的示例图。如图1所示，手机将日历应用小部件加载到桌面APP时，桌面APP首先在图1中的(a)所示的界面101中创建日历应用小部件102的默认布局对应的显示页面。其中，默认布局对应的显示页面用于加载日历应用小部件待显示的内容。然后，桌面APP将日历应用小部件的初始视图对应的内容信息加载到默认布局对应的显示页面中，加载了初始视图的内容信息的日历应用小部件如图1中的(b)所示的界面103中示出的日历应用小部件104。

可以理解为，上述图1中手机将日历应用小部件加载至桌面APP的过程，是在桌面APP的主线程上执行的，在桌面APP的主线程加载日历应用小部件的过程中，桌面APP的主线程处理与应用小部件加载相关的繁多任务，使得主线程无法及时响应其他的任务。比如，在桌面APP的主线程加载日历应用小部件的过程中，若桌面APP接收到对电话图标的触发操作，桌面APP的主线程在日历应用小部件在桌面APP中加载完成后，再去执行该触发操作，显示图1中的(c)所示的界面105。可见，在桌面APP加载日历应用小部件的过程中，手机检测到用户对桌面APP中其他应用的图标的触发操作后，桌面APP出现响应迟缓的现象。还比如，在桌面APP的主线程加载日历应用小部件的过程中，桌面APP接收到用户对桌面的滑动操作，桌面APP并无任何反应，导致用户使用手机时存在桌面响应不流畅的问题。

示例性的，图2为相关技术中宿主APP加载应用小部件的时序图。如图2所示，在电子设备中某一宿主APP中首次加载应用小部件的场景下，宿主APP的主线程基于应用小部件类调用创建视图函数创建应用小部件的宿主视图。比如，宿主APP的主线程基于AppWidgetHost类调用createView函数创建应用小部件的宿主视图。宿主APP的主线程基于应用小部件类创建出一个新的宿主视图。然后，宿主APP的主线程基于应用小部件类设置应用小部件的对应信息，比如，宿主APP的主线程基于AppWidgetHost类调用setAppWidget(widgetid，providerinfo)函数设置应用小部件的标识信息和应用小部件的属性信息。其中，widgetid用于设置应用小部件的标识信息，该标识信息用于唯一标识应用小部件。providerinfo用于设置应用小部件的属性信息，应用小部件的属性信息包括但不限于应用小部件在宿主APP中显示的形状、大小、待显示的内容、内容更新频率和提供内容的原生APP。宿主APP的主线程基于应用小部件类将应用小部件的标识信息和属性信息发送至宿主视图类。宿主APP的主线程基于宿主视图类根据获取到的应用小部件的标识信息和属性信息设置一个宿主视图后，宿主APP的主线程可以基于应用小部件类更新应用小部件，比如，宿主APP的主线程基于AppWidgetHost类调用updateAppWidget函数触发对宿主APP中显示的应用小部件进行更新的过程。宿主APP的主线程基于宿主视图类获取应用小部件的默认布局后，在宿主APP中显示应用小部件的默认布局。比如，宿主APP的主线程基于AppWidgetHostView类调用getDefaultView函数获取应用小部件的默认布局后，在宿主APP中显示应用小部件的默认布局。如图1中的(a)中的界面101中显示的日历应用小部件102的默认布局。

此后，宿主APP的主线程基于宿主视图类获取该应用小部件待显示的内容信息，以将应用小部件的内容信息显示在默认布局中。比如，宿主APP的主线程基于AppWidgetHostView类调用applyContent(defaultView)函数，将应用小部件的内容信息加载至默认布局中，以在宿主APP中显示应用小部件的内容信息。

上述图2中示出的电子设备在宿主APP中加载应用小部件的整个过程是由宿主APP的主线程同步执行的，因此，在宿主APP的主线程加载应用小部件的过程，若存在待处理的用户交互任务或界面更新等其它任务，则可能存在由于宿主APP的主线程无法及时执行用户交互任务、界面更新或其它任务，导致宿主APP的主线程阻塞的现象，进而导致宿主APP出现响应迟缓甚至不响应，从而导致宿主APP出现卡顿现象。

同样的，在宿主APP的主线程执行对应用小部件的更新或修改配置信息的过程中，若宿主APP的主线程接收到用户交互任务或界面更新等其它任务，则可能存在由于宿主APP的主线程执行应用小部件的更新或修改配置信息的任务，导致宿主APP的主线程阻塞，无法及时执行其它任务，进而导致宿主APP出现响应迟缓甚至不响应，从而导致宿主APP出现卡顿现象。

示例性的，假设电子设备响应于用户的操作，在日历APP中预先设定了一个定时提醒任务。后续，电子设备确定当前时间为预设时间时，桌面APP中主动加载日历应用小部件，并在日历应用小部件中显示该定时提醒任务对应的内容。比如，日历APP中设定晚上7点钟的会议提醒任务，当电子设备确定当前时间为晚上7点中，电子设备的桌面APP中主动加载日历应用小部件，并在该日历应用小部件中显示晚上7点钟的会议提醒任务。但是，在电子设备的桌面APP加载日历应用小部件的过程中，桌面APP无法同步执行其它任务，从而导致桌面APP出现响应缓慢的现象。

相关技术中，当宿主APP的主线程同时接收到对应用小部件进行更新的多个更新请求时，可能存在宿主APP的主线程并未依次执行多个更新请求，比如，宿主APP中可能仅执行最新接收到的更新请求，从而导致应用小部件出现更新内容显示不完整的现象。

示例性的，图3中示出的界面301中的桌面APP中加载了笔记应用小部件，当笔记的原生APP中新增加了3条记录时，桌面APP接收到3个更新请求，但是，桌面APP的主线程仅执行了最新的更新请求，从而导致宿主APP中仅显示最新的更新请求对应的内容。

为了解决上述问题，本申请实施例提供一种界面显示方法，可应用于电子设备。电子设备接收到用户的第一操作，电子设备基于宿主APP的不同于主线程的第一线程获取应用小部件的布局信息，以根据布局信息显示包括应用小部件的第一显示页面的第二界面。由此，在宿主APP中加载应用小部件的过程中，宿主APP开启新的第一线程执行获取应用小部件的布局信息的操作，也就是说，将加载应用小部件过程中的部分任务交由第一线程执行，从而不影响宿主APP的主线程执行其它任务，宿主APP的主线程和第一线程并行执行，能够降低主线程的处理工作量，避免了宿主APP的主线程出现阻塞，导致宿主APP出现卡顿的现象。

示例性的，本申请实施例提供的界面显示方法可应用于手机、平板电脑、个人计算机(personal computer，PC)、个人数字助理(personal digital assistant，PDA)、智能手表、上网本、可穿戴电子设备、增强现实技术(augmented reality，AR)设备、虚拟现实(virtual reality，VR)设备、车载设备、智能汽车、智能音响等具有显示屏的电子设备，本申请实施例对此不做任何限制。

如图4所示，图4为本申请实施例提供的电子设备的一种结构示意图。

电子设备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，骨传导传感器180M等。

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

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

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

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

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(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)接口等。

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

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。

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

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

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。

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

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

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

在本申请实施例中，显示屏194可以是一个一体的柔性显示屏，也可以采用两个刚性屏以及位于两个刚性屏之间的一个柔性屏组成的拼接的显示屏。

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

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

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

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

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

NPU为神经网络(neural-network，NN)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现电子设备100的智能认知等应用，例如：图像识别，人脸识别，语音识别，文本理解等。

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

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

在本申请实施例中，存储数据区可以存储电子设备100使用过程中所创建的数据(比如图像、视频、APP的用户界面中的内容、应用小部件中的内容)等。例如，内部存储器121可以用于存储应用小部件的相关信息和宿主APP的相关信息等。

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

按键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分离。

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

图5为本申请实施例提供的电子设备的一种软件结构图。

可以理解的是，分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，系统可以包括应用程序层(简称为应用层)、应用程序框架层(简称为框架层)、系统库和内核层。

其中，应用层可以包括宿主APP和内容提供方(即原生APP)。宿主APP和原生APP均可以为系统应用，也均可以为第三方应用，也可以宿主APP为系统应用，原生APP为第三方应用，还可以原生APP为系统应用，宿主APP为第三方应用，此处不做限定。

其中，系统应用是指电子设备在出厂之前设置在电子设备内的应用。示例性的，系统应用可以包括桌面、相机、图库、日历、音乐、备忘录以及天气等程序。第三方应用是指用户从应用商店(或者应用市场)下载安装包后安装的应用。例如，地图类应用、外卖类应用、阅读类应用(例如电子书)、社交类应用以及出行类应用等。

比如，宿主APP可以为桌面，原生APP可以为日历；还比如，宿主APP可以为桌面，原生APP可以为地图类应用；再比如，宿主APP可以为社交类应用，原生APP可以为地图类应用；又比如，宿主APP可以为社交类应用，原生APP可以为日历。

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

如图5所示，应用程序框架层可以包括应用小部件系统，窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

在本申请实施例中，宿主APP与原生APP之间无法直接进行通信，应用小部件系统可以作为宿主APP与原生APP之间的通信桥梁。此处，原生APP可以为应用小部件的内容提供方，原生APP可以调用AppWidgetProvider类与应用小部件系统调用的AppWidgetHostView类之间传递信息，以实现原生APP与应用小部件系统之间的通信。应用小部件系统可以调用AppWidgetHostView类与宿主APP调用的AppWidgetHost类之间传递信息，以实现宿主APP与应用小部件系统之间的通信。

示例性的，如图5所示，当宿主APP中加载应用小部件时，宿主APP可以基于应用小部件类(比如，AppWidgetHost类)向应用小部件系统(比如，AppWidgetHostView类)发送创建应用小部件的请求，应用小部件系统接收到创建应用小部件的请求后，应用小部件系统从原生APP获取应用小部件的默认布局的布局信息，将应用小部件的默认布局对应的布局信息发送至宿主APP，宿主APP根据接收到的布局信息显示应用小部件的默认布局。

当原生APP更新了内容后，原生APP通过应用小部件系统向宿主APP发送用于更新应用小部件的更新请求，宿主APP接收到更新请求后，将更新请求存储至请求队列中。在宿主APP中显示应用小部件的默认布局和/或初始视图后，宿主APP执行更新请求。宿主APP通过应用小部件系统向原生APP发送更新请求，原生APP接收到更新请求后，将更新后的内容信息发送至应用小部件系统，应用小部件系统将更新后的内容信息发送至宿主APP。宿主APP根据更新后的内容信息更新应用小部件的显示内容。

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

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

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

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

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

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

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

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

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

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

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

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

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

二维图形引擎是二维绘图的绘图引擎。

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

本申请实施例中的电子设备可以安装有一个或者多个应用，并在电子设备的显示屏上所显示的桌面上显示该电子设备中安装的应用的图标。其中，本申请实施例中的应用可以是嵌入式应用(即电子设备的系统应用)，也可以是可下载应用。嵌入式应用是作为电子设备实现的一部分提供的应用程序。可下载应用可以是一个可以提供因特网协议多媒体子系统(internet protocol multimedia subsystem，IMS)连接的应用程序，该可下载应用可以是预先安装在电子设备中的应用，还可以由用户下载并安装在电子设备中的第三方应用，此处不做限定。

其中，电子设备的显示屏可以显示桌面应用的一个页面或一屏。桌面应用可以包括多个页面(page)或多屏。其中，每个页面上可以显示或放置多个元素(element)，每一屏上可以显示或放置多个元素。其中，该元素可以为应用的图标、分组(例如，文件夹)或应用小部件等。另外，电子设备还可以在桌面应用的不同页面之间进行切换。其中，应用的图标也可以称为应用图标或简称为图标。

另外，电子设备的桌面上的页面还可以包括负一屏，负一屏上也可以显示元素，如负一屏可以显示电子设备中已经安装的应用的图标(比如，备忘录、日历等)或应用小部件(比如，健康应用小部件，新闻应用小部件或设置应用小部件等)。通常情况下，负一屏上显示的可以是用户常用的应用的图标或应用小部件。其中，上述负一屏可以是指用户从主屏幕向右滑动进入的界面，也可以是用户从锁屏界面向右滑动进入的界面，本申请实施例对进入负一屏的方式不做限定。

此外，负一屏上还可以显示电子设备推荐的待安装的应用的图标，比如，视频类应用的图标、交友类应用的图标或新闻类应用的图标等，本申请实施例中对负一屏中显示的元素不做限定。

由上可知，应用小部件可以位于电子设备的桌面的负一屏，桌面或者某一APP的界面上，本申请实施例对应用小部件的位置不做限定。例如，主界面可以为图6中的(a)所示的界面600，界面600包括时间应用小部件601。还例如，负一屏可以为图6中的(b)所示的界面602，界面602包括搜索应用小部件603和健康应用小部件604等。可以理解的是，电子设备可以响应于用户在界面600上向右的滑动操作，显示界面602。

又例如，以宿主APP为日历为例，日历的界面可以为图6中的(c)所示的界面605，界面605可以包括天气应用小部件606和日程应用小部件607。

本申请实施例中对宿主APP中显示应用小部件的数量不做限定，如图6中的(a)所示，桌面APP中可以显示一个应用小部件，还如图6中的(c)所示，日历APP中可以显示天气应用小部件606和日程应用小部件607。此外，一个应用小部件可以显示在多个宿主APP中，比如，日历应用小部件可以显示在桌面APP，还可以显示在负一屏。

宿主APP，为可以加载运行应用小部件的APP。宿主APP可以为桌面APP，也可以为负一屏APP，也可以为其他APP，此处不做限定。例如，假设主界面为图6中的(a)所示的界面600，界面600中包括时间小部件601，则时间小部件601的宿主APP为桌面APP。还例如，假设负一屏为图6中的(b)所示的界面602，界面602中包括搜索应用小部件603和健康应用小部件604，则搜索应用小部件603和健康应用小部件604的宿主APP为负一屏APP。又例如，图6中的(c)中的日历的界面605包括天气小部件606，则天气小部件606的宿主APP为日历。

在本申请实施例中，电子设备可以响应于用户的操作，将某一个或多个应用小部件加载至宿主APP中。比如，本申请实施例可以通过将日历应用小部件设置到主界面上，使得电子设备显示主界面时可以显示当前的日历；还比如，本申请实施例可以通过将健康应用小部件设置到负一屏上，使得电子设备在显示负一屏时可以显示当前步数等信息。

示例性的，图7为本申请实施例提供的将应用小部件设置到主界面的示例图一。如图7所示，桌面应用的主界面可以为图7中的(a)所示的界面700，电子设备检测到用户对主界面700中任意位置的触发操作(比如，长按操作)后，响应于用户的触发操作，电子设备显示图7中的(b)所示的界面701。电子设备检测到用户对界面701中桌面卡片控件702的触发操作后，响应于触发操作，电子设备显示图7中的(c)所示的界面703。其中，界面703中显示有多个应用小部件，比如，图7中的(c)中可以包括的图库应用小部件、日历应用小部件或录音机应用小部件，等等。电子设备检测到用户对界面703中的日历应用小部件704的触发操作(比如，点击操作或触摸操作等)，响应于触发操作，电子设备显示图7中的(d)所示的界面705。其中，日历应用小部件706被添加到界面705中。

此处，图7中的(c)中示出的应用小部件仅作为示例性描述，本申请实施例中不限于此。当界面703中当前显示的应用小部件不包括待添加至桌面的应用小部件时，电子设备接收到用户对界面703中搜索控件707的触发操作，响应于触发操作，电子设备显示搜索得到的应用小部件。响应于用户的触发操作，电子设备可以将搜索得到的应用小部件添加至桌面的任意页面中。

可以理解的是，上述图7中示出的电子设备将日历应用小部件添加至桌面的主界面仅作为一种示例，电子设备可以将日历应用小部件添加至桌面的任意页面中，本申请实施例中对日历应用小部件在桌面中的显示位置不做限定。

在本申请实施例中，在电子设备将应用小部件添加至宿主APP的过程中，电子设备可以设置不同形状和/或大小的应用小部件在宿主APP中显示。

示例性的，如图8所示，电子设备响应于用户的触发操作，显示图8中的(a)所示的界面800。其中，界面800中显示有多个应用小部件。电子设备检测到用户对界面800中的天气应用小部件801的触发操作(比如，点击操作或触摸操作等)，响应于触发操作，电子设备显示图8中的(b)所示的界面802。其中，界面802中显示有不同形状、大小的天气应用小部件。电子设备检测到用户对界面802的向左的滑动操作，响应于滑动操作，电子设备显示图8中的(c)所示的界面803，其中，界面803中显示有天气应用小部件，且界面803中显示的天气应用小部件与界面802中显示的天气应用小部件的形状、大小并不相同。当电子设备检测到用户对界面803中显示的添加到桌面控件804的触发操作(比如，单击操作，双击操作或触摸操作等)，响应于触发操作，电子设备显示如图8中的(d)所示的界面805，其中，界面805中显示有天气应用小部件806，且天气应用小部件806与界面803中显示的天气应用小部件的形状、尺寸相同。

在本申请实施例中，电子设备将应用小部件添加至宿主APP之后，即宿主APP中显示有应用小部件之后，电子设备还可以设置宿主APP中显示的应用小部件的形状和/或大小。

示例性的，电子设备检测到用户对如图8中的(d)显示的天气应用小部件806的触发操作(比如，长按操作或双击操作等)，电子设备可以对天气应用小部件806的形状和/或大小进行设置的界面，电子设备可以响应于用户的操作对天气应用小部件806的形状和/或大小进行设置。

以上示例中显示的应用小部件仅作为一种示例性描述，本申请实施例中对应用小部件在宿主APP中显示的具体形状、形式等不做限定。例如，宿主APP中显示的应用小部件可以为椭圆形、圆形、星形或方形等。

在本申请实施例中，电子设备桌面的应用小部件对应的原生APP的图标响应于用户的触发操作(比如，长按操作或双击操作等)后，原生APP的图标上显示有悬浮卡片，响应于用户对悬浮卡片的操作，电子设备桌面显示有应用小部件。

示例性的，图9为本申请实施例提供的将应用小部件设置到主界面的示例图二。如图9所示，桌面应用的主界面可以为图9中的(a)所示的界面900，电子设备桌面检测到用户对界面900中的天气图标901的长按操作后，电子设备显示图9中的(b)所示的界面902，且界面902中天气图标901上显示有悬浮卡片903。电子设备检测到用户对悬浮卡片903中“服务卡片”的控制操作，响应于控制操作，电子设备显示图9中的(c)所示的界面904，且界面904中显示有天气应用小部件905。其中，控制操作包括但不限于单击、双击或长按悬浮卡片903中“服务卡片”的操作。

上述图7和图9中示出的将应用小部件加载至宿主APP中的方法仅作为示例性描述，仅仅是本申请实施例中的可能的实现方式，本申请实施例中对应用小部件加载至宿主APP中的方法不做限定。比如，应用小部件的原生APP的图标可以响应于用户的控制操作，在原生APP的图标上悬浮显示。在原生APP的图标上悬浮显示的应用小部件响应于用户的双击或拖动操作后，在电子设备的桌面中显示应用小部件。

在本申请实施例中，电子设备将应用小部件加载至宿主APP之后，电子设备可以响应于用户的操作，调整应用小部件在宿主APP中的显示位置。比如，电子设备检测到用户对应用小部件的拖动操作后，响应于拖动操作，电子设备可以将应用小部件移动至用户指定位置。

示例性的，图10为本申请实施例提供的一种应用小部件的位置移动的示例图。如图10所示，桌面应用的主界面可以为图10中的(a)所示的界面1001，其中，界面1001中显示有日历应用小部件1002。电子设备检测到用户对日历应用小部件1002的向右的拖动操作后，电子设备可以在图10中的(b)所示的界面1003中显示日历应用小部件1002，电子设备还可以在图10中的(c)中所示的界面1004中显示日历应用小部件1002。

需要解释的是，图10中示出的日历应用小部件1002的显示位置仅作为示例性描述，该日历应用小部件1002可以显示在电子设备的任意显示位置，本申请实施例中对日历应用小部件1002的显示位置不做限定。电子设备可以响应于用户的拖动操作，将日历应用小部件1002移动至桌面的任意位置进行显示。

还需要解释的是，在电子设备将应用小部件首次加载至宿主APP，宿主APP中显示一定形状和大小的应用小部件之后，在电子设备重新启动或宿主APP更新后，应用小部件在宿主APP中显示形状和位置不变。比如，如图10中的(a)中显示有日历应用小部件1002，在手机响应于用户的操作重新启动后，日历应用小部件1002仍显示在图10中的(a)中的位置，且该日历应用小部件1002的形状和大小，与手机重新启动之前桌面中显示的日历应用小部件1002的形状和大小相同。

在本申请实施例中，电子设备将应用小部件加载至宿主APP之后，电子设备可以响应于用户的操作，删除宿主APP中的应用小部件。比如，宿主APP中显示的应用小部件接收到用户的长按操作后，响应于长按操作，电子设备将宿主APP中的应用小部件移除。还比如，宿主APP中显示的应用小部件接收到用户的拖动操作后，响应于用户的拖动操作，电子设备将宿主APP中的应用小部件拖动至预设区域(比如，电子设备的上侧、左侧或右侧区域等)，以移除该应用小部件。

示例性的，图11为本申请实施例提供的删除应用小部件的示例图。如图11中的(a)中的界面1101中显示有日历应用小部件1102，手机检测到用户对日历应用小部件1102的长按操作，响应于长按操作，显示图11中的(b)中的界面1103中的移除控件1104。手机检测到用户对移除控件1104的触发操作(比如，点击操作、双击操作或长按操作等)，响应于触发操作，手机移除界面1103中的日历应用小部件，显示如图11中的(c)中的界面1105。其中，界面1105为移除日历应用小部件后的界面。

上述图中示出的应用小部件仅作为示例性描述，本申请实施例中的应用小部件不限于此，比如，应用小部件还可以为音乐应用小部件或者视频应用小部件等等。本申请实施例中的应用小部件可以以卡片的形式展示内容，也可以以其它形式展示相应的内容，对此也不作限定。

在本申请实施例中，用户可以在应用小部件的宿主APP的用户界面上配置在应用小部件展示的内容，电子设备通过宿主APP将用户配置的应用小部件展示的内容的配置信息存储到应用小部件的内存空间中，当应用小部件被加载至宿主APP后，电子设备可以根据应用小部件的内存空间中存储的配置信息，获取对应的应用小部件的内容，并在宿主APP中显示获取到应用小部件的内容。

在本申请实施例中，宿主APP为电子设备上安装的某一应用程序，例如，宿主APP可以为电子设备安装的系统应用，也可以为电子设备上安装的第三方应用等，本申请实施例中对此不作限定。此外，本申请实施例中当电子设备在某一宿主APP上显示某一应用小部件时，该应用小部件的原生APP可以安装在电子设备上，也可以不安装在电子设备上，本申请实施例中对此也不作限定。

其中，原生APP可以包括对应的应用小部件的内容。例如，日历应用小部件的原生APP为日历。还例如，备忘录应用小部件的原生APP为备忘录。又例如，天气应用小部件的原生APP为天气。

在本申请实施例的一种可能的情况下，电子设备的宿主APP中设置有应用小部件之后，当该应用小部件对应的原生APP的内容更新时，该应用小部件的显示内容也随着原生APP的内容更新而更新。由此，宿主APP中加载了应用小部件后，应用小部件中显示的内容随着原生APP的内容更新，使得用户无需启动原生APP即可从应用小部件确定更新的内容。

示例性的，图10中的(a)中的界面1001中显示有日历应用小部件1002，其中，日历应用小部件1002中显示的当前日期为16日。当电子设备的日历APP显示的日期更新为17日时，日历应用小部件中显示的当前日期也更新为17日。更新后的日历应用小部件如图10中的(d)中的界面1005中显示的日历应用小部件1006，日历应用小部件1006中显示的当前日期为17日。

在本申请实施例中，针对某一应用小部件，该应用小部件的原生APP和该应用小部件的宿主APP可以相同，也可以不同，对此不作限定。例如，日历应用小部件的宿主APP可以为负一屏APP，日历应用小部件的原生APP为日历。还例如，天气应用小部件的宿主APP为桌面APP，天气应用小部件的原生APP为天气。又例如，日历应用小部件的宿主APP和原生APP可以均为日历。

本申请实施例中的应用小部件的内容和宿主APP的内容可以是同一内容提供商提供的，也可以是不同的内容提供商提供的，此处不做限定。例如，当应用小部件和宿主APP由同一厂家开发时，应用小部件的内容和宿主APP的内容可以由同一内容提供商提供。还例如，当应用小部件由厂家A开发，宿主APP由厂家B开发时，应用小部件的内容和宿主APP的内容是由不同的内容提供商提供的。

下面以电子设备为手机为例，结合附图对本申请实施例的界面显示方法进行阐述。

在本申请实施例中，手机显示宿主APP的第一界面的过程中，手机检测到用户的第一操作，在宿主APP加载应用小部件。在宿主APP加载应用小部件的过程中，在宿主APP创建应用小部件的默认布局时，宿主APP可以启动一个新的线程执行获取应用小部件的默认布局对应的布局信息的操作。宿主APP通过该新的线程获取到应用小部件的默认布局对应的布局信息后，手机显示第二界面在宿主APP中显示应用小部件的第一显示页面。其中，第一显示页面可以为应用小部件默认布局对应的显示页面。为了便于描述，后续将宿主APP启动的新的线程称为第一线程。

需要说明的是，上述第一界面可以为手机的主界面，也可以为负一屏，还可以为某一应用的界面等，本申请实施例中对此不作限定。此外，上述第一操作可以为用户对某一宿主APP图标的操作、在主界面上的滑动操作(比如，向左、向右或向上的滑动操作等)、语音指令、或者快捷手势操作等，本申请实施例中对此也不作限定。

例如，当负一屏包括应用小部件时，第一操作可以为用户在主界面上的向右滑动操作。比如，当负一屏为图6中的(b)所示的界面602，界面602中包括健康应用小部件604时，第一操作可以为用户在图6中的(a)中的界面600上向右的滑动操作。再例如，当某一宿主APP的界面包括应用小部件时，第一操作可以为用户对该应用图标的触发操作。比如，日历的界面为如图6中的(c)所示的界面605，包括天气应用小部件606和日程应用小部件607，第一操作可以为用户对桌面上日历图标的触发操作(比如，单击操作或双击操作等)。

上述在手机中宿主APP中显示应用小部件的默认布局的场景，可以为在宿主APP启动过程中加载已经设置在宿主APP中的应用小部件的默认布局的场景，也可以为在宿主APP中首次设置应用小部件时加载应用小部件的默认布局的场景，本申请实施例不做限定。

在一种可能的情况下，当在宿主APP中加载多个应用小部件时，宿主APP可以在首次加载多个应用小部件中任一应用小部件的默认布局时，启动第一线程，以采用该第一线程执行获取多个应用小部件的默认布局的操作。然后，宿主APP采用第一线程继续获取其它应用小部件的待显示的第一内容信息。也就是说，宿主APP可以通过新开启的一个第一线程即可执行获取多个应用小部件的默认布局的操作。

示例性的，当在宿主APP中加载3个应用小部件时，宿主APP可以在创建第一个应用小部件的默认布局时，新启动一个第一线程。然后，宿主APP采用该第一线程执行获取上述3个应用小部件的默认布局的操作。

在另一种可能的情况下，当在宿主APP中加载多个应用小部件时，宿主APP还可以在加载多个应用小部件的默认布局时，分别启动多个应用小部件对应的第一线程，以采用多个第一线程分别执行获取对应的应用小部件的默认布局的操作。也就是说，针对每一个应用小部件，宿主APP启动一个第一线程执行获取该应用小部件的默认布局的操作。

示例性的，当在宿主APP中加载3个应用小部件时，宿主APP可以在创建3个应用小部件的默认布局时，分别启动对应的第一线程。即宿主APP启动3个第一线程分别执行获取对应的应用小部件的默认布局的操作。

在本申请实施例中，在宿主APP中显示应用小部件的默认布局后，宿主APP可以通过主线程获取应用小部件待显示的第一内容信息，或者，宿主APP还可以通过第一线程继续获取应用小部件的待显示的第一内容信息。

在一种可能的方案中，在宿主APP中显示应用小部件的默认布局后，宿主APP可以通过主线程获取应用小部件的待显示的初始视图对应的第一内容信息。在宿主APP通过主线程获取到应用小部件的第一内容信息后，在宿主APP中显示的应用小部件的默认布局中显示该应用小部件的初始视图对应的第二显示页面。

示例性的，图12为本申请实施例提供的宿主APP中加载应用小部件的时序图一。如图12所示，宿主APP的主线程基于应用小部件类调用创建视图函数生成创建应用小部件的宿主视图请求(比如，默认布局对应的视图)。比如，宿主APP的主线程基于AppWidgetHost类调用createView函数创建应用小部件的宿主视图。宿主APP的主线程基于应用小部件类将创建新的宿主视图的请求发送至宿主视图类。然后，宿主APP的主线程基于应用小部件类设置应用小部件的信息，比如，宿主APP的主线程基于AppWidgetHost类调用setAppWidget(widgetid，providerinfo)函数设置应用小部件的标识信息和应用小部件的属性信息。

当宿主APP的主线程可以基于应用小部件类更新应用小部件时，比如，宿主APP的主线程调用基于应用小部件类创建应用小部件的默认布局的函数时，触发宿主APP的主线程启动新的第一线程。比如，当宿主APP的主线程基于AppWidgetHost类调用updateAppWidget函数时，触发宿主APP的主线程启动第一线程。然后，宿主APP的主线程基于宿主视图类向第一线程发送获取默认布局的布局信息的任务。

如图12所示，宿主APP的第一线程接收到获取默认布局的布局信息的任务后，宿主APP的第一线程获取应用小部件的布局信息，并将获取到的布局信息发送至宿主APP的主线程，宿主APP的主线程接收到布局信息后，宿主APP中显示应用小部件的默认布局对应的第一显示页面。比如，第一显示页面可以为图14中的(a)中所示的界面1401中的日历应用小部件1402对应的页面。比如，宿主APP的第一线程基于callback(defaultView)回调函数将布局信息返回至宿主APP的主线程。

此后，宿主APP的主线程基于宿主视图类获取该应用小部件待显示的第一内容信息，以将应用小部件的第一内容信息显示在默认布局中。比如，宿主APP的主线程基于AppWidgetHostView类调用applyContent(defaultView)函数，将应用小部件的第一内容信息加载至默认布局中，以在宿主APP中显示应用小部件的初始视图对应的第二显示页面。其中，应用小部件的第二显示页面中包括应用小部件的第一内容信息。比如，第二显示页面可以为上述图14中的(c)所示的界面1404中的日历应用小部件1405对应的页面。

在宿主APP加载应用小部件的过程中，宿主APP通过第一线程执行加载默认布局的操作的过程中，宿主APP接收到第一任务(比如，宿主APP接收到界面刷新任务)，宿主APP的主线程执行第一任务。其中，第一任务与宿主APP加载应用小部件的任务不同。可见，宿主APP通过第一线程和主线程并行执行加载应用小部件和第一任务，解决了相关技术中宿主APP加载应用小部件的过程中，宿主APP接收到其它任务处理不及时，导致宿主APP的主线程阻塞的现象，避免了宿主APP出现卡顿的现象，提高了宿主APP加载应用小部件的过程中运行的流畅性。

在另一种可能的方案中，在宿主APP中显示应用小部件的默认布局后，宿主APP可以通过第一线程继续获取应用小部件的待显示的第一内容信息。在宿主APP通过第一线程获取到应用小部件的初始视图对应的第一内容信息后，在宿主APP中显示的应用小部件的默认布局中显示该应用小部件的初始视图对应的第二显示页面。由此，宿主APP通过第一线程执行加载应用小部件的任务，避免了宿主APP的主线程执行加载应用小部件的过程中，无法及时执行其它任务，导致宿主APP出现卡顿的现象，提高了宿主APP加载应用小部件的过程中运行的流畅性。

示例性的，图13为本申请实施例提供的宿主APP中加载应用小部件的时序图二。由图12和图13可知，图13中示出的宿主APP中的主线程开始加载应用小部件，至宿主APP的第一线程获取到应用小部件的布局信息的过程，与图12中的执行过程相同，此处不再赘述。图13中宿主APP的第一线程获取到应用小部件的布局信息后，宿主APP的第一线程根据获取到的布局信息，在宿主APP中显示应用小部件的默认布局对应的第一显示页面。然后，宿主APP的第一线程获取应用小部件的第一内容信息，并根据获取到的第一内容信息在宿主APP中显示应用小部件的第二显示页面。比如，宿主APP的第一线程调用applyContent(defaultView)函数，将应用小部件的第一内容信息加载至默认布局对应的第一显示页面中，以在宿主APP中显示应用小部件的初始视图对应的第二显示页面。

示例性的，如图14所示，以宿主APP为桌面APP，应用小部件为日历应用小部件为例，图14中的(a)中显示界面1401，界面1401中显示有桌面APP加载了默认布局的日历应用小部件1402，该默认布局的布局信息是第一线程获取的。在桌面APP加载日历应用小部件初始视图的过程中，手机检测到用户桌面APP中的电话应用图标的触发操作，响应于触发操作，手机可以通过主线程控制显示图14中的(b)所示的界面1403。可以看出，在桌面APP加载日历应用小部件的过程中，由于主线程处理的部分任务已被第一线程代替处理，因此桌面APP的主线程可以及时响应手机的其他任务，提升应用小部件加载过程中手机的流畅性。手机检测到用户指示返回桌面APP的操作，手机显示图14中的(c)所示的界面1404，并且界面1404中显示有日历应用小部件1405。图14中的(c)中显示的日历应用小部件1405中加载了初始视图的内容信息(第一内容信息的一个示例)。日历应用小部件1405中显示的初始视图的内容信息也是第一线程获取的。桌面APP的第一线程执行加载日历应用小部件的整个过程，不影响桌面APP的主线程在应用小部件加载的过程中执行其他任务，使得桌面APP的运行更加流畅。

需要解释的是，在图14中的桌面APP的第一线程获取日历应用小部件的初始视图的过程中，手机检测到用户桌面APP中的电话应用图标的触发操作，桌面APP的主线程执行在桌面APP中显示电话APP的界面的过程。由此，桌面APP的第一线程和主线程并行执行不同的任务，减少了桌面APP运行卡顿的现象，提高了桌面APP运行的流畅度。

在本申请实施例中，在宿主APP加载应用小部件或宿主APP中显示有已经加载完成的应用小部件的过程中，宿主APP可以对应用小部件的显示页面中显示的内容信息进行更新。比如，桌面APP可以实时的对在桌面中显示的时间应用小部件中显示的时间信息进行更新。还比如，桌面APP可以周期性的(如，每隔1分钟、2分钟或3分钟)对桌面中显示的天气应用小部件中显示的天气信息进行更新。再比如，桌面APP可以在预设时间(如，上午9点钟)对桌面中显示的日程应用小部件中显示的日程信息进行更新。

下面以宿主APP加载应用小部件的过程中，宿主APP对应用小部件的内容信息进行更新的为例，对宿主APP对应用小部件进行更新的方案进行详细阐述。

作为本申请实施例的第一种可能的实现方式，在宿主APP的第一线程获取默认布局的布局信息的过程中，宿主APP的主线程接收到更新请求。宿主APP的主线程可以在获取应用小部件的第一内容信息之后，执行更新请求。也就是说，宿主APP的主线程执行获取更新请求，并且宿主APP在显示应用小部件的默认布局对应的第一显示页面(如图14的(a)所示)和初始视图对应的第二显示页面(如图14的(c)所示)之后，显示应用小部件的更新后视图对应的第三显示页面。

示例性的，图15为本申请实施例提供的宿主APP更新应用小部件的时序图一。如图15所示，在宿主APP的主线程基于宿主视图类将获取默认布局的布局信息的任务发送至第一线程之后，在宿主APP的第一线程获取默认布局的布局信息的过程中，应用小部件的广播类向宿主APP的主线程发送更新请求，宿主APP的主线程接收到更新请求后，将更新请求存储到请求队列中。其中，更新请求用于对应用小部件的显示页面中的内容信息进行更新。

比如，在宿主APP的主线程基于AppWidgetHostView将获取默认布局的布局信息的任务发送至第一线程之后，在宿主APP的第一线程获取默认布局的布局信息的过程中，宿主APP的AppWidgetProvider向宿主APP的主线程发送onUpdate，宿主APP的主线程接收到onUpdate后，将onUpdate指示的更新请求对应的请求任务存储到请求队列中。

需要说明的是，在宿主APP的第一线程获取默认布局的布局信息的过程中，若宿主APP的主线程接收到多个更新请求，则宿主APP的主线程根据接收到多个更新请求的顺序，将多个更新请求依次存储至请求队列中。比如，宿主APP的主线程依次接收到3个更新请求，分别为更新请求1、更新请求2和更新请求3。宿主APP的主线程可以将该3个更新请求依次存储至请求队列中。

在宿主APP的第一线程获取到默认布局的布局信息之后，宿主APP的第一线程将默认布局的布局信息发送至宿主APP的主线程。宿主APP的主线程接收到的布局信息，在宿主APP中显示应用小部件的默认布局对应的第一显示页面。宿主APP的主线程获取到应用小部件的初始视图对应的第一内容信息后，宿主APP根据第一内容信息显示初始视图对应的第二显示页面。然后，宿主APP的主线程遍历请求队列，依次执行从请求队列中获取到的每一个更新请求，宿主APP中依次显示主线程执行每一个更新请求后，应用小部件对应的第三显示页面。

需要说明的是，此处仅详细阐述了宿主APP获取应用小部件的默认布局的布局信息的过程中，宿主APP接收到对应用小部件的更新请求后，宿主APP根据更新请求对应用小部件的更新过程，宿主APP基于应用小部件类创建新的宿主视图，以及设置应用小部件的标识信息和属性信息的过程，可以参见上述实施例中对图12和图13的介绍过程，此处不再赘述。同样的，后续实施例中对此部分过程也不再做具体介绍。

示例性的，图16为本申请实施例提供的宿主APP更新应用小部件的示例图一，如图16中的(a)示出的界面1601中显示有笔记应用小部件1602，桌面APP在显示笔记应用小部件的过程中，桌面APP的主线程接收到3个更新请求，桌面APP的主线程将该3个更新请求存储至请求队列中。在桌面APP显示笔记应用小部件的初始视图对应的显示页面(第二显示页面的一个示例)之后，桌面APP的主线程遍历请求队列依次执行请求队列中存储的3更新请求后，手机显示如图16中的(b)所示的界面1603，界面1603中显示有笔记应用小部件1604，并且笔记应用小部件1604中显示有桌面APP的主线程依次执行3个更新请求对应的显示区域1605、显示区域1606和显示区域1607。

由上述可知，宿主APP在显示应用小部件的默认布局的过程中，宿主APP的主线程接收到对应用小部件的更新请求，宿主APP将更新请求按照顺序依次存储至请求队列中。宿主APP在显示应用小部件的初始视图对应的第二显示页面之后，宿主APP的主线程遍历请求队列依次执行更新请求对应的更新任务，宿主APP依次显示更新请求对应的显示页面。由此，宿主APP的主线程接收到更新请求后，将更新请求存储至请求队列中，然后，宿主APP的主线程依次执行请求队列中预先存储的更新请求，避免了宿主APP的主线程接收到的多个更新请求时，未执行所有的更新请求对应的请求任务，导致宿主APP中无法准确的显示更新内容的现象。

示例性的，图17为本申请实施例提供的宿主APP更新应用小部件的示例图二。如图17中的(a)中显示有界面1701，桌面APP显示日历应用小部件1702的过程中，桌面APP的主线程依次接收到对日历应用小部件的2个更新请求，桌面APP的主线程将该2个更新请求依次存储到更新队列中。桌面APP在界面1701显示日历应用小部件1702的默认布局后，显示图17中的(b)所示界面1703，界面1703中显示有日历应用小部件1704。日历应用小部件1704中显示有日历应用小部件的初始视图对应的第二显示页面。然后，桌面APP的主线程遍历更新队列中的更新请求，执行更新请求对应的更新任务，依次显示图17中的(c)和(d)所示的界面1705和界面1707。其中，界面1705中显示有桌面APP的主线程执行第一次存储的更新请求后的日历应用小部件1706。日历应用小部件1706中显示有主线程执行更新请求后对应的第二内容信息的第三显示页面。界面1707中显示有桌面APP的主线程执行第二次存储的更新请求后的日历应用小部件1708。

作为本申请实施例的第二种可能的实现方式，在宿主APP的第一线程获取默认布局的布局信息的过程中，宿主APP的主线程接收到更新请求。宿主APP的主线程可以在获取到默认布局的布局信息之后，直接执行更新请求。也就说，宿主APP在显示应用小部件的默认布局对应的第一显示页面(如图17的(a)所示的日历应用小部件1702的默认布局对应的页面)之后，不显示应用小部件的初始视图对应的第二显示页面(如图17的(b)所示的日历应用小部件1704的初始视图对应的页面)，直接显示应用小部件的更新后视图对应的第三显示页面(如图17中的(c)所示的日历应用小部件1706的更新后视图对应的页面)。

示例性的，图18为本申请实施例提供的宿主APP更新应用小部件的时序图二。如图18所示，在宿主APP的第一线程获取默认布局的布局信息的过程中，应用小部件广播类向宿主APP的主线程发送更新请求，宿主APP的主线程接收到更新请求后，将更新请求存储到请求队列中。比如，在宿主APP的主线程基于AppWidgetHostView将获取默认布局的布局信息的任务发送至第一线程之后，在宿主APP的第一线程获取默认布局的布局信息的过程中，宿主APP的AppWidgetProvider向宿主APP的主线程发送onUpdate，宿主APP的主线程接收到onUpdate后，将onUpdate指示的更新请求对应的请求任务存储到请求队列中。

在宿主APP的第一线程获取到默认布局的布局信息之后，宿主APP的第一线程将默认布局的布局信息发送至宿主APP的主线程。宿主APP的主线程接收到的布局信息，在宿主APP中显示应用小部件的默认布局对应的第一显示页面。然后，宿主APP的主线程遍历请求队列，依次执行从请求队列中获取到的每一个更新请求，宿主APP中依次显示主线程执行每一个更新请求后，应用小部件对应的第三显示页面。

由上述可知，宿主APP在显示应用小部件的默认布局的过程中，宿主APP的主线程接收到对应用小部件的更新请求，宿主APP将更新请求存储至请求队列中。宿主APP在显示应用小部件的默认布局对应的第一显示页面之后，宿主APP的主线程遍历请求队列依次执行更新请求对应的更新任务，宿主APP依次显示更新请求对应的显示页面。由此，宿主APP显示应用小部件的默认布局对应的显示页面之后，直接显示更新后的显示页面，使得用户可以直观的看到更新后的内容，提高了用户的使用体验。

示例性的，图19为本申请实施例提供的宿主APP更新应用小部件的示例图三。如图19中的(a)中显示有界面1901，桌面APP显示日历应用小部件1902的过程中，桌面APP的主线程依次接收到对日历应用小部件的2个更新请求，桌面APP的主线程将该2个更新请求依次存储到更新队列中。桌面APP在界面1901显示日历应用小部件1902的默认布局后，依次显示图19中的(b)所示界面1903和图19中的(c)所述的界面1905。其中，界面1903中显示有桌面APP的主线程执行第一次存储的更新请求后的日历应用小部件1904。界面1905中显示有桌面APP的主线程执行第二次存储的更新请求后的日历应用小部件1906。

作为本申请实施例的第三种可能的实现方式，在宿主APP的第一线程获取默认布局的布局信息的过程中，宿主APP的第一线程接收到更新请求。然后，宿主APP的第一线程将接收到的更新请求存储到请求队列中，宿主APP的第一线程在获取到默认布局的布局信息，将布局信息返回至主线程之后，宿主APP的主线程根据布局信息显示第一显示页面(默认布局对应的页面)和获取应用小部件的第一内容信息。宿主APP的主线程根据第一内容信息显示第二显示页面(初始视图对应的页面)。再后，宿主APP的第一线程从请求队列中获取更新请求并执行更新请求后，宿主APP显示包括更新请求对应的第二内容信息的第三显示页面。

示例性的，图20为本申请实施例提供的宿主APP更新应用小部件的时序图三。如图20所示，在宿主APP的第一线程获取默认布局的布局信息的过程中，应用小部件广播类向宿主APP的第一线程发送更新请求，宿主APP的第一线程接收到更新请求后，将更新请求存储至请求队列中。比如，在宿主APP的第一线程基于AppWidgetHostView将获取默认布局的布局信息的任务发送至第一线程之后，在宿主APP的第一线程获取默认布局的布局信息的过程中，宿主APP的AppWidgetProvider向宿主APP的第一线程发送onUpdate，宿主APP的第一线程接收到onUpdate后，将onUpdate指示的更新请求对应的请求任务存储到请求队列中。

在宿主APP的第一线程获取到默认布局的布局信息之后，宿主APP的第一线程将默认布局的布局信息发送至宿主APP的主线程。宿主APP的主线程接收到的布局信息，在宿主APP中显示应用小部件的默认布局对应的第一显示页面(如图17的(a)所示的日历应用小部件1702的默认布局对应的页面)。宿主APP的主线程根据获取到的第一内容信息显示第二显示页面(如图17中的(b)所示的日历应用小部件1704的初始视图对应的页面)。然后，宿主APP的第一线程遍历请求队列，依次执行从请求队列中获取到的每一个更新请求，宿主APP中依次显示第一线程执行每一个更新请求后，应用小部件对应的第三显示页面(如图17中的(c)所示的日历应用小部件1706的视图对应的页面，以及图17中的(d)所示的日历应用小部件1708的视图对应的页面)。

作为本申请实施例的第四种可能的实现方式，在宿主APP的第一线程获取默认布局的布局信息的过程中，宿主APP的第一线程接收到更新请求。然后，宿主APP的第一线程将接收到的更新请求存储到请求队列中，宿主APP的第一线程在获取到默认布局的布局信息，将布局信息返回至主线程之后，宿主APP的第一线程从请求队列中获取更新请求并执行更新请求，宿主APP直接显示包括更新请求对应的第二内容信息的第三显示页面。

示例性的，图21为本申请实施例提供的宿主APP更新应用小部件的时序图四。如图21所示，在宿主APP的第一线程获取默认布局的布局信息的过程中，应用小部件广播类向宿主APP的第一线程发送更新请求，宿主APP的第一线程接收到更新请求后，将更新请求存储到请求队列中。比如，在宿主APP的第一线程基于AppWidgetHostView将获取默认布局的布局信息的任务发送至第一线程之后，在宿主APP的第一线程获取默认布局的布局信息的过程中，宿主APP的AppWidgetProvider向宿主APP的第一线程发送onUpdate，宿主APP的第一线程接收到onUpdate后，将onUpdate指示的更新请求对应的请求任务存储到请求队列中。

如图21所示，在宿主APP的第一线程获取到默认布局的布局信息之后，宿主APP的第一线程将默认布局的布局信息发送至宿主APP的主线程之后，宿主APP的第一线程遍历请求队列，依次执行从请求队列中获取到的每一个更新请求，宿主APP中依次显示第一线程执行每一个更新请求后，应用小部件对应的第三显示页面(如图19中的(b)所示的日历应用小部件1904对应的页面，以及图19中的(c)所示的日历应用小部件1906对应的页面)。

作为本申请实施例的第五种可能的实现方式，在宿主APP的第一线程获取默认布局的布局信息的过程中，宿主APP的第一线程接收到更新请求。宿主APP的第一线程将接收到的更新请求存储至请求队列中，在宿主APP的第一线程在获取到默认布局的布局信息和应用小部件的第一显示内容之后，宿主APP的第一线程执行更新请求，宿主APP显示包括更新请求对应的第二内容信息的第三显示页面。由此可见，宿主APP的第一线程执行获取应用小部件的默认布局和初始视图对应的信息，以及执行更新请求对应的任务，宿主APP的主线程和第一线程并行执行对应的任务，避免了宿主APP中加载应用小部件的过程中，宿主APP的主线程出现阻塞导致宿主APP反应迟缓的问题。

示例性的，图22为本申请实施例提供的宿主APP更新应用小部件的时序图五。如图22所示，在宿主APP的第一线程获取默认布局的布局信息的过程中，应用小部件广播类向宿主APP的第一线程发送更新请求，宿主APP的第一线程接收到更新请求后，将更新请求存储到请求队列中。比如，在宿主APP的第一线程基于AppWidgetHostView将获取默认布局的布局信息的任务发送至第一线程之后，在宿主APP的第一线程获取默认布局的布局信息的过程中，宿主APP的AppWidgetProvider向宿主APP的第一线程发送onUpdate，宿主APP的第一线程接收到onUpdate后，将onUpdate指示的更新请求对应的请求任务存储到请求队列中。

如图22所示，在宿主APP的第一线程获取到默认布局的布局信息之后，宿主APP的第一线程根据布局信息加载应用小部件的默认布局，以在宿主APP中显示默认布局对应的第一显示页面(如图17的(a)所示的日历应用小部件1702的默认布局对应的页面)。然后，宿主APP的第一线程获取应用小部件的第一内容信息后，宿主APP的第一线程根据第一内容信息加载应用小部件的初始视图，以在宿主APP中显示应用小部件的初始视图对应的第二显示页面(如图17中的(b)所示的日历应用小部件1704的初始视图对应的页面)。此后，宿主APP的第一线程遍历请求队列，依次执行从请求队列中获取到的每一个更新请求，宿主APP中依次显示第一线程执行每一个更新请求后，应用小部件对应的第三显示页面(如图17中的(c)所示的日历应用小部件1706的视图对应的页面，以及图17中的(d)所示的日历应用小部件1708的视图对应的页面)。

作为本申请实施例的第六种可能的实现方式，在宿主APP的第一线程获取默认布局的布局信息的过程中，宿主APP的第一线程接收到更新请求。宿主APP的第一线程将接收到的更新请求存储至请求队列中，在宿主APP的第一线程获取到默认布局的布局信息之后，宿主APP的第一线程执行更新请求。由此，宿主APP显示应用小部件的整个过程是由第一线程执行的，宿主APP的主线程可以执行其它任务，避免了宿主APP加载应用小部件时出现卡顿的现象。此外，宿主APP的第一线程根据布局信息加载应用小部件的默认布局之后，直接执行更新请求，使得宿主APP在显示应用小部件的默认布局之后直接显示更新后的视图，提高了更新后视图的显示效率。

示例性的，图23为本申请实施例提供的宿主APP更新应用小部件的时序图六。如图23所示，在宿主APP的第一线程获取默认布局的布局信息的过程中，应用小部件广播类向宿主APP的第一线程发送更新请求，宿主APP的第一线程接收到更新请求后，将更新请求存储到请求队列中。在宿主APP的第一线程获取到默认布局的布局信息之后，宿主APP的第一线程根据布局信息加载应用小部件的默认布局，以在宿主APP中显示默认布局对应的第一显示页面。然后，宿主APP的第一线程遍历请求队列，依次执行从请求队列中获取到的每一个更新请求，宿主APP中依次显示第一线程执行每一个更新请求后，应用小部件对应的第三显示页面。

继续如图19中的(a)所示，在桌面APP的第一线程执行根据日历应用小部件的布局信息显示默认布局之后，手机的界面1901中显示日历应用小部件1902。桌面APP的第一线程遍历请求队列并依次执行获取到2个更新请求后，手机依次显示图19中的(b)所示的界面1903和图19中的(c)所示的界面1905。其中，界面1903中显示有桌面APP的第一线程执行第一次存储的更新请求后的日历应用小部件1904。界面1905中显示有桌面APP的第一线程执行第二次存储的更新请求后的日历应用小部件1906。

在本申请实施例中，在宿主APP中显示有应用小部件的过程中，宿主APP的主线程可以调用删除函数，以将应用小部件从宿主APP内删除。比如，在手机的桌面APP中显示有日历应用小部件，桌面APP的主线程可以调用onDeleted函数，以删除桌面APP中的日历应用小部件。

可以理解的是，当宿主APP中显示有多个应用小部件时，如果有多个应用小部件从宿主APP内被删除，宿主APP的主线程可以调用多次删除函数。比如，桌面APP的主线程可以调用3次onDeleted函数，以删除桌面APP中显示的日历应用小部件、天气应用小部件和音乐应用小部件。

在本申请实施例中，当手机检测到用户对桌面APP中至少一个应用小部件的删除操作后，响应于删除操作，桌面APP删除至少一个应用小部件。示例性的，图24为本申请实施例提供的一种删除应用小部件的示例图。如图24中的(a)的手机中显示有界面2400，界面2400中显示有日历应用小部件2401、天气应用小部件2402和健康应用小部件2403。手机检测到用户对桌面中显示的任意一个应用小部件的触发操作(比如，长按操作)，响应于触发操作，手机显示图24中(b)所示的界面2404。界面2404中显示的日历应用小部件2401、天气应用小部件2402和健康应用小部件2403处于待选择状态。手机检测到用户对任一应用小部件的选中操作(比如，单击操作或触摸操作等)，响应于用户对至少一个应用小部件的选中操作后，手机中至少一个应用小部件处于选中状态。

比如，图24中的(b)所示的日历应用小部件和天气应用小部件处于选中状态。然后，手机检测到用户对界面2404中显示的删除控件的触发操作后，桌面APP响应于触发操作，删除界面2404中显示的日历应用小部件和天气应用小部件，显示如图24中的(c)所示的界面2405，其中，界面2405中显示有健康应用小部件。

可以理解的是，上述图24中的示例中介绍的是手机响应于用户对多个应用小部件的选中操作，批量删除多个应用小部件的方法，此外，手机还可以响应于用户对一个应用小部件的删除操作，依次删除多个应用小部件。比如，仍如上述图11所示，手机检测到用户对应用小部件的触发操作(比如，长按操作)，响应于触发操作，手机桌面显示移除控件，响应于用户对移除控件的触发操作，删除桌面APP中显示的应用小部件。

如图25所示，本申请实施例公开了一种电子设备，该电子设备可以为上述手机。该电子设备具体可以包括：触摸屏2501，所述触摸屏2501包括触摸传感器2506和显示屏2507；一个或多个处理器2502；存储器2503；一个或多个应用程序(未示出)；以及一个或多个计算机程序2504，上述各器件可以通过一个或多个通信总线2505连接。其中，上述一个或多个计算机程序2504被存储在上述存储器2503中并被配置为被该一个或多个处理器2502执行，该一个或多个计算机程序2504包括指令，该指令可以用于执行上述实施例中的相关步骤。

可以理解的是，上述电子设备等为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明实施例的范围。

本申请实施例可以根据上述方法示例对上述电子设备等进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，上述实施例中涉及的电子设备的一种可能的组成示意图，该电子设备可以包括：显示单元、传输单元和处理单元等。需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

本申请实施例还提供一种电子设备，包括一个或多个处理器以及一个或多个存储器。该一个或多个存储器与一个或多个处理器耦合，一个或多个存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，使得电子设备执行上述相关方法步骤实现上述实施例中的界面显示方法。

本申请的实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的界面显示方法。

本申请的实施例还提供了一种计算机程序产品，该计算机程序产品包括计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的界面显示方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使装置执行上述各方法实施例中电子设备执行的界面显示方法。

其中，本实施例提供的电子设备、计算机可读存储介质、计算机程序产品或装置均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

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

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

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

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

Claims (14)

1.一种界面显示方法，其特征在于，包括：

电子设备显示第一界面；

所述电子设备检测到用户的第一操作，所述第一操作用于控制所述电子设备显示第二界面，所述第二界面包括应用小部件；

所述电子设备基于宿主应用程序APP的第一线程获取所述应用小部件的布局信息，所述第一线程与所述宿主APP的主线程不同；

所述电子设备显示所述第二界面，所述第二界面包括所述应用小部件的第一显示页面，所述第一显示页面是基于所述布局信息显示的。

2.根据权利要求1所述的方法，其特征在于，所述电子设备基于宿主应用程序APP的第一线程获取所述应用小部件的布局信息之前，所述方法还包括：

所述电子设备通过所述宿主APP启动所述第一线程。

3.根据权利要求1或2所述的方法，其特征在于，所述电子设备显示所述第二界面之后，所述方法还包括：

所述电子设备基于所述宿主APP获取所述应用小部件的第一内容信息；

所述电子设备显示第三界面，所述第三界面包括所述应用小部件的第二显示页面，所述第二显示页面中显示有所述第一内容信息。

4.根据权利要求3所述的方法，其特征在于，所述第一内容信息是所述宿主APP的第一线程获取到的；

所述电子设备显示第三界面，包括：

所述电子设备基于所述宿主APP的第一线程将所述第一内容信息发送至所述宿主APP的主线程；

所述电子设备基于所述宿主APP的所述主线程接收到的所述第一内容信息，显示所述第三界面。

5.根据权利要求3所述的方法，其特征在于，所述电子设备显示第三界面，包括：

所述电子设备基于所述宿主APP的所述第一线程或所述主线程获取到的所述第一内容信息，显示所述第三界面。

6.根据权利要求3至5任一项所述的方法，其特征在于，所述电子设备显示第三界面之前，所述方法还包括：

所述电子设备确定所述宿主APP的主线程接收到至少一个更新请求后，所述宿主APP的主线程将所述至少一个更新请求存储至请求队列，所述更新请求用于指示更新所述应用小部件中的内容信息；

所述电子设备显示第三界面之后，所述方法还包括：

所述电子设备基于所述宿主APP的主线程从所述请求队列中获取到更新请求，显示第四界面，所述第四界面中包括所述应用小部件的第三显示页面，所述第三显示页面中显示有所述更新请求对应的第二内容信息。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述电子设备显示所述第二界面之前，所述方法还包括：

所述电子设备确定所述宿主APP的主线程接收到至少一个更新请求后，所述宿主APP的主线程将所述至少一个更新请求存储至请求队列，所述更新请求用于指示更新所述应用小部件中的内容信息；

所述电子设备显示所述第二界面之后，所述方法还包括：

所述电子设备基于所述宿主应用APP的主线程从所述请求队列中获取到更新请求；

所述电子设备基于所述宿主APP的主线程从所述请求队列中获取的更新请求，显示第四界面。

8.根据权利要求6或7所述的方法，其特征在于，所述电子设备基于所述宿主应用APP的主线程从所述请求队列中获取到更新请求，包括：

所述电子设备基于所述宿主APP的主线程根据所述至少一个更新请求存储至请求队列的存储顺序，从所述请求队列中依次获取到所述更新请求。

9.根据权利要求3-8任一项所述的方法，其特征在于，所述电子设备显示第三界面之前，所述方法还包括：

所述电子设备确定所述宿主APP的第一线程接收到至少一个更新请求后，所述宿主APP的第一线程将所述至少一个更新请求存储至请求队列，所述更新请求用于指示更新所述应用小部件中的内容信息；

所述电子设备显示第三界面之后，所述方法还包括：

所述电子设备基于所述宿主APP的第一线程从所述请求队列中获取到更新请求，显示第四界面，所述第四界面中包括所述应用小部件的第三显示页面。

10.根据权利要求1-9任一项所述的方法，其特征在于，所述电子设备显示所述第二界面之前，所述方法还包括：

所述电子设备确定所述宿主APP的第一线程接收到至少一个更新请求后，所述宿主APP的第一线程将所述至少一个更新请求存储至请求队列，所述更新请求用于指示更新所述应用小部件中的内容信息；

所述电子设备显示所述第二界面之后，所述方法还包括：

所述电子设备基于所述宿主APP的第一线程从所述请求队列中获取到更新请求，显示第四界面。

11.根据权利要求9或10所述的方法，其特征在于，所述电子设备基于所述宿主APP的第一线程从所述请求队列中获取到更新请求，包括：

所述电子设备基于所述宿主APP的第一线程根据所述至少一个更新请求存储至请求队列的存储顺序，从所述请求队列中依次获取到所述更新请求。

12.根据权利要求1-11任一项所述的方法，其特征在于，所述电子设备显示第三界面之前，所述方法还包括：

所述电子设备的所述宿主APP接收第一任务，所述第一任务与所述宿主APP加载所述应用小部件的任务不同；

所述电子设备基于所述宿主APP的主线程执行所述第一任务。

13.一种电子设备，其特征在于，包括：

触摸屏，触摸屏包括触摸传感器和显示屏；

一个或多个处理器；

存储器；

其中，所述存储器中存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述电子设备执行时，使得所述电子设备执行如权利要求1-12中任一项所述的界面显示方法。

14.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求1-12中任一项所述的界面显示方法。