CN116684405A - 一种文件传输方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请实施例提供了一种文件传输方法、装置、电子设备及存储介质，能够通过第一线程传输文件、第二线程同步媒体传输协议数据库的方式，使文件传输与文件信息同步执行，从而加快计算机设备向移动终端发送文件的传输速度。其中，文件传输方法包括：基于媒体传输协议创建针对至少一个第一媒体文件的传输任务，每个第一媒体文件包括第一文件数据和第一元数据信息；响应传输任务，创建第一线程与第二线程；基于第一线程向移动终端的存储空间传输第一文件数据，以及，基于第二线程向移动终端的媒体传输协议数据库传输第一元数据信息。

Description

一种文件传输方法、装置、电子设备及存储介质

【技术领域】

本申请实施例涉及通信技术领域，尤其涉及一种文件传输方法、装置、电子设备及存储介质。

【背景技术】

媒体传输协议(Media Transfer Protocol，MTP)是一种支持在移动终端与计算机之间进行视频、图片、音乐等媒体文件互传的开放性协议。而由于这种媒体传输协议采用了串行发送的传输方式，在计算机向移动终端传输大量文件时，每个文件都需要先在移动终端的MTP数据库中完成文件信息同步，并在完成同步后再执行下个文件的传输。若上个文件未在MTP数据库同步完成，则下个文件必须一直等待到同步完成后才能开始发送。这种传输方式会导致文件的传输速度被严重拖慢，无法满足用户对于更快传输速度的需求。

【发明内容】

本申请实施例提供了一种文件传输方法、装置、电子设备及存储介质，能够通过第一线程传输文件、第二线程同步媒体传输协议数据库的方式，使文件传输与文件信息同步执行，从而加快计算机设备向移动终端发送文件的传输速度。

第一方面，本申请实施例提供了一种文件传输方法，应用于计算机设备，所述计算机设备与移动终端连接，所述方法包括：

基于媒体传输协议创建针对至少一个第一媒体文件的传输任务，每个所述第一媒体文件包括第一文件数据和第一元数据信息；

响应所述传输任务，创建第一线程与第二线程；

基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息。

本申请实施例中，通过改变传统媒体传输协议串行发送的默认规则，在基于一个线程进行第一文件数据发送的基础上，额外设置一个线程用于传输第一元数据信息，使得媒体传输协议数据库的同步和文件数据发送可以同时进行，从而节省文件批量发送时对移动终端的媒体传输协议数据库进行同步所消耗的时间，加快文件传输速度。

可选的，所述基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息之前，所述方法还包括：

从所述第一元数据信息中提取出所述第一文件数据对应的第一文件大小；

响应于所述第一文件大小大于标准字节大小，将所述第一文件数据输入压缩算法，得到压缩文件数据；

根据所述压缩文件数据更新所述第一元数据信息；

所述基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息包括：

基于所述第一线程向所述存储空间传输所述压缩文件数据，以及，基于所述第二线程向所述媒体传输协议数据库传输更新后的所述第一元数据信息。

本申请实施例中，通过设置标准字节大小来区分是否需要对第一文件数据进行压缩，并将第一文件大小大于标准字节大小的第一文件数据输入压缩算法压缩后再进行发送，从而针对性压缩体积过大的文件，减少需要传输的第一文件数据的数据量，加快文件传输速度。

可选的，所述第一媒体文件为至少两个，所述响应于所述第一文件大小大于标准字节大小，将所述第一文件数据输入压缩算法，得到压缩文件数据之前，所述方法还包括：

根据每个所述第一文件数据对应的所述第一文件大小，计算每个所述第一文件大小对应的第一预计传输时间、预计压缩时间以及预计压缩文件大小；

计算每个所述预计压缩文件大小对应的第二预计传输时间；

计算每个所述第一文件大小对应的所述预计压缩时间与所述第二预计传输时间之和，并将所述预计压缩时间与所述第二预计传输时间之和与所述第一预计传输时间作差，得到时间差值；

从多个所述时间差值中查找出绝对值最小的所述时间差值，以及查找出绝对值最小的所述时间差值对应的第一文件大小；

将绝对值最小的所述时间差值对应的所述第一文件大小确定为所述标准字节大小。

本申请实施例中，通过对第一文件数据的压缩耗时加压缩后传输耗时，以及直接传输的耗时分别进行估算，并对这两者进行作差，确定“是直接传输更快还是压缩后传输更快”的判断标准，从而确保从多个第一文件数据中，能够精准筛选出压缩后传输比直接传输更快的大体积文件数据。

可选的，所述基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息包括：

响应于所述第一文件大小不大于所述标准字节大小，基于所述第一线程向所述存储空间传输所述第一文件数据，以及，基于所述第二线程向所述媒体传输协议数据库传输所述第一元数据信息。

本申请实施例中，通过直接对第一文件大小不大于标准字节大小的第一文件数据进行传输，而不是先对其进行压缩再传输，从而确保压缩后传输的传输策略既能够加快较大体积文件传输，又不会因为文件压缩的额外耗时拖慢小体积文件的传输。

可选的，所述第一媒体文件为第二媒体文件经过文件处理后生成的，所述第二媒体文件为历史上已传输至所述移动终端的媒体文件，所述第二媒体文件中包括第二元数据信息，所述基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息之前，所述方法还包括：

读取所述计算机设备的修改日志，所述修改日志用于记录所述第一元数据信息相较于所述第二元数据信息的变更信息；

所述基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息包括：

基于所述第一线程向所述存储空间传输所述第一文件数据，以及，基于所述第二线程向所述媒体传输协议数据库传输所述变更信息。

本申请实施例中，通过在终端已存在第一媒体文件的历史版本时，调取计算机设备的修改日志中与第一元数据信息有关的变更信息，并传输该变更信息来代替传输整个第一元数据信息，从而显著缩小第二线程所传输的数据总量，实现降低传输带宽消耗的效果。

第二方面，本申请实施例提供了一种文件传输方法，应用于移动终端，所述移动终端与计算机设备连接，所述方法包括：

接收所述计算机设备针对至少一个第一媒体文件的传输任务创建请求，在所述移动终端的存储空间中为每个所述第一媒体文件分配存储地址，配置所述移动终端为文件接收模式，所述传输任务创建请求基于媒体传输协议生成，每个所述第一媒体文件包括第一文件数据和第一元数据信息；

响应于所述计算机设备创建第一线程与第二线程，将所述第一线程与所述存储空间建立连接，并将所述第二线程与所述移动终端的媒体传输协议数据库建立连接；

接收所述第一线程传输的所述第一文件数据，以及，接收所述第二线程传输的所述第一元数据信息；

将所述第一文件数据写入所述存储空间，以及，将所述第一元数据信息同步至所述媒体传输协议数据库。

本申请实施例中，通过第一线程、第二线程分别接收文件数据和元数据信息，将基于媒体传输协议的文件传输方式中先接收文件数据、后同步元数据信息的发送策略，降低由传输第一元数据信息引起的额外耗时，从而加快文件的传输速度。

可选的，所述接收所述第一线程传输的所述第一文件数据，以及，接收所述第二线程传输的所述第一元数据信息包括：

获取所述计算机设备使用的压缩算法对应的算法类型；

接收所述第一线程传输的压缩文件数据，所述压缩文件数据为所述第一文件数据输入所述压缩算法后生成的；

接收所述第二线程传输的更新后的所述第一元数据信息，更新后的所述第一元数据信息为根据所述压缩文件数据更新所述第一元数据信息后得到的；

所述将所述第一文件数据写入所述存储空间，以及，将所述第一元数据信息同步至所述媒体传输协议数据库包括：

将所述压缩文件数据写入所述存储空间，以及，将更新后的所述第一元数据信息同步至所述媒体传输协议数据库；

响应于所述移动终端不支持所述算法类型，向所述计算机设备发送解压失败信息，所述解压失败信息用于表征所述移动终端无法对所述压缩文件数据进行解压缩；或者，

响应于所述移动终端支持所述算法类型，使用所述压缩算法对所述压缩文件数据进行解压缩，并使用解压缩后的所述第一文件数据覆盖所述压缩文件数据。

本申请实施例中，通过在移动终端接收压缩后的第一文件数据时，判断计算机使用的压缩算法是否被移动终端本地支持，若支持则正常解压缩，若不支持则发送解压失败提醒，从而在移动终端中添加对“压缩后传输”策略的配套文件处理逻辑，确保使用压缩技术加快文件传输速度的同时，能够对传输到移动终端的压缩文件数据进行妥善处理，提升传输策略的灵活性和兼容性。

可选的，所述第一媒体文件为第二媒体文件经过文件处理后生成的，所述第二媒体文件为历史上已传输至所述移动终端的媒体文件，所述第二媒体文件中包括第二元数据信息和第二文件数据，所述接收所述第一线程传输的所述第一文件数据，以及，接收所述第二线程传输的所述第一元数据信息包括：

接收所述第一线程传输的所述第一文件数据，以及，接收所述第二线程传输的所述第一元数据信息相较于所述第二元数据信息的变更信息；

所述将所述第一文件数据写入所述存储空间，以及，将所述第一元数据信息同步至所述媒体传输协议数据库包括：

将所述第一文件数据写入所述存储空间，并覆盖所述第二文件数据；

基于所述变更信息与所述第二元数据信息，得到所述第一元数据信息。

本申请实施例中，通过在移动终端中已经存有第一媒体文件的历史版本文件时，根据计算机设备发送的变更信息将第二元数据信息修改为第一元数据信息，从而使用仅传输变更信息的方式替代发送整个第一元数据信息，降低第二线程传输的总数据量，减少传输带宽消耗。

第三方面，本申请实施例提供了一种文件传输装置，设置于计算机设备中，所述计算机设备与移动终端连接，所述装置包括：

任务创建单元，用于基于媒体传输协议创建针对至少一个第一媒体文件的传输任务，每个所述第一媒体文件包括第一文件数据和第一元数据信息；

线程创建单元，用于响应所述传输任务，创建第一线程与第二线程；

传输单元，用于基于所述第一线程向移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息。

可选的，所述装置还包括：

文件大小提取单元，用于从所述第一元数据信息中提取出所述第一文件数据对应的第一文件大小；

压缩单元，用于响应于所述第一文件大小大于标准字节大小，将所述第一文件数据输入压缩算法，得到压缩文件数据；

元数据信息更新单元，用于根据所述压缩文件数据更新所述第一元数据信息；

所述传输单元具体用于：

基于所述第一线程向所述存储空间传输所述压缩文件数据，以及，基于所述第二线程向所述媒体传输协议数据库传输更新后的所述第一元数据信息。

可选的，所述第一媒体文件为至少两个，所述装置还包括：

计算单元，用于根据每个所述第一文件数据对应的所述第一文件大小，计算每个所述第一文件大小对应的第一预计传输时间、预计压缩时间以及预计压缩文件大小；

所述计算单元，还用于计算每个所述预计压缩文件大小对应的第二预计传输时间；

所述计算单元，还用于计算每个所述第一文件大小对应的所述预计压缩时间与所述第二预计传输时间之和，并将所述预计压缩时间与所述第二预计传输时间之和与所述第一预计传输时间作差，得到时间差值；

查找单元，用于从多个所述时间差值中查找出绝对值最小的所述时间差值，以及查找出绝对值最小的所述时间差值对应的第一文件大小；

确定单元，用于将绝对值最小的所述时间差值对应的所述第一文件大小确定为所述标准字节大小。

可选的，所述传输单元具体用于：

响应于所述第一文件大小不大于所述标准字节大小，基于所述第一线程向所述存储空间传输所述第一文件数据，以及，基于所述第二线程向所述媒体传输协议数据库传输所述第一元数据信息。

可选的，所述第一媒体文件为第二媒体文件经过文件处理后生成的，所述第二媒体文件为历史上已传输至所述移动终端的媒体文件，所述第二媒体文件中包括第二元数据信息，所述装置还包括：

日志读取单元，用于读取所述计算机设备的修改日志，所述修改日志用于记录所述第一元数据信息相较于所述第二元数据信息的变更信息；

所述传输单元具体用于：

基于所述第一线程向所述存储空间传输所述第一文件数据，以及，基于所述第二线程向所述媒体传输协议数据库传输所述变更信息。

第四方面，本申请实施例提供了一种文件传输装置，设置于移动终端中，所述移动终端与计算机设备连接，所述装置包括：

存储地址配置单元，用于接收计算机设备针对至少一个第一媒体文件的传输任务创建请求，在所述移动终端的存储空间中为每个所述第一媒体文件分配存储地址，所述传输任务创建请求基于媒体传输协议生成，每个所述第一媒体文件包括第一文件数据和第一元数据信息；

线程连接单元，用于响应于所述计算机设备创建第一线程与第二线程，将所述第一线程与所述存储空间建立连接，并将所述第二线程与所述移动终端的媒体传输协议数据库建立连接；

接收单元，用于接收所述第一线程传输的所述第一文件数据，以及，接收所述第二线程传输的所述第一元数据信息；

数据写入单元，用于将所述第一文件数据写入所述存储空间，以及，将所述第一元数据信息同步至所述媒体传输协议数据库。

可选的，所述接收单元具体用于：

获取所述计算机设备使用的压缩算法对应的算法类型；

接收所述第一线程传输的压缩文件数据，所述压缩文件数据为所述第一文件数据输入所述压缩算法后生成的；

接收所述第二线程传输的更新后的所述第一元数据信息，更新后的所述第一元数据信息为根据所述压缩文件数据更新所述第一元数据信息后得到的；

所述数据写入单元具体用于：

将所述压缩文件数据写入所述存储空间，以及，将更新后的所述第一元数据信息同步至所述媒体传输协议数据库；

响应于所述移动终端不支持所述算法类型，向所述计算机设备发送解压失败信息，所述解压失败信息用于表征所述移动终端无法对所述压缩文件数据进行解压缩；或者，

响应于所述移动终端支持所述算法类型，使用所述压缩算法对所述压缩文件数据进行解压缩，并使用解压缩后的所述第一文件数据覆盖所述压缩文件数据。

可选的，所述第一媒体文件为第二媒体文件经过文件处理后生成的，所述第二媒体文件为历史上已传输至所述移动终端的媒体文件，所述第二媒体文件中包括第二元数据信息，所述接收单元具体用于：

接收所述第一线程传输的所述第一文件数据，以及，接收所述第二线程传输的变更信息，所述变更信息用于记录修改所述第二元数据信息以得到所述第一元数据信息的全部操作；

所述数据写入单元具体用于：

将所述第一文件数据写入所述存储空间，并覆盖所述第二文件数据；

基于所述变更信息与所述第二元数据信息，得到所述第一元数据信息。

第五方面，本申请实施例提供了一种电子设备，所述电子设备包括至少一个处理器以及与所述至少一个处理器连接的存储器，所述至少一个处理器用于执行存储器中存储的计算机程序时实现如第一方面、第二方面任一项所述方法的步骤。

第六方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面、第二方面任一项所述方法的步骤。

应当理解的是，本申请实施例的第二～四方面与本申请实施例的第一方面的技术方案一致，各方面及对应的可行实施方式所取得的有益效果相似，不再赘述。

【附图说明】

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

图1为本申请实施例提供的一种文件传输方法在计算机设备端的流程示意图；

图2为本申请实施例提供的一种大体积文件压缩传输方法的流程示意图；

图3为本申请实施例提供的一种标准字节大小的生成方法的流程示意图；

图4A-图4C为本申请实施例中一种标准字节大小的确定方式示意图；

图5为本申请实施例提供的一种小体积文件传输方法的流程示意图

图6为本申请实施例提供的一种第一元数据信息的传输方法的流程示意图；

图7为本申请实施例提供的一种文件传输方法在移动终端的流程示意图；

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

图9为本申请实施例提供的一种元数据信息的传输方法的流程示意图；

图10为本申请实施例提供的一种文件传输装置的结构示意图；

图11为本申请实施例提供的另一种文件传输装置的结构示意图；

图12为本申请实施例提供的一种电子设备的结构示意图。

【具体实施方式】

为了更好的理解本说明书的技术方案，下面结合附图对本申请实施例进行详细描述。

应当明确，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本说明书保护的范围。

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

MTP协议是一种支持在移动终端与计算机之间进行视频、图片、音乐等媒体文件互传的开放性协议，其具有同时支持多设备传输、传输连接稳定不中断、可在传输文件数据的同时传输元数据信息等优点，传输灵活性强，且可以兼容多种常见的移动终端类型，因此应用非常广泛。

经本申请发明人研究发现，由于媒体传输协议本身作为一种上层应用协议，规定了文件传输中必须采用串行发送的传输方式。而串行发送的方式在计算机向移动终端传输大量文件时，常采用单线程同时发送媒体文件与执行MTP数据库同步；而对于每个媒体文件的MTP数据库同步，其同步的开始时间都被安排在了移动终端接收文件数据之后，且必须等待MTP数据库同步完成，才会允许计算机设备执行下个文件的传输。

在这种传输机制的限制下，若上个媒体文件的文件数据刚刚传输完成，且还未在MTP数据库同步元数据信息，则下个文件必须在等待一个对MTP数据库进行同步的完整时间周期后才能开始传输。在基于MTP协议对多个媒体文件进行发送时，这种传输方式会导致文件的传输速度被多次同步MTP数据库的动作强行拖慢，造成不必要的发送耗时，因而无法满足用户对于更快传输速度的需求。。

鉴于此，本申请实施例提供了一种文件传输方法，能够通过第一线程传输文件、第二线程同步媒体传输协议数据库的方式，使文件传输与文件信息同步执行，从而加快计算机设备向移动终端发送文件的传输速度。

应理解的是，本申请实施例中所涉及的任何媒体文件，包括第一媒体文件与第二媒体文件，其类型均可以包括但不限于：视频文件、音频文件、图片文件、文档文件、电子书文件、软件安装包文件、电子表格文件、日历文件、联络人文件、网页文件等各种格式的媒体文件，本申请实施例对此不作任何限制。

下面结合附图对本申请实施例的技术方案进行介绍。

请参见图1，为本申请实施例提供了一种文件传输方法，该方法应用于计算机设备，且计算机设备与移动终端连接，计算机设备可以是桌上型计算机、笔记本电脑、掌上电脑或其它支持媒体传输协议的计算设备，移动终端可以是手机、平板电脑、智能手表、智能眼镜、智能音箱或其它支持媒体传输协议的便携式设备，该方法的步骤如下：

步骤101：基于媒体传输协议创建针对至少一个第一媒体文件的传输任务，每个第一媒体文件包括第一文件数据和第一元数据信息。

本申请实施例中，由于计算机设备向移动终端传输文件采用的是MTP协议，因此在建立针对第一媒体文件的传输任务时，至少需要执行以下配置操作：

(1)计算机设备扫描并识别移动终端的型号和存储容量；

(2)计算机设备选择MTP作为传输模式，并建立与移动终端之间的MTP连接；

(3)基于用户设置或其它硬件参数来配置基于MTP连接的传输任务，如指定文件路径、选择是否执行备份操作、选择是否启用错误重传策略等。

应理解，由于MTP协议是一种基于图片传输协议(Picture Transfer Protocol，简称PTP)编写的自定义扩展协议，其实质上是一种上层的应用协议，且不关心底层传输协议的内容。因此，基于MTP协议创建的协议可以适用于包括通用串行总线(Universal SerialBus，简称USB)、传输控制协议/互联网协议(Transmission Control Protocol/InternetProtocol，简称TCP/IP)协议在内的常用底层传输协议。

同时，计算机设备与移动设备之间建立的MTP连接可以基于包括以太网电缆传输、同轴电缆传输、光纤传输等大部分有线传输方式，或者无线保真传输(Wireless Fidelity，简称Wi-Fi)、蓝牙传输、移动通信网络传输、卫星传输等大部分无线传输方式创建，此处不再赘述。

而在传输任务建立完成后，便可基于这一传输任务创建用于发送第一媒体文件的线程。

步骤102：响应传输任务，创建第一线程与第二线程。

本申请实施例中，在计算机设备与移动终端之间成功建立传输任务后，还需要在正式传输文件之前在传输任务中创建线程，用于媒体文件的发送。应理解，由于MTP协议自身的传输标准限制，对第一媒体文件的传输任何时候都只能采取串行传输的方式进行。即对于每个传输任务，无论其具体配置如何，在不对协议底层规则进行更改的前提下，都有且仅能有一个线程用于文件传输。

对于这一协议限制，本申请实施例提供的解决方法是在传输任务中分别部署一个第一线程、第二线程，且第一线程与第二线程存在两种不同的部署方式：

(1)第一线程为主线程，用于传输文件数据至移动终端的存储空间，第二线程为第一线程的子线程，用于在第一线程的调度下传输元数据信息至移动终端的MTP数据库。

(2)第二线程为主线程，用于传输元数据信息至移动终端的MTP数据库，第一线程为第二线程的子线程，用于在第二线程的调度下传输文件数据至移动终端的存储空间。

其中，主线程是传输任务的主入口，一般用于在传输中发送较为重要的任务或功能，而子线程则是主线程创建的辅助线程，用于在主线程的指定下执行特定的任务，避免主线程因为繁琐或耗时长的任务被严重阻塞运行。主线程在创建子线程后便会继续进行自身的数据发送任务，因此子线程的创建并不会导致MTP传输出现延迟。同时，主线程只有在单次传输任务中需要发送的媒体文件全部发送完成时才可以被销毁或更改；而子线程相对布置更加灵活，在被指定的任务完成后可以随时被创建与销毁。

而在传输第一媒体文件的过程中，无论第一线程与第二线程哪个属于主线程，哪个又是被临时创建的子线程，其在传输中起到的作用并无任何差别。即第一线程作为主线程和作为子线程时都可以用作传输第一文件数据，第二线程作为主线程和作为子线程时也都可以用作传输第一元数据信息，其传输效果都是等效的，可以根据需要任意执行布置。

而在第一线程，第二线程创建完成后，便可以基于这两个线程分别对第一文件数据、第一元数据信息进行传输。

步骤103：基于第一线程向移动终端的存储空间传输第一文件数据，以及，基于第二线程向移动终端的媒体传输协议数据库传输第一元数据信息。

本申请实施例中，由于使用的并非传统MTP协议所规定的单线程传输，而是在其基础上添加了子线程用于执行第一元数据信息的传输；故相比于使用单线程传输的标准MTP传输行为，第一线程与第二线程之间还可能在传输时出现访问冲突。对于这一潜在问题，需要引入线程同步机制解决。

具体来说，在使用第一线程、第二线程分别传输第一文件数据、第一元数据信息时，两条线程之间还应当通过线程同步机制防止访问冲突。常见的线程同步机制包括但不限于：互斥锁(当一个线程存在互斥锁时，其它线程必须等待该线程释放互斥锁后才能访问被保护资源文件)、条件变量(满足特定条件时释放对共享资源的占用以供其它线程使用)、读写锁(对资源文件的并发读取和独占写入进行限制)等。通过这些方式实现第一线程、第二线程的协同工作，从而避免因为频繁的读写操作造成线程间的访问冲突。

而在引入线程同步机制后，便可基于上述第一线程、第二线程的两种部署方式中的任一种，对第一文件数据和第一元数据信息分别执行传输。

下面以本申请实施例中第一线程为主线程、第二线程为子线程的部署方式为例，对本申请实施例所提供方案与传统MTP传输的运行方式区别进行详细阐释：

当第一线程用于传输第一文件数据时，第二线程会负责传输与当前第一文件数据对应的第一元数据信息，使第一文件数据的传输与第一元数据信息的传输能够同步进行、分别完成，相互之间不存在任何阻碍。而相比于使用单一线程传输第一媒体文件的传统方法，这种方案使得作为主线程的第一线程在传输第一文件数据完成后，不必再额外将第一元数据信息发送至移动终端并写入MTP数据库中，而是可以立刻开始下一个第一文件数据的传输，节省MTP数据库同步的时间；同时，第二线程仅用于传输当前第一文件数据对应的第一元数据信息至MTP数据库中进行同步，并不涉及任何第一文件数据的传输，也不会违反MTP协议中关于串行发送的行为标准规范。

因此，本方案相比传统方法，既能够加快文件传输的速度，又不会对MTP协议的底层规则进行改动，保证了在大部分计算机设备与移动终端中的兼容性。

应理解，因为本申请实施例提供的方案是通过创建子线程、将第一媒体文件的第一文件数据与第一元数据信息同步传输的方式，使MTP数据库的同步提前到与第一文件数据开始发送相同的时间点执行，节省在第一文件数据传输完成后额外同步MTP数据库的时间；因此相比发送单个文件、少量文件的场合，其传输速度提升效果在大批量文件发送、且需要频繁更新MTP数据库时要更加显著。

而在使用第一线程、第二线程传输媒体文件的基础上，还可以进一步引入其它改进方案来加快媒体文件的传输速度。

图2为本申请实施例提供的一种大体积文件压缩传输方法的流程示意图。作为一种可能的实施方式，在执行步骤103之前，还可以进一步执行步骤104至106。

步骤104：从第一元数据信息中提取出第一文件数据对应的第一文件大小。

步骤105：响应于第一文件大小大于标准字节大小，将第一文件数据输入压缩算法，得到压缩文件数据。

步骤106：根据压缩文件数据更新第一元数据信息。

同时，步骤103可以通过执行子步骤1031来进一步实现。

步骤1031：基于第一线程向存储空间传输压缩文件数据，以及，基于第二线程向媒体传输协议数据库传输更新后的第一元数据信息。

本申请实施例中，由于创建第一线程、第二线程同时用于传输第一媒体文件的不同数据，只是将MTP数据库的同步时间点进行了适当提前，进而节省同步MTP数据库的等待时间，并不能从根本上改善第一文件数据本身的传输速度。故在计算机设备内存允许的情况下，还可以进一步引入压缩算法对第一文件数据进行压缩处理，使第一文件数据在压缩后缩小文件体积，降低文件本身的传输耗时。

具体来说，首先需要对第一文件数据对应的第一文件大小进行提取，用于筛选在压缩后能够有效加快传输的大体积文件。其中，第一媒体文件对应的第一文件大小可以在第一元数据信息中进行提取；而作为对大体积文件进行筛选的标准，标准字节大小则通过对全部将要发送的第一文件数据对应的第一文件大小进行综合计算后确定，具体的计算流程将在下文中进行详细阐释。

而在拟定了标准字节大小这一判断标准后，即可在每个第一文件数据发送前判断其对应的第一文件大小是否大于标准字节大小，若大于标准字节大小，则认为该第一文件数据在输入压缩算法进行压缩后再发送，相比直接发送所需的总耗时更短，即压缩后的发送速度更快。在筛选出这种第一文件数据后，便可以先将其输入压缩算法处理后再发送。

同时，由于压缩后生成的压缩文件数据相较于原本的第一文件数据发生了体积变化，因此需要将对应的第一元数据信息也进行更新。具体来说，在不发生较大的文件信息变化(如压缩后重命名、压缩后文件存储路径变更)的前提下，一般只需要基于压缩文件数据的体积大小，对第一元数据信息中用于记录文件大小的变量、用于记录文件格式的后缀名等少量信息进行更新即可，该步骤消耗的时间相对于传输时间可以忽略不计。

随后，基于前文中提及的使用第一线程传输第一文件数据、第二线程传输第一元数据信息的方法，将压缩文件数据通过第一线程传至移动终端的存储空间，更新后的第一元数据信息通过第二线程传输至移动终端的MTP数据库，再由移动终端在后续流程中对压缩文件数据进行解压缩即可。

需要注意的是，本申请实施例中所使用的压缩算法可以包括但不限于：DEFLATE压缩算法、弗洛伊德-斯坦伯格编码算法(也称LZ77压缩算法)、LZ78压缩算法、LZW压缩算法、霍夫曼编码算法、伯罗斯-惠勒变换、算术编码等常见的通用压缩算法，也可以包括其它同时在建立MTP连接的计算机设备和移动终端中得到支持的非常用压缩算法。

在一些实施例中，使用压缩算法来处理传输的媒体文件这一思路，同样可以应用于从移动终端基于MTP协议发送文件至计算机设备的场合。

首先，因为压缩算法同样可以由移动终端运行，且移动终端同样具有发送媒体文件的功能，因此基于压缩算法压缩移动终端发往计算机设备的媒体文件，同样可以起到缩减文件数据大小、提升传输速度的效果。其次，移动终端通过更新MTP数据库的方式，具有类似于计算机设备的更改本地文件元数据信息的能力，因此在压缩要发送的文件数据之后，移动终端同样可以更新对应的元数据信息，并将更新后的元数据信息导出MTP数据库、发送至计算机设备。最后，计算机设备对移动终端发送的压缩文件数据同样具有解压缩能力。

因此，根据步骤104至106以及步骤1031所提供的方法思路，在通过移动终端向计算机设备传输文件时，同样使用第一线程传输压缩文件数据，同时使用第二线程传输第一元数据信息，即可起到显著的传输速度提升效果。

而对于筛选第一文件数据所使用的标准字节大小，需要在执行文件传输之前进行计算，从而确定对需要压缩后传输的大体积文件的具体判断标准。

图3是本申请实施例提供的一种标准字节大小的生成方法的流程示意图。作为一种可能的实施方式，第一媒体文件为至少两个，在执行步骤105之前，还可以进一步执行步骤107至111。

步骤107：根据每个第一文件数据对应的第一文件大小，计算每个第一文件大小对应的第一预计传输时间、预计压缩时间以及预计压缩文件大小。

步骤108：计算每个预计压缩文件大小对应的第二预计传输时间。

步骤109：计算每个第一文件大小对应的预计压缩时间与第二预计传输时间之和，并将预计压缩时间与第二预计传输时间之和与第一预计传输时间作差，得到时间差值。

步骤110：从多个时间差值中查找出绝对值最小的时间差值，以及查找出绝对值最小的时间差值对应的第一文件大小。

步骤111：将绝对值最小的时间差值对应的第一文件大小确定为标准字节大小。

本申请实施例中，标准字节大小确定的核心思想，是默认多个第一文件数据对应的第一文件大小中存在一个分界点，使第一文件大小小于等于这一分界点的第一文件数据直接传输的耗时要小于先压缩、再传输的耗时，而第一文件大小大于这一分界点的第一文件数据先压缩、再传输的耗时要小于直接传输的耗时，并尝试寻找这个分界点对应的标准字节大小。因此，第一预计传输时间(直接传输耗时)与“第二预计传输时间+预计压缩时间”(压缩后传输总耗时)之间的时间差值便是锁定对应的标准字节大小的关键。

由于MTP协议在不添加额外扩展的情况传输动作不透明，不支持实时监控传输进度；所以本申请实施例中，对每个文件的传输时间进行精确计算是难以实现的。但由于MTP协议传输文件的速度仅与带宽限制、文件大小等变量相关，因此本申请实施例采用了根据第一文件大小提前估算相应的传输时间，并基于估算结果来确定标准字节大小的方案。

具体来说，由于第一预计传输时间与第二预计传输时间本质上都是通过已知的文件大小来估算对应的传输时间(如通过第一文件大小估计第一传输时间，或通过预计压缩文件大小估算第二预计传输时间)，因此，对于第一、第二预计传输时间的估值，可以直接采用对应的文件大小与第一线程传输带宽来计算得出。其中，第一线程的传输带宽可以根据计算机设备、移动终端中的传输任务相关参数计算获得，也可以根据底层传输方式的不同，针对USB2.0标准、USB3.0标准、蓝牙通信标准、第三代移动通信标准、第四代移动通信标准等不同的通信标准预设对应的传输带宽期望值，并在确定传输模式时直接调取对应的传输带宽期望值用于计算。

类似的，对于预计压缩时间同样采用估算的方式进行。首先，基于压缩算法对当前格式的第一文件数据的压缩率以及第一文件大小估算出压缩后的预计压缩文件大小，然后根据预计压缩文件大小与压缩速度估算预计压缩时间，其中压缩率和压缩速度均可根据压缩算法类型，通过归纳得到的平均值来进行预先配置，并在采用该压缩算法进行压缩时通过预先配置的映射关系获取。

而在计算出预计压缩时间、第一预计传输时间与第二预计传输时间后，还需要根据“第二预计传输时间+预计压缩时间”与第一预计传输时间的时间差值，寻找标准字节大小所对应的时间差值。

具体来说，在多个第一文件数据进行批量发送时，假设存在一个最理想的标准字节大小，其数值能够刚好让该第一文件数据的“第二预计传输时间+预计压缩时间”与第一预计传输时间相等，使得第一文件数据中需要压缩的大体积文件与不需要压缩的小体积文件被清晰分类。但在实际操作时，这种理想情况显然难以成立。

因此，为了计算的简便性，本申请实施例转而使用多个第一文件大小中对应的时间差值的绝对值最小的第一文件大小作为标准字节大小，使确定出的标准字节大小比起其它第一文件大小都更加逼近理想的“分界点”，实现近似于理想情况的筛选效果。

请参见图4A-图4C，为本申请实施例中一种标准字节大小的确定方式示意图。对于图4A-图4C中的三组即将被传输的第一文件数据①、④与⑧，首先讨论图4A中的第一文件数据①；由于其第一预计传输时间②明显要小于预计压缩时间与第二预计传输时间之和③，在这种情况下，直接传输该文件显然更加快速。而对于图4B中的第一文件数据④，由于其第一预计传输时间⑤最接近预计压缩时间与第二预计传输时间之和⑥，且考虑到预计传输时间、预计压缩时间的估算均存在一定误差，故直接将其对应的第一文件大小⑦作为标准字节大小，并将第一文件大小等于标准字节大小的第一文件数据④进行直接传输。而对于图4C中的第一文件数据⑧，由于其第一预计传输时间⑨明显大于预计压缩时间与第二预计传输时间之和⑩，将其输入压缩算法进行处理后再进行传输就变成了更优的选择。

在一些实施例中，可以在使用当前第一文件大小计算第一、第二预计传输时间还有预计压缩时间的时候，引入根据不同压缩算法类型、不同文件格式调整相关计算参数权重的估算方法，或者直接对MTP协议添加相关的协议扩展，使计算机设备能够对于待发送文件数据的精确传输时间进行计算。

在一些实施例中，可以直接根据压缩算法对应的压缩率、压缩速度，求得在理想情况下使第一预计传输时间与“第二预计传输时间+预计压缩时间”相等的标准字节大小，并利用该标准字节大小对第一文件数据是直接传输还是压缩后传输进行更细致的分类，从而在略微增大计算消耗的前提下进一步优化传输的总数据量。

在一些实施例中，针对仅有一个或少数第一媒体文件需要传输的情况，可以不用确定标准字节大小，而是直接估算每个第一媒体文件的第一预计传输时间、第二预计传输时间与预计压缩时间，并判断第一预计传输时间是否大于第二预计传输时间与预计压缩时间之和，若大于则压缩后再进行传输，若小于等于则直接传输。

而在计算出标准字节大小后，对于第一文件大小不大于标准字节大小的第一文件数据，还需要设置对应的处理策略。

图5是本申请实施例提供的一种小体积文件传输方法的流程示意图。作为一种可能的实施方式，步骤103可以通过执行子步骤1032来进一步实现。

步骤1032：响应于第一文件大小不大于标准字节大小，基于第一线程向存储空间传输第一文件数据，以及，基于第二线程向媒体传输协议数据库传输第一元数据信息。

本申请实施例中，当确定了标准字节大小之后，若待发送的第一文件数据对应的第一文件大小不大于标准字节大小，即证明对其先压缩再传输是不必要的，可以直接传输。因此，直接采取第一线程发送第一文件数据、第二线程发送第一元数据信息的方法传输该待发送的第一媒体文件即可。

在一些实施例中，由于MTP协议在传输任务创建并正式开始发送前，对于单次发送文件的顺序并无特定限制，因此计算机设备可在建立传输任务前对第一文件数据的发送顺序进行调整，使得调整后的第一文件数据的发送顺序能够匹配速度更快的文件传输方案。

例如，在对多个待发送的第一媒体文件进行传输时，若计算机设备的内存与其它硬件配置允许，则可以同时执行小体积的第一文件数据的直接发送，以及大体积的第一文件数据的压缩计算这两个步骤；当小体积的第一文件数据发送完成后，再发送压缩完成的压缩文件数据。而对于这种实施方式，标准字节大小的确定方式也要对应调整。

一种调整后的标准字节大小计算方式是：从最小的第一文件大小开始，一边对标准字节大小的数值进行周期性递增，一边按照递增后的标准字节大小对多个第一文件数据进行分类，并计算分类后小体积文件的预计总传输时间与大体积文件的预计总压缩时间之间的大小关系。为了实现在发送小体积文件完成之后，大体积文件至少已经全部压缩完成的效果，标准字节大小的数值应当刚好能使小体积文件对应的预计总传输时间略大于大体积文件对应的预计总压缩时间。而为了找出这一数值，对应采取了使标准字节大小递增以遍历所有分类方式的思路。

在标准字节大小的数值从最小逐步递增(递增的量可以为设定量)时，其分类为小体积文件的第一文件数据也随着递增不断增加，分类为大体积文件的第一文件数据则随递增不断减少。当预计总压缩时间首次小于等于预计总传输时间时，即实现了让小体积文件的预计总传输时间略大于大体积文件的预计总压缩时间这一目的，停止标准字节大小的递增并将其作为本次传输的分类标准，实现在小体积的第一文件数据发送完后刚好完成全部大体积第一文件数据的压缩这一期望效果，进一步加快传输速度。

在另一些实施例中，可以基于每个第一文件数据的预计压缩时间、第一预计传输时间和第二预计传输时间，在传输任务创建前对所有第一文件数据的发送顺序进行更加精细的排序，使每个(或者至少大部分)大体积的第一文件数据都在压缩完成之后刚好进行传输，或在压缩完成后只需等待小于某个时间阈值的时长即可进行传输，从而进一步加快传输速度。

而在对第一文件数据的传输速度进行优化后，还可以对第一元数据信息的同步速度进行优化，使得传输第一元数据信息的数据量、基于第一元数据信息对MTP数据库进行同步的耗时都得到缩减。

图6是本申请实施例提供的一种第一元数据信息的传输方法的流程示意图。作为一种可能的实施方式，第一媒体文件为第二媒体文件经过文件处理后生成的，第二媒体文件为历史上已传输至移动终端的媒体文件，第二媒体文件中包括第二元数据信息，在执行步骤103之前，还可以进一步执行步骤112。

步骤112：读取计算机设备的修改日志，修改日志用于记录所述第一元数据信息相较于所述第二元数据信息的变更信息。

同时，步骤103可以通过执行子步骤1033来进一步实现。

步骤1033：基于第一线程向存储空间传输第一文件数据，以及，基于第二线程向媒体传输协议数据库传输变更信息。

本申请实施例中，对于移动终端中已经存在第一媒体文件的历史版本文件，即第二媒体文件时，可以采用增量传输(即仅传输相同文件的改动部分)的方式来减少第一元数据信息的数据发送量，降低传输过程中的带宽消耗，使得更多带宽能够用于第一文件数据的传输。

首先，由于MTP数据库采用的基本为关系型数据库，并配套使用结构化查询语言(Structured Query Language，简称SQL)进行数据表更新。因此，可以采用类似主从服务器同步的方式，在计算机设备中额外配置一个修改日志，用于记录在计算机设备端对第二元数据信息执行的任何变更操作；同时，在移动终端配套设置读取变更信息的机制，对于移动终端中已存在的第二元数据信息执行与计算机设备相同的变更操作，从而实现靠复现变更操作同步第二元数据信息更改的效果，而不必发送完整的第一元数据信息来覆盖第二元数据信息。

应理解的是，MTP协议虽然在传输文件的元数据信息方面存在一定限制。但在大多数传输任务中，只要确保至少通过第一线程串行传输了第一文件数据，那么本次传输是否只发送了第一文件数据而未同步第一元数据信息，又或者本次传输使用第二线程和其它子线程发送了哪些数据，在MTP协议当中都是没有强制要求的。

因此，本申请实施例中，可以在作为主线程的第一线程发送第一文件数据的同时，不使用作为子线程的第二线程向MTP数据库发送第一元数据信息，而是直接发送第一元数据信息相较于第二元数据信息的变更信息。

对于第一、第二元数据信息，其内容里一般附带有记录文件最后一次修改时间的时间戳，而在记录对第二元数据信息的全部修改操作时，修改日志中也需要保留该操作的具体内容和对应的操作时间戳。通过这两种时间戳，即可确定将第二元数据信息修改为第一元数据信息这一过程对应的时间区间，并将这一时间区间内的全部变更信息全部提取出来，通过第二线程发送至移动终端，并在移动终端对MTP数据库中的第二元数据信息执行这些变更信息对应的变更操作，从而避免了对两个元数据信息中相同内容的重传，降低了第二线程传输的数据量与带宽占用。

需要注意的是，若移动终端的MTP数据库为关系型数据库，那么变更信息的内容就必须是对应的SQL格式；若MTP数据库为非关系型数据库，那么变更信息的内容就必须是对应的非结构化查询语言(也称NOSQL)格式。

在一些实施例中，还可以对第一文件数据同样执行增量传输策略，即通过逐字节比较移动终端中历史版本文件与计算机设备中的新版本文件之间的差异内容，并将差异内容生成为增量数据更新文件。进而，仅传输增量数据更新文件即可实现“将历史版本文件更新为新版本文件”的目的。

在一些实施例中，可以基于前文的对第一文件数据进行压缩的方法，同时压缩多个第一文件数据为多文件压缩数据，使多个第一元数据信息合并为新的元数据信息，从而实现一次打包传输多个第一文件数据对应的第一元数据信息的目的。

请参见图7，基于同一发明构思，本申请实施例还提供了一种文件传输方法，应用于移动终端，该方法的步骤如下：

步骤201：接收计算机设备针对至少一个第一媒体文件的传输任务创建请求，在移动终端的存储空间中为每个第一媒体文件分配存储地址，传输任务创建请求基于媒体传输协议生成，每个第一媒体文件包括第一文件数据和第一元数据信息。

步骤202：响应于所述计算机设备创建第一线程与第二线程，将第一线程与存储空间建立连接，并将第二线程与移动终端的媒体传输协议数据库建立连接。

步骤203：接收第一线程传输的第一文件数据，以及，接收第二线程传输的第一元数据信息。

步骤204：将第一文件数据写入存储空间，以及，将第一元数据信息同步至媒体传输协议数据库。

本申请实施例中，对应于前文的基于计算机设备的文件传输方法，移动终端首先接收传输任务创建请求，并配置与传输任务相关的参数如是否执行错误重传、是否进行备份等。随后，在与计算机设备的MTP连接中执行线程同步，将第一线程发送的文件数据指定至内存中的某个缓存分区，第二线程发送的元数据信息指定至另外的缓存分区。最后，接收第一文件数据、第一元数据信息至相应的缓存分区中，并将该缓存分区中的数据不断写入存储空间或同步至MTP数据库中，此处对传输与写入的细节操作不再赘述。

而在接收第一媒体文件的基础上，还可以对前文的压缩后传输策略执行配套操作，从而进一步优化传输速度。

图8为本申请实施例提供的一种压缩文件传输方法的流程示意图。作为一种可能的实施方式，步骤203可以通过执行子步骤2031至2033来进一步实现。

步骤2031：获取计算机设备使用的压缩算法对应的算法类型。

步骤2032：接收第一线程传输的压缩文件数据，压缩文件数据为第一文件数据输入压缩算法后生成的。

步骤2033：接收第二线程传输的更新后的第一元数据信息，更新后的第一元数据信息为根据压缩文件数据更新第一元数据信息后得到的。

同时，步骤204可以通过执行子步骤2041至2043来进一步实现。

步骤2041：将压缩文件数据写入存储空间，以及，将更新后的第一元数据信息同步至媒体传输协议数据库。

步骤2042：响应于移动终端不支持算法类型，向计算机设备发送解压失败信息，解压失败信息用于表征移动终端无法对压缩文件数据进行解压缩。或者，

步骤2043：响应于移动终端支持算法类型，使用压缩算法对压缩文件数据进行解压缩，并使用解压缩后的第一文件数据覆盖压缩文件数据。

本申请实施例中，由于移动终端接收到的大体积文件数据是被压缩处理过的压缩文件数据，因此需要配套执行对该压缩文件数据的解压缩。而执行解压缩就需要获取计算机终端对应的压缩算法类型，若计算机压缩时使用的默认压缩算法(或用户指定的压缩算法)是移动终端不支持的类型，那么在照常接收压缩文件数据后就像计算机终端发送解压失败信息，提示用户自行处理；若是移动终端支持的类型，则使用对应的压缩算法对压缩文件数据进行解压。

应理解，对于压缩算法的类型的获取，既可以基于第二线程或其它线程，向计算机设备发送请求包并接收计算机反馈的响应结果来实现，也可以直接基于压缩文件数据的文件后缀名确定。

并且，当移动终端支持当前使用的压缩算法，压缩文件数据却仍解压失败时，则可能是压缩错误或者压缩文件数据被用户设置了解压密码，同样向计算机设备发送解压失败信息，提醒用户自行处理。

而在对接收到的压缩文件数据进行解压缩后，还可能需要视情况在移动终端中基于解压缩后的第一文件数据，对第一元数据信息进行相应更新。由于基于第一文件数据对第一元数据信息进行更新的具体方式，与根据压缩文件数据对第一元数据信息进行更新的具体方式相似，故此处不再赘述。

而对于本申请实施例所提供的文件传输方法在移动终端的接收细节，在前文中已经得到阐释，故此处同样不再赘述。

图9是本申请实施例提供的一种元数据信息的传输方法的流程示意图。作为一种可能的实施方式，第一媒体文件为第二媒体文件经过文件处理后生成的，第二媒体文件为历史上已传输至移动终端的媒体文件，第二媒体文件中包括第二元数据信息，步骤203可以通过执行子步骤2034来进一步实现。

步骤2034：接收第一线程传输的第一文件数据，以及，接收第二线程传输的第一元数据信息相较于第二元数据信息的变更信息。

同时，步骤204可以通过执行子步骤2044至2045来进一步实现。

步骤2044：将第一文件数据写入存储空间，并覆盖第二文件数据。

步骤2045：基于变更信息与第二元数据信息，得到第一元数据信息。

由于本申请实施例在对第一元数据信息执行增量传输的方面，已经在前文中进行过详细阐释，故此处不再赘述。

请参见图10，基于同一发明构思，本申请实施例还提供了一种文件传输装置，设置于计算机设备中，计算机设备与移动终端连接，该装置包括：

任务创建单元301，用于基于媒体传输协议创建针对至少一个第一媒体文件的传输任务，每个第一媒体文件包括第一文件数据和第一元数据信息；

线程创建单元302，用于响应传输任务，创建第一线程与第二线程；

传输单元303，用于基于第一线程向移动终端的存储空间传输第一文件数据，以及，基于第二线程向移动终端的媒体传输协议数据库传输第一元数据信息。

可选的，该装置还包括：

文件大小提取单元，用于从第一元数据信息中提取出第一文件数据对应的第一文件大小；

压缩单元，用于响应于第一文件大小大于标准字节大小，将第一文件数据输入压缩算法，得到压缩文件数据；

元数据信息更新单元，用于根据压缩文件数据更新第一元数据信息；

传输单元303具体用于：

基于第一线程向存储空间传输压缩文件数据，以及，基于第二线程向媒体传输协议数据库传输更新后的第一元数据信息。

可选的，第一媒体文件为至少两个，该装置还包括：

计算单元，用于根据每个第一文件数据对应的第一文件大小，计算每个第一文件大小对应的第一预计传输时间、预计压缩时间以及预计压缩文件大小；

计算单元，还用于计算每个预计压缩文件大小对应的第二预计传输时间；

计算单元，还用于计算每个第一文件大小对应的预计压缩时间与第二预计传输时间之和，并将预计压缩时间与第二预计传输时间之和与第一预计传输时间作差，得到时间差值；

查找单元，用于从多个时间差值中查找出绝对值最小的时间差值，以及查找出绝对值最小的时间差值对应的第一文件大小；

确定单元，用于将绝对值最小的时间差值对应的第一文件大小确定为标准字节大小。

可选的，传输单元303具体用于：

响应于第一文件大小不大于标准字节大小，基于第一线程向存储空间传输第一文件数据，以及，基于第二线程向媒体传输协议数据库传输第一元数据信息。

可选的，移动终端的存储空间中存有第二媒体文件，第二媒体文件中包括第二元数据信息，第一媒体文件为第二媒体文件经过图像编辑、音视频剪辑或文件转码操作后生成的，该装置还包括：

日志读取单元，用于读取计算机设备的修改日志中与第一元数据信息相关的变更信息，修改日志用于记录对第二元数据信息的全部修改操作；

传输单元303具体用于：

基于第一线程向存储空间传输第一文件数据，以及，基于第二线程向媒体传输协议数据库传输变更信息。

请参见图11，基于同一发明构思，本申请实施例还提供了一种文件传输装置，设置于移动终端中，移动终端与计算机设备连接，该装置包括：

存储地址配置单元401，用于接收计算机设备针对至少一个第一媒体文件的传输任务创建请求，在移动终端的存储空间中为每个第一媒体文件分配存储地址，传输任务创建请求基于媒体传输协议生成，每个第一媒体文件包括第一文件数据和第一元数据信息；

线程连接单元402，用于响应于所述计算机设备创建第一线程与第二线程，将第一线程与存储空间建立连接，并将第二线程与移动终端的媒体传输协议数据库建立连接；

接收单元403，用于接收第一线程传输的第一文件数据，以及，接收第二线程传输的第一元数据信息；

数据写入单元404，用于将第一文件数据写入存储空间，以及，将第一元数据信息同步至媒体传输协议数据库。

可选的，接收单元403具体用于：

获取计算机设备使用的压缩算法对应的算法类型；

接收第一线程传输的压缩文件数据，压缩文件数据为第一文件数据输入压缩算法后生成的；

接收第二线程传输的更新后的第一元数据信息，更新后的第一元数据信息为根据压缩文件数据更新第一元数据信息后得到的；

数据写入单元404具体用于：

将压缩文件数据写入存储空间，以及，将更新后的第一元数据信息同步至媒体传输协议数据库；

响应于移动终端不支持算法类型，向计算机设备发送解压失败信息，解压失败信息用于表征移动终端无法对压缩文件数据进行解压缩；或者，

响应于移动终端支持算法类型，使用压缩算法对压缩文件数据进行解压缩，并使用解压缩后的第一文件数据覆盖压缩文件数据。

可选的，第一媒体文件为第二媒体文件经过文件处理后生成的，第二媒体文件为历史上已传输至移动终端的媒体文件，第二媒体文件中包括第二元数据信息接收单元403具体用于：

接收第一线程传输的第一文件数据，以及，接收第二线程传输的变更信息，变更信息用于记录修改第二元数据信息以得到第一元数据信息的全部操作；

数据写入单元404具体用于：

将第一文件数据写入存储空间，并覆盖第二文件数据；

基于变更信息与第二元数据信息，得到第一元数据信息。

请参见图12，基于同一发明构思，本申请实施例还提供了一种电子设备500，该电子设备500可以包括至少一个处理器501，该至少一个处理器501用于执行存储器中存储的计算机程序，实现本申请实施例提供的如图1-图3、图5-图9所示的文件传输方法的步骤。

可选的，上述处理器501具体可以是中央处理器、特定ASIC，可以是一个或多个用于控制程序执行的集成电路。

可选的，该电子设备500还可以包括与至少一个处理器501连接的存储器502，存储器502可以包括ROM、RAM和磁盘存储器。存储器502用于存储处理器运行时所需的数据，即存储有可被至少一个处理器501执行的指令，至少一个处理器501通过执行存储器502存储的指令，执行如图1-图3、图5-图9所示的方法。其中，存储器502的数量为一个或多个。

其中，任务创建单元301，线程创建单元302，传输单元303，或存储地址配置单元401，线程连接单元402，接收单元403与数据写入单元404所对应的实体设备均可以是前述的处理器501。该电子设备可以用于执行图1-图3、图5-图9所示的实施例所提供的方法。因此关于该电子设备中各功能模块所能够实现的功能，可参考图1-图3、图5-图9所示的实施例中的相应描述，不多赘述。

本申请实施例还提供一种计算机存储介质，其中，计算机存储介质存储有计算机指令，当计算机指令在计算机上运行时，使得计算机执行如图1-图3、图5-图9所述的方法。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (12)

1.一种文件传输方法，其特征在于，应用于计算机设备，所述计算机设备与移动终端连接，所述方法包括：

基于媒体传输协议创建针对至少一个第一媒体文件的传输任务，每个所述第一媒体文件包括第一文件数据和第一元数据信息；

响应所述传输任务，创建第一线程与第二线程；

基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息。

2.根据权利要求1所述的方法，其特征在于，所述基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息之前，所述方法还包括：

从所述第一元数据信息中提取出所述第一文件数据对应的第一文件大小；

响应于所述第一文件大小大于标准字节大小，将所述第一文件数据输入压缩算法，得到压缩文件数据；

根据所述压缩文件数据更新所述第一元数据信息；

所述基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息包括：

基于所述第一线程向所述存储空间传输所述压缩文件数据，以及，基于所述第二线程向所述媒体传输协议数据库传输更新后的所述第一元数据信息。

3.根据权利要求2所述的方法，其特征在于，所述第一媒体文件为至少两个，所述响应于所述第一文件大小大于标准字节大小，将所述第一文件数据输入压缩算法，得到压缩文件数据之前，所述方法还包括：

根据每个所述第一文件数据对应的所述第一文件大小，计算每个所述第一文件大小对应的第一预计传输时间、预计压缩时间以及预计压缩文件大小；

计算每个所述预计压缩文件大小对应的第二预计传输时间；

计算每个所述第一文件大小对应的所述预计压缩时间与所述第二预计传输时间之和，并将所述预计压缩时间与所述第二预计传输时间之和与所述第一预计传输时间作差，得到时间差值；

从多个所述时间差值中查找出绝对值最小的所述时间差值，以及查找出绝对值最小的所述时间差值对应的第一文件大小；

将绝对值最小的所述时间差值对应的所述第一文件大小确定为所述标准字节大小。

4.根据权利要求3所述的方法，其特征在于，所述基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息包括：

响应于所述第一文件大小不大于所述标准字节大小，基于所述第一线程向所述存储空间传输所述第一文件数据，以及，基于所述第二线程向所述媒体传输协议数据库传输所述第一元数据信息。

5.根据权利要求1所述的方法，其特征在于，所述第一媒体文件为第二媒体文件经过文件处理后生成的，所述第二媒体文件为历史上已传输至所述移动终端的媒体文件，所述第二媒体文件中包括第二元数据信息，所述基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息之前，所述方法还包括：

读取所述计算机设备的修改日志，所述修改日志用于记录所述第一元数据信息相较于所述第二元数据信息的变更信息；

所述基于所述第一线程向所述移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息包括：

基于所述第一线程向所述存储空间传输所述第一文件数据，以及，基于所述第二线程向所述媒体传输协议数据库传输所述变更信息。

6.一种文件传输方法，其特征在于，应用于移动终端，所述移动终端与计算机设备连接，所述方法包括：

接收所述计算机设备针对至少一个第一媒体文件的传输任务创建请求，在所述移动终端的存储空间中为每个所述第一媒体文件分配存储地址，所述传输任务创建请求基于媒体传输协议生成，每个所述第一媒体文件包括第一文件数据和第一元数据信息；

响应于所述计算机设备创建第一线程与第二线程，将所述第一线程与所述存储空间建立连接，并将所述第二线程与所述移动终端的媒体传输协议数据库建立连接；

接收所述第一线程传输的所述第一文件数据，以及，接收所述第二线程传输的所述第一元数据信息；

将所述第一文件数据写入所述存储空间，以及，将所述第一元数据信息同步至所述媒体传输协议数据库。

7.根据权利要求6所述的方法，其特征在于，所述接收所述第一线程传输的所述第一文件数据，以及，接收所述第二线程传输的所述第一元数据信息包括：

获取所述计算机设备使用的压缩算法对应的算法类型；

接收所述第一线程传输的压缩文件数据，所述压缩文件数据为所述第一文件数据输入所述压缩算法后生成的；

接收所述第二线程传输的更新后的所述第一元数据信息，更新后的所述第一元数据信息为根据所述压缩文件数据更新所述第一元数据信息后得到的；

所述将所述第一文件数据写入所述存储空间，以及，将所述第一元数据信息同步至所述媒体传输协议数据库包括：

将所述压缩文件数据写入所述存储空间，以及，将更新后的所述第一元数据信息同步至所述媒体传输协议数据库；

响应于所述移动终端不支持所述算法类型，向所述计算机设备发送解压失败信息，所述解压失败信息用于表征所述移动终端无法对所述压缩文件数据进行解压缩；或者，

响应于所述移动终端支持所述算法类型，使用所述压缩算法对所述压缩文件数据进行解压缩，并使用解压缩后的所述第一文件数据覆盖所述压缩文件数据。

8.根据权利要求6所述的方法，其特征在于，所述第一媒体文件为第二媒体文件经过文件处理后生成的，所述第二媒体文件为历史上已传输至所述移动终端的媒体文件，所述第二媒体文件中包括第二元数据信息和第二文件数据，所述接收所述第一线程传输的所述第一文件数据，以及，接收所述第二线程传输的所述第一元数据信息包括：

接收所述第一线程传输的所述第一文件数据，以及，接收所述第二线程传输的所述第一元数据信息相较于所述第二元数据信息的变更信息；

所述将所述第一文件数据写入所述存储空间，以及，将所述第一元数据信息同步至所述媒体传输协议数据库包括：

将所述第一文件数据写入所述存储空间，并覆盖所述第二文件数据；

基于所述变更信息与所述第二元数据信息，得到所述第一元数据信息。

9.一种文件传输装置，其特征在于，设置于计算机设备中，所述计算机设备与移动终端连接，所述装置包括：

任务创建单元，用于基于媒体传输协议创建针对至少一个第一媒体文件的传输任务，每个所述第一媒体文件包括第一文件数据和第一元数据信息；

线程创建单元，用于响应所述传输任务，创建第一线程与第二线程；

传输单元，用于基于所述第一线程向移动终端的存储空间传输所述第一文件数据，以及，基于所述第二线程向所述移动终端的媒体传输协议数据库传输所述第一元数据信息。

10.一种文件传输装置，其特征在于，设置于移动终端中，所述移动终端与计算机设备连接，所述装置包括：

存储地址配置单元，用于接收计算机设备针对至少一个第一媒体文件的传输任务创建请求，在所述移动终端的存储空间中为每个所述第一媒体文件分配存储地址，所述传输任务创建请求基于媒体传输协议生成，每个所述第一媒体文件包括第一文件数据和第一元数据信息；

线程连接单元，用于响应于所述计算机设备创建第一线程与第二线程，将所述第一线程与所述存储空间建立连接，并将所述第二线程与所述移动终端的媒体传输协议数据库建立连接；

接收单元，用于接收所述第一线程传输的所述第一文件数据，以及，接收所述第二线程传输的所述第一元数据信息；

数据写入单元，用于将所述第一文件数据写入所述存储空间，以及，将所述第一元数据信息同步至所述媒体传输协议数据库。

11.一种电子设备，其特征在于，所述电子设备包括至少一个处理器以及与所述至少一个处理器连接的存储器，所述至少一个处理器用于执行存储器中存储的计算机程序时实现如权利要求1-8任一项所述方法的步骤。

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