CN116954759A - 一种嵌入式应用页面的启动方法、服务端、客户端及系统 - Google Patents

Abstract

本发明提供了一种嵌入式应用页面的启动方法、服务端、客户端及系统，服务端接收客户端发送的数据请求；服务端确定数据请求所请求的目标数据；服务端获取目标数据对应的压缩数据；服务端将压缩数据反馈给客户端，客户端解析压缩数据以启动嵌入式应用页面。本方案中，预先对嵌入式web应用的源码结构和源码编译进行优化，将服务端需要传递给客户端的数据进行压缩和简化。客户端向服务端发送数据请求时，服务端将目标数据对应的压缩数据发送给客户端来启动嵌入式应用页面，提高嵌入式应用页面的启动速度和提高用户使用体验。

Description

一种嵌入式应用页面的启动方法、服务端、客户端及系统

技术领域

本发明涉及数据处理技术领域，具体涉及一种嵌入式应用页面的启动方法、服务端、客户端及系统。

背景技术

随着用户量增大、应用功能多样化和网络技术的发展，web（网页）应用也在快速发展。为了提高web应用页面的启动速度，目前通过加大服务器资源、提高网络宽带等措施来提高web应用页面的启动速度。

但是对于嵌入式设备而言，由于嵌入式设备本身性能限制，在服务器计算资源方面不够，这样就无法通过加大服务器资源、提高网络宽带等措施来提高嵌入式web应用页面的启动速度。

发明内容

有鉴于此，本发明实施例提供一种嵌入式应用页面的启动方法、服务端、客户端及系统，以提高嵌入式web应用页面的启动速度。

为实现上述目的，本发明实施例提供如下技术方案：

本发明实施例第一方面公开一种嵌入式应用页面的启动方法，所述方法应用于服务端，所述方法包括：

接收客户端发送的数据请求，所述客户端在检测到嵌入式web应用打开时发送所述数据请求；

确定所述数据请求所请求的目标数据，所述目标数据为嵌入式应用页面所需的页面数据；

获取所述目标数据对应的压缩数据；

将所述压缩数据反馈给所述客户端，使所述客户端解析所述压缩数据以启动所述嵌入式应用页面。

优选的，所述目标数据包含第一类数据和第二类数据；

获取所述目标数据对应的压缩数据，包括：

根据预设映射关系和所述第一类数据的原始数据类型，获取所述第一类数据对应的压缩包，所述预设映射关系包含原始数据类型与压缩数据类型的对应关系；

根据所述预设映射关系和所述第二类数据的原始数据类型，获取所述第二类数据对应的经过减小体积处理的第三类数据。

优选的，将所述压缩数据反馈给所述客户端，使所述客户端解析所述压缩数据以启动所述嵌入式应用页面，包括：

根据延迟加载方式，将所述第一类数据对应的压缩包反馈给所述客户端，及将所述第三类数据反馈给客户端，使所述客户端解析所述压缩包和所述第三类数据以启动所述嵌入式应用页面。

优选的，所述第一类数据至少包含以下任意一种或组合：超文本标记语言HTML文件、层叠样式表CSS文件、网页脚本语言文件；所述第二类数据至少包含图片文件。

本发明实施例第二方面公开一种嵌入式应用页面的启动方法，所述方法应用于客户端，所述方法包括：

在检测到嵌入式web应用打开时，向服务端发送数据请求，使所述服务端确定所述数据请求所请求的目标数据并获取所述目标数据对应的压缩数据，所述目标数据为嵌入式应用页面所需的页面数据；

接收所述服务端反馈的所述压缩数据；

解析所述压缩数据以启动所述嵌入式应用页面。

本发明实施例第三方面公开一种服务端，所述服务端包括：

接收单元，用于接收客户端发送的数据请求，所述客户端在检测到嵌入式web应用打开时发送所述数据请求；

确定单元，用于确定所述数据请求所请求的目标数据，所述目标数据为嵌入式应用页面所需的页面数据；

获取单元，用于获取所述目标数据对应的压缩数据；

反馈单元，用于将所述压缩数据反馈给所述客户端，使所述客户端解析所述压缩数据以启动所述嵌入式应用页面。

优选的，所述目标数据包含第一类数据和第二类数据；所述获取单元包括：

第一获取子单元，用于根据预设映射关系和所述第一类数据的原始数据类型，获取所述第一类数据对应的压缩包，所述预设映射关系包含原始数据类型与压缩数据类型的对应关系；

第二获取子单元，用于根据所述预设映射关系和所述第二类数据的原始数据类型，获取所述第二类数据对应的经过减小体积处理的第三类数据。

优选的，所述反馈单元具体用于：根据延迟加载方式，将所述第一类数据对应的压缩包反馈给所述客户端，及将所述第三类数据反馈给客户端，使所述客户端解析所述压缩包和所述第三类数据以启动所述嵌入式应用页面。

本发明实施例第四方面公开一种客户端，所述客户端包括：

发送单元，用于在检测到嵌入式web应用打开时，向服务端发送数据请求，使所述服务端确定所述数据请求所请求的目标数据并获取所述目标数据对应的压缩数据，所述目标数据为嵌入式应用页面所需的页面数据；

接收单元，用于接收所述服务端反馈的所述压缩数据；

解析单元，用于解析所述压缩数据以启动所述嵌入式应用页面。

本发明实施例第五方面公开一种嵌入式应用页面的启动系统，所述系统包括：本发明实施例第三方面公开的服务端，本发明实施例第四方面公开的客户端。

基于上述本发明实施例提供的一种嵌入式应用页面的启动方法、服务端、客户端及系统，服务端接收客户端发送的数据请求；服务端确定数据请求所请求的目标数据；服务端获取目标数据对应的压缩数据；服务端将压缩数据反馈给客户端，客户端解析压缩数据以启动嵌入式应用页面。本方案中，预先对嵌入式web应用的源码结构和源码编译进行优化，将服务端需要传递给客户端的数据进行压缩和简化。客户端向服务端发送数据请求时，服务端将目标数据对应的压缩数据发送给客户端来启动嵌入式应用页面，提高嵌入式应用页面的启动速度和提高用户使用体验。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本发明实施例提供的一种嵌入式应用页面的启动方法的流程图；

图2为本发明实施例提供的嵌入式web应用的开发流程图；

图3为本发明实施例提供的一种服务端的结构框图；

图4为本发明实施例提供的一种客户端的结构框图；

图5为本发明实施例提供的一种嵌入式应用页面的启动系统的结构框图。

具体实施方式

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

在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合背景技术可见，随着用户量增大、应用功能多样化和网络技术的发展，web（网页）应用也在快速发展。为了提高web应用页面的启动速度，目前通过加大服务器资源、提高网络宽带等措施来提高web应用页面的启动速度，例如为了用户能够快速启动web应用，在较快网速和强大的服务器资源加持下能够实现提高web应用页面的启动速度。

但是上述现有技术主要应用在客户端设备性能好、网络技术先进、用户需求多的基础上，却忽略了嵌入式设备的使用场景。对于嵌入式设备而言，由于嵌入式设备本身性能限制，在服务器计算资源方面不够，这样就无法通过加大服务器资源、提高网络宽带等措施来提高嵌入式web应用页面的启动速度。

此外，发明人经研究发现，用户通过客户端的浏览器使用嵌入式web应用时，客户端向服务端请求数据，服务端响应并返回对应的数据，最后在浏览器页面中呈现相应的数据。在这个过程中需要进行数据传输，具体来说，在嵌入式web应用页面启动过程中，客户端首先会向服务端请求相应的页面数据（包含HTML基本结构、CSS样式，JavaScript脚本程序、图片、字体等），由于这些数据较多，故数据会需要一定时间进行传输，嵌入式web应用启动后需要传输大量的文件，这样就会导致嵌入式web应用页面启动速度较慢。

因此，本方案提供一种嵌入式应用页面的启动方法、服务端、客户端及系统，预先对嵌入式web应用的源码结构和源码编译进行优化，将服务端需要传递给客户端的数据进行压缩和简化。客户端向服务端发送数据请求时，服务端将目标数据对应的压缩数据发送给客户端来启动嵌入式应用页面，实现用户打开和浏览嵌入式应用页面快速、流畅，提高用户使用体验和使用效率。

需要说明的是，本方案的嵌入式应用页面为嵌入式web应用页面；本方案中涉及较多的计算机术语，为更好理解本方案，以下先对本方案涉及的部分术语进行解释说明。

web：网页。

HTML：HyperText Markup Language，超文本标记语言，定义了网页内容的含义和结构。

CSS：Cascading Style Sheets，层叠样式表，描述网页样式。

JavaScript：网页脚本语言，简称为js，可实现网页的各种交互功能。

Gzip：若干种文件压缩程序，文件压缩格式。

客户端：用户所使用的浏览器。

服务端：嵌入式设备中的应用程序，也叫web服务器。

源码：开发web应用的源代码。

源码编译：将开发web应用的源代码按照规则转换为真实web应用的过程。

本方案基于嵌入式web应用开发，在开发过程中采用相应措施，使得用户启动嵌入式web应用的速度明显加快，同时在嵌入式web应用使用过程中也能快速、流畅地使用各种功能和服务。以下通过各个实施例对本方案进行解释说明。

参见图1，示出了本发明实施例提供的一种嵌入式应用页面的启动方法的流程图，包括以下步骤：

步骤S101：客户端在检测到嵌入式web应用打开时，向服务端发送数据请求。

在具体实现步骤S101的过程中，用户通过浏览器使用嵌入式web应用时，客户端向服务端发送数据请求，请求获取用于启动（或者说用于生成）嵌入式应用页面的目标数据。

步骤S102：服务端确定数据请求所请求的目标数据。

在具体实现步骤S102的过程中，服务端接收到客户端发送的数据请求后，服务端确定该数据请求所请求的目标数据，其中，目标数据为嵌入式应用页面所需的页面数据（相当于只将嵌入式应用页面所需的数据发送给客户端）。

步骤S103：服务端获取目标数据对应的压缩数据。

需要说明的是，嵌入式web应用的源码由HTML、JavaScript、CSS、图片等数据构成；在嵌入式web应用开发阶段，预先对嵌入式web应用进行源码结构优化和源码编译优化，以得到源码对应的压缩数据。

目标数据包含第一类数据和第二类数据，在对嵌入式web应用进行源码结构优化和源码编译优化的过程中，利用Gzip压缩算法（仅举例）将第一类数据压缩成相应的压缩包，将第二类数据进行减小体积处理以得到对应的第三类数据，例如：假设第二类数据为图片，可以减小该图片的分辨率或者可以将该图片的格式转换成压缩率较高的格式，从而减小该图片的体积，减小体积的图片即为第二类数据对应的第三类数据，“减小分辨率”和“转换成压缩率较高的格式”即为减小体积处理。

“减小体积处理”主要用于减小第二类数据的体积。

一些实施例中，第一类数据至少包含以下任意一种或组合：HTML文件、CSS文件、网页脚本语言文件（JavaScript文件）；第二类数据至少包含图片文件。

在具体实现步骤S103的过程中，目标数据包含第一类数据和第二类数据；服务端根据预设映射关系和第一类数据的原始数据类型，获取该第一类数据对应的压缩包，该预设映射关系包含原始数据类型与压缩数据类型的对应关系。例如：设第一类数据为a.js文件，通过预设映射关系和第一类数据的原始数据类型，找到的压缩包为a.js.gz文件。

服务端根据预设映射关系和第二类数据的原始数据类型，获取第二类数据对应的经过减小体积处理的第三类数据。

其中，上述所获取得到的压缩包和第三类数据即为目标数据对应的压缩数据。

步骤S104：服务端将压缩数据反馈给客户端。

在具体实现步骤S104的过程中，服务端获取得到目标数据对应的压缩数据之后，服务端将所获取的压缩数据反馈给客户端。

具体来说，由于压缩数据包含：第一类数据对应的压缩包、第二类数据对应的经过减小体积处理的第三类数据；故服务端将压缩数据反馈给客户端的具体方式为：服务端根据延迟加载方式，将第一类数据对应的压缩包反馈给客户端，及将第三类数据反馈给客户端。

需要说明的是，延迟加载方式也称为“懒加载”，在源码编译优化阶段，根据页面内容或业务逻辑拆分成不同的代码文件，当嵌入式web应用运行时，只有运行到嵌入式web应用的业务模块时再去执行相应的代码文件。例如：由于图片文件相对于文本文件而言数据体积较大，客户端向服务端请求图片时，如果将全部图片都返回给客户端，势必会造成客户端请求的数据量很大，这样就会影响整个嵌入式web应用页面的启动速度，因此本方案采用延迟加载方式，先将用户看得见的图片发送给客户端进行加载，暂时不加载用户看不见的图片，等到用户滚动到具体的页面位置时再去请求剩余的图片，这样就能够有效减少返回客户端的数据量。

步骤S105：客户端解析压缩数据以启动嵌入式应用页面。

在具体实现步骤S105的过程中，客户端接收到服务端返回的压缩数据后，客户端解析该压缩数据来启动嵌入式应用页面；具体来说，客户端基于第一类数据对应的压缩包、第三类数据启动嵌入式应用页面，由于压缩包和第三类数据是经过压缩的，故客户端需要对这些压缩数据进行解码，再根据解码后的数据启动嵌入式应用页面。

需要说明的是，客户端在生成嵌入式应用页面的过程中，浏览器先通过内部渲染引擎将HTML生成特定的数据结构，同时浏览器对CSS数据进行计算，这两种数据结合起来按照一定该规则生成嵌入式应用页面，此外浏览器还需要对JavaScript数据进行处理使得用户能够对嵌入式应用页面进行操作，最后完成整个嵌入式应用页面的启动。

在本发明实施例中，预先对嵌入式web应用的源码结构和源码编译进行优化，将服务端需要传递给客户端的数据进行压缩和简化。客户端向服务端发送数据请求时，服务端将目标数据对应的压缩数据发送给客户端来启动嵌入式应用页面，提高嵌入式应用页面的启动速度和提高用户使用体验。

通过以上内容可见，本方案预先对嵌入式web应用进行源码结构优化和源码编译优化，从而提高启动嵌入式应用页面的速度。

源码结构优化具体是指：在开发嵌入式web应用过程中，减少不必要的源码，例如压缩图片大小，具体通过减小图片分辨率、采用压缩率较高的图片格式等方式来减小图片大小；剔除不必要的动画特效和页面样式源码，这样就能够减少源代码的体积，进而完成源码结构优化。源码结构优化至少包含以下过程A1-A3的内容。

A1、嵌入式web应用的开发过程中抽取公共使用的代码作为通用模块，使得多个功能可以共用一个通用模块，从而减小源码的体积。

A2、减小图片分辨率，将图片的格式转换为jpeg格式或webp格式，可以减小图片的体积，进而减小源码的体积。

A3、减少动画特效，剔除某些样式代码，从而减小源码的体积。

需要说明的是，源码的大小决定了源码编译以后的嵌入式web应用代码的大小，嵌入式web应用的数据越小，则在嵌入式web应用启动过程中客户端向服务端请求的数据越小，客户端在处理这些从服务端返回的数据并渲染成嵌入式应用页面所消耗的时间也就越小，这样就能够加快嵌入式应用页面的启动速度。

源码编译优化具体是指：只引入嵌入式应用页面所需要的库文件，采用按需加载、懒加载等加载方式，这能够节省大量源码的体积，同时在源码编译中采用压缩算法对源码进行压缩来缩小源码体积，同时在服务端进行相应配置来获取对应的压缩文件，从而提高客户端和服务端之间的数据传输速度。

需要说明的是，库文件指的是开发嵌入式web应用所需要的工具代码库，在开发嵌入式web应用之前，需要进行需求分析来确定需要哪些功能，进而按照所需要的功能来引入所需要的库文件。

针对上述提及的“按需加载”，“按需加载”具体是指：在源码编译时根据嵌入式web应用的功能需要来进行加载；进一步而言，由于在开发嵌入式web应用时会使用一些通用代码库文件，这些通用代码库文件包含大部分的功能模块，但是最后真正用到的功能模块很少，因此可采用按需加载的方式，在编译时去掉其他不需要的模块，这样就可以避免将其它无关的代码编译到最后的嵌入式web应用中。

在进行源码结构优化和源码编译优化的过程中，主要涉及以下B1-B3示出的技术手段。

B1、源码处理：由于嵌入式web应用的开发过程中用到的某些代码库之间有关联，故可以通过解析源码来建立源码结构之间的依赖关系。例如：假设要实现功能A，此时先引入B代码库，然后把功能A封装成一个整体，在实现功能C的时候，需要引入封装好的A，这样A、B和C之间就建立了依赖关系。在源码编译阶段，由于每个代码库都包含多个功能，通过前述建立的依赖关系按需加载，只保留用到的功能，把没有用到的功能剔除，这样就能够减小源码的体积。

B2、图片处理：使用图片处理工具缩小图片分辨率、转换图片格式，在使用图片时，采用图片懒加载方式判断图片是否在嵌入式应用页面的可视范围内，设置图片的地址属性。

B3、源码压缩：采用Gzip等压缩算法将源码进行压缩。

B4、服务端配置：服务端是指存在于嵌入式设备中的应用程序，负责提供嵌入式web应用相关功能。当客户端启动web应用时，客户端会立刻与服务端进行通信来请求数据，服务端会及时处理并返回对应的数据；为实现前述功能，服务端需要进行以下配置：

（1）服务端开发：利用嵌入式设备芯片中的操作系统本身提供的网络编程接口，开发一个web网络服务器，使得客户端能与服务端建立通信，且服务端能够对客户端的请求做出响应。

（2）服务端配置：为了匹配客户端请求的原始数据（也就是上述提及的目标数据）和服务端返回的压缩数据，服务端需要配置数据类型匹配代码，具体包括配置原始数据类型和压缩数据类型的预设映射关系，例如：服务端请求a.js文件，服务端会查找对应的a.js.gz文件（压缩包）并将该a.js.gz文件返回给客户端，这就需要建立a.js和a.js.gz的预设映射关系。服务端配置后，允许客户端向服务端请求目标数据时，服务端返回相应的压缩数据。

以上是关于源码结构优化和源码编译优化的相关说明。

在嵌入式web应用开发并编译完成后，需要将嵌入式web应用上传到服务端，这样才能正常使用嵌入式web应用。因此服务端上会存有嵌入式web应用所需的数据（或文件），这些数据包括HTML、CSS、JavaScript等，其中CSS和JavaScript是嵌入式web应用的主要构成部分。客户端向服务端发送数据请求时，服务端根据客户端所请求的目标数据去做响应，然后会返回客户端所请求的目标数据，从服务端所返回的目标数据需要进行压缩，然后将压缩数据反馈给客户端。

本方案所采用的压缩方式为：在嵌入式web应用开发编译后就对数据进行压缩，然后将压缩数据上传到服务端。

在实际应用中，也可以采用另外一种压缩方式：在嵌入式web应用开发编译后将数据直接上传到服务端，客户端向服务端请求目标数据时，服务端先将目标数据进行压缩，再将压缩数据返回给客户端。但是此种压缩方式对服务端的设备性能要求更高，因此可以根据实际情况来选择合适的压缩方式。

通过以上内容可见，客户端和服务端在进行交互的过程中，客户端向服务端请求没有经过压缩的目标数据（原始数据），服务端查找对应的压缩数据返回给客户端，这样客户端请求回来的数据是经过压缩的，客户端将压缩数据进行解码来恢复成目标数据（原始数据）。由于在客户端和服务端之间传递的数据是经过压缩的，且压缩的数据本身体积较小，因此客户端和服务端之间传递数据的时间就会减小，这样就能够提高传输效率。

结合以上内容，嵌入式web应用的开发流程如图2所示，嵌入式web应用的开发流程主要包含以下步骤：

步骤S201：搭建嵌入式web应用的开发环境。

在具体实现中，安装开发嵌入式web应用所需要的代码库及相关配置。

步骤S202：功能开发。

具体实现中，对嵌入式web应用的源码结构进行优化。

步骤S203：源码编译。

在具体实现中，对嵌入式web应用的源码编译进行优化，具体包括源码压缩、源码按需加载等。

步骤S204：服务端配置。

在具体实现中，服务端进行以下配置：数据请求相关配置、返回客户端数据匹配。

需要说明的是，步骤S201至步骤S204的执行原理，可参见上述各个实施例的内容，在此不再赘述。

本方案通过源码结构优化和源码编译优化，能够大幅度减少客户端和服务端之间数据传输的大小，从而加快数据传输速度，进而提高嵌入式应用页面的启动速度。经验证，源码编译优化前后的文件夹大小对比结果如表1所示。

通过表1可见，源码编译优化后编译文件的大小远小于源码编译优化前编译文件的大小。

为进一步体现本方案能够有效提高嵌入式web应用的启动速度，对本方案和现有技术进行测试和比对，测试相关配置信息如下：

（1）数据来源：

测试工具：某浏览器开发者工具。

浏览器版本：64位的指定版本。

测试平台：指定版本的系统。

（2）测试方式：在网络、设备、测试平台、测试工具等相同的情况下，测试嵌入式web应用启动过程中网络请求数据及相关属性，测试5次并取平均值。

表2为采用现有技术启动嵌入式web应用的相关测试结果，表3为采用本方案启动嵌入式web应用的相关测试结果。

上述表2和表3中，request为请求数据的文件数量，transferred为传输数据的字节大小，resources为请求回来的数据经过解压之后的原始数据的大小，Finish为所有数据请求回来的时间总和，DOMContentLoaded为请求回来的HTML数据解析成特定结构所需要的时间，Load为所有数据加载完成并生成完整页面的总时间。

通过上述表2和表3的测试结果来看，采用本方案启动嵌入式web应用的速度可以缩短到1.22s，极大提升了嵌入式web应用的启动速度。

与上述本发明实施例提供的一种嵌入式应用页面的启动方法相对应，参见图3，本发明实施例还提供了一种服务端的结构框图，该服务端包括：接收单元301、确定单元302、获取单元303、反馈单元304；

接收单元301，用于接收客户端发送的数据请求，客户端在检测到嵌入式web应用打开时发送数据请求。

确定单元302，用于确定数据请求所请求的目标数据，目标数据为嵌入式应用页面所需的页面数据。

获取单元303，用于获取目标数据对应的压缩数据。

反馈单元304，用于将压缩数据反馈给客户端，使客户端解析压缩数据以启动嵌入式应用页面。

优选的，结合图3示出的内容，目标数据包含第一类数据和第二类数据；获取单元303包括第一获取子单元和第二获取子单元，各个子单元的执行原理如下：

第一获取子单元，用于根据预设映射关系和第一类数据的原始数据类型，获取第一类数据对应的压缩包，预设映射关系包含原始数据类型与压缩数据类型的对应关系。

第二获取子单元，用于根据预设映射关系和第二类数据的原始数据类型，获取第二类数据对应的经过减小体积处理的第三类数据。

相应的，反馈单元304具体用于：根据延迟加载方式，将第一类数据对应的压缩包反馈给客户端，及将第三类数据反馈给客户端，使客户端解析压缩包和第三类数据以启动嵌入式应用页面。

一些实施例中，第一类数据至少包含以下任意一种或组合：HTML文件、CSS文件、网页脚本语言文件；第二类数据至少包含图片文件。

在本发明实施例中，预先对嵌入式web应用的源码结构和源码编译进行优化，将服务端需要传递给客户端的数据进行压缩和简化。客户端向服务端发送数据请求时，服务端将目标数据对应的压缩数据发送给客户端来启动嵌入式应用页面，提高嵌入式应用页面的启动速度和提高用户使用体验。

与上述本发明实施例提供的一种嵌入式应用页面的启动方法相对应，参见图4，本发明实施例还提供了一种客户端的结构框图，该客户端包括：发送单元401、接收单元402、解析单元403；

发送单元401，用于在检测到嵌入式web应用打开时，向服务端发送数据请求，使服务端确定数据请求所请求的目标数据并获取目标数据对应的压缩数据，目标数据为嵌入式应用页面所需的页面数据。

接收单元402，用于接收服务端反馈的压缩数据。

解析单元403，用于解析压缩数据以启动嵌入式应用页面。

与上述本发明实施例提供的一种嵌入式应用页面的启动方法相对应，参见图5，本发明实施例还提供了一种嵌入式应用页面的启动系统的结构框图，该启动系统包括服务端501和客户端502。

需要说明的是，服务端501的执行原理参见上述图3示出的内容，客户端502的执行原理参见上述图4示出的内容，在此不再赘述。

综上所述，本发明实施例提供一种嵌入式应用页面的启动方法、服务端、客户端及系统，预先对嵌入式web应用的源码结构和源码编译进行优化，将服务端需要传递给客户端的数据进行压缩和简化。客户端向服务端发送数据请求时，服务端将目标数据对应的压缩数据发送给客户端来启动嵌入式应用页面，提高嵌入式应用页面的启动速度和提高用户使用体验。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种嵌入式应用页面的启动方法，其特征在于，所述方法应用于服务端，所述方法包括：

接收客户端发送的数据请求，所述客户端在检测到嵌入式web应用打开时发送所述数据请求；

确定所述数据请求所请求的目标数据，所述目标数据为嵌入式应用页面所需的页面数据；

获取所述目标数据对应的压缩数据；

将所述压缩数据反馈给所述客户端，使所述客户端解析所述压缩数据以启动所述嵌入式应用页面。

2.根据权利要求1所述的方法，其特征在于，所述目标数据包含第一类数据和第二类数据；

获取所述目标数据对应的压缩数据，包括：

根据预设映射关系和所述第一类数据的原始数据类型，获取所述第一类数据对应的压缩包，所述预设映射关系包含原始数据类型与压缩数据类型的对应关系；

根据所述预设映射关系和所述第二类数据的原始数据类型，获取所述第二类数据对应的经过减小体积处理的第三类数据。

3.根据权利要求2所述的方法，其特征在于，将所述压缩数据反馈给所述客户端，使所述客户端解析所述压缩数据以启动所述嵌入式应用页面，包括：

根据延迟加载方式，将所述第一类数据对应的压缩包反馈给所述客户端，及将所述第三类数据反馈给客户端，使所述客户端解析所述压缩包和所述第三类数据以启动所述嵌入式应用页面。

4.根据权利要求2所述的方法，其特征在于，所述第一类数据至少包含以下任意一种或组合：超文本标记语言HTML文件、层叠样式表CSS文件、网页脚本语言文件；所述第二类数据至少包含图片文件。

5.一种嵌入式应用页面的启动方法，其特征在于，所述方法应用于客户端，所述方法包括：

在检测到嵌入式web应用打开时，向服务端发送数据请求，使所述服务端确定所述数据请求所请求的目标数据并获取所述目标数据对应的压缩数据，所述目标数据为嵌入式应用页面所需的页面数据；

接收所述服务端反馈的所述压缩数据；

解析所述压缩数据以启动所述嵌入式应用页面。

6.一种服务端，其特征在于，所述服务端包括：

接收单元，用于接收客户端发送的数据请求，所述客户端在检测到嵌入式web应用打开时发送所述数据请求；

确定单元，用于确定所述数据请求所请求的目标数据，所述目标数据为嵌入式应用页面所需的页面数据；

获取单元，用于获取所述目标数据对应的压缩数据；

反馈单元，用于将所述压缩数据反馈给所述客户端，使所述客户端解析所述压缩数据以启动所述嵌入式应用页面。

7.根据权利要求6所述的服务端，其特征在于，所述目标数据包含第一类数据和第二类数据；所述获取单元包括：

第一获取子单元，用于根据预设映射关系和所述第一类数据的原始数据类型，获取所述第一类数据对应的压缩包，所述预设映射关系包含原始数据类型与压缩数据类型的对应关系；

第二获取子单元，用于根据所述预设映射关系和所述第二类数据的原始数据类型，获取所述第二类数据对应的经过减小体积处理的第三类数据。

8.根据权利要求7所述的服务端，其特征在于，所述反馈单元具体用于：根据延迟加载方式，将所述第一类数据对应的压缩包反馈给所述客户端，及将所述第三类数据反馈给客户端，使所述客户端解析所述压缩包和所述第三类数据以启动所述嵌入式应用页面。

9.一种客户端，其特征在于，所述客户端包括：

发送单元，用于在检测到嵌入式web应用打开时，向服务端发送数据请求，使所述服务端确定所述数据请求所请求的目标数据并获取所述目标数据对应的压缩数据，所述目标数据为嵌入式应用页面所需的页面数据；

接收单元，用于接收所述服务端反馈的所述压缩数据；

解析单元，用于解析所述压缩数据以启动所述嵌入式应用页面。

10.一种嵌入式应用页面的启动系统，其特征在于，所述系统包括：权利要求6-8中任一所述的服务端，权利要求9所述的客户端。