显示方法及装置与流程

1.本技术涉及电子信息领域，尤其涉及一种显示方法及装置。


背景技术：

2.应用(application，app)的服务器向app的客户端主动发送的消息，可以被称为通知消息。用户可以通过通知消息列表看到被推送的通知消息的摘要。
3.目前，电子设备支持用户通过点击通知消息的摘要，查看通知消息，但通知消息的查看功能还有改进的空间。


技术实现要素：

4.本技术提供了一种显示方法及装置，目的在于解决如何改进通知消息的查看功能的问题。
5.为了实现上述目的，本技术提供了以下技术方案：
6.本技术的第一方面提供一种显示方法，应用在电子设备，所述电子设备设置有应用app的客户端，所述方法包括：接收所述app的服务器发送的表示所述通知消息的通知消息的第一信息，向云服务器发送表示所述通知消息的所述通知消息的第二信息，接收所述云服务器发送的文件，所述文件由所述通知消息转换得到；响应于对所述通知消息的第一信息的第一操作，通过所述文件显示所述通知消息。因为通过文件显示通知消息，所以，无需再调用app的客户端显示通知消息，因此，降低了因启动app的客户端而导致通知消息显示时延过长的可能性，即降低了查看通知消息的时延，从而改善了电子设备的通知消息的查看功能。
7.可选的，所述向云服务器发送所述通知消息的第二信息，包括：响应于对所述通知消息的第一信息的第二操作，显示控件，响应于对所述控件的操作，向所述云服务器发送所述通知消息的第二信息。基于对通知消息的第一信息以及控件的操作，触发向云服务发送通知消息的第二信息，便于用户操作，有利于用户选择通知消息的查看模式。
8.可选的，所述通知消息包括：第一通知消息和第二通知消息。所述响应于对所述通知消息的第一信息的第二操作，显示控件，包括：响应于对所述第一通知消息的第一信息的第二操作，显示所述第一通知消息的所述控件，响应于对所述第二通知消息的第一信息的第二操作，显示所述第二通知消息的所述控件。在多条通知消息的场景下，对每一条通知消息的分别显示控件，能够更加灵活地实现通知消息的查看。
9.可选的，所述响应于对所述控件的操作，向所述云服务器发送所述通知消息的第二信息，包括：响应于对所述第一通知消息的所述控件的操作，向所述云服务器发送所述第一通知消息的第二信息，响应于对所述第二通知消息的所述控件的操作，向所述云服务器发送所述第二通知消息的第二信息。通过控件分别控制通知消息的方式，能够更加灵活地实现通知消息的查看。
10.可选的，所述文件包括：由第一通知消息转换得到的第一文件、以及由第二通知消
息转换得到的第二文件。所述响应于对所述通知消息的第一信息的第一操作，通过所述文件显示所述通知消息，包括：响应于对所述第一通知消息的第一信息，或者，所述第二通知消息的第一信息的所述第一操作，通过所述文件，显示所述第一通知消息和所述第二通知消息。可见，在用户预期查看多条通知消息的情况下，可以仅操作一条通知消息实现多条通知消息的查看，提高了通知消息查看功能的便利性。
11.可选的，所述显示所述第一通知消息和所述第二通知消息，包括：在同一显示界面中，显示所述第一通知消息和所述第二通知消息。将多条通知消息显示在同一显示界面中，能够实现多条通知消息的汇聚显示，能够进一步提高通知消息查看功能的便利性。
12.可选的，所述向云服务器发送所述通知消息的第二信息，包括：响应于接收到所述通知消息的第一信息，向所述云服务器发送所述通知消息的第二信息。接收到通知消息的第一信息，即发送通知消息的第二信息，而无需用户操作触发，有利于获得更好的使用体验。
13.可选的，在所述通过所述文件显示所述通知消息之后，还包括：删除所述文件，以便于释放存储资源。
14.可选的，所述向云服务器发送所述通知消息的第二信息，包括：通过system ui向云服务器发送所述通知消息的第二信息，云服务器的设置，有利于降低电子设备的资源的消耗，基于现有的软件框架实现，具有良好的可实施性和兼容性。
15.可选的，所述接收所述云服务器发送的文件，包括：通过所述app的客户端的通信组件和所述system ui，接收所述云服务器发送的文件，基于现有软件模块实现，具有良好的可实施性和兼容性。
16.可选的，所述通过所述文件显示所述通知消息，包括：由所述system ui触发，通过所述文件显示所述通知消息。通过现有软件框架实现，具有良好的兼容性。
17.本技术的第二方面提供了一种显示方法，应用在云服务器，所述方法包括：在接收到电子设备发送的通知消息的信息后，向app的服务器发送获取所述通知消息的请求，所述app的客户端设置在所述电子设备；接收所述app的服务器发送的所述通知消息；将所述通知消息转换为文件；向所述电子设备传输所述文件。云服务器实现上述功能，有利于节省电子设备的资源，从而在改进电子设备的通知消息查看功能的情况下，不降低电子设备的性能。
18.本技术的第三方面提供了一种显示方法，应用在电子设备，所述电子设备设置有应用app的客户端，所述方法包括：接收所述app的服务器发送的通知消息的第一信息，所述第一信息用于表示所述通知消息；向所述app的服务器发送所述通知消息的第二信息，所述第二信息用于表示所述通知消息；接收所述app的服务器发送的所述通知消息；将所述通知消息转换得到文件；响应于对所述通知消息的第一信息的第一操作，通过所述文件显示所述通知消息。因为通过文件显示通知消息，所以，无需再调用app的客户端显示通知消息，因此，降低了因启动app的客户端而导致通知消息显示时延过长的可能性，即降低了查看通知消息的时延，从而改善了电子设备的通知消息的查看功能。
19.可选的，所述向云服务器发送所述通知消息的第二信息，包括：响应于对所述通知消息的第一信息的第二操作，显示控件，响应于对所述控件的操作，向所述云服务器发送所述通知消息的第二信息。基于对通知消息的第一信息以及控件的操作，触发向云服务发送
通知消息的第二信息，便于用户操作，有利于用户选择通知消息的查看模式。
20.可选的，所述通知消息包括：第一通知消息和第二通知消息。所述响应于对所述通知消息的第一信息的第二操作，显示控件，包括：响应于对所述第一通知消息的第一信息的第二操作，显示所述第一通知消息的所述控件，响应于对所述第二通知消息的第一信息的第二操作，显示所述第二通知消息的所述控件。在多条通知消息的场景下，对每一条通知消息的分别显示控件，能够更加灵活地实现通知消息的查看。
21.可选的，所述响应于对所述控件的操作，向所述云服务器发送所述通知消息的第二信息，包括：响应于对所述第一通知消息的所述控件的操作，向所述云服务器发送所述第一通知消息的第二信息，响应于对所述第二通知消息的所述控件的操作，向所述云服务器发送所述第二通知消息的第二信息。通过控件分别控制通知消息的方式，能够更加灵活地实现通知消息的查看。
22.可选的，所述文件包括：由第一通知消息转换得到的第一文件、以及由第二通知消息转换得到的第二文件。所述响应于对所述通知消息的第一信息的第一操作，通过所述文件显示所述通知消息，包括：响应于对所述第一通知消息的第一信息，或者，所述第二通知消息的第一信息的所述第一操作，通过所述文件，显示所述第一通知消息和所述第二通知消息。可见，在用户预期查看多条通知消息的情况下，可以仅操作一条通知消息实现多条通知消息的查看，提高了通知消息查看功能的便利性。
23.可选的，所述显示所述第一通知消息和所述第二通知消息，包括：在同一显示界面中，显示所述第一通知消息和所述第二通知消息。将多条通知消息显示在同一显示界面中，能够实现多条通知消息的汇聚显示，能够进一步提高通知消息查看功能的便利性。
24.可选的，所述向云服务器发送所述通知消息的第二信息，包括：响应于接收到所述通知消息的第一信息，向所述云服务器发送所述通知消息的第二信息。接收到通知消息的第一信息，即发送通知消息的第二信息，而无需用户操作触发，有利于获得更好的使用体验。
25.可选的，在所述通过所述文件显示所述通知消息之后，还包括：删除所述文件，以便于释放存储资源。
26.可选的，所述向云服务器发送所述通知消息的第二信息，包括：通过system ui向云服务器发送所述通知消息的第二信息，云服务器的设置，有利于降低电子设备的资源的消耗，基于现有的软件框架实现，具有良好的可实施性和兼容性。
27.可选的，所述接收所述云服务器发送的文件，包括：通过所述app的客户端的通信组件和所述system ui，接收所述云服务器发送的文件，基于现有软件模块实现，具有良好的可实施性和兼容性。
28.可选的，所述通过所述文件显示所述通知消息，包括：由所述system ui触发，通过所述文件显示所述通知消息。通过现有软件框架实现，具有良好的兼容性。
29.本技术的第四方面提供一种电子设备，包括：处理器以及存储器。所述存储器用于存储应用程序，所述处理器用于运行所述应用程序，以本技术的第一方面、第二方面或第三方面所述的显示方法。
30.本技术的第五方面提供一种可读存储介质，其上存储有程序，在计算机设备运行所述应用程序时，实现本技术的第一方面、第二方面或第三方面所述的显示方法。
附图说明
31.图1a-图1c为电子设备支持用户查看通知消息的一种场景示例图；
32.图2a-图2e为电子设备支持用户查看通知消息的又一种场景示例图；
33.图3a-图3f为电子设备支持用户查看通知消息的又一种场景示例图；
34.图4为本技术实施例公开的电子设备的结构示例图；
35.图5为本技术实施例公开的电子设备中运行的软件框架的示例图；
36.图6为本技术实施例公开的电子设备获取通知消息的摘要的软件框架的示例图；
37.图7为本技术实施例公开的实现显示方法的软件框架的示例图；
38.图8为本技术实施例公开的一种显示方法的流程图；
39.图9a-图9d为本技术实施例公开的显示方法的应用场景示例图；
40.图10为本技术实施例公开的电子设备获取通知消息的摘要的又一种软件框架的示例图；
41.图11a-图11g为本技术实施例公开的显示方法应用在查看多条通知消息的一种场景的示例图；
42.图12为本技术实施例公开的又一种显示方法的流程图；
43.图13a-图13g为本技术实施例公开的显示方法应用在查看多条通知消息的又一种场景的示例图；
44.图14为本技术实施例公开的又一种显示方法的流程图；
45.图15为本技术实施例公开的又一种显示方法的流程图。
具体实施方式
46.图1a-图1c为电子设备支持用户查看通知消息的场景示例：
47.图1a中，用户通过下拉状态栏，查看通知消息列表，假设通知消息列表中包括app1的服务器推送的通知消息a的摘要(图中简化为“app1的消息a”)、app1的服务器推送的通知消息b的摘要(图中简化为“app1的消息b”)、app2的服务器推送的通知消息a的摘要(图中简化为“app2的消息a”)、以及app2的服务器推送的通知消息b的摘要(图中简化为“app2的消息b”)。用户点击“app1的消息a”，以便查看app1的服务器推送的通知消息a(以下简称为app1的消息a)。
48.用户点击“app1的消息a”后，如图1b所示，app1在电子设备中的客户端启动(图中简称为app1启动中)，app1的客户端启动过程中，加载并显示广告页面。
49.如图1c所示，在app1的客户端完成启动后，显示app1的消息a。
50.可见，在广告播放完毕后，才能显示app1的消息a。所以，用户查看app1的消息a的时延较大。
51.导致上述问题的原因在于：构成app的组件包括但不限于通信组件和显示组件。通信组件用于实现通信功能，显示组件用于实现显示功能。通信组件为轻量级组件，即占用的资源较少，而显示组件的运行需要较多的资源。因此，为了节省资源，在app不被用户使用的情况下，通常仅在后台保活通信组件，而显示组件则不在后台保活。
52.例如，后台运行的app响应于用户操作或自动被清理后，仅保留app的通信组件在后台运行，而显示组件等需要占用较多资源的组件则被关闭。
53.结合上述场景，app1的服务器推送的通知消息，被app1的客户端的通信组件接收后，需要由app1的客户端的显示组件进行显示，所以，用户点击“app1的消息a”后，如果app1在后台没有处于保活状态，即显示组件没有在后台运行，则需要先启动app1的显示组件才能显示通知消息，而导致app1的消息a的时延较大，进一步的，在app1的显示组件的启动伴有广告信息的显示的情况下，显示app1的消息a的时延被进一步增加。
54.在另一种场景示例中，用户查看通知消息不仅存在时延大的问题，还存在便利性较低的问题：
55.用户通过下拉状态栏，查看通知消息列表，假设用户预期查看的通知消息，既包括app1的消息a，又包括app1的消息b。
56.如图2a所示，用户需要先点击“app1的消息a”，如图2b以及图2c所示，在app1的客户端的显示组件启动后，显示app1的消息a。
57.如图2d所示，用户需要再次下拉状态栏，调出通知消息列表，在通知消息列表中再点击“app1的消息b”，如图2e所示，app1的客户端的显示组件显示app1的消息b。
58.可见，虽然查看的是同一app的通知消息，但只能逐条查看，且反复在下拉状态栏和app的客户端之间跳转，所以，导致用户查看通知消息不方便。
59.在另一种场景示例中，用户查看通知消息的时延大以及不方便的问题越发凸显：
60.图3a中，用户通过下拉状态栏，查看通知消息列表，假设用户预期查看的通知消息，既包括app1的消息a，又包括app2的消息b。
61.如图3b所示，用户先点击“app1的消息a”，如图3b以及图3c所示，app1的客户端的显示组件启动后，显示app1的消息a。
62.如图3d所示，用户需要再次下拉状态栏，调出通知消息列表，用户再点击“app2的消息a”，则如3e所示，app2的客户端的显示组件被启动且启动过程中播放广告，如图3f所示，app2的客户端的显示组件启动后，显示app2的消息a。
63.以此类推，用户需要逐条点击通知消息的摘要，并通过不同的app查看通知消息。
64.因此，查看的通知消息的条数越多、或者，显示组件没有处于保活的app的数量越多，则查看多条通知消息的时延大以及不方便的问题越凸显。
65.可以理解的是，上述场景仅为举例，在某些场景下，“状态栏”可以被替换为“通知栏”、“悬窗”等控件，查看通知消息列表的方式也不限于下拉操作。在某些场景下，通知消息的显示方式也不限于在下拉的状态中显示，还可以为其它方式，例如，锁屏状态下自动显示等。
66.在某些场景下，app的启动也可能不伴随广告，但只要app的显示组件没有处于保活状态，要查看通知消息就需要先启动app，启动app需要占用一定的时长，因此，还是存在用户查看app的通知消息的时延较大的问题。
67.在某些场景下，有可能app的通信组件在后台也不保活，app的服务器通过其它模块向电子设备推送通知消息。因此在本技术的实施例中，app在后台不保活包括app的显示组件或者app的全部组件在后台不保活。
68.总之，以上场景不构成对本案的适用范围的限定。
69.综合上述场景可以看出，电子设备中，通知消息的显示功能存在如下问题：
70.1、时延大，且被查看的通知消息的数量越多，和/或，没有处于后台保活的app的数
量越多，时延就越大。
71.2、查看通知消息的方式的便利性有待提高。
72.因此，电子设备的通知消息的查看功能有待改进。
73.为了解决上述问题，本技术实施例公开了一种显示方法，应用在电子设备中。
74.在一些实现方式中，电子设备可以为手机、平板电脑、桌面型、膝上型、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，umpc)、手持计算机、上网本、个人数字助理(personal digital assistant，pda)、可穿戴电子设备、智能手表等设备。
75.电子设备以手机为例，图4所示为与本技术实施例相关的手机的部分结构，包括：处理器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等。
76.可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
77.处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，ap)，调制解调处理器，图形处理器(graphics processing unit，gpu)，图像信号处理器(image signal processor，isp)，控制器，视频编解码器，数字信号处理器(digital signal processor，dsp)，基带处理器，和/或神经网络处理器(neural-network processing unit，npu)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
78.控制器可以是电子设备的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
79.处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用，避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
80.在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，i2c)接口，集成电路内置音频(inter-integrated circuit sound，i2s)接口，脉冲编码调制(pulse code modulation，pcm)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，uart)接口，移动产业处理器接口(mobile industry processor interface，mipi)，通用输入输出(general-purpose input/output，gpio)接口，用户标识模块(subscriber identity module，sim)接口，和/或通用串行总线(universal serial bus，usb)接口等。
81.mipi接口可以被用于连接处理器110与显示屏194，摄像头193等外围器件。mipi接
口包括摄像头串行接口(camera serial interface，csi)，显示屏串行接口(display serial interface，dsi)等。在一些实施例中，处理器110和显示屏194通过dsi接口通信，实现电子设备的显示功能。
82.gpio接口可以通过软件配置。gpio接口可以被配置为控制信号，也可被配置为数据信号。在一些实施例中，gpio接口可以用于连接处理器110与摄像头193，显示屏194，无线通信模块160，音频模块170，传感器模块180等。可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在本技术另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
83.电子设备通过gpu，显示屏194，以及应用处理器等实现显示功能。gpu为图像处理的微处理器，连接显示屏194和应用处理器。gpu用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个gpu，其执行程序指令以生成或改变显示信息。
84.显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，lcd)，有机发光二极管(organic light-emitting diode，oled)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode的，amoled)，柔性发光二极管(flex light-emitting diode，fled)，miniled，microled，micro-oled，量子点发光二极管(quantum dot light emitting diodes，qled)等。在一些实施例中，电子设备可以包括1个或n个显示屏194，n为大于1的正整数。
85.电子设备的显示屏194上可以显示一系列图形用户界面(graphical user interface，gui)，这些gui都是该电子设备的主屏幕。一般来说，电子设备的显示屏194的尺寸是固定的，只能在该电子设备的显示屏194中显示有限的控件。控件是一种gui元素，它是一种软件组件，包含在应用程序中，控制着该应用程序处理的所有数据以及关于这些数据的交互操作，用户可以通过直接操作(direct manipulation)来与控件交互，从而对应用程序的有关信息进行读取或者编辑。一般而言，控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、widget等可视的界面元素。例如，在本技术实施例中，显示屏194可以显示虚拟按键(一键编排、开始编排、场景编排)。
86.处理器110通过运行程序代码，实现的操作系统可以为ios操作系统、android开源操作系统、windows操作系统、鸿蒙操作系统等。
87.以android开源操作系统为例，如图5所示，在一些实施例中，将android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(android runtime)和系统库，以及内核层。
88.应用程序层可以包括一系列应用程序包。图5中，应用程序包以app1、app2
……
，appn以及system ui为例。system ui在电子设备开机时启动，用于提供各种显示能力，例如，在状态栏显示通知消息的提示信息，以及将通知消息的摘要显示在下拉状态栏等。
89.应用程序框架层为应用程序层的应用程序提供应用编程接口(application programming interface，api)和编程框架。应用程序框架层包括一些预先定义的函数。图5中以应用程序框架层运行的窗口管理服务、应用管理服务以及存储管理服务为例。窗口管理服务用于管理窗口系统，提供多窗口、分屏等各种显示形态。应用管理服务用于管理活动的应用进程，提供单应用的多进程打开能力。存储管理服务用于管理存储能力。
90.android runtime包括核心库和虚拟机。android runtime负责安卓系统的调度和管理。核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(media libraries)，三维图形处理库(例如：opengl es)，2d图形引擎(例如：sgl)等。
91.表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2d和3d图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:mpeg4，h.264，mp3，aac，amr，jpg，png等。
92.三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2d图形引擎是2d绘图的绘图引擎。
93.内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。
94.图5中所示的各层之间可以通过binder通信协议进行通信。
95.基于图5所示的软件框架，电子设备接收并显示通知消息的摘要的软件框架以及流程如图6所示：
96.app的服务器(图6中以app1的服务器为例)向运行在应用程序层的app(图6中以app1表示)的通信组件传输通知消息的摘要。app的通信组件向system ui传输通知消息的摘要。system ui通过调用窗口管理服务在状态栏显示提示信息，例如表示通知消息的图标，以提示接收到通知消息。system ui响应于用户的操作，例如下拉操作等，通过调用窗口管理服务，显示通知消息列表，通知消息列表中包括已接收且未读的通知消息的摘要。
97.可以理解的是，通知消息列表仅为一种示例，也可以使用其它方式，展现多条通知消息的摘要。通知消息的摘要也仅为一种示例，也可以为通知消息的标识等。在以下实施例中，还使用上述示例，但并不作为限定。
98.本技术实施例公开的显示方法，由图6所示的软件框架改进得到的图7所示的软件框架实现，与图6相比，图7中新增了云服务器。
99.基于图7，本实施例提供的显示方法，可以应用在但不限于以下场景中：
100.电子设备接收并显示一个或多个app的服务器推送的通知消息的信息。通知消息的信息可以为如图1a所示的通知消息的摘要，也可以为通知消息的完整内容或部分内容等，这里不做限定。在以下流程中，以通知消息的摘要为例进行说明。
101.在接收到通知消息的信息后，显示提示信息，提示信息可以为接收到的通知消息的信息，例如可以为如图1a所示的通知消息的摘要，还可以为通知消息的完整或部分内容等。提示信息还可以为对通知消息的信息进行如提取关键词等处理后，得到的信息。在以下流程中，以提示信息为通知消息的摘要为例进行说明。
102.提示信息的显示方式可以如图1a所示，显示在用户的下拉操作触发的下拉状态栏中。除此之外，提示消息还可以在锁屏界面或者在当前的活动界面中弹出显示。在以下流程中，以通知消息的摘要显示在用户的下拉操作触发的下拉状态栏中为例进行说明。
103.在一些实现方式中，提示信息还可以包括提示音，以更好地实现提示效果。
104.本实施例所述的流程，由对提示信息的操作触发，例如用户对下拉状态栏中的任意一条通知消息(以下简称为第一通知消息)的摘要的操作触发，如图8所示，本实施例所述的流程中包括以下步骤：
105.s801、system ui响应于对第一通知消息的摘要的第一操作，显示控件。
106.本实施例中，控件用于触发以下步骤。对用户而言，该步骤显示的控件的作用为提示用户触发新的通知消息查看模式。
107.第一操作可以包括但不限于：点击、滑动等手势，也可以为语音操作。用户可以通过对下拉状态栏中的通知消息的摘要进行操作，例如，以图9a为例，向左滑动“app1的消息a”，触发控件的显示。图9a中，控件的名称为“添加到关注”，可以理解的，并不限于该名称，只要能够提醒用户触发新的通知消息查看模式即可。
108.可以理解的是，本步骤中触发显示控件的第一操作，并不限于图9a所示的向左滑动，任何操作均可，只需预先配置第一操作与显示控件之间的对应关系即可。
109.s802、system ui响应于对控件的操作，向云服务器传输第一通知消息的摘要。
110.对控件的操作可以包括但不限于：点击、滑动等手势，也可以为语音操作。对控件的操作可以与第一操作相同，也可以不同。
111.例如，图9b中，用户点击“添加到关注”，表示触发新的通知消息查看模式。
112.可以理解的是，图9a以及图9b仅为一种示例，对控件的形态以及操控方式并不做限定。
113.为了更好地对本步骤进行说明，将上述场景中所述的“通知消息的信息”称为第一信息，将本步骤向云服务器传输的信息称为第二信息。第一信息和第二信息均用于表示通知消息。
114.在某些实现方式中，第二信息与第一信息相同，如第一信息和第二信息均为s802中所述的第一通知消息的摘要。
115.在另一些实现方式中，第二信息与第二信息不同，如第一信息为第一通知消息的摘要，第二信息为第一通知消息的唯一标识等。在该实现方式中，第二信息也可以由app的服务器传输至电子设备，可以与第一信息一并传输至电子设备，也可以单独传输至电子设备。
116.s803、云服务器向app的服务器传输查看第一通知消息的请求。
117.可以理解的是，app的服务器为推送第一通知消息的摘要的服务器。
118.在某些实现方式中，在请求中可以包括第一通知消息的摘要，或者第一通知消息的标识，或者第一通知消息的完整或部分内容等，只要能够告知app的服务器需要传输的是哪一条通知消息即可。
119.s804、云服务器接收app的服务器传输的第一通知消息。
120.可以理解的是，除了s804之外，在另一些实现方式中，如果app的服务器向电子设备传输的不是摘要而是第一通知消息的完整内容的情况下，云服务器在该步骤中，接收的可以是第一通知消息的标识、摘要等，只要能够向云服务器告知需要转换的是哪一条通知消息即可。app的服务器无需再向云服务器传输第一通知消息，以节省资源。
121.s805、云服务器将第一通知消息转换为预设格式的文件。
122.预设格式为电子设备在不依赖app的客户端的情况下，能够解析并显示的格式。可以理解的是，预设格式可以预先配置，也可以由云服务器在s805之前与电子设备交互协商信息获取，这里不做限定。
123.本实施例中，预设格式的一些示例为：电子设备可以显示的图片格式、文本格式
等。
124.s806、云服务器将文件向system ui传输。
125.可以理解的是，云服务器可以将文件向电子设备中运行的app的通信组件传输，再由app的通信组件向system ui传输，或者，也可以经过图6所示的安卓框架从底层逐层传输至system ui。
126.s807、system ui响应于对第一通知消息的摘要的第二操作，通过解析文件，显示第一通知消息。
127.因为文件的格式为电子设备不依赖于app的客户端可解析并显示的格式，所以，无需使用app的客户端，即可显示app的服务器推送的通知消息。
128.可以理解的是，system ui可以通过调用应用程序框架层中的存储管理服务，存储文件，并可以通过调用android runtime的显示相关模块显示第一通知消息。
129.还以图9a和图9b为例，用户触发显示“添加到关注”控件后，点击“添加到关注”控件，触发执行s802-s806，实现电子设备中存储第一通知消息转换的文件。以图9c为例，用户再点击第一通知消息的摘要，触发执行s807，显示如图9d所示的显示界面。因为文件已经保存在本地，所以，与先启动app再显示的方式相比，点击通知消息的摘要后，显示通知消息的时延更低。并且，点击通知消息的摘要后，用户不会再看到app的启动甚至显示广告的界面，用户体验更优。
130.可以理解的是，点击仅为第二操作的一种示例，第二操作可以是与第一操作不同的任何操作，这里不做限定。
131.可以理解的是，文件被存储在电子设备中后，只要system ui检测到对第一通知消息的摘要的第二操作，即可调用存储的解析文件，显示第一通知消息。
132.在用户使用手机的场景中，因为app的显示组件占用的资源过多，所以即使处于后台运行状态，例如已使用app查看通知消息，但只要app在一段时长内不被使用，为了节省手机的资源，app的显示组件会因被清理而关闭，如果用户再次要查看app的通知消息，app还要重启启动，例如图1a-图1c所示，耗时较长。
133.而还以图9a-图9d为例，因为手机中存储了文件，所以，即使显示组件被清理，也无需再重新启动显示组件，所以能够更快显示通知消息。
134.可选的，为了节省存储资源，还可以执行以下步骤：
135.s808、在第一通知消息被显示后，system ui删除文件。
136.因为通知消息通常具有时效性，在一些实现方式中，可以在文件被显示预设的次数后删除文件，或者，在文件的存储时长达到预设时长后删除文件。
137.在另一些实现方式中，从文件的通知消息内容中提取关键词，例如，发布时间、事件、事件的执行事件等，依据关键词判断距离关键词中的时间已过预设时长，则删除文件。
138.在一些实现方式中，system ui通过调用存储管理服务删除文件，在另一些实现方式中，system ui可以从存储单元中删除文件。
139.图8所示的流程，云服务器向app的服务器获取通知消息，并将通知消息转换为电子设备可解析并显示的格式的文件，电子设备获取文件后，在用户触发查看通知消息后，能够以较低的时延显示通知消息，并且，有利于获得较优的用户体验。
140.可以理解的是，图8所示的流程适用于任意一条通知消息的显示。而在多条通知消
息均需被查看的场景下，本实施例所述的显示方法与现有技术相比，具有更大的优势：不仅在用户触发查看通知消息后，能以较低的时延显示通知消息，还能够将多条通知消息进行汇聚显示，更方便用户的查看。
141.可以理解的是，被查看的多条通知消息可以为多个app的推送的通知消息。在此场景下，如图10所示，电子设备需要与多个app的服务器交互的软件框架示例。与图7相比，图10中增加了app2的服务器。
142.以图11a为例，假设电子设备接收到app1的服务器推送的“app1的消息a”和“app1的消息b”，以及接收到app2的服务器推送的“app2的消息a”和“app2的消息b”。用户下拉任务栏，触发图11a所示的通知消息列表，其中包括“app1的消息a”，“app1的消息b”、“app2的消息a”以及“app2的消息b”。
143.假设图11a中，用户预期查看app1的消息a和app2的消息a。
144.图12所示为本技术实施例公开的又一种显示方法，与图8的区别在于，用户点击多条通知消息以查看，如图11a所示的场景。
145.图12中包括以下步骤：
146.s1201、system ui响应于对第一通知消息的摘要的第一操作，显示控件。
147.如图11b所示，用户可以先向左滑动“app1的消息a”，触发执行s1201。
148.s1202、system ui响应于对控件的操作，向云服务器传输第一通知消息的摘要。
149.如图11c所示，用户点击“app1的消息a”右侧显示的“添加到关注”的控件，触发将app1的消息a的摘要向云服务器传输。
150.s1203、云服务器向app1的服务器传输查看第一通知消息的请求。
151.s1204、app1的服务器向云服务器传输第一通知消息。
152.s1205、云服务器将第一通知消息转换为预设格式的文件，这里简称第一文件。
153.s1206、云服务器将第一文件向system ui传输。
154.s1207、system ui将第一文件向存储管理服务传输第一文件，以存储第一文件。
155.s1208、system ui响应于对第二通知消息的摘要的第一操作，显示控件。
156.如图11d所示，用户向左滑动“app2的消息a”，触发执行s1208。
157.s1209、system ui响应于对控件的操作，向云服务器传输第二通知消息的摘要。
158.如图11e所示，用户点击“app2的消息a”右侧显示的“添加到关注”的控件，触发将app2的消息a的摘要向云服务器传输。
159.s1210、云服务器向app2的服务器传输查看第二通知消息的请求。
160.s1211、app2的服务器向云服务器传输第二通知消息。
161.s1212、云服务器将第二通知消息转换为预设格式的文件，这里简称第二文件。
162.s1213、云服务器将第二文件向system ui传输。
163.s1214、system ui向存储管理服务传输第二文件，以存储第二文件。
164.可以理解的是，s1201-s1207中的各步骤，与s1208-s1214中的各步骤之间的执行顺序不做限定。
165.s1215、system ui响应对第一通知消息的摘要或第二通知消息的摘要的操作，通过解析第一文件或第二文件，在同一个显示界面中，显示第一通知消息和第二通知消息。
166.也就是说，对添加关注的任意一条通知消息的摘要的操作，能够触发在一个显示
界面中，显示全部添加关注的通知消息。
167.如图11f所示，用户可以点击“app1的消息a”，或者点击“app2的消息a”。如图11g所示，app1的消息a以及app2的消息a被显示在一个界面中，也就是说，不同app推送的通知消息，被汇聚显示。
168.在一些实现方式中，多条通知消息，可以同时被显示在同一个界面中，也可以按照顺序例如被点击的顺序依次在同一个界面中显示。
169.在另一些实现方式中，在通知消息的摘要的列表中，用户可以选中多条通知消息的摘要，多条通知消息被汇聚显示在同一个界面中。
170.可以理解的是，除了s1215之外，也可以响应于对第一通知消息的摘要或第二通知消息的摘要的操作，通过解析第一通知消息转换得到的文件或者第二通知消息转换得到的文件，显示第一通知消息或者第二通知消息。即显示被用户点击摘要的一条通知消息。
171.对比图3a-图3f与图11a-图11g可以看出，本实施例所述的显示方法，在用户查看不同app的服务器推送的多条通知消息的情况下，除了无需再调用app客户端查看，也可以将多条通知消息汇聚显示，具有较高的便利性。
172.可以理解的是，本实施例中，还可以按照s808的方式删除文件，这里不再赘述。
173.除了不同类型的app的多条通知消息之外，同一app也可以推送多条通知消息的摘要，同一app的多条通知消息也可以汇聚显示。
174.以图13a为例，假设电子设备接收到app1的服务器推送的“app1的消息a”和“app1的消息b”，以及接收到app2的服务器推送的“app2的消息a”和“app2的消息b”。用户下拉任务栏，触发图13a所示的通知消息列表，其中包括“app1的消息a”，“app1的消息b”、“app2的消息a”以及“app2的消息b”。假设图13a中，用户预期查看app1的消息a和app1的消息b。
175.如图13b所示，用户向左滑动“app1的消息a”，触发显示“添加到关注”的控件，触发执行s1201。
176.如图13c所示，用户点击“app1的消息a”右侧显示的“添加到关注”的控件，触发执行s1202。
177.如图13d所示，用户向左滑动“app1的消息b”，触发执行s1208。
178.如图13e所示，用户点击“app1的消息b”右侧显示的“添加到关注”的控件，触发执行s1209。
179.至此，可参见图12所示，电子设备中已存储第一文件和第二文件，本场景示例中，第二文件为app1的消息b转换得到的文件。
180.如图13f所示，用户可以点击“app1的消息a”，也可以点击“app1的消息b”。如图13g所示，app1的消息a以及app1的消息b被显示在一个界面中，也就是说，不同的通知消息，被汇聚显示。
181.对比图2a-图2e与图13a-图13g可以看出，本实施例所述的显示方法，在用户查看同一app的服务器推送的多条通知消息的情况下，除了无需再调用app客户端查看，还可以将多条通知消息汇聚显示,具有更高的便利性。
182.因此，本技术实施例所述的显示方法，不仅能够在用户点击以查看通知消息后，能够以更小的时延显示通知消息，还能够实现用户对多条通知消息的批量查看，能够大大提升查看通知消息的便利性，并且提升用户的使用体验。
183.可以理解的是，图8或图12所示的流程中，system ui发送通知消息的摘要的触发条件还可以为其它条件，例如图8可以替换为图14所示，图14与图8所示的流程的区别在于：
184.system ui响应于接收到第一通知消息的摘要，向云服务器传输第一通知消息的摘要。也就是说，可以无需用户的添加关注的操作，而是以接收到通知消息的摘要为触发条件，自动获取通知消息的文件，为用户后续查看奠定基础。
185.与图8相比，图14所示的流程，因为已经准备好文件，所以在用户点击通知消息后，可以更快显示通知消息，从而能够进一步降低查看通知消息的时延。
186.在某些实现方式中，system ui响应于接收到目标app发送的通知消息的摘要，向云服务器传输第一通知消息的摘要。目标app为配置信息指示的app。即用户可以在电子设备中配置目标app，只要接收到目标app的通知消息的摘要，就向云服务器传输目标app的通知消息的摘要，以实现用户配置执行本技术所述的显示方法的app的目的。
187.可以理解的是，用户配置目标app的方式可以为：用户在通知消息查看模型的配置界面，从app列表中，选择至少一个app作为目标app。app列表中可以包括电子设备中已安装的app。
188.可以理解的是，还可以不设置云服务器，而由system ui实现云服务器的功能，软件框架可以参见图6所示。
189.基于图6，图15为本技术实施例公开的又一种显示方法的流程，与前述流程图相比，区别在于，由system ui向app的服务器传输查看通知消息的请求。与前述流程的相似之处不再赘述。
190.可以理解的是，在以上流程中，均以app的服务器向电子设备发送通知消息的摘要为例进行说明，“摘要”是为了适应电子设备的下拉状态栏的显示区域有限，无法显示通知消息的全部内容而设置。除“摘要”之外，还可以为“标识”、或“标题”等，可以概括为通知消息的第一信息。
191.并且，在以上流程中，云服务器或电子设备向app的服务器发送通知消息的摘要为例进行说明，除“摘要”之外，还可以为“标识”、或“标题”等，可以概括为通知消息的第二信息。在某些实现方式中，第二信息与第一信息相同，在另一些实现方式中，第二信息可以与第二信息不同，只要能告知app的服务器需要查看的是哪一条通知消息即可。