一种基于Android系统优化开机应用安装时间的方法与流程

本发明涉及一种基于Android系统的优化开机应用安装时间的方法，属于软件技术领域。

背景技术：

目前，Android系统已经作为普遍的智能电视平台出现在我们面前，而分析Android系统的启动流程我们可以发现，仅扫包这一项工作就占据了较长的时间。所谓扫包，即开机时对应用文件的逐个解析，以完成应用安装这一动作。所以扫包在Android系统启动中是即重要又耗时。

同时，在国内对Android的系统的开机优化，多半集中在整体的智能电视开机流程上，即：从上电到启动程序启动Linux内核，再加载Android系统这个大过程。又或者，对Android系统扫包的范围进行缩小。没有对扫包这个流程本身进行优化的，所以，本说明就是针对这一点对Android的扫包流程进行了优化控制。

技术实现要素：
：

本发明的目的在于提供一种如何在Android平台上，在不影响开机扫包这一功能流程的前提下，通过对扫包这个流程本身进行优化，缩短Android系统开机扫包耗费的时间，达到优化Android开机耗时的目的技术方案，

在介绍本发明的具体技术方案之前，需要对相关技术进行说明。

首先介绍Android的扫包流程。Android系统的扫包主要是由系统服务PackageManagerService(以下简称PKMS服务)来完成。该服务会遍历存放应用文件，即APK文件的各个目录，并对APK文件进行解析，将解析后的应用信息保存在内存中，并同时更新保存安装信息的文件。从而完成整个扫包过程。提取出其中的重点流程，如下：

1.1解析单个APK文件。

1.2解析信息保存到内存，以后开机后的系统调用等。

1.3更新保存安装信息的文件。

在上述重点流程中，发现有三处耗时的地方，分别是：

2.1：位于过程1.1中的收集APK签名信息。在解析APK文件时，会同时解析到该APK中的签名文件，从而获取到签名信息保存下来。这个过程一般是第一次开机执行一次就行，但实验发现，它在第二次开机时又执行了一次，也就是说，第二次是多余的耗费了时间。

2.2：位于1.2过程中的给应用分配primayAbi值。分配primayAbi值：abi(Application Binary Interface)实际就是指应用程序基于哪种指令集来进行编译。不同类型的指令集会对应不用的lib库。所以Android在扫包的时候会将最适合机器性能发挥的ABI标记给正在被扫描的包文件。这个过程是调用了底层的标准接口。我们暂不关心这个这个Abi值是如何分配的。只用清楚这个过程会得到一个abi值，且会很耗时。

2.3：位于1.2过程中的/data/app/下的应用会释放拷贝自己的so库文件。

对于系统目录下的APK文件，它需要利用的库已经存放在了系统目录/system/lib/下面。而对于/data/app/下的应用，是属于第三方安装的应用，同时也包括了用户自由安装的应用。它的so库一般被压缩保存在了自己的APK文件中。所以在开机扫包时，需要把APK文件中包含的so库提取出来存放在指定目录下。这个过程是第三个耗时的过程。

本发明主要就是针对这三个耗时的地方，采取下面的技术方案来解决：

一种基于Android系统优化开机应用安装时间的方法，包括：

3.1在扫描完APK后PKMS服务更新对APK文件夹的访问时间戳的记录。

针对耗时2.1的分析，之所以第二次开机会进行一次多余的签名信息获取，主要是因为系统检测到APK文件的访问时间戳发生了变化，以为APK文件发生了更新所以进行了新一轮的签名信息获取。

其中，APK文件访问时间戳可调用Java基类File类的标准接口lastModified()来直接得到一个数据类型为Long的访问时间，它是直接被记录在文件系统中。

然而事实上APK文件并没有发生变化。而是由于PKMS这个系统服务记录的访问时间发生了错误。在第一次开始解析APK文件时，该系统服务记录了访问这个APK文件所在的文件夹(即/data/app/应用包名)的时间，而后面APK文件会释放自己包含的so库到这个文件夹(/data/app/应用包名)，所以此时这个文件夹的访问时间是改变了的，但是PKMS服务并没有记录下来。所以才导致了第二次开机时判断到访问时间不一致而引发的多余的签名信息的获取操作。

所以，为了避免这种情况的发生，在APK文件被扫描完毕以及释放完so库后，需要更新一次PKMS服务对访问时间戳的记录。节省出进行多余签名信息获取时耗费的时间。

3.2避免每次开机都进行primay cpu ABI值的分配和APK中so库的释放拷贝。

对于primay cpu ABI和APK中so库的拷贝，在APK没有发生变化的情况下，它们的内容也是不会发生变化的，所以没有必要每次开机都去进行这些耗时的工作。所以针对这一点，采取的措施有：

3.2.1在第一次开机扫包时，执行完整的扫包流程，并记录下给每个应用分配的ABI值，并将其保存到我们在文件系统中专门创建的一个记录文件。

3.2.2在后续开机中，ABI值直接从指定文件中获取。并不再进行APK中so库的释放拷贝动作。

3.2.3为了保证ABI值和so库的准确性，在应用自升级、卸载、电视恢复出厂设置、系统在线升级时，需要删除我们在3.2.3.2.1中的那个记录文件里对应的项。

这样一来，在下一次扫包时，若判断到扫描的包在记录文件中找不到对应的数据，则就会重新执行原生流程来获得ABI值和拷贝so库，这样就能保证ABI值和so库不会因为应用发生变化而没有更新的问题，从而保证了准确性。

本发明大大缩短了Android开机时的扫包时间，当然要排除第一次开机。提升了整个Android系统的开机速度，使用户能更快使用到Android智能电视，感受Android智能电视带来的无穷乐趣。

附图说明

图1为PKMS服务的扫包流程图。

图2为对PKMS服务已经进行优化修改后的扫包流程图。

具体实施方式

下面结合附图对本发明做进一步的说明。

附图1为PKMS服务的扫包流程图，图中黑圈标出的部分则表示在扫包流程中很耗时的，需要我们采用技术方案对其进行优化的部分。

附图2为对PKMS服务已经进行优化修改后的扫包流程图。其中粗体的部分就是我们新增的优化措施。其中包括：

在扫包前先去解析保存ABI信息的文件/data/packageABIs，并将内容存储到Hashmap列表中。

在扫包中判断列表中是否已经包含当前正在扫描的APK的abi值，若不包含，则先按照原生流程给其分配abi值和让/data/app/下apk释放拷贝so库。并且，记录下给它分配的abi值以及在最后更新APK文件夹的访问时间戳。

若判断到列表中已经包含了当前正在扫描的APK的abi值，则将abi值直接赋给APK解析结果存储对象PackageParser.Package pkg中的applicationInfo成员。

最后再更新/data/packageABIs文件的内容。

本发明具体实施例详细的步骤如下：

5-1在扫描完每个APK后，PKMS服务对APK文件所在文件夹的访问时间戳进行重新保存。

PKMS服务中解析APK文件的标准接口为scanPackageDirtyLI

在该接口中，保存APK文件所在文件夹的访问时间戳的任务是由一个类型为PackageSetting的对象来完成的。

所以，实施方式就是在该标准接口的末尾，添加如下方法来完成时间的保存：

pkgSetting.setTimeStamp(scanFile.lastModified())；

其中，pkgSetting就是负责保存访问时间戳的PackageSetting对象。系统在整个扫包流程结束后，会将这个对象中的值保存到对应的文件中。

setTimeStamp是PackageSetting类的标准接口，用来保存时间。

scanFile就是当前解析的APK所在的文件夹File对象。

lastModified()就是File对象的标准接口，获取File对象的最后被访问的时间戳。

5-2避免每次开机在扫包时都进行对APK文件的ABI值分配和APK中so库的拷贝。

首先，需要在PKMS服务中添加如下的接口

void readPackageABIs()

作用：从特定的保存ABI值的文件/data/packageABIs中解析各个APK应用对应的ABI值，并赋值给对象mPackageAbis。mPackageAbis对象的类型为HashMap<String,String>，key代表每个APK文件对应的应用包名，value代表每个APK文件被分配的ABI值。

void writePackageABIs()

作用：将mPackageAbis对象中的内容保存到特定文件/data/packageABIs中。

void updatePackageABI(PackageParser.Package pkg)

作用：将之前保存好的abi值直接分配给APK文件的解析结果存储对象，即接口中的参数pkg对象。

void updateAbiItem(String pkgname,String abis)

作用：更新mPackageAbis对象中存储的内容。

5-2-1：在PKMS服务启动的时候，先解析保存ABI值的文件内容。

在PKMS服务的构造函数中，在扫包流程之前，调用新增接口readPackageABIs

去解析文件/data/packageABIs，并将内容保存在HashMap对象mPackageAbis中。

5-2-2：在PKMS扫包中，判断是否需要跳过ABI值的分配过程和so库的拷贝过程。

在解析每个APK文件时，先判断mPackageAbis对象是否为空，

若为空或者mPackageAbis列表里没有存储当前正在解析的APK文件的对应信息，则重新按照原标准流程进行系统的ABI值分配，和/data/app/下APK文件的so库拷贝动作。分配完毕之后，将分配的ABI值和对应APK文件的应用包名通过调用添加接口updateAbiItem保存在mPackageAbis对象中。

若不为空且mPackageAbis列表中包含了当前正在解析的APK文件的对应信息，则直接跳过标准流程，不进行ABI值的分配和/data/app/下APK文件的so库拷贝动作。直接调用接口updatePackageABI,将之前保存的当前正在解析的APK文件对应的ABI值赋给APK文件解析结果保存对象PackageParser.Package pkg中。

5-2-3：即时更新保存应用ABI值的特定文件/data/packageABIs内容。

首先，在PKMS服务的整个扫包流程结束后，需要调用writePackageABIs()将mPackageAbis中记录的信息保存到/data/packageABIs文件中。

其次，在应用的自升级时(对应调用PKMS服务的标准接口installPackageLI)、以及卸载应用时(对应调用PKMS服务的标准接口deletePackageX)需要删掉mPackageAbis列表中保存的对应信息，并调用接口writePackageABIs()同步到/data/packageABIs文件中。

最后，需要在系统差分升级时删掉文件/data/packageABIs。这个动作需要在系统升级模块中添加。

尽管这里参照本发明的解释性实施例对本发明进行了描述，上述实施例仅为本发明较佳的实施方式，本发明的实施方式并不受上述实施例的限制，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式将落在本申请公开的原则范围和精神之内。