CN116233805A - 分享文件的方法和电子设备 - Google Patents

Abstract

本申请实施例提供了一种分享文件的方法和电子设备，该方法应用于第一电子设备，包括：显示包含有第二电子设备的标识的第一界面；当接收到用户在第一界面上作用于第二电子设备的标识的第一操作，与第二电子设备建立通信连接，第二电子设备用于接收第一电子设备发送的多个待分享文件；对多个待分享文件中的预处理类文件依次进行压缩，得到压缩文件；基于所述通信连接对应的数据通道，将所述多个待分享文件中的直接发送类文件和已经得到的压缩文件发送至所述第二电子设备，预处理类文件和直接发送类文件为依据预设的分类策略对多个待分享文件进行分类所得到。该方法可以提高文件分享过程的效率。

Description

分享文件的方法和电子设备

技术领域

本申请涉及电子技术领域，具体涉及一种分享文件的方法和电子设备。

背景技术

随着电子技术的不断发展，电子设备的功能也越来越丰富。例如，用户可以使用电子设备进行文件分享，即将一个电子设备中的一个或多个文件发送至另一个电子设备；比如，手机与手机之间的文件分享，个人计算机(personal computer，PC)与PC之间的文件分享等。

目前，当用户需要将一个电子设备中的多个文件发送至另一个电子设备时，会在电子设备上执行相应的分享文件操作，电子设备在接收到用户的分享文件操作后，通常是将待分享的多个文件逐个发送至另一个电子设备，这种分享文件的过程效率比较低。

发明内容

本申请提供了一种分享文件的方法和电子设备，能够提高文件分享过程的效率。

第一方面，本申请提供一种分享文件的方法，应用于第一电子设备，该方法包括：显示包含有第二电子设备的标识的第一界面；当接收到用户在第一界面上作用于第二电子设备的标识的第一操作，与第二电子设备建立通信连接，第二电子设备用于接收第一电子设备发送的多个待分享文件；对多个待分享文件中的第一类文件依次进行压缩，得到压缩文件；基于通信连接对应的数据通道，将多个待分享文件中的第二类文件和已经得到的压缩文件发送至第二电子设备，第一类文件和第二类文件为依据预设的分类策略对多个待分享文件进行分类所得到，第一类文件为需要进行压缩的文件，第二类文件为直接发送至第二电子设备的文件。

其中，第一电子设备向第二电子设备发送文件前，需先建立两者的通信连接。第一电子设备可以提供建立通信连接的界面，该界面上包含有第二电子设备的标识，通过对该标识的点击操作(即第一操作)，可触发第一电子设备与第二电子设备建立通信连接。当第一电子设备与第二电子设备建立连接后，第一电子设备便可向第二电子设备发送多个待分享文件。此时，为提高分享效率，第一电子设备可以将待分享文件中的第一类文件(即分类得到的需要进行压缩的文件，也即预处理类文件)进行压缩，然后将压缩文件和第二类文件(即分类得到的不需要压缩的文件，也即直接发送类文件)发送至第二电子设备。可选地，上述对待分享文件进行分类的分类策略，可以是根据待分享文件的文件大小和/或文件类型进行分类的策略。

需要说明的是，为减少发送文件时的等待时间，第一电子设备可以在与第二电子设备建立通信连接的过程中，即开始对第一类文件进行压缩，这样，当第一电子设备与第二电子设备建立连接成功后，直接将压缩文件和第二类文件发送即可。还需说明的是，第一电子设备和第二电子设备可以为手机、PC或平板电脑等，本实现方式可以实现多种设备之间的文件互传。

上述实现方式，第一电子设备可以根据多个文件的类型、大小等因素对待分享文件进行分类，然后将多个文件中的一部分文件进行压缩打包，再将另一部分文件和压缩文件发送至另一个电子设备。由此可以减少所分享文件的数据量，提高分享效率。

结合第一方面，在第一方面的有些实现方式中，上述方法还包括：创建第一线程和第二线程；上述对多个待分享文件中的第一类文件依次进行压缩，得到压缩文件，包括：调用第一线程对第一类文件依次进行压缩，得到压缩文件；上述将多个待分享文件中的第二类文件和已经得到的压缩文件发送至第二电子设备，包括：调用第二线程将第二类文件和已经得到的压缩文件发送至第二电子设备，第一线程与第二线程并发执行。

其中，第一线程可以称为压缩线程，第二线程可以称为发送线程，第一线程与第二线程并发执行。也即是说，第一线程对第一类文件进行压缩的同时，第二线程可以将第二类文件发送至第二电子设备，并在得到压缩文件后，第二线程也将压缩文件发送至第二电子设备。

结合第一方面和上述实现方式，第一电子设备启动一个压缩线程将第一类文件进行压缩，再由发送线程将压缩后的文件和第二类文件发送至目标电子设备。由此可以减少所分享文件的数据量，提高分享效率，并且两个线程并发执行也进一步提高了文件分享效率。

结合第一方面，在第一方面的有些实现方式中，上述方法还包括：将第一类文件的存储地址存储于第一队列；上述调用第一线程对第一类文件依次进行压缩，得到压缩文件，包括：调用第一线程依次从第一队列中读取第一类文件的存储地址；根据第一类文件的存储地址，获取第一类文件的数据；对第一类文件的数据进行压缩，得到压缩文件。

其中，第一电子设备在调用两个线程对待分类文件进行处理时，为更好的区分不同类文件，可以将第一类文件的存储地址存储于第一队列(即预处理文件队列)，第二类文件的存储地址存储于第二队列(即直接发送文件队列)。在调用第一线程对第一类文件进行压缩时，可由第一线程从第一队列中读取第一类文件的存储地址，以获取第一类文件并进行压缩，进而提高获取文件的效率。可选地，第一线程可依次从第一队列中读取一个第一类文件进行压缩，也可以依次从第一队列中读取多个第一类文件进行压缩。

结合第一方面，在第一方面的有些实现方式中，上述调用第一线程依次从第一队列中读取第一类文件的存储地址，包括：调用第一线程依次从第一队列中读取预设数量的第一类文件的存储地址；相应的，上述对第一类文件的数据进行压缩，得到压缩文件，包括：依次对预设数量的第一类文件的数据进行压缩，得到压缩文件。

其中，第一线程从第一队列中读取第一类文件的存储地址时，可以每次读取预设数量(如3个或其他数量)的存储地址，并对这些预设数量的第一类文件进行压缩，以得到压缩文件。由此，可将多个第一类文件压缩成一个压缩文件，进一步减少所发送文件的数量，提高发送效率。

结合第一方面，在第一方面的有些实现方式中，在得到压缩文件之后，上述方法还包括：调用第一线程对压缩文件进行存储，得到压缩文件的存储地址；将压缩文件的存储地址存储于第二队列，第二队列存储有第二类文件的存储地址。

其中，上述第一线程压缩得到压缩文件后，可将压缩文件进行存储，并将对应的存储地址存储于第二队列，以供第二线程从第二队列中读取该存储地址，以及将压缩文件发送至第二电子设备。由此，第一线程将压缩文件的存储地址存储于第二队列，可为第二线程发送文件提供数据准备。

结合第一方面，在第一方面的有些实现方式中，上述调用第二线程将第二类文件和已经得到的压缩文件发送至第二电子设备，包括：调用第二线程，从第二队列中读取第二类文件的存储地址和已经得到的压缩文件的存储地址；根据第二类文件的存储地址，获取第二类文件的数据；根据已经得到的压缩文件的存储地址，获取已经得到的压缩文件的数据；将第二类文件的数据和已经得到的压缩文件的数据发送至第二电子设备。

其中，第二类文件的存储地址和压缩文件的存储地址存储于第二队列。在调用第二线程将第二类文件和压缩文件发送时，可由第二线程从第二队列中读取相应文件的存储地址，以获取相应文件并进行发送，进而提高获取文件的效率。

结合第一方面，在第一方面的有些实现方式中，在第一线程和第二线程并发执行的过程中，若第二队列中的存储地址所对应的文件个数小于预设阈值，上述方法还包括：读取第一队列中的第一存储地址，并将第一存储地址存储于第二队列，以及从第一队列中删除第一存储地址，第一存储地址为第一队列中还未被压缩的第一类文件的存储地址。

其中，本申请可以设置第二线程的优先级高于第一线程，即优先保证第二线程有文件发送，避免第二线程进入等待状态。因此，当第二队列中的文件个数小于预设阈值(比如3个)时，说明发送线程即将把需要发送的文件发送完成，那么发送线程可能要处于等待状态，需要等待压缩线程执行压缩过程。在此情况下，第一电子设备可以将第一队列中还未被压缩的第一类文件的存储地址由第一队列移入第二队列，即原本需要压缩的文件不再进行压缩，而是由第二线程直接进行发送。由此，可进一步提高文件发送的效率。

结合第一方面，在第一方面的有些实现方式中，在与第二电子设备建立通信连接之后，上述方法还包括：向第二电子设备发送第一消息，第一消息用于通知第二电子设备接收文件；接收第二电子设备根据第一消息发送的确认接收文件的消息。

可选地，上述第一消息携带多个待分享文件的文件类型、文件大小和文件简要信息中的至少一个信息。

其中，第一电子设备与第二电子设备建立通信连接之后，第一电子设备在向第二电子设备发送文件之前，还可以先向第二电子设备发送待分享文件的基本信息，比如待分享文件的文件类型、文件大小和文件简要信息(例如缩略图)中的至少一个信息，以通知第二电子设备接收文件。此时，用户可以在第二电子设备上进行确认，并在确认接收后由第二电子设备向第一电子设备发送确认接收文件的消息；如果用户发现选错了待分享文件，也可以在第二电子设备上选择拒绝接收，然后重新在第一电子设备上选择待分享文件。由此，可减少错发文件的概率。

结合第一方面，在第一方面的有些实现方式中，上述分类策略为根据待分享文件的文件大小和/或文件类型进行分类的策略。

此实现方式中，第一电子设备可以根据待分享文件的文件大小和/或文件类型对待分享文件进行分类。在一种实现方式中，若待分享文件的文件大小小于第一阈值(如5KB)，则将其归为第一类文件；若待分享文件的文件大小大于或者等于第一阈值，则将其归为第二类文件。在另一种实现方式中，若待分享文件的文件类型为第一类型(例如：txt、xls、xlsx、xlt、xlsm、docx、doc、bmp和apk)，则将其归为第一类文件；若待分享文件的文件类型不为第一类型，则将其归为第二类文件。在又一种实现方式中，对于文件大小小于第一阈值的文件，归为第一类文件；对于文件大小大于第二阈值(如60MB)的文件，归为第二类文件。对于文件大小在[第一阈值，第二阈值]之间的文件，再以文件类型进行分类：这部分文件中，对于文件类型为第一类型的文件，归为第一类文件；对于文件类型为第二类型(例如：pptx、ppt、png、jpg、mp3、mp4、pdf、rar、zip、7z、avi、rmbv、mkv、rm和exe)的文件，归为第二类文件；对于其他类型的文件，也暂归为第二类文件。在又一种实现方式中，对于文件类型为第一类型的文件，归为第一类文件；对于文件类型为第二类型的文件，归为第二类文件。对于其他类型的文件，再以文件大小进行分类：这部分文件中，对于文件大小小于第一阈值的文件，归为第一类文件；对于文件大小大于第二阈值的文件，归为第二类文件；对于文件大小在[第一阈值，第二阈值]之间的文件，也暂归为第二类文件。

结合第一方面，在第一方面的有些实现方式中，上述方法还包括：显示包含有多个待分享文件的标识的第二界面；当接收到用户在第二界面上作用于多个待分享文件的标识的第二操作，显示第一界面。

其中，第二界面为显示有多个待分享文件的标识的界面，用户可以在该界面上选中多个待分享文件，然后点击分享选项，跳转至上述包含有第二电子设备的标识的第一界面，以供用户选中第二电子设备，并与第二电子设备建立通信连接。由此，用户可在可视化界面上选择待分享文件以及要发送的目标电子设备，以提高与用户之间的交互性。

第二方面，本申请提供一种分享文件的方法，应用于第二电子设备，该方法包括：接收并存储第一电子设备发送的第二类文件和压缩文件；将压缩文件的存储地址存储于第三队列；创建第三线程；调用第三线程从第三队列中读取压缩文件的存储地址；根据压缩文件的存储地址，获取压缩文件的数据；对压缩文件的数据进行解压缩，得到并存储第一类文件。

其中，第二电子设备可以采用接收线程接收到第二类文件和压缩文件，并将已接收的文件存入相应的存储地址。然后接收线程判断已接收的文件中是否有压缩文件，如果有，则将压缩文件的存储地址写入第三队列(即后处理队列)。接下来，第三线程(即后处理线程)从第三队列中获取压缩文件的存储地址，并根据存储地址获取相应的压缩文件，对压缩文件进行解压缩，最后将解压缩后的文件存入上述已接收的文件对应的存储地址。由此，可减少所接收文件的数据量，提高文件分享效率。

第三方面，本申请提供一种装置，该装置包含在电子设备中，该装置具有实现上述第一方面及上述第一方面的可能实现方式中电子设备行为的功能。功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。例如，接收模块或单元、处理模块或单元等。

第四方面，本申请提供一种装置，该装置包含在电子设备中，该装置具有实现上述第二方面中电子设备行为的功能。功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。例如，接收模块或单元、处理模块或单元等。

第五方面，本申请提供一种电子设备，电子设备包括：处理器、存储器和接口；处理器、存储器和接口相互配合，使得电子设备执行第一方面的技术方案中任意一种方法。

第六方面，本申请提供一种电子设备，电子设备包括：处理器、存储器和接口；处理器、存储器和接口相互配合，使得电子设备执行第二方面的技术方案中任意一种方法。

第七方面，本申请提供一种分享文件的系统，包括第一电子设备和第二电子设备，第一电子设备执行第一方面的技术方案中任意一种方法，第二电子设备执行第二方面的技术方案中任意一种方法。

第八方面，本申请提供一种芯片，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法或第二方面的实现方式中的方法。

可选地，芯片还包括存储器，存储器与处理器通过电路或电线连接。

进一步可选地，芯片还包括通信接口。

第九方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得该处理器执行第一方面的技术方案中任意一种方法，或者执行第二方面的技术方案中任意一种方法。

第十方面，本申请提供一种计算机程序产品，计算机程序产品包括：计算机程序代码，当计算机程序代码在电子设备上运行时，使得该电子设备执行第一方面的技术方案中任意一种方法，或者执行第二方面的技术方案中任意一种方法。

附图说明

图1是本申请实施例提供的一例电子设备的结构示意图；

图2是本申请实施例提供的另一例电子设备的结构示意图；

图3是本申请实施例提供的一例电子设备的软件结构框图；

图4是本申请实施例提供的一例PC打开分享功能的过程示意图；

图5中的(a)图是本申请实施例提供的一例手机打开分享功能的过程示意图；

图5中的(b)图是本申请实施例提供的另一例手机打开分享功能的过程示意图；

图6是本申请实施例提供的一例PC向手机发送文件的过程示意图；

图7是本申请实施例提供的一例手机向PC发送文件的过程示意图；

图8是本申请实施例提供的一例PC接收文件时显示界面的示意图；

图9是本申请实施例提供的另一例PC向手机发送文件的过程示意图；

图10是本申请实施例提供的另一例手机向PC发送文件的过程示意图；

图11是本申请实施例提供的一例电子设备分享文件的流程示意图；

图12是本申请实施例提供的另一例电子设备分享文件的流程示意图；

图13是本申请实施例提供的一例电子设备分享文件的架构示意图；

图14是本申请实施例提供的又一例电子设备分享文件的流程示意图；

图15中的(a)图是本申请实施例提供的一例分类策略流程图；

图15中的(b)图是本申请实施例提供的另一例分类策略流程图；

图16是本申请实施例提供的一例第一发送策略的流程图；

图17是本申请实施例提供的一例对待分享文件进行分类的穷举实验的部分数据示意图；

图18是本申请实施例提供的一例第二发送策略的流程图；

图19是本申请实施例提供的一例目标电子设备接收待分享文件的过程示意图；

图20是本申请实施例提供的又一例电子设备分享文件的流程示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

以下，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”、“第三”的特征可以明示或者隐含地包括一个或者更多个该特征。

目前，电子设备的种类越来越多，以电子设备是PC1为例，该PC1可以具有文件分享功能。通常情况下，在用户打开文件分享功能之后，当用户想要将该PC1中的多个文件(比如多个图片)分享至另一个PC2或者手机时，可以在该PC1的图片目录下选中要分享的多个图片，并通过“分享”选项选中PC2或者手机，进而将多个图片发送至PC2或者手机上。其中，当用户在PC1上选中PC2或者手机时，PC1会与PC2或者手机建立通信连接以及传输文件的数据通道，然后通过数据通道将多个文件逐个发送至PC2或者手机。但是，将多个文件逐个进行发送的分享过程效率比较低。

有鉴于此，本申请实施例提供一种分享文件的方法，在电子设备将多个文件分享至另一个电子设备时，可以根据多个文件的类型、大小等因素，启动一个发送线程将多个文件中的一部分文件直接发送给另一个电子设备，以及启动一个压缩线程将多个文件中的其余部分文件进行压缩打包，再由发送线程将压缩后的文件发送至另一个电子设备。由此可以减少所分享文件的数据量，提高分享效率；并且两个线程并发执行也进一步提高了文件分享效率。需要说明的是，本申请实施例提供的分享文件的方法可以应用于手机、平板电脑、PC、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等具有文件分享功能的电子设备上，可以实现手机与手机、手机与PC、手机与平板电脑、PC与平板电脑、PC与PC等同类设备或不同类设备之间的文件互传，本申请实施例对电子设备的具体类型不作任何限制。

示例性的，图1是本申请实施例提供的一例电子设备100的结构示意图。以电子设备100是手机为例，电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

其中，处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

触摸传感器180K，也称“触控面板”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备100的表面，与显示屏194所处的位置不同。

示例性的，图2是本申请实施例提供的另一例电子设备100的结构示意图。以电子设备100是PC为例，电子设备100可以包括处理器210、存储器220和通信模块230等。

其中，处理器210可以包括一个或多个处理单元，存储器220用于存储程序代码和数据。在本申请实施例中，处理器210可执行存储器220存储的计算机执行指令，用于对电子设备100的动作进行控制管理。

通信模块230可以用于电子设备100的各个内部模块之间的通信、或者电子设备100和其他外部电子设备之间的通信等。示例性的，如果电子设备100通过有线连接的方式和其他电子设备通信，通信模块230可以包括接口等，例如USB接口，USB接口可以是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如增强现实(augmented reality，AR)设备等。

或者，通信模块230可以包括音频器件、射频电路、蓝牙芯片、Wi-Fi芯片、NFC模块等，可以通过多种不同的方式实现电子设备100与其他电子设备之间的交互。

可选地，电子设备100还可以包括显示屏240，显示屏240可以显示人机交互界面中的图像或视频等。

可选地，电子设备100还可以包括外设设备250，例如鼠标、键盘、扬声器、麦克风等。

应理解，除了图1或图2中列举的各种部件或者模块之外，本申请实施例对电子设备100的结构不做具体限定。在本申请另一些实施例中，电子设备100还可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

图3是本申请实施例的电子设备100的软件结构框图。分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，可以将软件系统从上至下分为应用层、中间件层和硬件层。

如图3所示，应用层可以包括安装的各种应用程序(application，APP)，例如PC中的电脑管家APP等业务应用，业务应用可以提供设备管理、事件处理、消息处理、任务管理、进度管理以及异常判断等能力。硬件层包括例如蓝牙芯片、Wi-Fi芯片等硬件模块。

中间件层分布有中间件，例如软总线等，中间件是介于应用系统和系统软件之间的一类软件，它使用系统软件所提供的基础服务(功能)，衔接网络上应用系统的各个部分或不同的应用，能够达到资源共享、功能共享的目的。其中，在PC中，软总线可以与电脑管家APP进行通信，依据电脑管家APP的需求执行相应的响应动作，例如执行设备发现与连接操作、数据传输操作等。另外，在数据传输时，软总线还可依据下层硬件层的硬件能力，调用相应的硬件进行数据传输，比如调用蓝牙芯片，在蓝牙数据通道上进行数据传输。

为了便于理解，本申请以下实施例将以具有图1-图3所示结构的电子设备为例，结合附图和应用场景，对本申请实施例提供的分享文件的方法进行具体阐述。

以PC和手机进行文件互传为例，即PC可以向手机发送文件，手机也可以向PC发送文件。在第一种场景中，用户需要先将PC和手机中的分享功能打开，其中，PC端打开分享功能的过程可以为：如图4所示，可以通过鼠标点击桌面上的电脑管家APP图标以打开电脑管家APP，在电脑管家APP的打开页面上具有分享功能的开关，进而用户可以点击该开关以打开分享功能；或者，在PC的任务栏具有电脑管家APP的快捷入口，通过该快捷入口打开分享功能。手机端打开分享功能的过程可以为：如图5中的(a)图所示，可以通过下拉系统菜单，在系统菜单中点击“分享”开关以打开文件分享功能；或者，如图5中的(b)图所示，通过手机上的设置路径，在设置页面具有一个“分享”选项，用户点击该选项后，可以跳转至分享功能的开关页面；在该页面上，用户可以通过点击开关控件来开启分享功能。

在用户打开上述文件分享功能之后，一方面，若用户要使用PC向手机发送文件，则可以如图6所示，用户可以打开待分享文件所在的文件夹，选中多个待分享文件，点击鼠标右键，在弹出的操作选项列表中选择“分享”选项。此时，PC的显示页面上可以显示出该PC附近同样打开分享功能的设备列表(包括上述手机)，那么用户可以选择手机作为目标设备，使PC与手机建立通信连接，以向手机发送待分享文件。

另一方面，若用户要使用手机向PC发送文件，则可以如图7所示，用户可以打开待分享文件所在的目录，选中多个待分享文件，点击分享选项，此时，手机的显示页面上可以显示出该手机附近同样打开分享功能的设备列表(包括上述PC)，那么用户可以选择PC作为目标设备，使手机与PC建立通信连接，以向PC发送待分享文件。

其中，在该场景中，PC与手机建立的通信连接可以为蓝牙连接、Wi-Fi P2P(peerto peer)连接等，具体的连接过程详见下述实施例的描述。另外，如图8所示，当手机向PC发送文件(例如图片)时，PC的界面上可以显示一条类似于“设备A向您分享1张图片”的提示消息；当用户点击接收按钮后，PC的界面上可以显示一条“设备A向您分享1张图片”的进度消息，并在文件接收完成后显示“接收成功”的提示消息。同理，PC向手机发送文件时，手机的界面上也可以显示类似的提示消息。

在第二种场景中，用户可以打开手机和PC中的WLAN开关、蓝牙开关，然后通过PC中电脑管家APP的连接界面建立PC与手机的通信连接。此时，如图9所示，当用户点击PC任务栏上的电脑管家APP快捷入口时，可以显示出“多屏协同”页面，该页面上可以显示当前已连接的设备，即上述手机。

在该场景中，当用户点击图9中已连接设备(手机)的图标时，手机屏幕可以显示在PC的桌面上。此时，若用户要将PC中的文件发送至手机，则可以在PC上选中文件并进行拖拽，拖到手机窗口，实现PC向手机发送文件的过程。若用户要将手机中的文件发送至PC，则可以在PC显示的手机窗口上，长按手机中的文件至“+”图标出现，然后拖到PC对应的文件夹中，实现手机向PC发送文件的过程。

在第三种场景中，若用户要将手机中的文件发送至PC，则如图10所示，可以将手机的NFC开关打开，并使用相应的应用打开需要发送的文件，然后将手机的NFC区域轻触PC上的分享感应区或标签，此时手机可以与PC建立NFC连接，并在NFC连接的通道上协商建立数据传输通道，以完成文件的传送过程。

针对上述三种场景，都可实现PC与手机之间的文件互传，但需要说明的是，本申请实施例对于PC与手机进行文件互传的场景并不限于上述三种场景。

在上述场景下，PC与手机进行文件传输的过程中，为提高文件分享效率，本申请实施例在发送文件的设备端根据多个文件的类型、大小等因素，启动一个发送线程将多个文件中的一部分文件直接发送给接收设备，以及启动一个压缩线程将多个文件中的其余部分文件进行压缩打包，再由发送线程将压缩后的文件发送至接收设备。由此可以减少所分享文件的数据量，提高分享效率，并且两个线程并发执行也进一步提高了文件分享效率。对于文件传输的具体实现过程可详见下述实施例的描述。

为便于理解，以下实施例中将存储有待分享文件的电子设备称为源电子设备，将接收待分享文件的电子设备称为目标电子设备。由上述描述可知，源电子设备在接收到用户的分享操作后才会执行文件分享过程，那么下述实施例将以上述的第一种场景详细介绍源电子设备向目标电子设备发送文件的处理流程。

根据上述电子设备的结构和软件架构，电子设备在正常运行时，可以具有前台UI界面、Services后台服务和Nearby模块。其中，UI界面可以向用户展示电子设备的画面内容，以及使用户在UI界面执行交互操作；Services可以服务于UI界面，负责数据流程和业务的调度；Nearby可以根据Services的指令搜索发现附近的设备，以及连接设备。

在此架构下，如图11所示，源电子设备向目标电子设备发送文件的过程可以包括：

S1，源电子设备的UI接收到用户分享待分享文件的操作。

S2，源电子设备的UI向Services发送发现指令。

其中，发送发现指令可以通过调用discovery接口实现。

S3，源电子设备的Services将发现指令发送至Nearby。

其中，Services调用discovery接口向Nearby发送发现指令时，需要注册发现回调，即Nearby发现到设备后需将设备信息回传至Services。

S4，源电子设备的Nearby发送正向广播。

此处需要说明的是，若目标电子设备想要被源电子设备发现，则需要先打开被发现功能，即需要执行S5和S6的步骤：

S5，目标电子设备的UI向Services发送被发现指令。

其中，发送被发现指令可以通过调用subscribe接口实现。

S6，目标电子设备的Services将被发现指令发送至Nearby。

其中，Services调用subscribe接口向Nearby发送被发现指令时，需要注册设备被发现。

然后，目标电子设备的Nearby接收到源电子设备的正向广播后，可以执行以下步骤：

S7，目标电子设备的Nearby发送逆向广播。

S8，源电子设备的Nearby向Services发送发现设备的消息。

其中，Nearby可以调用onDeviceFound接口向Services发送消息。

S9，源电子设备的Services将发现设备的消息发送至UI，可供用户查看设备信息。

S10，源电子设备的UI将待分享文件发送至Services。

S11，源电子设备的Services将待分享文件发送至Nearby。

其中，发送待分享文件时，可以调用sendfile接口实现。

S12，源电子设备的Nearby与目标电子设备的Nearby建立Socket通道，并发送待分享文件的预览信息。

其中，待分享文件的预览信息可以由源电子设备的Nearby生成，比如生成的是预览图片。

S13，目标电子设备的Nearby将预览信息发送至Services。

S14，目标电子设备的Services将预览信息发送至UI，以供用户查看确认。

其中，发送预览信息时，可以调用showPreviewReceive接口实现。

当用户在目标电子设备上点击确认接收文件后，目标电子设备可以执行S15-S17的步骤：

S15，目标电子设备的UI向Services发送确认信息。

S16，目标电子设备的Services将确认信息发送至Nearby。

其中，发送确认信息时，可以调用confirm接口实现。

S17，目标电子设备的Nearby向源电子设备的Nearby发送确认接收的消息。

S18，源电子设备的Nearby将待分享文件以二进制数据流发送至目标电子设备的Nearby。

在目标电子设备接收待分享文件的过程中，源电子设备和目标电子设备的显示屏上可以同时显示发送进度，比如进度由1％-100％递增。源电子设备可以执行S19-S20和S23-S24的步骤，目标电子设备可以执行S21-S22和S25-S26的步骤：

S19，源电子设备的Nearby向Services发送进度信息。

S20，源电子设备的Services向UI发送进度信息，以供用户查看发送进度。

其中，发送进度信息时，可以调用onProgress接口实现。

S21，目标电子设备的Nearby向Services发送进度信息。

S22，目标电子设备的Services向UI发送进度信息，以供用户查看发送进度。

其中，发送进度信息时，可以调用onProgress接口实现。

S23，源电子设备的Nearby向Services发送成功信息。

S24，源电子设备的Services向UI发送成功信息，以供用户查看发送结果。

其中，发送成功信息时，可以调用onSuccess接口实现。

S25，目标电子设备的Nearby向Services发送成功信息。

S26，目标电子设备的Services向UI发送成功信息，以供用户查看发送结果。

其中，发送成功信息时，可以调用onSuccess接口实现。

经过上述过程，即完成了源电子设备向目标电子设备发送待分享文件的过程。

在一个实施例中，上述电子设备的Nearby中还可以包括数字传输内容保护协议(digital transmission content protection，DTCP)，Services的功能也可以由业务应用完成，那么，如图12所示，上述发送待分享文件的过程还可以由以下步骤实现：

S30，源电子设备的业务应用将发现指令发送至DTCP。

其中，业务应用可以调用publish接口向DTCP发送发现指令，例如调用PublishListener listener接口。

S31，源电子设备的DTCP将发现指令发送至Nearby。

S32，源电子设备的Nearby执行蓝牙低能耗(bluetooth low energy，BLE)广播。

此处需要说明的是，若目标电子设备想要被源电子设备发现，则需要先打开被发现功能，即需要执行S33和S34的步骤：

S33，目标电子设备的业务应用向DTCP发送被发现指令。

其中，发送被发现指令可以通过调用DTCPReceiveListener listener接口实现。

S34，目标电子设备的DTCP将被发现指令发送至Nearby。

其中，DTCP可以调用subscribe接口和registerSocketListener接口向Nearby发送被发现指令。

然后，目标电子设备的Nearby接收到源电子设备的BLE广播后，可以执行以下步骤：

S35，源电子设备的Nearby向业务应用发送发现设备的消息。

其中，Nearby可以调用onDeviceFound接口向业务应用发送消息。

S36，源电子设备的业务应用将待分享文件发送至DTCP。

其中，发送待分享文件时，可以调用sendfile接口实现，具体地可以调用sendFile(NearbyDevice recvDevice，int timeout，Uri[]fileUriList，SendTransmitCallbacktransCallback)实现。

S37，源电子设备的DTCP生成缩略图等预览信息。

S38，源电子设备的DTCP通知Nearby建立P2P命令通道。

具体地，DTCP可以调用openNearbySocket接口通知Nearby。

S39，源电子设备的Nearby向目标电子设备的Nearby进行BLE广播，以进行P2P命令通道协商，例如协商P2P版本号等内容。

S40，目标电子设备的Nearby向DTCP发送协商请求。

其中，发送协商请求时，可以调用onConnectRequest接口实现。

S41，目标电子设备的DTCP准备接收命令。

S42，目标电子设备的DTCP与源电子设备的DTCP进行内部认证、协议协商等。

S43，源电子设备的DTCP通知Nearby建立P2P数据通道。

S44，源电子设备的Nearby向目标电子设备的Nearby进行BLE广播，以进行P2P数据通道协商。

S45，目标电子设备的Nearby向DTCP发送协商请求。

其中，发送协商请求时，可以调用onConnectRequest接口实现。

S46，目标电子设备的DTCP准备接收数据。

S47，源电子设备的DTCP使用数据通道发送缩略图等预览信息至目标电子设备的DTCP。

S48，目标电子设备的DTCP将预览信息发送至业务应用，以供用户查看确认。

当用户在目标电子设备上点击确认接收文件后，S49，目标电子设备的业务应用将确认接收信息发送至DTCP。

S50，目标电子设备的DTCP与源电子设备的DTCP通过命令通道确认接收，并协商文件传输协议。

S51，源电子设备的DTCP使用数据通道发送待分享文件至目标电子设备的DTCP。

S52，目标电子设备的DTCP接收待分享文件，并保存至指定路径。

S53，源电子设备的DTCP向业务应用回调文件发送进度和速率等信息。

S54，目标电子设备的DTCP向业务应用回调文件发送进度和速率等信息。

经过上述过程，即完成了源电子设备向目标电子设备发送待分享文件的过程。

在一个实施例中，上述Nearby的功能还可以由软总线实现，结合上述图3所示的软件结构框图，以手机向PC发送文件为例，整体流程架构可参见图13：其中，手机的操作系统可以为安卓系统，PC的操作系统可以为Windows系统。分享文件的流程示意图可参见图14，该方法包括：

S101，源电子设备中的业务应用接收到用户作用于待分享文件的分享操作。

其中，当源电子设备为PC时，业务应用可以为电脑管家APP，用户在文件夹中选中多个待分享文件并选择“分享”选项后，电脑管家APP可以接收到此分享操作。当源电子设备为手机时，业务应用可以为图库应用、文档应用等用于存储文件的应用，用户在待分享文件所在的目录选中多个待分享文件并点击分享选项后，业务应用可以接收到此分享操作。

S102，业务应用响应于上述分享操作，向软总线发送指示搜索附近可进行文件分享的电子设备的消息。

业务应用在接收到上述分享操作后，可以向软总线发送一个进程间通信(inter-process communication，IPC)消息，可选地，该IPC消息可以携带搜索指示指令，用于指示软总线搜索发现附近可进行文件分享的电子设备。为方便描述，本申请实施例以下将可进行文件分享的电子设备称为待选电子设备。

S103，软总线调用蓝牙芯片的能力搜索附近的待选电子设备。

S104，获取并展示待选电子设备的设备信息。

此步骤中，软总线调用蓝牙芯片的能力，也即是利用蓝牙芯片进行蓝牙广播，如BLE广播，附近的电子设备接收到该广播信号后，可以向源电子设备的蓝牙芯片发送反馈信号，进而使软总线获取附近的待选电子设备的设备信息；可选地，所获取的设备信息可以包括设备标识，比如设备名称、媒体存取控制地址(media access control address，MAC地址)等。在一个实施例中，软总线可以调用显示驱动，将所获取的设备信息展示在显示屏上。

S105，软总线接收用户对待选电子设备中的其中一个电子设备(即目标电子设备)的选中操作。

S106，软总线创建发送线程和压缩线程。

其中，压缩线程用于对上述待分享文件中的一部分文件进行压缩，发送线程用于在源电子设备和目标电子设备建立连接后，将压缩文件和待分享文件中的另一部分文件发送至目标电子设备。

在一个实施例中，软总线可以根据预设的分类策略对待分享文件进行分类，以确定哪些文件需要压缩，哪些文件不需要压缩；其中，可以将待分享文件分为直接发送类文件和预处理类文件，直接发送类文件即可以直接发送至目标电子设备的文件，预处理类文件即需要进行压缩打包的文件。

预设的分类策略可以为根据文件大小和文件类型进行分类的策略。作为一种可实现的方式，参见图15中的(a)图，具体的分类策略如下：

S60，判断待分享文件的文件大小是否小于第一阈值(如5KB)，若是，执行S61，若否，执行S62。

S61，归为预处理类文件。

S62，判断文件大小是否大于第二阈值(如60MB)，若是，执行S63，若否，执行S64。

S63，归为直接发送类文件。

S64，判断待分享文件的文件类型是否为第一类型(例如：txt、xls、xlsx、xlt、xlsm、docx、doc、bmp和apk)，若是，执行S65，若否，执行S66。

S65，归为预处理类文件。

S66，归为直接发送类文件。

作为另一种可实现的方式，参见图15中的(b)图，具体的分类策略如下：

S70，判断待分享文件的文件类型是否为第一类型，若是，执行S71，若否，执行S72。

S71，归为预处理类文件。

S72，判断文件类型是否为第二类型(例如：pptx、ppt、png、jpg、mp3、mp4、pdf、rar、zip、7z、avi、rmbv、mkv、rm和exe)，若是，执行S73，若否，执行S74。

S73，归为直接发送类文件。

S74，判断待分享文件的文件大小是否小于第一阈值，若是，执行S75，若否，执行S76。

S75，归为预处理类文件。

S76，归为直接发送类文件。

在将待分享文件进行分类之后，软总线还可以对每个待分享文件进行分类标记，并将待分享文件的存储地址和分类标记存入待发送文件队列。或者，将直接发送类文件的存储地址和分类标记存入直接发送文件队列，将预处理类文件的存储地址和分类标记存入预处理文件队列。

S107，压缩线程对预处理类文件进行压缩，得到压缩文件。

其中，压缩线程可以在上述文件分类之后，就开始对预处理类文件进行压缩，为发送线程准备发送数据，以减少后续发送线程的等待时间；具体的压缩过程可以参见下述描述。

S108，软总线调用蓝牙芯片的能力与目标电子设备的蓝牙芯片建立蓝牙连接。

S109，软总线通过所建立的蓝牙连接的通道向目标电子设备的软总线发送所生成的服务集标识(service set identifier，SSID)和密码，使目标电子设备与源电子设备建立Wi-Fi P2P(peer to peer)连接。

S110，目标电子设备的软总线将SSID和密码发送至Wi-Fi芯片。

S111，源电子设备的Wi-Fi芯片与目标电子设备的Wi-Fi芯片建立Wi-Fi P2P连接。

其中，在上述所展示的待选电子设备中，用户可以选择其中一个作为目标电子设备，然后软总线可以先调用蓝牙能力与该目标电子设备建立蓝牙连接。建立蓝牙连接之后，软总线可以生成SSID和密码，并调用Wi-Fi芯片建立一个模拟热点(SoftAP)，该SoftAP对应有上述SSID和密码。接下来，软总线可以通过建立的蓝牙连接的通道将SSID和密码发送至目标电子设备，进而使目标电子设备根据接收到的SSID和密码与源电子设备建立Wi-FiP2P连接。同时，源电子设备与目标电子设备之间还建立起一个socket数据通道，以供后续源电子设备与目标电子设备相互传输数据。

需要说明的是，上述源电子设备与目标电子设备之间所建立连接的类型不限于蓝牙连接和Wi-Fi P2P连接，也可以是其他类型的连接方式，只要能实现两者之间传输数据即可。

在一个实施例中，S108-S111所实现的源电子设备与目标电子设备建立连接的过程也可以在S101之前执行，也即是，当用户打开了文件分享功能后，源电子设备便可搜索附近的待选电子设备，并选中想要进行文件分享的电子设备作为目标电子设备，以及与目标电子设备建立连接。那么，当S105中用户在文件分享过程中再次选中该目标电子设备时，因已与目标电子设备建立了连接，那么源电子设备便可直接执行下述发送文件的过程。

S112，在上述建立的数据通道上，软总线向目标电子设备发送待分享文件的基本信息。

其中，软总线在执行上述建立连接操作的过程中，同时，还获取到待分享文件的基本信息，比如文件类型、文件大小、文件缩略图等信息。然后在建立好数据通道之后，将待分享文件的基本信息发送至目标电子设备，用户便可以在目标电子设备上预览这些基本信息。在一个实施例中，目标电子设备的软总线可以用于接收待分享文件的基本信息，并将这些基本信息发送至业务应用，以向用户展示这些基本信息。

S113，软总线接收目标电子设备发送的确认接收文件的消息。

其中，目标电子设备向用户展示待分享文件的基本信息后，用户可以在目标电子设备上进行确认，目标电子设备接收到用户输入的确认操作，便可以向源电子设备发送确认接收文件的消息。

S114，发送线程通过上述数据通道将直接发送类文件和压缩文件发送至目标电子设备。

因上述压缩线程已对预处理类文件进行压缩，那么此时发送线程可将直接发送类文件和得到的压缩文件发送至目标设备。需要说明的是，上述S106-S107的过程可以和S108-S111的过程同时执行，即压缩线程的处理过程可以和源电子设备与目标电子设备建立连接的过程并发执行，以减少相互等待时间；或者，S106-S107的过程也可以在S108-S111的过程之后执行，本申请实施例对此不作限制。

以下实施例将详细描述发送线程和压缩线程的执行过程：

其中，发送线程和压缩线程这两个线程并发执行，即在源电子设备与目标电子设备建立通信连接后，压缩线程在对预处理类文件进行压缩的同时，发送线程可以将直接发送类文件发送至目标电子设备；但考虑到实际场景中发送文件的需求较高，这里可以设置发送线程的优先级高于压缩线程的优先级。

在一个实施例中，在上述将直接发送类文件的存储地址和分类标记存入直接发送文件队列，将预处理类文件的存储地址和分类标记存入预处理文件队列的情况下，如图16所示，源电子设备在接收到目标电子设备发送的确认接收文件的消息后，可以采用以下第一发送策略将待发送文件发送至目标电子设备：

S80，发送线程从直接发送文件队列中获取直接发送类文件的存储地址。

S81，根据该存储地址获取直接发送类文件。

S82，将直接发送类文件发送至目标电子设备。

S83，压缩线程从预处理文件队列中获取预处理类文件的存储地址。

S84，根据该存储地址获取预处理类文件。

S85，移除已获取文件的存储地址。

其中，压缩线程从预处理文件队列中获取预处理类文件的存储地址后，可以将预处理文件队列中对应的存储地址和分类标记移除，以避免重复获取存储地址。

S86，对预处理类文件进行压缩、打包，得到压缩文件。

可选地，压缩线程对预处理类文件进行压缩得到的压缩文件可以为二进制格式的文件，也可以为其他格式的文件。此时，压缩线程还可以将压缩文件进行存储，得到压缩文件的存储地址。

S87，将压缩文件的存储地址存入上述直接发送文件队列，以供发送线程从直接发送文件队列中获取压缩文件的存储地址，并将压缩文件发送至目标电子设备。

其中，上述S80-S82与S83-S87的步骤同时执行。在一个实施例中，压缩线程可以将压缩文件存储于与原预处理类文件同一目录下，也可以存储于其他目录下。需要说明的是，发送线程将直接发送类文件和压缩文件发送至目标电子设备后，还可以执行：

S88，移除已发送文件的存储地址。

作为一种可实现的方式，压缩线程可以依次从预处理文件队列中获取一个预处理类文件的存储地址，即先获取一个预处理类文件1的存储地址，根据该存储地址获取预处理文件1并进行压缩；然后再获取一个预处理类文件2的存储地址，根据该存储地址获取预处理文件2并进行压缩，以此类推。作为另一种可实现的方式，压缩线程可以依次从预处理文件队列中获取第一预设数量(如3个或其他数量)的预处理类文件的存储地址，即先获取3个预处理文件1、2、3的存储地址，根据存储地址获取相应的预处理文件1、2、3并进行压缩；然后再获取3个预处理文件4、5、6的存储地址，根据存储地址获取相应的预处理文件4、5、6并进行压缩，依次类推。当压缩得到第二预设数量(如5个)的压缩文件后，压缩线程可以将这些压缩文件进行存储，并将存储地址存入上述直接发送文件队列以供发送线程进行发送；或者，压缩线程可以将这些压缩文件进行打包，并将最终打包文件的存储地址存入上述直接发送文件队列。

此实施例中，因发送线程的优先级高于压缩线程的优先级，即需要保证发送线程持续处于工作状态，尽量减少发送线程的等待时长。那么，作为一种可实现的方式，若上述直接发送文件队列中的文件数量少于第三预设数量(即剩余未发送的直接发送类文件的个数少于第三预设数量)，则压缩线程不再从预处理文件队列中获取剩余的预处理类文件的存储地址，而是将这些剩余的预处理类文件的存储地址从预处理文件队列移入直接发送文件队列，进而由发送线程直接发送至目标电子设备，以避免发送线程需等待压缩线程压缩完预处理类文件后才能进行发送。作为另一种可实现的方式，若上述直接发送文件队列中的文件数量和预处理文件队列中的文件数量都已为零，但是压缩线程还未对已获取的预处理类文件压缩完成，则压缩线程可以停止压缩，将已获取的全部预处理类文件的存储地址移入上述直接发送文件队列，以供发送线程进行发送；或者，压缩线程将已压缩完成的压缩文件的存储地址和未压缩的预处理类文件的移入上述直接发送文件队列，以供发送线程进行发送。

示例性地，假设第三预设数量为3个，直接发送文件队列中的文件数量为2个(包括2个直接发送类文件)，预处理文件队列中的文件数量为2个(包括2个预处理类文件)。那么，压缩线程不再获取预处理文件队列中的2个预处理类文件的存储地址进行压缩，而是将此2个预处理类文件的存储地址移入直接发送文件队列，由发送线程将4个文件(包括2个直接发送类文件和2个预处理类文件)直接发送至目标电子设备。

再示例性地，假设直接发送文件队列中的文件数量和预处理文件队列中的文件数量都已为0，压缩线程之前获取到了3个预处理文件4、5、6的存储地址，当前已对预处理文件4压缩完成，预处理文件5和6还未进行压缩。那么，压缩线程可以将预处理文件4、5、6的存储地址移入上述直接发送文件队列；或者，将预处理文件4对应的压缩文件的存储地址和预处理文件5、6的存储地址移入上述直接发送文件队列。

另外，此实施例中，发送线程在向目标电子设备发送文件时，因会受到源电子设备的当前使用性能的影响，传输文件所使用的数据通道的状态也会发生变化，比如有时发送文件的速率比较快，有时发送文件的速率比较慢。那么，针对此情况，本申请实施例可以动态调整上述第一发送策略，以最大限度的使发送线程的性能达到最优。

作为一种可实现的方式，发送线程在发送文件时，可以获取当前的发送速率，若当前的发送速率小于预设的速率阈值，说明发送线程当前文件的速率比较慢，发送相同大小的文件所需的时间也相应较长，那么对于当前还在直接发送文件队列中的直接发送类文件，软总线可以对其进行重新标记，例如将文件大小大于第二阈值(如60MB)但小于第三阈值(如100MB)的文件标记为预处理类文件，并将这些预处理类文件的存储地址由直接发送文件队列移入预处理文件队列，而其他大于或者等于第三阈值的文件仍为直接发送类文件，对应的存储地址仍保持在直接发送文件队列。由此，减少直接发送类文件的数量，可以在发送速率较慢的时候减轻发送线程的压力。

若当前的发送速率大于或者等于预设的速率阈值，说明发送线程当前文件的速率比较快，发送相同大小的文件所需的时间也相应较短，那么对于当前还在预处理文件队列中的预处理类文件，软总线可以对其进行重新标记，例如将文件大小大于或者等于第四阈值(如3KB)但小于第一阈值(如5KB)的文件标记为直接发送类文件，并将这些直接发送类文件的存储地址由预处理文件队列移入直接发送文件队列，其他小于第四阈值的文件仍为预处理类文件，对应的存储地址仍保持在预处理文件队列。由此，增加直接发送类文件的数量，可以在发送速率较快的时候快速发送文件。

作为另一种可实现的方式，上述软总线根据预设的第一分类策略对待分享文件进行分类时，可以先对待分享文件的预设比例(如20％)进行分类，然后在发送线程发送文件时，再根据发送速率对剩余的待分享文件进行分类，并将直接发送类文件的存储地址和分类标记存入直接发送文件队列，将预处理类文件的存储地址和分类标记存入预处理文件队列。示例性地，软总线先按上述预设的分类策略对待分享文件的预设比例进行分类，然后在发送文件时，若当前的发送速率小于预设的速率阈值，则将剩余的待分享文件中文件大小小于第一阈值(如5KB)的文件归为预处理类文件，对应的存储地址存入预处理文件队列；对于文件大小大于第三阈值(如100MB)的文件归为直接发送类文件，对应的存储地址存入直接发送文件队列；对于文件大小在[第一阈值，第三阈值]之间的文件，再以文件类型进行分类；由此，减少直接发送类文件的数量，可以在发送速率较慢的时候减轻发送线程的压力。若当前的发送速率大于或者等于预设的速率阈值，则将剩余的待分享文件中文件大小小于第一阈值(如5KB)的文件归为预处理类文件，对应的存储地址存入预处理文件队列；对于文件大小大于第四阈值(如50MB)的文件归为直接发送类文件，对应的存储地址存入直接发送文件队列；对于文件大小在[第一阈值，第四阈值]之间的文件，再以文件类型进行分类；由此，增加直接发送类文件的数量，可以在发送速率较快的时候快速发送文件。需要说明的是，软总线对剩余的待分享文件进行分类时，可以将剩余的全部待分享文件进行分类，或者，对其中的预设比例的待分享文件进行分类，并在预设的时间间隔后再次根据发送速率对剩余的待分享文件进行分类，以此类推。

作为又一种可实现的方式，发送线程可以根据当前的发送速率和直接发送文件队列中剩余的直接发送类文件的总大小，估算发送剩余的直接发送类文件所需的第一时间，同时，压缩线程可以根据预处理文件队列中剩余的预处理类文件的类型和大小，估算压缩剩余的预处理类文件所需的第二时间，若第二时间大于第一时间，说明压缩线程所需的时间大于发送线程所需的时间，可能会造成发送线程等待的情况。那么，此时压缩线程可以停止压缩，或者，只对剩余的预处理类文件中的一部分进行压缩，并将不再压缩的预处理类文件的存储地址由预处理文件队列移入直接发送文件队列，交由发送线程直接发送。需要说明的是，上述软总线根据分类策略对待分享文件进行分类的方法、发送线程估算发送直接发送类文件所需的时间的方法、以及压缩线程估算压缩预处理类文件所需的时间的方法，可以根据穷举实验所确定；示例性地，对待分享文件进行分类的穷举实验的部分数据可以参见图17。

在一个实施例中，在上述待分享文件的存储地址和分类标记被存入待发送文件队列的情况下，如图18所示，源电子设备可以采用以下第二发送策略将待发送文件发送至目标电子设备：

S90，发送线程从待发送文件队列中获取直接发送类文件的存储地址。

S91，根据该存储地址获取直接发送类文件。

S92，将直接发送类文件发送至目标电子设备。

S93，压缩线程从待发送文件队列中获取预处理类文件的存储地址。

S94，根据该存储地址获取预处理类文件。

S95，移除已获取文件的存储地址。

其中，压缩线程从待发送文件队列中获取预处理类文件的存储地址后，可以将待发送文件队列中对应的存储地址和分类标记移除，以避免发送线程重复获取存储地址。

S96，对预处理类文件进行压缩、打包，得到压缩文件。

此时，压缩线程可以将压缩文件进行存储，得到压缩文件的存储地址。

S97，将压缩文件的存储地址继续存入上述待发送文件队列，以供发送线程从待发送文件队列中获取压缩文件的存储地址，并将压缩文件发送至目标电子设备。

其中，上述S90-S92与S93-S97的步骤同时执行。在一个实施例中，压缩线程可以将压缩文件存储于与原预处理类文件同一目录下，也可以存储于其他目录下。需要说明的是，发送线程将直接发送类文件和压缩文件发送至目标电子设备后，还可以执行：

S98，移除已发送文件的存储地址。

作为一种可实现的方式，压缩线程可以依次从待发送文件队列中获取一个预处理类文件的存储地址，即先获取一个预处理类文件1的存储地址，根据该存储地址获取预处理文件1并进行压缩；然后再获取一个预处理类文件2的存储地址，根据该存储地址获取预处理文件2并进行压缩，以此类推。作为另一种可实现的方式，压缩线程可以依次从待发送文件队列中获取第一预设数量(如3个或其他数量)的预处理类文件的存储地址，即先获取3个预处理文件1、2、3的存储地址，根据存储地址获取相应的预处理文件1、2、3并进行压缩；然后再获取3个预处理文件4、5、6的存储地址，根据存储地址获取相应的预处理文件4、5、6并进行压缩，依次类推。当压缩得到第二预设数量(如5个)的压缩文件后，压缩线程可以将这些压缩文件进行存储，并将存储地址存入上述待发送文件队列以供发送线程进行发送；或者，压缩线程可以将这些压缩文件进行打包，并将最终打包文件的存储地址存入上述待发送文件队列。

此实施例中，因发送线程的优先级高于压缩线程的优先级，即需要保证发送线程持续处于工作状态，尽量减少发送线程的等待时长。那么，作为一种可实现的方式，若上述待发送文件队列中的文件数量少于第三预设数量(即剩余未发送的文件的个数少于第三预设数量)，则压缩线程不再从待发送文件队列中获取预处理类文件的存储地址，这些预处理类文件由发送线程直接发送至目标电子设备，以避免发送线程需等待压缩线程压缩完预处理类文件后才能进行发送。作为另一种可实现的方式，若上述待发送文件队列中的文件数量已为零，但是压缩线程还未对已获取的预处理类文件压缩完成，则压缩线程可以停止压缩，将获取的全部预处理类文件的存储地址重新存入上述待发送文件队列，以供发送线程进行发送；或者，压缩线程将已压缩完成的压缩文件的存储地址和未压缩的预处理文件的存入上述待发送文件队列，以供发送线程进行发送。

示例性地，假设第三预设数量为5个，待发送文件队列中的文件数量为4个(包括2个直接发送类文件和2个预处理类文件)。那么，压缩线程不再获取2个预处理类文件的存储地址进行压缩，而是由发送线程将此4个文件直接发送至目标电子设备。

再示例性地，假设待发送文件队列中的文件数量已为0，压缩线程之前获取到了3个预处理文件4、5、6的存储地址，当前已对预处理文件4压缩完成，预处理文件5和6还未进行压缩。那么，压缩线程可以将预处理文件4、5、6的存储地址重新存入待发送文件队列；或者，将预处理文件4对应的压缩文件的存储地址和预处理文件5、6的存储地址存入待发送文件队列。

另外，此实施例中，发送线程在向目标电子设备发送文件时，传输文件所使用的数据通道的状态会发生变化，比如有时发送文件的速率比较快，有时发送文件的速率比较慢。那么，针对此情况，本申请实施例可以动态调整上述第二发送策略，以最大限度的使发送线程的性能达到最优。

作为一种可实现的方式，发送线程在发送文件时，可以获取当前的发送速率，若当前的发送速率小于预设的速率阈值，说明发送线程当前文件的速率比较慢，发送相同大小的文件所需的时间也相应较长，那么对于当前还在待发送文件队列中的直接发送类文件，软总线可以对其进行重新标记，例如将文件大小大于第二阈值(如60MB)但小于第三阈值(如100MB)的文件标记为预处理类文件，其他大于或者等于第三阈值的文件仍为直接发送类文件。由此，减少直接发送类文件的数量，可以在发送速率较慢的时候减轻发送线程的压力。

若当前的发送速率大于或者等于预设的速率阈值，说明发送线程当前文件的速率比较快，发送相同大小的文件所需的时间也相应较短，那么对于当前还在待发送文件队列中的预处理类文件，软总线可以对其进行重新标记，例如将文件大小大于或者等于第四阈值(如3KB)但小于第一阈值(如5KB)的文件标记为直接发送类文件，其他小于第四阈值的文件仍为预处理类文件。由此，增加直接发送类文件的数量，可以在发送速率较快的时候快速发送文件。

作为另一种可实现的方式，上述软总线根据预设的分类策略对待分享文件进行分类时，可以先对待分享文件的预设比例(如20％)进行分类，然后在发送线程发送文件时，再根据发送速率对剩余的待分享文件进行分类，并将分类后的待分享文件的存储地址和分类标记存储于待发送文件队列。示例性地，软总线先按上述预设的分类策略对待分享文件的预设比例进行分类，然后在发送文件时，若当前的发送速率小于预设的速率阈值，则将剩余的待分享文件中文件大小小于第一阈值(如5KB)的文件归为预处理类文件；对于文件大小大于第三阈值(如100MB)的文件归为直接发送类文件；对于文件大小在[第一阈值，第三阈值]之间的文件，再以文件类型进行分类；由此，减少直接发送类文件的数量，可以在发送速率较慢的时候减轻发送线程的压力。若当前的发送速率大于或者等于预设的速率阈值，则将剩余的待分享文件中文件大小小于第一阈值(如5KB)的文件归为预处理类文件；对于文件大小大于第四阈值(如50MB)的文件归为直接发送类文件；对于文件大小在[第一阈值，第四阈值]之间的文件，再以文件类型进行分类；由此，增加直接发送类文件的数量，可以在发送速率较快的时候快速发送文件。需要说明的是，软总线对剩余的待分享文件进行分类时，可以将剩余的全部待分享文件进行分类，或者，对其中的预设比例的待分享文件进行分类，并在预设的时间间隔后再次根据发送速率对剩余的待分享文件进行分类，以此类推。

作为又一种可实现的方式，发送线程可以根据当前的发送速率和剩余的直接发送类文件的总大小，估算发送剩余的直接发送类文件所需的第一时间，同时，压缩线程可以根据剩余的预处理类文件的类型和大小，估算压缩剩余的预处理类文件所需的第二时间，若第二时间大于第一时间，说明压缩线程所需的时间大于发送线程所需的时间，可能会造成发送线程等待的情况。那么，此时压缩线程可以停止压缩，或者，只对剩余的预处理类文件中的一部分进行压缩，其余的交由发送线程直接发送。

在一个实施例中，如图19所示，目标电子设备接收待分享文件的过程可以包括：

S1001，接收线程接收到待分享文件(此时可以称为已接收文件)。

S1002，将已接收文件存入相应的存储地址。

S1003，接收线程判断已接收文件中是否有压缩文件。

如果有，S1004，将压缩文件的存储地址写入后处理队列。

S1005，后处理线程从后处理队列中获取压缩文件的存储地址。

S1006，根据存储地址获取相应的压缩文件。

S1007，对压缩文件进行解压缩，得到解压缩后的文件。

S1008，将解压缩后的文件存入上述已接收文件对应的存储地址。

在一个实施例中，源电子设备在向目标电子设备发送文件的过程中，为方便用户查看发送进度，源电子设备上可以显示诸如“已发送10％”之类的显示字样，目标电子设备上可以显示诸如“已接收10％”之类的显示字样，本申请实施例对具体的显示内容不做限制。

上述分享文件的方法，在源电子设备将多个文件分享至目标电子设备时，可以根据多个文件的类型、大小等因素，将多个文件分类为直接发送类文件和预处理类文件，然后启动一个发送线程将直接发送类文件直接发送给目标电子设备，以及启动一个压缩线程将预处理类文件进行压缩，再由发送线程将压缩后的文件发送至目标电子设备。由此可以减少所分享文件的数据量，提高分享效率，并且两个线程并发执行也进一步提高了文件分享效率。

以上对本申请实施例提供的分享文件的方法进行了介绍，下面再以一个实施例对其进行描述，图20是本申请实施例提供的另一例分享文件的方法的流程示意图，该方法应用于源电子设备上，包括：

S201，源电子设备接收到用户作用于待分享文件的分享操作。

S202，响应于上述分享操作，与目标电子设备建立通信连接。

S203，对待分享文件进行分类，得到直接发送类文件和预处理类文件。

S204，调用压缩线程，对预处理类文件进行压缩，得到压缩文件。

S205，调用发送线程，通过上述通信连接的数据通道将直接发送类文件和压缩文件发送至目标电子设备。

其中，S203-S204的步骤可以与S202同时执行，S204和S205两个步骤可以并发执行，S201-S205步骤的具体实现过程可以参见上述实施例的描述；在本申请另一些实施例中，上述分享文件的方法还可以包括比图示更多或更少的步骤，在此不再赘述。

上文详细介绍了本申请实施例提供的分享文件的方法的示例。可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分为各个功能模块，例如检测单元、处理单元、显示单元等，也可以将两个或两个以上的功能集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

本实施例提供的电子设备，用于执行上述分享文件的方法，因此可以达到与上述实现方法相同的效果。

在采用集成的单元的情况下，电子设备还可以包括处理模块、存储模块和通信模块。其中，处理模块可以用于对电子设备的动作进行控制管理。存储模块可以用于支持电子设备执行存储程序代码和数据等。通信模块，可以用于支持电子设备与其他设备的通信。

其中，处理模块可以是处理器或控制器。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理(digital signal processing，DSP)和微处理器的组合等等。存储模块可以是存储器。通信模块具体可以为射频电路、蓝牙芯片、Wi-Fi芯片等与其他电子设备交互的设备。

在一个实施例中，当处理模块为处理器，存储模块为存储器时，本实施例所涉及的电子设备可以为具有图1或图2所示结构的设备。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得处理器执行上述任一实施例的分享文件的方法。

本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的分享文件的方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的分享文件的方法。

其中，本实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

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

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (17)

1.一种分享文件的方法，其特征在于，应用于第一电子设备，所述方法包括：

显示包含有第二电子设备的标识的第一界面；

当接收到用户在所述第一界面上作用于所述第二电子设备的标识的第一操作，与所述第二电子设备建立通信连接，所述第二电子设备用于接收所述第一电子设备发送的多个待分享文件；

对所述多个待分享文件中的第一类文件依次进行压缩，得到压缩文件；

基于所述通信连接对应的数据通道，将所述多个待分享文件中的第二类文件和已经得到的压缩文件发送至所述第二电子设备，所述第一类文件和所述第二类文件为依据预设的分类策略对所述多个待分享文件进行分类所得到，所述第一类文件为需要进行压缩的文件，所述第二类文件为直接发送至所述第二电子设备的文件。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

创建第一线程和第二线程；

所述对所述多个待分享文件中的第一类文件依次进行压缩，得到压缩文件，包括：

调用所述第一线程对所述第一类文件依次进行压缩，得到压缩文件；

所述将所述多个待分享文件中的第二类文件和已经得到的压缩文件发送至所述第二电子设备，包括：

调用所述第二线程将所述第二类文件和所述已经得到的压缩文件发送至所述第二电子设备，所述第一线程与所述第二线程并发执行。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：将所述第一类文件的存储地址存储于第一队列；

所述调用所述第一线程对所述第一类文件依次进行压缩，得到压缩文件，包括：

调用所述第一线程依次从所述第一队列中读取所述第一类文件的存储地址；

根据所述第一类文件的存储地址，获取所述第一类文件的数据；

对所述第一类文件的数据进行压缩，得到压缩文件。

4.根据权利要求3所述的方法，其特征在于，所述调用所述第一线程依次从所述第一队列中读取所述第一类文件的存储地址，包括：

调用所述第一线程依次从所述第一队列中读取预设数量的第一类文件的存储地址；

相应的，所述对所述第一类文件的数据进行压缩，得到压缩文件，包括：

依次对预设数量的第一类文件的数据进行压缩，得到所述压缩文件。

5.根据权利要求3或4所述的方法，其特征在于，在得到压缩文件之后，所述方法还包括：

调用所述第一线程对所述压缩文件进行存储，得到所述压缩文件的存储地址；

将所述压缩文件的存储地址存储于第二队列，所述第二队列存储有所述第二类文件的存储地址。

6.根据权利要求5所述的方法，其特征在于，所述调用所述第二线程将所述第二类文件和所述已经得到的压缩文件发送至所述第二电子设备，包括：

调用所述第二线程，从所述第二队列中读取所述第二类文件的存储地址和所述已经得到的压缩文件的存储地址；

根据所述第二类文件的存储地址，获取所述第二类文件的数据；

根据所述已经得到的压缩文件的存储地址，获取所述已经得到的压缩文件的数据；

将所述第二类文件的数据和所述已经得到的压缩文件的数据发送至所述第二电子设备。

7.根据权利要求5或6所述的方法，其特征在于，在所述第一线程和所述第二线程并发执行的过程中，若所述第二队列中的存储地址所对应的文件个数小于预设阈值，所述方法还包括：

读取所述第一队列中的第一存储地址，并将所述第一存储地址存储于所述第二队列，以及从所述第一队列中删除所述第一存储地址，所述第一存储地址为所述第一队列中还未被压缩的第一类文件的存储地址。

8.根据权利要求1-7任一项所述的方法，其特征在于，在与所述第二电子设备建立通信连接之后，所述方法还包括：

向所述第二电子设备发送第一消息，所述第一消息用于通知所述第二电子设备接收文件；

接收所述第二电子设备根据所述第一消息发送的确认接收文件的消息。

9.根据权利要求8所述的方法，其特征在于，所述第一消息携带所述多个待分享文件的文件类型、文件大小和文件简要信息中的至少一个信息。

10.根据权利要求1-9任一项所述的方法，其特征在于，所述分类策略为根据待分享文件的文件大小和/或文件类型进行分类的策略。

11.根据权利要求1-9任一项所述的方法，其特征在于，所述方法还包括：

显示包含有多个待分享文件的标识的第二界面；

当接收到所述用户在所述第二界面上作用于所述多个待分享文件的标识的第二操作，显示所述第一界面。

12.一种分享文件的方法，其特征在于，应用于第二电子设备，所述方法包括：

接收并存储第一电子设备发送的第二类文件和压缩文件；

将所述压缩文件的存储地址存储于第三队列；

创建第三线程；

调用所述第三线程从所述第三队列中读取所述压缩文件的存储地址；

根据所述压缩文件的存储地址，获取所述压缩文件的数据；

对所述压缩文件的数据进行解压缩，得到并存储第一类文件。

13.一种分享文件的系统，其特征在于，包括第一电子设备和第二电子设备；

所述第一电子设备执行如权利要求1至11中任一项所述的方法，所述第二电子设备执行如权利要求12所述的方法。

14.一种电子设备，其特征在于，包括：

一个或多个处理器；

一个或多个存储器；

所述存储器存储有一个或多个程序，当所述一个或者多个程序被所述处理器执行时，使得所述电子设备执行如权利要求1至11中任一项所述的方法。

15.一种电子设备，其特征在于，包括：

一个或多个处理器；

一个或多个存储器；

所述存储器存储有一个或多个程序，当所述一个或者多个程序被所述处理器执行时，使得所述电子设备执行如权利要求12所述的方法。

16.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储了计算机程序，当所述计算机程序被处理器执行时，使得所述处理器执行权利要求1至12中任一项所述的方法。

17.一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，其特征在于，当所述计算机程序代码在电子设备上运行时，使得该电子设备执行权利要求1至12中任一项所述的方法。

Images