CN108228077B - 存储区的管理方法、运行方法、装置、设备、可读介质 - Google Patents

Abstract

本申请公开了存储区的管理方法、运行方法、装置、设备、可读介质，该方法在预置阶段获取第一压缩包以及可执行文件，所述第一压缩包包括中间代码文件，所述可执行文件基于中间代码文件生成；将所述第一压缩包存储于系统分区，将所述可执行文件存储于数据分区。本申请可以减少用户的等待时间、缩短系统启动时间、提高系统性能。

Description

存储区的管理方法、运行方法、装置、设备、可读介质

技术领域

本申请涉及操作系统存储空间管理技术，尤其涉及智能设备的存储区的管理方法、预置压缩包的运行方法、电子设备、智能设备的存储区的管理装置、预置压缩包的运行装置及可读介质。

背景技术

智能设备的存储空间通常可以分为机身内部存储空间和外部扩展存储空间。机身内部存储空间通常被划分为只读存储区和可写存储区。只读存储区供操作系统使用，通常对用户不可见且无法修改，系统分区被配置在只读存储空间内。可写存储区对用户是可见的，通常数据分区被配置在可写存储区内。

目前，系统分区占用了过多的机身内部存储空间，而用户对于不可见的只读存储区无法修改，即无法删除和清理，因此影响了用户对机身内部存储空间的使用率。

发明内容

本申请提供智能设备的存储区的管理方法、预置压缩包的运行方法、电子设备、智能设备的存储区的管理装置、预置压缩包的运行装置及可读介质。

根据本申请实施例的第一方面，提供一种智能设备的存储区的管理方法，在预置阶段执行以下步骤：

获取第一压缩包以及可执行文件，所述第一压缩包包括中间代码文件，所述可执行文件基于中间代码文件生成；

将所述第一压缩包存储于系统分区，将所述可执行文件存储于数据分区。

根据本申请实施例的第二方面，提供一种预置压缩包的运行方法，该方法包括步骤：

检测数据分区是否存在可执行文件，如果存在，则运行所述可执行文件；所述可执行文件在预置阶段被存储于数据分区，所述可执行文件基于第一压缩包中的中间代码文件生成，所述所述第一压缩包在预置阶段被存储于系统分区。

根据本申请实施例的第三方面，提供一种智能设备，包括：

处理器；

存储处理器可执行指令的存储器；

其中，所述处理器耦合于所述存储器，用于读取所述存储器存储的程序指令，并作为响应，执行如下操作：

在预置阶段，获取第一压缩包以及可执行文件，所述第一压缩包包括中间代码文件，所述可执行文件基于中间代码文件生成；

将所述第一压缩包存储于系统分区，将所述可执行文件存储于数据分区。根据本申请实施例的第四方面，提供一种智能设备的存储区的管理装置，包括：

获取模块，用于在预置阶段获取第一压缩包以及可执行文件，所述第一压缩包包括中间代码文件，所述可执行文件基于中间代码文件生成；

存储处理模块，用于将所述第一压缩包存储于系统分区，将所述可执行文件存储于数据分区。

根据本申请实施例的第五方面，提供一种预置压缩包的运行装置，包括：

检测模块，用于检测数据分区是否存在可执行文件，如果存在，则通知处理模块，所述可执行文件在预置阶段被存储于数据分区，所述可执行文件基于第一压缩包中的中间代码文件生成，所述所述第一压缩包在预置阶段被存储于系统分区；

处理模块，用于运行所述可执行文件。

根据本申请实施例的第六方面，提供一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得终端设备执行如上所述的方法。

本申请所提供的实施例，将基于第一压缩包生成的与平台相关的可执行文件在设备工厂生产的预置阶段预置在数据分区，而不是系统分区，由于传统方案中，第一压缩包在出厂后被用户使用时本身就需要在数据分区释放一份可执行文件，因此预置的可执行文件并未占据额外的存储空间，并且由于数据分区预置有可执行文件，相对于传统技术在用户使用第一压缩包时需要在系统分区和数据分区均释放一份可执行文件的做法，不仅节省了系统分区的空间，并且无需执行第一压缩包编译生成可执行文件的过程，从而减少了用户的等待时间、缩短了系统启动时间、提高了系统性能。

附图说明

图1为本申请实施例中智能设备的存储区的结构示意图；

图2智能设备的存储区的管理方法的部分流程图；

图2a为图2的一应用实例中存储区的管理方法的部分流程图；

图3为本申请实施例中预置压缩包的运行方法的部分流程图；

图4为图3的一应用实例中预置压缩包的运行方法的部分流程图；

图5为本申请实施例中存储区的管理装置的逻辑框图；

图6为本申请实施例中预置压缩包的运行装置的逻辑框图；

图7为本申请实施例中存储区的管理装置/预置压缩包的运行装置的硬件架构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

一些编程语言可以生成与平台无关的中间代码，并可以通过虚拟机来执行这些中间代码，或编译成平台相关的可执行代码来执行。例如java语言、python、ruby、erlang、lisp、lua等编程语言。

很多应用需要将平台相关的可执行代码的中间代码文件进行压缩存储，然后在安装此应用时，利用中间代码文件的压缩包生成可执行文件。以Android系统为例，apk包是dex中间代码文件的压缩包形式，dex是java生成的平台无关的class字节码。apk包被存储在智能设备上，在安装应用时，apk包生成dex中间代码文件，然后由dex中间代码文件生成odex文件，odex文件即apk包所对应的可执行文件。本申请针对传统方案中平台相关的可执行代码在智能设备上的存储问题提出解决方案。

智能设备的内部存储区的结构可以参见图1，内部存储区11通常包括只读存储区21和可写存储区22；只读存储区21通常不允许用户修改，该只读存储区21可以包括启动分区31、内核分区32、系统分区33、灾备分区34。系统分区33不仅包括系统框架和库51，还包括预置第一压缩包52以及其他文件。第一压缩包52内可以包括中间代码文件以及其他资源，资源的类型例如图片等。可写存储区22可以包括数据分区35，存放用户可更改的数据，例如用户手工安装的各种应用软件，均可以放在数据分区35。

智能设备在工厂生产时，生产工艺的流程通常包括预置阶段和工厂复位阶段。在预置阶段，设备厂商通常将智能设备出厂时所需要在设备中提前植入的数据预置在智能设备的指定存储区，可参见图1，可以将操作系统启动相关的数据预置在启动分区31、操作系统内核的相关文件预置在内核分区32、系统框架和库51预置在系统分区。一些预置应用也是由设备厂商在设备预置阶段预置在设备存储区中。在智能设备出厂前，需要对设备的功能以及性能进行测试，然后在工厂复位阶段将测试数据清除，因此传统技术中，通常是将数据分区的数据全部清除。

申请人经过研究发现，系统分区占据了过多的存储空间的其中一个原因是各种预置第一压缩包52占据的空间较大，而且，由于某些预置应用对设备厂商产生盈利，因此预置应用的第一压缩包占据的存储空间越来越大，使得用户可使用的空间越来越小。申请人提出了智能设备的存储区的管理方法，可以有效节省系统分区占用存储空间的大小。

参见图2，一个实施例中揭示的智能设备的存储区的管理方法在预置阶段被执行，该方法包括的部分步骤如图2：

S201，获取第一压缩包以及可执行文件，第一压缩包包括中间代码文件，也可能包含其他资源，例如图片等资源；可执行文件基于中间代码文件生成。

S202，将第一压缩包存储于系统分区，将可执行文件存储于数据分区。

一些类型的第一压缩包，在被安装时，需要生成与平台相关的可执行文件。一种传统方案中，在智能设备出厂后，用户启动设备或者手动安装第一压缩包时，智能设备预置在系统分区的第一压缩包通过编译或解释器等方式生成平台相关的可执行文件，释放在系统分区，并且为了安全的目的也会同时释放在数据分区一份，再对数据分区的这一份可执行文件进行混淆加密动态定位等安全技术，防止对可执行文件进行动态修改等非法操作，对用户数据的安全造成不利影响。由于此过程发生在用户使用智能设备过程中，因此造成开机时间长、用户等待时间长等问题，并且占用存储空间较多。本实施例中，第一压缩包的可执行文件在设备工厂生产时就被预置在数据分区，智能设备出厂后，用户开机或手工安装第一压缩包时，数据分区的可执行文件直接被调用，而不需再由第一压缩包经过生成中间字节码、编译等过程生成，因此节省了安装时间，并且由于可执行文件存储在数据分区，不占用系统分区，因此节省了对存储空间的占用。不仅如此，由于预置在系统分区的第一压缩包的升级通常是无法在系统分区实现的，除非进行一次完整的FOTA升级，因此本实施例的另一个优点是，在智能设备响应升级指令时，可根据升级指令直接对数据分区的可执行文件进行升级操作，例如替换旧版本的可执行文件、增加新的补丁文件等等操作。

申请人还进一步考虑到用户在某些情况下可能会需要恢复出厂设置，此时数据分区将被清空，预置的可执行文件也会被清空，因此，为了解决用户恢复出厂设置导致的可执行文件丢失问题，在某些例子中，在智能设备的预置阶段，可以在系统分区预置一份可执行文件的压缩文件。由于可执行文件是以压缩的形式(例如利用无损压缩算法压缩)存储，因此相对于传统做法仍然可以较少的占用系统区域的存储空间。以Android系统中的电话界面应用为例，我们假设电话应用界面的应用的第一压缩包和未压缩的可执行文件需要占用的空间相同，实验数据显示，可执行文件经过压缩后可能需要占据的空间是第一压缩包所需要的空间的四分之一左右，因此可以看出，在系统分区存放压缩后的可执行文件比一些传统技术的做法大大减少了对存储空间的占用率。

值得指出，申请人在解决恢复出厂设置的问题时，充分兼顾了存储空间的占用问题以及系统运行效率的问题，在系统分区存放可执行文件的压缩文件，在数据分区存放未压缩的可执行文件，用户开机时可以直接读取数据分区的可执行文件，提高第一次启动的速度，而在用户恢复出厂设置时，读取系统分区的压缩文件，解压后释放到数据分区，重新获得智能设备出厂时的版本，从而保证不会因为恢复出厂设置而使第一压缩包无法运行。以Android系统的apk包或jar包为例，描述一个实例，请参见图2a。

apk包中通常包含有中间代码dex字节代码，这个代码无法直接在智能设备上执行，需要通过解释或编译的方式来执行。由于解释器会使执行过程损失一些运行效率，因此一些例子中会基于dex字节代码编译生成odex可执行文件。

S201步骤中的可执行文件可以是odex文件，该文件可以是apk包通过java编辑器编译成dex中间代码(S201a)，然后利用oat技术将dex中间代码编译而成(S202a)。生成odex文件后，将odex文件压缩(S203a)，压缩后的odex文件存放在系统分区(S204a)，未压缩的odex文件存放在数据分区(S205a)。

申请人还针对智能设备在响应清除数据的指令时，数据分区的数据被清除的问题，提出了解决方案。一些例子中，清除数据的指令可以是工厂复位阶段触发的指令，当然并不排除在其他例子中，工厂复位阶段和用户使用智能设备时请求恢复出厂设置情况下均采用类似的流程，使得在清除数据时保留数据分区的可执行文件。该解决方案可以设计如下流程实现：提前设置一个预定次数(例如首次、前两次等)，在该次数内响应清除数据的指令时，所清除得数据分区的数据不包括可执行文件。以工厂复位阶段保留可执行文件作为具体实现，此流程可以通过以下过程实现：

可以事先在数据分区划分出一个区域保存一标志位，用此标志位来代表工厂复位模式，然后在工厂复位模式完成后，此标志位被清除，以便用户在智能设备出厂后使用到恢复出厂设置请求时，清除数据分区的所有数据。为了区分是否为工厂模式，可以预先设置一个预定次数，在预定次数内不清除标志位。可以通过以下流程来作为具体实现：如果未达到预定次数，则将所述标志位和所述可执行文件写入内存RAM；并在清除数据分区的数据后，将标志位和可执行文件重新写入数据分区；如果达到预定次数，则清除数据分区的全部数据。

可以看出，此流程可以在工厂复位模式下，清除数据分区的数据时，先读出此标志位放入内存中，然后再将数据分区进行格式化处理，当格式化处理完成后，重新从内存中读取此标志位写入原始位置。针对数据分区的可执行文件也是如此，系统预置的可执行文件的总大小通常都小于系统RAM的可用大小，比如在实际生产的某手机中，odex文件的总大小是600M字节左右，而目前手机RAM的大小通常在1G字节以上，例如手机RAM通常会在2G～6G左右。这样，RAM空间很容易容纳格式化数据闪存芯片flash存储时暂存可执行文件的任务。在格式化完成后，再将数据从RAM中的虚拟盘写回到新建的数据分区上。

在其他实施例中，针对工厂对于生产时间要求更高，或者是RAM空间不足以暂存可执行文件的例子，可以对odex文件与其它数据的设置不同的目录，在删除数据分区的其它所有的数据文件时，保留可执行文件，而不用将整个数据分区格式化。

表1是一组实验数据，将传统技术中的操作系统版本(表中A版本)与本申请实施例的操作系统版本(表中B版本)的首次开机时间和工厂复位时间进行了对比，此处假设预先设置前两次的工厂复位时可执行文件被保留。可以看出，在预置可执行文件和工厂复位时不清除可执行文件的情况下，本申请实施例可以节省80秒左右的生产效率。

表1

	首次开机	第一次工厂复位	第二次工厂复位
				A版本	126607.127378秒	123609.760447秒	125083.55605秒
B版本	24068.656910秒	133836.906780秒	133796.231318秒

图3是运行预置压缩包的部分流程图。预置压缩包可以按照图2所描述的第一压缩包被预置的方式预置在智能设备的存储区中。

S301，检测数据分区是否存在可执行文件。

S302，如果存在，则运行所述可执行文件；可执行文件可以参照图2描述的方式在预置阶段被存储在数据分区中。

图3所描述的流程可以是在第一次运行或第一压缩包首次被运行时执行，通过图2描述的流程可以获知，由于在智能设备工厂生产阶段已经预置了可执行文件在数据分区，因此无需像某些传统技术那样，在开机运行或第一压缩包首次运行时才执行生成可执行文件的动作，大大节省了系统和应用的启动时间，在工厂复位阶段可以提高生产线的效率，而对于出厂后用户使用，也可减少用户等待时间。

一些实例中，还可以包括第一压缩包升级的流程：响应升级指令时，根据升级指令对数据分区的可执行文件进行升级。

某些例子中，用户可能通过恢复出厂设置清除了数据分区的可执行文件，则预置第一压缩包的运行方法还可以包括如下步骤：如果数据分区未保存第一压缩包的可执行文件，且系统分区保存有可执行文件的压缩文件，则将所述压缩文件解压到数据分区。从而将智能设备恢复到出厂版本。

另外，某些情况下，数据分区的可执行文件被删除后，系统分区可能未保存有可执行文件的压缩文件，为了保证第一压缩包在恢复出厂设置操作后仍可使用，可以基于系统分区所保存的第一压缩包生成可执行文件，并存储到数据分区。这是因为一些第一压缩包中携带有生成可执行文件的源文件，根据此源文件可以生成可执行文件。所生成的可执行文件的性能可能与预置可执行文件有所差异，但可以保证应用的基本功能。

图4是一个运行预置第一压缩包的实例，如图所示：

智能设备在首次开机或首次运行第一压缩包时，检测系统分区是否存在压缩的可执行文件(S401)，如果存在，则进一步检测数据分区是否有未压缩的可执行文件(S402)，如果有，则使用此可执行文件运行预置第一压缩包(S403)，如果没有检测到未压缩的可执行文件，则将系统分区的压缩文件解压生成可执行文件(S404)后执行S403。

如果系统分区不存在未压缩的可执行文件，则检测数据分区是否存在未压缩的可执行文件(S405)，如果有，则使用此可执行文件运行预置第一压缩包(S403)，如果数据分区不存在未压缩的可执行文件，则编译第一压缩包中的源文件，生成可执行文件(S406)。

需要指出，本申请并不限制图4为唯一的实现流程。在其他实例中运行预置第一压缩包的流程可以有所差异，例如，某些例子中，可能先检测数据分区是否存在可执行文件，然后再在某种条件下检查系统分区是否存在压缩的可执行文件等等。

图4所描述的过程可以通过以下步骤所描述的odex文件的生成过程作为具体实现：

1.system_server的framework层通过native方法getDexoptNeeded()从虚拟机得知是否需对指定的某个jar/apk做patchoat，以便对代码进行动态定位，防止被黑客或病毒修改劫持。

2.对指定的jar/apk包，若其system下对应的odex文件不存在且被压缩的odex存在(例如，.odex.gz文件存在)，虚拟机会通过1所述native方法的返回值告知framework层需对该jar/apk做patchoat。若是其他情况，则按原有逻辑执行。

3.在2返回需做patchoat时，system_server的framework层向installd守护进程请求对该jar/apk做patchoat。

4.installd守护进程收到请求后，计算jar/apk包在system路径下对应的odex的全路径(如/system/priv-app/Settings/Settings.apk,对应odex为/system/priv-app/Settings/oat/<isa>/Settings.odex)。

4.1如果odex存在，则按原有逻辑进行，以该odex作为输入做patchoat。

4.2如果odex不存在，但临时根目录(/data/dalvik-cache/temp-oat/)下存在相同路径的未压缩的odex(如/data/dalvik-cache/temp-oat/system/priv-app/Settings/oat/<isa>/Settings.odex)，则以此未压缩的odex作为patchoat的输入，生成的文件的路径和文件名可以与默认的一致。

4.3在4.2不满足的情况下，判断system下对应已压缩的odex.gz文件(如/system/priv-app/Settings/oat/<isa>/Settings.odex.gz)是否存在。若存在，则将该压缩文件解压至临时根目录对应的路径下，并以解压后的odex作为patchoat的输入。

本申请各实施例可以适用于基于虚拟机的操作系统，例如基于OAT技术的虚拟机的操作系统，针对OAT的Java虚拟机在使用被申请后会有较好的效果，某些实例中，可以将内存空间节省300M左右。

与前述存储区的管理方法以及预置压缩包的运行方法的实施例相对应，本申请还提供了存储区的管理装置以及预置压缩包的运行装置的实施例。

请参考图5，智能设备的存储区的管理装置500，包括：

获取模块501，用于在预置阶段获取第一压缩包以及可执行文件，所述第一压缩包包括中间代码文件，所述可执行文件基于中间代码文件生成；

存储处理模块502，用于将所述第一压缩包存储于系统分区，将所述可执行文件存储于数据分区。

一个例子中，所述存储处理模块502还可以用于在预置阶段将所述可执行文件的压缩文件存储于系统分区。

一个例子中，管理装置还可以包括清除模块(未在图5中示出)，用于在工厂复位阶段，清除数据分区的数据，所清除的数据不包括所述可执行文件。

作为例子，所述数据分区存储的数据还可以包括一标志位；

所述清除模块清除数据分区的数据的步骤可以包括：

如果未达到预定次数，则将所述标志位和所述可执行文件写入内存；并在清除数据分区的数据后，将标志位和可执行文件重新写入数据分区.

如果达到预定次数，则清除数据分区的全部数据。

在其他例子中，所述清除模块清除数据分区的数据的步骤可以包括：

根据数据存储的目录清除数据，所述可执行文件被存储的目录与其他数据被存储的目录不同。

请参见图6，预置压缩包的运行装置600，包括：

检测模块601，用于检测数据分区是否存在所述第一压缩包的可执行文件，如果存在，则通知处理模块，所述可执行文件在预置阶段被存储于数据分区，所述可执行文件基于第一压缩包中的中间代码文件生成，所述所述第一压缩包在预置阶段被存储于系统分区。

处理模块602，用于运行所述可执行文件；所述可执行文件在预置阶段被存储。

一个例子中，所述处理模块602，还可以用于在数据分区未保存所述第一压缩包的可执行文件，且系统分区保存有所述可执行文件的压缩文件时，将所述压缩文件解压到数据分区。

一个例子中，所述第一压缩包内预置有生成可执行文件的源文件；所述处理模块还可以用于：

如果数据分区未保存所述第一压缩包的可执行文件，且所述系统分区未保存所述可执行文件的压缩文件，则基于所述中间代码文件生成可执行文件，并存储到数据分区。

一个例子中，所述第一压缩包的类型可以包括apk包或jar包，所述可执行文件可以包括odex文件，所述中间代码文件可以包括dex文件。

一个例子中，处理模块602还可以在响应升级指令时，根据升级指令对数据分区的可执行文件进行升级。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本申请管理装置和运行装置的实施例可以应用在智能设备上。具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现中，智能设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

本申请的装置的实施例可以应用在智能设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在智能设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图7所示，为智能设备的一种硬件结构图，除了图7所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的智能设备通常根据该智能设备的实际功能，还可以包括其他硬件，对此不再赘述。智能设备的存储处理器可以是可执行指令的存储器；处理器可以耦合存储器，用于读取所述存储器存储的程序指令，并作为响应，执行如下操作：在预置阶段，获取第一压缩包以及可执行文件，所述可执行文件基于第一压缩包编译生成；

将所述第一压缩包存储于系统分区，将所述可执行文件存储于数据分区。

在其他实施例中，处理器所执行的操作可以参考上文方法实施例中相关的描述，在此不予赘述。

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

Claims (24)

1.一种智能设备的存储区的管理方法，其特征在于，在预置阶段执行以下步骤：

获取第一压缩包以及可执行文件，所述第一压缩包包括中间代码文件，所述可执行文件基于中间代码文件生成；

将所述第一压缩包存储于系统分区，将所述可执行文件存储于数据分区；

其中，所述方法还包括：

在响应清除数据的指令时，清除数据分区的数据，所述清除数据的指令包括工厂复位阶段触发的指令，所清除的数据不包括所述可执行文件；

其中，所述数据分区存储的数据还包括一标志位；所述清除数据分区的数据的步骤包括：

如果未达到预定次数，则将所述标志位和所述可执行文件写入内存；并在清除数据分区的数据后，将标志位和可执行文件重新写入数据分区；

如果达到预定次数，则清除数据分区的全部数据。

2.根据权利要求1所述的方法，其特征在于，在预置阶段执行的步骤还包括：

将所述可执行文件的压缩文件存储于系统分区。

3.根据权利要求1所述的方法，其特征在于，清除数据分区的数据的步骤包括：

根据数据存储的目录清除数据，所述可执行文件被存储的目录与其他数据被存储的目录不同。

4.根据权利要求1所述的方法，其特征在于，所述第一压缩包包括apk包或jar包，所述可执行文件包括odex文件。

5.一种预置压缩包的运行方法，其特征在于，该方法包括步骤：

检测数据分区是否存在可执行文件，如果存在，则运行所述可执行文件；所述可执行文件在预置阶段被存储于数据分区，所述可执行文件基于第一压缩包中的中间代码文件生成，所述第一压缩包在预置阶段被存储于系统分区；

其中，在所述预置阶段还包括：

在响应清除数据的指令时，清除数据分区的数据，所述清除数据的指令包括工厂复位阶段触发的指令，所清除的数据不包括所述可执行文件；

其中，所述数据分区存储的数据还包括一标志位；所述清除数据分区的数据的步骤包括：

如果未达到预定次数，则将所述标志位和所述可执行文件写入内存；并在清除数据分区的数据后，将标志位和可执行文件重新写入数据分区；

如果达到预定次数，则清除数据分区的全部数据。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括步骤：

如果数据分区未保存所述可执行文件，且系统分区保存有所述可执行文件的压缩文件，则将所述压缩文件解压到数据分区；所述可执行文件的压缩文件在预置阶段被保存。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括步骤：

如果数据分区未保存所述第一压缩包的可执行文件，且所述系统分区未保存所述可执行文件的压缩文件，则基于所述第一压缩包中的中间代码文件生成可执行文件，并存储到数据分区。

8.根据权利要求5所述的方法，其特征在于，所述第一压缩包的类型包括apk包或jar包，所述可执行文件包括odex文件，所述中间代码文件包括dex文件。

9.根据权利要求5所述的方法，其特征在于，所述方法还包括步骤：

响应升级指令时，根据升级指令对数据分区的可执行文件进行升级。

10.一种智能设备，其特征在于，包括：

处理器；

存储处理器可执行指令的存储器；

其中，所述处理器耦合于所述存储器，用于读取所述存储器存储的程序指令，并作为响应，执行如下操作：

在预置阶段，获取第一压缩包以及可执行文件，所述第一压缩包包括中间代码文件，所述可执行文件基于中间代码文件生成；

将所述第一压缩包存储于系统分区，将所述可执行文件存储于数据分区；

其中，所述处理器还被配置为，在响应清除数据的指令时，执行如下步骤，其中，清除数据的指令包括工厂复位阶段触发的指令：

清除数据分区的数据，所清除的数据不包括所述可执行文件；

其中，所述数据分区存储的数据还包括一标志位；

所述处理器执行清除数据分区的数据的步骤包括：

如果未达到预定次数，则将所述标志位和所述可执行文件写入内存；并在清除数据分区的数据后，将标志位和可执行文件重新写入数据分区；

如果达到预定次数，则清除数据分区的全部数据。

11.根据权利要求10所述的智能设备，其特征在于，所述处理器在预置阶段执行的步骤还包括：

将所述可执行文件的压缩文件存储于系统分区。

12.根据权利要求10所述的智能设备，其特征在于，所述处理器执行清除数据分区的数据的步骤包括：

根据数据存储的目录清除数据，所述可执行文件被存储的目录与其他数据被存储的目录不同。

13.根据权利要求10所述的智能设备，其特征在于，所述处理器还被配置为执行以下步骤：

检测数据分区是否存在所述可执行文件，如果存在，则运行所述可执行文件。

14.根据权利要求11所述的智能设备，其特征在于，所述处理器还被配置为执行：

如果数据分区未保存所述可执行文件，且系统分区保存有所述可执行文件的压缩文件，则将所述压缩文件解压到数据分区。

15.根据权利要求11所述的智能设备，其特征在于，所述处理器还被配置为执行步骤：

如果数据分区未保存所述可执行文件，且所述系统分区未保存所述可执行文件的压缩文件，则基于所述中间代码文件生成可执行文件，并存储到数据分区。

16.根据权利要求10所述的智能设备，其特征在于，所述第一压缩包的类型包括apk包或jar包，所述可执行文件包括odex文件，所述中间代码文件包括dex文件。

17.根据权利要求10所述的智能设备，其特征在于，所述处理器还被配置为：

响应升级指令时，根据升级指令对数据分区的可执行文件进行升级。

18.一种智能设备的存储区的管理装置，其特征在于，包括：

获取模块，用于在预置阶段获取第一压缩包以及可执行文件，所述第一压缩包包括中间代码文件，所述可执行文件基于中间代码文件生成；

存储处理模块，用于将所述第一压缩包存储于系统分区，将所述可执行文件存储于数据分区；

其中，所述管理装置还包括清除模块，用于在响应清除数据的指令时，清除数据分区的数据，所清除的数据不包括所述可执行文件，其中，清除数据的指令包括工厂复位阶段触发的指令；

其中，所述数据分区存储的数据还包括一标志位；

所述清除模块清除数据分区的数据的步骤包括：

如果未达到预定次数，则将所述标志位和所述可执行文件写入内存；并在清除数据分区的数据后，将标志位和可执行文件重新写入数据分区；

如果达到预定次数，则清除数据分区的全部数据。

19.根据权利要求18所述的管理装置，其特征在于，所述存储处理模块还用于在预置阶段将所述可执行文件的压缩文件存储于系统分区。

20.根据权利要求18所述的管理装置，其特征在于，所述清除模块清除数据分区的数据的步骤包括：

根据数据存储的目录清除数据，所述可执行文件被存储的目录与其他数据被存储的目录不同。

21.一种预置压缩包的运行装置，其特征在于，包括：

检测模块，用于检测数据分区是否存在可执行文件，如果存在，则通知处理模块，所述可执行文件在预置阶段被存储于数据分区，所述可执行文件基于第一压缩包中的中间代码文件生成，所述第一压缩包在预置阶段被存储于系统分区；

处理模块，用于运行所述可执行文件；

其中，所述预置阶段还用于在响应清除数据的指令时，清除数据分区的数据，所述清除数据的指令包括工厂复位阶段触发的指令，所清除的数据不包括所述可执行文件；

其中，所述数据分区存储的数据还包括一标志位；所述清除数据分区的数据的步骤包括：

如果未达到预定次数，则将所述标志位和所述可执行文件写入内存；并在清除数据分区的数据后，将标志位和可执行文件重新写入数据分区；

如果达到预定次数，则清除数据分区的全部数据。

22.根据权利要求21所述的运行装置，其特征在于，所述处理模块，还用于在数据分区未保存所述可执行文件，且系统分区保存有所述可执行文件的压缩文件时，将所述压缩文件解压到数据分区。

23.根据权利要求22所述的运行装置，其特征在于，所述处理模块还用于：

如果数据分区未保存所述可执行文件，且所述系统分区未保存所述可执行文件的压缩文件，则基于所述第一压缩包中的中间代码文件生成可执行文件，并存储到数据分区。

24.一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得终端设备执行如权利要求1-9任一项所述的方法。

Images