CN114615259A

CN114615259A - 文件传输方法、装置及终端设备

Info

Publication number: CN114615259A
Application number: CN202210361593.9A
Authority: CN
Inventors: 陈修良; 赵子昂
Original assignee: PAX Computer Technology Shenzhen Co Ltd
Current assignee: Shenzhen Zhaolong Technology Co ltd
Priority date: 2022-04-07
Filing date: 2022-04-07
Publication date: 2022-06-10
Also published as: WO2023193599A1

Abstract

本申请提供了文件传输方法、装置及终端设备，适用于数据传输技术领域，该方法包括：获取多种通信方式；利用多种通信方式，将待传输文件的文件内容并行传输至接收端。本申请可以极大地提高文件传输效率，使得文件传输速度加快，传输时间减少。

Description

文件传输方法、装置及终端设备

技术领域

本申请属于数据传输技术领域，尤其涉及文件传输方法、装置及终端设备。

背景技术

随着信息时代的发展和技术的进步，数据正在***式增长。随之增加的不仅是数据的数量，还有单个文件的体积。例如，一张图片的体积从几KB增长至几十M，一首歌曲的体积从几百KB增长至几十M，一个视频的体积从几M增长至几十G。

大体积的文件往往可以承载更多的信息，从而给用户带来更加优质的文件使用体验，但同时也给文件传输带来了更大的挑战。受限于终端设备之间通信方式的传输速度，用户若想在不同终端设备之间传输文件，往往需要等待较长的时间，从而导致用户体验下降。

综上，目前亟需一种可以快速传输文件的方法，以提高对文件的传输速度，减少文件传输时间。

发明内容

有鉴于此，本申请实施例提供了文件传输方法、装置及终端设备，可以解决现有技术中文件传输时间较长的问题。

本申请实施例的第一方面提供了一种文件传输方法，应用于发送端，包括：

获取多种通信方式。

利用多种通信方式，将待传输文件的文件内容并行传输至接收端。

在第一方面的第一种可能的实现方式中，获取多种通信方式，包括：

获取可与接收端进行文件传输的通信方式。

从可与接收端进行文件传输的通信方式中确定出多种通信方式。

在第一方面的第二种可能的实现方式中，从可与接收端进行文件传输的通信方式中确定出多种通信方式，包括：

获取待传输文件的文件体积，并根据文件体积从可与接收端进行文件传输的通信方式中确定出多种通信方式。或者

获取待传输文件的文件体积和文件数量，并根据文件体积和文件数量，从可与接收端进行文件传输的通信方式中确定出多种通信方式。或者

获取可与接收端进行文件传输的通信方式中，每种通信方式的传输速度和传输稳定性。根据传输速度和传输稳定性，从可与接收端进行文件传输的通信方式中确定出多种通信方式。

在第一方面的第三种可能的实现方式中，在从可与接收端进行文件传输的通信方式中确定出多种通信方式之前，还包括：

获取可与接收端进行文件传输的通信方式中，每种通信方式在发送端中的使用状态。

根据每种通信方式的使用状态，对可与接收端进行文件传输的通信方式进行筛选，并基于筛选后剩余的通信方式，执行从可与接收端进行文件传输的通信方式中确定出多种通信方式的操作。

在第一方面的第四种可能的实现方式中，利用多种通信方式，将待传输文件的文件内容并行传输至接收端，包括：

在待传输文件中确定一个或多个起始位置点，并确定出多种通信方式中，每种通信方式分别对应的起始位置点。

控制多种通信方式中的每种通信方式，从各自对应的起始位置点处开始，并行传输待传输文件的文件内容至接收端。

在第一方面的第五种可能的实现方式中，利用多种通信方式，将待传输文件的文件内容并行传输至接收端，还包括：

获取多种通信方式中每种通信方式的传输任务量。

在利用多种通信方式，将待传输文件的文件内容并行传输至接收端的过程中，包括：

若在完成对待传输文件的传输之前，多种通信方式中存在通信方式已完成其对应的传输任务量，则利用该已完成对应传输任务量的通信方式，对待传输文件中未传输的文件内容进行并行传输。

在第一方面的第六种可能的实现方式中，多种通信方式包括第一通信方式和第二通信方式。起始位置点共有两个，分别为待传输文件的文件头部和文件尾部。其中，第一通信方式对应文件头部，第二通信方式对应文件尾部。

控制多种通信方式中的每种通信方式，从各自对应的起始位置点处开始，并行传输待传输文件的文件内容至接收端，包括：

控制第一通信方式从文件头部开始，第二通信方式从文件尾部开始，并行传输待传输文件的文件内容至接收端。

本申请实施例的第二方面提供了一种文件传输装置，包括：

通信获取模块，用于获取多种通信方式。

并行传输模块，用于利用多种通信方式，将待传输文件的文件内容并行传输至接收端。

本申请实施例的第三方面提供了一种终端设备，所述终端设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使得终端设备实现如上述第一方面中任一项所述文件传输方法的步骤。

本申请实施例的第四方面提供了一种计算机可读存储介质，包括：存储有计算机程序，所述计算机程序被处理器执行时，使得终端设备实现如上述第一方面中任一项所述文件传输方法的步骤。

本申请实施例的第五方面提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面中任一项所述文件传输方法。

本申请实施例的第六方面提供了一种芯片***，所述芯片***包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述第一方面任一项所述的文件传输方法。

其中，芯片***可以是单个芯片或者，多个芯片组成的芯片模组。

可以理解的是，上述第二方面至第六方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

本申请实施例与现有技术相比存在的有益效果是：本申请实施例同时使用发送端和接收端支持的多种通信方式，对待传输文件的文件内容进行并行传输。通过同时使用多种通信方式进行文件传输，可以极大地提高文件传输效率，使得文件传输速度加快，传输时间减少。进而可以提高文件传输的用户体验。

附图说明

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

图1是本申请一实施例提供的文件传输方法的流程示意图；

图2是本申请一实施例提供的文件传输方法的流程示意图；

图3是本申请一实施例提供的文件传输方法的流程示意图；

图4是本申请一实施例提供的文件传输方法的流程示意图；

图5是本申请一实施例提供的文件传输方法的流程示意图；

图6是本申请一实施例提供的起始位置点的应用场景示意图；

图7是本申请一实施例提供的起始位置点的应用场景示意图；

图8是本申请一实施例提供的文件传输方法的流程示意图；

图9是本申请一实施例提供的文件传输方法的流程示意图；

图10是本申请一实施例提供的文件传输的应用场景示意图；

图11是本申请一实施例提供的通信方式传输文件内容的流程示意图；

图12是本申请一实施例提供的文件传输方法的***交互图；

图13是本申请实施例提供的文件传输装置的结构示意图；

图14是本申请实施例提供的终端设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定***结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的***、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

首先应当说明地，在本申请实施例中，发送端和接收端是不同的两个终端设备。其中发送端是指发送文件的终端设备，接收端是指接收文件的终端设备。由于单个终端设备在不同使用场景下，既可能需要发送文件，又可能需要接收文件。因此实际应用中，发送端和接收端仅是针对单个场景下终端设备的区分命名，并不构成对终端设备的限定。

在本申请的一些实施例中，将所需传输的文件称为待传输文件。

另外，在本申请实施例中，“多个”是指两个或两个以上。

本申请实施例提供的文件传输方法可以应用于手机、电脑、平板电脑和可穿戴设备等终端设备上，此时终端设备即为本申请实施例提供的文件传输方法的执行主体，本申请实施例对终端设备的具体类型不作任何限制。

为了实现不同终端设备之间的文件传输，可以采用WiFi、蜂窝网络、蓝牙或者有线连接等通信方式传输文件。但无论使用哪种通信方式，其传输能力都是较为有限的。因此实际应用中很容易受到所选用通信方式的传输速度限制，导致文件传输速度较慢，用户体验不佳的情况。

实际应用中发现，终端设备支持的通信方式往往不止一种。例如智能手机、平板电脑和笔记本电脑等终端设备，往往都会支持两种或以上的通信方式。如常见的WiFi、蓝牙、蜂窝网络、NFC、数据线、有线宽带等通信方式。

基于上述实际情况，为了提高文件传输速度，本申请实施例提出了一种文件传输方法。在进行终端设备之间的文件传输时，本申请实施例会同时使用发送端和接收端支持的多种通信方式，对待传输文件的文件内容进行并行传输。通过同时使用多种通信方式进行文件传输，可以极大地提高文件传输效率，使得文件传输速度加快，传输时间减少。进而可以提高文件传输的用户体验。

为了说明本申请所述的技术方案，下面通过具体实施例来进行说明。

图1示出了本申请实施例一提供的文件传输方法的实现流程图，详述如下：

S101，发送端获取可与接收端进行文件传输的通信方式。

实际应用中，每个终端设备支持的通信方式可能相同也可能存在差异。例如常见的终端设备中，智能手机一般会支持WiFi、蓝牙、蜂窝网络、NFC和数据线等通信方式，平板电脑一般会支持WiFi、蓝牙、NFC和数据线等通信方式，台式电脑或笔记本电脑，一般会支持WiFi、蓝牙和有线宽带等通信方式。

为了实现文件传输，首先需要确认出发送端和接收端支持相互传输文件的通信方式。在本申请实施例中，终端设备之间的文件传输分为两种情况：

情况1：终端设备之间进行直连传输。

情况2：终端设备之间接入局域网或广域网，并基于接入的网络进行文件传输。

针对情况1，WiFi、蓝牙、NFC和有线连接等通信方式，均可以实现。此时需发送端和接收端均支持相同的通信方式才可。例如比如发送端和接收端同时具备WiFi功能时，才能使用WiFi进行直连传输。又比如发送端和接收端同时具备蓝牙功能时，才能使用蓝牙进行直连传输。

针对情况2，则需WiFi和蜂窝网络等具有接入局域网或广域网功能的通信方式才能实现。此时对于发送端和接收端，可以无需使用相同的通信方式进行文件传输。例如发送端通过WiFi接入互联网，而接收端通过蜂窝网络接入互联网。此时发送端和接收端仍可以相互传输文件。

基于上述两种情况，本申请实施例在传输文件之前，发送端首先需要确定出与接收端可进行文件传输的通信方式。以便于后续确定出具体使用的通信方式。其中，本申请实施例不对确定发送端和接收端支持通信方式的实现方法做过多限定，可由技术人员根据实际需求选取或设定。

作为确定发送端和接收端支持的通信方式的一种可选实现方式。在本申请实施例中，可以由发送端根据自己支持的通信方式，询问接收端是否支持对应的通信方式。此时S101可以被替换为：S1011和S1012。

S1011，发送端将自身支持的通信方式信息发送至接收端。

S1012，发送端接收由接收端针对发送端的通信方式信息返回的，可进行文件传输的通信方式信息，并根据接收到的通信方式信息，确定出可与接收端进行文件传输的通信方式。

在本申请实施例中，由于发送端不确定接收端支持哪些通信方式，因此可以先将自己所支持的通信方式告知接收端。对应的，发送端发送的自身支持的通信方式信息中，记录有发送端所支持的通信方式。

接收端在接收到通信方式信息后，可以得知发送端支持的通信方式。此时接收端会参考自身支持的通信方式，来进行匹配，以判断出哪些通信方式是可以与发送端进行文件传输的。再将确定出的这些通信方式告知发送端。即将可以进行文件传输的通信方式的信息返回至发送端。

以一实例进行举例说明。假设发送端支持WiFi、蓝牙和NFC，而接收端仅支持WiFi和蓝牙。此时仅WiFi和蓝牙是发送端和接收端可以进行文件传输的通信方式。相应的，此时接收端将记录有WiFi和蓝牙的通信方式信息返回至发送端。发送端接收到返回的通信方式信息之后，即可获知发送端和接收端支持的通信方式包含WiFi和蓝牙。

作为确定发送端和接收端支持的通信方式的另一种可选实现方式。在本申请实施例中，可以由接收端根据自己支持的通信方式，询问发送端是否支持对应的通信方式。此时S101可以被替换为：S1013和S1014。

S1013，接收端将自身支持的通信方式信息发送至发送端。

S1014，发送端接收由接收端发送的，接收端支持的通信方式信息，确定出可与接收端进行文件传输的通信方式。

本申请实施例与前一实施例的不同之处在于，本申请实施例是由接收端先将自身支持的通信方式告知发送端。由发送端根据接收端支持的通信方式，确定两者之间可以进行文件传输的通信方式。其中，接收端既可以是主动执行 S1013，将自身支持的通信方式告知发送端。也可以是在S1013之前，先由发送端发送询问请求。接收端在接收到询问请求之后，再执行S1013的操作。此处不做过多限定，可以可根据实际需求确定。

在上述本申请的两个实施例中，通过发送端与接收端之间主动或被动的交流，告知对方自身所支持的通信方式，从而准确确定出双方所支持的所有可以进行文件传输的通信方式。两个实施例均可以适用于各种实际使用场景，并准确确定出发送端和接收端所支持的所有可以进行文件传输的通信方式，具有极强的使用场景兼容性。同时还有助于后续对实际使用的通信方式的准确选用。

作为确定发送端和接收端支持的通信方式的又一种可选实现方式。在本申请实施例中，可由技术人员预先设置默认的几种通信方式，作为发送端可与接收端进行文件传输的通信方式。此时S101可被替换为：发送端读取预设的多种通信方式，并作为可与接收端进行文件传输的通信方式。

本申请实施例可适用于多种实际场景。包括但不限于如一些发送端和接收端相对较为固定的场景，此时两者支持的通信方式亦相对较为固定。又例如现在的智能设备往往都会支持较多种通信方式，且支持的通信方式往往种类和数量都差不多。在这些场景之中，通过预设一些默认的通信方式，可以缩短发送端执行S101确定与接收端进行文件传输通信方式的时间，从而缩短整个文件传输的时间。

S102，从可与接收端进行文件传输的通信方式中确定出多种用于进行文件传输的通信方式。

考虑到发送端与接收端可进行文件传输的通信方式可能有较多种，理论上可以全部用于文件传输。但实际应用中这些通信方式全部开启使用，又可能会导致终端设备出现性能下降，功耗过大等问题，进而影响用户使用体验。因此在S101确定出发送端与接收端可进行文件传输的通信方式之后，本申请实施例中可以对通信方式进行部分或全部选取。其中，本申请实施例不对选取的具体方式做过多限定，可由技术人员根据实际需求选取或设定。例如，可以仅选取其中传输速度较快的前m种通信方式。其中m可以是大于1的任意自然数。

作为选取通信方式的一种可选实现方式。在本申请实施例中，可由技术人员根据实际需求预先设置所需选取的通信方式数量。在此基础上，S102可以被替换为：从可与接收端进行文件传输的通信方式中确定出预设数量种用于进行文件传输的通信方式。

作为选取通信方式的另一种可选实现方式。在本申请实施例中，可由技术人员根据实际需求预先设置所需选取的通信方式数量，以及设置一种对通信方式排序的规则或方法。在此基础上，S102可以被替换为：S1021。

S1021，对可与接收端进行文件传输的通信方式进行排序，并将排序前预设数量种的通信方式，作为用于进行文件传输的通信方式。

其中，具体的排序方式此处不做过多限定，可由技术人员自行设定。例如，在一些实施例中，可以根据通信方式的传输速度从快到慢的顺序来进行排序。也可以根据通信方式的传输稳定性从好到差的顺序来进行排序。同理，预设数量此处亦不做限定，可以是大于1的任意自然数。

作为选取通信方式的另一种可选实现方式。在前一实施例的基础上，在本申请实施例中，可以同时根据通信方式的传输速度和传输稳定性来进行综合排序。此时S102可以被替换为：S10211和S10212。

S10211，根据通信方式的传输速度和传输稳定性，对可与接收端进行文件传输的通信方式进行传输质量评估，并按照传输质量从高到低进行排序。

S10212，将排序前预设数量种的通信方式，作为用于进行文件传输的通信方式。

在本申请实施例中，会基于传输速度和传输稳定性对通信方式进行综合传输质量评估，并取其中评估传输质量最佳的前几种通信方式作为传输文件的通信方式。其中，具体的传输质量评估方式此处不做过多限定，可由技术人员自行设定。例如，在一些可选实施例中，可以对传输速度和传输稳定性进行加权求和，并将和值作为传输质量的分数。分数越高，传输质量越高。

作为选取通信方式的又一种可选实现方式。在本申请实施例中，可以根据实际所需传输文件(即待传输文件)的体积大小来选择所需的通信方式的种类及数量。在此基础上，参考图2，S102可以被替换为：S1022。

S1022，获取待传输文件的文件体积，并根据文件体积，从可与接收端进行文件传输的通信方式中确定出多种用于进行文件传输的通信方式。

理论上采用越多种的通信方式，文件传输效率越高。但考虑到实际应用中当文件体积较小时，较少数量的通信方式亦可以实现文件快速传输。此时若选用较多的通信方式进行传输，一方面会增加发送端的功耗，另一方面还可能会对用户的使用体验造成影响。因此在本申请实施例中，会根据待传输文件的体积大小来确定所需的通信方式的种类及数量。具体的确定方式此处不做过多限定，可由技术人员根据实际需求选取或设置。作为本申请的一个可选实施例，可以设置一个文件体积与通信方式的种类及数量的对应关系，并根据实际的文件体积和对应关系来确定最终的通信方式。

作为本申请的一个可选实施例，可以设置一个或多个体积阈值，并设置当文件体积与体积阈值不同的大小关系时，分别对应的通信方式的种类及数量。在此基础上，发送端再根据实际待传输文件的文件体积与体积阈值的大小关系，来确定通信方式的种类及数量，并确定最终的通信方式。以一实例进行示例说明，假设设置一个体积阈值为50M。并设置当待传输文件大于50M时，从WiFi、蜂窝网络、蓝牙和有线传输中尽可能的多选取。当待传输文件小等于50M时，则从WiFi、蜂窝网络、蓝牙和有线传输中任选两种通信方式。

在前一实施例的基础上，作为选取通信方式的又一种可选实现方式。在本申请实施例中，待传输文件数量可以不止一个，此时可以根据待传输文件的文件体积和文件数量来选择所需的通信方式的种类及数量。在此基础上，参考图 3，S102可以被替换为：S10221。

S10221，获取待传输文件的文件体积和文件数量，并根据文件体积和文件数量，从可与接收端进行文件传输的通信方式中确定出多种用于进行文件传输的通信方式。

实际应用中发现，当待传输文件数量较多时，即使总的文件体积不大，单种通信方式传输的速度还是会相对较慢(本申请实施例中的文件体积，是指待传输文件的总文件体积)。因此本申请实施例会同时结合文件体积和文件数量来选取通信方式，以实现传输速度和发送端功耗和用户体验等维度的平衡。其中，本申请实施例不对具体根据文件体积和文件数量确定通信方式的方法做过多限定，具体可由可由技术人员根据实际需求选取或设置。作为本申请的一个可选实施例，可以设置一个文件体积、文件数量和通信方式的种类及数量的对应关系，并根据实际的文件体积、文件数量和对应关系来确定最终的通信方式。

作为本申请的一个可选实施例，可以将文件体积和文件数量划分为多种情况，并设置每种情况下分别对应的通信方式的种类及数量。在此基础上，发送端再根据实际待传输文件的文件体积和文件数量情况，来确定通信方式的种类及数量，并确定最终的通信方式。以一实例举例进行示例说明，假设将文件体积和文件数量划分3种情况，其中每种情况对应的通信方式的种类及数量如下：

情况a、文件体积大于50M，文件数量为任意值。此时从WiFi、蜂窝网络、蓝牙和有线传输中尽可能的多选取。

情况b、文件体积小等于50M，且文件数量大于2。此时从WiFi、蜂窝网络、蓝牙和有线传输中尽可能的多选取。

情况c、文件体积小等于50M，且文件数量小等于2。从WiFi、蜂窝网络、蓝牙和有线传输中任选两种通信方式。

作为选取通信方式的又一种可选实现方式。考虑到实际情况中用户在需要进行文件传输的同时，也可能会使用其他占用通信方式的功能。例如用户可能在利用WiFi播放在线视频，或者在利用蜂窝网络进行视频通话，又或者在通过蓝牙耳机播放音乐。在这些场景中，用户对已被占用的通信方式是具有实时使用需求的。因此若直接使用这些已被占用的通信方式来传输文件，可能会对用户正常使用发送端造成一定的影响。例如造成在线视频卡顿、视频通话卡顿或者蓝牙耳机播放音乐断断续续。基于此，本申请实施例可以先根据各个通信方式的使用状态来对通信方式进行筛选，再进行S102对通信方式的确定操作。基于此，参考图4，在本申请实施例中，在S101之后，在S102之前，还包括： S1000和S1001。

S1000，获取可与接收端进行文件传输的通信方式中，各个通信方式在发送端中的使用状态。

S1001，根据各个通信方式的使用状态，对可与接收端进行文件传输的通信方式进行筛选。并基于筛选后剩余的通信方式，执行S102的操作。

此时S102可以适应性地调整为：从筛选后剩余的通信方式中确定出多种用于进行文件传输的通信方式。

在本申请实施例中，将通信方式的使用状态划分为空闲状态和使用中状态。其中空闲状态是指通信方式当前没有数据或文件传输任务，使用中状态则是指通信方式当前有数据或文件传输任务。对于空闲状态的通信方式，筛选时均可以保留下来，以备S102中选取。而对于处于使用中状态的通信方式，考虑到用户当前正在使用，为了减少对用户体验的影响，在筛选时可以选择部分或全部剔除。本申请实施例不对具体使用中状态的通信方式处理方法做过多限定，可由技术人员自行设定。

作为本申请的一个可选实施例，在本申请实施例中有两种可选的使用中状态的通信方式处理方法：

处理方法1、筛选时，将所有处于使用中状态的通信方式均剔除掉。

处理方法2、筛选时，统计所有处于空闲状态的通信方式的数量。如果数量大等于2，则将所有处于使用中状态的通信方式均剔除掉。如果数量小于2，则从处于使用中状态的通信方式中选取部分或全部通信方式保留下来，其余的可以剔除掉。其中保留下来的使用中状态的通信方式数量，与处于空闲状态的通信方式的数量和，需大等于2。

实际应用中，技术人员可根据实际需求来选取所使用的处理方法。亦可以由技术人员自行设置其他处理方法。

作为本申请的一个可选实施例，上述S101和S102的步骤，实质是为了确定出最终用于文件传输的通信方式。因此在本申请实施例中，可以将S101和 S102一起替换为：获取多种通信方式。

在将S101和S102一起替换为“获取多种通信方式”的基础上，作为本申请的又一个可选实施例。在本申请实施例中，可以由技术人员预先设置好确定数量和种类的通信方式。此时亦可以无需进行S101和S102对通信方式的选取，以提升整体文件传输的速度。具体设置的通信方式数量和种类此处不做过多限定，可由技术人员根据实际需求设定。

S103，利用确定出的多种通信方式，将待传输文件的文件内容并行传输至接收端。

在确定出具体使用的通信方式之后，发送端开始传输文件。为了提高传输效率，提升传输速度。本申请实施例会利用这些通信方式并行对待传输文件的文件内容进行传输，即几种通信方式同时传输不同的文件内容。其中，本申请实施例不对具体并行传输的方法做过多限定，可由技术人员根据实际需求设定。例如，在一些可选实施例中，可以利用各个通信方式从待传输文件中不同的位置点出发开始并行传输文件内容，直至将所有待传输文件的所有文件内容均传输至接收端。

在本申请实施例中，通过筛选出发送端和接收端可用的通信方式，并从中选取出多种通信方式来并行传输待传输文件的文件内容。从而使得本申请实施例相对传统的单一通信方式传输文件而言，可以极大地提高文件传输效率，提高文件传输速度。进而提升用户进行文件传输时的使用体验。

作为本申请的一个实施例。理论上将待传输文件的所有文件内容都发送到接收端，即可完成对待传输文件的传输。而实际在进行文件传输的过程中，可以由发送端或者接收端来实现对传输完成的判断。例如，对于发送端，可以判断是否将待传输文件的所有文件内容都通过通信方式发送出去。而对于接收端，则可以判断是否接收到待传输文件的所有文件内容。本申请实施例不对具体判断传输是否完成的主体做过多限定，既可以是发送端也可以是接收端，具体可根据实际应用情况确定。当判断主体为接收端时，可以由接收端在判断出传输完成后，再告知发送端传输完成。同时本申请实施例也不对传输是否完成判断方法做过多限定，亦可由技术人员自行设定。

另外，在完成传输的基础上，接收端还可以对接收到的待传输文件进行完整性校验，以防止传输出现问题或者传输识别。完整性校验的方法此处亦不做过多限定，可由技术人员自行设定。例如可以利用哈希校验的方式进行完整性校验。

作为本申请中实现对待传输文件并行传输的一种可选实现方式。参考图5，在本申请实施例中，S103可以替换为S1031和S1032：

S1031，在待传输文件中确定一个或多个起始位置点，并确定出多种通信方式中每种通信方式分别对应的起始位置点。

在本申请实施例中，为了实现对文件内容的并行传输，首先会在待传输文件中确定出一个或多个起始位置点。并确定好每种通信方式各自对应的起始位置点。其中，考虑到除文件头部和文件尾部以外，任意位置点均可以向位置点两侧进行文件内容读取传输。而文件传输过程中，同一文件内容无需多种通信方式重复传输。因此，文件头部和文件尾部作为起始位置点时，仅需对应一种通信方式。除文件头部和文件尾部以外，单个起始位置点可以对应一种或两种通信方式，但每种通信方式对应一个起始位置点。在此基础上，本申请实施例不对待传输文件中起始位置点的确定方式、起始位置点的具体数量，以及各个起始位置点与通信方式的对应关系做过多限定，可由技术人员根据实际需求设定。

作为本申请的一个可选实施例，可以将文件头部和文件尾部作为固定的两个起始位置点。此时若仅使用2种通信方式进行文件传输，在S1031中，则可以将2种通信方式与2个起始位置点进行对应，并执行S1032的操作。

作为本申请中确定起始位置点及其具体数量的一种可选实现方式。设最终确定出用于文件传输的通信方式数量为m，起始位置点的总数为h，其中m为大于1的自然数，h为大等于1的自然数。为了使得每种通信方式都有一个起始位置点进行文件内容传输，在本申请实施例中，h的取值范围如下：

m为奇数时，(m+1)/2≤h≤m。其中，当取h＝(m+1)/2时，h个起始位置点中，最多有一个1个起始位置点为文件头部和文件尾部。即不包含文件头部和文件尾部，或者仅1个起始位置点为文件头部和文件尾部。

m为偶数时，m/2≤h≤m。其中，当取h＝m/2时，h个起始位置点中，不包含文件头部或者文件尾部。

在上述取值范围内，技术人员可以根据实际需求自行选取具体的起始位置点数量，此处不做过多限定。

以一实例进行举例说明，假设m＝2，此时1≤h≤2。当取h＝1时，唯一的一个起始位置点，须为待传输文件中非文件头部或文件尾部的位置点。参考图6 的(a)部分，此时起始位置点须在文件头部和文件尾部之间选取。而当取h＝2 时，理论上可以在待传输文件中任取两个位置点作为起始位置点。例如，可以将文件头部和文件尾部均作为起始位置点。

应当特别说明地，在本申请所有实施例中，对于起始位置点的确定，既可以是由发送端确定，亦可以是由接收端确定并告知发送端。当由接收端确定起始位置点时，若涉及到对起始位置点的处理或判断逻辑，均是由接收端来实现。相应的S1031则为：发送端接收由接收端发送的一个或多个起始位置点，以及多种通信方式中每种通信方式分别对应的起始位置点。本申请实施例不对确定起始位置点的主体进行限定，可由技术人员自行设定。

S1032，发送端控制多种通信方式从各自对应的起始位置点开始，并行传输待传输文件的文件内容至接收端。

在确定出每种通信方式对应的起始位置点之后，本申请实施例会从起始位置点处读取待传输文件的文件内容，并控制每种通信方式并行发送各自对应起始位置点处读取出的文件内容。

以一实例进行举例说明，参考图6的(b)部分。假设实际使用的通信方式有2种，分别为通信方式1和通信方式2，起始位置点有2个，分别为文件头部(起始位置点1)和文件尾部(起始位置点2)。且通信方式1对应文件头部，通信方式2对应文件尾部。在此基础上，本申请实施例会从文件头部和文件尾部分别开始读取待传输文件的文件内容。同时，会将从文件头部开始读取出的文件内容，通过通信方式1发送至接收端。将从文件尾部开始读取出的文件内容，同步使用通信方式2发送至接收端。

以另一实例进行举例说明，参考图6的(c)部分。本申请实施例是在图6 的(b)部分实施例的基础上，增加了一种通信方式3，以及对应的起始位置点 3。其中起始位置点3处于文件头部和文件尾部之间的任一位置。在图6的(b) 部分实施例的基础上，本申请实施例还会从起始位置点3开始读取待传输文件的文件内容。并使用通信方式3，将从起始位置点3处读取出的文件内容，与通信方式1和通信方式2并行发送至接收端。

在本申请实施例中，通过给每种通信方式设置相应的起始位置点，并从各自的起始位置点处开始进行文件内容的传输。可以实现使用多种通信方式，对待传输文件的同步传输。进而提升对待传输文件的传输效率和速度。

作为本申请中确定起始位置点的一种可选实现方式。在本申请实施例中，S1031可以被替换为：S10311和S10312。

S10311，获取多种通信方式中每种通信方式的传输任务量。

其中，通信方式的传输任务量是指文件传输过程中，该通信方式所需传输的文件内容量。本申请实施例不对传输任务量的设置方法做过多限定，可根据实际需求确定。例如在一些可选的实施例中，传输任务量可以是技术人员预先设置。如可以由技术人员预设设置好各种通信方式之间的传输任务量比例。在 S10311中，再由发送端根据预设的传输任务量比例和实际待传输文件的情况，来确认最终每种通信方式实际的传输任务量。而在另一些可选的实施例中，考虑到实际不同通信方式的传输能力不同，导致对文件内容的传输速度会存在一定的差异。为了充分利用好各个通信方式的传输能力，以提高对待传输文件整体的传输速度。可以根据通信方式的传输速度来确定对应的传输任务量。其中单种通信方式的传输任务量与其传输速度成正相关，例如可以成正比。

S10312，根据多种通信方式中每种通信方式之间的传输任务量的比例，在待传输文件中确定一个或多个起始位置点，并确定出多种通信方式中每种通信方式分别对应的起始位置点。

由于起始位置点是各个通信方式开始传输文件内容的位置点，为了尽可能将通信方式的传输任务量与起始位置点相匹配，以提升传输速度。在本申请实施例中，会根据通信方式之间的传输任务量比例来对传输文件进行位置点定位，从而确定出可以作为起始位置点的位置点。再从这些定位出的位置点钟，选取出所需的起始位置点。关于起始位置点的相关说明，可以参考对S1031的说明，此处不予赘述。

以一实例进行举例说明。假设使用通信方式1、通信方式2和通信方式3 共3种通信方式传输文件内容，且3种通信方式的传输任务量比例为1:1:1。此时可以参考图7的(a)部分，按照1:1:1对待传输文件的文件内容进行位置点定位，可以得到文件头部、待传输文件的1/3处、待传输文件的2/3处以及文件尾部共4个可用位置点。在此基础上，可以有3种起始位置点的选取方案，分别如下：

方案1、将文件头部、待传输文件的1/3处和待传输文件的2/3处，共3个位置点，作为起始位置点。此时可参考参考图7的(b)部分。

方案2、将待传输文件的1/3处、待传输文件的2/3处和文件尾部，共3个位置点，作为起始位置点。此时可参考参考图7的(c)部分。

方案3、将待传输文件的1/3处和待传输文件的2/3处，共2个位置点，作为起始位置点。此时可参考参考图7的(d)部分。

在本申请实施例中，通过按照通信方式传输任务量比例的方式定位起始位置点，可以将通信方式的传输任务量，与实际起始位置点之间的文件内容量同步关联起来。从而使得后续传输过程中，每种通信方式都可以减少跨起始位置点传输的情况可能性。进而提高整体对待传输文件的传输速度。

作为本申请的一个可选实施例，为了提高对待传输文件的传输效率，提升传输速度。在本申请实施例中，会给各个通信方式设置对应的传输任务量。并会在根据各个通信方式对自身传输任务量的完成情况，来调整对待传输文件的传输方式。参考图8，详述如下：

在S103中，还包括：获取多种通信方式中每种通信方式的传输任务量。

其中，关于传输任务量的设置方法，可参考上述S10311中，此处不予赘述。

同时，在执行S103，利用确定出的多种通信方式，将待传输文件的文件内容并行传输至接收端的过程中。本申请实施例会监测各个通信方式对自身传输任务量的完成情况。

在完成对待传输文件的传输之前，若多种通信方式中存在通信方式已完成其对应的传输任务量。此时，本申请实施例中提供至少2种可选的处理方案：

方案1：由通信方式各自完成自己的传输任务量即可，在完成自己的传输任务量之后，等待待传输文件传输完成。

方案2：通信方式在完成自己的传输任务量之后，协助其他的通信方式传输剩余未传输完成的文件内容。以加快传输速度，检索传输时间。此时未完成自身传输任务量的通信方式，仍会继续传输文件内容。

对于方案1，此时发送端无需再进行更多的操作，正常使用正在传输的通信方式继续传输文件内容即可。而对于方案2，则在执行S103的过程中，还包括：

S1030，若在完成对待传输文件的传输之前，多种通信方式中存在通信方式已完成其对应的传输任务量，则利用该已完成对应传输任务量的通信方式，对待传输文件中未传输的文件内容进行并行传输。

当某一通信方式完成了自身的传输任务量，说明该通信方式已闲置。此时本申请实施例会利用该已闲置的通信方式来协助传输剩余的文件内容，可以提高对通信方式的利用率。从而提升传输效率和速度，缩短传输时间。其中，本申请实施例不对协助传输剩余文件内容的方式做过多限定。可由技术人员根据实际需求选取或设置。例如在一些可选实施例中，可以找出当前传输任务量剩余最多的通信方式并作为目标通信方式。让闲置的通信方式与目标通信方式，并行传输目标通信方式剩余的传输任务量。而在另一些可选实施例中，亦可以找出传输任务量完成度最低的通信方式并作为目标通信方式。让闲置的通信方式与目标通信方式，并行传输目标通信方式剩余的传输任务量。其中，单个通信方式的传输任务量完成度，等于其剩余的传输任务量除以其总的传输任务量。

作为本申请的一个可选实施例。在图5对应的实施例的基础上，本申请实施例中，使用第一通信方式和第二通信方式共2种通信方式来进行文件传输。起始位置点共有2个，分别为待传输文件的文件头部和文件尾部。其中第一通信方式对应文件头部，第二通信方式对应文件尾部。在本申请实施例中，第一通信方式和第二通信方式既可以是通过S101和S102筛选出来的，亦可以是根据技术人员预先设置选取的，此处不做限定。相应的，参考图9，在本申请实施例中S1031和S1032可以被替换为：S2031和S2032。

S2031，将待传输文件的文件头部个文件尾部作为起始位置点，其中第一通信方式对应文件头部，第二通信方式对应文件尾部。

S2032，控制第一通信方式从文件头部开始，第二通信方式从文件尾部开始，并行传输待传输文件的文件内容至接收端。

参考图10，是本申请实施例中文件传输时的场景示意图。在本申请实施例中，发送端会从文件头部和文件尾部同步开始读取待传输文件的文件内容。同时，使用第一通信方式传输从文件头部开始读取到的文件内容，使用第二通信方式并行传输从文件尾部开始读取到的文件内容，直至将待传输文件的所有文件内容均发送至接收端。

在本申请实施例中，使用2种通信方式传输文件，且分别从文件头部和文件尾部两端开始读取和发送文件内容。由于从两端开始传输文件内容，且待传输文件的两端之间无其他的起始位置点等，使得本申请实施例无需再进行通信方式的传输任务划分。在文件传输过程中，2种通信方式没有对应的传输任务量。发送端只需不断的从两端向中间读取文件内容，并交由2种通信方式进行传输即可。最后2种通信方式可以在待传输文件的某一位置点同步完成最后的文件内容传输，传输过程中两者均无需等待另外一个通信方式。因此本申请实施例一方面可以无需对传输任务量的分配工作，另一方面又可以避免出现由于传输任务量划分不合理，导致出现闲置通信方式的情况出现。进而本申请实施例可以最大程度的发挥出2种通信方式的通信传输能力，提高传输效率和速度，减少传输时间。

作为本申请中通信方式传输文件内容的一个具体实施例。为了实现通信方式对待传输文件的文件内容传输，在本申请实施例中，通信方式每次仅会发送一个特定长度的文件内容至发送端。同时还会发送该文件内容在待传输文件内的位置信息给发送端，以便发送端进行文件内容写入。参考图11，详述如下：

S301，发送端获取通信方式单次传输的文件内容长度，并作为目标长度。

其中，通信方式单次传输的文件内容长度，可以是接收端通过发送请求等方式告知发送端。亦可以是技术人员根据通信方式的实际传输原理和能力，预先设置好通信方式的目标长度。

由于每种通信方式的实际传输原理和能力不同，不同通信方式对应的目标长度可以存着一定的差异。例如在一些可选实施例中，WiFi的目标长度可以设置为64K，而蓝牙的目标长度可以设置为4K。

S302，发送端从通信方式对应的起始位置点开始，每次读取目标长度的文件内容，并将读取出的文件内容，以及该文件内容在待传输文件内的位置信息给发送端。直至通信方式无传输任务，或者发送端完成对待传输文件的传输。

其中，位置信息可以是相对前一次发送的文件内容的偏移位置，或者相对通信方式对应的起始位置点的偏移位置，也可以是在待传输文件中为具***置点。

在本申请实施例中，通信方式对文件内容的传输是一个多次传输的过程。即将文件内容以目标长度为单位，多次传输至接收端，直至无需再继续传输文件内容为止。应当理解的，目标长度是一个单次传输的理论长度，实际应用中可能会出现某一通信方式剩余未传输的文件内容长度不足目标长度的情况。此时通信方式仍可以对不足目标长度的文件内容进行传输。例如假设通信方式1 的目标长度为128K，而待传输文件需要利用通信方式1传输的文件内容仅剩64K 未完成传输。此时发送端仍可以利用通信方式1开继续传输剩余的64K文件内容。

S303，接收端接收文件内容及文件内容对应的位置信息，并根据文件内容对应的位置信息将接收到的文件内容写入在本地创建的待传输文件。

本申请实施例的传输方法适用于每种通信方式。在本申请实施例中，每种通信方式均是多次传输的方式完成文件内容的传输，使得本申请实施例可以较好地适应每种通信方式的实际特点。提高对文件传输的效率和速度，减少传输时间。

作为本申请中传输文件的一个具体实施例。在本申请实施例中，使用通信方式1和通信方式2两种通信方式进行文件传输，同时基于通信方式3进行基础通信。起始位置点共有2个，分别为待传输文件的文件头部和文件尾部。其中通信方式1对应文件头部，通信方式2对应文件尾部。在此基础上，参考图 12，是本申请实施例的***交互示意图。发送端和接收端进行文件传输的操作详述如下：

S401，接收端使用通信方式3开始监听数据。

在本申请实施例中，通信方式3是发送端和接收端进行基础通信的通信方式，具体可根据实际应用场景确定通信方式3的种类。其中需要说明地，通信方式3仅仅是举例性命名，实际应用中，通信方式3也可以是通信方式1或通信方式2。即实际应用中，通信方式3可以在作为基础通信方式的同时，也作为传输文件的通信方式之一。

S402，发送端通过通信方式3连接到接收端，并发送通信信息和待传输文件的文件信息至接收端。文件信息中包含待传输文件的文件总长度(即文件体积大小)和文件哈希值。通信信息中包含通信方式1和通信方式2的监听端口或者信道等信息。

S403，接收端接收到通信信息和文件信息后保存信息，创建一个长度为文件总长度的目标文件，并向发送端返回响应应答。

S404，发送端接收到响应之后，分别建立通信方式1和通信方式服务端，并向接收端发送通道准备就绪报文。

S405，接收端在接收到通道准备就绪报文后，启动通信方式1和通信方式 2的客户端，并分别连接通信方式1和通信方式2对应的服务端。

S406，接收端通过通信方式1发送从文件头部开始读取的请求报文，并行通过通信方式2发送从文件尾部开始读取的请求报文。请求报文中包含请求文件内容开始的文件偏移位置以及对文件内容的请求长度。

S407，发送端通过通信方式1和通信方式2的服务端，响应通信方式1和通信方式2的客户端请求。即根据接收到的请求报文中的文件偏移位置和请求长度来读取待传输文件的文件内容，并通过通信方式1和通信方式2将文件内容并行发送至接收端。

在本申请实施例中，由接收端选择起始位置点并告知发送端。由发送端在接收到对应的请求报文之后，按照接收端选择的起始位置点：文件头部和文件尾部，开始进行文件内容的读取和发送。

S408，接收端接收通信方式1和通信方式2发送的文件内容，并按照文件偏移位置和请求长度，将接收到的文件内容写入目标文件之中。

S409，接收端检查接收到的文件内容总长度。若文件内容总长度小于待传输文件的文件总长度，则返回执行S406的操作。若文件内容总长度等于待传输文件的文件总长度，则执行S410。

在本申请实施例中，S406至S409为循环操作。每次发送文件内容时，发送端都会读取接收端请求长度的文件内容，并交由对应的通信方式发送出去。其中关于请求长度的内容，可以参考S301中对目标长度的说明，此处不予赘述。

本申请实施例中，由接收端负责根据接收到的文件内容总长度，检查待传输文件是否传输完成。若没传输完成，则重新循环S406至S409的操作。若传输完成，则继续执行后续的S410的操作。

S410，接收端检查目标文件的哈希值是否与待传输文件的文件哈希值相同。若相同，则判定此次文件传输成功。若不相同，则判定此次文件传输失败。

在本申请实施例中，通过使用两种通信从待传输文件的首尾开始传输文件内容，可以最大程度的发挥通信方式的传输能力。相对传统的单通信方式的文件传输，本申请实施例可以极大地提高传输效率，提升传输速度，缩短传输时间。

应当理解地，在无逻辑冲突的前提下，上述各个本申请实施例之间可以相互组合实施，以适应实际的应用需求。这些组合后得到的具体实施例或实施方案，仍属于本申请的保护范围内。

对应于上文实施例所述的文件传输方法，图13示出了本申请实施例提供的文件传输装置的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图13，该文件传输装置包括：

通信获取模块131，用于获取多种通信方式。

并行传输模块132，用于利用多种通信方式，将待传输文件的文件内容并行传输至接收端。

作为本申请的一个实施例，通信获取模块131，包括：

通信获取子模块，获取可与接收端进行文件传输的通信方式。

通信筛选模块，用于从可与接收端进行文件传输的通信方式中确定出多种通信方式。

作为本申请的一个实施例，通信筛选模块，包括：

第一通信筛选模块，用于获取待传输文件的文件体积，并根据文件体积从可与接收端进行文件传输的通信方式中确定出多种通信方式。或者

第二通信筛选模块，用于获取待传输文件的文件体积和文件数量，并根据文件体积和文件数量，从可与接收端进行文件传输的通信方式中确定出多种通信方式。或者

第三通信筛选模块，用于获取可与接收端进行文件传输的通信方式中，每种通信方式的传输速度和传输稳定性。根据传输速度和传输稳定性，从可与接收端进行文件传输的通信方式中确定出多种通信方式。

作为本申请的一个实施例，文件传输装置，还包括：

状态获取模块，用于获取可与接收端进行文件传输的通信方式中，每种通信方式在发送端中的使用状态。

第四通信筛选模块，用于根据每种通信方式的使用状态，对可与接收端进行文件传输的通信方式进行筛选，并基于筛选后剩余的通信方式，执行从可与接收端进行文件传输的通信方式中确定出多种通信方式的操作。

作为本申请的一个实施例，并行传输模块132，包括：

位置点确定模块，用于在待传输文件中确定一个或多个起始位置点，并确定出多种通信方式中，每种通信方式分别对应的起始位置点。

并行传输子模块，用于控制多种通信方式中的每种通信方式，从各自对应的起始位置点处开始，并行传输待传输文件的文件内容至接收端。

作为本申请的一个实施例，并行传输模块132，还包括：

任务量获取模块，用于获取多种通信方式中每种通信方式的传输任务量。

作为本申请的一个实施例，多种通信方式包括第一通信方式和第二通信方式。起始位置点共有两个，分别为待传输文件的文件头部和文件尾部。其中，第一通信方式对应文件头部，第二通信方式对应文件尾部。在本申请实施例中，并行传输子模块，包括：

本申请实施例提供的文件传输装置中各模块实现各自功能的过程，具体可参考前述图1所示实施例以及其他相关方法实施例的描述，此处不再赘述。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。还应理解的是，虽然术语“第一”、“第二”等在文本中在一些本申请实施例中用来描述各种元素，但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如，第一表格可以被命名为第二表格，并且类似地，第二表格可以被命名为第一表格，而不背离各种所描述的实施例的范围。第一表格和第二表格都是表格，但是它们不是同一表格。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

本申请实施例提供的文件传输方法可以应用于手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR) 设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer， UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等终端设备上，本申请实施例对终端设备的具体类型不作任何限制。

例如，所述终端设备可以是WLAN中的站点(STAION，ST)，可以是蜂窝电话、无绳电话、会话启动协议(Session InitiationProtocol，SIP)电话、无线本地环路(WirelessLocal Loop，WLL)站、个人数字处理(Personal Digital Assistant， PDA)设备、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、车联网终端、电脑、膝上型计算机、手持式通信设备、手持式计算设备、卫星无线设备、无线调制解调器卡、电视机顶盒(set top box，STB)、用户驻地设备(customer premise equipment，CPE)和/或用于在无线***上进行通信的其它设备以及下一代通信***，例如，5G网络中的终端设备或者未来演进的公共陆地移动网络(Public Land Mobile Network，PLMN)网络中的终端设备等。

作为示例而非限定，当所述终端设备为可穿戴设备时，该可穿戴设备还可以是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上，或是整合到用户的衣服或配件的一种便携式设备。可穿戴设备不仅仅是一种硬件设备，更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能，如智能手表或智能眼镜等，以及只专注于某一类应用功能，需要和其它设备如智能手机配合使用，如各类进行体征监测的智能手环、智能首饰等。

图14是本申请一实施例提供的终端设备(可以是发送端或者接收端)的结构示意图。如图14所示，该实施例的终端设备14包括：至少一个处理器140 (图14中仅示出一个)、存储器141，所述存储器141中存储有可在所述处理器140上运行的计算机程序142。所述处理器140执行所述计算机程序142时实现上述各个文件传输方法实施例中的步骤，例如图1所示的步骤101至103。或者，所述处理器140执行所述计算机程序142时实现上述各装置实施例中各模块/单元的功能，例如图13所示模块131至133的功能。

所述终端设备14可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括，但不仅限于，处理器140、存储器141。本领域技术人员可以理解，图14仅仅是终端设备14的示例，并不构成对终端设备 14的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述终端设备还可以包括输入发送设备、网络接入设备、总线等。

所称处理器140可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器141在一些实施例中可以是所述终端设备14的内部存储单元，例如终端设备14的硬盘或内存。所述存储器141也可以是所述终端设备14的外部存储设备，例如所述终端设备14上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card) 等。进一步地，所述存储器141还可以既包括所述终端设备14的内部存储单元也包括外部存储设备。所述存储器141用于存储操作***、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器141还可以用于暂时地存储已经发送或者将要发送的数据。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

本申请实施例还提供了一种终端设备，所述终端设备包括至少一个存储器、至少一个处理器以及存储在所述至少一个存储器中并可在所述至少一个处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使所述终端设备实现上述任意各个方法实施例中的步骤。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时可实现上述各个方法实施例中的步骤。

本申请实施例还提供了一种芯片***，所述芯片***包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述各个方法实施例中的步骤。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读存储介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使对应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims

1.一种文件传输方法，其特征在于，应用于发送端，包括：

获取多种通信方式；

利用所述多种通信方式，将待传输文件的文件内容并行传输至接收端。

2.根据权利要求1所述的文件传输方法，其特征在于，所述获取多种通信方式，包括：

获取可与所述接收端进行文件传输的通信方式；

从所述可与所述接收端进行文件传输的通信方式中确定出所述多种通信方式。

3.根据权利要求2所述的文件传输方法，其特征在于，所述从所述可与所述接收端进行文件传输的通信方式中确定出所述多种通信方式，包括：

获取所述待传输文件的文件体积，并根据所述文件体积从所述可与所述接收端进行文件传输的通信方式中确定出所述多种通信方式；或者

获取所述待传输文件的文件体积和文件数量，并根据所述文件体积和所述文件数量，从所述可与所述接收端进行文件传输的通信方式中确定出所述多种通信方式；或者

获取所述可与所述接收端进行文件传输的通信方式中，每种通信方式的传输速度和传输稳定性；根据所述传输速度和传输稳定性，从所述可与所述接收端进行文件传输的通信方式中确定出所述多种通信方式。

4.根据权利要求2或3所述的文件传输方法，其特征在于，在所述从所述可与所述接收端进行文件传输的通信方式中确定出所述多种通信方式之前，还包括：

获取所述可与所述接收端进行文件传输的通信方式中，每种通信方式在发送端中的使用状态；

根据每种通信方式的所述使用状态，对所述可与所述接收端进行文件传输的通信方式进行筛选，并基于筛选后剩余的通信方式，执行所述从所述可与所述接收端进行文件传输的通信方式中确定出所述多种通信方式的操作。

5.根据权利要求1所述的文件传输方法，其特征在于，所述利用所述多种通信方式，将待传输文件的文件内容并行传输至接收端，包括：

在所述待传输文件中确定一个或多个起始位置点，并确定出所述多种通信方式中，每种通信方式分别对应的所述起始位置点；

控制所述多种通信方式中的每种通信方式，从各自对应的所述起始位置点处开始，并行传输所述待传输文件的文件内容至所述接收端。

6.根据权利要求1所述的文件传输方法，其特征在于，所述利用所述多种通信方式，将待传输文件的文件内容并行传输至接收端，还包括：

获取所述多种通信方式中每种通信方式的传输任务量；

在所述利用所述多种通信方式，将待传输文件的文件内容并行传输至接收端的过程中，包括：

若在完成对所述待传输文件的传输之前，所述多种通信方式中存在通信方式已完成其对应的所述传输任务量，则利用该已完成对应所述传输任务量的通信方式，对所述待传输文件中未传输的文件内容进行并行传输。

7.根据权利要求5所述的文件传输方法，其特征在于，所述多种通信方式包括第一通信方式和第二通信方式；所述起始位置点共有两个，分别为所述待传输文件的文件头部和文件尾部；其中，所述第一通信方式对应所述文件头部，所述第二通信方式对应所述文件尾部；

所述控制所述多种通信方式中的每种通信方式，从各自对应的所述起始位置点处开始，并行传输所述待传输文件的文件内容至所述接收端，包括：

控制所述第一通信方式从所述文件头部开始，所述第二通信方式从所述文件尾部开始，并行传输所述待传输文件的文件内容至所述接收端。

8.一种文件传输装置，其特征在于，包括：

通信获取模块，用于获取多种通信方式；

并行传输模块，用于利用所述多种通信方式，将待传输文件的文件内容并行传输至接收端。

9.一种终端设备，其特征在于，所述终端设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现根据权利要求1至7任一项所述方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现根据权利要求1至7任一项所述方法的步骤。