CN108108089B - 一种图片加载方法及装置 - Google Patents

Abstract

本发明公开了一种图片加载方法及装置，所述方法包括：在图片加载页面上检测是否有输入操作；如果检测到输入操作，确定所述输入操作的属性参数；判断所述属性参数是否大于预设的阈值；如果所述属性参数小于所述预设的阈值，按照预设的图片加载数量获取待加载的图片；在所述图片加载页面上加载获取的所述待加载的图片。

Description

一种图片加载方法及装置

技术领域

本发明涉及电子技术，尤其涉及一种图片加载方法及装置。

背景技术

现如今的手机应用，越来越多的以图片列表的形式展现内容；因此，图片的处理对于应用的优化就显得格外的重要。例如安卓手机的列表视图(ListView)页是用于图片的加载及优化，以及从服务器上下载图片一直到在列表页上显示。在这一过程中，如果用户在快速滑动页面，就会出现大量的线程来请求服务器加载图片。在图片下载过程中有可能出现网络堵塞，线程堵塞，以及下载的图片缓存过大出现内存溢出等情况，从而导致应用处于不可用状态或者直接退出。

在解决这一问题上，现有的解决方案如下：

相关技术1提供的技术方案包括：加载来自于网络图片资源的统一资源标识符(URI，Uniform Resource Identifier)上的网络图片信息，并将该网络图片信息传输给本地缓存模块中；本地缓存模块存储网络图片信息；然后通过获取视图(getview)方法运算得出获取网络图片的方式；最后显示加载的网络图片或本地缓存模块中的网络图片。该技术采用限制内存的大小的方法，通过对图片的权重大小排列并在图片存储超过设定的存储上限时清理权重小的图片来来防止内存溢出。但是还有一点没有考虑到的是，如果界面列表图片的权重差不多，页面显示的图片较多且都会经常加载，这个时候就要考虑将缓存划分层次来处理了。

相关技术2提供的技术防范包括：a.设置缓存最大值；b.设置软引用图片缓存模块可保存的图片数量；c.根据应用程序传入的图片地址将图片加载到内存中；d.当应用程序需要使用之前保存的图片时，传入图片地址以及尺寸到获取图片缓存模块。此技术采用了两个缓存模块来对图片进行缓存，两个模块的存储算法均是LRU(Least Recently Used)近期最少使用算法。在存储方面可以说是极大的优化了手机内存，但是此技术没有考虑到一点的是，有些图片属于基本信息，需要长期驻存在手机上，不管有没有经常被加载。例如：用户的头像，好友的头像。这些可能不会经常被加载，但是查看时需要及时显示。因此需要增加一层内存存储，其级别高于这两级缓存，来存储重要信息。

相关技术3提供的方法包括：存放所有图片信息；存放图片列表中需要加载的图片信息；存放图片列表中需要显示的图片信息；存放已经下载的图片信息；图片应用启动后下载图片并将图片信息保存至所述图片列表中，根据图片显示列表中的图片总数量进行构建显示，并根据当前显示屏的前一屏和/或后一屏需要显示的图片进行加载显示图片，超出当前显示屏的前一屏和/或后一屏需要显示的图片均不加载显示。此技术适合的场景是图文结合且文字较多，图片间距大小适中，这个时候加载图片的请求不多，线程池里的线程能够充分利用。当加载图片较多且没有文字作为间隔的时候，此时需要考虑如果用户快速滑动界面，这个时候无需加载前一屏或后一屏的图片，只需加载当前页面，才能够满足图片加载的流畅性。

发明内容

有鉴于此，本发明实施例为解决现有技术中存在的至少一个问题而提供一种图片加载方法及装置，能够判断用户的滑动状态，然后根据滑动状态确定加载图片的数量。

本发明实施例的技术方案是这样实现的：

第一方面，本发明实施例提供一种图片加载方法，所述方法包括：

在图片加载页面上检测是否有输入操作；

如果检测到输入操作，确定所述输入操作的属性参数；

判断所述属性参数是否大于预设的阈值；

如果所述属性参数小于所述预设的阈值，按照预设的图片加载数量获取待加载的图片；

在所述图片加载页面上加载获取的所述待加载的图片。

第二方面，本发明实施例一种图片加载装置，所述装置包括检测单元、确定单元、判断单元、获取单元和加载单元，其中：

所述检测单元，用于在图片加载页面上检测是否有输入操作；

所述确定单元，用于如果检测到输入操作，确定所述输入操作的属性参数；

所述判断单元，用于判断所述属性参数是否大于预设的阈值；

所述获取单元，用于如果所述属性参数小于所述预设的阈值，按照预设的图片加载数量获取待加载的图片；

所述加载单元，用于在所述图片加载页面上加载获取的所述待加载的图片。

本发明实施例提供一种图片加载方法及装置，其中，在图片加载页面上检测是否有输入操作；如果检测到输入操作，确定所述输入操作的属性参数；判断所述属性参数是否大于预设的阈值；如果所述属性参数小于所述预设的阈值，按照预设的图片加载数量获取待加载的图片；在所述图片加载页面上加载获取的所述待加载的图片；如此，能够判断用户的滑动状态，然后根据滑动状态确定加载图片的数量。

附图说明

图1为本发明实施例图片加载方法的实现流程示意图；

图2为本发明实施例图片加载方法的实现流程示意图；

图3为本发明实施例图片加载装置的组成结构示意图。

具体实施方式

下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。

为了解决背景技术中存在的技术问题，本发明实施例提供一种图片加载方法，该方法应用于电子设备，该信息处理方法所实现的功能可以通过电子设备中的处理器调用程序代码来实现，当然程序代码可以保存在计算机存储介质中，可见，该电子设备至少包括处理器和存储介质。

图1为本发明实施例图片加载方法的实现流程示意图，如图1所示，该方法包括：

步骤S101，在图片加载页面上检测是否有输入操作；

这里，所述电子设备在具体实施例的过程中可以为各种类型的具有信息处理能力的设备，例如所述电子设备可以包括手机、平板电脑、台式机、个人数字助理、导航仪、数字电话、视频电话、电视机等。

步骤S102，如果检测到输入操作，确定所述输入操作的属性参数；

这里，所述属性参数用于描述所述输入操作的滑动速度或滑动压力。

步骤S103，判断所述属性参数是否大于预设的阈值；

这里，所述阈值可以为对速度而设置的速度阈值，或者对压力所设置的压力阈值。

步骤S104，如果所述属性参数小于所述预设的阈值，按照预设的图片加载数量获取待加载的图片；

步骤S105，在所述图片加载页面上加载获取的所述待加载的图片。

步骤S106，如果所述属性参数大于所述预设的阈值，则重新在图片加载页面上检测是否有输入操作。

在本发明的其他实施例中，步骤S104，按照预设的图片加载数量获取待加载的图片，包括：

步骤S141，按照预设的图片加载数量获取所述待加载的图片的URI；

步骤S142，通过将所述待加载的图片的URI作为关键值，以关键值作为索引获取所述待加载的图片；

在本发明的其他实施例中，所述通过将所述待加载的图片的URI作为关键值，以关键值作为索引获取所述待加载的图片，包括：根据所述待加载的图片的URI查找第一缓存、第二缓存和第三缓存，得到查找结果；其中第一缓存用于缓存已解码的图片，所述第二缓存用于缓存未解码的图片，所述第三缓存用于缓存从所述述图片加载页面对应的服务器下载的原图；如果所述查找结果表明所述第一缓存、所述第二缓存或所述第三缓存中有所述待加载的图片，从所述第一缓存、所述第二缓存或所述第三缓存中获取所述待加载的图片；如果所述查找结果表明所述第一缓存、所述第二缓存和所述第三缓存中均有所述待加载的图片，则确定为以关键值作为索引未获取到所述待加载的图片。在实现的过程中，所述第一缓存为磁盘缓存，所述第二缓存为内存缓存，所述第三缓存为匿名共享缓存。

步骤S143，如果以关键值作为索引未获取到所述待加载的图片，根据所述待加载的图片的URI从所述图片加载页面对应的服务器上下载所述待加载的图片；

这里，电子设备向服务器发送下载请求，所述下载请求中携带有URI，服务器响应所述下载请求，向电子设备发送下载响应，所述下载响应中携带有所述待加载的图片的原图；

步骤S144，如果下载成功，将已下载的图片按照URI为关键值进行缓存。

这里，所述如果下载成功，将已下载的图片按照URI为关键值进行缓存，包括：如果下载成功，对所述已下载的图片进行预处理，其中所述预处理至少包括裁剪、解码；将未解码的带有图片大小尺寸信息的图片存储在第二缓存中；将已解码的图片信息通过匿名共享缓存缓存在虚拟机底层分配的堆内存中。

在本发明的其他实施例中，所述根据所述待加载的图片的URI查找第一缓存、第二缓存和第三缓存，得到查找结果，包括：

步骤S11，根据所述待加载的图片的URI查找第三缓存，得到第一查找结果；

步骤S12，如果所述第一查找结果表明所述第三缓存中有所述待加载的图片，则确定所述查找结果为所述第三缓存中有所述待加载的图片；

步骤S13，如果所述第一查找结果表明所述第三缓存中没有所述待加载的图片，则根据所述待加载的图片的URI查找第二缓存，得到第二查找结果；

步骤S14，如果所述第二查找结果表明所述第二缓存中有所述待加载的图片，则确定所述查找结果为所述第二缓存中有所述待加载的图片；

步骤S15，如果所述第二查找结果表明所述第二缓存中没有所述待加载的图片，则根据所述待加载的图片的URI查找第三缓存，得到第三查找结果；

步骤S16，如果所述第三查找结果表明所述第三缓存中有所述待加载的图片，则确定所述查找结果为所述第三缓存中有所述待加载的图片；

步骤S17，如果所述第二查找结果表明所述第二缓存中没有所述待加载的图片，则确定所述查找结果为所述第一缓存、所述第二缓存和第三缓存中均没有所述待加载的图片。

在本发明的其他实施例中，所述第二缓存包括第一缓存池和第二缓存池，所述将未解码的带有图片大小尺寸信息的图片存储在第二缓存中，包括：

步骤S21，判断第一缓存池是否存满，如果未存满，则将未解码的带有图片大小尺寸信息的图片直接缓存到第一缓存池；

步骤S22，如果第一缓存池已经存满且第二缓存池未存满，将未解码的带有图片大小尺寸信息的图片直接将图片存储在第二缓存池中；

步骤S23，当第一和第二缓存池均存满，则判断第一和第二缓存池中是否有与所述已下载的图片具有相同图片内容但图片尺寸不同的图片；

步骤S24，如果第一和第二缓存池中有与所述已下载的图片具有相同图片内容但图片尺寸不同的图片，则将用所述未解码的带有图片大小尺寸信息的图片替换所述第一和第二缓存池中具有相同图片内容但图片尺寸不同的图片；

步骤S25，如果第一和第二缓存池中没有与所述已下载的图片具有相同图片内容但图片尺寸不同的图片，将第一、第二缓存池中的超过存活时间的图片全部移除，然后将所述未解码的带有图片大小尺寸信息的图片缓存在第一缓存池或第二缓存池。

在本发明的其他实施例中，所述第二缓存包括第一子缓存和第二子缓存，其中第一子缓存用链式哈希图作为数据结构，第二子缓存使用并发哈希图，所述根据所述待加载的图片的URI查找第二缓存，得到第二查询结果，包括：

步骤S31，根据所述待加载的图片的URI查找第一子缓存；

步骤S32，如果第一子缓存有，则确定第二查询结果表明第二缓存中有所述待加载的图片；

步骤S33，如果第一子缓存没有，根据所述待加载的图片的URI查找第二子缓存；

步骤S34，如果所述第二子缓存有，则确定第二查询结果表明第二缓存中有所述待加载的图片；如果所述第二子缓存没有，则确定第二查询结果表明第二缓存中没有所述待加载的图片。

为了解决前述背景技术中存在的技术问题，本发明实施例提供一种图片加载方法，在本实施例中，针对图片加载，使用图片对应的统一资源标识符(URI，UniformResource Identifier)作为关键值进行存储，在现实过程中匹配URI，从而防止图片加载错位。在用户操作上，识别用户当前的操作，如果用户不是出于快速滑动过程中，可以预先下载下一屏的前三个图片，有效利用线程池中的线程。如果用户出于快速滑动，则只加载当前用户停留页面的图片。对于图片存储方面的优化，本发明采用手机的安全数码卡(SD Card，Secure Digital Memory Card)存储以及手机二级缓存存储的方式，针对一些必要却不经常显示的图片以及用户浏览的图片进行分类分级存储，即满足了使用的流畅性，又免去了不必要的图片下载过程。

下面介绍一下本实施例的实现流程，该实现流程包括两部分，第一部分为图片加载部分，图2为本发明实施例图片加载方法的实现流程示意图，如图2所示，该流程包括：

步骤S201、判断用户是否处于快速滑动状态；如果是，进入步骤S201，如果否，进入步骤S202；

这里，在当前页面判断用户的操作，看用户是否处于快速滑动状态。如果用户不是处于快速滑动状态，则进入步骤S202。如果用户处于快速滑动状态，则直至用户停止滑动后重复步骤S201。

步骤S202、当用户处于缓慢滑动时，获取下一屏前三个图片的URI，在加载当前屏的图片的同时，在SDCard和缓存中查找图片是否存在；如果存在，进入步骤S203；如果否，进入步骤S205；

这里，如果存在，则等待加载，如果不存在，则进入步骤S205。

步骤S203、通过当前图片列表的URI作为关键值key，在内存中以key作为索引查找图片是否存在；如果存在，进入步骤S207；如果不存在，进入步骤S204；

这里，如果找到则显示图片，如果未找到则进入步骤S204。

步骤S204、采用key值对应的文件名来检索SDCard上的文件是否存在，如果是，进入步骤S207；如果否，进入步骤S205。

这里，如果SDCard上有相对应的文件，则对文件进行解码并返回数据，同时将数据写入内存缓存中并显示图片。如果SDCard中没有相对应的文件，则执行步骤S205。

步骤S205、开启异步线程，从服务器上下载图片。

步骤S206、如果下载成功，将数据写入SDCard中；

步骤S207、则将数据同时写入SDCard和内存缓存中，并显示图片。

第二部分为图片存储部分，本实施例提出了一种更好的图片存储策略，对图片存储采取三级缓存策略。第三级缓存为磁盘缓存，用来存放从网络上下载下来的原图，磁盘缓存可以SDCard缓存，主要存储一些不经常查看但是需要快速加载出来的图片，比如用户的头像还有应用不升级时涉及到的Tab页图片改变；第二级缓存为内存缓存，其中缓存的图片为未解码的图片；第一级缓存为匿名共享缓存，此层缓存处于虚拟机底层，存放的是已解码的图片信息。下面主要说一下三级缓存的缓存流程。

1)加载图片时，发现已解码的图片里没有需要加载的图片，而且内存缓存里也没有需要的图片，此时需要从网络上下载图片。图片解码通过视图(View)显示后，将已解码的位图(Bitmap)信息通过匿名共享缓存，缓存在虚拟机底层分配的堆内存中；然后将View需要显示的图片尺寸及图片内容存储在二级内存缓存中。下载下来的原图信息则存储在磁盘缓存中。

2)加载图片时，发现已解码的图片里没有需要加载的图片，内存缓存中也没有需要的图片，磁盘缓存中存有图片原图，此时直接加载磁盘中的图片。在加载过程中，查看需要加载图片的尺寸，在加载过程中，原始图片经历裁剪、解码,然后采用红绿蓝_565(RGB_565)格式加载图片，这样可以尽可能的减小内存占用空间，将未解码的带有图片大小尺寸信息的图片存储在内存缓存中；最后将已解码的图片信息通过匿名共享缓存例如安卓系统中的Ashmem缓存在虚拟机底层分配的堆内存中。

3)加载图片时，发现已解码的图片里没有需要加载的图片，内存缓存中存在，则直接将内存缓存中的图片解码并存储到底层虚拟机分配的内存空间中。然后加载图片显示。

4)加载图片时，发现存在已解码的图片，则直接加载。

分析过缓存流程后，下面主要介绍下内存缓存。内存缓存包括两部分，第一层级为未解码的图片内存缓存，第二层级为通过匿名共享缓存存储的已经解码的Bitmap缓存，其中：

未解码的图片内存缓存，此级缓存设计一个图片缓存池来存储未解码的图片。这个图片缓存池分为两个部分，一个部分是主缓存池(Main Pool)，另一部分为副缓存池(Second Pool)，主、副缓存池均限定了存储图片数量大小。缓存池中的关键值是以图片的大小、图片名称以及分辨率来标记图片的。当需要将图片缓存在图片缓存池中，流程如下：首先，判断主缓存池是否存满，如果未存满，则直接缓存到主缓存池。如果已经存满且副缓存池未存满，直接将图片存储在副缓存池中。当主副缓存池均存满，则判断主副缓存池中是否有相同图片内容但图片尺寸不同的图片；如果存在，则移除最近未使用的那个图片，并将新图片添加到缓存池中；如果不存在，考虑清除图片缓存池的时间，即设定一个alive时间(即图片存活时间)，当超过这个时间后，将主副缓存池中的超过存活时间的图片全部移除，但是主副缓存池的空间大小不变。

通过匿名共享缓存存储的已解码的Bitmap缓存，匿名共享缓存(例如安卓系统中的Ashmem)不能被Java应用直接处理，但是图片是例外的。当创建一张没有经过压缩的Bitmap的时候，将options.inPurgeable设置为真(true)；可清除的Bitmap会驻留在Ashmem堆中。不管发生什么，垃圾回收器都不会自动回收这些Bitmap。当Android绘制系统在渲染这些图片，Android的系统库就会把这些Bitmap从Ashmem堆中抽取出来，而当渲染结束后，这些Bitmap又会被放回到原来的位置。如果一个被抽取的图片需要再绘制一次，系统仅仅需要把它再解码一次，这个操作非常迅速。在系统内存紧张时底层才会回收Ashmem里的这部分内存。这样的缓存存储设置提高了图片缓存性能以及图片加载速度。

在本发明的其他实施例中，在内存缓存方面，还可以采取了二级缓存方式，其具体方法如下。第一子缓存用链式哈希图(Linked Hash Map)作为数据结构，键值(key)为字符串(string)类型，存放位图(Bitmap)的URI，value为Bitmap对象，存放该URI对应的保留Bitmap的强引用对象。此时图片为强引用(Strong Reference)，不会被图形计算器(Graphing Calculator，GC)回收。在第一子缓存中要设置缓存的大小，在本程序中设置缓存大小为10。第二子缓存使用并发哈希图(Concurrent Hash Map)，key为string类型，存放Bitmap的URI，value为软引用类型存放Bitmap对象的软引用。在第二子缓存中采用软引用方式是因为软引用保存的对象实例在被GC回收时，除非是Java虚拟机内存即将溢出，否则它是不会被回收的。在缓存设计方面，软引用特别适合作为缓存对象。设计缓存的原因就是希望对象能够被快速加载，因此对象最好常驻内存。但是如果对象使用强引用方式，及时JVM出现OOM(Out Of Memory，内存不足)现象，GC也不会回收这个对象。因此采用软引用(Soft Reference)方式，使得系统设计得更具弹性。

下面的图片存储部分的实现流程，该流程包括两个步骤：

步骤1、查询：根据一个URI查询一个对象时，先会在第一子缓存中进行查询，如果第一子缓存没有，会进入到第二子缓存进行查询，如果依旧没有，再进行异步下载。

步骤2、添加：向这个缓存结构中添加数据时，先在第一子缓存进行添加，如果第一子缓存没有到达设定的容量，则直接添加；如果第一子缓存已经到达设定的容量，则依照近期最少使用算法(Least Recently Used，LRU)算法，将新添加的对象加入到第一子缓存，将最近最不常使用的对象移入第二子缓存。

LRU算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。LRU算法可以使用一个链表保存缓存数据，即：1)新数据插入到链表头部；2)每当缓存命中(即缓存数据被访问)，则将数据移到链表头部；3)当链表满的时候，将链表尾部的数据丢弃。当存在热点数据时，LRU的效率很好，但偶发性的、周期性的批量操作会导致LRU命中率急剧下降，缓存污染情况比较严重。实现起来比较简单。命中时需要遍历链表，找到命中的数据块索引，然后需要将数据移到头部。

下面介绍一下对象的强、软、弱和虚引用；

若一个对象不被任何变量引用，那么程序就无法再使用这个对象。也就是说，只有对象处于可触及(reachable)状态，程序才能使用它。一般把对象的引用分为4种级别，从而使程序能更加灵活地控制对象的生命周期。这4种级别由高到低依次为：强引用、软引用、弱引用和虚引用。下面介绍一下这四种引用：

强引用(Strong Reference)，是使用最普遍的引用。如果一个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出内存错误(out ofMemory Error)，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。

软引用(Soft Reference)，如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。软引用可以和一个引用队列(Reference Queue)联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。

弱引用(Weak Reference)，弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。弱引用可以和一个引用队列(Reference Queue)联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

虚引用(Phantom Reference)，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。

通过以上实施例可以看出，本实施例基于安卓系统的图片加载方式需要预先判断用户的滑动状态，然后根据滑动状态确定加载图片的数量。另外，图片存储优化方法采用三级缓存方式对图片进行缓存处理方式，第一级缓存为磁盘缓存，用来存放从网络上下载的原图；第二级缓存为内存缓存，其中缓存的图片为未解码的图片，在内存缓存中设计两个缓存池，对图片进行分池存储，定时清除缓存；第三级缓存为匿名共享缓存，此层缓存处于虚拟机底层，存放的是已解码的图片信息，降低被GC回收的几率。此方法在防止应用内存溢出的同时快速加载图片。和现有技术相比，本实施例的优点在于：1)、对于图片加载，使用图片对应的URI作为关键值进行存储，在现实过程中匹配URI，从而防止图片加载错位。在用户操作上，识别用户当前的操作，如果用户不是出于快速滑动过程中，可以预先下载下一屏的前三个图片，有效利用线程池中的线程。如果用户出于快速滑动，则只加载当前用户停留页面的图片。2、对于图片存储方面的优化，本发明采用三级缓存方式对图片进行缓存处理方式。第一级缓存为磁盘缓存，用来存放从网络上下载的原图；第二级缓存为内存缓存，其中缓存的图片为未解码的图片，在内存缓存中设计两个缓存池，对图片进行分池存储，定时清除缓存；第三级缓存为匿名共享缓存，此层缓存处于虚拟机底层，存放的是已解码的图片信息，降低被GC回收的几率。既满足了使用的流畅性，又免去了不必要的图片下载过程。

基于前述的实施例，本发明实施例提供一种图片加载装置，该装置所包括的各单元以及各单元所包括的各模块，各模块所包括的各子模块都可以通过电子设备中的处理器来实现，当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU)、微处理器(MPU)、数字信号处理器(DSP)或现场可编程门阵列(FPGA)等。

图3为本发明实施例图片加载装置的组成结构示意图，如图3所示，该装置300包括检测单元301、确定单元302、判断单元303、获取单元304和加载单元305，其中：

所述检测单元301，用于在图片加载页面上检测是否有输入操作；

所述确定单元302，用于如果检测到输入操作，确定所述输入操作的属性参数；

所述判断单元303，用于判断所述属性参数是否大于预设的阈值；

所述获取单元304，用于如果所述属性参数小于所述预设的阈值，按照预设的图片加载数量获取待加载的图片；

所述加载单元305，用于在所述图片加载页面上加载获取的所述待加载的图片。

在本发明的其他实施例中，所述判断单元，还用于如果所述属性参数大于所述预设的阈值，则触发所述检测单元。

在本发明的其他实施例中，所述获取单元包括第一获取模块、第二获取模块、下载模块和缓存模块，其中：

所述第一获取模块，用于按照预设的图片加载数量获取所述待加载的图片的URI；

所述第二获取模块，用于通过将所述待加载的图片的URI作为关键值，以关键值作为索引获取所述待加载的图片；

所述下载模块，用于如果以关键值作为索引未获取到所述待加载的图片，根据所述待加载的图片的URI从所述图片加载页面对应的服务器上下载所述待加载的图片；

所述缓存模块，用于如果下载成功，将已下载的图片按照URI为关键值进行缓存。

在本发明的其他实施例中，所述第二获取模块包括查询子模块、获取子模块和确定子模块，其中：

所述查询子模块，用于根据所述待加载的图片的URI查找第一缓存、第二缓存和第三缓存，得到查找结果；其中第一缓存用于缓存已解码的图片，所述第二缓存用于缓存未解码的图片，所述第三缓存用于缓存从所述述图片加载页面对应的服务器下载的原图；

所述获取子模块，用于如果所述查找结果表明所述第一缓存、所述第二缓存或所述第三缓存中有所述待加载的图片，从所述第一缓存、所述第二缓存或所述第三缓存中获取所述待加载的图片；

所述确定子模块，用于如果所述查找结果表明所述第一缓存、所述第二缓存和所述第三缓存中均有所述待加载的图片，则确定为以关键值作为索引未获取到所述待加载的图片。

在本发明的其他实施例中，所述第一缓存为磁盘缓存，所述第二缓存为内存缓存，所述第三缓存为匿名共享缓存。

在本发明的其他实施例中，所述查询子模块，用于根据所述待加载的图片的URI查找第三缓存，得到第一查找结果；

如果所述第一查找结果表明所述第三缓存中有所述待加载的图片，则确定所述查找结果为所述第三缓存中有所述待加载的图片；

如果所述第一查找结果表明所述第三缓存中没有所述待加载的图片，则根据所述待加载的图片的URI查找第二缓存，得到第二查找结果；

如果所述第二查找结果表明所述第二缓存中有所述待加载的图片，则确定所述查找结果为所述第二缓存中有所述待加载的图片；

如果所述第二查找结果表明所述第二缓存中没有所述待加载的图片，则根据所述待加载的图片的URI查找第三缓存，得到第三查找结果；

如果所述第三查找结果表明所述第三缓存中有所述待加载的图片，则确定所述查找结果为所述第三缓存中有所述待加载的图片；

如果所述第二查找结果表明所述第二缓存中没有所述待加载的图片，则确定所述查找结果为所述第一缓存、所述第二缓存和第三缓存中均没有所述待加载的图片。

在本发明的其他实施例中，所述缓存模块还包括预处理子模块、第一缓存子模块和第二缓存子模块，其中：

所述预处理子模块，用于对所述已下载的图片进行预处理，其中所述预处理至少包括裁剪、解码；

所述第一缓存子模块，用于将未解码的带有图片大小尺寸信息的图片存储在第二缓存中；

所述第二缓存子模块，用于将已解码的图片信息通过匿名共享缓存缓存在虚拟机底层分配的堆内存中。

在本发明的其他实施例中，所述第二缓存包括第一缓存池和第二缓存池，所述第一缓存子模块，用于：

判断第一缓存池是否存满，如果未存满，则将未解码的带有图片大小尺寸信息的图片直接缓存到第一缓存池；

如果第一缓存池已经存满且第二缓存池未存满，将未解码的带有图片大小尺寸信息的图片直接将图片存储在第二缓存池中；

当第一和第二缓存池均存满，则判断第一和第二缓存池中是否有与所述已下载的图片具有相同图片内容但图片尺寸不同的图片；

如果第一和第二缓存池中有与所述已下载的图片具有相同图片内容但图片尺寸不同的图片，则将用所述未解码的带有图片大小尺寸信息的图片替换所述第一和第二缓存池中具有相同图片内容但图片尺寸不同的图片；

如果第一和第二缓存池中没有与所述已下载的图片具有相同图片内容但图片尺寸不同的图片，将第一、第二缓存池中的超过存活时间的图片全部移除，然后将所述未解码的带有图片大小尺寸信息的图片缓存在第一缓存池或第二缓存池。

在本发明的其他实施例中，所述第二缓存包括第一子缓存和第二子缓存，其中第一子缓存用链式哈希图作为数据结构，第二子缓存使用并发哈希图，所述根据所述待加载的图片的URI查找第二缓存，得到第二查询结果，包括：

根据所述待加载的图片的URI查找第一子缓存；

如果第一子缓存有，则确定第二查询结果表明第二缓存中有所述待加载的图片；

如果第一子缓存没有，根据所述待加载的图片的URI查找第二子缓存；

如果所述第二子缓存有，则确定第二查询结果表明第二缓存中有所述待加载的图片；如果所述第二子缓存没有，则确定第二查询结果表明第二缓存中没有所述待加载的图片。

这里需要指出的是：以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，因此不做赘述。对于本发明装置实施例中未披露的技术细节，请参照本发明方法实施例的描述而理解，为节约篇幅，因此不再赘述。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (12)

1.一种图片加载方法，其特征在于，所述方法包括：

在图片加载页面上检测是否有输入操作；

如果检测到输入操作，确定所述输入操作的属性参数；

判断所述属性参数是否大于预设的阈值；

如果所述属性参数小于所述预设的阈值，按照预设的图片加载数量获取待加载的图片的URI；通过将所述待加载的图片的URI作为关键值，以关键值作为索引获取所述待加载的图片；

在所述图片加载页面上加载获取的所述待加载的图片；

其中，所述通过将所述待加载的图片的URI作为关键值，以关键值作为索引获取所述待加载的图片，包括：

根据所述待加载的图片的URI查找第一缓存、第二缓存和第三缓存，得到查找结果；其中，所述第一缓存用于缓存已解码的图片，所述第二缓存用于缓存未解码的图片，所述第三缓存用于缓存从所述述图片加载页面对应的服务器下载的原图；

如果所述查找结果表明所述第一缓存、所述第二缓存或所述第三缓存中有所述待加载的图片，从所述第一缓存、所述第二缓存或所述第三缓存中获取所述待加载的图片。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：如果所述属性参数大于所述预设的阈值，则重新在图片加载页面上检测是否有输入操作。

3.根据权利要求1或2所述的方法，其特征在于，按照预设的图片加载数量获取待加载的图片，包括：

如果以关键值作为索引未获取到所述待加载的图片，根据所述待加载的图片的URI从所述图片加载页面对应的服务器上下载所述待加载的图片；

如果下载成功，将已下载的图片按照URI为关键值进行缓存。

4.根据权利要求1所述的方法，其特征在于，所述通过将所述待加载的图片的URI作为关键值，以关键值作为索引获取所述待加载的图片，包括：

如果所述查找结果表明所述第一缓存、所述第二缓存和所述第三缓存中均有所述待加载的图片，则确定为以关键值作为索引未获取到所述待加载的图片。

5.根据权利要求4所述的方法，其特征在于，所述第一缓存为磁盘缓存，所述第二缓存为内存缓存，所述第三缓存为匿名共享缓存。

6.根据权利要求4所述的方法，其特征在于，所述根据所述待加载的图片的URI查找第一缓存、第二缓存和第三缓存，得到查找结果，包括

根据所述待加载的图片的URI查找第三缓存，得到第一查找结果；

如果所述第一查找结果表明所述第三缓存中有所述待加载的图片，则确定所述查找结果为所述第三缓存中有所述待加载的图片；

如果所述第一查找结果表明所述第三缓存中没有所述待加载的图片，则根据所述待加载的图片的URI查找第二缓存，得到第二查找结果；

如果所述第二查找结果表明所述第二缓存中有所述待加载的图片，则确定所述查找结果为所述第二缓存中有所述待加载的图片；

如果所述第二查找结果表明所述第二缓存中没有所述待加载的图片，则根据所述待加载的图片的URI查找第三缓存，得到第三查找结果；

如果所述第三查找结果表明所述第三缓存中有所述待加载的图片，则确定所述查找结果为所述第三缓存中有所述待加载的图片；

如果所述第二查找结果表明所述第二缓存中没有所述待加载的图片，则确定所述查找结果为所述第一缓存、所述第二缓存和第三缓存中均没有所述待加载的图片。

7.根据权利要求3所述的方法，其特征在于，所述如果下载成功，将已下载的图片按照URI为关键值进行缓存，包括：

如果下载成功，对所述已下载的图片进行预处理，其中所述预处理至少包括裁剪、解码；

将未解码的带有图片大小尺寸信息的图片存储在第二缓存中；

将已解码的图片信息通过匿名共享缓存缓存在虚拟机底层分配的堆内存中。

8.根据权利要求7所述的方法，其特征在于，所述第二缓存包括第一缓存池和第二缓存池，所述将未解码的带有图片大小尺寸信息的图片存储在第二缓存中，包括：

判断第一缓存池是否存满，如果未存满，则将未解码的带有图片大小尺寸信息的图片直接缓存到第一缓存池；

如果第一缓存池已经存满且第二缓存池未存满，将未解码的带有图片大小尺寸信息的图片直接将图片存储在第二缓存池中；

当第一和第二缓存池均存满，则判断第一和第二缓存池中是否有与所述已下载的图片具有相同图片内容但图片尺寸不同的图片；

如果第一和第二缓存池中有与所述已下载的图片具有相同图片内容但图片尺寸不同的图片，则将用所述未解码的带有图片大小尺寸信息的图片替换所述第一和第二缓存池中具有相同图片内容但图片尺寸不同的图片；

如果第一和第二缓存池中没有与所述已下载的图片具有相同图片内容但图片尺寸不同的图片，将第一、第二缓存池中的超过存活时间的图片全部移除，然后将所述未解码的带有图片大小尺寸信息的图片缓存在第一缓存池或第二缓存池。

9.根据权利要求6所述的方法，其特征在于，所述第二缓存包括第一子缓存和第二子缓存，其中第一子缓存用链式哈希图作为数据结构，第二子缓存使用并发哈希图，所述根据所述待加载的图片的URI查找第二缓存，得到第二查询结果，包括：

根据所述待加载的图片的URI查找第一子缓存；

如果第一子缓存有，则确定第二查询结果表明第二缓存中有所述待加载的图片；

如果第一子缓存没有，根据所述待加载的图片的URI查找第二子缓存；

如果所述第二子缓存有，则确定第二查询结果表明第二缓存中有所述待加载的图片；如果所述第二子缓存没有，则确定第二查询结果表明第二缓存中没有所述待加载的图片。

10.一种图片加载装置，其特征在于，所述装置包括检测单元、确定单元、判断单元、获取单元和加载单元，其中：

所述检测单元，用于在图片加载页面上检测是否有输入操作；

所述确定单元，用于如果检测到输入操作，确定所述输入操作的属性参数；

所述判断单元，用于判断所述属性参数是否大于预设的阈值；

所述获取单元，用于如果所述属性参数小于所述预设的阈值，按照预设的图片加载数量获取待加载的图片的URI；通过将所述待加载的图片的URI作为关键值，以关键值作为索引获取所述待加载的图片；

所述加载单元，用于在所述图片加载页面上加载获取的所述待加载的图片；

其中，所述获取单元包括第一获取模块、第二获取模块，所述第一获取模块，用于按照预设的图片加载数量获取所述待加载的图片的URI；所述第二获取模块，用于通过将所述待加载的图片的URI作为关键值，以关键值作为索引获取所述待加载的图片；

所述第二获取模块包括查询子模块、获取子模块，所述查询子模块，用于根据所述待加载的图片的URI查找第一缓存、第二缓存和第三缓存，得到查找结果；其中第一缓存用于缓存已解码的图片，所述第二缓存用于缓存未解码的图片，所述第三缓存用于缓存从所述述图片加载页面对应的服务器下载的原图；

所述获取子模块，用于如果所述查找结果表明所述第一缓存、所述第二缓存或所述第三缓存中有所述待加载的图片，从所述第一缓存、所述第二缓存或所述第三缓存中获取所述待加载的图片。

11.根据权利要求10所述的装置，其特征在于，所述获取单元还包括下载模块和缓存模块，其中：

所述下载模块，用于如果以关键值作为索引未获取到所述待加载的图片，根据所述待加载的图片的URI从所述图片加载页面对应的服务器上下载所述待加载的图片；

所述缓存模块，用于如果下载成功，将已下载的图片按照URI为关键值进行缓存。

12.根据权利要求10所述的装置，其特征在于，所述第二获取模块还包括确定子模块，其中：

所述确定子模块，用于如果所述查找结果表明所述第一缓存、所述第二缓存和所述第三缓存中均有所述待加载的图片，则确定为以关键值作为索引未获取到所述待加载的图片。

Images