CN115794749A - 移动终端数据提取方法、装置、设备和存储介质 - Google Patents

Abstract

本发明公开了提取移动终端数据的方法、设备和存储介质，所述方法包括：获取所述目标目录中子目录的目录层级；当所述目录层级数大于预设层数时，在遍历缓存进行到预设进度后执行数据提取命令；当某一子目录中文件的碎片文件的数量和比例大于预设阈值时，在执行数据提取命令前将所述子目录中的所有文件进行打包。本发明根据现有技术中数据提取的效率低下的产生的多方面原因，采用了针对性的技术手段，包括：让遍历时间和数据提取时间相叠加，以充分利用遍历过程的时间；在进行数据提取前对数量巨大且碎片化严重的文件进行打包来减少握手次数，以提高传输效率。

Description

移动终端数据提取方法、装置、设备和存储介质

技术领域

本发明涉及移动终端数据处理领域，特别涉及移动终端数据提取方法、装置、设备和存储介质。

背景技术

移动终端的数据，特别是基于Android系统存储机制的移动终端，会在其三方应用被高频使用的同时会产生出海量的数据，从而占据移动终端中的内部存储。

三方应用所产生的数据中会包括很多有价值的信息，因此很多应用场景中，都有提取移动终端中数据的需要。

发明人经过研究发现，现有技术中对通过数据线对移动终端中数据进行拷贝的数据提取方式费时费力，且效率低下。

公开于该背景技术部分的信息仅仅旨在增加对本发明的总体背景的理解，而不应当被视为承认或以任何形式暗示该信息构成已为本领域一般技术人员所公知的现有技术。

发明内容

本发明的目的在于提高对于移动终端数据的提取效率。

本发明提供了一种提取移动终端数据的方法，包括步骤：

S11、获取所述目标目录中子目录的目录层级；当所述目录层级数大于预设层数时，在遍历缓存进行到预设进度后执行数据提取命令；

S12、当某一子目录中文件的碎片文件的数量和比例大于预设阈值时，在执行数据提取命令前将所述子目录中的所有文件进行打包。

优选的，在本发明实施例中，还包括：

在执行数据提取命令前，将已打包的文件进行压缩。

在本发明实施例的另一面，还提供了一种提取移动终端数据的方法，包括步骤：

S21、获取所述目标目录中子目录的目录层级；当所述目录层级数大于预设层数时，在遍历缓存进行到预设进度后执行数据提取命令；

S22、判断子目录中文件的文件数量和体量统计特性是否符合预设规则；

S23、如果是，在移动终端遍历并读取所述子目录后，将所述子目录的打包头信息及文件内容直接发送到TCP通道中；

S24、在数据接收端直接保存数据流到预设文件目录中，接收完毕后的数据为tar包数据。

优选的，在本发明实施例中，还包括：

上调IOBuffer缓冲区的大小防止频繁写入。

优选的，在本发明实施例中，所述预设进度包括：

遍历缓存进行到预设时间，或，完成缓存的数据达到预设体量，或，完成缓存的子目录达到预设目录数。

优选的，在本发明实施例中，还包括：

在执行数据提取命令时滤除特定的文件或文件夹。

优选的，在本发明实施例中，所述特定的文件包括：

文件类型为“.nomedia”的文件。

优选的，在本发明实施例中，还包括：

采用异步文件I/O方式写入数据，或，使用协程优化IO。

在本发明实施例的另一面，还提供了一种提取移动终端数据的设备，包括：

存储器，用于存储计算机程序；

处理器，用于调用并执行所述计算机程序，以实现如上任一项所述的提取移动终端数据的方法的各个步骤。

在本发明实施例的另一面，还提供了一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如上任一项所述的提取移动终端数据的方法的各个步骤。

所述提取移动终端数据的设备包括存储在介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行以上各个方面所述的方法，并实现相同的技术效果。

与现有技术相比，本发明具有如下有益效果：

综上所述，本发明实施例中，研究了总体体量（即数据量）大，文件数量巨大，存储目录层级数较多的数据存储场景下，数据提取的效率低下的产生的多方面原因，并采用了针对性的技术手段，包括：让遍历时间和数据提取时间相叠加，以充分利用遍历过程的时间；在进行数据提取前对数量巨大且碎片化严重的文件进行打包来减少握手次数，以提高传输效率。

上述说明仅为本发明技术方案的概述，为了能够更清楚地了解本发明的技术手段并可依据说明书的内容予以实施，同时为了使本发明的上述和其他目的、技术特征以及优点更加易懂，以下列举一个或多个优选实施例，并配合附图详细说明如下。

附图说明

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

图1是本发明中所述提取移动终端数据的方法的步骤图；

图2是本发明中所述提取移动终端数据的方法的又一步骤图；

图3是本发明中所述提取移动终端数据的设备结构示意图。

具体实施方式

下面结合附图，对本发明的具体实施方式进行详细描述，但应当理解本发明的保护范围并不受具体实施方式的限制。

除非另有其他明确表示，否则在整个说明书和权利要求书中，术语“包括”或其变换如“包含”或“包括有”等等将被理解为包括所陈述的元件或组成部分，而并未排除其他元件或其他组成部分。

在本文中，术语“第一”、“第二”等是用以区别两个不同的元件或部位，并不是用以限定特定的位置或相对关系。换言之，在一些实施例中，术语“第一”、“第二”等也可以彼此互换。

实施例一

为了提高对于移动终端数据的提取效率，如图1所示，在本发明实施例中提供了一种提取移动终端数据的方法，包括步骤：

S11、获取所述目标目录中子目录的目录层级；当所述目录层级数大于预设层数时，在遍历缓存进行到预设进度后执行数据提取命令；

本发明实施例基于ADB协议的交互机制，主要针对的是提取数据的总体体量（即数据量）大，文件数量巨大，存储目录层级数较多的数据存储场景；此外，本发明实施例中提取数据的对象可以是手机中微信或QQ等APP中的文本类数据和资源文件数据。

基于安卓系统下动终端的存储和应用的特性，通常会存在存储数据量异常庞大的同时，又存在大量碎片化文件的情况；也就是说，存在着巨大数量的“碎片化”文件（这里的碎片化特指单文件占用空间小）；而这类“小而多”的文件就会会导致在通过电脑等终端设备提取移动终端的数据存在时费时费力，且效率低下的问题。

以手机中的微信为例，微信作为使用率较高的应用程序，其频繁的应用便会促使每天在手机存储中生成大量的聊天数据，当需要进行其中有价值信息的完整提取时，往往涉及的数据量会很大。据分析可知，其中文本类聊天记录会直接存储在sqlite数据库中且占用极少量的存储，一般也就几十字节，但是聊天过程中产生的多媒体图片、语音、视频、文件这种资源类文件，其占用空间小至百、千字节大至万字节甚至百万字节，而这类多媒体数据占据了绝大部分的存储空间。通常情况下，微信的资源文件大小占据了微信总数据量的50%-70%左右。

此外，资源文件的特点除了文件小而多，目录也存在分级嵌套，因此逐层目录的扫描也会消耗大量时间，导致最终提取耗时大幅增长。

在一个实例中，以微信的语音资源文件为例数据，微信语音文件的存储路径为：

/sdcard/Android/data/com.tencent.mm/MicroMsg/aacac396ca6055a3919cb14190726930/voice2；

根据“voice2”文件夹属性概览，其文件属性为：文件夹数为：10738；文件数为：18902；总大小为201M。

由上可以发现目录的分类分层，基本上一个目录仅存储着1-2个文件，平均每个文件的大小也仅为10KB，属于十分零碎的文件，但其总容量居然高达211,629,136 字节。

发明人经过研究发现，现有技术之所以效率低下，其原因包括：提取流程中需要先遍历并缓存完所有的文件列表后才开始提取工作，这样，对于微信资源文件这种动辄几十万甚至上百万个文件和文件夹，就需要消耗非常多的时间，而这遍历文件列表过程的时间往往都会被直接浪费掉，十分影响整体的数据提取效率。为此，在本发明实施例中，本发明实施例不再等待先遍历并缓存完所有的文件列表，而是等遍历缓存到一定的进度后即行执行数据提取命令，从而有效地节约时间提高效率。

在实际应用中，本发明实施例中的预设阈值和预设层数时可以由本领域技术人员根据需要或有限次的实验来确定，在此并不做具体的限定。

本发明实施例的预设进度具体可以是：遍历缓存进行到预设时间，或，完成缓存的数据达到预设体量，或，完成缓存的子目录达到预设目录数。

S12、当某一子目录中文件的碎片文件的数量和比例大于预设阈值时，在执行数据提取命令前将所述子目录中的所有文件进行打包。

发明人还发现，常规方式进行数据提取时，提取每一个文件时都需要握手操作（ID_RECV指令），当提取数据是大量的碎片性文件（低于100KB的文件）时，会因为产生大量的握手操作导致效率低下。为此，在本发明实施例中，还根据子目录中的碎片性文件的数量和比例是否大于预设阈值来确定是否需要执行本步骤的打包指令来提高效率；这样，可以将大量的零散数据打包为整体的数据文件，经一次的握手既可以将所有数据一次性传输。进一步的，在本发明实施例中，还可以启用压缩（zip或者tar.gz）指令，通过减少数据的体量来进一步的节约数据传输时间。

需要说明的是，用于判断碎片文件的数量和比例的预设阈值的具体取值，可以由本领域技术人员根据工作经验或是有限次的实验来确定。

优选的，在本发明实施例中，在执行数据提取命令时，还可以滤除特定的文件或文件夹。

通过添加文件过滤器，从导出目录中过滤掉不需要提取的文件/文件夹。现有技术中在数据提取时，指定目标目录后，会提取目标目录中所有包含的文件及文件夹。

发明人经过研究发现，移动终端的数据文件中会有很多无用的垃圾文件或者缓存文件，提取这部分文件也会消耗较多时间。例如资源文件中会有大量的“.nomeida”文件，大小为0字节，该类型的文件就是最常见的无意义的文件，仅用于标记该目录中的图片文件不出现在手机系统相册中。此外，还有很多升级残留的系统组件等，也是没有利用价值的。

基于以上发现，本发明实施例通过通过添加过滤器，使用过滤规则对这些没有价值的特定的文件或文件夹进行过滤，以节省大量时间。

优选的，在本发明实施例中，还可以包括步骤：

S13、采用异步文件I/O方式写入数据，或，使用协程优化IO。

现有技术中虽然多线程可以叠加单位时间的任务，但是会产生额外的系统消耗，对于HDD机械硬盘来说，硬盘的读取写入操作本就非常缓慢，再加上大量创建小文件需要磁盘不停的切换寻址，同步执行本地文件操作产生的延迟就会非常明显。

在本发明实施例中，通过采用异步文件I/O方式写入数据，或，使用协程优化IO；这样，利用系统提供的异步文件IO方法让一些文件操作变为异步。ADB交互属于网络数据通信（ADBServer将USB传输的数据转换为电脑本机端口的TCP数据流），也可以结合协程相关方法，在不多开线程的情况下充分利用上等待接收数据时空闲的系统资源，提高效率。

具体来说，Windows系统中文件读写操作提供了OVERLAPPED方式异步读写文件，这样，发起写操作后，不用等待数据真正写入到硬盘，会立即返回交出操作权，让工作线程可以继续做其他操作，文件真正的写入结果可以通过OVERLAPPED中的事件句柄进行用来确认写操作无误。

协程（coroutine）是比线程更小化的实现方式，非常适合I/O阻塞型场景。相对于CPU速度来说，I/O速度是非常缓慢的，通过在阻塞时切换到其他协程上继续执行其他操作，可以充分利用CPU时间片，通过协程结合系统的事件机制，来有效提升任务执行效率。

让网络接收数据操作和保存文件操作并发进行，接收数据的工作时间和保存文件的工作时间相叠加，节省总时间。

综上所述，本发明实施例中，研究了总体体量（即数据量）大，文件数量巨大，存储目录层级数较多的数据存储场景下，数据提取的效率低下的产生的多方面原因，并采用了针对性的技术手段，包括：让遍历时间和数据提取时间相叠加，以充分利用遍历过程的时间；在进行数据提取前对数量巨大且碎片化严重的文件进行打包来减少握手次数，以提高传输效率。

实施例二

在本发明实施例的另一面，还提供了另一种提取移动终端数据的方法，如图2所示，包括步骤：

S21、获取所述目标目录中子目录的目录层级；当所述目录层级数大于预设层数时，在遍历缓存进行到预设进度后执行数据提取命令；

本发明实施例基于ADB协议的交互机制，主要针对的是提取数据的总体体量（即数据量）大，文件数量巨大，存储目录层级数较多的数据存储场景；此外，本发明实施例中提取数据的对象可以是手机中微信或QQ等APP中的文本类数据和资源文件数据。

基于安卓系统下动终端的存储和应用的特性，通常会存在存储数据量异常庞大的同时，又存在大量碎片化文件的情况；也就是说，存在着巨大数量的“碎片化”文件（这里的碎片化特指单文件占用空间小）；而这类“小而多”的文件就会会导致在通过电脑等终端设备提取移动终端的数据存在时费时费力，且效率低下的问题。

以手机中的微信为例，微信作为使用率较高的应用程序，其频繁的应用便会促使每天在手机存储中生成大量的聊天数据，当需要进行其中有价值信息的完整提取时，往往涉及的数据量会很大。据分析可知，其中文本类聊天记录会直接存储在sqlite数据库中且占用极少量的存储，一般也就几十字节，但是聊天过程中产生的多媒体图片、语音、视频、文件这种资源类文件，其占用空间小至百、千字节大至万字节甚至百万字节，而这类多媒体数据占据了绝大部分的存储空间。通常情况下，微信的资源文件大小占据了微信总数据量的50%-70%左右。

此外，资源文件的特点除了文件小而多，目录也存在分级嵌套，因此逐层目录的扫描也会消耗大量时间，导致最终提取耗时大幅增长。

在一个实例中，以微信的语音资源文件为例数据，微信语音文件的存储路径为：

/sdcard/Android/data/com.tencent.mm/MicroMsg/aacac396ca6055a3919cb14190726930/voice2；

根据“voice2”文件夹属性概览，其文件属性为：文件夹数为：10738；文件数为：18902；总大小为201M。

由上可以发现目录的分类分层，基本上一个目录仅存储着1-2个文件，平均每个文件的大小也仅为10KB，属于十分零碎的文件，但其总容量居然高达211,629,136 字节。

发明人经过研究发现，现有技术之所以效率低下，其原因包括：提取流程中需要先遍历并缓存完所有的文件列表后才开始提取工作，这样，对于微信资源文件这种动辄几十万甚至上百万个文件和文件夹，就需要消耗非常多的时间，而这遍历文件列表过程的时间往往都会被直接浪费掉，十分影响整体的数据提取效率。为此，本发明实施例不再等待先遍历并缓存完所有的文件列表，而是等遍历缓存到一定的进度后即行执行数据提取命令，从而有效地节约时间提高效率。

在实际应用中，本发明实施例中的预设阈值和预设层数时可以由本领域技术人员根据需要或有限次的实验来确定，在此并不做具体的限定。

本发明实施例的预设进度具体可以是：遍历缓存进行到预设时间，或，完成缓存的数据达到预设体量，或，完成缓存的子目录达到预设目录数。

S22、判断子目录中文件的文件数量和体量统计特性是否符合预设规则；

发明人还发现，常规方式进行数据提取时，提取每一个文件时都需要握手操作（ID_RECV指令），当提取数据是大量的碎片性文件（低于100KB的文件）时，会因为产生大量的握手操作导致效率低下。为此，在本发明实施例中，还根据子目录中的碎片性文件的数量和比例是否大于预设阈值来确定是否需要执行下面步骤的流传输方案来提高效率；

S23、如果是，在移动终端遍历并读取所述子目录后，将所述子目录的打包头信息及文件内容直接发送到TCP通道中；

如果子目录中的碎片性文件的数量和比例大于预设阈值，说明此时采用常规的数据提取方式的话，就会因为大量的握手过程造成效率降低；为此，在本发明实施例中，通过监听网络端口或者连接电脑已开放的端口，建立TCP连接后，遍历并读取该子目录，然后，将子目录的打包头信息及文件内容直接发送到TCP通道中。

优选的，为了避免移动终端TCP/IP协议栈缓存过小，在本发明实施例中，还可以适当上调IOBuffer缓冲区大小以防止频繁写入。

具体来说，默认情况下TCP接收/发送缓冲区一般是4k-16k，对于数据传输来说一个数据块足够填满缓冲区，如果对端接收不及时可能会造成阻塞延时。本发明实施例中，在TCP连接建立完毕后，可以通过setsockopt方法调整接收/发送缓冲区的大小到8-16M，这样，可以利用设备内存缓存来减少业务逻辑上的阻塞延时。

S24、在数据接收端直接保存数据流到预设文件目录中，接收完毕后的数据为tar包数据。

数据接收端直接保存数据流到文件，接收完毕后即为数据tar包（如果开启压缩就是zip包）。本发明实施例中，并不在移动终端执行打包命令，而是只给包括了很多碎片文件的子目录一个包头信息，然后将该子目录的数据传输到接收端后进行实时打包，这样，在数据传输的时候就不用对各个碎片文件进行逐个的握手。

在本发明实施例中，可以使用最为普及的HTTP接口作为接口协议，从而极大的便捷了应用的开发和测试。

需要说明的是，用于判断碎片文件的数量和比例的预设阈值的具体取值，可以由本领域技术人员根据工作经验或是有限次的实验来确定。

优选的，在本发明实施例中，在执行数据提取命令时，还可以滤除特定的文件或文件夹。

通过添加文件过滤器，从导出目录中过滤掉不需要提取的文件/文件夹。现有技术中在数据提取时，指定目标目录后，会提取目标目录中所有包含的文件及文件夹。

发明人经过研究发现，移动终端的数据文件中会有很多无用的垃圾文件或者缓存文件，提取这部分文件也会消耗较多时间。例如资源文件中会有大量的“.nomeida”文件，大小为0字节，该类型的文件就是最常见的无意义的文件，仅用于标记该目录中的图片文件不出现在手机系统相册中。此外，还有很多升级残留的系统组件等，也是没有利用价值的。

基于以上发现，本发明实施例通过添加过滤器，使用过滤规则对这些没有价值的特定的文件或文件夹进行过滤，以节省大量时间。

优选的，在本发明实施例中，还可以包括步骤：

S25、采用异步文件I/O方式写入数据，或，使用协程优化IO。

现有技术中虽然多线程可以叠加单位时间的任务，但是会产生额外的系统消耗，对于HDD机械硬盘来说，硬盘的读取写入操作本就非常缓慢，再加上大量创建小文件需要磁盘不停的切换寻址，同步执行本地文件操作产生的延迟就会非常明显。

在本发明实施例中，通过采用异步文件I/O方式写入数据，或，使用协程优化IO；这样，利用系统提供的异步文件IO方法让一些文件操作变为异步。ADB交互属于网络数据通信（ADBServer将USB传输的数据转换为电脑本机端口的TCP数据流），也可以结合协程相关方法，在不多开线程的情况下充分利用上等待接收数据时空闲的系统资源，提高效率。

综上所述，本发明实施例中，研究了总体体量（即数据量）大，文件数量巨大，存储目录层级数较多的数据存储场景下，数据提取的效率低下的产生的多方面原因，并采用了针对性的技术手段，包括：让遍历时间和数据提取时间相叠加，以充分利用遍历过程的时间；在进行数据提取前对数量巨大且碎片化严重的文件进行打包来减少握手次数，以提高传输效率。

实施例三

与方法实施例相对应的，本发明实施例中，还提供了一种提取移动终端数据的设备，如终端、服务器等。其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机等，但并不局限于此。

本申请实施例提供的提取移动终端数据的设备的硬件结构框图的示例图如图3所示，可以包括：

处理器1，通信接口2，存储器3和通信总线4；

其中处理器1、通信接口2、存储器3通过通信总线4完成相互间的通信；

可选的，通信接口2可以为通信模块的接口，如GSM模块的接口；

处理器1可能是一个中央处理器CPU，或者是特定集成电路ASIC (ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。

存储器3可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。

其中，处理器1具体用于执行存储器3中存储的计算机程序，以执行如下步骤：

S11、获取资源文件中目标目录中包括的子目录的目录层级，当所述目录层数大于预设层数时，在遍历缓存进行到预设进度后执行数据提取命令；

S12、当某一子目录中文件的碎片文件的数量和比例大于预设阈值时，在执行数据提取命令前将所述子目录中的所有文件进行打包，或者，

S21、获取资源文件中目标目录中包括的子目录的目录层级，当所述目录层数大于预设层数时，在遍历缓存进行到预设进度后执行数据提取命令；

S22、判断子目录中文件的文件数量和体量统计特性是否符合预设规则；

S23、如果是，在移动终端遍历并读取所述子目录后，将所述子目录的打包头信息及文件内容直接发送到TCP通道中；

S24、在数据接收端直接保存数据流到预设文件目录中，接收完毕后的数据为tar包数据。

上述产品可执行本发明实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本发明实施例所提供的提取移动终端数据的方法。

实施例四

本发明实施例中，还提供了一种存储介质，该存储介质可存储有适于处理器执行的程序，所述程序用于：

S11、获取资源文件中目标目录中包括的子目录的目录层级，当所述目录层数大于预设层数时，在遍历缓存进行到预设进度后执行数据提取命令；

S12、当某一子目录中文件的碎片文件的数量和比例大于预设阈值时，在执行数据提取命令前将所述子目录中的所有文件进行打包，或者，

S21、获取资源文件中目标目录中包括的子目录的目录层级，当所述目录层数大于预设层数时，在遍历缓存进行到预设进度后执行数据提取命令；

S22、判断子目录中文件的文件数量和体量统计特性是否符合预设规则；

S23、如果是，在移动终端遍历并读取所述子目录后，将所述子目录的打包头信息及文件内容直接发送到TCP通道中；

S24、在数据接收端直接保存数据流到预设文件目录中，接收完毕后的数据为tar包数据。

可选的，所述程序的细化功能和扩展功能可参照上文描述。

上述产品可执行本发明实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本发明实施例所提供的方法。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

应当理解，本申请实施例中，从权、各个实施例、特征可以互相组合结合，都能实现解决前述技术问题。

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

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种提取移动终端数据的方法，其特征在于，包括步骤：

S11、获取目标目录中子目录的目录层级；当所述目录层级数大于预设层数时，在遍历缓存进行到预设进度后执行数据提取命令；

S12、当某一子目录中文件的碎片文件的数量和比例大于预设阈值时，在执行数据提取命令前将所述子目录中的所有文件进行打包。

2.根据权利要求1中所述提取移动终端数据的方法，其特征在于，还包括：

在执行数据提取命令前，将已打包的文件进行压缩。

3.一种提取移动终端数据的方法，其特征在于，包括步骤：

S21、获取目标目录中子目录的目录层级；当所述目录层级数大于预设层数时，在遍历缓存进行到预设进度后执行数据提取命令；

S22、判断子目录中文件的文件数量和体量统计特性是否符合预设规则；

S23、如果是，在移动终端遍历并读取所述子目录后，将所述子目录的打包头信息及文件内容直接发送到TCP通道中；

S24、在数据接收端直接保存数据流到预设文件目录中，接收完毕后的数据为tar包数据。

4.根据权利要求1中所述提取移动终端数据的方法，其特征在于，还包括：

上调IOBuffer缓冲区的大小防止频繁写入。

5.根据权利要求1或2中所述提取移动终端数据的方法，其特征在于，所述预设进度包括：

遍历缓存进行到预设时间，或，完成缓存的数据达到预设体量，或，完成缓存的子目录达到预设目录数。

6.根据权利要求1或2中所述提取移动终端数据的方法，其特征在于，还包括：

在执行数据提取命令时滤除特定的文件或文件夹。

7.根据权利要求6中所述提取移动终端数据的方法，其特征在于，所述特定的文件包括：

文件类型为“.nomedia”的文件。

8.根据权利要求1或2中所述提取移动终端数据的方法，其特征在于，还包括：

采用异步文件I/O方式写入数据，或，使用协程优化IO。

9.一种提取移动终端数据的设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于调用并执行所述计算机程序，以实现如权利要求1-8中任一项所述提取移动终端数据的方法的步骤。

10.一种存储介质，其特征在于，包括软件程序，所述软件程序适于由处理器执行如权利要求1至8中任一所述提取移动终端数据的方法的步骤。

Images