基于H5页面的数据预加载方法、装置及电子设备与流程

基于h5页面的数据预加载方法、装置及电子设备
技术领域
1.本技术涉及h5技术领域，尤其是涉及到一种基于h5页面的数据预加载方法、装置、存储介质及电子设备。


背景技术：

2.智能手机的普及和移动互联网的发展，都为html5(hypertext markup language 5，超文本标记语言5，简称h5)的发展提供了良好的环境。当前，html5已被广泛应用于移动app(应用程序)产品中。基于h5端和native(原生)端的hybird(混合应用)开发模式具有低成本、高效率、跨平台等优点。


技术实现要素：

3.有鉴于此，本技术提供了一种基于h5页面的数据预加载方法、装置、存储介质及电子设备，主要目的在于针对多webview h5实现数据预加载。
4.依据本技术的一个方面，提供了一种基于h5页面的数据预加载方法，用于基于多webview h5进行数据异步预加载，其中，h5端与native端基于通信协议进行双向通信，所述方法包括：在加载目标webviewurl之前：所述native端响应于目标webview预加载触发条件，获取所述目标webview的预请求配置项；以及，根据所述目标webview的预请求配置项，从网络侧预先获取目标webview的配置数据，并以所述预请求配置项为索引，将所述配置数据存储在所述native端的数据缓存池中。
5.依据本技术的一个方面，提供了一种基于数据预加载的h5页面实现方法，用于基于数据异步预加载实现h5多webview，其中，h5端与native端基于通信协议进行双向通信，所述方法包括：在加载目标webviewurl时，所述native端在本地的数据缓存池中以预请求配置项为索引查找配置数据；若查找成功，则将查找到的目标webview的配置数据发送给所述h5端，使得h5端根据配置数据进行页面渲染。
6.依据本技术的一个方面，提供了一种基于h5页面的数据预加载装置，用于基于多webview h5进行数据异步预加载，所述装置包括h5端和native端，h5端与native端基于通信协议进行双向通信，其中，所述native端用于，在加载目标webviewurl之前，响应于目标webview预加载触发条件，获取所述目标webview的预请求配置项；以及，根据所述目标webview的预请求配置项，从网络侧预先获取目标webview的配置数据，并以所述预请求配置项为索引，将所述配置数据存储在所述native端的数据缓存池中。
7.依据本技术的一个方面，提供了一种基于数据预加载的h5页面实现装置，用于基于数据异步预加载实现h5多webview，所述装置包括h5端和native端，其中，所述native端用于：在加载目标webviewurl时，在本地的数据缓存池中以预请求配置项为索引查找配置数据；若查找成功，则将查找到的目标webview的配置数据发送给所述h5端，使得h5端根据配置数据进行页面渲染。
8.依据本技术的一个方面，提供了一种存储介质，所述存储介质中存储有计算机程
序，其中，所述计算机程序被设置为运行时执行上述基于h5页面的数据预加载方法或基于数据预加载的h5页面实现方法。
9.依据本技术的一个方面，提供了一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述基于h5页面的数据预加载方法或基于数据预加载的h5页面实现方法。
10.借由上述技术方案，本技术提供的一种基于h5页面的数据预加载方法、装置、存储介质及电子设备，针对会场页面等多webview场景下接口耗时较长的问题，为了缩短页面加载耗时，native端在特定触发时机触发预请求操作，将请求的配置数据存储到native端本地的数据缓存池中，从而在后续webview阶段，直接读取本地数据缓存池中预先加载的配置数据，提供给h5端进行页面渲染即可，而无需使native端在webview阶段现从网络侧请求配置数据，节省网络开销，减少延迟，改善用户体验。
11.上述说明仅是本技术技术方案的概述，为了能够更清楚了解本技术的技术手段，而可依照说明书的内容予以实施，并且为了让本技术的上述和其它目的、特征和优点能够更明显易懂，以下特举本技术的具体实施方式。
附图说明
12.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
13.图1示出了本技术实施例提供的一种基于h5页面的数据预加载方法流程图；
14.图2示出了本技术实施例提供的一种基于h5页面的数据预加载方法框架示意图；
15.图3示出了本技术实施例提供的一种基于h5页面的数据预加载方法示意图；
16.图4示出了本技术实施例提供的一种基于h5页面的数据预加载方法示例一流程图；
17.图5示出了本技术实施例提供的一种基于h5页面的数据预加载方法示例二流程图；
18.图6示出了本技术实施例提供的一种基于h5页面的数据预加载方法示例三流程图；
19.图7示出了本技术实施例提供的一种基于h5页面的数据预加载方法示例四流程图；
20.图8示出了了本技术实施例提供的一种基于数据预加载的h5页面实现方法流程图。
具体实施方式
21.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分的实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本技术保护的范围。需要说明的是，在不冲突的情况下，本技术中的实施例及实施例中的特征可以相互组合。
22.本技术实施例可以应用于移动终端的app上。移动终端可以为手机、平板电脑、可穿戴设备，等等。移动终端的操作系统可以为ios系统(苹果公司开发的操作系统)、android(安卓)系统，等等。
23.随着移动互联网的发展，移动app产品已经成为移动互联网产品最大的流量渠道，企业为了追求开发成本、产品质量、用户体验和开发效率，h5端(前端)和native端(原生端)融合开发的模式是必然的趋势。目前，移动app产品通常会采用h5端承载服务，native端承载基础组件服务(如加载h5页面并提供页面路由等)的方式进行开发。
24.以外卖app为例，在促销日或促销期间，往往要实现多webview(网页视图)的h5页面，例如，多tab(页面标签)会场场景，从而吸引用户。实际中，会场页面的首屏接口调用耗时较长，部分甚至达2s以上。为了缩短页面加载耗时，本技术实施例提供一种基于h5页面的数据预加载方法，以针对多webview h5页面的场景下，提高页面数据加载的效率，提升用户体验。
25.参见图1，为本技术实施例提供的一种基于h5页面的数据预加载方法，其中，h5端与native端基于通信协议进行双向通信。该基于h5页面的数据预加载方法，在加载目标webviewurl(uniform resource locator，统一资源定位符)之前，执行如下步骤s101-s102。
26.s101：native端响应于目标webview预加载触发条件，获取目标webview的预请求配置项。
27.s102：根据目标webview的预请求配置项，从网络侧预先获取目标webview的配置数据，并以预请求配置项为索引，将配置数据存储在native端的数据缓存池中。
28.webview是指网页视图，可以内嵌在移动端，实现前端的混合式开发。其中，目标webview是指待预加载的webview，例如，可以是多webview h5的首屏webview，也可以是用户页面操作所针对的webview，也可以是h5端通过jsapi调用所针对的指定webview，后文会有具体例子进行详细说明。
29.本技术实施例中，针对多webview h5场景，提供多种触发预加载的时机和方式，例如，在路由阶段触发首屏webview预加载，在h5容器阶段进行首屏webview预加载、在h5容器阶段响应于用户页面操作(点击tab切换webview、顶部pageheader(页面指示器)滑动或者切换，等)进行的webview预加载，以及，h5端调用jsapi进行指定webview预加载。
30.下面以多webview会场页面应用场景和具体实施示例，对本技术实施例提供的基于h5页面的数据预加载方法行示意性说明。
31.术语解释如下。
32.webview，指网页视图，可以内嵌在移动端，实现前端的混合式开发。
33.h5容器，是移动端基于webview的解决方案，提供了良好的外部扩展功能，拥有jsapi(javascript api，javascript语言编程接口)定制、事件机制等能力。
34.pha(改进hybrid app)容器，是提升hybrid体验的一种新框架，可认为是一种特定h5容器，pha容器可实现多tab会场页面。
35.jsbridge，是为javascript提供调用native功能的接口。
36.以外卖app为例，在促销日或促销期间，往往要实现多tab会场页面，从而吸引用户。多tab会场页面中，在顶部或底部有导航的多个tab(页面标签)，如果采用普通h5容器，
且每次点击tab都需要加载网络端页面数据，则之前打开过的tab也要重新创建和加载，体验不佳。因此，可利用pha容器的优越性能，实现多tab会场。
37.参见图2，为本技术实施例提供的一种基于h5页面的数据预加载方法的框架示意图。图中示出了路由阶段、容器阶段(h5容器或pha容器)、webview阶段，以及服务(service)阶段。本技术实施例提供的基于h5页面的数据预加载方法，可在webview阶段之前实现，例如是在路由阶段或容器阶段实现。
38.参见图3，为本技术实施例提供的一种基于h5页面的数据预加载方法示意图。
39.如前分析的，会场页面的首屏接口耗时较长，部分甚至达2s以上，为了缩短页面加载耗时，可对首屏webview进行预请求。首先，提前确定预请求配置，然后，在触发时机(路由阶段或容器阶段的首屏启动、响应于用户页面操作、h5端通过jsbridge调用指定webview时)，触发预请求操作，最后，native端在预请求操作被触发时，根据预请求配置，从网络侧获取到目标webview(首屏webview或指定webview)的配置数据，完成数据预先加载，从而在后续webview阶段，直接读取本地数据缓存池中预先加载的配置数据，提供给h5端进行页面渲染，而无需使native端在webview阶段现从网络侧请求配置数据，节省网络开销，提高页面加载效率，减少延迟，改善用户体验。
40.示例一：路由阶段触发预加载。
41.参见图4，为本技术实施例提供的一种基于h5页面的数据预加载方法示例一流程图，该示例一在路由阶段触发预加载，对已确定的首屏webview的页面数据进行预加载。
42.其中，h5端(也可称为前端)、native端和后端，都是用开发语言编写的应用程序；配置平台是java等语言开发的平台。可以理解，native端和h5端，可以理解为app端，位于用户侧，后端和配置平台可以理解为服务器端，位于网络侧。例如：
43.h5端，是h5、js、css、图片等组成的html页，需要发布到网络侧。
44.native端：开发语言为安卓或者ios编写的应用程序。
45.后端：部署在网络侧，会返回给h5端或者native端所需的数据。
46.配置平台：提供开关及配置数据，部署在网络侧。
47.该示例一中，还具体描述了，native端在路由阶段建立预请求配置项的预请求库，容器阶段进行url加载，以及，在webview阶段基于预加载的配置数据实现页面渲染。下面具体说明。
48.s401：app启动。
49.s402：预请求库初始化。
50.预请求库可以理解是一个数据库，位于native端，用于存储预请求配置项。预请求配置项是指待预加载的目标webview的关键信息，例如，预请求配置项可以包括目标webviewurl对应的接口path、参数、header等信息。在native端进行预请求库的初始化过程，从而确定可进行预加载的多个目标webview。
51.s403：向配置平台请求预请求配置项，以请求到的预请求配置项更新预请求库。
52.s404：以scheme形式触发多webview h5容器启动路由。
53.urlscheme是一种页面内跳转协议，通过定义scheme协议，可以非常方便跳转app中的各个页面。
54.app可以向操作系统注册一个url scheme，该scheme用于从浏览器或其他应用中
启动本应用。通过指定的url字段，可以使app在被调起后直接打开某些特定页面，比如商品详情页、活动详情页等等；也可以执行某些指定动作，如完成支付等；也可以在应用内通过html页来直接调用显示app内的某个页面。
55.综上，url scheme使用场景大致分以下几种：(1)服务器下发跳转路径，客户端根据服务器下发跳转路径跳转相应的页面；(2)h5页面点击锚点，根据锚点具体跳转路径跳转具体的页面；(3)app端收到服务器端下发的push通知栏消息，根据消息的点击跳转路径跳转相关页面；(4)app根据url跳转到另外一个app指定页面。完整的urlscheme中包含有url链接等信息。
56.s405：从scheme中解析出webview url。
57.s406：根据解析出的webview url在预请求库中进行匹配：若匹配成功，执行s407步骤，若匹配不成功，执行s408步骤。
58.s407：向后端请求获取首屏webview的配置数据，并存储到数据缓存池中。
59.根据s405解析出的webview url在预请求库中匹配之后，根据匹配结果，从预请求库中调取出预请求配置项，以预请求配置项为索引，向后端发起数据预请求，并将请求到的配置数据存储在native端的数据缓存池中。
60.在一种实现方式中，通过设置一个预请求记录管理模块，对数据缓存池的数据缓存记录进行管理，此种方式中，上述s407步骤的具体执行过程如下：
61.首先，根据解析出的预请求配置项进行网络请求之前，预请求记录管理模块查找数据缓存池，确定是否已针对该预请求配置项进行过数据缓存；然后，如果已经缓存过，则无需发起网络请求，如果没有缓存过，发起网络请求，将请求到的配置数据存入到数据缓存池中之后，在预请求记录管理模块中进行记录。
62.至此，预请求流程结束。可见，此例子中是在路由阶段触发预请求，具体的，此方式适用于多webview h5场景下预先确定好首屏webview的情形，在已确定首屏webview的情况下，从scheme中解析出webview url即首屏url，针对该webviewurl在预请求库中进行预请求配置项的匹配，若匹配成功，则启动网络请求，完成首屏webview配置数据的预加载。
63.下面的步骤涉及容器阶段和webview阶段，实现基于预加载进行页面渲染。
64.s408：多webviewh5容器启动。
65.s409：向后端发起请求，从配置参数库中请求获取首屏webview url。
66.需要说明的是，该s409步骤中仅向后端请求获取首屏webview url，而无需请求多webview的配置数据。
67.从网络侧预先获取目标webview的配置数据，并以所述预请求配置项为索引，将所述配置数据存储在所述native端的数据缓存池中
68.s410：与h5端交互，进行首屏webview加载url。
69.具体的，native端通过webview加载h5端首屏主文档，h5端通过特定native jsbridge将接口path、参数、header等预请求配置项提供给native端去拉取页面数据配置。
70.s411：以预请求配置项为索引在数据缓存池进行匹配，获取首屏webview配置数据。
71.在一种实现方式中，首先到预请求记录管理模块查找缓存记录，若，查找到记录且配置数据已成功存入数据缓冲池，则从数据缓存池中调取出预请求配置项对应的配置数
据；若，查找到记录且配置数据正在请求中，还未成功存入数据缓冲池，则暂时进行等待，待预请求数据下载完成并成功存入之后，再从数据缓存池中调取出预请求配置项对应的配置数据；如果没有查找到记录，则向后端发起网络请求，从后端获取到配置数据。
72.s412：native端将配置数据提供给h5端。
73.s413：h5端根据配置数据进行页面元素展示或相应资源下载。
74.其中，配置数据具体可以包括产品信息数据，根据配置数据再去下载js、css、图片等资源类文件。s414：完成首屏渲染。
75.示例二：容器启动阶段触发预加载。
76.参见图5，为本技术实施例提供的一种基于h5页面的数据预加载方法示例二流程图，该示例二在容器阶段触发预加载，对从多个webview中确定首屏webview并进行页面数据预加载。
77.该示例二与示例一不同之处在于触发预加载时机不同，对于相同步骤及说明可参见示例一。
78.s501：app启动。
79.s502：预请求库初始化。
80.s503：向配置平台请求预请求配置项，以请求到的预请求配置项更新预请求库。
81.s504：多webviewh5容器启动。
82.s505：向后端发起请求，从配置参数库中获取解析出首屏webview url。
83.向后端发起请求，从配置参数库中获取多webview容器中各webveiw所需的配置参数，例如，配置参数包括：webview url、title(标题)、tab icon(标签图标)、key(关键值)、tab title color(标签标题颜色)、page header(页面高度)等，并从中取出已打标为首屏webview的url。
84.s506：根据解析出首屏webview url在预请求库中进行匹配：若匹配成功，执行s507步骤，若匹配不成功，执行s508步骤。
85.s507：向后端请求获取首屏webview的配置数据，并存储到数据缓存池中。
86.s508：初始化webview。
87.s509：与h5端交互，进行首屏webview加载url。
88.s510：以预请求配置项为索引在数据缓存池进行匹配，获取首屏webview配置数据。在一种实现方式中，首先到预请求记录管理模块查找缓存记录，若，查找到记录且配置数据已成功存入数据缓冲池，则从数据缓存池中调取出预请求配置项对应的配置数据；若，查找到记录且配置数据正在请求中，还未成功存入数据缓冲池，则暂时进行等待，待预请求数据下载完成并成功存入之后，再从数据缓存池中调取出预请求配置项对应的配置数据；如果没有查找到记录，则向后端发起网络请求，从后端获取到配置数据。
89.s511：native端将配置数据提供给h5端。
90.s512：h5端根据配置数据进行页面元素展示或相应资源下载。
91.s513：完成首屏渲染。
92.示例三：响应于用户页面操作而触发预加载。
93.参见图6，为本技术实施例提供的一种基于h5页面的数据预加载方法示例三流程图，该示例三响应于用户页面操作而触发预加载。
94.该示例三与示例一、示例二不同之处在于触发预加载时机不同，对于相同步骤及说明可参见示例一和示例二。
95.s601：native端响应用户页面操作。
96.页面操作包括但不限于：页面滑动操作、页面标签点击操作，或，页面指示器点击或切换操作。
97.s602：解析页面操作对应的目标webview url。
98.s603：根据解析出的目标webview url在预请求库中进行匹配：若匹配成功，执行s604步骤，若匹配不成功，执行605步骤。
99.s604：向后端请求获取解析出的目标webview的配置数据，并存储到数据缓存池中。
100.s605：初始化目标webview。
101.s606：与h5端交互，进行目标webview加载url。
102.s607：以预请求配置项为索引在数据缓存池进行匹配，获取目标webview的配置数据。
103.在一种实现方式中，首先到预请求记录管理模块查找缓存记录，若，查找到记录且配置数据已成功存入数据缓冲池，则从数据缓存池中调取出预请求配置项对应的配置数据；若，查找到记录且配置数据正在请求中，还未成功存入数据缓冲池，则暂时进行等待，待预请求数据下载完成并成功存入之后，再从数据缓存池中调取出预请求配置项对应的配置数据；如果没有查找到记录，则向后端发起网络请求，从后端获取到配置数据。
104.s608：native端将配置数据提供给h5端。
105.s609：h5端根据配置数据进行页面元素展示或相应资源下载。
106.s610：完成页面渲染。
107.示例四：响应于h5端调用而触发预加载。
108.参见图7，为本技术实施例提供的一种基于h5页面的数据预加载方法示例四流程图，该示例四响应于h5端调用而触发预加载。
109.该示例四与示例一、示例二、示例四不同之处在于触发预加载时机不同，对于相同步骤及说明可参见示例一、示例二和示例三。
110.s701：h5端运行容器线程。
111.例如，启动h5容器的worker线程，该worker线程执行js脚本。通过容器线程，可得到webview相关数据。
112.s702：通过jsbridge，native端从h5端获取目标webview url。
113.jsbridge，是给javascript提供调用native功能的接口。本示例中，native端和h5端通过jsbridge进行通信。
114.s703：根据目标webview url在预请求库中进行匹配：若匹配成功，执行s704步骤，若匹配不成功，不发起预请求。
115.s704：向后端请求获取解析出的目标webview的配置数据，并存储到数据缓存池中。
116.至此，完成数据预请求。
117.s705：h5端响应任意触发场景。
118.该任意触发场景，可以是用户页面操作场景或者页面自动跳转场景等。
119.s706：native端与h5端交互，进行目标webview加载url。
120.s707：以预请求配置项为索引在数据缓存池进行匹配，获取目标webview的配置数据。
121.在一种实现方式中，首先到预请求记录管理模块查找缓存记录，若，查找到记录且配置数据已成功存入数据缓冲池，则从数据缓存池中调取出预请求配置项对应的配置数据；若，查找到记录且配置数据正在请求中，还未成功存入数据缓冲池，则暂时进行等待，待预请求数据下载完成并成功存入之后，再从数据缓存池中调取出预请求配置项对应的配置数据；如果没有查找到记录，则向后端发起网络请求，从后端获取到配置数据。
122.s708：native端将配置数据提供给h5端。
123.s709：h5端根据配置数据进行页面元素展示或相应资源下载。
124.s710：完成页面渲染。
125.另外，本技术实施例还提供一种基于数据预加载的h5页面实现方法，请参见图8，为该基于数据预加载的h5页面实现方法流程图。
126.s801：在加载目标webviewurl之前，native端响应于目标webview预加载触发条件，获取目标webview的预请求配置项；根据目标webview的预请求配置项，从网络侧预先获取目标webview的配置数据，并述预请求配置项为索引，将配置数据存储在native端的数据缓存池中。
127.s802：在加载目标webviewurl时，native端在本地的数据缓存池中以预请求配置项为索引查找配置数据；若查找成功，则将查找到的目标webview的配置数据发送给h5端，使得h5端根据配置数据进行页面渲染。
128.其中，步骤s801包括以下任一种实现方式：
129.(1)native端响应于以scheme形式对多webview h5容器进行的路由启动操作，从scheme中解析出目标webviewurl；根据目标webview url在预请求库中进行匹配，得到目标webview的预请求配置项。
130.(2)native端响应于多webview h5容器启动的操作，向网络侧请求从多webview所需加载所有配置数据中进行查找，确定出目标webviewurl；根据目标webview url在预请求库中进行匹配，得到目标webview的预请求配置项。
131.(3)native端响应于用户页面操作，获取页面操作对应的目标webviewurl；根据目标webviewurl在预请求库中进行匹配，得到目标webview的预请求配置项。
132.(4)native端响应于h5端基于jsapi的预加载请求，获取到目标webviewurl；根据目标webview url在预请求库中进行匹配，得到目标webview的预请求配置项。
133.另外，在native端响应于目标webview预加载触发条件之前，还可以包括如下步骤：对预请求库进行初始化，确定可进行预加载的页面；以及，从网络侧获取可进行预加载页面的预请求配置项，以预请求配置项更新预请求库。
134.可见，本技术实施例提供的方法，针对会场页面等多webview场景下接口耗时较长的问题，为了缩短页面加载耗时，native端在触发时机(路由阶段或容器阶段的首屏启动、响应于用户页面操作、h5端通过jsbridge调用指定webview时)，触发预请求操作，将请求的配置数据存储到native端本地的数据缓存池中，从而在后续webview阶段，直接读取本地数
据缓存池中预先加载的配置数据，提供给h5端进行页面渲染即可，而无需使native端在webview阶段现从网络侧请求配置数据，节省网络开销，减少延迟，改善用户体验。
135.与上述基于h5页面的数据预加载方法相对应，本技术实施例还提供一种基于h5页面的数据预加载装置，用于基于多webview h5进行数据异步预加载，所述装置包括h5端和native端，h5端与native端基于通信协议进行双向通信，其中，所述native端用于，在加载目标webviewurl之前，响应于目标webview预加载触发条件，获取所述目标webview的预请求配置项；以及，根据所述目标webview的预请求配置项，从网络侧预先获取目标webview的配置数据，并以所述预请求配置项为索引，将所述配置数据存储在所述native端的数据缓存池中。
136.在一种实现方式中，所述native端具体用于：响应于以scheme形式对多webview h5容器进行的路由启动操作，从所述scheme中解析出所述目标webview url；根据所述目标webview url在预请求库中进行匹配，得到所述目标webview的预请求配置项。
137.在一种实现方式中，所述native端具体用于：响应于多webview h5容器启动的操作，向网络侧请求从多webview所需加载所有配置数据中进行查找，确定出所述目标webviewurl；根据所述目标webview url在预请求库中进行匹配，得到所述目标webview的预请求配置项。
138.在一种实现方式中，所述native端具体用于：响应于用户页面操作，获取所述页面操作对应的目标webview url；根据所述目标webview url在预请求库中进行匹配，得到所述目标webview的预请求配置项。
139.在一种实现方式中，所述页面操作包括页面滑动操作、页面标签点击操作，或，页面指示器点击或切换操作。
140.在一种实现方式中，所述native端响具体用于：响应于h5端基于jsapi的预加载请求，获取到目标webview url；根据所述目标webview url在预请求库中进行匹配，得到所述目标webview的预请求配置项。
141.在一种实现方式中，所述native端还用于：对预请求库进行初始化，确定可进行预加载的多个目标webview；从网络侧获取可进行预加载的多个webview的预请求配置项，以所述预请求配置项更新所述预请求库。
142.在一种实现方式中，所述native端还用于：启动对目标webview url的加载；在本地的所述数据缓存池中以预请求配置项为索引查找配置数据；若查找成功，则将查找到的目标webview的配置数据发送给所述h5端，使得h5端根据配置数据进行页面渲染。
143.与上述基于数据预加载的h5页面实现方法相对应，本技术实施例还提供一种基于数据预加载的h5页面实现装置，用于基于数据异步预加载实现h5多webview，所述装置包括h5端和native端，其中，所述native端用于：在加载目标webviewurl时，在本地的数据缓存池中以预请求配置项为索引查找配置数据；若查找成功，则将查找到的目标webview的配置数据发送给所述h5端，使得h5端根据配置数据进行页面渲染。
144.在一种实现方式中，所述native端还用于：响应于目标webview预加载触发条件，获取所述目标webview的预请求配置项；根据所述目标webview的预请求配置项，从网络侧预先获取目标webview的配置数据，并以所述预请求配置项为索引，将所述配置数据存储在所述native端的数据缓存池中。
145.在一种实现方式中，所述native端具体用于：响应于以scheme形式对多webview h5容器进行的路由启动操作，从所述scheme中解析出所述目标webviewurl；根据所述目标webview url在预请求库中进行匹配，得到所述目标webview的预请求配置项。
146.在一种实现方式中，所述native端具体用于：响应于多webview h5容器启动的操作，向网络侧请求从多webview所需加载所有配置数据中进行查找，确定出所述目标webviewurl；根据所述目标webview url在预请求库中进行匹配，得到所述目标webview的预请求配置项。
147.在一种实现方式中，所述native端具体用于：响应于用户页面操作，获取所述页面操作对应的目标webviewurl；根据所述目标webviewurl在预请求库中进行匹配，得到所述目标webview的预请求配置项。
148.在一种实现方式中，所述页面操作包括页面滑动操作、页面标签点击操作，或，页面指示器点击或切换操作。
149.在一种实现方式中，所述native端具体用于：响应于h5端基于jsapi的预加载请求，获取到目标webviewurl；根据所述目标webview url在预请求库中进行匹配，得到所述目标webview的预请求配置项。
150.在一种实现方式中，所述native端还用于：对预请求库进行初始化，确定可进行预加载的页面；从网络侧获取可进行预加载页面的预请求配置项，以所述预请求配置项更新所述预请求库。
151.本技术的实施例还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
152.可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：
153.用于基于多webview h5进行数据异步预加载，其中，h5端与native端基于通信协议进行双向通信，所述方法包括：在加载目标webviewurl之前：所述native端响应于目标webview预加载触发条件，获取所述目标webview的预请求配置项；以及，根据所述目标webview的预请求配置项，从网络侧预先获取目标webview的配置数据，并以所述预请求配置项为索引，将所述配置数据存储在所述native端的数据缓存池中。
154.或者，
155.基于数据预加载的h5页面实现方法，用于基于数据异步预加载实现h5多webview，其中，h5端与native端基于通信协议进行双向通信，所述方法包括：在加载目标webviewurl时，所述native端在本地的数据缓存池中以预请求配置项为索引查找配置数据；若查找成功，则将查找到的目标webview的配置数据发送给所述h5端，使得h5端根据配置数据进行页面渲染。
156.可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(read-only memory，简称为rom)、随机存取存储器(random access memory，简称为ram)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
157.本技术的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
158.可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。
159.可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：
160.用于基于多webview h5进行数据异步预加载，其中，h5端与native端基于通信协议进行双向通信，所述方法包括：在加载目标webviewurl之前：所述native端响应于目标webview预加载触发条件，获取所述目标webview的预请求配置项；以及，根据所述目标webview的预请求配置项，从网络侧预先获取目标webview的配置数据，并以所述预请求配置项为索引，将所述配置数据存储在所述native端的数据缓存池中。
161.或者，
162.基于数据预加载的h5页面实现方法，用于基于数据异步预加载实现h5多webview，其中，h5端与native端基于通信协议进行双向通信，所述方法包括：在加载目标webviewurl时，所述native端在本地的数据缓存池中以预请求配置项为索引查找配置数据；若查找成功，则将查找到的目标webview的配置数据发送给所述h5端，使得h5端根据配置数据进行页面渲染。
163.可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。
164.上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
165.在本技术的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
166.在本技术所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
167.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
168.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
169.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的
介质。
170.以上所述仅是本技术的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。