图片解码方法和装置与流程

本发明涉及图片处理领域，特别是涉及一种图片解码方法和装置。

背景技术：

随着计算机技术和网络技术的发展，越来越多的用户使用终端拍摄图片或绘制图片上传到网络中，以分享给其他用户观赏。用户使用终端浏览图片时，终端上的解码程序会对图片进行解码，解码后的bitmap(位图)在系统内存不足时会自动被收回。当系统需要再次访问该被回收的bitmap时，会由主线程进行匆忙解码，如此主线程被阻塞，导致画面卡顿。

技术实现要素：

基于此，有必要针对传统的图片被回收后再次被访问解码时造成主线程阻塞，画面卡顿的问题，提供一种图片解码方法和装置，能避免被回收的位图被再次访问造成主线程阻塞，避免了画面卡顿，提高了画面的流畅度。

一种图片解码方法，包括：

若操作系统支持inPurgeable且inPurgeable属性为真，则获取目标图片；

锁定所述目标图片在原生层共享内存对应的内存区域；

采用inPurgeable对所述目标图片进行解码。

一种图片解码装置，包括：

第一获取模块，用于若操作系统支持inPurgeable且inPurgeable属性为真，则获取目标图片；

锁定模块，用于锁定所述目标图片在原生层共享内存对应的内存区域；

第一解码模块，用于采用inPurgeable对所述目标图片进行解码。

上述图片解码方法和装置，若操作系统支持inPurgeable且inPurgeable属性为真，采用inPurgeable解码目标图片时，提前锁定目标图片在原生层共享内存对应的内存区域，确保它不会被自动解锁，如此能够避免在共享内存中的bitmap被回收，从而被匆忙解码，造成主线程阻塞的问题，避免了画面卡顿，提高了画面的流畅度。

附图说明

图1A为一个实施例中终端的内部结构示意图；

图1B为一个实施例中服务器的内部结构示意图；

图2为一个实施例中图片解码方法的流程图；

图3为另一个实施例中图片解码方法的流程图；

图4为一个实施例中遍历可重用图片集合得到本次可重用图片的流程图；

图5为一个实施例中图片解码装置的结构框图；

图6为另一个实施例中图片解码装置的结构框图；

图7为另一个实施例中图片解码装置的结构框图；

图8为另一个实施例中图片解码装置的结构框图；

图9为另一个实施例中图片解码装置的结构框图；

图10为另一个实施例中图片解码装置的结构框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

图1A为一个实施例中终端(或电子设备等)的内部结构示意图。如图1A所示，该终端包括通过系统总线连接的处理器、非易失性存储介质、内存储器、网络接口、显示屏和输入装置。其中，终端的非易失性存储介质存储有操作系统，还包括一种图片解码装置，该图片解码装置用于实现一种图片解码方法。该处理器用于提供计算和控制能力，支撑整个终端的运行。终端中的内存储器为非易失性存储介质中的图片解码装置的运行提供环境，该内存储器中可储存有计算机可读指令，该计算机可读指令被所述处理器执行时，可使得所述处理器执行一种图片解码方法。网络接口用于与服务器或其他设备进行网络通信等。终端的显示屏可以是液晶显示屏或者电子墨水显示屏等，输入装置可以是显示屏上覆盖的触摸层，也可以是终端外壳上设置的按键、轨迹球或触控板，也可以是外接的键盘、触控板或鼠标等。该终端可以是手机、平板电脑或者个人数字助理或穿戴式设备或阅读器等。本领域技术人员可以理解，图1A中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的终端的限定，具体的终端可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

图1B为一个实施例中服务器(或云端等)的内部结构示意图。如图1B所示，该服务器包括通过系统总线连接的处理器、非易失性存储介质、内存储器和网络接口。其中，该服务器的非易失性存储介质存储有操作系统、数据库和图片解码装置，数据库中存储有图片，该图片解码装置用于实现适用于服务器的一种图片解码方法。该服务器的处理器用于提供计算和控制能力，支撑整个服务器的运行。该服务器的内存储器为非易失性存储介质中的图片解码装置的运行提供环境，该内存储器中可储存有计算机可读指令，该计算机可读指令被所述处理器执行时，可使得所述处理器执行一种图片解码方法。该服务器的网络接口用于据以与外部的终端或其他服务器通过网络连接通信等。服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。本领域技术人员可以理解，图1B中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的服务器的限定，具体的服务器可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

图2为一个实施例中图片解码方法的流程图。如图2所示，一种图片解码方法，可运行于终端或服务器，包括：

步骤202，若操作系统支持inPurgeable且inPurgeable属性为真，则获取目标图片。

在终端和服务器上均安装有操作系统。不同版本的操作系统支持的功能不同。以Android操作系统为例，从Android操作系统1.6版本开始支持inPurgeable功能。inPurgeable属性为真，则表示bitmap(图片)是可清除的。使用inPurgeable解码的图片存在于native(原生)层的一块共享内存中。通过管理好共享内存中的bitmap位图，保证它不会被内存泄漏，就不必担心解码bitmap造成的GC(Garbage Collection，垃圾回收)。

inPurgeable是用来表示使用BitmapFactory创建的Bitmap是否可以被回收的。若inPurgeable设为True(真)的话表示使用BitmapFactory创建的bitmap用于存储Pixel的内存空间在系统内存不足时可以被回收，在应用需要再次访问bitmap的Pixel时(如绘制bitmap或是调用getPixel)，系统会再次调用BitmapFactory decoder重新生成bitmap的Pixel数组。目标图片是指待解码的图片。目标图片可从网络或本地获取。用户可使用终端连接网络，在线浏览图片，浏览的图片需要先解码，则将待浏览的图片作为目标图片。用户也可浏览终端上(即本地)的图片，浏览过程中图片显示，需要进行解码，则将待浏览的图片作为目标图片。

步骤204，锁定该目标图片在原生层共享内存对应的内存区域。

因使用inPurgeable创建的位图可能随时会被系统回收，为此，在使用inPurgeable解码图片时，提前锁定该目标图片在原生层共享内存对应的内存区域，且确保它不会被自动解锁。

本实施例中，若操作系统为Android操作系统，则采用AndroidBitmap_lockPixels函数来pin(锁定)目标图片在原生层共享内存对应的内存区域。AndroidBitmap_lockpixels函数是对bitmap进行加锁、互斥使用资源。

步骤206，采用inPurgeable对该目标图片进行解码。

若inPurgeable设为True(真)的话表示使用BitmapFactory创建的bitmap用于存储Pixel的内存空间在系统内存不足时可以被回收，在应用需要再次访问bitmap的Pixel时(如绘制bitmap或是调用getPixel)，系统会再次调用BitmapFactory decoder重新生成bitmap的Pixel数组。为了能够重新解码图像，bitmap要能够访问存储bitmap的原始数据。通过BitmapFactory创建的bitmap对目标图片进行解码。

上述图片解码方法，若操作系统支持inPurgeable且inPurgeable属性为真，采用inPurgeable解码目标图片时，提前锁定目标图片在原生层共享内存对应的内存区域，确保它不会被自动解锁，如此能够避免在共享内存中的bitmap被回收，从而被匆忙解码，造成主线程阻塞的问题，避免了画面卡顿，提高了画面的流畅度。

在一个实施例中，在步骤206之后，上述图片解码方法还包括：对解码出来的目标图片进行封装。

因bitmap在原生共享内存中，它不受虚拟机的控制，容易发生内存泄漏。为此采用closableBitmap对解码出来的目标图片进行封装，可以保证虚拟机在回收closableBitmap对象时，closableBitmap对象包含的bitmap也能被回收，防止发生内存泄漏。

在一个实施例中，在对解码出来的目标图片进行封装之后，上述图片解码方法还包括：对解码出来的目标图片进行引用计数，得到各个目标图片对应的引用计数；当该各个目标图片对应的引用计数为零时，调用释放资源函数，回收目标图片。

本实施例中，在java层提供类似于C++智能指针的方式对目标图片进行引用计数。closableBitmap对图片进行引用计数，得到各个目标图片对应的引用计数。当closableBitmap的引用计数变为0时，调用referencerelease释放资源函数释放资源，并调用bitmap.recycle()，回收bitmap。

图3为另一个实施例中图片解码方法的流程图。如图3所示，一种图片解码方法，包括：

步骤302，检测操作系统是否支持inPurgeable且inPurgeable属性为真，若是，执行步骤304，若否，执行步骤310。

在终端和服务器上均安装有操作系统。不同版本的操作系统支持的功能不同。以Android操作系统为例，从Android操作系统1.6版本开始支持inPurgeable功能。inPurgeable属性为真，则表示bitmap(图片)是可清除的。使用inPurgeable解码的图片存在于native(原生)层的一块共享内存中。通过管理好共享内存中的bitmap位图，保证它不会被内存泄漏(OOM，Out Of Memory)，就不必担心解码bitmap造成的GC(Garbage Collection，垃圾回收)。Andorid5.0及以上版本不支持inPurgeable，支持inBitmap。

若操作系统不支持inPurgeable，且支持inBitmap，则遍历可重用图片集合得到本次可重用图片，采用该本次可重用图片对该目标图片进行解码。其中，inBitmap是可以复用图片，inBitmap指向缓存中的图片。支持inBitmap是指支持复用内存块，不需要在重新给该bitmap申请一块新的内存，避免了一次内存的分配和回收，从而改善了运行效率。

步骤304，获取目标图片，然后执行步骤306。

具体地，目标图片是指待解码的图片。目标图片可从网络或本地获取。用户可使用终端连接网络，在线浏览图片，浏览的图片需要先解码，则将待浏览的图片作为目标图片。用户也可浏览终端上(即本地)的图片，浏览过程中图片显示，需要进行解码，则将待浏览的图片作为目标图片。

采用BitmapFactory.DecodeByteArray(options.inJustDecodeBounds＝true)，获取目标图片的尺寸。

步骤306，锁定该目标图片在原生层共享内存对应的内存区域，然后执行步骤308。

因使用inPurgeable创建的位图可能随时会被系统回收，为此，在使用inPurgeable解码图片时，提前锁定该目标图片在原生层共享内存对应的内存区域，且确保它不会被自动解锁。

步骤308，采用inPurgeable对该目标图片进行解码，然后执行步骤316。

步骤310，获取目标图片，然后执行步骤312。

具体地，目标图片是指待解码的图片。目标图片可从网络或本地获取。用户可使用终端连接网络，在线浏览图片，浏览的图片需要先解码，则将待浏览的图片作为目标图片。用户也可浏览终端上(即本地)的图片，浏览过程中图片显示，需要进行解码，则将待浏览的图片作为目标图片。

步骤312，遍历可重用图片集合得到本次可重用图片。

具体地，可重用图片集合用于收集使用过的图片。等到新的图片需要解码时，可以从可重用图片集合中获取本次可重用图片。本次可重用图片是指本次能够用来解码的且在本次解码之前已使用过的图片。

步骤314，采用该本次可重用图片对该目标图片进行解码，然后执行步骤316。

具体地，采用本次可重用图片对目标图片进行解码主要是采用本次可重用图片的重用内存块供目标图片进行解码，不需要再为该目标图片分配新的内存块。采用BitmapFactory.DecodeByteArray表示解码图片，采用options.inBitmap＝reuseBitmap表示复用之前的bitmap来解码。

步骤316，对解码出来的目标图片进行封装。

具体地，因bitmap在原生共享内存中，它不受虚拟机的控制，容易发生内存泄漏。为此采用closableBitmap对解码出来的目标图片进行封装，可以保证虚拟机在回收closableBitmap对象时，closableBitmap对象包含的bitmap也能被回收，防止发生内存泄漏。

步骤318，对解码出来的目标图片进行引用计数，得到各个目标图片对应的引用计数。

具体地，在java层提供类似于C++智能指针的方式对目标图片进行引用计数。closableBitmap对图片进行引用计数，得到各个目标图片对应的引用计数。

步骤320，当该各个目标图片对应的引用计数为零时，调用释放资源函数，回收目标图片。

具体地，当closableBitmap的引用计数变为0时，调用referencerelease释放资源函数释放资源，并调用bitmap.recycle()，回收bitmap。

上述图片解码方法，若操作系统支持inPurgeable且inPurgeable属性为真，采用inPurgeable解码目标图片时，提前锁定目标图片在原生层共享内存对应的内存区域，确保它不会被自动解锁，如此能够避免在共享内存中的bitmap被回收，从而被匆忙解码，造成主线程阻塞的问题，避免了画面卡顿，提高了画面的流畅度；若操作系统不支持inPurgeable，遍历可重用图片集合得到本次可重用图片，采用本次可重用图片对目标图片进行解码，因采用可重用图片解码不会造成线程阻塞，避免了画面卡顿，提高了画面的流畅度；对解码后的目标图片进行封装，防止了目标图片不受控制而导致的内存泄漏，通过对图片进行引用计数，进一步确保不会发生内存泄漏。

在其他实施例中，步骤316、318和320可省略，或者包括步骤316等所有可能的组合。

在一个实施例中，如图4所示，遍历可重用图片集合得到本次可重用图片的步骤包括：

步骤402，遍历可重用图片集合，从可重用图片集合中获取一个可重用图片及对应的尺寸。

具体地，采用BitmapFactory.DecodeByteArray(options.inJustDecodeBounds＝true)，获取一个可重用图片的尺寸。可重用图片的尺寸的长度和宽度可采用像素点数表示，如100*100等。

步骤404，获取该目标图片的尺寸，将该目标图片的尺寸与该可重用图片的尺寸比较。

具体地，采用BitmapFactory.DecodeByteArray(options.inJustDecodeBounds＝true)，获取目标图片的尺寸。

目标图片的尺寸的长度和宽度可采用像素点数表示。

步骤406，若该目标图片的尺寸小于或等于该可重用图片的尺寸，则将该可重用图片作为本次可重用图片。

采用needDecodeByteCount<＝ReuseBitmapByteCount表示目标图片的尺寸需满足小于或等于该可重用图片的尺寸的条件。

步骤408，若该目标图片的尺寸大于该可重用图片的尺寸，则返回步骤402。

具体地，若该目标图片的尺寸大于该可重用图片的尺寸，重新遍历所述可重用图片集合，从该可重用图片集合中获取下一个可重用图片及对应的尺寸，将所述目标图片的尺寸与所述下一个可重用图片的尺寸比较，若所述目标图片的尺寸小于或等于所述下一个可重用图片的尺寸，则将所述下一个可重用图片作为本次可重用图片，若目标图片的尺寸大于该下一个可重用图片的尺寸，则再重新遍历所述可重用图片集合，从该可重用图片集合中获取下一个可重用图片及对应的尺寸，将所述目标图片的尺寸与所述下一个可重用图片的尺寸比较，若所述目标图片的尺寸小于或等于所述下一个可重用图片的尺寸，则将所述下一个可重用图片作为本次可重用图片，直到遍历得到本次可重用图片。

通过遍历可重用图片集合，从中筛选得到尺寸大于目标图片尺寸的可重用图片，从而满足解码需求。

在一个实施例中，若操作系统支持inBitmap，且要求目标图片与可重用图片尺寸完全一致，则获取二维向量图形处理函数库地址，对该二维向量图形处理函数库的内存空间以预设字节为步长进行遍历，查找到与所述目标图片尺寸参数的字段，将所述目标图片尺寸参数的字段修改为可重用图片尺寸；采用本次可重用图片对修改过尺寸参数的目标图片进行解码。

因Android操作系统的3.0版本至4.4版本之间必须满足所解码的图片必须与重用的图片的位图大小完全一致，故通过hack方式修改底层的skiaBitmap结构，实现对图片的解码。

获取skiaBitmap(二维向量图形处理函数库)地址后，对其内存空间以预设字节为步长进行遍历，直至找到与目标图片原始RowBytes/Width/Height相等的三个uint32的字段，通过hack方式将这三个字段分别修改成新的RowBytes/Width/Height即可。新的RowBytes/Width/Height即为可重用图片尺寸。预设字节可为4字节、8字节或16字节等。

通过修改目标图片的尺寸参数，实现了可重用图片对目标图片的解码。

图5为一个实施例中图片解码装置的结构框图。如图5所示，一种图片解码装置，包括第一获取模块502、锁定模块504和第一解码模块506。其中：

第一获取模块，用于若操作系统支持inPurgeable且inPurgeable属性为真，则获取目标图片。

在终端和服务器上均安装有操作系统。不同版本的操作系统支持的功能不同。以Android操作系统为例，从Android操作系统1.6版本开始，支持一个名为inPurgeable，inPurgeable属性为真，则表示bitmap(图片)是可清除的。使用inPurgeable解码的图片存在于native(原生)层的一块共享内存中。通过管理好共享内存中的bitmap位图，保证它不会被内存泄漏，就不必担心解码bitmap造成的GC。目标图片是指待解码的图片。目标图片可从网络或本地获取。用户可使用终端连接网络，在线浏览图片，浏览的图片需要先解码，则将待浏览的图片作为目标图片。用户也可浏览终端上(即本地)的图片，浏览过程中图片显示，需要进行解码，则将待浏览的图片作为目标图片。

锁定模块504用于锁定所述目标图片在原生层共享内存对应的内存区域。

若操作系统为Android操作系统，则采用AndroidBitmap_lockPixels函数来pin(锁定)目标图片在原生层共享内存对应的内存区域。AndroidBitmap_lockpixels函数是对bitmap进行加锁、互斥使用资源。

第一解码模块506用于采用inPurgeable对该目标图片进行解码。

上述图片解码装置，若操作系统支持inPurgeable且inPurgeable属性为真，采用inPurgeable解码目标图片时，提前锁定目标图片在原生层共享内存对应的内存区域，确保它不会被自动解锁，如此能够避免在共享内存中的bitmap被回收，从而被匆忙解码，造成主线程阻塞的问题，避免了画面卡顿，提高了画面的流畅度。

图6为另一个实施例中图片解码装置的结构框图。如图6所示，一种图片解码装置，除了包括第一获取模块502、锁定模块504和第一解码模块506，还包括第二获取模块508、遍历模块510和第二解码模块512。其中：

第二获取模块508用于若所述操作系统不支持inPurgeable，则获取目标图片。

遍历模块510用于遍历可重用图片集合得到本次可重用图片。

具体地，可重用图片集合用于收集使用过的图片。等到新的图片需要解码时，可以从可重用图片集合中获取本次可重用图片。本次可重用图片是指本次能够用来解码的且在本次解码之前已使用过的图片。

第二解码模块512用于采用该本次可重用图片对所述目标图片进行解码。

具体地，采用本次可重用图片对目标图片进行解码主要是采用本次可重用图片的重用内存块供目标图片进行解码，不需要再为该目标图片分配新的内存块。采用BitmapFactory.DecodeByteArray表示解码图片，采用options.inBitmap＝reuseBitmap表示复用之前的bitmap来解码。

上述图片解码装置，若操作系统支持inPurgeable且inPurgeable属性为真，采用inPurgeable解码目标图片时，提前锁定目标图片在原生层共享内存对应的内存区域，确保它不会被自动解锁，如此能够避免在共享内存中的bitmap被回收，从而被匆忙解码，造成主线程阻塞的问题，避免了画面卡顿，提高了画面的流畅度；若操作系统不支持inPurgeable，遍历可重用图片集合得到本次可重用图片，采用本次可重用图片对目标图片进行解码，因采用可重用图片解码不会造成线程阻塞，避免了画面卡顿，提高了画面的流畅度。

图7为一个实施例中遍历模块的内部结构框图。如图7所示，遍历模块510包括遍历单元5102、比较单元5104和选定单元5106。

遍历单元5102用于遍历可重用图片集合，从可重用图片集合中获取一个可重用图片及对应的尺寸。可重用图片的尺寸的长度和宽度可采用像素点数表示，如100*100等。

比较单元5104用于获取该目标图片的尺寸，将所述目标图片的尺寸与所述可重用图片的尺寸比较。目标图片的尺寸的长度和宽度可采用像素点数表示。

选定单元5106用于若所述目标图片的尺寸小于或等于所述可重用图片的尺寸，则将所述可重用图片作为本次可重用图片。

遍历单元5102还用于若所述目标图片的尺寸大于所述可重用图片的尺寸，则重新遍历所述可重用图片集合，从所述可重用图片集合中获取下一个可重用图片及对应的尺寸。

比较单元5104还用于将所述目标图片的尺寸与所述下一个可重用图片的尺寸比较；

选定单元5106还用于若所述目标图片的尺寸小于或等于所述可重用图片的尺寸，则将所述可重用图片作为本次可重用图片。

具体地，若该目标图片的尺寸大于该可重用图片的尺寸，重新遍历所述可重用图片集合，从该可重用图片集合中获取下一个可重用图片及对应的尺寸，将所述目标图片的尺寸与所述下一个可重用图片的尺寸比较，若所述目标图片的尺寸小于或等于所述下一个可重用图片的尺寸，则将所述下一个可重用图片作为本次可重用图片，若目标图片的尺寸大于该下一个可重用图片的尺寸，则再重新遍历所述可重用图片集合，从该可重用图片集合中获取下一个可重用图片及对应的尺寸，将所述目标图片的尺寸与所述下一个可重用图片的尺寸比较，若所述目标图片的尺寸小于或等于所述下一个可重用图片的尺寸，则将所述下一个可重用图片作为本次可重用图片，直到遍历得到本次可重用图片。

通过遍历可重用图片集合，从中筛选得到尺寸大于目标图片尺寸的可重用图片，从而满足解码需求。

图8为另一个实施例中图片解码装置的结构框图。如图8所示，一种图片解码装置，除了包括第一获取模块502、锁定模块504和第一解码模块506，还包括封装模块514。其中：

封装模块514用于对解码出来的目标图片进行封装。

具体地，因bitmap在原生共享内存中，它不受虚拟机的控制，容易发生内存泄漏。为此采用closableBitmap对解码出来的目标图片进行封装，可以保证虚拟机在回收closableBitmap对象时，closableBitmap对象包含的bitmap也能被回收，防止发生内存泄漏。

对解码后的目标图片进行封装，防止了目标图片不受控制而导致的内存泄漏。

图9为另一个实施例中图片解码装置的结构框图。如图9所示，一种图片解码装置，除了包括第一获取模块502、锁定模块504、第一解码模块506、封装模块514，还包括计数模块516和调用模块518。其中：

计数模块516用于对解码出来的目标图片进行引用计数，得到各个目标图片对应的引用计数。

调用模块518用于当所述各个目标图片对应的引用计数为零时，调用释放资源函数，回收目标图片。

通过对图片进行引用计数，进一步确保不会发生内存泄漏。

图10为另一个实施例中图片解码装置的结构框图。如图10所示，一种图片解码装置，除了包括第一获取模块502、锁定模块504、第一解码模块506、第二获取模块508、遍历模块510和第二解码模块512，还包括修改模块520。

修改模块520用于若该操作系统支持inBitmap，且要求目标图片与可重用图片尺寸完全一致，则获取二维向量图形处理函数库地址，对所述二维向量图形处理函数库的内存空间以预设字节为步长进行遍历，查找到与所述目标图片尺寸参数的字段，将所述目标图片尺寸参数的字段修改为本次可重用图片尺寸。

第二解码模块512还用于采用本次可重用图片对修改过尺寸参数的目标图片进行解码。

具体地，获取skiaBitmap(二维向量图形处理函数库)地址后，对其内存空间以预设字节为步长进行遍历，直至找到与目标图片原始RowBytes/Width/Height相等的三个uint32的字段，通过hack方式将这三个字段分别修改成新的RowBytes/Width/Height即可。新的RowBytes/Width/Height即为可重用图片尺寸。预设字节可为4字节、8字节或16字节等。

通过修改目标图片的尺寸参数，实现了可重用图片对目标图片的解码。

在其他实施例中，一种图片解码装置可包括第一获取模块502、锁定模块504、第一解码模块506、第二获取模块508、遍历模块510、第二解码模块512、封装模块514、计数模块516、调用模块518和修改模块520中任意可能的组合。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。