CN116932102A - 电子设备及其应用显示方法和介质 - Google Patents

Abstract

本申请涉及操作系统领域，涉及一种电子设备及其应用显示方法和介质，该应用显示方法包括：电子设备运行有第一系统和第二系统，第二系统从第一系统接收到多个应用窗口的显示数据和每个显示数据的数据标识，第二系统根据每个显示数据对应的应用窗口的窗口标识，将每个显示数据发送至与每个显示数据对应的应用窗口的渲染任务分别进行渲染，得到每个显示数据的渲染图像；在电子设备的屏幕上，将每个显示数据的渲染图像显示在每个显示数据各自对应的应用窗口中。本申请实施例的方法，第一系统将多个窗口的显示数据发送给第二系统进行渲染并显示，第一系统各个窗口的显示帧率相互独立，其中一个窗口的延迟不会影响其他的窗口显示帧率，提高了用户体验。

Description

电子设备及其应用显示方法和介质

技术领域

本申请涉及操作系统领域的虚拟化技术。尤其涉及一种电子设备及其应用显示方法和介质。

背景技术

在Linux与Android双系统融合的技术领域中，电子设备可以将Android系统作为主系统，将Linux系统作为辅系统，例如，在安装了Android系统的电子设备上，通过虚拟化(虚拟机或者容器)的方式运行Linux系统，用户可以启动Linux侧的应用并在电子设备的屏幕中显示应用的窗口。在这种情况下，Linux侧中安装的应用的窗口需要通过Android侧的系统服务(渲染服务)来进行渲染，并显示在电子设备的屏幕中。

在上述技术方案中，在运行Linux侧的多个应用时，会产生多个应用的窗口，这些窗口的显示数据都需要从Linux侧发送到Android侧，通过Android侧的渲染服务渲染应用的窗口并显示。其中，Android侧的渲染服务只能同时渲染处理Linux侧发送的一个应用的窗口的显示数据，也就是说，在Android侧渲染处理一个应用的窗口的显示数据时，Linux侧生成的其他的窗口的显示数据需要排队等待。在Linux侧的应用窗口较多且部分窗口的显示数据较大的情况下，Android侧对显示数据较大的应用的窗口进行渲染的过程会产生较高的延迟，这样会阻塞Android侧渲染其他Linux侧的应用的窗口，造成Linux侧的其他应用的窗口显示也产生延迟，降低用户体验。

发明内容

本申请的目的在于提供一种电子设备及其应用显示方法和介质。

本申请的第一方面提供了一种应用显示方法，应用于电子设备，其特征在于，电子设备运行有第一系统和第二系统，并且

方法包括：

第二系统从第一系统接收到多个应用窗口的显示数据和每个显示数据的数据标识，其中，第一显示数据的第一数据标识包括用于标识第一显示数据所属应用窗口的窗口标识，第一显示数据的第一数据标识为每个显示数据的数据标识中的任意一个显示数据的数据标识；

第二系统根据每个显示数据对应的窗口标识，将每个显示数据发送至与每个显示数据对应的应用窗口的渲染任务分别进行渲染，得到每个显示数据的渲染图像；

第二系统在电子设备的屏幕上，将得到的每个显示数据的渲染图像显示在每个显示数据各自对应的应用窗口中。

即在本申请的实施例中，这里的电子设备可以是手机、平板电脑等智能设备，第一系统可以是Linux系统，第二系统可以是Android系统，第二系统为运行在电子设备的主系统，第一系统为运行在第二系统的从系统。也就是说，第一系统可以通过虚拟机或者容器的方式运行在电子设备的第二系统。这里的多个应用窗口可以是运行在第一系统上的一个应用对应的多个应用窗口或者是多个应用对应的多个应用窗口。这里的数据标识可以包括窗口标识和数据标识，其中窗口标识可以是显示数据对应的应用窗口的窗口标号和数据标识可以是显示数据对应的帧标号，并且每个应用窗口对应的窗口标识是唯一的，每个应用窗口的显示数据对应的帧标号可以彼此独立，可以通过窗口标识结合数据标识唯一确定一个应用窗口的显示数据。这里的渲染任务可以是第二系统可以根据每个显示数据的窗口标识建立的窗口处理线程，用于将显示数据渲染(也就是，显示处理或者绘制)成应用窗口的显示内容。每个应用窗口对应的渲染任务可以相互独立同时运行；第二系统将渲染完成的应用窗口的显示内容显示在电子设备的屏幕中。

本申请实施例的方法，在第一系统启动了多应用多窗口的场景下，第一系统可以将各个窗口的显示数据发送给第二系统进行渲染并显示，第一系统可以同时接收并处理各个窗口的响应消息，使得第一系统各个窗口的显示帧率相互独立，即使其中一个窗口的显示数据较大，第二系统对该窗口的渲染处理缓慢，也只会造成该窗口的画面卡顿，而不会影响其他的窗口显示帧率，提高了用户体验。

在上述第一方面的一种可能的实现中，第一数据标识还包括显示数据序号，显示数据序号用于表示第一显示数据在同一应用窗口的多个显示数据中的渲染顺序。

即在本申请的实施例中，这里的显示数据序号也就是数据标识的数值(帧标号的数值)。数据标识的数值是递增的，可以通过显示数据序号确定显示数据的渲染顺序，确保第一系统的应用的窗口的显示数据的连续性。

在上述第一方面的一种可能的实现中，多个应用窗口包括第一应用窗口，第一显示数据为第一应用窗口的显示数据；

方法还包括：

第二系统在完成对第一显示数据的渲染后，向第一系统返回第一显示数据的第一响应消息和第一数据标识；

第一系统根据接收到的第一响应消息、第一数据标识中的第一窗口标识，从生成的显示数据中选择出第一应用窗口的显示数据，并根据第一数据标识中的第一显示数据序号，从选择出的第一应用窗口的显示数据中选择出在第一显示数据之后需要渲染的第二显示数据；

第一系统向第二系统发送第二显示数据和第二显示数据的第二数据标识，其中第二数据标识包括第一窗口标识和第二显示数据序号。

即在本申请的实施例中，这里的第一显示数据和第二显示数据可以是第一系统先后生成的第一应用窗口的显示数据。第一显示数据和第二显示数据可以通过第一显示数据序号和第一显示数据序号来区分。例如，第一应用窗口的窗口标识可以是w_id，对应的第一显示数据和第二显示数据的第一显示数据序号和第一显示数据序号可以分别是f_id＝1和f_id＝2，这里的第一显示数据序号和第一显示数据序号是依次递增的，用于表示第一显示数据和第二显示数据是第一系统先后生成的。第一响应消息可以与第一显示数据的第一数据标识对应，用于第一系统确定已经发送并完成渲染的第一显示数据。

在上述第一方面的一种可能的实现中，渲染任务为第二系统建立的线程任务，其中，每个应用窗口对应一个渲染任务。

即在本申请的实施例中，这里的渲染任务可以是第一系统的显示服务对应的处理线程，渲染任务可以与应用窗口的窗口标识对应。例如，每一个渲染任务可以通过应用窗口的窗口标识(窗口标号w_id)进行唯一标识。

在上述第一方面的一种可能的实现中，多个应用窗口还包括第二应用窗口，多个应用窗口的显示数据还包括第二应用窗口的第三显示数据，并且

第一显示数据和第三显示数据的数据量不同，第二系统渲染第一显示数据和渲染第三显示数据的时间不同。

即在本申请的实施例中，这里的第二应用窗口与第一应用窗口可以是同一个应用的窗口，也可以是不同应用的窗口。这里的第一显示数据和第三显示数据的数据量不同可以是指相较于第二显示数据，第三显示数据较大，使得第二系统渲染第三显示数据的时间会比渲染第一显示数据的时间长。

在上述第一方面的一种可能的实现中，在电子设备的屏幕上，第一应用窗口和第二应用窗口的渲染图像的显示帧率不同，其中，显示帧率用于表示每单位时间内应用窗口刷新渲染图像的数量。

即在本申请的实施例中，由于第二系统渲染第三显示数据的时间会比渲染第一显示数据的时间长，使得电子设备的屏幕上，第二应用窗口的渲染图像的显示帧率会小于第一应用窗口的渲染图像的显示帧率，也就是说，第二应用窗口的显示内容会产生延迟。

在上述第一方面的一种可能的实现中，第一系统包括Linux系统，第二系统包括Android系统，第二系统为运行在电子设备的主系统，第一系统为运行在第二系统的从系统。

在上述第一方面的一种可能的实现中，多个应用窗口包括第一系统上的同一应用或者不同应用的窗口。

即在本申请的实施例中，上述第一应用窗口和第二应用窗口可以是第一系统上运行的同一应用或者不同应用的窗口。

本申请的第二方面提供了一种电子设备，包括：

处理器；以及

存储器，可以与处理器耦合或者解耦用于存储由处理器执行的指令；

指令被处理器执行时，使得电子设备执行前述第一方面提供的方法。

本申请的第三方面提供了一种计算机可读存储介质，计算机可读存储介质中包含有指令，当指令被电子设备执行时使电子设备实现前述第一方面提供的方法。

附图说明

图1根据本申请的实施例示出了一种电子设备显示应用的窗口的场景示意图；

图2根据本申请的实施例示出了一种电子设备的Linux显示服务和Android显示代理之间传输应用的窗口的显示数据的流程示意图；

图3a、图3b和图3c根据本申请的实施例示出了一种电子设备的Linux侧和Android侧生成渲染应用的显示数据的示意图；

图4根据本申请的实施例示出了一种电子设备的应用显示方法的场景示意图；

图5根据本申请的实施例示出了一种电子设备的硬件结构示意图；

图6根据本申请的实施例示出了一种电子设备的应用显示方法的流程示意图；

图7根据本申请的实施例示出了一种电子设备的Linux侧向Android侧发送应用的窗口的显示数据的流程示意图；

图8根据本申请的实施例示出了一种电子设备的Android侧从Linux侧接收并渲染窗口的显示数据的流程示意图；

图9根据本申请的实施例示出了一种电子设备的Linux侧从Android侧接收响应消息的流程示意图；

图10根据本申请的实施例示出了一种电子设备显示应用的窗口的场景示意图。

具体实施方式

本申请的实施例包括但不限于一种电子设备及其应用显示方法和介质。为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请的实施方式作进一步地详细描述。

如前所述，目前在Linux与Android双系统融合技术中，在Android侧对显示数据较大的应用的窗口进行渲染的过程会产生较高的延迟，这样会阻塞Android侧渲染其他Linux侧的应用的窗口，造成Linux侧的其他应用的窗口显示也产生延迟。

可以理解，这里的渲染可以包括：Linux侧向Android侧发送应用的窗口的显示数据，Android侧从Linux侧获取了应用的窗口的显示数据后，对显示数据进行显示处理，也就是对显示数据进行绘制，生成应用的窗口的显示内容。渲染的过程也可以称为送显的过程。

例如，图1示出了一种电子设备显示应用的窗口的场景示意图。具体地，这里的电子设备100的主系统是Android系统，电子设备100将运行在Android系统上的Linux系统的应用的窗口显示在电子设备100的屏幕，在图1所示的场景中，Linux侧生成多个应用的窗口(如图1中的窗口1至窗口N)。其中，对于Linux侧生成的某一应用的窗口，如窗口1，对应于该应用显示内容的变化，Linux侧会对应每次变化生成一组显示数据，而Android系统会在接收到每组显示数据后，对应每组显示数据渲染成一帧图像显示在该应用的窗口1中。即如果Linux侧生成对于该应用的新的显示数据，Android系统收到后会将新的显示数据渲染成对应的图像，然后更新窗口1中的显示内容为最新渲染的图像。

Linux侧可以通过Linux显示服务将其中一个窗口的显示数据发送给Android侧的Android显示代理，Android显示代理可以将窗口的显示数据发送给Android侧的渲染服务，渲染服务可以对窗口的显示数据进行渲染并显示。在Android侧的渲染服务完成渲染后，Android显示代理可以向Linux侧回复完成渲染的响应消息。在Linux侧收到响应消息后，Linux侧可以通过Linux显示服务继续向Android侧的Android显示代理发送下一个窗口的显示数据。这里的Linux显示服务和Android显示代理可以是运行在Linux侧和Android侧的软件模块。

可以理解，在一些实施例中，Linux侧不会对显示数据所对应的应用的窗口做区分，仅仅按照显示数据的生成顺序向Android侧依次进行发送。例如，在第一送显周期生成了对应窗口1的显示数据1，则发送显示数据1，在第二送显周期生成了对应窗口3的显示数据2，则发送显示数据2。如此，Android侧的渲染服务也只能一次接收一组显示数据，并在同一送显周期仅渲染处理Linux侧发送的一组显示数据，而无法同时并行处理多个应用的窗口的多组显示数据。

可以理解，在Linux侧向Android侧发送应用的窗口的显示数据时，同时会生成并发送一组显示数据对应的帧标号(frame_id下文简称为f_id)，帧标号用于唯一标识显示数据，在Linux从Android侧接收渲染完成的显示数据的响应消息时，也会接收到显示数据对应的帧标号，使得Linux侧可以确定已发送的应用的窗口的上一组显示数据渲染完成，可以接着向Android侧发送应用的窗口的下一组显示数据，这里的帧标号的数值是递增的，确保Linux侧发送的应用的窗口的显示数据的连续性。但是，帧标号只是与显示数据对应，并不会区分显示数据对应的应用的窗口。

下面通过图2对图1所示的场景示意图进行说明，图2示出了一种电子设备的Linux显示服务和Android显示代理之间传输应用的窗口的显示数据的流程示意图，具体地，图2所示的流程包括：

S201：Linux侧生成应用的窗口的显示数据。

这里的显示数据可以是电子设备100的Linux侧的应用的窗口中的文字、图像以及各种组件(如：按钮，输入框，下拉框等)。

S202：Linux显示服务判断是否满足送显条件。

如果Linux显示服务确定满足送显条件，则执行步骤S203；如果不满足，则继续执行步骤S202，Linux显示服务等待直至满足送显条件。

例如，这里的送显条件可以包括：Linux侧的应用的窗口的显示数据发生变化、电子设备100的主系统(Android系统)到达下一个送显周期以及Android系统的渲染服务已经渲染完成前一次发送的应用的窗口的显示数据等。

可以理解，送显周期可以用电子设备100的屏幕刷新率(Frames Per Second,FPS)来表示，也就是屏幕每秒钟更新画面的次数。例如，电子设备100的屏幕的刷新频率为30帧每秒，电子设备100的屏幕每33毫秒(1000/30＝33)刷新一次屏幕中的应用的窗口，也就是说，电子设备100可以每33毫秒获取一次应用的窗口的显示数据，并将显示数据渲染成图像帧后在屏幕中显示。也就是说，送显周期可以表示为电子设备100的Android侧从Linux侧获取应用的窗口的显示数据到Android侧根据显示数据渲染完成应用的窗口并显示的过程。

S203：Linux显示服务将显示数据送显。

例如，如图3a所示，在第一个送显周期内，电子设备100的Linux侧可以生成应用的窗口的第一图像帧的显示数据；在第二个送显周期内，Linux侧将第一图像帧的显示数据发送给Android侧。也就是，Linux显示服务在获取了Linux侧的应用的窗口的显示数据后，将显示数据发送给Android侧的Android显示代理。

这里的Linux显示服务在获取了第一图像帧的显示数据时，可以对第一图像帧的显示数据设置第一图像帧的帧标号(f_id)，在向Android显示代理发送第一图像帧的显示数据时，还可以同时发送第一图像帧的帧标号(f_id)。这里的帧标号用于唯一标识Linux侧向Android侧发送的应用的窗口的显示数据，也就是唯一标识Android侧的渲染服务当前正在渲染的显示数据对应的图像帧的帧标号，一组显示数据可以对应一个当前帧标号。

Android显示代理在接收到Linux侧的应用的窗口的显示数据后，将显示数据发送给Android侧的渲染服务。

S204：Android侧的渲染服务处理显示数据。

Android侧的渲染服务根据第一图像帧的显示数据渲染完成Linux侧的应用的窗口的第一图像帧并显示第一图像帧。

可以理解，Android侧的渲染服务可以根据接收到的显示数据依次渲染显示数据生成图像帧。也就是说，Android侧的渲染服务只能同时渲染处理Linux侧发送的一个图像帧的显示数据。

S205：Android侧的渲染服务处理完成显示数据后，通过Android显示代理回复响应消息。

在Android侧的渲染服务渲染完成应用的窗口的第一图像帧并显示后，也就是在第二个送显周期内，Android显示代理将Android侧的渲染服务的响应消息通过Linux显示服务向Linux侧回复。Android显示代理在通过Linux显示服务向Linux侧回复响应消息的同时，Android显示代理可以将渲染完成的第一图像帧的帧标号(f_id1)一起回复给Linux侧，通知Linux侧应用的窗口的第一图像帧已经渲染完成并显示。

可以理解，继续参考图3a，Linux侧还可以在第二个送显周期内继续生成应用的窗口的第二图像帧的显示数据。以此类推，在Linux侧收到Android侧的响应消息以及应用的窗口的第一图像帧的帧标号(f_id1)后，在第三个送显周期内，在Linux侧确认收到Android侧的响应消息以及第一图像帧的帧标号后，Linux侧可以向Android侧发送显示应用的窗口的第二图像帧的显示数据以及第二图像帧的帧标号(f_id2)，Android侧可以渲染并显示应用的窗口的第二图像帧，同时，Linux侧可以生成应用的窗口的第三图像帧(f_id3)的显示数据。可以看出，这里的图像帧的帧标号的数值可以是依次递增的，也就是说，Linux侧需要等待前一个图像帧的显示数据被Android侧渲染完成后，才能向Android侧发送下一个图像帧的显示数据。

可以理解，这里的依次递增的图像帧的帧标号也可以表示Android侧渲染图像帧的渲染顺序。也就是，Android侧依次渲染第一图像帧(f_id1)，第二图像帧(f_id2)和第三图像帧(f_id3)。

在本申请实施例中，如果Linux侧一发送的应用的窗口的一个图像帧的显示数据较大，导致Android侧的渲染服务无法在一个送显周期内渲染完成应用的窗口的显示数据并显示，Linux侧无法及时收到已发送的应用的窗口的显示数据的响应消息以及显示数据对应的帧标号，也就是，即使Linux侧生成了应用的窗口的下一个图像帧的显示数据，也无法在下一个显示周期发送给Android侧，则电子设备100的屏幕中该应用的窗口的显示帧率会降低，应用的窗口会出现卡顿。

例如，如图3b所示，Linux侧启动了应用1和应用2，应用1和应用2分别对应窗口1和窗口2。在第一个送显周期内，电子设备100的Linux侧可以生成窗口1的第一图像帧的显示数据；在第二个送显周期内，Linux侧将窗口1的第一图像帧的显示数据以及显示数据的帧标号(f_id1)发送给Android侧，同时，Linux侧生成窗口2的第一图像帧的显示数据(f_id2)。继续参考图3b，由于窗口1的第一图像帧的显示数据较大，直到第三个送显周期，Android侧的渲染服务才渲染完成应用的窗口1的第一图像帧，并响应消息以及帧标号(f_id1)通过Linux显示服务向Linux侧回复。导致了Linux侧生成的窗口2的第一图像帧的显示数据只能在第四个送显周期内发送给Android侧进行渲染并显示，进而，Linux侧生成的窗口1的第二图像帧的显示数据(f_id3)和窗口2的第二图像帧的显示数据(f_id4)也必须等待Android侧渲染完成窗口2的第一图像帧的显示数据(f_id2)。也就是说，即使在第二个送显周期内，Linux侧生成了窗口2的第一图像帧的显示数据，Linux侧也无法在第三个送显周期将窗口2的第一图像帧的显示数据发送给Android侧进行渲染并显示。也就是说，电子设备100的屏幕中窗口1和窗口2的显示帧率都会降低，造成窗口1和窗口2的显示内容同时会出现卡顿。

可以看出，如果Linux侧启动了多个应用，在电子设备100的屏幕中显示多个应用的窗口，则Linux侧会生成多个应用的窗口的显示数据，Linux侧也会对每一组显示数据对应的图像帧设置一个帧标号，多个应用的窗口的显示数据对应的图像帧的帧标号的数值也是依次递增的。在Linux侧将其中一个应用的窗口的显示数据发送给Android侧进行渲染时，Linux侧也需要等待已发送的应用的窗口的显示数据被Android侧处理完毕后，才能向Android侧发送下一个窗口的显示数据。

如果其中一个应用的窗口的显示数据较大，会导致每次发送的该应用的窗口的显示数据的处理时间较长，除了使得该应用的窗口出现画面卡顿，还会导致Android侧无法及时向Linux侧发送其他应用的窗口的显示数据，影响Android侧处理其他应用的窗口的显示数据，最终降低Linux侧启动的所有应用的窗口的显示帧率，导致电子设备100的屏幕中所有的应用的窗口都出现画面卡顿。

为了解决在Linux与Android的双系统的电子设备中，Linux侧启动多个应用，其中一个应用的窗口的显示数据过多，使得Android侧处理该应用的窗口的显示数据产生延迟，导致电子设备的屏幕中所有的应用的窗口都出现画面卡顿的问题，本申请实施例提供了一种电子设备的应用显示方法。具体地，在本申请实施例提供的应用显示方法包括：

对Linux侧启动的应用的每个窗口设置标识各窗口的窗口标号(window_id下文简称为w_id)，并为每次生成的每个窗口的显示数据设置帧标号(f_id)，其中没一个窗口对应的窗口标号是唯一的，通过将窗口标号与帧标号结合可以区分显示数据对应的应用的窗口，且每个窗口的显示数据对应的帧标号可以彼此独立。如此，Linux侧可以同时向Android侧发送多个应用的窗口的显示数据以及显示数据的帧标号和显示数据的窗口标号。Android侧在收到多个应用的窗口的显示数据之后，Android侧可以为每个窗口创建一个对应的渲染任务(处理线程)，每个渲染任务通过窗口标号(w_id)进行标识，多个渲染任务可以同时调用Android侧的渲染服务对每个窗口的显示数据进行渲染并在电子设备的屏幕中显示渲染后的窗口的显示内容，可以理解，这里的每个窗口的显示内容并不一定是同时显示的，每个窗口的显示内容可以是同步显示或者异步显示，本实施例对多个窗口的显示内容的显示顺序不做限定。在Android侧的每一个渲染任务完成对各自对应的窗口的显示数据的渲染后，Android侧可以向Linux侧同时返回响应消息、窗口标号以及帧标号，使得Linux侧可以继续向Android侧同时发送已经渲染完成的每个窗口的更新后的显示数据(Linux侧生成的窗口的下一个的显示数据)。

例如，如图3c所示，Linux侧启动了应用1和应用2，应用1和应用2分别对应窗口1(w_id1)和窗口2(w_id2)。在第一个送显周期内，电子设备100的Linux侧可以生成窗口1的第一图像帧的显示数据以及窗口2的第一图像帧的显示数据；在第二个送显周期内，Linux侧可以将窗口1的第一图像帧的显示数据、窗口标号(w_id1)以及显示数据的帧标号(f_id1)和窗口2的第一图像帧的显示数据、窗口标号(w_id2)以及显示数据的帧标号(f_id1)发送给Android侧，同时，Linux侧生成窗口1的第二图像帧的显示数据以及窗口2的第二图像帧的显示数据。Android侧可以创建两个渲染任务同时对窗口1的第二图像帧的显示数据以及窗口2的第二图像帧的显示数据进行渲染。

继续参考图3c，由于窗口1的第一图像帧的显示数据较大，直到第三个送显周期，Android侧的渲染服务才渲染完成应用的窗口1的第一图像帧，并向Linux侧回复；同时，在第二个送显周期和第三个送显周期，Android侧的渲染服务分别渲染完成窗口2的第一图像帧的显示数据和窗口2的第二图像帧的显示数据，并向Linux侧回复。在第四个送显周期，Android侧的渲染服务分别渲染完成窗口1的第二图像帧的显示数据和窗口2的第三图像帧的显示数据，并向Linux侧回复。

可以看出，在第二个送显周期到第三个送显周期的时间段，窗口1的显示帧率都会降低，窗口1的显示内容会出现卡顿；而窗口2可以始终保持正常显示。

通过本申请实施例的应用显示方法，在Linux侧启动了多应用多窗口的场景下，Linux侧可以同时将各个窗口的显示数据发送给Android侧进行渲染并显示，Linux侧可以同时接收并处理各个窗口的响应消息，使得Linux侧各个窗口的显示帧率相互独立，即使其中一个窗口的显示数据较大，Android侧对该窗口的渲染处理缓慢，也只会造成该窗口的画面卡顿，而不会影响其他的窗口显示帧率，提高了用户体验。

参考图4，图4示出了本申请实施例提供的一种电子设备的应用显示方法的场景示意图，图4中的电子设备100的主系统是Android系统，电子设备100将运行在Android系统上的系统Linux系统的应用的窗口显示在电子设备的屏幕，在图4所示的场景中，Linux侧生成多个应用的窗口(窗口1至窗口N)的显示数据，其中，Linux侧还可以对每一个应用的窗口以及显示数据设置：窗口标号(w_id)、返回帧标号(rsp_f_id)以及当前帧标号(current_f_id)等标识信息。例如：以图4中的应用的窗口1为例，Linux侧已经向Android侧发送的应用的窗口1的显示数据的帧标号为current_f_id＝1，窗口标号为w_id1，在发送后，Linux侧继续生成的该应用的窗口1的下一组显示数据的帧标号为current_f_id＝2，也就是当前帧标号(current_f_id)为current_f_id＝2。这里的当前帧标号用于标识Linux侧当前生成的应用的窗口1的显示数据，Linux侧每一次生成应用的窗口1的显示数据都可以对显示数据设置一个当前帧标号，当前帧标号的数值可以是依次递增的。返回帧标号用于保存Android侧向Linux侧返回响应消息时，同时向Linux侧返回的已完成渲染的显示数据的帧标号。Linux侧可以通过判断当前帧标号和返回帧标号之间的差值是否为1来确定Linux侧向Android侧发送的应用的窗口的显示数据是连续的，确保应用的窗口不会产生丢帧。

可以理解，这里的依次递增的帧标号也可以表示Android侧渲染图像帧的渲染顺序。也就是，Android侧依次渲染窗口1的显示数据(current_f_id＝1)以及窗口2的显示数据(current_f_id＝2)。

Linux侧可以通过Linux显示服务(hsl-weston模块)将多个窗口的显示数据以及窗口的显示数据对应的窗口标号(w_id)和当前帧标号(current_f_id)同时发送给Android侧的Android显示代理(hsl-shell app模块)，Linux显示服务和Android显示代理可以建立用于传输显示数据和标识信息的传输连接。Android显示代理可以为每一个窗口建立一个渲染任务(如图4中的窗口处理线程)，每一个窗口对应的渲染任务可以通过窗口的窗口标号(w_id)来唯一标识；同时，Android侧可以将接收到的显示数据的当前帧标号(current_f_id)存储为显示数据对应的帧标号(f_id)，Android侧可以通过窗口标号结合帧标号(w_id+f_id)用于区分Android侧正在处理的应用的窗口的显示数据。Android显示代理将窗口的显示数据发送给Android侧与窗口对应的渲染任务，渲染任务可以调用Android侧的渲染服务对窗口的显示数据进行渲染并显示。在Android侧的渲染服务完成渲染后，Android显示代理可以向Linux侧返回完成渲染的响应消息以及完成渲染的应用的窗口的窗口标号(w_id)和帧标号(f_id)。在Linux侧收到响应消息以及窗口标号(w_id)和帧标号(f_id)后，Linux侧可以通过Linux显示服务根据返回的窗口标号(w_id)确定对应的应用的窗口以及将返回的帧标号(f_id)保存为返回帧标号(rsp_f_id)，根据返回帧标号(rsp_f_id)确定应用的窗口对应的下一组显示数据，并继续向Android侧的Android显示代理发送。例如：继续以应用的窗口1为例，Linux侧收到的窗口标号为w_id1、帧标号为f_id＝1，Linux侧将帧标号保存为返回帧标号rsp_f_id＝1，Linux侧通过w_id1确定应用的窗口为窗口1，并计算出返回帧标号rsp_f_id＝1与窗口1的当前帧标号current_f_id＝2之间的差值为1，则Linux侧确定Linux侧向Android侧发送的应用的窗口1的显示数据是连续的。可以理解，Linux侧可以继续向Android侧发送应用的窗口1的当前帧标号current_f_id＝2的显示数据，而Linux侧可以生成应用的窗口1的当前帧标号current_f_id＝3的显示数据。可以理解，这里的窗口1至窗口N中的每个窗口的显示内容并不一定是同时显示的，窗口1至窗口N中的每个窗口的显示内容可以是同步显示或者异步显示，本实施例对窗口1至窗口N中的每个窗口的显示内容的显示顺序不做限定。

可以理解，本申请的实施例中的电子设备是一种具有显示功能的终端设备，例如，常见的终端设备可以包括：车载设备、手机、平板电脑、笔记本电脑、掌上电脑、移动互联网设备(mobile internet device，MID)、可穿戴设备(例如包括：智能手表、智能手环、计步器等)、个人数字助理、便携式媒体播放器、导航设备、视频游戏设备、机顶盒、虚拟现实和/或增强现实设备、物联网设备、工业控制设备、流媒体客户端设备、电子书、阅读设备以及其他设备。

图5示出了根据本申请的实施例的电子设备100的结构示意图，电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serialbus，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可以包括应用处理器(AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digitalsignal processor，DSP)，基带处理器(BP)，和/或神经网络处理器(neural-networkprocessing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

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

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。

电源管理模块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等无线通信的解决方案。

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

显示屏194用于显示图像，视频等。显示屏194包括显示面板。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

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

摄像头193用于捕获静态图像或视频。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

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

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。处理器110通过运行存储在内部存储器121的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备100的各种功能应用以及数据处理。

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

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

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

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

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

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

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。

陀螺仪传感器180B可以用于确定电子设备100的运动姿态。

气压传感器180C用于测量气压。在一些实施例中，电子设备100通过气压传感器180C测得的气压值计算海拔高度，辅助定位和导航。

磁传感器180D包括霍尔传感器。

加速度传感器180E可检测电子设备100在各个方向上(一般为三轴)加速度的大小。

距离传感器180F，用于测量距离。

接近光传感器180G可以包括例如发光二极管(LED)和光检测器，

环境光传感器180L用于感知环境光亮度。

指纹传感器180H用于采集指纹。

温度传感器180J用于检测温度。

触摸传感器180K，也称“触控器件”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。

骨传导传感器180M可以获取振动信号。

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

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。

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

SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和电子设备100的接触和分离。

下面基于图5所示的电子设备100的软硬件结构，通过图6对本申请的电子设备100的应用显示方法进行详细说明。

具体地，本申请图6的应用显示方法可以通过电子设备100的处理器110执行相关程序来实现。如图6所示，根据本申请的一个具体实施方式提供的用于电子设备的应用显示方法包括如下所示的步骤。

S601：生成应用的窗口的显示数据。

本申请实施例中，这里的显示数据可以是电子设备100的Linux侧的应用的窗口中的文字、图像以及各种组件(如：按钮，输入框，下拉框等)。

S602：生成应用的窗口的显示数据的标识信息。

本申请实施例中，显示数据的标识信息可以是应用的窗口的窗口标号(w_id)、返回帧标号(rsp_f_id)以及当前帧标号(current_f_id)。窗口标号(w_id)用于唯一标识Linux侧的应用的窗口。也就是说，若电子设备100的Linux侧启动了多个应用的窗口，则每个应用的窗口都有一个唯一的窗口标号(w_id)。当前帧标号(current_f_id)用于标识Linux侧当前生成的每一个应用的窗口的显示数据，返回帧标号(rsp_f_id)用于保存Android侧Linux侧返回的已完成渲染的应用的窗口的显示数据的帧标号

例如，Linux侧可以启动应用1和应用2，应用1和应用2分别对应窗口1和窗口2，则Linux侧除了生成窗口1和窗口2的显示数据，Linux侧还可以生成窗口1的窗口标号w_id1和窗口2的窗口标号w_id2。可以理解，若Linux侧首次生成窗口1和窗口2的显示数据，也就是，Linux侧生成窗口1和窗口2的第一图像帧的显示数据，则窗口1和窗口2的当前帧标号可以为current_f_id＝1，而返回帧标号rsp_f_id为空。Linux侧可以通过窗口标号结合当前帧标号来唯一识别应用的窗口的显示数据。w_id1+1可以标识窗口1的第一图像帧的显示数据，w_id2+1可以标识窗口2的第一图像帧的显示数据。

可以理解，Linux侧启动的一个应用也可以具有多个窗口，例如，Linux侧可以启动应用1，应用1对应窗口1和窗口2。

S603：判断是否满足送显条件。

本申请实施例中，如果满足送显条件，则执行步骤S604；如果不满足，则等待直至满足送显条件。

这里的送显条件可以包括：Linux侧的应用的窗口的显示数据发生变化、电子设备100的主系统(Android系统)到达下一个送显周期以及Android侧的渲染服务已经渲染完成前一次发送的应用的窗口的显示数据。

可以理解，Linux侧的应用的窗口的显示数据发生变化表示应用的窗口中的显示内容发生变化，也就是Linux侧生成的窗口相邻两个图像帧的显示数据不一致。而电子设备100的主系统(Android系统)到达下一个送显周期表示Linux侧向Android侧发送应用的窗口的显示数据到Android侧完成渲染并显示需要在一个送显周期内完成。

可以理解，判断Android侧的渲染服务已经渲染完成前一次发送的应用的窗口的显示数据的过程可以包括：Linux侧接收到渲染完成的响应消息以及渲染完成的应用的窗口的显示数据的标识信息，Linux侧根据标识信息中的窗口标号确定与窗口标号对应的应用的窗口，以及Linux侧判断标识信息中的应用的窗口的帧标号(f_id)与Linux侧的保存的应用的窗口的当前帧标号(current_f_id)之间的差值是否为1，如果为1，说明Android侧的渲染服务已经渲染完成的应用的窗口的显示数据和Linux侧即将向Android侧发送的应用的窗口的显示数据是连续的。如果差值不为1，说明Android侧显示的应用的窗口产生丢帧，Android侧可以要求Linux侧重新发送丢失的应用的窗口的显示数据，亦或者，Linux侧也可以忽略丢失的应用的窗口的显示数据，继续发送生成的下一个应用的窗口的显示数据。

S604：发送显示数据和标识信息。

本申请实施例中，Linux侧可以将应用的窗口的显示数据和显示数据对应的标识信息同时发送给Android侧。例如，Linux侧可以通过如图4所示的Linux显示服务将应用的窗口的显示数据和显示数据对应的标识信息发送给Android侧的Android显示代理。可以理解，若Linux侧启动了多个应用，也就是，打开了多个应用的窗口，则Linux侧会生成多个应用的窗口的显示数据以及显示数据对应的标识信息。Linux侧可以同时将多个应用的窗口的显示数据以及显示数据对应的标识信息发送给Android侧。

例如，Linux侧生成了应用1的窗口1和应用2的窗口2的显示数据和标识信息，包括：窗口标号w_id1和窗口标号w_id2，以及窗口1的窗口2的显示数据的当前帧标号current_f_id＝1。

可以理解，在Linux侧向Android侧发送了应用的窗口的显示数据和标识信息后，Linux侧可以继续生成应用的窗口的下一组显示数据，同时，应用的窗口的显示数据的当前帧标号的数值可以递增。

例如，Linux侧已发送的窗口1的窗口2的显示数据的当前帧标号current_f_id＝1，则Linux侧生成了窗口1的窗口2的下一组显示数据后，窗口1的窗口2的显示数据的当前帧标号current_f_id＝2。

S605：接收应用的窗口的显示数据和标识信息。

本申请实施例中，Android侧的Android显示代理也可以同时从Linux侧接收多个应用的窗口的显示数据以及显示数据对应的标识信息。Android侧可以将接收到的多个应用的窗口的显示数据以及显示数据对应的标识信息保存在电子设备100的存储区域(内存)，可以理解，用于保存多个应用的窗口的显示数据以及显示数据对应的标识信息的存储区域可以是Android侧划分的专门用于保存多个应用的窗口的显示数据以及显示数据对应的标识信息的共享内存。

例如，Android侧接收到应用1的窗口1和应用2的窗口2的显示数据以及窗口1和窗口2的窗口标号w_id1和w_id2，则Android侧可以建立应用1的窗口1和窗口2对应的渲染任务，通过窗口标号w_id1和w_id2来唯一标识建立的渲染任务。同时，Android侧可以将窗口1和窗口2的显示数据对应的当前帧标号current_f_id＝1保存为帧标号f_id＝1。

S606：根据标识信息中的窗口标号确定应用的窗口对应的渲染任务。

本申请实施例中，若Android侧从Linux侧接收多个应用的窗口的显示数据以及显示数据对应的标识信息，Android侧可以为每一个应用的窗口建立一个渲染任务(窗口处理线程)，每一个应用的窗口对应的渲染任务可以通过窗口的窗口标号(w_id)来唯一标识。可以理解例如，Android侧接收到应用1的窗口1和应用2的窗口2，则Android侧可以通过窗口标号w_id1来建立应用1的窗口1对应的渲染任务，通过窗口标号w_id2来建立的应用2的窗口2的。每一个应用的窗口的渲染任务可以调用Android侧的渲染服务，渲染该应用的窗口的显示数据。

可以理解，Android侧也可以接收到Linux侧的一个应用的多个窗口，例如，Android侧接收到应用1的窗口1和窗口2，则Android侧可以通过窗口标号w_id1来唯一标识应用1的窗口1的渲染任务，通过窗口标号w_id2来唯一标识应用1的窗口2的渲染任务。

S607：调用渲染服务对应用的窗口的显示数据进行渲染并显示。

本申请实施例中，在Android侧为接收到的每一个应用的窗口的显示数据建立对应的渲染任务后，Android侧可以从步骤S605中描述的电子设备100的存储区域，也就是共享内存中读取应用的窗口的显示数据，并通过应用的窗口对应的渲染任务调用Android侧的渲染服务对应用的窗口的显示数据进行渲染并显示。

S608：返回渲染完成的应用的窗口的显示数据的响应消息和标识信息。

本申请实施例中，在Android侧通过应用的窗口对应的渲染任务调用Android侧的渲染服务对应用的窗口的显示数据进行渲染并显示后，Android侧可以向Linux侧返回渲染完成的应用的窗口的显示数据的响应消息，同时，Android侧还可以向Linux侧返回渲染完成的应用的窗口的标识信息。例如，Android侧渲染完成了窗口1和窗口2，则Android侧向Linux侧返回渲染完成的窗口1和窗口2的响应消息、窗口1和窗口2的窗口标号w_id1和窗口标号w_id2以及窗口1和窗口2的帧标号f_id＝1。

可以理解，这里的窗口1和窗口2的显示内容并不一定是同时显示的，窗口1和窗口2中的每个窗口的显示内容可以是同步显示或者异步显示，本实施例对窗口1和窗口2的显示内容的显示顺序不做限定。

S609：接收返回的响应消息和标识信息，并更新应用的窗口的标识信息。

本申请实施例中，在Linux侧从Android侧接收了返回的响应消息和标识信息，Linux侧可以对保存的应用的窗口的标识信息进行更新，并重新回到步骤S601，Linux侧生成应用的窗口的下一组显示数据，在满足送显条件的情况下，再次向Android侧发送生成的应用的窗口的下一组显示数据。

例如，Linux侧根据返回的窗口标号w_id1和窗口标号w_id2确定对应的窗口1和窗口2以及将返回的窗口1和窗口2的帧标号f_id＝1保存为返回帧标号rsp_f_id＝1。Linux侧可以计算出返回帧标号rsp_f_id＝1与窗口1的当前帧标号current_f_id＝2之间的差值为1，则Linux侧确定Linux侧向Android侧发送的应用的窗口1的显示数据是连续的。可以理解，上述过程可以在步骤S603中执行，也就是在判断是否满足送显条件的步骤中执行。

下面参考图7至图9，图7至图9分别示出了本申请实施例中Linux侧向Android侧发送应用的窗口的显示数据、Android侧从Linux侧接收并渲染窗口的显示数据以及Linux侧从Android侧接收响应消息的步骤，先参考图7，图7示出了本申请实施例提供的一种电子设备的Linux侧的渲染服务向Android侧发送应用的窗口的显示数据的过程。图7的方案可以是对图2中描述的步骤S202至步骤S203或者图6中描述的步骤S603至步骤S604的进一步说明，该过程包括：

S701：判断是否满足送显周期以及窗口的显示数据是否发生变化。

如果满足以及窗口的显示数据发生变化，则执行步骤S702，如果不满足或者窗口的显示数据未发生变化，则回到步骤S701，Linux侧继续等待条件满足。

S702：通过窗口标号找到已处理完成的返回帧标号。

本申请实施例中，在Linux侧持续生成应用的窗口的显示数据并送显示的过程中，Linux侧也会持续收到Android侧返回的渲染完成的显示数据的窗口标号和返回帧标号。

S703：判断返回帧标号与当前帧标号的差值是否小于预设差值阈值。

Linux侧可以根据返回的窗口标号确定对应的窗口以及计算返回帧标号与窗口的当前帧标号之间的差值是否小于预设差值阈值来判断已发送的窗口的显示数据是否渲染完成。如果小于预设差值阈值，则Linux侧可以继续向Android侧发送应用的窗口的下一组显示数据。如果不小于预设差值阈值，则Linux侧可以回到步骤S701，Linux侧继续等待条件满足；亦或者，Linux侧也可以忽略丢失的应用的窗口的显示数据，继续发送生成的下一个应用的窗口的显示数据。

例如，这里的预设差值阈值可以设置为2，也就是说，返回的帧标号与窗口的当前帧标号之间的差值为1，说明Linux侧正要发送的显示数据与Android侧渲染完成的显示数据之间是连续的，没有出现丢帧。可以理解，这里的预设差值阈值可以设置也可以设置为其他数值。例如，将预设差值阈值可以设置为3，这时，可以允许Linux侧正要发送的显示数据与Android侧渲染完成的显示数据之间出现一帧显示数据丢失。在本申请实施例中对预设差值阈值的取值范围不做限定。

S704：发送窗口的显示数据以及标识信息，将当前帧标号递增。

Linux侧可以继续向Android侧发送应用的窗口的下一组显示数据，并接着生成应用的窗口的显示数据，也就是说，Linux侧生成的应用的窗口的显示数据的当前帧标号的数值逐步递增。

在通过图7介绍完Linux侧向Android侧发送应用的窗口的显示数据的过程后，下面参考图8，图8示出了本申请实施例提供的一种电子设备的Android侧从Linux侧接收并渲染窗口的显示数据的过程。图8的方案可以是对图2中描述的步骤S204或者图6中描述的步骤S605至步骤S607的进一步说明，该过程包括：

S801：接收并保存应用的窗口的显示数据和标识信息。

Android侧可以同时从Linux侧接收多个应用的窗口的显示数据以及显示数据对应的标识信息，将应用的窗口的显示数据以及显示数据对应的标识信息保存在电子设备100的存储区域(共享内存)。

例如，Android侧接收到应用1的窗口1和应用2的窗口2的显示数据以及窗口1和窗口2的窗口标号w_id1和w_id2，同时，Android侧可以将窗口1和窗口2的显示数据对应的当前帧标号current_f_id＝1保存为帧标号f_id＝1。

S802：判断是否已经建立应用的窗口对应的渲染任务。

Android侧可以通过应用的窗口的窗口标号查找是否已经建立了应用的窗口对应的渲染任务，如果未建立，则执行步骤S803，Android侧可以建立应用的窗口对应的渲染任务，通过窗口标号来唯一标识建立的渲染任务。如果已经建立，则执行步骤S804，Android侧可以通过窗口标号来查找已经建立的渲染任务。

例如：Android侧可以通过窗口标号w_id1和w_id2来建立或者查找应用1的窗口1和窗口2对应的渲染任务。

S803：建立应用的窗口对应的渲染任务。

这里的渲染任务可以是Android侧的窗口的显示数据的处理线程，渲染任务可以调用Android侧的渲染服务，也就是，通过电子设备的图形处理器(Graphics ProcessingUnit，缩GPU)对窗口的显示数据进行渲染。Android侧可以建立应用的窗口对应的渲染任务，通过窗口标号来唯一标识建立的渲染任务

S804：查找应用的窗口对应的渲染任务。

Android侧可以通过窗口标号来查找已经建立的渲染任务。

S805：从存储区域读取显示数据并处理。

Android侧可以从步骤S801中描述的电子设备100的存储区域，也就是共享内存中读取应用的窗口的显示数据，并通过应用的窗口对应的渲染任务调用Android侧的渲染服务对应用的窗口的显示数据进行渲染并显示。

S806：返回渲染完成的应用的窗口的显示数据的响应消息和标识信息。

例如，Android侧渲染完成了窗口1和窗口2，则Android侧向Linux侧返回渲染完成的窗口1和窗口2的响应消息、窗口1和窗口2的窗口标号w_id1和窗口标号w_id2以及窗口1和窗口2的帧标号f_id＝1。

在通过图8介绍完Android侧从Linux侧接收并渲染窗口的显示数据的过程后，下面参考图9，图9示出了本申请实施例提供的一种电子设备的Linux侧从Android侧接收响应消息的过程。图9的方案可以是对图2中描述的步骤S205或者图6中描述的步骤S608至步骤S609的进一步说明，该过程包括：

S901：接收返回的响应消息和标识信息。

Linux侧可以从Android侧接收了返回的响应消息，同时，Linux侧还可以从Android侧接收标识信息，这里的标识信息包括：Android侧渲染完成的应用的窗口的窗口标号和窗口的显示数据的帧标号。

例如，Linux侧接收到返回的窗口标号w_id1和窗口标号w_id2以及返回的窗口1和窗口2的帧标号f_id＝1。

S902：更新应用的窗口的标识信息。

Linux侧可以对保存的应用的窗口的标识信息进行更新，并生成应用的窗口的下一组显示数据，在满足送显条件的情况下，再次向Android侧发送生成的应用的窗口的下一组显示数据。

例如，Linux侧将返回的窗口1和窗口2的帧标号f_id＝1保存为返回帧标号rsp_f_id＝1。

可以看出，上述图6至图9示出了本申请实施例提供的应用于Linux和Android双系统的电子设备100的应用显示方法，下面参考图10，图10描述另一种电子设备显示应用的窗口的场景示意图，这里的电子设备100的主系统是Android系统，电子设备100将运行在Android系统上的系统Linux系统的应用的窗口显示在电子设备的屏幕，在图10所示的场景中，Linux侧的可显示的图形应用有两种：一种是X11协议的应用，另外一种是wayland协议的应用。Linux系统和其应用运行在Android系统下的虚拟机或者容器内，其中X11协议的应用，通过XServer(显示服务)和HSL-Linux显示系统进行交互，wayland协议的应用直接用wayland协议和HSL-Linux显示系统进行交互，应用和HSL-Linux显示系统直接传到窗口、显示相关的信息，这些信息经过HSL-Linux显示系统的处理后，把应用的窗口的显示信息、窗口的管理信息提取出来，通过HSL通信模块和HSL通信模块client传递给Android系统的HSL-shell app(HSL指令库)，然后由HSL-shell app调用Android侧的系统服务(渲染服务)完成Android系统上显示Linux应用的窗口。

应当理解的是，虽然在本文中可能使用了术语“第一”、“第二”等等来描述各个特征，但是这些特征不应当受这些术语限制。使用这些术语仅仅是为了进行区分，而不能理解为指示或暗示相对重要性。举例来说，在不背离示例性实施例的范围的情况下，第一特征可以被称为第二特征，并且类似地第二特征可以被称为第一特征。

此外，各种操作将以最有助于理解说明性实施例的方式被描述为多个彼此分离的操作；然而，描述的顺序不应被解释为暗示这些操作必须依赖描述的顺序，其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序也可以被重新安排。当所描述的操作完成时，所述处理可以被终止，但是还可以具有未包括在附图中的附加操作。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

说明书中对“一个实施例”，“实施例”，“说明性实施例”等的引用表示所描述的实施例可以包括特定特征、结构或性质，但是每个实施例也可能或不是必需包括特定的特征、结构或性质。而且，这些短语不一定是针对同一实施例。此外，当结合具体实施例描述特定特征，本领域技术人员的知识能够影响到这些特征与其他实施例的结合，无论这些实施例是否被明确描述。

除非上下文另有规定，否则术语“包含”、“具有”和“包括”是同义词。短语“A/B”表示“A或B”。短语“A和/或B”表示“(A)、(B)或(A和B)”。

如本文所使用的，术语“模块”可以指代，作为其中的一部分，或者包括：用于运行一个或多个软件或固件程序的存储器(共享、专用或组)，专用集成电路(ASIC)，电子电路和/或处理器(共享、专用或组)，组合逻辑电路，和/或提供所述功能的其他合适组件。

在附图中，可能以特定布置和/或顺序示出了一些结构或方法特征。然而，应当理解的是，这样的特定布置和/或排序不是必需的。而是，在一些实施例中，这些特征可以以不同于说明性附图中所示的方式和/或顺序来进行说明。另外，特定附图中所包含得结构或方法特征并不意味着所有实施例都需要包含这样的特征，在一些实施例中，可以不包含这些特征，或者可以将这些特征与其他特征进行组合。

上面结合附图对本申请的实施例做了详细说明，但本申请技术方案的使用不仅仅局限于本专利实施例中提及的各种应用，各种结构和变型都可以参考本申请技术方案轻易地实施，以达到本文中提及的各种有益效果。在本领域普通技术人员所具备的知识范围内，在不脱离本申请宗旨的前提下做出的各种变化，均应归属于本申请专利涵盖范围。

Claims (10)

1.一种应用显示方法，应用于电子设备，其特征在于，所述电子设备运行有第一系统和第二系统，并且

所述方法包括：

第二系统从第一系统接收到多个应用窗口的显示数据和每个显示数据的数据标识，其中，第一显示数据的第一数据标识包括用于标识所述第一显示数据所属应用窗口的窗口标识，所述第一显示数据的第一数据标识为所述每个显示数据的数据标识中的任意一个显示数据的数据标识；

所述第二系统根据每个所述显示数据对应的窗口标识，将每个所述显示数据发送至与每个所述显示数据对应的应用窗口的渲染任务分别进行渲染，得到每个所述显示数据的渲染图像；

所述第二系统在所述电子设备的屏幕上，将得到的每个所述显示数据的渲染图像显示在每个所述显示数据各自对应的应用窗口中。

2.根据权利要求1所述的方法，其特征在于，所述第一数据标识还包括显示数据序号，所述显示数据序号用于表示所述第一显示数据在同一应用窗口的多个显示数据中的渲染顺序。

3.根据权利要求2所述的方法，其特征在于，所述多个应用窗口包括第一应用窗口，所述第一显示数据为第一应用窗口的显示数据；

所述方法还包括：

所述第二系统在完成对所述第一显示数据的渲染后，向所述第一系统返回所述第一显示数据的第一响应消息和所述第一数据标识；

所述第一系统根据接收到的所述第一响应消息、所述第一数据标识中的第一窗口标识，从生成的显示数据中选择出所述第一应用窗口的显示数据，并根据所述第一数据标识中的第一显示数据序号，从选择出的所述第一应用窗口的显示数据中选择出在所述第一显示数据之后需要渲染的第二显示数据；

所述第一系统向所述第二系统发送所述第二显示数据和所述第二显示数据的第二数据标识，其中所述第二数据标识包括所述第一窗口标识和第二显示数据序号。

4.根据权利要求1-3任意一项所述的方法，其特征在于，所述渲染任务为所述第二系统建立的线程任务，其中，每个应用窗口对应一个所述渲染任务。

5.根据权利要求3或4所述的方法，其特征在于，所述多个应用窗口还包括第二应用窗口，所述多个应用窗口的显示数据还包括所述第二应用窗口的第三显示数据，并且

所述第一显示数据和第三显示数据的数据量不同，所述第二系统渲染所述第一显示数据和渲染所述第三显示数据的时间不同。

6.根据权利要求5所述的方法，其特征在于，在所述电子设备的屏幕上，所述第一应用窗口和第二应用窗口的渲染图像的显示帧率不同，其中，所述显示帧率用于表示每单位时间内应用窗口刷新渲染图像的数量。

7.根据权利要求1-6任意一项所述的方法，其特征在于，所述第一系统包括Linux系统，所述第二系统包括Android系统，所述第二系统为运行在所述电子设备的主系统，所述第一系统为运行在所述第二系统的从系统。

8.根据权利要求1-7任意一项所述的方法，其特征在于，所述多个应用窗口包括所述第一系统上的同一应用或者不同应用的窗口。

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

处理器；以及

存储器，可以与处理器耦合或者解耦用于存储由所述处理器执行的指令；

所述指令被处理器执行时，使得所述电子设备执行权利要求1至8中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中包含有指令，当所述指令被电子设备执行时使电子设备实现权利要求1至8中任一项所述的方法。