一种图片解码方法、装置以及设备与流程

本申请涉及图片处理技术领域，尤其涉及一种图片解码方法、装置、设备以及计算机存储介质。

背景技术：

随着移动设备的普及，适应于移动终端的应用程序种类也越来越多，目前绝大部分应用程序在运行过程中，需要获得图片并进行纹理映射，以给用户提供沉浸式交互体验；例如，在游戏应用程序中需要对图片进行纹理映射，从而为用户提供更逼真的游戏场景，提高用户沉浸式体验。

目前游戏应用程序在进行纹理映射以渲染游戏界面元素时，往往需要借助游戏应用程序中的渲染引擎先对图片进行解码得到位图，然后再基于位图进行纹理映射。

然而，目前市面上已有的游戏应用程序中的渲染引擎大多集成了多种图片类型的优秀解码库，以满足游戏应用程序的高解码率要求以及支持多类型图片解码的要求；但是，这样就造成整个应用程序的安装包体积过大，而体积过大的游戏应用程序，其在内存有限的移动终端运行时，其运行速率也会受限，有时甚至无法保证正常运行。另外，渲染引擎中集成的解码库有时会出现与移动端机型的兼容性问题。

因此，目前亟需研究一种图片解码方案，既能够轻量化应用程序，又能够满足应用程序对图片解码的高速率需求，保证应用程序为用户提供流畅交互画面。

技术实现要素：

本申请实施例提供了一种图片解码方法、装置以及设备，提供了一种新的图片解码方式，不再需要利用应用程序内置的解码库函数对图片进行解码，从而减小了应用程序安装包的体积。

有鉴于此，本申请第一方面提供了一种图片解码方法，应用于终端，所述终端中安装有操作系统以及应用程序，所述应用程序包括应用逻辑模块、js引擎、渲染引擎、图片下载模块以及第一图片解码器，所述方法包括：

所述应用逻辑模块生成图片下载及解码指令，向所述js引擎发送所述图片下载及解码指令，所述图片下载及解码指令中携带有目标图片对应的下载路径；

所述js引擎接收所述图片下载及解码指令，将所述图片下载及解码指令发送至所述渲染引擎；

所述渲染引擎接收所述图片下载及解码指令，调用所述图片下载模块，向所述图片下载模块发送所述下载路径；

所述图片下载模块根据所述下载路径下载所述目标图片，将所述目标图片存储于文件系统，向所述渲染引擎返回所述目标图片在所述文件系统中的存储地址；

所述渲染引擎调用所述第一图片解码器，向所述第一图片解码器发送所述存储地址；

所述第一图片解码器接收所述存储地址，根据所述存储地址获取所述目标图片，调用操作系统内置的解码库对所述目标图片进行解码得到位图。

本申请第二方面提供了一种图片解码装置，应用于终端，所述终端中安装有操作系统，所述装置包括：应用逻辑模块、js引擎、渲染引擎、图片下载模块以及第一图片解码模块；其中，

所述应用逻辑模块，用于生成图片下载及解码指令，向所述js引擎发送所述图片下载及解码指令，所述图片下载及解码指令中携带有目标图片对应的下载路径；

所述js引擎，用于接收所述图片下载及解码指令，将所述图片下载及解码指令发送至所述渲染引擎；

所述渲染引擎，用于接收所述图片下载及解码指令，调用所述图片下载模块将所述下载路径传递至所述图片下载模块；

所述图片下载模块，用于根据所述下载路径下载所述目标图片，将所述目标图片存储于文件系统，向所述渲染引擎返回所述目标图片在所述文件系统中的存储地址；

所述渲染引擎，还用于调用所述第一图片解码器，向所述第一图片解码器发送所述存储地址；

所述第一图片解码器，用于接收所述存储地址，根据所述存储地址获取所述目标图片，调用操作系统内置的解码库对所述目标图片进行解码得到位图。

本申请第三方面提供了一种设备，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令，执行如上述第一方面所述的图片解码方法的步骤。

本申请第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行上述第一方面所述图片解码的方法。

本申请第五方面提供一种包括指令的计算机程序产品，当其在计算机上运行时，使得所述计算机执行上述第一方面所述的图片解码方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例提供了一种图片解码方法，该方法应用于安装有操作系统和应用程序的终端，其中的应用程序包括应用逻辑模块、js引擎、渲染引擎、图片下载模块以及第一图片解码模块；在需要对图片进行解码时，应用程序逻辑模块生成图片下载及解码指令，并向js引擎发送该图片下载及解码指令，该图片下载及解码指令中携带有目标图片对应的下载路径；js引擎接收到该图片下载及解码指令后，将该图片下载及解码指令发送至渲染引擎；渲染引擎接收到该图片及解码指令后，调用图片下载模块，向该图片下载模块发送目标图片的下载路径；图片下载模块根据该下载路径下载目标图片，将目标图片存储于文件系统，并向渲染引擎返回该目标图片在文件系统中的存储地址；渲染引擎调用第一图片解码器，将该目标图片在文件系统中的存储地址发送给该第一图片解码器；第一图片解码器接收到存储地址后，相应地根据该存储地址获取目标图片，并调用操作系统内置的解码库对该目标图片进行解码得到位图。

在上述图片解码方法中，应用程序中的渲染引擎调用第一图片解码器，通过该第一图片解码器调用操作系统内置的解码库对目标图片进行解码，不再需要利用集成在渲染引擎中的解码库进行图片解码，基于此，在开发应用程序的过程中也不再需要在应用程序的渲染引擎中集成额外的解码库，减少了应用程序安装包的体积。此外，操作系统内置的解码库相比集成在渲染引擎中的解码库具有更好的性能和更高的稳定性，因此，利用该操作系统内置的解码库进行图片解码能够有效地提高解码速度，并且保证图片解码的稳定性。

附图说明

图1为本申请实施例提供的一种图片解码方法的应用场景示意图；

图2为本申请实施例提供的一种图片解码方法的流程示意图；

图3a为本申请实施例提供的一种终端内部模块结构示意图；

图3b为本申请实施例提供的一种图片解码方法的交互信令图；

图4为本申请实施例提供的一种图片解码装置的结构示意图；

图5为本申请实施例提供的另一种图片解码装置的结构示意图；

图6为本申请实施例提供的一种终端设备的硬件结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

现有技术中，应用程序进行纹理映射、渲染应用界面元素时，往往需要借助渲染引擎中集成的解码库对目标图片进行解码，而集成在渲染引擎中的解码库通常会占据很大的体积，这样将相应地导致应用程序安装包的体积增大，并且，在一些情况下，渲染引擎中集成的解码库可能出现与终端机型难以兼容的问题。

为了解决上述现有技术中存在的问题，本申请实施例提供了一种图片解码方法，其采用了一种新的图片解码方式，利用操作系统内置的解码库对图片进行解码，不再需要利用渲染引擎中集成的解码库进行图片解码，从而减小了应用程序安装包的体积。下面先对本申请实施例提供的图片解码方法的核心技术思路进行介绍：

本申请实施例提供了一种图片解码方法，该方法应用于安装有操作系统和应用程序的终端，其中的应用程序包括应用逻辑模块、js引擎、渲染引擎、图片下载模块以及第一图片解码模块；在需要对图片进行解码时，应用程序逻辑模块生成图片下载及解码指令，并向js引擎发送该图片下载及解码指令，该图片下载及解码指令中携带有目标图片对应的下载路径；js引擎接收到该图片下载及解码指令后，将该图片下载及解码指令发送至渲染引擎；渲染引擎接收到该图片及解码指令后，调用图片下载模块，向该图片下载模块发送目标图片的下载路径；图片下载模块根据该下载路径下载目标图片，将目标图片存储于文件系统，并向渲染引擎返回该目标图片在文件系统中的存储地址；渲染引擎调用第一图片解码器，将该目标图片在文件系统中的存储地址发送给该第一图片解码器；第一图片解码器接收到存储地址后，相应地根据该存储地址获取目标图片，并调用操作系统内置的解码库对该目标图片进行解码得到位图。

在上述图片解码方法中，应用程序中的渲染引擎调用第一图片解码器，通过该第一图片解码器调用操作系统内置的解码库对目标图片进行解码，不再需要利用集成在渲染引擎中的解码库进行图片解码，基于此，在开发应用程序的过程中也不再需要在应用程序的渲染引擎中集成额外的解码库，减少了应用程序安装包的体积。此外，操作系统内置的解码库相比集成在渲染引擎中的解码库具有更好的性能和更高的稳定性，因此，利用该操作系统内置的解码库进行图片解码能够有效地提高解码速度，并且保证图片解码的稳定性。

应理解，上述本申请实施例提供的图片解码方法通常应用于终端，该终端具体可以为智能手机、计算机、个人数字助理(personaldigitalassitant，pda)、平板电脑等。

应理解，本申请实施例中提及的应用程序为需要执行图片解码操作的软件应用程序(application，app)，该应用程序具体可以为微信、qq等社交应用程序，还可以为王者荣耀、荒野求生等游戏应用程序，在此不对具体应用该图片解码方法的应用程序做任何限定。

为了便于理解本申请实施例提供的技术方案，下面结合应用场景，对本申请实施例提供的图片解码方法进行整体性介绍。

参见图1，图1为本申请实施例提供的图片解码方法的应用场景示意图。

如图1所示，当在终端100上运行的应用程序110需要在其显示界面上显示目标图片时，应用程序中110的应用逻辑模块111相应地生成图片下载及解码指令，该图片下载及解码指令中携带有目标图片对应的下载路径，应用逻辑模块111将自身生成的图片下载及解码指令发送至js引擎112。js引擎112接收到该图片下载及解码指令后，将该图片下载及解码指令发送至渲染引擎113。渲染引擎113接收到该图片下载及解码指令后，调用图片下载模块114，向图片下载模块发送下载路径。图片下载模块114根据该下载路径下载该目标图片，并将该目标图片存储于文件系统，然后向渲染引擎113返回该目标图片在文件系统中的存储地址。渲染引擎113进而调用第一图片解码器115，向第一图片解码器115发送目标图片在文件系统中的存储地址。进而，第一图片解码器115接收该存储地址，根据该存储地址获取目标图片，调用操作系统120内置的解码库对该目标图片进行解码得到位图。

需要说明的是，上述应用逻辑模块111、js引擎112、渲染引擎113、图片下载模块114以及第一图片解码模块115均属于应用程序中的功能模块，在应用程序运行的过程中，其中的各个功能模块相应地执行自身所需执行的操作，以实现该应用程序所需要实现的各个功能。

需要说明的是，上述第一图片解码器115在对目标图片进行解码时，直接调用了操作系统120内置的解码库对图片进行解码，不再需要利用集成于渲染引擎中的解码库进行图片解码，基于此，在开发应用程序的过程中也不再需要在应用程序的渲染引擎中集成解码库，从而减少了应用程序安装包的体积。此外，操作系统内置的解码库相比渲染引擎中集成的解码库具有更好的性能和更高的稳定性，因此，利用该操作系统内置的解码库进行图片解码能够有效地提高解码速度，并且保证图片解码的稳定性。

下面通过实施例对本申请提供的图片解码方法进行介绍。

参见图2，图2为本申请实施例提供的一种图片解码方法的流程示意图。应理解，该图片解码方法应用于终端，该终端中安装有操作系统以及应用程序，具体执行该图片解码方法对图片进行解码时，应用程序中的应用逻辑模块、js引擎、渲染引擎、图片下载模块以及第一图片解码器相应地执行自身需要执行的操作。

如图2所示，该图片解码方法包括以下步骤：

步骤201：应用逻辑模块生成图片下载及解码指令，向js引擎发送该图片下载及解码指令，该图片下载及解码指令中携带有目标图片对应的下载路径。

在实际应用中，应用程序响应于用户的操作，会相应地为用户展示对应的显示页面，通常情况下，显示页面上还可能包括需要为用户展示的图片，这些图片即为目标图片。以使用微信为例，微信程序响应于用户发起的查看推送内容的操作，相应地为用户展示承载有推送内容的显示页面，推送内容中通常会包括一些相关图片，这些图片即为目标图片。

应理解，需要在显示页面上显示的所有图片均属于目标图片，该目标图片可以为插入在推送内容中的图片，也可以为游戏页面中以图片形式显示的游戏元素，还可以为用户在社交平台上发表的的图片，在此不对目标图片做任何限定。

应用程序需要显示目标图片时，应用程序中的应用逻辑模块会相应地针对该目标图片生成图片下载及解码指令，该图片下载及解码指令中携带有该目标图片对应的下载路径；进而，应用逻辑模块将该图片下载及解码指令发送至应用程序中的js引擎。

通常情况下，上述图片下载及解码指令为image.src指令，其指令的值即为目标图片对应的统一资源定位符(uniformresourcelocator，url)，即该目标图片存储区域对应的绝对路径或相对路径。

需要说明的是，目标图片对应的下载路径指向目标图片对应的存储区域，根据该目标图片对应的下载路径，即可相应地获知该目标图片对应的存储区域，进而从该存储区域中下载目标图片。应理解，目标图片具体可以为存储于服务器端的图片，也可以为存储在终端中的图片，在此不对目标图片对应的存储区域做具体限定。

需要说明的是，此处的js引擎是能够将javascript代码处理并执行的运行环境，其在运行时，先将javascript代码转变为抽象语法树，然后在该抽象语法树上解释执行。

应理解，上述目标图片可以为一张，也可以为多张；在应用程序仅需要显示一张目标图片的情况下，应用逻辑模块生成的图片下载及解码指令中仅包括该张目标图片对应的存储路径即可；在应用程序需要同时显示多张目标图片的情况下，应用逻辑模块可以生成一条图片下载及解码指令，该图片下载及解码指令中包括需要显示的各张目标图片各自对应的存储路径，当然，应用逻辑模块也可以针对每张目标图片相应地生成一条图片下载及解码指令，每条图片下载及解码指令中包括一张目标图片对应的存储路径。

需要说明的是，当应用程序为游戏应用程序时，应用逻辑模块相应地为游戏应用逻辑模块，该游戏应用逻辑模块可以根据用户在游戏界面上的操作，相应地生成图片下载及解码指令。

具体的，游戏应用逻辑模块可以在检测到用户在游戏界面上触发特定游戏操作时，相应地根据用户触发的操作确定是否需要对当前游戏界面进行变换，并且在确定需要对当前游戏界面进行变换时，进一步确定如何对当前游戏界面进行变换，在一些情况下，游戏应用程序仅需对游戏界面上的某些元素进行变换，如对游戏界面上的人物元素进行变换，或对游戏界面上的装饰元素进行变换，此时，需要变换的游戏元素即可被确定为目标图片，在另一些情况下，游戏应用程序需要对游戏界面整体进行变换，此时游戏界面整体即可被确定为目标图片；游戏应用逻辑模块根据用户触发的操作确定出目标图片后，相应地针对该目标图片生成图片下载及解码指令，并进一步将该图片下载及解码指令发送至游戏应用程序中的js引擎。

需要说明的是，上述游戏应用程序可以为独立的游戏应用程序，如王者荣耀、荒野求生等游戏应用；也可以为集成在其他应用程序中的游戏应用程序，如集成在微信中的小游戏应用。

步骤202：js引擎接收上述图片下载及解码指令，将该图片下载及解码指令发送至渲染引擎。

js引擎接收到携带有目标图片对应的下载路径的图片下载及解码指令后，进一步将该图片下载及解码指令发送至渲染引擎，以通过渲染引擎相应地调用图片下载模块下载目标图片。

步骤203：渲染引擎接收图片下载及解码指令，调用图片下载模块，向该图片下载模块发送下载路径。

应用程序中的渲染引擎接收到js引擎发送的图片下载及解码指令后，调用应用程序中的图片下载模块，并将图片下载及解码指令中携带的目标图片对应的下载路径发送至图片下载模块，以利用该图片下载模块根据目标图片对应的下载路径相应地下载目标图片。

在一种可能的实现方式中，应用程序中的渲染引擎接收到图片下载及解码指令后，可以基于反射的方式将该图片下载及解码指令传输至java层，以调用图片下载模块。具体的，渲染引擎接收到下载图片及解码指令后，将该下载图片及解码指令通过反射的方式传输给java层，图片下载模块在该java层中运行。

需要说明的是，上述反射机制是java层提供的一种动态获取信息以及动态调用对象的方法，其在运行过程中，对于任意一个实体类，均可获知该实体类所有属性和方法；对于任意一个对象，均可调用它的任意方法和属性；java层的反射机制对应的程序运行时，允许改变程序结构或变量类型。

应理解，应用程序中的渲染引擎也可以通过其他指定的机制调用图片下载模块，在此不对渲染引擎调用图片下载模块的方式做任何限定。

步骤204：图片下载模块根据下载路径下载目标图片，将目标图片存储于文件系统，向渲染引擎返回该目标图片在文件系统中的存储地址。

图片下载模块接收到渲染引擎发送的下载路径后，相应地根据该下载路径下载目标图片，并且将下载得到的目标图片存储于文件系统中，在将目标图片存储至文件系统中后，生成目标图片在文件系统中的存储地址，向渲染引擎返回该存储地址。

应理解，当目标图片对应的下载路径指向的存储区域在支持该应用程序运行的终端上时，图片下载模块相应地根据该下载路径，从终端上对应的存储区域中下载目标图片；当目标图片对应的下载路径指向的存储区域在服务器上时，图片下载模块将相应地通过网络，从服务器端用于存储目标图片的存储区域中下载该目标图片。

应理解，当仅需要下载一张目标图片时，图片下载模块直接根据该目标图片对应的下载路径，从对应的存储区域下载该目标图片即可；当需要下载多张目标图片时，图片下载模块可以一次性地根据各张目标图片各自对应的下载路径，下载所有目标图片，当然，图片下载模块也可以根据每张目标图片各自对应的下载路径，逐一地从各张目标图片对应的存储区域下载各张目标图片，在此不对下载目标图片的方式做具体限定。

需要说明的是，图片下载模块下载获得目标图片后，相应地将所下载的目标图片存储于终端的文件系统，应理解，对于智能手机、平板电脑等终端来说，此处的文件系统通常指的是内存文件系统，对于电脑等终端来说，此处的文件系统通常指的是电脑上的存储设备。完成对于目标图片的存储后，文件系统相应地生成与目标图片对应的存储地址，并向渲染引擎返回该目标图片对应的存储地址。

步骤205：渲染引擎调用第一图片解码器，向该第一图片解码器发送存储地址。

应用程序中的渲染引擎调用图片下载模块下载获得目标图片后，将下载得到的目标图片存储于文件系统中，并将目标图片在文件系统中的存储地址发送给渲染引擎。渲染引擎在获取到目标图片在文件系统中的存储地址后，进一步调用第一图片解码器，向该第一图片解码器发送该目标图片在文件系统中的存储地址，以使第一图片解码器根据该存储地址从文件系统中获取目标图片。

在一种可能的实现方式中，渲染引擎在获取到目标图片在文件系统中存储地址后，可以基于反射的方式将该存储地址传输至java层，以调用第一图片解码器。具体的，渲染引擎接收到目标图片在文件系统中的存储地址后，将该存储地址通过反射的方式传输给java层，第一图片解码器在该java层中运行。

需要说明的是，上述反射机制是java层提供的一种动态获取信息以及动态调用对象的方法，其在运行过程中，对于任意一个实体类，均可获知该实体类所有属性和方法；对于任意一个对象，均可调用它的任意方法和属性；java层的反射机制对应的程序运行时，允许改变程序结构或变量类型。

应理解，应用程序中的渲染引擎也可以通过其他指定的机制调用第一图片解码器，在此不对渲染引擎调用第一图片解码器的方式做任何限定。

步骤206：第一图片解码器接收该存储地址，根据该存储地址获取目标图片，调用操作系统内置的解码库对目标图片进行解码得到位图。

第一图片解码器接收到渲染引擎发送的存储地址后，根据该存储地址从文件系统中获取该目标图片，进而，调用操作系统内置的解码库对获取的目标图片进行解码得到其对应的位图(bitmap)。

具体实现时，第一图片解码器在接收到渲染引擎发送的存储地址后，根据该存储地址从文件系统中调取目标图片对应的压缩文件(通常情况下，目标图片以压缩文件的形式存储于文件系统中)，并且调用操作系统内置的解码库，根据目标图片对应的原始格式，相应地从解码库中调用与该图片原始格式对应的解码函数对其进行解码，最终得到目标图片对应的位图。

需要说明的是，目前常见的图片格式通常包括png、jpeg、gif、svg、webp和bmp等，操作系统内置的解码库中包括的解码函数能够覆盖常见的各种图片格式，即利用操作系统内置的解码库能够对目前所有常见的图片格式进行解码。

当应用程序在安卓android系统中运行时，第一图片解码器调用的操作系统中内置的解码库即为android系统内置的解码库skia库，skia库为安卓系统底层图像库，是一种基于c++的开源2d向量图像处理函数库，包括字型处理、坐标变换和位图处理等功能，利用该skia可以对png、jpeg、gif、svg、webp和bmp等图片格式的图片进行解码。

应理解，当应用程序在其他操作系统(如ios系统、windows系统等)中运行时，第一图片解码器将相应地调用该操作系统内置的解码库，目前各个操作系统内置的解码库均能基本覆盖常见的图片格式，即利用各个操作系统内置的解码库均能够实现对各种常见的图片格式进行解码。

需要说明的是，为了使得下载的目标图片最终能够在应用程序的显示页面上显示，本申请实施例提供的方法还可以进一步通过图形处理器(graphicsprocessingunit，gpu)根据目标图片对应的位图渲染目标图片，以使目标图片在显示页面上显示。

图形处理器具体根据目标图片对应的位图进行渲染时，图形处理器可以基于opengl(opengraphicslibrary)图形图像程序开发接口技术对位图进行图像渲染处理，以将位图渲染至显示页面上显示。当然，图形处理器也可以采用其他图像渲染技术对位图进行渲染处理，在此不对图形处理器具体采用的渲染技术做任何限定。

在游戏应用的场景下，游戏应用程序为了保证向用户呈现的游戏界面元素更加逼真，给用户带来更真实的游戏体验，游戏应用程序通常需要利用图形处理器根据目标图片对应的位图，进行纹理映射处理，从而在终端的屏幕上显示应用界面元素。

在游戏应用的场景下，渲染引擎可以根据位图的位图句柄为纹理对象指定纹理图像数据，进而，将为纹理对象传递给终端中的图形处理器；图形处理器基于该纹理图像数据进行纹理映射，以在终端的屏幕上显示应用界面元素。

具体的，第一图片解码器调用操作系统内置的解码库对目标图片进行解码处理，得到目标图片对应的位图后，将该位图存储于原生层native层共享内存中，并相应地生成与该位图对应的像素数据对应的位图句柄，渲染引擎根据该位图对应的位图句柄生成纹理图像数据，并将该纹理图像数据指定给预先构建的纹理对象，利用该纹理对象承载纹理图像数据，进而，将该纹理对象发送给图形处理器。相应地，图形处理器接收到该纹理对象后，将纹理图像数据相应地映射至纹理对象上，从而在终端的屏幕上显示游戏应用界面元素。

可选的，当操作系统为android系统时，渲染引擎可以采用androidbitmap_getinfo函数从位图的位图句柄获得位图信息，此处的位图信息包括宽度、高度以及像素格式；进而，渲染引擎采用androidbitmap_lockpixels函数对位图的像素缓存进行上锁，以获得像素缓存的指针，并且根据该指针以及位图信息为纹理对象指定纹理图像数据。

需要说明的是，在这种实现方式中，渲染引擎通过对位图对应的像素缓存进行上锁，得到对应于该像素缓存的指针，进而使得渲染引擎可以根据该指针以及位图信息为纹理对象指定纹理图像数据，这样，免去了拷贝位图对应的像素数据的过程，从而免去了拷贝像素数据需要占用的内存空间，节省了内存空间，并且提高了像素数据的传输速度。

在上述实现方式中，为了保证未被进行纹理映射处理的位图对应的像素数据在native层中不被释放，渲染引擎采用androidbitmap_lockpixels函数对位图的像素缓存进行上锁处理。具体的，渲染引擎可以调用android系统接口对位图在native层共享内存中对应的像素缓存区域进行封锁，由此防止在对该像素缓存进行纹理映射处理之前误被操作系统释放，并且在封锁的过程中，相应地生成该位图对应的指针，以利用该指针指示该位图在native层共享内存中具体对应的像素缓存区域。

可选的，在图形处理器完成对该位图的渲染后，渲染引擎可以再通过android系统接口释放该被上锁的像素缓存区域，即将该像素缓存区域解锁并释放，由此避免已完成纹理映射的位图继续占用native层共享内存的内存空间，以为后续解码得到的位图提供充分的存储空间。在android系统中，渲染引擎可以采用androidbitmap_unlockpixels函数对位图的像素缓存进行解锁，从而释放位图对应的内存空间。

应理解，当应用程序在其他操作系统中运行时，渲染引擎也可以相应地采用该操作系统支持的上锁函数，对位图在native层共享内存中的像素缓存区域进行封锁，并在完成渲染后，采用该操作系统支持的解锁函数，对位图在native层共享内存中的像素缓存区域进行解锁，在此不对渲染引擎所调用的封锁函数和解锁函数做具体限定。

需要说明的是，在一些情况下，渲染引擎需要解码的目标图片可能存在某些安全隐患，直接利用操作系统内置的解码库对该这类目标图片进行解码处理，可能为会操作系统带来安全问题，为了保证操作系统的安全性，在本申请实施例提供的图片解码方法中，渲染引擎在向渲染引擎返回目标图片在文件系统中的存储地址后，在调用第一图片解码器对该目标图片进行解码处理之前，还可以先对目标图片进行特定的判断操作，进而根据判断结果选择合适的解码方式对目标图片进行解码。

具体的，应用程序在向渲染引擎返回目标在文件系统中的存储地址之后，且在渲染引擎调用第一图片解码之前，渲染引擎先判断目标图片是否属于白名单，该白名单中存储有存在安全隐患的图片对应的图片类型；若目标图片属于该白名单，则渲染引擎调用应用程序中的第二图片解码器，向该第二图片解码器发送目标图片在文件系统中的存储地址；相应地，第二图片解码器在接收到该存储地址后，根据该存储地址从文件系统中获取目标图片，该第二图片解码器调用其内置的解码库，对该目标图片进行解码得到位图；若目标图片不属于该白名单，则执行上述步骤205至步骤206，即渲染引擎调用第一图片解码器，向第一图片解码器发送该存储地址，该第一图片解码器接收到存储地址后，根据该存储地址获取存储于文件系统中的目标图片，调用操作系统内置的解码库对该目标图片进行解码得到位图。

具体实现时，应用程序可以预先设置一个白名单，将可能存在安全隐患的图片对应的图片类型相应地存储于该白名单中；渲染引擎接收到图片下载模块发送的目标图片在文件系统中的存储地址后，渲染引擎先判断目标图片对应的图片类型是否属于白名单中存储的图片类型；若该目标图片对应的图片类型属于该白名单，则说明该目标图片可能存在安全隐患，不能直接利用操作系统内置的解码库对其进行解码，以防为操作系统带来安全问题，则渲染引擎相应地调用第二图片解码器，向该第二图片解码器发送目标图片在文件系统中的存储地址，该第二图片解码器相应地调用应用程序自身内置的解码库，利用该解码库中的解码函数相应地对目标图片进行解码处理；反之，若该目标图片对应的图片类型不属于该白名单，则说明该目标图片不存在安全隐患，则渲染引擎可以相应地调用第一图片解码器，向该第一图片解码器发送目标图片在文件系统中的存储地址，该第一图片解码器调用系统内置的解码库对目标图片进行解码处理。

应理解，上述第二图片解码器和第一图片解码器所采用的解码逻辑不同，第二图片解码器是调用应用程序内置的解码库进行解码，而第一图片解码器是调用操作系统内置的解码库进行解码。

需要说明的是，在开发应用程序的过程中，仅需针对可能存在安全隐患的图片类型设置对应的解码库，并将该解码库函数内置于应用程序安装包中，由于该解码库仅用于解码可能存在安全隐患的图片，因此，该解码库的体积会远远小于现有技术中应用程序安装包内集成的解码库的体积，也就是说，即使在应用程序安装包中内置该解码库，也不会对应用程序安装包的体积造成很大影响，即不会使得应用程序安装包的体积过大。

在上述图片解码方法中，应用程序中的渲染引擎调用第一图片解码器，通过该第一图片解码器调用操作系统内置的解码库对目标图片进行解码，不再需要利用集成在渲染引擎中的解码库进行图片解码，基于此，在开发应用程序的过程中也不再需要在应用程序的渲染引擎中集成额外的解码库，减少了应用程序安装包的体积。此外，操作系统内置的解码库相比集成在渲染引擎中的解码库具有更好的性能和更高的稳定性，因此，利用该操作系统内置的解码库进行图片解码能够有效地提高解码速度，并且保证图片解码的稳定性。

为了便于进一步理解本申请实施例提供的图片解码方法，下面结合附图对用于执行该图片解码方法的终端内部模块结构做具体介绍，并且，结合终端内部模块结构，以应用程序为游戏应用程序为例，对本申请实施例提供的图片解码方法做整体性介绍。

参见图3a，图3a为本申请实施例提供的终端内部模块结构示意图。

如图3a所示，该终端中安装有操作系统3100、应用程序3200和图形处理器3300；其中，操作系统3100中内置有用于解码图片的解码库3110；应用程序3200为需要执行图片解码操作的软件应用程序，在本实施例中以应用程序3200为游戏应用程序为例，对其中的模块结构做具体介绍；图形处理器3300用于根据解码得到的位图进行纹理映射处理。

游戏应用程序3200中包括有游戏应用逻辑模块3210、js引擎3220、渲染引擎3230、图片下载模块3240、第一图片解码器3250、第二图片解码器3260和其自身内置的解码库3270。其中，游戏应用逻辑模块3210与js引擎3220通信，向js引擎3220发送图片下载及解码指令；js引擎3220与渲染引擎3230通信，将自身接收的图片下载及解码指令发送给渲染引擎3230；渲染引擎3230与图片下载模块3240之间相互通信，渲染引擎3230将图片下载及解码指令中携带的下载路径发送给图片下载模块3240，图片下载模块3240将自身下载得到的目标文件在文件系统中的存储地址发送给渲染引擎3230；渲染引擎3230与第一图片解码器3250通信，在判断目标图片不属于白名单时，将自身接收的存储地址发送至第一图片解码器3250；第一图片解码器3250与操作系统3100内置的解码库3110相关联，其可以解码库3110对该目标图片进行解码；渲染引擎还与第二图片解码器3260通信，在判断目标图片属于白名单时，将自身接收的存储地址发送至第二图片解码器3260；第二图片解码器3260与应用程序内置的解码库3270相关联，其可以调用解码库3270对目标图片进行解码。

下面以上述图3a所示的终端内部模块结构为基础，对在图3a所示的应用程序内部各个模块执行本申请实施例提供的图片解码方法的流程做整体性介绍。

参见图3b，图3b为本申请实施例提供的图片解码方法的交互信令图。如图3b所示该方法包括：

第一步：游戏应用逻辑模块3210根据用户在游戏界面上的操作，生成图片下载及解码指令。

游戏应用逻辑模块3210实时检测用户在游戏界面上的操作，当检测到用户执行的某项操作能够触发游戏界面上游戏元素或游戏整体界面的改变，则游戏应用逻辑模块3210相应地确定需要改变的游戏元素或游戏整体界面为目标图片，并针对该目标图片生成图片下载及解码指令，该图片下载及解码指令中包括该目标图片的下载路径。

第二步：游戏应用逻辑模块3210向js引擎3220发送该图片下载及解码指令。

第三步：js引擎3220接收到图片下载及解码指令后，将该图片下载及解码指令发送给渲染引擎3230。

第四步：渲染引擎3230调用图片下载模块3240，将图片下载及解码指令中的下载路径发送至图片下载模块3240。

第五步：图片下载模块3240根据下载路径下载目标图片，并将目标图片存储于文件系统，相应地获取目标图片在文件系统中的存储地址。

第六步：图片下载模块3240向渲染引擎3230返回目标图片在文件系统中的存储地址。

第七步：渲染引擎3230判断目标图片是否属于白名单，若目标图片不属于白名单，则按顺序执行步骤308和步骤309，若目标图片属于白名单，则按顺序执行步骤310和步骤311。

第八步：渲染引擎3230调用第一图片解码器3250，向第一图片解码器3250发送目标图片在文件系统中的存储地址。

第九步：第一图片解码器3250根据该存储地址获取目标图片，调用操作系统3100内置的解码库3110，对目标图片进行解码得到位图。

第十步：渲染引擎3230调用第二图片解码器3260，向第二图片解码器3260发送目标图片在文件系统中的存储地址。

第十一步：第二图片解码器3260根据该存储地址获取目标图片，调用应用程序3200内置的解码库3270，对目标图片进行解码得到位图。

第十二步：渲染引擎3230根据上述步骤309或步骤311解码得到的位图的位图句柄，为纹理对象指定纹理图像数据，将该纹理对象传递给终端中的图形处理器3300，以使图形处理器3300基于纹理图像数据进行纹理映射，以在终端的屏幕上显示目标图片。

渲染引擎3230可以采用androidbitmap_getinfo函数从位图的位图句柄获得位图信息，该位图信息包括宽度、高度以及像素格式；可以采用androidbitmap_lockpixels函数对位图的像素缓存进行上锁，以获得像素缓存的指针，并根据指针以及位图信息为纹理对象指定纹理图像数据。

针对上文描述的图片解码方法，本申请还提供了对应的图片解码装置，以使上述图片解码方法在实际中的应用以及实现。

参见图4，图4是与上文图2所示的图片解码方法对应的一种图片解码装置400的结构示意图，该图片解码装置400包括：

应用逻辑模块401，用于生成图片下载及解码指令，向所述js引擎发送所述图片下载及解码指令，所述图片下载及解码指令中携带有目标图片对应的下载路径；

js引擎402，用于接收所述图片下载及解码指令，将所述图片下载及解码指令发送至所述渲染引擎；

渲染引擎403，用于接收所述图片下载及解码指令，调用所述图片下载模块将所述下载路径传递至所述图片下载模块；

图片下载模块404，用于根据所述下载路径下载所述目标图片，将所述目标图片存储于文件系统，向所述渲染引擎返回所述目标图片在所述文件系统中的存储地址；

渲染引擎403，还用于调用所述第一图片解码器，向所述第一图片解码器发送所述存储地址；

第一图片解码器405，用于接收所述存储地址，根据所述存储地址获取所述目标图片，调用操作系统内置的解码库对所述目标图片进行解码得到位图。

可选的，在上述图4所示的图片解码装置的基础上，参见图5，图5为本申请实施例提供的另一种图片解码装置500的结构示意图，该装置还包括第二图片解码器501。

则在所述图片下载模块404向所述渲染引擎403返回所述目标图片在所述文件系统中的存储地址之后，且在所述渲染引擎403调用所述第一图片解码器405之前，所述渲染引擎403还用于：判断所述目标图片是否属于白名单，所述白名单中存储有存在安全隐患的图片对应的图片类型；

若是，则所述渲染引擎403，还用于调用所述应用程序中的第二图片解码器501，向所述第二图片解码器501发送所述存储地址；所述第二图片解码器501，用于接收所述存储地址，根据所述存储地址获取所述目标图片；所述第二图片解码器501，还用于调用其内置的解码库，对所述目标图片进行解码得到位图；

若否，则所述渲染引擎403再执行所述调用所述第一图片解码器405，向所述第一图片解码器405发送所述存储地址的操作；以及，所述第一图片解码器405再执行所述接收所述存储地址，根据所述存储地址获取所述目标图片，调用操作系统内置的解码库函数对所述目标图片进行解码得到位图的操作。

可选的，在上述图4所示的图片解码装置的基础上，所述渲染引擎403，还用于根据所述位图的位图句柄为纹理对象指定纹理图像数据，将所述纹理对象传递给所述终端中的图形处理器，以使所述图形处理器基于所述纹理图像数据进行纹理映射，以在所述终端的屏幕上显示应用界面元素。

可选的，在上述图4所示的图片解码装置的基础上，所述渲染引擎403在根据所述位图的位图句柄为纹理对象指定纹理图像数据时，具体用于：

采用androidbitmap_getinfo函数从所述位图的位图句柄获得位图信息，所述位图信息包括宽度、高度以及像素格式；

采用androidbitmap_lockpixels函数对所述位图的像素缓存进行上锁，以获得所述像素缓存的指针，并根据所述指针以及所述位图信息为纹理对象指定纹理图像数据。

可选的，在上述图4所示的图片解码装置的基础上，所述应用程序为游戏应用程序，所述应用逻辑模块401为游戏应用逻辑模块；

所述游戏应用逻辑模块，用于根据用户在游戏界面上的操作，生成所述图片下载及解码指令。

在上述图片解码方法中，应用程序中的渲染引擎调用第一图片解码器，通过该第一图片解码器调用操作系统内置的解码库对目标图片进行解码，不再需要利用集成在渲染引擎中的解码库进行图片解码，基于此，在开发应用程序的过程中也不再需要在应用程序的渲染引擎中集成额外的解码库，减少了应用程序安装包的体积。此外，操作系统内置的解码库相比集成在渲染引擎中的解码库具有更好的性能和更高的稳定性，因此，利用该操作系统内置的解码库进行图片解码能够有效地提高解码速度，并且保证图片解码的稳定性。

本申请实施例还提供了一种用于解码图片的设备，该设备具体为终端设备，如图6所示，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该终端可以为包括手机、平板电脑、个人数字助理(personaldigitalassistant，pda)、销售终端(pointofsales，pos)、车载电脑等任意终端设备，以终端为手机为例：

图6示出的是与本申请实施例提供的终端相关的手机的部分结构的框图。参考图6，手机包括：射频(radiofrequency，rf)电路610、存储器620、输入单元630、显示单元640、传感器650、音频电路660、无线保真(wirelessfidelity，wifi)模块670、处理器680(其中包括图形处理器)、以及电源690等部件。本领域技术人员可以理解，图6中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图6对手机的各个构成部件进行具体的介绍：

rf电路610可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器680处理；另外，将设计上行的数据发送给基站。通常，rf电路610包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(lownoiseamplifier，lna)、双工器等。此外，rf电路610还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(globalsystemofmobilecommunication，gsm)、通用分组无线服务(generalpacketradioservice，gprs)、码分多址(codedivisionmultipleaccess，cdma)、宽带码分多址(widebandcodedivisionmultipleaccess,wcdma)、长期演进(longtermevolution，lte)、电子邮件、短消息服务(shortmessagingservice，sms)等。

存储器620可用于存储软件程序以及模块，处理器680通过运行存储在存储器620的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器620可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器620可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元630可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元630可包括触控面板631以及其他输入设备632。触控面板631，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板631上或在触控面板631附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板631可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器680，并能接收处理器680发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板631。除了触控面板631，输入单元630还可以包括其他输入设备632。具体地，其他输入设备632可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元640可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元640可包括显示面板641，可选的，可以采用液晶显示器(liquidcrystaldisplay，lcd)、有机发光二极管(organiclight-emittingdiode，oled)等形式来配置显示面板641。进一步的，触控面板631可覆盖显示面板641，当触控面板631检测到在其上或附近的触摸操作后，传送给处理器680以确定触摸事件的类型，随后处理器680根据触摸事件的类型在显示面板641上提供相应的视觉输出。虽然在图6中，触控面板631与显示面板641是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板631与显示面板641集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器650，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板641的亮度，接近传感器可在手机移动到耳边时，关闭显示面板641和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路660、扬声器661，传声器662可提供用户与手机之间的音频接口。音频电路660可将接收到的音频数据转换后的电信号，传输到扬声器661，由扬声器661转换为声音信号输出；另一方面，传声器662将收集的声音信号转换为电信号，由音频电路660接收后转换为音频数据，再将音频数据输出处理器680处理后，经rf电路610以发送给比如另一手机，或者将音频数据输出至存储器620以便进一步处理。

wifi属于短距离无线传输技术，手机通过wifi模块670可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图6示出了wifi模块670，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器680是手机的控制中心，其中包括有图形处理器，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器620内的软件程序和/或模块，以及调用存储在存储器620内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器680可包括一个或多个处理单元；优选的，处理器680可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器680中。

手机还包括给各个部件供电的电源690(比如电池)，优选的，电源可以通过电源管理系统与处理器680逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本申请实施例中，该终端所包括的处理器680中运行有应用程序，该应用程序中的各个模块分别具有以下功能：

所述应用逻辑模块生成图片下载及解码指令，向所述js引擎发送所述图片下载及解码指令，所述图片下载及解码指令中携带有目标图片对应的下载路径；

所述js引擎接收所述图片下载及解码指令，将所述图片下载及解码指令发送至所述渲染引擎；

所述渲染引擎接收所述图片下载及解码指令，调用所述图片下载模块，向所述图片下载模块发送所述下载路径；

所述图片下载模块根据所述下载路径下载所述目标图片，将所述目标图片存储于文件系统，向所述渲染引擎返回所述目标图片在所述文件系统中的存储地址；

所述渲染引擎调用所述第一图片解码器，向所述第一图片解码器发送所述存储地址；

所述第一图片解码器接收所述存储地址，根据所述存储地址获取所述目标图片，调用操作系统内置的解码库对所述目标图片进行解码得到位图。

可选的，处理器680还可以执行本申请实施例中图片解码方法任一具体实现方式的方法步骤。

本申请实施例还提供一种计算机可读存储介质，用于存储程序代码，该程序代码用于执行前述各个实施例所述的一种图片解码方法中的任意一种实施方式。

本申请实施例还提供一种包括指令的计算机程序产品，当其在计算机上运行时，使得计算机执行前述各个实施例所述的一种图片解码方法中的任意一种实施方式。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。