数据传输方法、装置、终端设备及存储介质与流程

本申请一般涉及计算机技术领域，尤其涉及数据传输方法、装置、终端设备及存储介质。

背景技术：

移动终端产品的开发过程中，为了提高产品的效率和移植便利，一些展示性较强或者需要动态更新的页面会基于h5来实现；对应的，部分功能特性将在本地实现，即通过jsbridge实现页面端与本地端之间的双向通信。

目前，在利用jsbridge实现页面端与本地端的通信过程中，由于jsbridge的局限性，对于大字节参数的传输，页面端或本地端通常将大数据上传到服务器，本地或页面端去服务器下载来获取对应大数据。

对于上述传输方法，将造成移动终端流量及服务器存储空间的耗费，并使得数据传输时间变长，从而降低传输效率，增加业务实现复杂度，影响用户体验。

技术实现要素：

鉴于现有技术中的上述缺陷或不足，期望提供一种数据传输方法、装置、终端设备及存储介质，来提高页面端与本地的数据传输效率，提高用户体验。

第一方面，本申请实施例提供了一种数据传输方法，该方法包括：

接收并响应数据传输指令，对一个或多个第一传输参数进行分包，得到该第一传输参数的多个数据包，并生成每个该数据包的标识；

基于预设的交互协议生成业务消息，并向本地端发送，该业务消息包括该第一传输参数的数据包的标识；

接收该本地端返回的第一数据请求消息，该第一数据请求消息由该本地端解析该业务消息后，基于该交互协议生成，该第一数据请求消息包括该第一传输参数的至少一个数据包的标识；

响应每次接收到的该第一数据请求消息，向该本地端发送数据包，使得该本地端解析接收到的该数据包得到该第一传输参数，该数据包为第一数据请求消息中标识对应的数据包。

第二方面，本申请实施例提供一种数据传输方法，该方法包括：

获取并解析业务消息，得到第一传输参数的数据包的标识，该业务消息由页面端响应于数据传输指令，基于预设的交互协议生成，该业务消息包第一传输参数的数据包的标识；

基于该交互协议生成第一数据请求消息，该第一数据请求消息中包括该待传输参数的至少一个数据包的标识；

向该页面端发送该第一数据请求消息；

接收该页面端响应每个该第一数据请求消息返回的数据包，该数据包为每个该第一数据请求消息中该标识对应的该第一传输参数的数据包。

第三方面，本申请实施例提供的一种数据传输装置，该装置包括：

处理模块，用于接收并响应数据传输指令，对一个或多个第一传输参数进行分包，得到该第一传输参数的多个数据包，并生成每个该数据包的标识；

第一发送模块，用于基于预设的交互协议生成业务消息，并向本地端发送，该业务消息包括该第一传输参数的数据包的标识；

接收模块，用于接收该本地端返回的第一数据请求消息，该第一数据请求消息由该本地端解析该业务消息后，基于该交互协议生成，该第一数据请求消息包括该第一传输参数的至少一个数据包的标识；

第二发送模块，用于响应每次接收到的该第一数据请求消息，向该本地端发送数据包，使得该本地端解析接收到的该数据包得到该第一传输参数，该数据包为第一数据请求消息中标识对应的数据包。

第四方面，本申请实施例提供的一种数据传输装置，该装置包括：

获取模块，用于获取并解析业务消息，得到该第一传输参数的数据包的标识，该业务消息由页面端响应于数据传输指令，基于预设的交互协议生成，该业务消息包第一传输参数的数据包的标识；

生成模块，用于基于该交互协议生成第一数据请求消息，该第一数据请求消息中包括该第一传输参数的至少一个数据包的标识；

发送模块，用于向该页面端发送该第一数据请求消息；

接收模块，用于接收该页面端响应每个该第一数据请求消息返回的数据包，该数据包为每个该第一数据请求消息中该标识对应的该第一传输参数的数据包。

第五方面，本申请实施例提供一种数据传输方法，包括：

接收并响应数据传输指令对一个或多个待传输参数进行分包，得到该待传输参数的多个数据包，并生成每个数据包的标识；

基于预设的交互协议生成数据传输消息，并向页面端发送，该数据传输消息至少包括该待传输参数的数据包的标识；

接收该页面端返回的数据请求消息，该数据请求消息由该页面端解析该数据传输消息后，基于该交互协议及该标识生成，该数据请求消息包括该待传输参数的至少一个数据包的标识；

响应每次接收到的该数据请求消息，向该页面端发送数据包，使得该本地端解析接收到的该数据包得到该待传输参数，该数据包为数据请求消息中标识对应的数据包。

第八方面，本申请实施例提供一种终端设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，该处理器执行该程序时实现如上述所述的方法。

第九方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序用于实现如上所述的方法。

本申请实施例提供的数据传输方法、装置、终端设备及存储介质，本地端或页面端通过确定待传输的数据为大字节参数时，对待传输的大字节参数进行分包处理，并基于预设的交互协议，生成包括大字节参数的数据包标识的业务消息，以使得接收参数的页面端或本地端能够基于业务消息中的分包数据的标识，通过串行多次完成大数据的下载，实现了页面端与本地端之间的大字节参数的高效传输，避免了后台服务器存储空间的占用，节省了移动端的流量消耗，降低了业务复杂度，提升了用户体验。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1所示为本申请实施例的应用场景示意性框图；

图2所示为现有技术中数据传输的示意性框图；

图3所示为本申请实施例的数据传输的示意性框图；

图4所示为本申请实施例的数据传输的流程示意图；

图5所示为本申请又一实施例的数据传输的流程示意图；

图6所示为本申请实施例的数据传输的交互示意图；

图7所示为本申请实施例的数据传输的流程示意图；

图8所示为本申请又一实施例的数据传输的交互示意图；

图9所示为本申请实施例的数据传输装置的结构示意图；

图10所示为本申请又一实施例提供的数据传输装置的结构示意图；

图11所示为本申请又一实施例提供的数据传输装置的结构示意图；

图12所示为本申请又一实施例提供的数据传输装置的结构示意图；

图13所示为本申请实施例的终端设备的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关公开，而非对该公开的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与公开相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本申请实施例提供的数据传输方法，应用于如图1所示场景中的页面端与本地端之间的数据传输。

该本地端可以为运行在终端设备的应用程序，该终端设备可以为配置有安卓或ios平台的终端，如手机或平板电脑等终端。该应用程序可以为基于安卓或ios平台运行的应用程序，如微信等即时通讯app，或者淘宝、京东等购物app，或者支付宝等支付app。则页面端可以为运行在该终端设备上的上述应用程序的操作页面。

可以理解，在上述应用程序启动时，app框架中的web页面将展示在终端设备上。在web页面展示过程中，页面端需要与服务器或本地进行数据交互，例如，基于提前设计的框架，从本地端或服务器获取相应数据，填充在相应的区域内，以一定的效果展示给用户。

可以理解，在上述场景下，预设的交互协议提供了页面端与本地端之间双向通信的通道，可以以不同的代码实现。通过预设的交互协议，页面端可以调用本地侧实现的功能；同样的，本地端也可以调用web页面的某些功能。即可以让本地端调用web页面的代码，页面端也可以调用本地端的代码，使得web页面根据和本地端约定好的规则，通知本地端需要执行的操作。

可以理解，预设的交互协议可以为基于jsbridge的交互协议。则在页面端和本地端基于jsbridge进行通信时，可以定义如jsbridge协议以便区分，即约定的规则。本地端可以拦截web页面的请求，当页面端加载一个链接，本地端可以进行拦截，检测是否符合约定规则，如是否以“jsbridge://”开头，如果是，则拒绝加载并根据该链接携带的参数来执行相应的代码，若否，则正常加载链接。可以理解，约定规则可以为其他形式，如“jsb://”等。

例如，如图1所示，web页面为基于h5开发，通常会在web页面触发一条以“jsbridge://”开头的url，则本地端拦截到该url后，解析该url中的参数并进行对应的业务处理，如调用摄像头或开启相机等操作。本地端完成业务处理后，如果需要回传数据，如回传获取的图像数据，则执行对应的js代码，其中对应的函数保存在“jsbridge://”开头的url中。这样就实现了web页面与本地端的数据交互。

还可以理解，在目前的利用jsbridge来实现页面端与本地端的双向通信时，由于本地端的机器性能的局限，以及url的长度局限，使得两者之间能够传输的数据量非常有限。例如，当传输的数据量非常大时，将导致本地端收不到数据，或者内存激增，app崩溃的问题。

例如，经过测试，在内存容量16g、运行内存1g的iphone6机型上，传输10万字节需要耗时73ms，100万字节耗时201ms。当数据量超过4000万字节后，本地端内存激增，导致app崩溃。而在内存6g的vivonexa机型上时，10万字节的数据传输耗时166ms。当数据流超过130万后，本地端收不到传输的数据。

另外，url的长度上限在不同平台是不一样的，若url越长，则移动端的javescript内核解析所需要的时间成本越高。

因此，鉴于jsbridge的上述缺陷，通过如图2所示的方式进行大字节数据的传输，页面端将需要传输的数据上传到服务器，同时在jsbridge参数中通知本地端对应的资源下载参数。本地端解析到这些参数后，去后台服务器下载对应的数据。同样地，本地端如果传输大字节数据给页面端的话，也需要将数据先上传到后台服务器，页面端拿到对应的资源id后，去服务器请求对应的参数。

为了方便理解和说明，下面通过图3至图13详细阐述本申请实施例提供的数据传输方法、装置、终端设备及存储介质。

可以理解，如图3所示，本申请提供的数据传输方法，页面端及本地端都可以作为大数据的传输方或接收方，即页面端或本地端，根据业务需求，都可以通过中间层，生成以jsbridge开头的url，进行大数据传输，即通过jsbridge来调用对方的代码，执行业务。

例如，通常在页面端来启动本地端与页面端的通信，页面端首先需要对参数进行组装，生成业务消息，即触发一个url。如果有字节数超上限的大字节参数传输，则在中间层将大字节的参数进行格式化，若没有，则直接透传参数。数据格式化完成后通过jsbridge调用本地端的代码。本地端通过拦截url的方式获得业务消息后，首先通过中间层对业务消息进行处理，若有大字节的参数，则从页面端下载完数据后，将格式化的参数转变成jsbridge的一般参数格式；若无，则可以直接获取业务消息中参数。本地端解析参数后进行业务处理，并进一步通过jsbridge将回传数据回调前端。若有大字节的回传参数传输，则将回传参数经过本地端的中间层格式化之后；若无，则透传回传参数。页面端接收到本地端的回传参数后，通过页面端中间层。若有大字节的参数，则先从本地端下载完原始的回传参数，进一步将数据格式化成一般格式的回传参数。若无，则透传回传参数。

为了便于理解，可以将页面端及本地端的中间层分为四个模块：参数处理模块，数据处理模块，大数据传输模块，大数据下载模块。

参数处理模块：参数处理模块负责格式化数据，主要作用是判断参数是否需要以大数据模式传输，格式化大数据传输参数。

数据处理模块：数据处理模块主要提供数据的分包处理，生成大数据传输所需参数，数据包标识，分包数(count)，提供大字节传输参数的存储和获取。

传输模块：传输主要负责传输分包数据。

下载模块主要负责下载数据包，并对数据传输消息进行校验。

为了更好理解本申请的数据传输的详细过程，下面通过图4至图6说明本申请提供的数据传输方法。

图4所示为本申请实施例的数据传输方法的流程示意图，如图4所示，该方法由页面端作为数据传输方执行，具体包括：

s401，接收并响应数据传输指令，对一个或多个第一传输参数进行分包，得到该第一传输参数的多个数据包，并生成每个该数据包的标识；

s402，基于预设的交互协议生成业务消息，并向本地端发送，该业务消息包括该第一传输参数的数据包的标识；

s403，接收该本地端返回的第一数据请求消息，该第一数据请求消息由该本地端解析该业务消息后，基于该预设的交互协议生成，该第一数据请求消息包括该第一传输参数的至少一个数据包的标识；

s404，响应每次接收到的该第一数据请求消息，向该本地端发送数据包，使得该本地端解析接收到的该数据包得到该第一传输参数，该数据包为第一数据请求消息中标识对应的数据包。

具体的，本申请实施例中，如在微信平台下，用户的操作触发某个业务场景，该场景中需要页面端将数据传输给本地端，即在页面端接收到用户触发的数据传输指令后，响应该数据传输指令，基于页面端与本地端约好的规则，进行参数传输。该待传输的参数可以为较小字节数的业务参数，如用于调用本地端的摄像头的业务参数；或者包括大量字节的数据参数，如微信平台中多个好友信息的大量数据。即待传输参数可以包括大字节量的第一传输参数，和/或小字节量的第二传输参数，第一传输参数的字节数大于预设阈值。

此时，当待传输的参数中存在一个或多个第一传输参数时，则页面端首先可以对第一传输参数进行分包处理，得到第一传输参数的多个数据包。并可以生成每个数据包的标识。然后进行传输参数组装，形成大字节的参数格式的消息，即可以将待传输的第一参数名称及该参数对应的数据包的标识一起封装到一个url中，生成业务消息。可以理解，该业务消息可以为以预设的交互协议规定的格式的url，且包括有第一传输参数的每个数据包的标识、数据包的数量及对应的参数名称。另外，如果待传输参数还存在第二传输参数时，该业务消息中还包括所有的第二传输参数。

进而通过预设的交互协议调用本地端，使得本地端在拦截到该url时，通过解析该url，获取其中的标识，并生成第一数据请求消息。第一数据请求消息由本地端解析业务消息后，基于该交互协议生成，第一数据请求消息中至少包括待请求的第一传输参数的至少一个数据包的标识。最后，在页面端每接收到一个第一数据请求消息后，响应本次接收到的该数据请求消息，向本地端发送待第一数据请求消息中的标识对应的数据包，使得本地端通过多次的数据包请求与接收，得到第一传输参数的所有数据包，进而通过解析数据包得到第一传输参数。

本申请实施例中，在页面端需要将待传输数据传输至本地端时，通过将大字节的待传输参数进行分包，并生成对应的每个数据包的标识，进而基于预设的交互协议生成一个url，使得本地端在拦截到该url后，可以基于数据包的标识，多次从页面端下载获取到大字节的待传输参数的数据包，实现页面端与本地端之间的大字节的参数传输，避免了通过服务器作为中转的方式，节省了本地端的流量，提高了数据传输效率，提升了用户体验。

图5所示为本申请又一实施例提供的数据传输方法的流程示意图，如图5所示，该方法由本地端作为数据接收方来执行，该方法包括：

s501，获取并解析业务消息，得到第一传输参数的数据包的标识，该业务消息由页面端响应于数据传输指令，基于预设的交互协议生成，该业务消息包第一传输参数的数据包的标识；

s502，基于该预设的交互协议生成第一数据请求消息，该第一数据请求消息中包括该待传输参数的至少一个数据包的标识

s503，向页面端发送第一数据请求消息。

s504，接收页面端响应每个第一数据请求消息返回的数据包。

具体的，本申请实施例中，本地端可以实时的获取页面端触发的url，并获取后，进行解析判断。页面端通常会触发基于http协议、https协议或者预设的交互协议的业务消息。则当页面端触发一条以预设的交互协议的url，。本地端可以确定为本地端发送的需要自己处理的业务，则拒绝加载该url。进一步解析该url中携带的参数，该url中可以包括传输参数，或者还可以包括传输参数的数据包的标识，即页面端有大字节的参数传输，即该业务消息中可以包括第一传输参数的数据包的标识和/或第二传输参数。

当该url中包括第一传输参数的数据包的标识时，进而可以响应该携带数据包标识的业务消息，基于预设的交互协议及标识生成第一数据请求消息，每个第一数据请求消息中可以包括第一传输参数的至少一个数据包的标识，并通过串行的方式发送给页面端，使得页面端可以响应每个第一数据请求消息，每次向本地端返回相应的一个或多个数据包，进而使得本地端从页面端逐个获取到数据包。最后，可以将获取的所有数据包进行格式转换，得到完整的待传输参数，并基于约定的规则，执行该参数对应的业务。

本申请实施例中，本地端通过截取基于预设的交互协议协议封装的url，并利用解析到的数据包的标识，多次从页面端获取被分包的待传输参数，实现了大字节参数在页面端与本地端的直接传输，提高了传输效率，降低了用户流量耗费，提升了用户体验。

图6所示为又一实施例提供的数据传输方法，该方法由页面端及本地端执行，在该方法中，页面端及本地端都可以作为数据发送及接受方，具体包括：

s601，页面端接收数据传输指令，并响应于数据传输指令，确定一个或多个待传输参数；

s602，当待传输参数中存在所述第一传输参数时，对待传输参数中的第一传输参数分包，得到第一传输参数的多个数据包，并生成每个数据包的标识；

s603，页面端基于jsbridge生成业务消息。

s604，页面端向本地端发送业务消息。

具体的，在某个终端设备上运行某平台的应用程序时，如微信等，该应用程序的web页面在开始加载，或者用户在操作时，需要与本地端进行数据交互，如将其上的数据传输给本地端。

例如，安卓平台或ios平台中运行有微信，当某用户在选择器的web页面上依次选择多个好友，以将某内容转发给选中的好友。该场景下，则页面端需要将选中的所有好友信息发送给本地端。实际中，当用户通过滑动或点击完成按钮时，页面端可以接收到数据传输指令。此时，页面端可以确定待传输参数，如上述场景下，需要传输选中的多个好友信息。页面端首先需要确定待传输参数的字节数的大小，并与预设阈值进行对比，以根据对比结果确定执行不同的操作。

实际中，可以通过对该web所在平台性能进行测试，或结合该平台所在的终端的性能，设定一个阈值，如10万字符串，从而可以根据该预设阈值来判断待传输参数是否为大字节参数。

如果上述场景下，待传输参数(选中的好友信息)的字节数小于该阈值，可以直接对待传输的参数进行包装，以符合页面端与本地端的传输规则，即生成的业务消息中只有待传输的第二传输参数。。

如果上述场景下，待传输参数(选中的好友数量)非常庞大，字节数大于该预设阈值，表示待传输参数中存在大字节的第一传输参数则执行s602，对待传输的第一传输参数进行分包处理。

如图7所示，可以将第一传输参数发送给数据处理模块，数据处理模块可以以每10个用户的信息作为一个数据包，对该第一传输参数进行分包处理，得到多个数据包，并为每个数据包配置一个标识。则在参数处理模块，实现待传输参数的格式化，将大字节参数的多个数据包的标识封装在业务消息中，得到业务消息。

优选的，为了方便数据传输，在业务消息中还可以封装有大字节参数标识，如可以为“largedatainfo”，该大字节参数标识可用于本地端识别业务消息中是否有大字节参数传输。如当本地端解析业务消息后，发现业务消息中携带有大字节参数标识，则确定页面端有大字节的参数传输。进而可以通过数据请求消息从页面端获取大字节参数的数据包。

进一步，该业务消息中还可以包括第一传输参数的所有数据包的数量以及第一传输参数的属性及名称。

在完成上述参数的格式化后，将生成的业务消息发送给本地端，以调用本地端的代码。

s605，本地端获取并解析业务消息。

具体的，本申请实施例中，本地端实时获取页面端触发的url，并检测获取到的url是否符合jsb协议。如果不符合，如基于http协议或https协议，继续加载该业务请求消息。如果符合，说明需要本地端解析识别该业务请求消息中的参数，并执行对应的业务。

s606，当业务消息中包括大字节参数标识时，本地端基于jsbridge生成第一数据请求消息，该第一数据请求消息中包括第一传输参数的数据包的标识。

s607，本地端向页面端发送第一数据请求消息。

具体的，在本申请实施例中，本地端截取到业务消息后，对业务消息进行解析，并判断是否有大字节参数标识。

当本地端解析上述的业务消息，发现url中携带有大字节参数标识时，如上述格式化后的“largedatainfo”标识，则表示页面端有大字节参数传输。进一步，可以解析得到大字节参数的每个数据包的标识、数据包的数量及该大字节参数的名称及属性，如参数类型。

在解析到大字节参数的数据包的标识后，本地端可以利用该标识进行大字节参数的获取。如，首先将第一个数据包的标识添加在js函数中，生成第一个数据包的数据请求消息，即第一数据请求消息，并通过调用jsbridege，返回给页面端。

s608，页面端接收并解析第一数据请求消息。

s609，响应第一数据请求消息，页面端生成第一数据传输消息。

s610，页面端向本地端发送第一数据传输消息。

具体的，页面端在接收到本地端传输的第一数据请求消息后，通过解析，得到其包括的数据包的标识。进而可以通过数据传输模块将该标识对应的第一传输参数的数据包封装在url中，即以jsbridege开头，触发一个url的第一数据传输消息，以将请求的数据包发送给本地端。

s611，本地端对第一数据传输消息进行验证。

s612，基于验证结果，生成第一数据重传消息或第一后继数据请求消息。

s613，本地端向页面端发送第一数据重传消息或第一后继数据请求消息。

s614，页面端接收并解析第一数据重传消息或第一后继数据请求消息，生成第二数据传输消息。

s615，页面端向本地端发送第二数据传输消息。

具体的，本地端在获取数据包时，可以利用校验模块进行对第一数据传输消息校验。如通过校验，当在预设时间段内未拦截到页面端触发的以jsbridege开头的url，即未收到第一数据传输消息，或者通过解析发现第一数据传输消息中的数据包缺失时，表示上一次请求的数据包传输失败，需要向页面端重新请求，则可以生成用于请求上一次请求的数据包的第一数据重传消息。

当通过校验第一数据传输消息，解析得到当前时刻请求的数据包时，表示上一次请求的数据包接收完成，则可以对该数据包进行保存。并且，生成后继的下一个数据包的请求消息，即第一后继数据请求罅隙，用于请求下一数据包。例如，基于下一个数据包的标识，调用js函数，获取下一数据包。例如，下一个数据包的请求消息可以携带用于指示下一数据包的标识，如下一个数据包自己的标识，或者基于当前成功接收的数据包的基础上，逐步加一，生成新的标识。

可以理解，通过上述方法，本地端可以从页面端多次获取到待传输参数的数据包，并存储。

s616，本地端对获取的数据包进行解析，得到第一传输参数。

具体的，在得到第一传输参数的所有的数据包后，可以将每个数据包进行拼接，格式化成为原始的第一传输参数格式。

例如，在上述的微信转发消息场景中，本地端在接收到所有好友用户对应的数据包后，可以经过格式化，得到所有好友用户的参数信息。

在经过上述步骤，页面端可以将待传输的大字节参数通过串行的方式多次传输给本地端。本地端可以通过并行或串行的方式对大数据进行存储。

可以理解，在s607中，当本地端解析业务消息后，未发现有大字节参数标识时，则可以直接获取到url中页面端传输的所有待传输参数，即第二传输参数。进而可以基于该参数，执行相应的业务，如开启摄像头等操作。并在操作完成后，可以基于url中调用的js函数，向页面端回传参数，如开启成功的反馈消息等。具体可以将待返回的参数添加在截取的url中调用的js函数(如图1所示的function)中。即在执行完s607后，执行s617。

s617，本地端响应业务消息，确定回传参数。

s618，当回传参数中存在第一回传参数时，对第一回传参数进行切分处理，得到第一回传参数的多个数据包，并生成每个数据包的标识。

s619，本地端基于jsbridge，生成回传消息；

s620，本地端向页面端发送回传消息。

具体的，在本地端获取到业务消息，即拦截页面端触发的以jsbridge打头的一个url，可以基于该参数，执行相应的业务处理，并在执行完成业务消息中参数对应的业务后。如果需要回传参数，则可以响应该业务消息，向页面端返回回传参数，即基于jsbridge，将待返回的参数添加在url中的调用的js函数中。相应的，回传参数中同样存在大字节的参数，即回传消息包括待传输的第一回传参数的数据包的标识和/或待传输的第二回传参数。

例如，当业务消息中的参数表示需要执行业务时，可以返回执行结果对应的回传参数；或者，当业务消息中的参数表示需要获取数据时，本地端可以将页面端请求的数据作为回传参数返回给页面端。即可以将待回传的参数添加在js函数中，通过调用jsbridge实现待回传参数的回传。

例如，在上述微信平台下，用户需要将某内容转发给多个好友的场景下，用户在本地端操作时，即需要本地端将用户的所有好友信息发送给选择器的页面端，以使得页面端能够显示用户的所有好友，以供选择。

可以理解，在本地端返回回传参数时，同样需要判断回传参数的大小。当回传参数的字节数大于预设阈值时，如所有好友的信息的第一回传参数，可以在本地端的数据处理模块中对第一回传参数进行切分，得到第一回传参数的多个数据包，并生成每个数据包的标识。进而可以基于jsbridge，在参数处理模块中，将大字节参数标识、每个数据包的标识、数据包个数及第一回传参数名称等添加到回传消息中，即将上述内容添加到js函数中。

可以理解，当回传参数的字节数不大于预设阈值时，则可以直接将回传参数添加在js函数中，如第二回传参数，使得生成的回传消息中包括原始的回传参数。

s621，页面端接收并解析该回传消息。

s622，页面端基于jsbridge生成第二数据请求消息，

s623，并向本地端发送第二数据请求消息。

具体的，在页面端接收到本地端返回的回传消息后，可以解析该消息。当发现该回传消息中有大字节参数标识时，表示本地端回传的参数有大字节参数，如第一回传参数。此时，页面端可以基于该第一回传参数的数据包的标识生成第二数据请求消息。该第二数据请求消息中携带有第一回传参数的至少一个数据包的标识，用于向本地端获取第一回传参数的至少一个数据包。即页面端在接收到本地端返回的回传消息后，触发一个url，该url种携带有第一回传参数的至少一个数据包的标识。

可以理解，当在解析回传消息中没有发现大数据标识时，表示回传的参数中没有大字节参数标识，则可以直接从回传消息中得到回传参数，即第二回传参数，即执行完s621后，可以直接执行s632。

s624，本地端接收并解析第二数据请求消息。

s625，本地端响应于第二数据请求消息，生成第三数据传输消息。

s626，本地端向页面端发送第三数据传输消息。

具体的，本地端在接收到第二数据请求消息后，可以对该数据请求消息进行解析，并根据解析到的第一回传参数的数据包的标识，将该标识对应的第一回传参数的数据包添加到js函数，即生成第三数据传输消息，并向页面端发送。

s627，页面端对第三数据传输消息进行校验。

s628，页面端基于校验结果生成第二数据重传消息；或生成第二后继数据请求消息。

s629，面端向本地端发送第二数据重传消息或第二后继数据请求消息。

s630，本地端生成第四数据传输消息。

s631，本地端向页面端发送第四数据传输消息。

s632，获取的回传消息或数据包进行解析，得到回传参数。

具体的，当在预设时间段内没有收到第三数据传输消息，或者收到第三数据传输消息，经解析后发现待请求的第一回传参数的数据包缺失，则表示待请求的数据包传输失败。此时，页面端可以生成第二数据请求消息，使得本地端将当前请求的数据包重新发送。

如果经过检验发现当前的数据包成功接收，则可以生成后继的下一个数据包的请求消息，用于请求本地端的第一回传参数的下一数据包。

进一步，在页面端通过串行得到回传参数的所有数据包后，可以将所有的数据包存储在数据处理模块，并且对数据包进行格式化，转换成原始的第一回传参数。

可以理解，经过上述的阐述，本申请实施例提供的页面端与本地端数据传输的完整流程，即从页面端触发一个业务消息，至本地端将回传参数返回给页面端，在jsbridge框架下，通过将待传输的大字节参数分包处理，以使得页面端及本地端可以直接从对方获取参数，避免了利用服务器的上传或下载，提高了数据传输效率，节省了服务器内存及用户流量，提高了用户体验度。

还可以理解，在上述实施例中，页面端与本地端的数据传输由页面端触发的一个url来启动。除此之外，还可以通过预先定好的规则，由本地端基于预先设定好的js函数主动向页面端发送大字节参数，即触发页面端与本地端的数据传输。

图8所示为本申请实施例提供的由本地端主动触发向页面端传输大字节参数的方法，如图8所示，该方法包括：

s801，本地端接收数据传输指令，确定待传输参数；

s802，当待传输参数中存在第一传输参数时，对第一传输参数进行分包，得到第一传输参数的多个数据包，并生成每个数据包的标识；

s803，本地端生成数据传输消息；

s804，本地端向页面端发送数据传输消息；

s805，页面端接收本地端发送的数据传输消息；

s806，页面端解析该数据传输消息，并基于jsbridge生成数据请求消息；

s807，页面端向本地端发送数据请求消息；

s808，本地端接收数据请求消息；

s809，本地端响应每次接收到的数据请求消息，向页面端发送数据请求消息中标识对应的第一传输参数的数据包。

s810，页面端接收本地端返回的数据包。

s811，页面端解析接收到的数据包或数据传输消息，得到第一传输参数。

具体的，在本申请实施例中，本地端可以基于预先约定的js函数，，根据待传输参数字节数大小，将待传输的参数或参数的数据包标识加载在js函数中，发送给页面端，实现本地端到页面端的大数据传输。如当待传输参数的字节数大于预设阈值，即第一传输参数，可以对第一传输参数分包，得到第一传输参数的多个数据包，并生成每个第一传输参数的数据包的标识，进而可以基于jsbridge及标识生成数据传输消息。页面端可以接收到包括第一传输参数的数据包的标识数据传输消息，以响应数据传输消息，生成数据请求消息，每个数据请求消息中包括第一传输参数的至少一个数据包的标识，使得本地端可以响应每个数据请求消息，以串行的方式将数据包分多次传输给页面端，使得页面端可以在接收到所有数据包后，解析得到第一传输参数。

本申请实施例提供的数据传输方法，本地端可以将待传输的参数分割成多个数据包，并基于jsbridge及预先约定的js函数，将大字节的传输参数的数据包标识发送给页面端，使得页面端可以基于数据包标识，多次从本地端获取到待传输参数的所有数据包，最后经过格式化解析，得到待传输的原始参数，避免了通过服务器的上传及下载，节省了服务器内存消耗及用户流量消耗，提高了用户体验度。

图9所示为本申请实施例提供的数据装置的结构示意图，如图8所示，该装置900包括：

处理模块910，用于接收并响应数据传输指令，对一个或多个第一传输参数进行分包，得到该第一传输参数的多个数据包，并生成每个该数据包的标识；

第一发送模块920，用于基于预设的交互协议生成业务消息，并向本地端发送，该业务消息包括该第一传输参数的数据包的标识；

第一接收模块930，用于接收该本地端返回的第一数据请求消息，该第一数据请求消息由该本地端解析该业务消息后，基于该预设的交互协议生成，该第一数据请求消息包括该第一传输参数的至少一个数据包的标识；

第二发送模块940，用于响应每次接收到的该第一数据请求消息，向该本地端发送数据包，使得该本地端解析接收到的该数据包得到该第一传输参数，该数据包为第一数据请求消息中标识对应的数据包。

可选的，本申请实施例提供的数据传输装置，第一接收模块930包括：

第一接收单元931，用于接收第一数据重传请求消息，该第一数据重传请求消息包括上一次请求的该第一传输参数的数据包的标识；

或者，

第二接收单元932，用于接收第一后继数据请求消息，该第一后继数据包请求消息包括下一次请求的该第一传输参数的数据包的标识。

可选的，本申请实施例提供的数据传输装置，该业务消息中还包括一个或多个第二传输参数，该第一传输参数的字节数大于预设阈值。

可选的，本申请实施例提供的数据传输装置，还包括：

第二接收模块950，用于接收该本地端基于jsbridge返回的响应于该业务消息的回传消息，该回传消息包括该本地端待传输的第一回传参数的数据包的标识和/或该本地端待传输的第二回传参数，该第一回传参数的字节数大于预设阈值。

可选的，本申请实施例提供的数据传输装置，当回传消息中包括该本地端待传输的第二回传参数对应的数据包标识时，还该装置还包括：

解析模块960，用于解析该回传消息，得到该第二回传参数对应的数据包标识；

生成模块970，用于基于该第二回传参数对应的数据包标识生成第二数据请求消息，并向该本地端发送该第二数据请求消息；

第三接收模块980，用于接收该本地端响应该第二数据请求消息返回的该第二回传参数对应的数据包。

可选的，本申请实施例提供的数据传输装置，生成模块具体用于若在预设时间段内未收到当前时刻请求的该第二参数对应的数据包，生成第二数据重传请求消息，该第二数据重传请求消息中包括当前时刻请求的该第二参数对应的数据包的标识；

否则，基于该第二回传参数对应的数据包的标识生成第二后继数据包请求消息，该第二后继数据包请求消息包括下一次请求的该第二参数对应的数据包的标识。

图10所示为本申请又一实施例提供的数据传输装置，该装置100包括：

获取模块110，用于获取并解析业务消息，得到该第一传输参数的数据包的标识，该业务消息由页面端响应于数据传输指令，基于预设的交互协议生成，该业务消息包第一传输参数的数据包的标识；

生成模块120，用于基于该预设的交互协议生成第一数据请求消息，该第一数据请求消息中包括该第一传输参数的至少一个数据包的标识；

发送模块130，用于向该页面端发送该第一数据请求消息；

接收模块140，用于接收该页面端响应每个该第一数据请求消息返回的数据包，该数据包为每个该第一数据请求消息中该标识对应的该第一传输参数的数据包。

可选的，本申请实施例提供的数据传输装置，该生成模块120具体用于：

若在预设时间段内未收到上一次请求的该待传输参数对应的数据包，生成第一数据重传请求消息，该第一数据重传请求消息包括上一次请求的该第一传输参数的数据包的标识；

否则，生成第一后继数据请求消息，该第一后继数据请求消息包括下一次请求的该第一传输参数的数据包的标识。

可选的，本申请实施例提供的数据传输装置，还包括：

解析模块150，用于基于该第一传输参数的数据包的标识对该数据包进行解析，得到该第一传输参数。

可选的，本申请实施例提供的数据传输装置，还包括：

回传模块160，用于响应于该业务消息，基于预设的交互协议向该页面端返回回传消息，该回传消息包括待传输的第一回传参数的数据包的标识和/或待传输的第二回传参数，其中，该业务消息中还包括第二传输参数，该第一传输参数及该第一回传参数的字节数大于预设阈值。

可选的，本申请实施例提供的数据传输装置，当该回传消息包括待传输的第一回传参数的数据包的标识时，回传模块160具体包括：

确定单元161，用于基于该业务消息确定回传参数；

处理单元162，用于当回传参数中存在第一回传参数时时，对第一回传参数进行切分处理，得到多个该第一回传参数对应的数据包，并生成每个数据包的标识；

生成单元163，用于基于jsbridge生成该回传消息，该回传消息至少包括该第一回传参数的数据包的标识；

第一发送单元164，用于向页面端发送该回传消息；

接收单元165，用于接收该页面端返回的第二数据请求消息，该第二数据请求消息包括该第一回传参数的至少一个数据包的标识；

第二发送单元166，用于响应于每次接收到的该第二数据请求消息，向该页面端发送该第二数据请求消息中的标识对应的该第一回传参数的数据包，使得该页面端解析接收到的该数据包得到该第一回传输参数。

可选的，本申请实施例提供的数据传输装置，该接收单元165，具体用于：

接收第二数据重传请求消息，该第二数据重传请求消息中包括上一次请求的该第一回传参数对应的数据包的标识；

或者，

接收第二后继数据请求消息，该第二后继数据包请求消息包括下一次请求的该第一回参数对应的数据包的标识。

图11所示为本申请又一实施例提供的数据传输装置，该装置110包括：

处理模块101，接收并响应数据传输指令对一个或多个待传输参数进行分包，得到该待传输参数的多个数据包，并生成每个数据包的标识；

生成模块102，基于预设的交互协议生成数据传输消息，并向页面端发送，该数据传输消息至少包括该待传输参数的数据包的标识；

接收模块103，接收该页面端返回的数据请求消息，该数据请求消息由该页面端解析该数据传输消息后，基于该预设的交互协议及该标识生成，该数据请求消息包括该待传输参数的至少一个数据包的标识；

发送模块104，响应每次接收到的该数据请求消息，向该页面端发送数据包，使得该本地端解析接收到的该数据包得到该待传输参数，该数据包为第一数据请求消息中标识对应的数据包。

图12所示为本申请又一实施例提供的数据传输装置，该装置120包括：

第一接收模块121，用于接收数据传输消息，该数据传输消息由本地端基于预设的交互协议生成，该数据传输消息包括第一传输参数的数据包的标识和/或第二传输参数，该第一传输参数的字节数大于预设阈值；

处理模块122，用于解析该数据传输消息，当该数据传输消息中存在第一传输参数时，基于该jsbridge生成数据请求消息，该数据请求消息包括该第一传输参数的至少一个数据包的标识；

发送模块123，用于向该本地端发送该数据请求消息；

第二接收模块124，用于接收该本地端响应每个该数据请求消息返回的数据包，该数据包为每个该数据请求消息中该标识对应的该第一传输参数的数据包。

另一方面，本申请实施例提供的终端设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，该处理器执行该程序时实现如上该的数据传输方法。

下面参考图13，图13为本申请实施例的终端设备的计算机系统300的结构示意图。

如图13所示，计算机系统300包括中央处理单元(cpu)301，其可以根据存储在只读存储器(rom)302中的程序或者从存储部分303加载到随机访问存储器(ram)303中的程序而执行各种适当的动作和处理。在ram303中，还存储有系统300操作所需的各种程序和数据。cpu301、rom302以及ram303通过总线304彼此相连。输入/输出(i/o)接口305也连接至总线304。

以下部件连接至i/o接口305：包括键盘、鼠标等的输入部分306；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分307；包括硬盘等的存储部分308；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分309。通信部分309经由诸如因特网的网络执行通信处理。驱动器310也根据需要连接至i/o接口305。可拆卸介质311，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器310上，以便于从其上读出的计算机程序根据需要被安装入存储部分308。

特别地，根据本申请的实施例，上文参考流程图3-8描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在机器可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分303从网络上被下载和安装，和/或从可拆卸介质311被安装。在该计算机程序被中央处理单元(cpu)301执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，例如，可以描述为：一种处理器包括处理模块、第一发送模块、接收模块及第二发送模块。其中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定，例如，第二发送模块还可以被描述为“用于响应每次接收到的该第一数据请求消息，向该本地端发送数据包，使得该本地端解析接收到的该数据包得到该第一传输参数，该所述数据包为所述第一数据请求消息中所述标识对应的数据包”。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中的。上述计算机可读存储介质存储有一个或者多个程序，当上述前述程序被一个或者一个以上的处理器用来执行描述于本申请的数据传输方法。

综上所述，本申请实施例提供的数据传输方法、装置、终端设备及存储介质，本地端或页面端通过确定待传输的数据为大数据时，对待传输数据进行分包处理，并基于预设的交互协议，生成包括分包数据对应的标识的业务消息，以使得接收数据的页面端或本地能够基于业务消息中的分包数据的标识，依次完成大数据的下载，实现了页面端与本地端之间的大数据的高效传输，避免了后台服务器存储空间的占用，节省了移动端的流量消耗，降低了业务复杂度，提升了用户体验。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。