具体实施方式
下面详细描述本申请的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,旨在用于解释本申请,而不能理解为对本申请的限制。
下面参考附图描述本申请实施例的数据处理方法、装置及终端设备。
图1是本申请一个实施例的数据处理方法的流程图。
如图1所示,该数据处理方法包括:
步骤101,构建与待处理的第一应用数据对应的打包指令,其中,所述打包指令包括:所述第一应用数据的第一源路径和第一目的路径。
步骤102,通过Java层中用于与native层通信的封装类,将所述打包指令发送给所述native层。
具体地,本实施例提供的数据处理方法被配置具有操作系统的终端设备中执行。需要注意的是,终端设备的类型很多,可以根据应用需要进行选择,例如:手机、平板电脑等。
在实际应用中,用户会将所需要的应用数据进行备份,在不同的应用场景中对该备份的应用数据进行恢复处理,举例说明如下:
示例一,假设用户对终端设备A中的应用数据进行备份处理保存在终端设备A中。当终端设备A进行刷机还原后,用户可以通过对终端设备A中保存的备份数据进行恢复,使用户可以在终端设备A上正常使用之前的应用数据。
示例二,假设用户对终端设备A中的应用数据进行备份处理保存在终端设备A中。当用户更换终端设备B后,用户需要将终端设备A中保存的备份数据传输到终端设备B上进行恢复,使用户可以在终端设备B上正常使用之前的应用数据。
以上情况仅为举例说明。但是,目前对应用数据进行备份的效率很低,速度瓶颈主要在Java层用IO流的操作来实现应用数据的打包。其中,打包即对应用数据进行备份。由于Java层的操作相对native层的底层操作来说比较耗时,也就导致了整体备份操作速度比较慢。
为了提高应用数据的备份速度,就要减少应用数据打包时间,本实施例提供的数据处理方法在native层植入目前在BusyBox来实现应用数据的打包。从而将应用数据的打包操作从Java层移植到native层(C底层),即在Linux操作系统下来实现应用数据的打包操作。
需要说明的是,BusyBox是一个集成了一百多个最常用linux命令和工具的软件。BusyBox包含了一些简单的工具,例如ls、cat和echo等等,还包含了一些更大、更复杂的工具,例grep、find、mount以及telnet,简单的说BusyBox就是个大工具箱,它集成压缩了Linux的许多工具和命令。其中,busybox里有tar命令,可以用来实现数据的打包操作。
为了使Java层和native层进行信令交互,在Java层设置用于与native层通信的封装类,例如:假设在Java层封装一个与native层通信的类A,通信方式为socket。以及在native层编写c文件,接收从Java层的类A传入的消息,进而在native层(即Linux层)执行命令。
进而,根据用户指令需要对应用程序的原始数据(即本申请中涉及的第一应用数据)进行打包备份时,Java层构建与待处理的第一应用数据对应的打包指令,其中,该打包指令包括:该第一应用数据的第一源路径和第一目的路径。
需要解释的是,第一源路径是当前的终端设备中用于存储第一应用数据的目录文件路径;第一目的路径是当前的终端设备中用于存储第一应用数据的备份数据(即本申请中涉及的第二应用数据)的目录文件路径。
进而,将该打包指令传递给与native层通信的封装类,封装类通过socket将该打包指令发送给native层。
步骤103,通过所述native层解析所述打包指令,从所述第一源路径获取所述第一应用数据进行打包处理生成第二应用数据,并存储到所述第一目的路径。
具体地,native层对接收到的打包指令进行解析,获取第一应用数据的第一源路径和第一目的路径。进而在native层执行打包指令,从第一源路径获取第一应用数据进行打包处理生成第二应用数据,并存储到第一目的路径。
基于上述实施过程,通过将Java层对应用数据的打包操作移植到native层(C底层),即在Linux操作系统下来实现应用数据的打包处理。假设200M的数据打包时间在Java层需要60秒左右,在native层需要20秒左右,优化速度显著。
本申请实施例的数据处理方法,通过构建与待处理的第一应用数据对应的打包指令,其中,所述打包指令包括:所述第一应用数据的第一源路径和第一目的路径;通过Java层中用于与native层通信的封装类,将所述打包指令发送给所述native层;通过所述native层解析所述打包指令,从所述第一源路径获取所述第一应用数据进行打包处理生成第二应用数据,并存储到所述第一目的路径。由此,实现了提高了应用数据的备份处理速度,节约了处理时间。
基于上述实施例,进一步地,由于有些文件数据在检测出终端设备更换的情况下不允许进行恢复反打包处理,以第一应用数据中的第一文件为例说明如下:假设在第一终端设备上对第一应用数据进行打包备份处理,但是第二终端设备获取第一终端设备上的备份数据,将备份数据在第二终端设备上进行恢复时,第一文件检测出由第一终端设备更换为第二终端设备,则不允许进行反打包的恢复处理。
因此,针对上述应用场景,可以预先设置具有安全检测的文件信息,即过滤文件的路径信息。进而,Java层构建与待处理的第一应用数据对应的打包指令中还包括:第一应用数据中过滤文件的路径信息,所述方法还包括:
native层对接收到的打包指令进行解析,获取第一应用数据中过滤文件的路径信息,根据该路径信息确定过滤文件,并对该过滤文件不进行打包处理,以免第二终端设备对第一终端设备上打包的第一应用数据恢复时,具有安全检测功能的文件数据不允许进行反打包的恢复处理。
基于上述实施例描述的通过所述native层执行打包指令,对第一应用数据进行打包处理后生成第二应用数据之后,可以根据应用需要在第二应用数据所在的终端设备中,或者更换的终端设备中进行恢复的反打包处理。具体通过图2所示实施例进行描述,具体如下:
图2是本申请另一个实施例的数据处理方法的流程图。
如图2所示,在步骤103之后,该数据处理方法还包括:
步骤201,构建与所述第二应用数据对应的反打包指令,其中,所述反打包指令包括:所述第二应用数据的第二源路径和第二目的路径。
步骤202,通过Java层中用于与native层通信的封装类,将所述反打包指令发送给所述native层。
具体地,目前对应用数据进行恢复的效率很低,速度瓶颈主要在Java层用IO流的操作来实现应用数据的反打包。其中,反打包即对应用数据进行恢复。由于Java层的操作相对native层的底层操作来说比较耗时,也就导致了整体恢复操作速度比较慢。
为了提高应用数据的恢复速度,就要减少应用数据反打包时间,本实施例提供的数据处理方法在native层植入目前在BusyBox来实现应用数据的反打包。从而将应用数据的反打包操作从Java层移植到native层(C底层),即在Linux操作系统下来实现应用数据的反打包操作。
需要说明的是,BusyBox是一个集成了一百多个最常用linux命令和工具的软件。BusyBox包含了一些简单的工具,例如ls、cat和echo等等,还包含了一些更大、更复杂的工具,例grep、find、mount以及telnet,简单的说BusyBox就是个大工具箱,它集成压缩了Linux的许多工具和命令。其中,busybox里有tar命令,可以用来实现数据的反打包操作。
进而,根据用户指令需要对应用程序的备份数据(即本申请中涉及的第二应用数据)进行反打包恢复时,Java层构建与第二应用数据对应的反打包指令,其中,该反打包指令包括:该第二应用数据的第二源路径和第二目的路径。
需要解释的是,第二源路径是用于存储第二应用数据的源文件路径;第二目的路径是当前的终端设备中用于恢复后应用数据的目录文件路径。
进而,将该反打包指令传递给与native层通信的封装类,封装类通过socket将该反打包指令发送给native层。
步骤203,通过所述native层解析所述反打包指令,从所述第二源路径获取所述第二应用数据进行反打包处理,并存储到所述第二目的路径。
具体地,native层对接收到的反打包指令进行解析,获取第二应用数据的第二源路径和第二目的路径。进而在native层执行反打包指令,从第二源路径获取第二应用数据进行反打包处理并存储到第二目的路径。
基于上述实施过程,通过将Java层对应用数据的反打包操作移植到native层(C底层),即在Linux操作系统下来实现应用数据的反打包处理。假设200M的数据反打包时间在Java层需要60秒左右,在native层需要20秒左右,优化速度显著。
本申请实施例的数据处理方法,通过构建与第二应用数据对应的反打包指令,其中,所述反打包指令包括:所述第二应用数据的第二源路径和第二目的路径;通过Java层中用于与native层通信的封装类,将所述反打包指令发送给所述native层;通过所述native层解析所述反打包指令,从所述第二源路径获取所述第二应用数据进行反打包处理,并存储到所述第二目的路径。由此,实现了提高了应用数据的恢复处理速度,节约了处理时间。
基于上述实施例,进一步地,由于终端设备不同,在第一终端设备对第一应用数据进行打包处理后的第二应用数据可能具有安全检测功能的文件数据。为了兼容第一终端设备上的第二应用数据,如果检测到第二终端设备从第一终端设备获取所述第二应用数据,在第二终端设备对第二应用数据进行反打包恢复时,根据预设的过滤文件的路径信息从所述第二应用数据中获取过滤文件,对该过滤文件进行删除处理。
基于上述实施例,进一步地,由于SELinux的安全管控,在Linux层执行相关应用数据打包指令的时候会被阻止,需要在native层加入执行相关应用数据的打包权限和反打包权限。不同平台的手机需要添加的权限文件也不一样,需要根据log手动逐个添加权限,例如:
在init_shell.te文件中加入allow init_shell app_data_file:dir{read};意思为允许对类型init_shell对类型为app_data_file的目录进行读操作。
为了实现上述实施例,本申请还提出一种数据处理装置。
图3是本申请一个实施例的数据处理装置的结构示意图。
如图3所示,该数据处理装置包括:
第一构建模块11,用于构建与待处理的第一应用数据对应的打包指令,其中,所述打包指令包括:所述第一应用数据的第一源路径和第一目的路径;
第一发送模块12,用于通过Java层中用于与native层通信的封装类,将所述打包指令发送给所述native层;
第一处理模块13,用于通过所述native层解析所述打包指令,从所述第一源路径获取所述第一应用数据进行打包处理生成第二应用数据,并存储到所述第一目的路径。
基于上述实施例,进一步地,在另一个实施例中,所述打包指令还包括:所述第一应用数据中过滤文件的路径信息,所述第一处理模块13还用于:
根据所述路径信息确定所述过滤文件,对所述过滤文件不进行打包处理。
基于上述实施例,进一步地,在另一个实施例中,所述第一处理模块13还用于:
在所述native层加入执行相关应用数据的打包权限。
需要说明的是,前述对数据处理方法实施例的解释说明也适用于该实施例的数据处理装置,此处不再赘述。
本申请实施例的数据处理装置,通过构建与待处理的第一应用数据对应的打包指令,其中,所述打包指令包括:所述第一应用数据的第一源路径和第一目的路径;通过Java层中用于与native层通信的封装类,将所述打包指令发送给所述native层;通过所述native层解析所述打包指令,从所述第一源路径获取所述第一应用数据进行打包处理生成第二应用数据,并存储到所述第一目的路径。由此,实现了提高了应用数据的备份处理速度,节约了处理时间。
图4是本申请另一个实施例的数据处理装置的结构示意图。
如图4所示,基于图3所示实施例,所述装置还包括:
第二构建模块14,用于构建与所述第二应用数据对应的反打包指令,其中,所述反打包指令包括:所述第二应用数据的第二源路径和第二目的路径;
第二发送模块15,用于通过Java层中用于与native层通信的封装类,将所述反打包指令发送给所述native层;
第二处理模块16,用于通过所述native层解析所述反打包指令,从所述第二源路径获取所述第二应用数据进行反打包处理,并存储到所述第二目的路径。
基于上述实施例,进一步地,在另一个实施例中,所述第二处理模块16还用于:
如果检测到第二终端设备从第一终端设备获取所述第二应用数据,根据预设的过滤文件的路径信息从所述第二应用数据中获取过滤文件,对所述过滤文件进行删除处理。
基于上述实施例,进一步地,在另一个实施例中,所述第二处理模块16还用于:
在所述native层加入执行相关应用数据的反打包权限。
需要说明的是,前述对数据处理方法实施例的解释说明也适用于该实施例的数据处理装置,此处不再赘述。
本申请实施例的数据处理装置,通过构建与第二应用数据对应的反打包指令,其中,所述反打包指令包括:所述第二应用数据的第二源路径和第二目的路径;通过Java层中用于与native层通信的封装类,将所述反打包指令发送给所述native层;通过所述native层解析所述反打包指令,从所述第二源路径获取所述第二应用数据进行反打包处理,并存储到所述第二目的路径。由此,实现了提高了应用数据的恢复处理速度,节约了处理时间。
为了实现上述实施例,本申请还提出一种终端设备。
本申请提供的终端设备包括设备本体,以及如上所述的数据处理装置。
需要说明的是,前述对数据处理方法实施例的解释说明也适用于该实施例的终端设备,其实施过程和技术效果类似,此处不再赘述。
在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
此外,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中,“多个”的含义是至少两个,例如两个,三个等,除非另有明确具体的限定。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为,表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分,并且本申请的优选实施方式的范围包括另外的实现,其中可以不按所示出或讨论的顺序,包括根据所涉及的功能按基本同时的方式或按相反的顺序,来执行功能,这应被本申请的实施例所属技术领域的技术人员所理解。
在流程图中表示或在此以其他方式描述的逻辑和/或步骤,例如,可以被认为是用于实现逻辑功能的可执行指令的定序列表,可以具体实现在任何计算机可读介质中,以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用,或结合这些指令执行系统、装置或设备而使用。就本说明书而言,"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下:具有一个或多个布线的电连接部(电子装置),便携式计算机盘盒(磁装置),随机存取存储器(RAM),只读存储器(ROM),可擦除可编辑只读存储器(EPROM或闪速存储器),光纤装置,以及便携式光盘只读存储器(CDROM)。另外,计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质,因为可以例如通过对纸或其他介质进行光学扫描,接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序,然后将其存储在计算机存储器中。
应当理解,本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中,多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如,如果用硬件来实现,和在另一实施方式中一样,可用本领域公知的下列技术中的任一项或他们的组合来实现:具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路,具有合适的组合逻辑门电路的专用集成电路,可编程门阵列(PGA),现场可编程门阵列(FPGA)等。