数据读取方法、装置、存储介质和程序产品与流程

1.本技术涉及计算机技术领域，特别涉及一种数据读取方法、装置、存储介质和程序产品。


背景技术：

2.在应用启动、玩游戏等场景下，往往会生成多个输入输出(input output，io)请求，该多个io请求用于请求顺序读取文件系统中的数据。为了提高数据读取效率，设置了数据预读机制。具体地，每次接收到io请求时，除了访问该io请求所请求的数据外，还会在文件系统中按顺序继续读取后续数据到内存中，也就是预读后续数据到内存中。这样，在接收到下一个io请求时，就可以直接在预读到内存的数据中访问这个io请求所请求的数据，而无需从文件系统中读取，从而可以加快数据访问。
3.目前，终端中经常采用可扩展只读文件系统(extendable read
‑
only file system，erofs)。erofs中的数据是压缩存放，如此可以减少数据占用空间，且可以提升随机读取性能。对erofs中的数据的预读还伴随着对数据的解压操作。这种情况下，随着预读的数据的增多，需要解压的数据越来越多，从而会占用越来越多的中央处理器(central processing unit，cpu)资源，进而会影响其他应用的正常运行。


技术实现要素：

4.本技术提供了一种数据读取方法、装置、存储介质和程序产品，可以根据系统负载状态来调整本次预读时需解压的数据量，从而保证系统性能均衡稳定。所述技术方案如下：
5.第一方面，提供了一种数据读取方法。在该方法中，接收io请求，该io请求用于请求读取文件系统中的数据。之后，根据cpu负载信息和io负载信息确定系统负载状态，且根据系统负载状态设置预读解压率，预读解压率是从文件系统预读数据至内存时对预读出的数据的解压率。最后，根据预读解压率从文件系统预读数据至内存，并在内存中访问该io请求所请求的数据。
6.该io请求可以是在目标业务运行过程中生成的。目标业务是在运行过程中需要顺序读取文件系统中的数据的业务，因而在目标业务运行过程中会生成一些io请求，这些io请求用于请求顺序读取文件系统中的数据。
7.文件系统中的数据是压缩存储，也即文件系统中存储的数据为压缩数据。比如，文件系统可以为erofs，erofs中存储的数据即为压缩数据。这种情况下，对文件系统中的压缩数据的预读还可以伴随着对压缩数据的解压操作。
8.cpu负载信息用于体现cpu负载情况。示例地，cpu负载信息可以包括系统丢帧率。系统丢帧率可以体现cpu负载的高低。也即，系统丢帧率越高，说明cpu负载越高；系统丢帧率越低，说明cpu负载越低。
9.io负载信息用于体现io负载情况。示例地，io负载信息可以包括io时间比率，io时间比率是指周期内用于io操作的时间比率，即指示一秒中有百分之多少的时间用于io操
作。io时间比率可以体现io负载的高低。也即，io时间比率越高，说明io负载越高；io时间比率越低，说明io负载越低。
10.系统负载状态用于体现系统整体的负载情况。系统负载状态可以为繁忙状态、正常状态或空闲状态。系统负载状态为繁忙状态时，说明系统负载较高；系统负载状态为正常状态时，说明系统负载适中；系统负载状态为空闲状态时，说明系统负载较低。
11.在本技术中，根据系统负载状态来调整本次预读时需解压的数据量，因而可达到在系统重负载时解压较少的数据，在系统轻负载时解压较多的数据的效果，从而在保证预读效果的同时，也保证了系统性能均衡稳定，进而保证了应用的正常运行。
12.可选地，根据cpu负载信息和io负载信息确定系统负载状态的操作可以为：若系统丢帧率大于或等于第一丢帧率阈值，或者io时间比率大于或等于第一时间比率阈值，则确定系统负载状态为繁忙状态；若系统丢帧率大于第二丢帧率阈值且小于第一丢帧率阈值，以及io时间比率大于第二时间比率阈值且小于第一时间比率阈值，则确定系统负载状态为正常状态；若系统丢帧率小于或等于第二丢帧率阈值，或者io时间比率小于或等于第二时间比率阈值，则确定系统负载状态为空闲状态。
13.第一丢帧率阈值和第二丢帧率阈值均可以预先进行设置，第一丢帧率阈值和第二丢帧率阈值是用来判断系统丢帧率的高低的阈值，第一丢帧率阈值大于第二丢帧率阈值。当系统丢帧率大于或等于第一丢帧率阈值时，说明系统丢帧率较高，即cpu负载较高。当系统丢帧率小于或等于第二丢帧率阈值时，说明系统丢帧率较低，即cpu负载较低。
14.第一时间比率阈值和第二时间比率阈值均可以预先进行设置，第一时间比率阈值和第二时间比率阈值是用来判断io时间比率的高低的阈值，第一时间比率阈值大于第二时间比率阈值。当io时间比率大于或等于第一时间比率阈值时，说明io时间比率较高，即io负载较高。当io时间比率小于或等于第二时间比率阈值时，说明io时间比率较低，即io负载较低。
15.在本技术中，通过对系统丢帧率和io时间比率设置相应的阈值，可以判断出系统负载的高低，继而就可以确定系统负载状态，从而便于后续根据系统负载状态设置在本次预读时使用的预读解压率，以使预读时需解压的数据量与系统负载状态匹配，从而保证在系统负载较高时预读不会过多占用cpu资源。
16.可选地，根据系统负载状态设置预读解压率的操作可以为：若系统负载状态为繁忙状态，则设置预读解压率为0；若系统负载状态为正常状态，则根据系统丢帧率和io时间比率设置预读解压率；若系统负载状态为空闲状态，则设置预读解压率为1。
17.在本技术中，若系统负载状态为繁忙状态，说明系统负载较高，因而可以设置预读解压率为0，也即在本次预读时对预读出的所有数据都不解压，如此在系统重负载时，可以在预读时避免对cpu资源的额外占用，以保证应用的正常运行。
18.若系统负载状态为空闲状态，说明系统负载较低，因而可以设置预读解压率为1，也即在本次预读时对预读出的所有数据都解压，如此在系统轻负载时，即在cpu资源比较充足的情况下，可以正常对预读出的所有数据进行解压，在保证较好的预读效果的情况下，也不影响应用的正常运行。
19.若系统负载状态为正常状态，说明系统负载适中，因而可以根据系统丢帧率和io时间比率设置预读解压率，此时预读解压率大于0且小于1，也即在本次预读时对预读出的
所有数据中的一部分数据进行解压，如此在系统负载适中时，在预读时不会过多占用cpu资源，从而可以保证应用的正常运行。
20.可选地，在系统负载状态为正常状态时，根据系统丢帧率和io时间比率设置预读解压率时，可以遵循系统丢帧率和io时间比率整体与预读解压率呈负相关关系的原则来设置。也即，遵循系统丢帧率和io时间比率越大，预读解压率越小，系统丢帧率和io时间比率越小，预读解压率越大的原则来设置。这种情况下，系统丢帧率和io时间比率越大，说明系统负载越高，则需使得预读解压率越小，以减小需解压的数据量，避免过多占用cpu资源。而系统丢帧率和io时间比率越小，说明系统负载越低，则需使得预读解压率越大，以在不会过多占用cpu资源的情况下，增加需解压的数据量，提高预读效果。
21.作为一种示例，根据系统丢帧率和io时间比率设置预读解压率的操作可以为：根据系统丢帧率和io时间比率，通过如下公式得到预读解压率；
[0022][0023]
其中，d为预读解压率，f为系统丢帧率，f1为第一丢帧率阈值，f2为第二丢帧率阈值，第一丢帧率阈值大于第二丢帧率阈值，i为io时间比率，i1为第一时间比率阈值，i2为第二时间比率阈值，第一时间比率阈值大于第二时间比率阈值，a为系统丢帧率的权重。
[0024]
可选地，根据预读解压率从文件系统预读数据至内存的操作可以为：若预读解压率为0，则从文件系统预读数据至内存，且不对本次预读出的所有数据进行解压；若预读解压率大于0且小于1，则从文件系统预读数据至内存，且对本次预读出的所有数据中所占比例为预读解压率的一部分数据进行解压；若预读解压率为1，则从文件系统预读数据至内存，且对本次预读出的所有数据进行解压。
[0025]
为了便于后续在io请求到来时，能够对内存中存储的未解压的数据进行解压，根据预读解压率从文件系统预读数据至内存之后，还可以对本次预读出的所有数据中未解压的数据进行解压标记，该解压标记用于标记压缩数据，即该解压标记用于指示在内存中访问到所标记的数据时需要解压。
[0026]
在本技术中，在io请求到来时，若内存中存储的该io请求所请求的数据带有解压标记，说明该数据是压缩数据，则先对该数据进行解压，得到解压数据，再访问该解压数据；若内存中存储的该io请求所请求的数据未带有解压标记，说明该数据是解压数据，则直接访问该数据。如此，通过解压标记，可以保证准确访问到所需的数据。
[0027]
可选地，由于同步预读出的数据在后续有很大可能会被访问到，所以在同步预读时可以直接对预读出的所有数据正常进行解压，而在异步预读时可以执行本技术提供的数据读取方法。也即，在接收到io请求后，若本次进行的是异步预读，则执行根据cpu负载信息和io负载信息确定系统负载状态的步骤及后续步骤。在接收io请求后，若本次进行的是同步预读，则从文件系统预读数据至内存，且对本次预读出的所有的数据进行解压，此时内存中存储的数据是解压数据，因而可以直接在内存中访问io请求所请求的数据。
[0028]
第二方面，提供了一种数据读取装置，所述数据读取装置具有实现上述第一方面中数据读取方法行为的功能。所述数据读取装置包括至少一个模块，所述至少一个模块用于实现上述第一方面所提供的数据读取方法。
[0029]
第三方面，提供了一种数据读取装置，所述数据读取装置的结构中包括处理器和
存储器，所述存储器用于存储支持数据读取装置执行上述第一方面所提供的数据读取方法的程序，以及存储用于实现上述第一方面所述的数据读取方法所涉及的数据。所述处理器被配置为用于执行所述存储器中存储的程序。所述数据读取装置还可以包括通信总线，所述通信总线用于在所述处理器与所述存储器之间建立连接。
[0030]
第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面所述的数据读取方法。
[0031]
第五方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面所述的数据读取方法。
[0032]
上述第二方面、第三方面、第四方面和第五方面所获得的技术效果与上述第一方面中对应的技术手段获得的技术效果近似，在这里不再赘述。
附图说明
[0033]
图1是本技术实施例提供的一种终端的结构示意图；
[0034]
图2是本技术实施例提供的一种终端的软件系统的框图；
[0035]
图3是本技术实施例提供的一种数据读取过程的示意图；
[0036]
图4是本技术实施例提供的一种数据读取方法的流程图；
[0037]
图5是本技术实施例提供的一种系统负载状态的示意图；
[0038]
图6是本技术实施例提供的另一种数据读取方法的流程图；
[0039]
图7是本技术实施例提供的一种启动音乐应用的界面示意图；
[0040]
图8是本技术实施例提供的另一种数据读取过程的示意图；
[0041]
图9是本技术实施例提供的一种数据读取装置的结构示意图。
具体实施方式
[0042]
为使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术的实施方式作进一步地详细描述。
[0043]
应当理解的是，本技术提及的“多个”是指两个或两个以上。在本技术的描述中，除非另有说明，“/”表示或的意思，比如，a/b可以表示a或b；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，比如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，为了便于清楚描述本技术的技术方案，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
[0044]
在对本技术实施例提供的数据读取方法进行详细地解释说明之前，先对本技术实施例涉及的终端予以说明。
[0045]
图1是本技术实施例提供的一种终端的结构示意图。参见图1，终端100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，usb)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170a，受话器170b，麦克风170c，耳机接口170d，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识
模块(subscriber identification module，sim)卡接口195等。其中，传感器模块180可以包括压力传感器180a，陀螺仪传感器180b，气压传感器180c，磁传感器180d，加速度传感器180e，距离传感器180f，接近光传感器180g，指纹传感器180h，温度传感器180j，触摸传感器180k，环境光传感器180l，骨传导传感器180m等。
[0046]
可以理解的是，本技术实施例示意的结构并不构成对终端100的具体限定。在本技术另一些实施例中，终端100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
[0047]
处理器110可以包括一个或多个处理单元，比如：处理器110可以包括应用处理器(application processor，ap)，调制解调处理器，图形处理器(graphics processing unit，gpu)，图像信号处理器(image signal processor，isp)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，dsp)，基带处理器，和/或神经网络处理器(neural
‑
network processing unit，npu)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
[0048]
其中，控制器可以是终端100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
[0049]
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从该存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
[0050]
在一些实施例中，处理器110可以包括一个或多个接口，如可以包括集成电路(inter
‑
integrated circuit，i2c)接口，集成电路内置音频(inter
‑
integrated circuit sound，i2s)接口，脉冲编码调制(pulse code modulation，pcm)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，uart)接口，移动产业处理器接口(mobile industry processor interface，mipi)，通用输入输出(general
‑
purpose input/output，gpio)接口，用户标识模块(subscriber identity module，sim)接口，和/或通用串行总线(universal serial bus，usb)接口等。
[0051]
i2c接口是一种双向同步串行总线，包括一根串行数据线(serial data line，sda)和一根串行时钟线(derail clock line，scl)。在一些实施例中，处理器110可以包含多组i2c接口。处理器110可以通过不同的i2c接口分别耦合触摸传感器180k，充电器，闪光灯，摄像头193等。比如：处理器110可以通过i2c接口耦合触摸传感器180k，使处理器110与触摸传感器180k通过i2c接口通信，实现终端100的触摸功能。
[0052]
i2s接口可以用于音频通信。在一些实施例中，处理器110可以包含多组i2s接口。处理器110可以通过i2s接口与音频模块170耦合，实现处理器110与音频模块170之间的通信。在一些实施例中，音频模块170可以通过i2s接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。
[0053]
pcm接口也可以用于音频通信，将模拟信号抽样，量化和编码。在一些实施例中，音频模块170与无线通信模块160可以通过pcm接口耦合。在一些实施例中，音频模块170也可以通过pcm接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。
emitting diodes，qled)等。在一些实施例中，终端100可以包括1个或n个显示屏194，n为大于1的整数。
[0069]
终端100可以通过isp，摄像头193，视频编解码器，gpu，显示屏194以及应用处理器等实现拍摄功能。
[0070]
isp用于处理摄像头193反馈的数据。比如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将电信号传递给isp处理，转化为肉眼可见的图像。isp还可以对图像的噪点，亮度，肤色进行算法优化。isp还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，isp可以设置在摄像头193中。
[0071]
摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，ccd)或互补金属氧化物半导体(complementary metal
‑
oxide
‑
semiconductor，cmos)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给isp转换成数字图像信号。isp将数字图像信号输出到dsp加工处理。dsp将数字图像信号转换成标准的rgb，yuv等格式的图像信号。在一些实施例中，终端100可以包括1个或n个摄像头193，n为大于1的整数。
[0072]
外部存储器接口120可以用于连接外部存储卡，比如micro sd卡，实现扩展终端100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。比如将音乐，视频等文件保存在外部存储卡中。
[0073]
内部存储器121可以用于存储计算机可执行程序代码，计算机可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，来执行终端100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储终端100在使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，比如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，ufs)等。
[0074]
终端100可以通过音频模块170，扬声器170a，受话器170b，麦克风170c，耳机接口170d以及应用处理器等实现音频功能，比如音乐播放，录音等。
[0075]
音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。
[0076]
按键190包括开机键，音量键等。按键190可以是机械按键，也可以是触摸式按键。终端100可以接收按键输入，产生与终端100的用户设置以及功能控制有关的键信号输入。
[0077]
马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。比如，作用于不同应用(比如拍照，音频播放等)的触摸操作，可以对应不同的振动反馈效果。作用于显示屏194不同区域的触摸操作，也可对应不同的振动反馈效果。不同的应用场景(比如：时间提醒，接收信息，闹钟，游戏等)，也可以对应不同的振动反馈效果。触摸振动反馈效果还可以支持自定义。
[0078]
指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。
[0079]
sim卡接口195用于连接sim卡。sim卡可以通过插入sim卡接口195，或从sim卡接口195拔出，实现和终端100的接触和分离。终端100可以支持1个或n个sim卡接口，n为大于1的整数。sim卡接口195可以支持nano sim卡，micro sim卡，sim卡等。同一个sim卡接口195可以同时插入多张卡。多张卡的类型可以相同，也可以不同。sim卡接口195也可以兼容不同类型的sim卡。sim卡接口195也可以兼容外部存储卡。终端100通过sim卡和网络交互，实现通话以及数据通信等功能。在一些实施例中，终端100采用esim，即：嵌入式sim卡。esim卡可以嵌在终端100中，不能和终端100分离。
[0080]
接下来对终端100的软件系统予以说明。
[0081]
终端100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本技术实施例以分层架构的安卓(android)系统为例，对终端100的软件系统进行示例性说明。
[0082]
图2是本技术实施例提供的一种终端100的软件系统的框图。参见图2，分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(android runtime)和系统层，以及内核层。
[0083]
应用程序层可以包括一系列应用程序包。如图2所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，wlan，蓝牙，音乐，游戏，短信息等应用程序。
[0084]
应用程序框架层为应用程序层的应用程序提供应用编程接口(application programming interface，api)和编程框架。应用程序框架层包括一些预先定义的函数。如图2所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问，这些数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。视图系统包括可视控件，比如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序的显示界面，显示界面可以由一个或多个视图组成，比如，包括显示短信通知图标的视图，包括显示文字的视图，以及包括显示图片的视图。电话管理器用于提供终端100的通信功能，比如通话状态的管理(包括接通，挂断等)。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如，通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或滚动条文本形式出现在系统顶部状态栏的通知，比如后台运行的应用程序的通知。通知管理器还可以是以对话窗口形式出现在屏幕上的通知，比如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。
[0085]
android runtime包括核心库和虚拟机。android runtime负责安卓系统的调度和管理。核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
[0086]
系统库可以包括多个功能模块，比如：表面管理器(surface manager)，媒体库
(media libraries)，三维图形处理库(比如：opengl es)，2d图形引擎(比如：sgl)等。表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2d和3d图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，比如：mpeg4，h.264，mp3，aac，amr，jpg，png等。三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2d图形引擎是2d绘图的绘图引擎。
[0087]
内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。
[0088]
下面结合游戏应用启动场景，示例性说明终端100软件以及硬件的工作流程。
[0089]
当触摸传感器180k接收到触摸操作，相应的硬件中断被发给内核层。内核层将触摸操作加工成原始输入事件(包括触摸坐标，触摸操作的时间戳等信息)。原始输入事件被存储在内核层。应用程序框架层从内核层获取原始输入事件，识别原始输入事件所对应的控件。以该触摸操作是单击操作，该单击操作所对应的控件为游戏应用图标的控件为例，游戏应用调用应用程序框架层的接口，启动游戏应用，再调用内核层启动显示驱动，通过显示屏194显示游戏应用的应用界面。
[0090]
接下来对本技术实施例提供的数据读取方法的应用场景予以说明。
[0091]
在应用启动、玩游戏等场景下，数据读取量较大。而且，终端一般都是多任务运行，经常存在并发的io请求，进一步加大了数据读取量。为了提高数据读取效率，诸如android、linux等操作系统中设置了数据预读机制。预读是指在接收到io请求时，一次从文件系统中读出比所请求的数据更多的数据并缓存在内存中，这样在下一个io请求到来时可以直接在内存中访问所请求的数据，从而可以加快数据访问。
[0092]
目前，终端中经常采用erofs。erofs中的数据是压缩存放，如此可以减少数据占用空间，且可以提升随机读取性能。对erofs中的数据的预读还伴随着对数据的解压操作，也即，从erofs中预读数据至内存的同时，还会对预读出的数据进行解压。这种情况下，随着预读的数据的增多，需要解压的数据越来越多，从而会占用越来越多的cpu资源。在cpu性能较低的终端上，cpu资源比较紧张，若预读占用过多的cpu资源，将会导致应用运行缓慢，出现卡顿现象。
[0093]
为此，本技术实施例提供了一种数据读取方法，可以根据系统负载状态来设置预读解压率，然后根据预读解压率从文件系统中预读数据至内存。如此，不需在每次预读时对预读出的所有数据进行解压，而是根据系统负载状态来调整需解压的数据量，在系统重负载时解压较少的数据，在系统轻负载时解压较多的数据，从而在保证预读效果的同时，也保证了系统性能均衡稳定，进而保证了应用的正常运行。
[0094]
接下来对数据预读机制予以说明。
[0095]
图3是本技术实施例提供的一种数据读取过程的示意图。参见图3，假设在启动应用的过程中，生成三个io请求来顺序读取文件系统中的数据。具体读取过程如下：
[0096]
操作系统接收在启动应用的过程中生成的第一个io请求，第一个io请求用于请求读取文件系统中的数据1。操作系统先在内存中查找数据1。因为是首次读取，所以在内存中查找不到数据1，此时触发一次同步预读。操作系统在进行同步预读时，先初始化一个预读窗口，预读窗口大小决定本次的预读数据量。假设初始化的预读窗口大小为4，则从文件系统中读取4个数据(即数据1～数据4)到内存中。可以看出，第一个io请求所请求的是数据1，
而操作系统从文件系统中一共读出数据1～数据4，其中的后3个数据(即数据2～数据4)均属于预读数据，此时操作系统在内存中访问第一个io请求所请求的数据1。并且，这种情况下，操作系统为本次预读出的这3个预读数据中的第一个预读数据(即数据2)打上预读标记。当后续访问到内存中被打上预读标记的这个预读数据时，操作系统会进行一次异步预读，具体在下面说明。
[0097]
操作系统接收在启动应用的过程中生成的第二个io请求，第二个io请求用于请求读取文件系统中的数据2和数据3。操作系统先在内存中查找数据2和数据3。因为之前已经从文件系统中将数据2和数据3预读到了内存中，所以可以在内存中查找到数据2和数据3，此时直接在内存中访问第二个io请求所请求的数据2和数据3。这种情况下，由于数据2被打上了预读标记，所以在访问到数据2时，会触发一次异步预读。操作系统在进行本次异步预读时，将上次同步预读时使用的预读窗口大小增大后作为本次异步预读时所要使用的预读窗口大小，示例地，可以将2倍的上次同步预读时使用的预读窗口大小作为本次异步预读时所要使用的预读窗口大小，即本次异步预读时所要使用的预读窗口大小为8，则在上次同步预读的基础上，即从文件系统中位于上次预读出的最后一个数据(即数据4)的后一个数据(即数据5)开始，从文件系统中读取8个数据(即数据5～数据12)到内存中。可以看出，第二个io请求所请求的是数据2和数据3，而操作系统从文件系统中一共读出数据5～数据12，数据5～数据12均属于预读数据。这种情况下，操作系统为本次预读出的这8个预读数据中的第一个预读数据(即数据5)打上预读标记。当后续访问到内存中被打上预读标记的这个预读数据时，操作系统会进行一次异步预读，具体在下面说明。
[0098]
操作系统接收在启动应用的过程中生成的第三个io请求，第三个io请求用于请求读取文件系统中的数据4～数据9。操作系统先在内存中查找数据4～数据9。因为之前已经从文件系统中将数据4～数据9预读到了内存中，所以可以在内存中查找到数据4～数据9，此时直接在内存中访问第三个io请求所请求的数据4～数据9。这种情况下，由于数据5被打上了预读标记，所以在访问到数据5时，会触发一次异步预读。操作系统在进行本次异步预读时，将上次异步预读时使用的预读窗口大小增大后作为本次异步预读时所要使用的预读窗口大小，示例地，可以将2倍的上次异步预读时使用的预读窗口大小作为本次异步预读时所要使用的预读窗口大小，即本次异步预读时所要使用的预读窗口大小为16，则在上次异步预读的基础上，即从文件系统中位于上次预读出的最后一个数据(即数据12)的后一个数据(即数据13)开始，从文件系统中读取16个数据(即数据13～数据28)到内存中。可以看出，第三个io请求所请求的是数据4～数据9，而操作系统从文件系统中一共读出数据13～数据28，数据13～数据28均属于预读数据。这种情况下，操作系统为本次预读出的这16个预读数据中的第一个预读数据(即数据13)打上预读标记。当后续访问到内存中被打上预读标记的这个预读数据时，操作系统会进行一次异步预读。
[0099]
值得注意的是，上述从文件系统预读数据至内存时，可以是将文件系统中的数据预读至内存中的page cache(页缓存)中，后续接收到io请求时，可以在page cache中访问该io请求所请求的数据。
[0100]
由上述数据读取过程可知，操作系统每接收到一个io请求，在访问这个io请求所请求的数据的同时，还可以从文件系统中预读后续数据至内存中。并且，每次预读时使用的预读窗口大小会大于前一次预读时使用的预读窗口大小，如每次预读时使用的预读窗口大
小可以以2倍的方式不断增大。这种情况下，随着不断接收到io请求，每次预读时使用的预读窗口大小会越来越大，每次从文件系统预读至内存中的数据也就会越来越多。
[0101]
对于诸如erofs等文件系统，其中的数据是压缩存储。因而在从文件系统预读数据至内存的同时，还需要对预读出的数据进行解压，以将解压数据存储在内存中，如此后续可以直接在内存中访问解压数据。然而，随着每次从文件系统预读至内存中的数据的增多，每次预读时需解压的数据越来越多，这将会占用越来越多的cpu资源。在cpu资源比较紧张的情况下，若预读占用过多的cpu资源，将会导致应用运行缓慢，出现卡顿现象，影响用户体验。
[0102]
为此，本技术实施例中提供的数据读取方法，不需要在每次预读时对预读出的所有数据进行解压，而是根据系统负载状态来调整需解压的数据量，在系统重负载时解压较少的数据，在系统轻负载时解压较多的数据，从而在保证预读效果的同时，也保证了系统性能均衡稳定，进而保证了应用的正常运行。
[0103]
接下来对本技术实施例提供的数据读取方法予以说明。
[0104]
图4是本技术实施例提供的一种数据读取方法的流程图，该方法应用于终端，具体可以应用于终端的操作系统。参见图4，该方法包括：
[0105]
步骤401：终端接收io请求，该io请求用于请求读取文件系统中的数据。
[0106]
该io请求可以是在目标业务运行过程中生成的。目标业务是在运行过程中需要顺序读取文件系统中的数据的业务，因而在目标业务运行过程中会生成一些io请求，这些io请求用于请求顺序读取文件系统中的数据。例如，目标业务可以是启动应用、在应用内执行某些操作(如显示游戏界面)等，本技术实施例对此不作限定。
[0107]
文件系统中的数据是压缩存储，也即文件系统中存储的数据为压缩数据。比如，文件系统可以为erofs，erofs中存储的数据即为压缩数据。这种情况下，对文件系统中的压缩数据的预读还可以伴随着对压缩数据的解压操作。由于解压操作会占用cpu资源，所以为了保证系统性能均衡稳定，在本技术实施例中，在预读的同时需要解压多少数据量可以根据系统负载状态来确定，具体在下面说明。
[0108]
步骤402：终端根据cpu负载信息和io负载信息确定系统负载状态。
[0109]
cpu负载信息用于体现cpu负载情况。示例地，cpu负载信息可以包括系统丢帧率。系统丢帧率可以体现cpu负载的高低。也即，系统丢帧率越高，说明cpu负载越高；系统丢帧率越低，说明cpu负载越低。
[0110]
在一些实施例中，终端可以通过surfaceflinger服务中用于获取帧信息的相关接口来获取系统丢帧率，当然，终端也可以通过其他方式来获取系统丢帧率，本技术实施例对此不作限定。
[0111]
io负载信息用于体现io负载情况。示例地，io负载信息可以包括io时间比率，io时间比率是指周期内用于io操作的时间比率，即指示一秒中有百分之多少的时间用于io操作。io时间比率可以体现io负载的高低。也即，io时间比率越高，说明io负载越高；io时间比率越低，说明io负载越低。
[0112]
在一些实施例中，终端可以通过io吞吐量统计服务来获取io时间比率，当然，终端也可以通过其他方式来获取io时间比率，本技术实施例对此不作限定。
[0113]
系统负载状态用于体现系统整体的负载情况。系统负载状态可以为繁忙状态、正
常状态或空闲状态。系统负载状态为繁忙状态时，说明系统负载较高；系统负载状态为正常状态时，说明系统负载适中；系统负载状态为空闲状态时，说明系统负载较低。
[0114]
可选地，步骤402的操作可以为：若系统丢帧率大于或等于第一丢帧率阈值，或者io时间比率大于或等于第一时间比率阈值，则终端确定系统负载状态为繁忙状态；若系统丢帧率大于第二丢帧率阈值且小于第一丢帧率阈值，以及io时间比率大于第二时间比率阈值且小于第一时间比率阈值，则终端确定系统负载状态为正常状态；若系统丢帧率小于或等于第二丢帧率阈值，或者io时间比率小于或等于第二时间比率阈值，则终端确定系统负载状态为空闲状态。
[0115]
第一丢帧率阈值和第二丢帧率阈值均可以预先进行设置，第一丢帧率阈值和第二丢帧率阈值是用来判断系统丢帧率的高低的阈值，第一丢帧率阈值大于第二丢帧率阈值。比如，第一丢帧率阈值可以为1％、2％等，第二丢帧率阈值可以为0％、0.1％等。当系统丢帧率大于或等于第一丢帧率阈值时，说明系统丢帧率较高，即cpu负载较高。当系统丢帧率小于或等于第二丢帧率阈值时，说明系统丢帧率较低，即cpu负载较低。
[0116]
第一时间比率阈值和第二时间比率阈值均可以预先进行设置，第一时间比率阈值和第二时间比率阈值是用来判断io时间比率的高低的阈值，第一时间比率阈值大于第二时间比率阈值。比如，第一时间比率阈值可以为90％、85％等，第二时间比率阈值可以为40％、35％等。当io时间比率大于或等于第一时间比率阈值时，说明io时间比率较高，即io负载较高。当io时间比率小于或等于第二时间比率阈值时，说明io时间比率较低，即io负载较低。
[0117]
这种情况下，若系统丢帧率大于或等于第一丢帧率阈值，或者io时间比率大于或等于第一时间比率阈值，说明cpu负载较高或者io负载较高，即说明系统负载较高，因而终端可以确定系统负载状态为繁忙状态。
[0118]
若系统丢帧率大于第二丢帧率阈值且小于第一丢帧率阈值，以及io时间比率大于第二时间比率阈值且小于第一时间比率阈值，说明cpu负载适中且io负载适中，即说明系统负载适中，因而终端可以确定系统负载状态为正常状态。
[0119]
若系统丢帧率小于或等于第二丢帧率阈值，或者io时间比率小于或等于第二时间比率阈值，说明cpu负载较低或者io负载较低，即说明系统负载较低，因而终端可以确定系统负载状态为空闲状态。
[0120]
比如，假设第一丢帧率阈值为1％，第二丢帧率阈值为0，第一时间比率阈值为90％，第二时间比率阈值为40％。如图5所示，在系统负载状态处于空闲状态或正常状态时，若系统丢帧率持续升高至大于或等于1％，或者io时间比率持续升高至大于或等于90％，说明系统负载增高，则系统负载状态从空闲状态或正常状态切换至繁忙状态。在系统负载状态处于繁忙状态或正常状态时，若系统丢帧率持续降低至等于0，或者io时间比率持续降低至小于或等于40％，说明系统负载降低，则系统负载状态从繁忙状态或正常状态切换至空闲状态。在系统负载状态处于空闲状态时，若系统丢帧率持续升高至大于0且小于1％，并且io时间比率持续升高至io时间比率大于40％且小于90％，则系统负载状态从空闲状态切换为正常状态。在系统负载状态处于繁忙状态时，若系统丢帧率持续降低至大于0且小于1％，并且io时间比率持续降低至io时间比率大于40％且小于90％，则系统负载状态从繁忙状态切换为正常状态。
[0121]
如此，通过对系统丢帧率和io时间比率设置相应的阈值，可以判断出系统负载的
高低，继而就可以确定系统负载状态，后续根据系统负载状态可以设置在本次预读时使用的预读解压率，以使预读时需解压的数据量与系统负载状态匹配，从而保证在系统负载较高时预读不会过多占用cpu资源。
[0122]
步骤403：终端根据系统负载状态设置预读解压率。
[0123]
预读解压率是从文件系统预读数据至内存时对预读出的数据的解压率，也即是，在本次预读时需解压的数据量占预读出的所有数据量的比例。
[0124]
在一种可能的实现方式中，步骤403的操作可以为：若系统负载状态为繁忙状态，则终端设置预读解压率为0；若系统负载状态为正常状态，则终端根据系统丢帧率和io时间比率设置预读解压率；若系统负载状态为空闲状态，则终端设置预读解压率为1。
[0125]
若系统负载状态为繁忙状态，说明系统负载较高，因而终端可以设置预读解压率为0，也即在本次预读时对预读出的所有数据都不解压，如此在系统重负载时，可以在预读时避免对cpu资源的额外占用，以保证应用的正常运行。
[0126]
若系统负载状态为空闲状态，说明系统负载较低，因而终端可以设置预读解压率为1，也即在本次预读时对预读出的所有数据都解压，如此在系统轻负载时，即在cpu资源比较充足的情况下，可以正常对预读出的所有数据进行解压，在保证较好的预读效果的情况下，也不影响应用的正常运行。
[0127]
若系统负载状态为正常状态，说明系统负载适中，因而终端可以根据系统丢帧率和io时间比率设置预读解压率，此时预读解压率大于0且小于1，也即在本次预读时对预读出的所有数据中的一部分数据进行解压，如此在系统负载适中时，在预读时不会过多占用cpu资源，从而可以保证应用的正常运行。
[0128]
可选地，在系统负载状态为正常状态时，终端根据系统丢帧率和io时间比率设置预读解压率时，可以遵循系统丢帧率和io时间比率整体与预读解压率呈负相关关系的原则来设置。也即，遵循系统丢帧率和io时间比率越大，预读解压率越小，系统丢帧率和io时间比率越小，预读解压率越大的原则来设置。这种情况下，系统丢帧率和io时间比率越大，说明系统负载越高，则需使得预读解压率越小，以减小需解压的数据量，避免过多占用cpu资源。而系统丢帧率和io时间比率越小，说明系统负载越低，则需使得预读解压率越大，以在不会过多占用cpu资源的情况下，增加需解压的数据量，提高预读效果。
[0129]
作为一种示例，终端根据系统丢帧率和io时间比率设置预读解压率的操作可以为：终端根据系统丢帧率和io时间比率，通过如下公式得到预读解压率。
[0130][0131]
其中，d为预读解压率；f为系统丢帧率；f1为第一丢帧率阈值；f2为第二丢帧率阈值；i为io时间比率；i1为第一时间比率阈值；i2为第二时间比率阈值；a为系统丢帧率的权重。系统丢帧率的权重可以预先进行设置。在一些实施例中，在对预读解压率的计算中，系统丢帧率的权重可以大于io时间比率的权重，即a可以大于50％，如a可以为80％等。
[0132]
当然，终端根据系统丢帧率和io时间比率，也可以通过其他方式设置预读解压率，只要使得系统丢帧率和io时间比率整体与预读解压率呈负相关关系即可。
[0133]
步骤404：终端根据预读解压率从文件系统预读数据至内存，并在内存中访问该io请求所请求的数据。
[0134]
由于预读解压率是根据系统负载状态确定的，所以根据预读解压率从文件系统中预读数据至内存时，是根据系统负载状态来调整本次预读时需解压的数据量，如此可达到在系统重负载时解压较少的数据，在系统轻负载时解压较多的数据的效果，从而在保证预读效果的同时，也保证了系统性能均衡稳定，进而保证了应用的正常运行。
[0135]
在一种可能的实现方式中，终端根据预读解压率从文件系统预读数据至内存的操作可以为：若预读解压率为0，则终端从文件系统预读数据至内存，且不对本次预读出的所有数据进行解压。若预读解压率大于0且小于1，则终端从文件系统预读数据至内存，且对本次预读出的所有数据中所占比例为预读解压率的一部分数据进行解压，也即是，解压的这一部分数据占本次预读出的所有数据的比例为预读解压率，示例地，解压的这一部分数据可以是本次预读出的所有数据中排序在前的一部分数据。若预读解压率为1，则终端从文件系统预读数据至内存，且对本次预读出的所有数据进行解压。
[0136]
这种情况下，将文件系统中的数据预读至内存后，后续io请求到来时就可以直接在内存中访问到所请求的数据。在本技术实施例中，若内存中存储的该io请求所请求的数据是解压数据，则直接访问即可；若内存中存储的该io请求所请求的数据不是解压数据，则先对该数据进行解压，得到解压数据，再访问该解压数据即可。如此，在该io请求到来时，可以直接在内存中访问所请求的数据，而无需从文件系统中读取，从而对该io请求来说，加快了数据访问速度。
[0137]
为了便于后续在io请求到来时，能够对内存中存储的未解压的数据进行解压，终端根据预读解压率从文件系统预读数据至内存后，可以对本次预读出的所有数据中未解压的数据进行解压标记，该解压标记用于标记压缩数据，即该解压标记用于指示在内存中访问到所标记的数据时需要解压。也就是说，在后续io请求到来时，若内存中存储的该io请求所请求的数据带有解压标记，说明该数据是压缩数据，则先对该数据进行解压，得到解压数据，再访问该解压数据；若内存中存储的该io请求所请求的数据未带有解压标记，说明该数据是解压数据，则直接访问该数据。如此，通过解压标记，可以保证准确访问到所需的数据。
[0138]
在一些实施例中，终端在步骤401中接收到io请求的情况下，无论本次进行的是同步预读还是异步预读均可以执行本技术实施例所述的数据读取方法，也即执行上述步骤402
‑
步骤404。
[0139]
这种情况下，对于在目标业务本次运行过程中生成的第一个io请求来说，终端接收到该io请求后，先在内存中查找该io请求所请求的数据，由于是首次读取，所以在内存中查找不到该io请求所请求的数据，此时终端可以进行在目标业务本次运行过程中的首次预读，也即是同步预读。这种情况下，终端先根据cpu负载信息和io负载信息确定系统负载状态，再根据系统负载状态设置预读解压率，然后根据预读解压率从文件系统预读数据至内存，此时也会将该io请求所请求的数据从文件系统读取至内存，因而可以在内存中访问该io请求所请求的数据。其中，终端在内存中访问该io请求所请求的数据时，若内存中存储的该io请求所请求的数据带有解压标记，则先对该数据进行解压，得到解压数据，再访问该解压数据；若内存中存储的该io请求所请求的数据未带有解压标记，则直接访问该数据。
[0140]
对于在目标业务本次运行过程中生成的在第一个io请求之后的其他io请求来说，终端接收到该io请求后，在内存中查找该io请求所请求的数据，由于之前进行了数据预读，所以能够在内存中查找到该io请求所请求的数据，此时终端可以进行异步预读。也即，终端
可以直接在内存中访问该io请求所请求的数据，并且，如果在该内存中访问的该io请求所请求的数据中存在带有预读标记的数据，则终端可以先根据cpu负载信息和io负载信息确定系统负载状态，再根据系统负载状态设置预读解压率，然后根据预读解压率从文件系统预读数据至内存。其中，终端在内存中访问该io请求所请求的数据时，若内存中存储的该io请求所请求的数据带有解压标记，则先对该数据进行解压，得到解压数据，再访问该解压数据；若内存中存储的该io请求所请求的数据未带有解压标记，则直接访问该数据。
[0141]
在另一些实施例中，由于同步预读出的数据在后续有很大可能会被访问到，所以在同步预读时可以直接对预读出的所有数据正常进行解压，而在异步预读时可以执行本技术实施例所述的数据读取方法。也即是，终端在步骤401中接收到io请求的情况下，在本次进行的是异步预读的情况下执行本技术实施例所述的数据读取方法，也即执行上述步骤402
‑
步骤404。
[0142]
这种情况下，对于在目标业务本次运行过程中生成的第一个io请求来说，终端接收到该io请求后，先在内存中查找该io请求所请求的数据，由于是首次读取，所以在内存中查找不到该io请求所请求的数据，此时终端可以进行在目标业务本次运行过程中的首次预读，也即是同步预读。这种情况下，终端从文件系统预读数据至内存，且对预读出的所有数据进行解压，此时预读出的数据中包含该io请求所请求的数据，且该数据已被解压，因而可以在内存中直接访问该io请求所请求的数据。
[0143]
对于在目标业务本次运行过程中生成的在第一个io请求之后的其他io请求来说，终端接收到该io请求后，在内存中查找该io请求所请求的数据，由于之前进行了数据预读，所以能够在内存中查找到该io请求所请求的数据，此时终端可以进行异步预读。也即，终端可以直接在内存中访问该io请求所请求的数据，并且，如果在该内存中访问的该io请求所请求的数据中存在带有预读标记的数据，则终端可以先根据cpu负载信息和io负载信息确定系统负载状态，再根据系统负载状态设置预读解压率，然后根据预读解压率从文件系统预读数据至内存。其中，终端在内存中访问该io请求所请求的数据时，若内存中存储的该io请求所请求的数据带有解压标记，则先对该数据进行解压，得到解压数据，再访问该解压数据；若内存中存储的该io请求所请求的数据未带有解压标记，则直接访问该数据。
[0144]
在本技术实施例中，终端接收用于请求读取文件系统中的数据的io请求，文件系统中的数据是压缩存储。之后，终端根据cpu负载信息和io负载信息确定系统负载状态，且根据系统负载状态设置预读解压率，预读解压率是从文件系统预读数据至内存时对预读出的数据的解压率。最后，终端根据预读解压率从文件系统预读数据至内存，并在内存中访问该io请求所请求的数据。如此，是根据系统负载状态来调整本次预读时需解压的数据量，因而可达到在系统重负载时解压较少的数据，在系统轻负载时解压较多的数据的效果，从而在保证预读效果的同时，也保证了系统性能均衡稳定，进而保证了应用的正常运行。
[0145]
下面结合图6来对上述数据读取方法进行举例说明。
[0146]
图6是本技术实施例提供的一种数据读取方法的流程图。参见图6，该方法包括以下步骤：
[0147]
步骤601：终端确定需要从文件系统预读数据至内存。
[0148]
终端在接收到io请求时，若该io请求用于请求读取文件系统中的数据，则终端可以确定是否需要从文件系统预读数据至内存。该io请求可以是在目标业务运行过程中生成
的。目标业务是在运行过程中需要顺序读取文件系统中的数据的业务，因而在目标业务运行过程中会生成一些io请求，这些io请求用于请求顺序读取文件系统中的数据。例如，目标业务可以是启动应用、在应用内执行某些操作(如显示游戏界面)等，本技术实施例对此不作限定。
[0149]
在一种可能的方式中，若该io请求是在目标业务本次运行过程中生成的第一个io请求，则终端接收到该io请求后，先在内存中查找该io请求所请求的数据，由于是首次读取，所以在内存中查找不到该io请求所请求的数据，此时终端可以进行在目标业务本次运行过程中的首次预读，也即是同步预读。这种情况下，终端确定需要从文件系统预读数据至内存。
[0150]
在另一种可能的方式中，若该io请求是在目标业务本次运行过程中生成的在第一个io请求之后的其他io请求，则终端接收到该io请求后，在内存中查找该io请求所请求的数据，由于之前进行了数据预读，所以能够在内存中查找到该io请求所请求的数据，终端可以直接在内存中访问该io请求所请求的数据，并且，如果在该内存中访问的该io请求所请求的数据中存在带有预读标记的数据，则终端可以进行异步预读。这种情况下，终端确定需要从文件系统预读数据至内存。
[0151]
步骤602：终端判断文件系统是否为erofs。
[0152]
erofs中存储的数据为压缩数据。
[0153]
若文件系统不为erofs，则终端可以直接从文件系统中预读数据至内存。
[0154]
若文件系统为erofs，则对文件系统中的压缩数据的预读还可以伴随着对压缩数据的解压操作。由于解压操作会占用cpu资源，所以为了保证系统性能均衡稳定，在本技术实施例中，在预读的同时需要解压多少数据量可以根据系统负载状态来确定，具体在下面说明。
[0155]
步骤603：终端判断本次预读是否为异步预读。
[0156]
若本次预读为同步预读，则继续执行如下步骤604；若本次预读为异步预读，则继续执行如下步骤605
‑
步骤613。
[0157]
步骤604：若本次预读为同步预读，则终端从文件系统预读数据至内存，且对预读出的所有数据进行解压。
[0158]
这种情况下，预读出的数据中包含该io请求所请求的数据，且该数据已被解压，因而可以在内存中直接访问该io请求所请求的数据。
[0159]
步骤605：若本次预读为异步预读，则终端确定需要设置预读解压率。
[0160]
预读解压率是从文件系统预读数据至内存时对预读出的数据的解压率，也即是，在本次预读时需解压的数据量占预读出的所有数据量的比例。
[0161]
步骤606：终端获取系统丢帧率和io时间比率。
[0162]
在一些实施例中，终端可以通过surfaceflinger服务中用于获取帧信息的相关接口来获取系统丢帧率，当然，终端也可以通过其他方式来获取系统丢帧率，本技术实施例对此不作限定。
[0163]
在一些实施例中，终端可以通过io吞吐量统计服务来获取io时间比率，当然，终端也可以通过其他方式来获取io时间比率，本技术实施例对此不作限定。
[0164]
步骤607：终端根据系统丢帧率和io时间比率确定系统负载状态。
[0165]
系统负载状态用于体现系统整体的负载情况。系统负载状态可以为繁忙状态、正常状态或空闲状态。系统负载状态为繁忙状态时，说明系统负载较高；系统负载状态为正常状态时，说明系统负载适中；系统负载状态为空闲状态时，说明系统负载较低。
[0166]
终端根据系统丢帧率和io时间比率确定系统负载状态的操作已在上述步骤402中进行详细描述，本技术实施例对此不再赘述。
[0167]
若系统负载状态为空闲状态，则继续执行如下步骤608；若系统负载状态为繁忙状态，则继续执行如下步骤609
‑
步骤610；若系统负载状态为正常状态，则继续执行如下步骤611
‑
步骤613。
[0168]
步骤608：若系统负载状态为空闲状态，则终端设置预读解压率为1，此时终端从文件系统预读数据至内存时，对本次预读出的所有数据进行解压。
[0169]
若系统负载状态为空闲状态，说明系统负载较低，因而终端可以设置预读解压率为1，也即在本次预读时对预读出的所有数据都解压，如此在系统轻负载时，即在cpu资源比较充足的情况下，可以正常对预读出的所有数据进行解压，在保证较好的预读效果的情况下，也不影响应用的正常运行。
[0170]
步骤609：若系统负载状态为繁忙状态，则终端设置预读解压率为0，此时终端从文件系统预读数据至内存时，不对本次预读出的所有数据进行解压。
[0171]
若系统负载状态为繁忙状态，说明系统负载较高，因而终端可以设置预读解压率为0，也即在本次预读时对预读出的所有数据都不解压，如此在系统重负载时，可以在预读时避免对cpu资源的额外占用，以保证应用的正常运行。
[0172]
这种情况下，由于本次预读出的所有数据都未解压，则终端还可以执行步骤610：终端对本次预读出的所有数据均进行解压标记。
[0173]
该解压标记用于标记压缩数据，即该解压标记用于指示在内存中访问到所标记的数据时需要解压。也就是说，在后续io请求到来时，若内存中存储的该io请求所请求的数据带有解压标记，说明该数据是压缩数据，则先对该数据进行解压，得到解压数据，再访问该解压数据；若内存中存储的该io请求所请求的数据未带有解压标记，说明该数据是解压数据，则直接访问该数据。如此，通过解压标记，可以保证准确访问到所需的数据。
[0174]
步骤611：若系统负载状态为正常状态，则终端根据系统丢帧率和io时间比率设置预读解压率，此时预读解压率大于0且小于1。
[0175]
若系统负载状态为正常状态，说明系统负载适中，因而终端可以根据系统丢帧率和io时间比率设置预读解压率，此时预读解压率大于0且小于1，也即在本次预读时对预读出的所有数据中的一部分数据进行解压，如此在系统负载适中时，在预读时不会过多占用cpu资源，从而可以保证应用的正常运行。
[0176]
终端根据系统丢帧率和io时间比率设置预读解压率的操作已在上述步骤403中进行详细描述，本技术实施例对此不再赘述。
[0177]
步骤612：终端从文件系统预读数据至内存时，对本次预读出的所有数据中所占比例为预读解压率的一部分数据进行解压。
[0178]
本次预读出的所有数据中解压的这一部分数据占本次预读出的所有数据的比例为预读解压率。如此，在系统负载适中时，在本次预读时对预读出的所有数据中的一部分数据进行解压，从而在预读时不会过多占用cpu资源，进而可以保证应用的正常运行。
[0179]
这种情况下，由于本次预读出的所有数据中的另一部分数据未解压，则终端还可以执行步骤613：终端对本次预读出的所有数据中未解压的另一部分数据进行解压标记。
[0180]
值得注意的是，终端将文件系统中的数据预读至内存后，后续io请求到来时就可以直接在内存中访问到所请求的数据。在本技术实施例中，若内存中存储的该io请求所请求的数据是解压数据，则直接访问即可；若内存中存储的该io请求所请求的数据不是解压数据，则先对该数据进行解压，得到解压数据，再访问该解压数据即可。如此，在该io请求到来时，可以直接在内存中访问所请求的数据，而无需从文件系统中读取，从而对该io请求来说，加快了数据访问速度。
[0181]
在本技术实施例中，终端在每次需要从文件系统预读数据至内存时，均可以获取当前的系统丢帧率和io时间比率，继而根据系统丢帧率和io时间比率确定当前的系统负载状态。之后，根据系统负载状态来调整本次预读时需解压的数据量，以在系统重负载时解压较少的数据，在系统轻负载时解压较多的数据，如此在保证预读效果的同时，也保证了系统性能均衡稳定，进而保证了应用的正常运行。
[0182]
下面结合图7和图8来对上述数据读取方法进行举例说明。
[0183]
如图7中的a图所示，在手机主界面701上显示有多个应用的图标。用户点击其中的音乐应用的图标，以启动音乐应用。在启动音乐应用的过程中共生成三个io请求来顺序读取文件系统中的数据。假设文件系统中存储的数据为压缩数据，且第一丢帧率阈值为1％，第二丢帧率阈值为0％，第一时间比率阈值为90％，第二时间比率阈值为40％。参见图8，启动音乐应用时的数据读取过程如下：
[0184]
手机的操作系统接收在启动音乐应用的过程中生成的第一个io请求，第一个io请求用于请求读取文件系统中的数据1。操作系统先在内存中查找数据1。因为是首次读取，所以在内存中查找不到数据1，从而触发同步预读，同步预读时对预读出的所有数据均进行解压。
[0185]
具体地，操作系统在进行同步预读时，先初始化一个预读窗口。假设初始化的预读窗口大小为4，则可以从文件系统中读取该预读窗口大小所指示的数据量(即4个数据，也即数据1～数据4)到内存中，并且对数据1～数据4进行解压，此时内存中存储的是数据1～数据4的解压数据。可以看出，第一个io请求所请求的是数据1，而操作系统从文件系统中一共读出数据1～数据4，其中的后3个数据(即数据2～数据4)均属于预读数据。之后，操作系统在内存中访问第一个io请求所请求的数据1的解压数据。并且，这种情况下，操作系统为本次预读出的这3个预读数据中的第一个预读数据(即数据2)打上预读标记。当后续访问到内存中被打上预读标记的这个预读数据时，操作系统会进行一次异步预读，具体过程在下面说明。
[0186]
操作系统接收在启动音乐应用的过程中生成的第二个io请求，第二个io请求用于请求读取文件系统中的数据2和数据3。操作系统先在内存中查找数据2和数据3。因为之前已经从文件系统中将数据2和数据3预读到了内存中，所以可以在内存中查找到数据2和数据3，且由于数据2和数据3不带有解压标记，所以可以确定内存中存储的是数据2和数据3的解压数据，此时在内存中直接访问第二个io请求所请求的数据2和数据3的解压数据。这种情况下，由于数据2被打上了预读标记，所以在访问到数据2时，会触发异步预读，异步预读时需要根据系统负载状态设置预读解压率。
[0187]
具体地，操作系统在进行本次异步预读时，获取系统丢帧率和io时间比率，假设系统丢帧率为0.5％、io时间比率为50％。由于系统丢帧率(0.5％)小于第一丢帧率阈值(1％)且大于第二丢帧率阈值(0％)，以及io时间比率(50％)小于第一时间比率阈值(90％)且大于第二时间比率阈值(40％)，所以可以确定系统负载状态为正常状态，此时可以通过如下公式得到预读解压率为56％。
[0188][0189]
之后，操作系统先确定本次异步预读时所要使用的预读窗口大小，示例地，可以将2倍的上次同步预读时使用的预读窗口大小作为本次异步预读时所要使用的预读窗口大小，即本次异步预读时所要使用的预读窗口大小为8。由于预读解压率为56％，所以本次异步预读时需解压的数据量为8
×
56％≈4，则确定需要对本次预读出的所有数据中的前4个数据进行解压，对其他数据不解压。这种情况下，操作系统在上次同步预读的基础上，即从文件系统中位于上次预读出的最后一个数据(即数据4)的后一个数据(即数据5)开始，从文件系统中读取该预读窗口大小所指示的数据量(即8个数据，也即数据5～数据12)到内存中，且对前四个数据(即数据5～数据8)进行解压，对其他数据(即数据9～数据12)不进行解压，此时内存中存储的是数据5～数据8的解压数据，而存储的数据9～数据12均为压缩数据，因而对数据9～数据12进行解压标记，以指示后续在内存中访问到数据9～数据12时需要解压。可以看出，第二个io请求所请求的是数据2和数据3，而操作系统从文件系统中一共读出数据5～数据12，数据5～数据12均属于预读数据。这种情况下，操作系统为本次预读出的这8个预读数据中的第一个预读数据(即数据5)打上预读标记。当后续访问到内存中被打上预读标记的这个预读数据时，操作系统会进行一次异步预读，具体在下面说明。
[0190]
操作系统接收在启动音乐应用的过程中生成的第三个io请求，第三个io请求用于请求读取文件系统中的数据4～数据9。操作系统先在内存中查找数据4～数据9。因为之前已经从文件系统中将数据4～数据9预读到了内存中，所以可以在内存中查找到数据4～数据9，且由于数据4～数据8不带有解压标记，数据9带有解压标记，所以可以确定内存中存储的是数据4～数据8的解压数据，而存储的数据9是压缩数据，此时在内存中直接访问数据4～数据8的解压数据，以及对内存中存储的数据9进行解压，访问数据9的解压数据。这种情况下，由于数据5被打上了预读标记，所以在访问到数据5时，会触发异步预读，异步预读时需要根据系统负载状态设置预读解压率。
[0191]
具体地，操作系统在进行本次异步预读时，获取系统丢帧率和io时间比率，假设系统丢帧率为2％、io时间比率为40％，由于系统丢帧率(2％)大于第一丢帧率阈值(1％)，所以可以确定系统负载状态为繁忙状态，则设置预读解压率为0。
[0192]
之后，操作系统先确定本次异步预读时所要使用的预读窗口大小，示例地，可以将2倍的上次异步预读时使用的预读窗口大小作为本次异步预读时所要使用的预读窗口大小，即本次异步预读时所要使用的预读窗口大小为16。由于预读解压率为0，所以本次异步预读时需解压的数据量为0，即对本次预读出的所有数据都不需要解压。这种情况下，操作系统可以在上次异步预读的基础上，即从文件系统中位于上次预读出的最后一个数据(即数据12)的后一个数据(即数据13)开始，从文件系统中读取该预读窗口大小所指示的数据量(即16个数据，也即数据13～数据28)到内存中，且对数据13～数据28均不解压，此时内存
中存储的数据13～数据28均为压缩数据，因而对数据13～数据28进行解压标记，以指示后续在内存中访问到数据13～数据28时需要解压。可以看出，第三个io请求所请求的是数据4～数据9，而操作系统从文件系统中一共读出数据13～数据28，数据13～数据28均属于预读数据。这种情况下，操作系统为本次预读出的这16个预读数据中的第一个预读数据(即数据13)打上预读标记。当后续访问到内存中被打上预读标记的这个预读数据时，操作系统会进行一次异步预读。
[0193]
当操作系统在内存中访问了第三个io请求所请求的数据4～数据9的解压数据后，就完成了启动音乐应用的过程，此时手机会从图7中的a图所示的主界面701切换至显示图7中的b图所示的音乐应用的应用界面702。
[0194]
在本次启动音乐应用的过程中，如图8所示，共生成三个io请求来顺序读取文件系统中存储的数据。在接收到第一个io请求后进行同步预读时，对预读出的所有数据进行解压。在接收到第二个io请求后进行异步预读时，由于系统负载状态为正常状态，所以对预读出的一部分数据进行解压，以避免过多占用cpu资源。在接收到第三个io请求后进行异步预读时，由于系统负载状态为繁忙状态，所以对预读出的所有数据均不进行解压，以避免对cpu资源的占用。如此，在每次异步预读时，均根据系统负载状态来调整本次预读时需解压的数据量，以在系统重负载时解压较少的数据，在系统轻负载时解压较多的数据，从而可在保证预读效果的同时，保证系统性能均衡稳定，进而保证了应用的正常运行。
[0195]
图9是本技术实施例提供的一种数据读取装置的结构示意图，该数据读取装置可以由软件、硬件或者两者的结合实现成为计算机设备的部分或者全部，该计算机设备可以为图1所示的终端。参见图9，该装置包括：接收模块901、确定模块902、设置模块903和读取模块904。
[0196]
接收模块901，用于执行上述图4实施例中的步骤401；
[0197]
确定模块902，用于执行上述图4实施例中的步骤402；
[0198]
设置模块903，用于执行上述图4实施例中的步骤403；
[0199]
读取模块904，用于执行上述图4实施例中的步骤404。
[0200]
可选地，cpu负载信息包括系统丢帧率，io负载信息包括io时间比率，系统负载状态为繁忙状态、正常状态或空闲状态。
[0201]
可选地，确定模块902用于：
[0202]
若系统丢帧率大于或等于第一丢帧率阈值，或者io时间比率大于或等于第一时间比率阈值，则确定系统负载状态为繁忙状态；
[0203]
若系统丢帧率大于第二丢帧率阈值且小于第一丢帧率阈值，以及io时间比率大于第二时间比率阈值且小于第一时间比率阈值，则确定系统负载状态为正常状态；第一丢帧率阈值大于第二丢帧率阈值，第一时间比率阈值大于第二时间比率阈值；
[0204]
若系统丢帧率小于或等于第二丢帧率阈值，或者io时间比率小于或等于第二时间比率阈值，则确定系统负载状态为空闲状态。
[0205]
可选地，设置模块903用于：
[0206]
若系统负载状态为繁忙状态，则设置预读解压率为0；
[0207]
若系统负载状态为正常状态，则根据系统丢帧率和io时间比率设置预读解压率；
[0208]
若系统负载状态为空闲状态，则设置预读解压率为1。
[0209]
可选地，设置模块903用于：
[0210]
根据系统丢帧率和io时间比率，通过如下公式得到预读解压率；
[0211][0212]
其中，d为预读解压率，f为系统丢帧率，f1为第一丢帧率阈值，f2为第二丢帧率阈值，第一丢帧率阈值大于第二丢帧率阈值，i为io时间比率，i1为第一时间比率阈值，i2为第二时间比率阈值，第一时间比率阈值大于第二时间比率阈值，a为系统丢帧率的权重。
[0213]
可选地，读取模块904用于：
[0214]
若预读解压率为0，则从文件系统预读数据至内存，且不对本次预读出的所有数据进行解压；
[0215]
若预读解压率大于0且小于1，则从文件系统预读数据至内存，且对本次预读出的所有数据中所占比例为预读解压率的一部分数据进行解压；
[0216]
若预读解压率为1，则从文件系统预读数据至内存，且对本次预读出的所有数据进行解压；
[0217]
该装置还包括：
[0218]
标记模块，用于对本次预读出的所有数据中未解压的数据进行解压标记，解压标记用于指示在内存中访问到所标记的数据时需要解压。
[0219]
可选地，读取模块904用于：
[0220]
若内存中存储的io请求所请求的数据带有解压标记，则对内存中存储的io请求所请求的数据进行解压，访问解压后的数据。
[0221]
可选地，该装置还包括：
[0222]
触发模块，用于在接收io请求后，在本次进行的是异步预读的情况下，触发确定模块902执行上述图4实施例中的步骤402。
[0223]
可选地，该装置还包括：
[0224]
解压模块，用于在接收io请求后，若本次进行的是同步预读，则从文件系统预读数据至内存，且对本次预读出的所有的数据进行解压；
[0225]
读取模块904，还用于在内存中访问io请求所请求的数据。
[0226]
可选地，文件系统为erofs。
[0227]
在本技术实施例中，接收用于请求读取文件系统中的数据的io请求，文件系统中的数据是压缩存储。之后，根据cpu负载信息和io负载信息确定系统负载状态，且根据系统负载状态设置预读解压率，预读解压率是从文件系统预读数据至内存时对预读出的数据的解压率。最后，根据预读解压率从文件系统预读数据至内存，并在内存中访问该io请求所请求的数据。如此，是根据系统负载状态来调整本次预读时需解压的数据量，因而可达到在系统重负载时解压较少的数据，在系统轻负载时解压较多的数据的效果，从而在保证预读效果的同时，也保证了系统性能均衡稳定，进而保证了应用的正常运行。
[0228]
需要说明的是：上述实施例提供的数据读取装置在读取数据时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的数据读取装置与数据读取方法实施例属于同一构思，其具体实
现过程详见方法实施例，这里不再赘述。
[0229]
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意结合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时，全部或部分地产生按照本技术实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络或其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如：同轴电缆、光纤、数据用户线(digital subscriber line，dsl))或无线(例如：红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质，或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如：软盘、硬盘、磁带)、光介质(例如：数字通用光盘(digital versatile disc，dvd))或半导体介质(例如：固态硬盘(solid state disk，ssd))等。
[0230]
以上所述为本技术提供的可选实施例，并不用以限制本技术，凡在本技术揭露的技术范围之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。