操作系统缓存文件处理方法与流程

1.本说明书一个或多个实施例涉及操作系统技术领域，尤其涉及一种操作系统缓存文件处理方法。


背景技术：

2.自20世纪中后期以来，随着计算机技术的飞速发展，从电子管到超大规模集成电路，运算速度大幅提高，体积也越来越小，至20世纪末期个人计算机终端得到普及。如图2所示，计算机科学家为了使人与计算机更好的交互，让普通人使用计算机终端更便利，故而发明了运行于计算机的操作系统。得益于互联网的高速发展，用户安装的应用软件越来越多，软件安装和使用过程所产生的缓存日志等缓存文件会占用智能终端大量的rom存储空间。如果无法及时清理缓存文件，将会带来运行内存不足、运行卡顿等不良后果。
3.目前，用户通常使用手机助手、手机管家等应用程序来清理内存，但此类应用程序并不能彻底清除缓存、卸载残留等缓存文件。因为清理软件大多分为两种。一种是：以后缀名识别缓存文件(例如，以log等作为后缀名的文件)和类似cache的文件夹识别，这种方式识别精度低，无法清理干净，也可能造成误删等问题；另一种是：技术人员分析部分主流应用程序的文件夹结构，人工标识缓存文件并存储文件路径至云端，清理软件在执行清理的时候从云端获取缓存文件路径并根据该文件路径检测本地文件系统进行清理操作。此种方式可以精确定位缓存文件，但局限性很大，仅限于主流应用程序，并且随着程序升级，该应用下文件夹结构可能发生变化，因此该方式局限性大，不灵活。


技术实现要素：

4.本说明书一个或多个实施例描述了一种操作系统缓存文件处理方法。
5.本发明提供了一种操作系统缓存文件处理方法，包括：
6.操作系统的框架层获取应用程序的身份信息以及在安装过程中所述应用程序的安装压缩包解压后的文件目录；所述身份信息包括所述应用程序的名称和/或唯一标识；
7.在所述应用程序首次启动运行时，所述应用程序调用所述框架层的文件操作接口，通过文件操作接口将运行过程所产生的缓存文件的文件信息传递给所述框架层；所述文件信息包括文件名称、路径和后缀名；
8.所述操作系统的文件系统根据所述框架层接收到的文件信息，在所述文件目录下的对应位置生成对应的文件和文件夹，将所述缓存文件存储至生成的所述文件夹中，并生成数据记录表，所述数据记录表中存储有所述文件信息与对应的文件或文件夹之间的映射关系；
9.所述应用程序在对缓存文件进行预设处理时，调用所述框架层中对应的预设接口，并将预设处理对应的处理请求通过所述预设接口传递给所述框架层；所述框架层根据接收到的处理请求和所述数据记录表，确定所述待处理文件和/或待处理文件夹，对所述待处理文件和/或待处理文件夹进行预设处理，并对所述数据记录表进行更新。
10.本说明书实施例提供的操作系统缓存文件处理方法，在安装压缩包解压后的文件目录下生成新的文件和文件夹，用来存储缓存数据，同时还生成数据记录表，用来记录文件信息与文件、文件夹之间的映射关系，在应用程序对缓存文件进行预设处理时，框架层会根据数据记录表在文件目录下找到对应的文件、文件夹，进而对其进行预设处理，同时还对数据记录表中的信息进行更新，从而保证数据记录表与文件、文件夹的一致性。可见，通过本发明提供的方法可以精准的找到对应的缓存文件，进而对其进行重命名、删除等处理。在缓存数据过多时，可以实现精准的找到缓存文件，及时清理，并且不会发生误删，从而解决缓存文件过多造成的内存不足、运行卡顿等不良后果。而且本发明提供的方法不限于主流应用程序，对于任何应用程序都可以使用，也不会受限于应用程序的升级、文件夹结构等因素，非常灵活。
附图说明
11.为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本说明书的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
12.图1是本说明书一个实施例中操作系统缓存文件处理方法的流程示意图；
13.图2是背景技术中用户和计算机的交互示意图。
具体实施方式
14.下面结合附图，对本说明书提供的方案进行描述。
15.第一方面，本发明提供一种操作系统缓存文件处理方法，如图1所示，该方法包括如下步骤：
16.s110、操作系统的框架层获取应用程序的身份信息以及在安装过程中所述应用程序的安装压缩包解压后的文件目录；所述身份信息包括所述应用程序的名称和/或唯一标识；
17.其中，操作系统的框架包括应用层、框架层和内核三层。这里通过框架层对应用程序的相关信息进行记录。
18.可理解的是，应用程序的安装压缩包通常是操作系统能够识别出的采用固定格式的数据压缩包，以一定的后缀名结尾。应用程序在安装时，操作系统会对安装压缩包进行解压，生成文件夹结构。而操作系统的框架层就会获取或记录解压后生成的文件夹结构对应的文件目录。而且，框架层还会记录应用程序的身份信息，例如，应用程序的唯一标识信息、应用程序的名称等能够表征应用程序身份标识的信息。操作系统的框架层将获取到的身份信息和文件目录可以保存在智能终端本地。
19.可见，s110实际上是对应用程序的安装过程中所生成的文件夹结构以文件目录的形式进行标记。
20.s120、在所述应用程序首次启动运行时，所述应用程序调用所述框架层的文件操作接口，通过文件操作接口将运行过程所产生的缓存文件的文件信息传递给所述框架层；
21.其中，所述文件信息包括文件名称、路径和后缀名。
22.也就是说，在应用程序首次启动时，应用程序通过调用文件操作接口(或者系统接口)，进而通过所调用的接口将运行过程所产生的缓存文件对应的文件名称、路径和后缀名等文件信息传递给框架层，以便于文件系统依据这些信息生成新的文件和文件夹，用来存储缓存文件，同时生成数据记录表，用来存储文件信息与文件、文件夹的对应关系。
23.可理解的是，只在应用程序首次启动运行时生成新的文件和文件夹，以及创建一个数据记录表即可。其中，生成的新的文件和文件夹用来存储应用程序在运行过程中所产生的缓存文件，这里的缓存文件包括应用程序的运行日志、用户在应用程序上查看过的图片和视频、下载过的音视频和图片、用户的截图、用户访问过的实时性要求较高的内容。
24.s130、所述操作系统的文件系统根据所述框架层接收到的文件信息，在所述文件目录下的对应位置生成对应的文件和文件夹，将所述缓存文件存储至生成的所述文件夹中，并生成数据记录表，所述数据记录表中存储有所述文件信息与对应的文件或文件夹之间的映射关系；
25.也就是说，当框架层接收到文件信息之后，文件系统会根据这些文件信息生成文件和文件夹，生成的文件和文件夹位于上述文件目录下，具体位置要根据缓存文件的不同内容而定，通过生成的文件夹对缓存文件进行存储和分类。同时还要生成数据记录表，用来存储所有缓存文件的文件信息与文件、文件夹的对应关系。
26.可理解的是，数据记录表中可以存储一个应用程序中缓存文件的文件信息与文件、文件夹的映射关系，也可以存储多个应用程序中缓存文件的文件信息与文件、文件夹的映射关系，通过身份信息可以对不同应用程序对应的映射关系进行区分。
27.在应用程序非首次运行时，如果在文件目录下已经存在存储同类型缓存文件的文件和文件夹，只需要将运行过程产生的缓存文件存储至文件和文件夹中即可，不需要再生成新的文件和文件夹，为了对同类型不同时间段生成的缓存数据进行区分，可以对文件和文件夹的名称用日期加以区分。而如果在在非首次运行时，在文件目录下不存在相同类型缓存文件的文件和文件夹，则还需要生成对应的文件和文件夹，同时在数据记录表中添加新的对应关系。
28.s140、所述应用程序在对缓存文件进行预设处理时，调用所述框架层中对应的预设接口，并将预设处理对应的处理请求通过所述预设接口传递给所述框架层；所述框架层根据接收到的处理请求和所述数据记录表，确定所述待处理文件和/或待处理文件夹，对所述待处理文件和/或待处理文件夹进行预设处理，并对所述数据记录表进行更新。
29.可理解的是，应用程序对缓存文件的预设处理可以有多种，例如，重命名、删除等。不同的预设处理可以调用不同的预设接口，例如，在重命名时可以调用重命名接口或者应用程序编程接口(即api接口)，在删除时可以调用应用程序编程接口。通过调用预设接口的方式将预设处理对应的处理请求传递给框架层，其中处理请求中可以携带有应用程序的身份信息，当然处理请求中还需携带有文件信息。当框架层在接收到处理请求时，可以根据身份信息在数据记录表中查找到该应用程序对应的所有映射关系，进而在这些映射关系中查找文件信息对应的映射关系，根据映射关系可以找到待处理文件和/或待处理文件夹的存储路径，进而依据该存储路径在文件目录中找到待处理文件和/或待处理文件夹，进而对待处理文件和/或待处理文件夹进行预设处理。在进行预设处理之后，还需要对数据记录表进行更新，以保证映射关系的正确。
30.在具体实施时，预设处理可以包括重命名处理，这样预设接口可以包括：重命名接口或者应用程序编程接口。s140中框架层的处理过程可以包括：在通过所述重命名接口或者所述应用程序编程接口接收到所述处理请求时，根据所述处理请求中携带的文件信息，在所述数据记录表中查找到对应的待处理文件和/或待处理文件夹的路径，根据所述路径在所述文件目录下查找到对应的待处理文件和/或待处理文件夹，对所述待处理文件和/或待处理文件夹进行重命名，并对所述数据记录表中所述待处理文件和/或待处理文件夹的名称进行更新。
31.可见，在对缓存文件进行重命名时需要通过数据记录表在文件目录下找到待处理文件和/或待处理文件夹，从而可以对待处理文件和/或待处理文件夹进行重命名处理，同时还要对数据记录表进行更新。通过这种方式可以实现对缓存文件的重命名。
32.在具体实施时，所述预设处理可以包括删除处理，所述预设接口可以为应用程序编程接口。s140中框架层的处理过程可以包括：在通过所述应用程序编程接口接收到所述处理请求时，根据所述处理请求中携带的文件信息，在所述数据记录表中查找到对应的待处理文件和/或待处理文件夹的路径，根据所述路径在所述文件目录下找到对应的待处理文件和/或待处理文件夹，对所述待处理文件和/或待处理文件夹进行删除，并对所述数据记录表中所述待处理文件和/或待处理文件夹的文件信息进行删除。
33.可见，在对缓存文件进行删除时通过数据记录表在文件目录下找到待处理文件和/或待处理文件夹，从而对待处理文件和/或待处理文件夹进行删除，同时还要对数据记录表进行更新。
34.当然，除了删除和重命名之外，还可以包括其它类型的预设处理，这里不一一说明。
35.在具体实施时，本发明提供的方法还可以包括如下步骤：
36.s150、在所述应用程序接收到卸载请求时，所述应用程序调用所述框架层的应用程序编程接口；所述框架层在通过所述应用程序编程接口接收到完成卸载的消息时，读取所述数据记录表；根据在所述数据记录表中读取到的所述应用程序的所有文件信息，查找到对应的所有文件和文件夹；根据所述文件和所述文件夹的属性信息将所述文件和所述文件夹分类为第一类数据和第二类数据，将所述第一类数据删除，展示选择性删除界面，所述选择性删除界面上展示有第二类数据，响应于用户在所述选择性删除界面上的选择操作，对第二类数据进行选择性删除，并根据删除的数据对所述数据记录表进行更新。
37.也就是说，用户对一个应用程序进行卸载时，应用程序接收到卸载请求后，会调用框架层的api接口，同时对应用程序进行卸载，在卸载之后会向框架层反馈一个卸载完成的消息，当框架层通过api接口接收到这个消息之后，会在数据记录表中读取所卸载应用程序的所有文件信息，根据数据记录表中的映射关系，可以在文件目录下根据所述所有文件信息找到对应的所有的缓存文件。在找到这些缓存文件之后并不是直接删除，而是先进行分类，分为第一类数据和第二类数据，第一类数据是一些无用、不重要的缓存数据，框架层可以直接将其删除，而第二类数据可能是一些重要的缓存数据，框架层不能直接删除掉，需要用户进行选择性删除，即此时展示一个选择性删除界面，用以展示第二类数据，当用户在选择性删除界面上进行选择操作后，框架层可以根据用户的选择对第二类数据进行选择性删除，从而避免重要数据被误删的情况发生。在缓存数据删除之后，还需要对数据记录表进行
更新。
38.在具体实施时，可以根据缓存文件的属性信息进行分类，分为第一类数据和第二类数据，其中属性信息可以包括但不限于缓存文件是否为用户自主下载的数据，如果是用户自主下载的数据，例如，用户自己下载的音频、视频、文档等，则表明该缓存文件对于用户来说可能比较重要，如果不是用户自主下载的数据，则表明该缓存文件对于用户来说不太重要，对于可能比较重要的缓存文件让用户自己选择是否删除，从而避免框架层的误删除情况发生。
39.也就是说，所述属性信息包括是否为用户自主下载的数据，s150中根据所述文件和所述文件夹的属性信息将所述文件和所述文件夹分类为第一类数据和第二类数据，可以包括：判断所述文件和文件夹是否为用户自主下载的数据，若是，则所述文件或文件夹为所述第二类数据，否则所述文件或文件夹为所述第一类数据。
40.在具体实施时，本发明提供的方法还可以包括如下步骤：
41.s160、在所述操作系统启动时，所述框架层对所述数据记录表进行读取，并对所述文件目录下的文件和文件夹进行扫描，判断扫描后得到的信息与从所述数据记录表中读取到的信息是否一致，若不一致，则根据扫描后得到的信息对所述数据记录表进行修正。
42.即，在操作系统每一次启动时都会对数据记录表和缓存文件进行一致性对比，在不一致时根据缓存文件对数据记录表进行修正，从而保证数据记录表的真实正确。例如，在对缓存文件进行预设处理后，对数据记录表的更新出现错误而没有正确更新的话，缓存文件和数据记录表会出现不一致的情况发生，因此在操作系统启动时依据缓存文件对数据记录表进行纠正，从而解决这一问题。
43.举例来说，将本发明提供的方法应用在智汇家app中，智汇家app在使用过程中产生的缓存文件包括：app的运行日志、用户查看过的图片、下载过的界面、观看过的视频以及访问过的实时性要求较高的数据，伴随用户的使用时间的增长，缓存数据也会变得很庞大，会造成系统内存空间的扩张。通过本发明提供的方法，可以有效预防了缓存数据的无限扩张，可让用户选择或定时清除内存中的缓存文件，有效避免应用程序的卡顿。
44.本发明提供的方法，在安装压缩包解压后的文件目录下生成新的文件和文件夹，用来存储缓存数据，同时还生成数据记录表，用来记录文件信息与文件、文件夹之间的映射关系，在应用程序对缓存文件进行预设处理时，框架层会根据数据记录表在文件目录下找到对应的文件、文件夹，进而对其进行预设处理，同时还对数据记录表中的信息进行更新，从而保证数据记录表与文件、文件夹的一致性。可见，通过本发明提供的方法可以精准的找到对应的缓存文件，进而对其进行重命名、删除等处理。在缓存数据过多时，可以实现精准的找到缓存文件，及时清理，并且不会发生误删，从而解决缓存文件过多造成的内存不足、运行卡顿等不良后果。而且本发明提供的方法不限于主流应用程序，对于任何应用程序都可以使用，也不会受限于应用程序的升级、文件夹结构等因素，非常灵活。
45.在具体实施时，在应用程序对缓存文件进行预设处理(例如，重命名、删除等)的过程中，为了保证处理过程不会出现异常，本发明提供的方法还可以包括如下步骤s170～s180：
46.s170、所述应用程序在对缓存文件进行预设处理时，所述应用程序启动运行异常防护代码；所述异常防护代码用于在所述应用程序对所述缓存文件进行预设处理时对所述
应用程序的运行过程进行异常防护；
47.其中，所述异常防护代码预先采用面向切面编程的方式植入所述应用程序的app代码中。面向切面编程的方式即aop方式，这种方式不会对系统底层的源代码做修改，而常规的植入方式需要修改底层的源代码，因此采用aop方式对app代码的侵入极小，不会造成性能损耗。而且在将异常防护代码植入之前，可以将异常防护代码为采用sdk集成为一个插件，其中sdk的含义是软件开发工具包，通过软件开发工具包将异常防护代码集成为一个插件，这样可以将异常防护代码以插件的形式插入不同的应用程序中，实现对多种不同应用程序的异常防护。
48.s180、所述异常防护代码在启动后，所述异常防护代码对所述应用程序在消息转发阶段的运行过程是否发生异常进行监听，若监听到发生异常，则所述异常防护代码对所述运行过程对应的异常代码段进行代码重写以实现对所述应用程序的修复。
49.当应用程序在运行时，若消息发送阶段发生错误，没有实现消息的正确发送，就会进入到消息转发阶段。而异常防护代码正是在消息转发阶段发挥其异常防护作用。
50.在具体实施时，针对ios应用程序可以采用键值观察者事件通知机制对所述应用程序在消息转发阶段的运行过程是否发生异常进行监听。键值观察者事件通知机制，即kvo(全称为key
‑
value
‑
observer)事件通知机制。键值观察者事件通知机制是ios系统提供的一套事件通知机制，允许对象监听另一个对象特定属性的改变，并在改变时接收到事件。例如，观察者a监听被观察者b的某个属性，当b的属性发生更改时，a就会收到通知，执行相应的方法。
51.其中，对异常代码段进行重写，实际上是用对应的一段新的代码去替代原来的异常代码的过程，重写过程是由异常防护代码执行的，通过重写的方式实现对异常代码的修复。
52.在实际中，消息转发阶段可以包括三个子阶段：方法解析子阶段(即resolveinstancemethod对应的子阶段)、快速转发子阶段(即forwardingtargetforselector对应的子阶段)、慢速转发子阶段(即methodsignatureforselector对应的子阶段)。在具体实施时可以针对这三个子阶段实现异常防护。也就是说，s180可以具体包括：
53.s181、所述异常防护代码在所述消息转发阶段的方法解析子阶段中，判断在预设方法列表中是否能够查找到第一对象方法或者第一类方法，所述第一对象方法为所述应用程序的运行过程所对应的对象方法，所述第一类方法为所述应用程序的运行过程所对应的类方法；
54.若是，则进入快速转发子阶段进行异常监听；
55.否则，所述方法解析子阶段出现异常，所述异常防护代码将当前运行过程对应的app代码段作为所述异常代码段，并对所述异常代码段进行重写处理。
56.可理解的是，第一对象方法或第一类方法是应用程序当前的运行过程所执行的功能所对应的对象方法或类方法，例如，应用程序当前执行的是登录功能，则第一对象方法或第一类方法是能够实现登录功能的对象方法或类方法。
57.可理解的是，如果在方法解析子阶段调用了第一类方法或第一对象方法，说明方法解析子阶段的执行过程是成功的，可以进入下一个子阶段，从而进入下一个子阶段进行
异常监听。而如果在方法解析子阶段没有调用第一对象方法或第一类方法，说明方法解析子阶段是失败的，有可能因为这一子阶段的执行失败而发生异常，所以此时认为方法解析子阶段出现了异常，从而对当前对应的异常代码段进行重写操作。
58.在具体实施时，当需要进入所述方法解析子阶段的下一个子阶段进行异常监听时，所述s180具体还可以包括：
59.s182、所述异常防护代码在所述快速转发子阶段中，判断在预设对象列表中是否能够查找到响应所述第一对象方法或所述第一类方法的子对象；
60.若是，则进入慢速转发子阶段进行异常监听；
61.否则，所述快速转发子阶段出现异常，所述异常防护代码将当前运行过程对应的app代码段作为所述异常代码段，并对所述异常代码段进行重写处理。
62.可理解的是，在预设对象列表中包括多个子对象，不同的子对象能够响应不同的对象方法或者类方法。
63.可理解的是，为了实现应用程序当前运行过程所对应的功能，需要调用第一类方法或第一对象方法，由于在方法解析子阶段没有调用第一类方法或第一对象方法，因此需要找到能够响应第一类方法或第一对象方法的子对象，才能实现应用程序当前运行过程所对应的功能。
64.可理解的是，如果能够找到响应第一类方法或第一对象方法的子对象，这样快速转发子阶段便可以通过该子对象实现该子阶段的功能，进而进入下一个子阶段进行异常监听。而如果在快速转发子阶段没有找到该子对象，则说明快速转发子阶段是失败的，有可能因为这一子阶段的执行失败而发生异常，所以此时认为快速转发子阶段出现了异常，从而对当前对应的异常代码段进行重写操作。
65.在具体实施时，当需要进入所述快速转发子阶段的下一个子阶段进行异常监听时，所述s180具体还可以包括：
66.s183、所述异常防护代码在所述慢速转发子阶段中，将所述预设对象列表切换为对应的关联对象列表，并判断在所述关联对象列表中是否能够查找到响应所述第一对象方法或所述第一类方法的关联子对象；
67.若是，则所述消息转发阶段的运行过程未出现异常；
68.否则，所述慢速转发子阶段出现异常，所述异常防护代码将当前运行过程对应的app代码段作为所述异常代码段，并对所述异常代码段进行重写处理。
69.可理解的是，在关联对象列表中包括多个关联子对象，这些关联子对象能够响应不同的对象方法或类方法。预设对象列表和关联对象列表是关联的。
70.可理解的是，由于在快速转发子阶段中，在预设对象列表中没有找到能够响应上述第一类方法或第一对象方法的子对象，因此在关联对象列表查找能够响应所述第一对象方法或所述第一类方法的关联子对象，在查找之前需要将预设对象列表切换为对应的关联对象列表，只有找到能够响应所述第一对象方法或所述第一类方法的关联子对象，才能实现应用程序当前运行过程所对应的功能。
71.可理解的是，如果能够找到响应第一类方法或第一对象方法的关联子对象，这样慢速转发子阶段便可以通过该关联子对象实现该子阶段的功能，至此所述消息转发阶段的整个运行过程均未出现异常。而如果在慢速转发子阶段没有找到该关联子对象，则说明慢
速转发子阶段是失败的，有可能因为这一子阶段的执行失败而发生异常，所以此时认为慢速转发子阶段出现了异常，从而对当前对应的异常代码段进行重写操作。
72.通过上述三个步骤实现对消息转发阶段的三个子阶段进行异常监听并在出现异常时进行重写进行代码修复。通过异常防护代码的异常防护功能可以保证在对文件或文件夹进行预设处理的过程可以正常进行，减少运行错误的发生。
73.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
74.本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、挂件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。
75.以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。