图片加载的方法及终端

1.一种图片加载的方法，其特征在于，包括：
根据当前可用内存空间确定能够加载的图片的数目；
获取多个图片中从起始位置开始的所述数目的图片，其中，用户操作线程将符合加载上下限条件的所有图片列表添加到图片解析线程的任务队列中；以及
为所述获取的图片分配资源，使用所述资源预加载所述获取的图片，其中，所述图片解析线程为所述用户操作线程交给所述图片解析线程的任务队列中的所有图片列表项分配资源。
2.根据权利要求1所述的图片加载的方法，其特征在于，获取所述多个图片中从起始位置开始的所述数目的图片包括：在所述起始位置发生改变时，根据改变后的所述起始位置重新获取所述数目的图片。
3.根据权利要求2所述的图片加载的方法，其特征在于，所述起始位置发生改变通过以下方式至少之一：屏幕的滚动条通过快速按键或触摸的方式拖动、当前屏幕发生变换。
4.根据权利要求3所述的图片加载的方法，其特征在于，还包括：
在所述起始位置发生改变之后，确定在屏幕中按缩略图形式应该显示的新图片；
如果所述应该显示的新图片属于所述预加载的图片，则直接从所述预加载的图片显示所述应该显示的新图片。
5.根据权利要求2所述的图片加载的方法，其特征在于，使用所述资源预加载所述获取的图片之后，包括：回收在重新获取所述数目的图片之外的图片的分配资源。
6.根据权利要求1所述的图片加载的方法，其特征在于，所述数目大于当前屏幕显示的图片的数量。
7.根据权利要求1所述的图片加载的方法，其特征在于，所述起始位置通过图片目录中图片的列表项和/或屏幕的滚动条的位置来确定。
8.一种终端，其特征在于，包括：
确定模块，用于根据当前可用内存空间确定能够加载的图片的数目；
获取模块，用于获取多个图片中从起始位置开始的所述数目的图片，其中，用户操作线程将符合加载上下限条件的所有图片列表添加到图片解析线程的任务队列中；以及加载模块，用于为所述获取的图片分配资源，使用所述资源预加载所述获取的图片，其中，所述图片解析线程为所述用户操作线程交给所述图片解析线程的任务队列中的所有图片列表项分配资源。
9.根据权利要求8所述的终端，其特征在于，所述获取模块包括：更新单元，用于在所述起始位置发生改变时，根据改变后的所述起始位置重新获取所述数目的图片。
10.根据权利要求9所述的终端，其特征在于，所述更新单元还用于屏幕的滚动条通过快速按键或触摸的方式拖动、或者当前屏幕发生变换时所述起始位置发生改变。

图片加载的方法及终端 \n技术领域\n[0001] 本发明涉及通信领域，尤其是涉及一种图片加载的方法及终端。 背景技术\n[0002] 低速处理器和低内存的图像终端设备通常体型比较小，且方便移动，但它的数据处理能力比起普通的PC机来说，毕竟还是很有限的。因此，低速处理器和低内存的图像终端设备的数据处理能力只能通过合理地利用其有限的资源的方式来提升它先天的不足。 [0003] 现有的低速处理器和低内存图像终端设备(例如，手机)虽然可以通过多线程的图片加载，达到用户的操作无需等待图片加载的进行的目的，但是，都存在一些缺陷，具体地，有两种设计形式： \n[0004] (1)加载所有图片。用户在浏览图片时，没有图片加载的时延，有利于用户体验。\n但是，这种加载方式对终端的内存消耗特别大，对具有低速处理器和低内存的图像终端设备是不可取的。随着存储技术的不断发展，闪存(flash)容量会越来越大，用户存储的图片数目也可能会非常庞大，这样必将会出现终端死机的情况。 \n[0005] (2)只加载可见部分图片。这种加载方式的好处是可以大大节省了终端的资源，属于即用即加载的方式。但是，相应的缺点是其用户体验比较差，即，用户每次进行页面切换时，都需等待图片加载的执行，当图片文件比较大或者图片解析过程比较慢时，用户的等待时间也是相当可观的。 \n[0006] 综上所述，现有的低速处理器和低内存的图像终端设备上的图片加载方式是很不合理的，亟需进行优化。 \n[0007] 本发明的主要目的在于提供一种图片的加载方案，以至少解决上述问题。 [0008] 为了实现上述目的，根据本发明的一个方面，提供了一种图片加载的方法。 [0009] 根据本发明的图片加载的方法包括：根据当前可用内存空间确定能够加载的图片的数目；获取多个图片中从起始位置开始的数目的图片，其中，用户操作线程将符合加载上下限条件的所有图片列表添加到图片解析线程的任务队列中；以及为获取的图片分配资源，使用资源预加载获取的图片，其中，图片解析线程为用户操作线程交给图片解析线程的任务队列中的所有图片列表项分配资源。 \n[0010] 优选地，获取多个图片中从起始位置开始的数目的图片包括：在起始位置发生改变时，根据改变后的起始位置重新获取数目的图片。 \n[0011] 优选地，起始位置发生改变通过以下方式至少之一：屏幕的滚动条通过快速按键或触摸的方式拖动、当前屏幕发生变换。 \n[0012] 优选地，该方法还包括：在起始位置发生改变之后，确定在屏幕中按缩略图形式应该显示的新图片；如果应该显示的新图片属于预加载的图片，则直接从预加载的图片显示应该显示的新图片。 \n[0013] 优选地，使用资源预加载获取的图片之后，包括：回收在重新获取数目的图片之外的图片的分配资源。 \n[0014] 优选地，数目大于当前屏幕显示的图片的数量。 \n[0015] 优选地，起始位置通过图片目录中图片的列表项和/或屏幕的滚动条的位置来确定。 \n[0016] 为了实现上述目的，根据本发明的另一方面，还提供了一种终端。 [0017] 根据本发明的终端，包括：确定模块，用于根据当前可用内存空间确定能够加载的图片的数目；获取模块，用于获取多个图片中从起始位置开始的数目的图片，其中，用户操作线程将符合加载上下限条件的所有图片列表添加到图片解析线程的任务队列中；以及加载模块，用于为获取的图片分配资源，使用资源预加载获取的图片，其中，所述图片解析线程为所述用户操作线程交给所述图片解析线程的任务队列中的所有图片列表项分配资源。 [0018] 优选地，获取模块包括：更新单元，用于在起始位置发生改变时，根据改变后的起始位置重新获取数目的图片。 \n[0019] 优选地，更新单元还用于屏幕的滚动条通过快速按键或触摸的方式拖动、或者当前屏幕发生变换时起始位置发生改变。 \n[0020] 通过本发明，采用多线程的图片加载方式，利用用户的操作时间进行图片的预解析，解决了现有的低速处理器和低内存的图像终端设备加载所有图片内存消耗特别大和加载可见部分图片解析过程慢的问题，保证了用户在访问图片时图片数据资源已经就位，从而实现了用户在切换图片时的“零”时间等待及在预览图片时的不间断性，提升了用户体验，合理利用了系统资源。 \n[0021] 此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中： [0022] 图1是根据本发明实施例的终端的结构框图； \n[0023] 图2是根据本发明实施例的终端的优选结构框图； \n[0024] 图3是根据本发明实施例的图片加载的方法的流程图； \n[0025] 图4是根据本发明实施例的进入图片目录的流程图； \n[0026] 图5是根据本发明实施例的切换图片页面的流程图。 \n具体实施方式\n[0027] 下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。 \n[0028] 在实施例中，提供了一种终端。图1是根据本发明实施例的终端的结构框图，如图1所示，终端包括：确定模块12、获取模块14和加载模块16，下面对此终端进行详细的说明。 \n[0029] 终端确定模块12，该模块用于根据可用内存空间确定能够加载的图片的数目；获取模块14连接至确定模块12，用于获取多个图片中从起始位置开始的该数目的图片；以及加载模块16连接至获取模块14，用于为获取的图片分配资源，使用该资源预加载获取的图片。 \n[0030] 通过上述终端，可以利用用户的操作时间进行图片的预解析，解决了加载所有图片内存消耗特别大和加载可见部分图片解析过程慢的问题。 \n[0031] 图2是根据本发明实施例的终端的优选结构框图，如图2所示，获取模块14包括：\n更新单元142，用于在起始位置发生改变时，根据改变后的起始位置重新获取该数目的图片。 \n[0032] 优选地，更新单元142还用于屏幕的滚动条通过快速按键或触摸的方式拖动、或者当前屏幕发生变换时起始位置发生改变。也就是说，屏幕的滚动条通过快速按键或触摸的方式拖动，或者其他可以使当前屏幕发生变换的行为(例如，采用传感器的重力感应方式)都可以触发起始位置的改变。 \n[0033] 在实施例中，对应于上述的终端，提供了一种图片加载的方法，图3是根据本发明实施例的图片加载的方法的流程图，如图3所示，该方法包括如下步骤： \n[0034] 步骤S302，根据可用内存空间确定能够加载的图片的数目； \n[0035] 步骤S304，获取多个图片中从起始位置开始的上述数目的图片；以及 [0036] 步骤S306，为获取的图片分配资源，使用该资源预加载获取的图片。 [0037] 通过上述方法，保证了用户在访问图片时图片数据资源已经就位，实现了用户在切换图片时的“零”时间等待及在预览图片时的不间断性。 \n[0038] 优选地，步骤S302中的能够加载的图片数目可以大于当前屏幕显示的图片的数量。该方法使得在屏幕滚动时，新出现在屏幕的图片无需等待重新加载，可以直接看到显示的图片，提高了用户体验。 \n[0039] 优选地，在步骤S304中，在起始位置发生改变时，根据改变后的起始位置重新获取上述数目的图片，例如，屏幕的滚动条通过快速按键或触摸的方式拖动，或者其他可以使当前屏幕发生变换的行为(例如，采用传感器的重力感应方式)都可以触发起始位置发生改变；另外，起始位置可以通过图片目录中图片的列表项和/或屏幕的滚动条的位置(或者其他可以唯一地表征列表项位置的参数)来确定。该方法明确了重新加载图片数目的时机，使得上述数目可以根据内存的使用情况动态更改，增加了系统的灵活性。 [0040] 优选地，在起始位置发生改变之后，确定在屏幕中按缩略图形式应该显示的新图片；如果应该显示的新图片属于预加载的图片，则直接从预加载的图片显示应该显示的新图片。该方法使得在图片在以缩略图形式显示时，通过快速按键或触摸的方式拖动屏幕滚动条时，用户可以无需等待地直接看到显示图片，增强了用户体验。 \n[0041] 优选地，可以在步骤S306之后回收在重新获取上述数目的图片之外的图片的分配资源。该方法提高了内存的利用率和系统性能。 \n[0042] 上述步骤S302至步骤S306可以采用多线程预加载和内存管理的方式来完成，主要包括两个线程：线程1，负责响应用户的操作，在整个操作过程中充当控制角色；线程2，负责图片的加载处理，在整个过程中是执行单元。两者相辅相成，通过同步机制，共同配合完成图片的预处理过程和终端的内存的管理。 \n[0043] 具体地，线程1对用户的操作指令进行解析，根据符合图片加载上下限条件的每一个图片列表项的属性，分别为它们分配一个任务，并通过同步机制将这一任务添加到线程2的队列中，交给线程2来处理。与此同时，线程1对不符合加载上下限条件、但又已经分配了系统资源的图片列表项的资源进行回收。然后，线程1继续监控用户动作和线程2返回的处理结果，并对任务结果进行处理。 其中，线程2的任务很简单，是通过同步机制来处理自己队列中的一个个图片解析请求，并在图片解析处理完毕后，通知线程1图片解析处理的结果信息。需要说明的是，上述图片加载上下限是指软件中约定的、需要图片解析函数处理的、在图片目录列表中的上限至下限的范围，即，图片目录列表中需要进行图片解析处理的图片列表项。 \n[0044] 下面对本发明技术方案的具体实施例做进一步的详细描述。 \n[0045] 优选实例一 \n[0046] 图4是根据本发明实施例的进入图片目录的流程图，如图4所示，当用户首次进入图片文件目录时，根据当前内存的大小以及使用情况确定加载的上下限，线程1(用户操作线程)开始将符合加载上下限条件的所有图片列表项添加到线程2(图片解析线程)的任务队列中；线程2为线程1交给它的任务队列中的所有图片列表项分配资源，并进行解析处理(由于加载图片需要片刻的时间，此刻可以在屏幕上添加一个漂亮的等待图片以增加用户体验)，同时，将不在此加载上下限中的已分配资源进行回收，等待解析任务完毕，通知线程1释放等待图片，显示加载完毕的图片。与此同时，设置一个监视器，定期对内存使用情况进行监测，一旦内存变化达到本发明实施例设计方案的监测算法中的门限值时，系统更新上述加载上下限值，实现自适应的图片预加载。 \n[0047] 如图4所示，根据本发明实施例的初始进入图片目录的系统的处理，是基于一个GUI图形操作系统来实现，该流程主要包括以下处理(步骤S401-步骤S409)： [0048] 步骤S401，进入图片目录。 \n[0049] 步骤S402，加载等待图片。 \n[0050] 步骤S403，创建列表窗口并进行相关参数初始化工作。文件管理模块创建图片明细ComplexList列表窗口，然后，对ComplexList列表控件和ScrollBar滚动条控件的位置参数进行初始化。ComplexList控件为它的每个列表项分配一段附加数据，保存图片文件的相关信息，其中，最重要的信息就是图片文件在flash中的路径。ScrollBar滚动条控件也将其位置参数初始值置为0，表示当前页面是整个软件ComplexList列表的第1屏。 [0051] 步骤S404，遍历所有图片列表项，动态确定图片加载数目。首先，计算内存的总容量和当前内存的使用情况，根据这两个因素动态确定图片加载数目门限值(能够加载的图片的数目)，即，根据内存的总容量和内存的消耗情况动态设置图片加载数目门限值。需要说明的是，虽然图片加载数目是动态设置的，但是为了保证用户体验，本发明实施例还设定了一个最低预加载数目，其中，这个最低预加载值一定是大于当前屏幕显示个数的，当内存使用达到极限时，提示用户“内存不足”。 \n[0052] 步骤S405，确定图片加载上下限，判断当前项是否符合加载上下限条件。根据ScrollBar滚动条控件的位置参数来确定ComplexList列表控件的列表项图片加载上下限，并判断当前项是否符合加载上下限条件。由于刚进入目录，聚焦项肯定是第1项。因此，假设此时动态设置的图片加载数目为9，那么需要加载ComplexList列表控件中索引值为1、2、3、4、5、6以及的最后3个的列表项，其中，这里的加载图片的数目为9，即，有9个图片列表项需要加载。 \n[0053] 步骤S406，将符合加载上下限的图片解析任务加入线程2队列中。在确定了图片加载上下限之后，便可以开始将符合加载上下限的图片的相关信息(例如，图片在文件系统中的路径)附加到线程2的队列中，等待线程2的处理和返回。为了提升用户感官体验，此时可以加载系统中预置的漂亮的等待位图(可以提升加载速度， 使得加载的位图无需再做解析便可以直接使用)，并且可以设定一个指示变量值用来指示当前的图片加载数目，等待图片解析线程的处理结果，一旦解析完毕一个图片，指示变量就减1，直到该变量值为\n0，这时候解除等待图片，显示当前目录第1屏，其中，在等待图片期间，如果用户点击上下键，系统将不会对此做出响应。 \n[0054] 步骤S407，线程1对不符合加载上下限条件、但又已经分配了系统资源的图片列表项的资源进行回收。 \n[0055] 步骤S408，线程2通过同步机制来处理自己队列中的一个个图片解析请求，并在图片解析处理完毕后，通知线程1图片解析处理的结果信息。 \n[0056] 步骤S409，线程1监控用户动作和线程2返回的处理结果，并对任务结果进行处理。 \n[0057] 优选实例二 \n[0058] 图5是根据本发明实施例的切换图片页面的流程图，如图5所示，在图片目录下，用户点击上下键切换页面，线程1将符合加载上下限条件的列表项通过线程同步机制添加到线程2的队列中，同时，对不符合加载上下线条件但已经分配系统资源的图片列表项的系统资源进行释放；线程2对来自线程1的图片解析请求队列中的任务进行处理，并将处理结果及时反馈给线程1；线程1实时监控线程2的处理结果，在收到线程2的处理结果后，将分配好系统资源的图片指定到绘制句柄上，并在用户切换到图片所在页面时，负责将图片绘制出来。 \n[0059] 需要说明的是，本发明的实施例的图片列表中可以存在缩略图，且快速按键、拖动滚动条或者当前屏幕发生变换(例如，采用传感器的重力感应)时存在某些项临时进行加载。通过内存检测工具， 检测进入图片列表前后剩余内存空间的差值，且与图片列表中所有图片的占用的内存空间值作比对，可以得出剩余内存空间的差值远远大于所有图片占用的内存空间值。 \n[0060] 如图5所示，根据本发明实施例的切换图片页面的处理，该流程主要包括以下处理(步骤S501-步骤S508)： \n[0061] 步骤S501，切换页面。由于该方法支持触摸屏，所以，用户可以通过按上下键或触摸滚动条的方式切换图片页面。 \n[0062] 步骤S502，系统参数更新。对ComplexList列表控件和ScrollBar滚动条控件的位置参数进行更新。 \n[0063] 步骤S503，遍历所有图片列表项，动态确定图片加载数目。具体步骤同优选实施例一的步骤S404。 \n[0064] 步骤S504，确定图片加载上下限，判断当前项是否符合加载上下限条件。具体步骤同优选实施例一的步骤S405。用户按键或者触摸滚动条触发图片加载上下限更新。在用户按上下键和触摸滚动条的上下键以及拖动滚动条时均会触发当前页面的改变，因此，可以自定义PageChange事件，当用户按上下键和触摸滚动条等操作时触发该事件，并在消息映射函数中根据ComplexList列表控件的位置参数来确定新的图片加载上下限。 [0065] 步骤S505，将新的符合加载上下限的图片解析任务加入线程2队列中，同时将不在加载上下限但占有系统资源的图片进行释放。 \n[0066] 步骤S506，线程1对不符合加载上下限条件、但又已经分配了系统资源的图片列表项的资源进行回收。 \n[0067] 在图片目录下，用户触摸滚动条切换页面，这时线程1开始将符合加载上下限条件的列表项通过线程同步机制添加到线程2的队列中，线程1对不符合加载上下线条件但已经分配系统资源的列表项释放系统资源。但是，由于触摸滚动条切换页面速度很快，远远超过图片解析速度，这样每当滚动条有一次最小移动(是指的是在拖动滚动条时触发滚动条事件移动最小距离)，都会改变图片加载上下限。因此，会存在很多符合加载条件的列表项，线程1会将它们添加到线程2的解析队列中。但是，由于切换速度很快，可能刚刚还符合加载条件并已经添加到线程2队列中的任务现在已经不满足加载上下限条件了，所以，如果让线程2对这些任务进行处理，只会白白浪费了宝贵的处理器和内存资源，无法让需要解析的任务得到及时地处理，而且可能导致内存泄露。因此，为了更好地支持用户体验，线程1负责将已经加入到线程2队列中还未处理但当前又不满足加载条件的项任务取消，这样就能够保证线程2处理的任务总是有效的。 \n[0068] 步骤S 507，线程2通过同步机制来处理自己队列中的一个个图片解析请求，并在图片解析处理完毕后，通知线程1图片解析处理的结果信息。 \n[0069] 步骤S508，线程1监控用户动作和线程2返回的处理结果，并对任务结果进行处理。例如，加载图片。 \n[0070] 优选实例三 \n[0071] 在图片加载期间，退出页面时系统的处理，该流程主要包括以下处理： [0072] 步骤1，动态确定图片加载数目，具体步骤同优选实施例一的步骤S404。 [0073] 步骤2，用户退出当前页面触发图片加载上下限更新。 \n[0074] 步骤3，线程1将符合加载上下限的列表项相关信息添加到线程2的队列中。 [0075] 步骤4，在所有图片解析任务还未执行完成前退出当前页面，此时，会触发SelectedChange事件，在SelectedChange事件的消息映射函数中主动触发PageChange事件，并在消息映射函数中根据ComplexList列表控件的位置参数来确定新的图片加载上下限。 \n[0076] 步骤3，通知线程2取消不在图片加载上下限中的解析任务。如果存在某些ComplexList列表项没有占用系统资源、但是在线程2的处理队列中，那么需要向线程2发送一个信号，用以说明该项已经被取消解析，命令图片解析线程在遇到该项时跳过处理并释放系统资源。 \n[0077] 需要说明的是，在优选实施例二中快速按上下键和拖动滚动条显示时也会导致图片加载上下限的改变，也会出现处于线程2队列中但是已经不在图片加载上下限中的图片解析任务，此时，也按照该步骤3的情况进行处理。 \n[0078] 综上所述，鉴于现有的低速处理器和低内存图像终端设备的两种设计形式，本发明提出了一种折中的方案，采用多线程的图片加载方式，利用用户的操作时间进行图片的预解析，保证了用户在访问图片时图片数据资源已经就位，提高了系统的性能。从用户体验设计的理念层面增加了用户对产品的认知度，为用户创造良好的人机界面。同时，本发明的技术方案在多线程调度和内存管理上面也有不逊于第一种加载方式的高效和不逊于第二种加载方式的灵活。 \n[0079] 显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算 装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。 [0080] 以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。