CN112925654B - 图片解码方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本申请是关于一种图片解码方法、装置、计算机设备及存储介质，涉及图像处理技术领域。该方法包括：通过应用程序中的第一组件获取待解码的图片数据；通过所述第一组件将所述图片数据写入缓冲区；通过所述第二组件从所述缓冲区中提取所述图片数据；通过所述第二组件，在分配给所述第二组件的内存中对所述图片数据进行解码。当应用程序中的第一组件接收到外部输入的加载图片的加载请求时，可以通过共享内存的方式将图片数据传递给使用不同内存的第二组件，由第二组件进行解码，从而可以避免图片解码过程占用第一组件的内存而导致的内存溢出异常，从而减少图片解码时对第一组件的内存占用，提高解码效率。

Description

图片解码方法、装置、计算机设备及存储介质

技术领域

本申请实施例涉及图像处理技术领域，特别涉及一种图片解码方法、装置、计算机设备及存储介质。

背景技术

随着计算机应用技术的不断发展，很多应用程序提供图片展示的功能，而应用程序在展示图片时，首选需要对图片数据进行解码。

在相关技术中，应用程序接收到解码请求时，可以创建一个用于解码的线程，并在该线程中进行图片解码。例如，以安卓平台中的应用程序的解码方案为例，应用程序中的Java组件接收到解码请求后，创建一个解码线程，使用安卓提供的图片解码类BitmapFactory的相关方法将输入源转换为Bitmap(位图)对象，并在当前线程中同步解码并返回Bitmap对象，该Bitmap对象中含有解码后的图片数据并存在于Java堆内存中。

由于安卓系统中运行的Java虚拟机存在最大内存限制，相关技术中的解码方法容易导致Java堆内存占用超过限制而引发内存溢出(Out Of Memory，OOM)异常，影响图片解码效率。

发明内容

本申请实施例提供了一种图片解码方法、装置、计算机设备及存储介质，可以提高图片解码效率，技术方案如下：

一方面，提供了一种图片解码方法，所述方法包括：

通过应用程序中的第一组件获取待解码的图片数据；

通过所述第一组件将所述图片数据写入缓冲区，所述缓冲区由所述第一组件与所述应用程序中的第二组件共享；所述第一组件与所述第二组件被分配不同的内存；

通过所述第二组件从所述缓冲区中提取所述图片数据；

通过所述第二组件，在分配给所述第二组件的内存中对所述图片数据进行解码。

另一方面，提供了一种图片解码装置，所述装置包括：

图片数据获取模块，用于通过应用程序中的第一组件获取待解码的图片数据；

写入模块，用于通过所述第一组件将所述图片数据写入缓冲区，所述缓冲区由所述第一组件与所述应用程序中的第二组件共享；所述第一组件与所述第二组件被分配不同的内存；

提取模块，用于通过所述第二组件从所述缓冲区中提取所述图片数据；

解码模块，用于通过所述第二组件，在分配给所述第二组件的内存中对所述图片数据进行解码。

可选的，所述装置还包括：

存储模块，用于通过所述第二组件将对所述图片数据的解码结果存储在分配给所述第二组件的内存中。

可选的，所述装置还包括：

地址返回模块，用于通过所述第二组件将所述解码结果的内存地址返回给所述第一组件。

可选的，所述地址返回模块，包括：

地址写入单元，用于通过所述第二组件，将所述解码结果的内存地址写入指定类型对象，所述指定类型对象是所述第一组件支持的对象；

对象返回单元，用于将写入所述解码结果的内存地址的所述指定类型对象返回给所述第一组件。

可选的，所述装置还包括：

预解码模块，用于在所述写入模块通过所述第一组件将所述图片数据写入缓冲区之前，通过所述第一组件对所述图片数据进行预解码，获得所述图片数据对应的图片的图片信息，所述图片信息包括图片格式以及图片尺寸中的至少一种；

所述写入模块，用于，

当所述图片信息满足解码条件时，通过所述第一组件将所述图片数据写入缓冲区。

可选的，所述解码模块，包括：

线程创建单元，用于通过所述第二组件创建独立线程；

解码单元，用于通过所述独立线程对所述图片数据进行解码。

可选的，所述装置还包括：

内存回收模块，用于通过所述第二组件对所述图片数据解码成功后，回收所述缓冲区占用的内存。

可选的，所述装置还包括：

缓冲区申请模块，用于在所述写入模块通过所述第一组件将所述图片数据写入缓冲区之前，通过所述第一组件申请所述缓冲区，所述缓冲区占用的内存是分配给所述第二组件的内存中的一部分。

可选的，所述装置还包括：

第一占用率获取模块，用于在所述写入模块通过所述第一组件将所述图片数据写入缓冲区之前，通过所述第一组件获取所述第二组件的内存占用率，所述第二组件层的内存占用率用于指示分配给所述第二组件的内存被占用的比例；

所述写入模块，用于当所述第二组件的内存占用率小于第一比例时，通过所述第一组件将所述图片数据写入缓冲区。

可选的，所述装置还包括：

第二占用率获取模块，用于在所述写入模块通过所述第一组件将所述图片数据写入缓冲区之前，通过所述第一组件获取所述第一组件的内存占用率，所述第一组件的内存占用率用于指示分配给所述第一组件的内存被占用的比例；

所述写入模块，用于当所述第一组件的内存占用率大于第二比例时，通过所述第一组件将所述图片数据写入缓冲区。

可选的，所述第一组件是Java组件，分配给所述第一组件的内存为Java堆内存；

所述第二组件是Native组件，分配给所述第二组件的内存为Native堆内存。

又一方面，提供了一种计算机设备，所述计算机设备包含处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上所述的图片解码方法。

又一方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如上所述的图片解码方法。

本申请提供的技术方案可以包括以下有益效果：

当应用程序中的第一组件接收到外部输入的加载图片的加载请求时，可以不直接在第一组件对应的内存中进行图片解码，而是通过共享内存的方式将图片数据传递给使用不同内存的第二组件，由第二组件进行解码，从而可以避免图片解码过程占用第一组件的内存而导致的内存溢出异常，从而减少图片解码时对第一组件的内存占用，提高解码效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1是本申请一示例性实施例涉及的系统框架示意图；

图2是根据一示例性实施例实施例示出的一种图片解码流程示意图；

图3是图2所示实施例涉及的一种图片解码流程的示意图；

图4是根据一示例性实施例示出的一种图片解码方法的流程图；

图5是根据一示例性实施例示出的一种图片解码的框架图；

图6是图5所示实施例涉及的一种图片解码流程示意图；

图7是本申请一个示例性实施例提供的图片解码装置的方框图；

图8是根据一示例性实施例示出的一种计算机设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

本申请提出了一种图片解码方案，该方案能够减少图片解码过程中的内存溢出的情况，从而提高解码效率。

本申请所示的方案可以应用在计算机设备中。其中，该计算机设备可以是具有图片展示功能的设备。例如，该计算机设备可以是智能手机、平板电脑、电子书阅读器等移动终端，或者，计算机设备也可以是台式计算机、笔记本电脑或者个人工作站等个人计算机(Personal Computer，PC)，或者，该计算机设备也可以是智能眼镜、智能手表等智能可穿戴设备，或者，该计算机设备也可以是车载计算机等等。

在一种可能的实现方式中，本申请所示的方案可以由计算机设备中安装并运行的应用程序来实现。

以安卓平台为例，请参考图1，其示出了本申请一示例性实施例涉及的系统框架示意图。安卓系统架构采用了分层架构，如图1所示，安卓系统架构可以分为四层架构，从高到低分别是Android应用层110、Android应用框架层120、Android系统运行层130和Linux内核层104。

其中，Android应用层110中运行应用程序，比如安卓系统内置的应用程序或者用户自行安装的第三方应用程序。

应用程序通常使用Java语言编写的，每一个应用程序由一个或者多个活动组成，活动以Activity类为超类，活动类似于操作系统上的进程，但是活动比操作系统的进程要更为灵活，与进程类似的是，活动可以在多种状态之间进行切换。

此外，应用程序中也可以存在部分使用Java之外的语言(比如C/C++)编写的组件，比如Native组件，其中，Native组件是使用C++语言编码并编译为原生机器码执行的代码组件。

Android应用框架层120设计简化了组件的重用；任何一个应用程序都可以发布它的功能块，并且任何其它的应用程序都可以使用其所发布的功能块(需要遵循框架的安全性限制)。Android应用框架层120可以帮助程序员快速的开发程序，并且该应用程序重用机制也使用户可以方便的替换程序组件。

Android应用框架层120中包含一系列的服务和系统，比如：

a、丰富而又可扩展的视图(Views)，可以用来构建应用程序，它包括列表(lists)，网格(grids)，文本框(text boxes)，按钮(buttons)，甚至可嵌入的web浏览器。

b.内容提供器(Content Providers)使得应用程序可以访问另一个应用程序的数据(如联系人数据库)，或者共享它们自己的数据。

c.资源管理器(Resource Manager)提供非代码资源的访问，如本地字符串，图形，和布局文件(layout files)。

d.通知管理器(Notification Manager)使得应用程序可以在状态栏中显示自定义的提示信息。

e.活动管理器(Activity Manager)用来管理应用程序生命周期并提供常用的导航回退功能。

Android系统运行层130也称为Android系统运行库层，其可以包括程序库和Android运行库。

其中，程序库包含一些C/C++库，这些库能被Android系统中不同的组件使用。C/C++库通过Android应用程序框架为应用程序提供服务。这些C/C++库可以包括基本的C库、支持各种多媒体格式的多媒体库、位图和矢量字体库、2D和3D图形引擎、浏览器、数据库(比如SQLite)等等。

Android运行库包括了一个核心库，该核心库提供了Java编程语言核心库的大多数功能。

例如，每一个Android应用程序可以在它自己的进程中运行，且拥有一个独立的Dalvik虚拟机实例。Dalvik被设计成一个设备可以同时高效地运行多个虚拟系统。Dalvik虚拟机执行(.dex)的Dalvik可执行文件，该格式文件针对小内存使用做了优化。同时虚拟机是基于寄存器的，各个类可以经由Java编译器编译，然后通过SDK中的"dx"工具转化成.dex格式由虚拟机执行。Dalvik虚拟机依赖于linux内核的一些功能，比如线程机制和底层内存管理机制。

Android的核心系统服务依赖于Linux内核层104，如安全性、内存管理、进程管理、网络协议栈和驱动模型等。

Linux内核也同时作为硬件和软件栈之间的抽象层。此外，还对其做了部分修改，主要涉及两部分修改：

a)Binder：提供有效的进程间通信。

b)电源管理：为手持设备节省能耗。

本申请所示的方案，可以应用在图1所示系统架构中的Android应用层110中，其方案逻辑可以由Android应用层110中的应用程序来实现。

以图1所示的系统架构为例，在相关技术中，如果应用程序通过Java组件直接使用安卓提供的图片解码类BitmapFactory的相关方法将输入源转换为Bitmap(位图)对象，如使用BitmapFactory.decodeFile()方法接受文件作为输入，并在当前线程中同步地解码并返回Bitmap对象，则该Bitmap对象的解码后的图片数据会存在于Java堆内存中；而由于BitmapFactory返回的Bitmap对象占用了Java堆内存，易导致Java堆内存占用超过限制而引发OOM异常。此外，解码得到Bitmap对象后续需要被Native组件调用，而在Native中需要通过额外的方法(例如lockPixels方法)获取Java堆内存中图像数据，且无法保证该方法可以成功获取到图像数据。此外，由于该解码过程是在当前线程中同步执行，在处理大量图片时，需要串行执行，容易导致主线程的卡顿。

图2是根据一示例性实施例实施例示出的一种图片解码流程示意图。其中，该图片解码流程可以由上述的计算机设备执行。例如，该计算机设备可以是移动终端、个人计算机、智能可穿戴设备或者车载计算机等等。该图片解码流程可以如下：

S21，通过应用程序中的第一组件获取待解码的图片数据。

S22，通过第一组件将该图片数据写入缓冲区，该缓冲区由该第一组件与该应用程序中的第二组件共享；该第一组件与该第二组件被分配不同的内存。

S23，通过第二组件从该缓冲区中提取该图片数据。

S24，通过第二组件，在分配给该第二组件的内存中对该图片数据进行解码。

其中，上述第一组件和第二组件可以是应用程序中，通过不同的语言编写的代码组件，且第一组件和第二组件被分配不同的内存。

例如，在Android系统中，上述第一组件可以是Java语言编写的Java组件，第二组件可以是C++语言编写的Native组件。

或者，在iOS系统中，上述第一组件可以是Object C语言编写的代码组件，第二组件可以是C语言编写的代码组件。

通过本申请所示的方案，当应用程序中的第一组件接收到外部输入的加载图片的加载请求时，可以不直接在第一组件对应的内存中进行图片解码，而是通过共享内存的方式将图片数据传递给使用不同内存的第二组件，由第二组件进行解码，从而可以避免图片解码过程占用第一组件的内存而导致的内存溢出异常，从而减少图片解码时对第一组件的内存占用，提高解码效率。

例如，以第一组件是Java组件，第二组件是Native组件为例，请参考图3，其示出了本申请实施例涉及的一种图片解码流程的示意图。

如图3所示，应用程序中的Java组件接收到外部输入加载请求(S31)，该加载请求中可以包含需要加载的图片的地址，比如统一资源定位符(Uniform Resource Locator，URL)或者，图片在计算机设备中的存储路径(path)等。Java组件根据图片地址或者存储路径获取图片数据(S32)，并将获取到的图片数据缓存到与Native组件共享的缓冲区中(S33)。之后，应用程序中的Native组件从缓冲区读取图片数据(S34)，并在Native堆内存中进行图片解码(S35)，获得解码后的图片数据。

在上述过程中，在收到外部的输入后，Java组件可以通过资源获取模块，根据输入的数据获取统一的输入流，再经过加载模块加载到一块合适大小的字节缓冲区(ByteBuffer)内存中，再将ByteBuffer送至Native组件的解码模块，使用libpng/libjpeg等Native库进行解码，得到最终的图像数据。在此过程中，Java堆内存中不会产生图片解码和数据存储，从而减少图片解码时Java堆内存的占用，提高了解码效率。

图4是根据一示例性实施例示出的一种图片解码方法的流程图，该图片解码方法可以由上述的计算机设备执行。例如，该计算机设备可以是移动终端、个人计算机、智能可穿戴设备或者车载计算机等等。以第一组件是Java组件，第二组件是Native组件为例，如图4所示，该图片解码方法可以包括如下步骤：

步骤401，通过应用程序中的第一组件接收渲染引擎发送的加载请求。

在本申请实施例中，计算机设备中的应用程序在执行过程中，当有图片展示需求时，渲染引擎可以向应用程序中的解码组件发送用于请求加载图片的加载请求，其中，该加载请求中可以包含待加载的图片的存储位置，该存储位置可以网络位置(比如URL)或者本地位置(比如存储路径)。

在本申请实施例中，应用程序中的解码组件可以包含第一组件和第二组件，并且，其中，第一组件与该第二组件被分配不同的内存。例如，第一组件和第二组件是基于不同的语言编写的代码组件。

比如，以Android平台为例，假设第一组件是Java组件，第二组件是Native组件，系统分配给Java组件的内存是Java堆内存，而分配给该Native组件的内存为Native堆内存。

在本申请实施例中，渲染引擎可以将加载请求发送给应用程序的解码组件中的第一组件。

步骤402，通过应用程序中的第一组件获取待解码的图片数据。

计算机设备通过应用程序中的第一组件接收到加载请求后，即可以通过第一组件根据待加载的图片的存储位置，获取待解码的图片数据。

比如，在本申请实施例中，以第一组件是Java组件为例，Java组件可以根据待加载的图片的存储位置，将图片资源转化为输入流(Input Stream)。

步骤403，通过该第一组件对该图片数据进行预解码，获得该图片数据对应的图片的图片信息，该图片信息包括图片格式以及图片尺寸中的至少一种。

在本申请实施例中，计算机设备可以通过第一组件对输入的图片数据进行预解码，该预解码过程是指对图片数据进行有限度的解码，以得到该图片数据对应的图片信息，比如图片格式以及图片尺寸等。

步骤404，当该图片信息满足解码条件时，通过该第一组件将该图片数据写入缓冲区，该缓冲区由该第一组件与该应用程序中的第二组件共享。

其中，计算机设备通过第一组件对图片数据进行预解码，获得图片数据对应的图片信息后，可以判断该图片信息是否满足解码条件。

比如，当上述图片信息包括图片格式时，计算机设备可以判断第二组件是否支持对该图片格式对应的图片数据进行解码，若是，则确定该图片信息满足解码条件；否则，可以确定该图片信息不满足解码条件。

再比如，当上述图片信息包括图片尺寸时，计算机设备可以判断第二组件支持解码的图片尺寸是否大于该图片数据对应的图片尺寸，若是，则确定该图片信息满足解码条件；否则，可以确定该图片信息不满足解码条件。

再比如，当上述图片信息包括图片格式以及图片尺寸时，计算机设备可以判断第二组件是否支持对该图片格式对应的图片数据进行解码，并判断第二组件支持解码的图片尺寸是否大于该图片数据对应的图片尺寸，若第二组件支持对该图片格式对应的图片数据进行解码，并且第二组件支持解码的图片尺寸大于该图片数据对应的图片尺寸，则确定该图片信息满足解码条件；如上述两个条件中的任一条件不满足，则可以确定该图片信息不满足解码条件。

在确定上述图片信息满足解码条件后，计算机设备可以通过第一组件将该图片数据写入缓冲区。例如，以第一组件是Java组件为例，Java组件可以将上述输入流写入缓冲区。

在一种可能的实现方式中，上述缓冲区是可以由第一组件和第二组件共享的缓冲区，比如，以第一组件是Java组件，第二组件是Native组件为例，上述缓冲区可以是字节缓冲区ByteBuffer；或者，上述缓冲区也可以是由Java组件和Native组件共享的其它类型的缓冲区。

可选的，如果确定上述图片信息不满足解码条件，则计算机设备可以通过第一组件返回解码异常的响应。

可选的，在通过该第一组件将该图片数据写入缓冲区之前，计算机设备还可以通过该第一组件申请该缓冲区，该缓冲区占用的内存是分配给该第二组件的内存中的一部分。

在本申请实施例中，第一组件在申请缓冲区时，可以在分配给第二组件的内存中申请该缓冲区，这样可以进一步减少解码过程对第一组件的内存的占用。

例如，以第一组件是Java组件，第二组件是Native组件为例，Java组件在申请缓冲区时，可以在分配给Native组件的Native堆内存中申请一块内存作为缓存图片数据的ByteBuffer，这样可以减少解码过程对Java堆内存的占用，减少Java堆内存发生内存溢出异常的概率。

可选的，在通过该第一组件将该图片数据写入缓冲区之前，计算机设备还可以通过该第一组件获取该第二组件的内存占用率，该第二组件层的内存占用率用于指示分配给该第二组件的内存被占用的比例；当该第二组件的内存占用率小于第一比例时，通过该第一组件将该图片数据写入缓冲区。

在本申请实施例中，第一组件在将图片数据写入缓冲区之前，还可以获取被分配给第二组件的内存的内存占用率，如果第二组件对应的内存占用率较低，此时说明第二组件具有足够的内存进行图片解码，解码导致分配给第二组件的内存发生内存溢出异常的概率较低，此时，第一组件可以将图片数据写入缓冲区；反之，如果第二组件对应的内存占用率过高，则通过第二组件进行图片解码可能会导致分配给第二组件的内存发生内存溢出异常，此时，第一组件可以不将图片数据写入缓冲区，比如，此时计算机设备可以通过第一组件直接在分配给第一组件的内存中进行图片解码。

例如，以第一组件是Java组件，第二组件是Native组件为例，Java组件在将图片数据写入ByteBuffer之前，可以获取Native堆内存的内存占用率，如果Native堆内存的内存占用率小于一定的阈值，则将图片数据写入ByteBuffer，否则，直接在Java堆内存中进行图片解码。

可选的，在通过该第一组件将该图片数据写入缓冲区之前，计算机设备还可以通过该第一组件获取该第一组件的内存占用率，该第一组件的内存占用率用于指示分配给该第一组件的内存被占用的比例；当该第一组件的内存占用率大于第二比例时，通过该第一组件将该图片数据写入缓冲区。

在本申请实施例中，第一组件在将图片数据写入缓冲区之前，还可以获取被分配给第一组件的内存的内存占用率，如果第一组件对应的内存占用率较低，此时说明第一组件具有足够的内存进行图片解码，解码导致分配给第一组件的内存发生内存溢出异常的概率较低，此时，第一组件可以直接在分配给第一组件的内存中进行图片解码；反之，如果第一组件对应的内存占用率过高，则通过第一组件进行图片解码可能会导致分配给第一组件的内存发生内存溢出异常，此时，第一组件可以将图片数据写入缓冲区，以便通过第二组件进行图片解码。

例如，以第一组件是Java组件，第二组件是Native组件为例，Java组件在将图片数据写入ByteBuffer之前，可以获取Java堆内存的内存占用率，如果Java堆内存的内存占用率小于一定的阈值，则直接在Java堆内存中进行图片解码，否则，将图片数据写入ByteBuffer。

其中，上述第一比例或者第二比例可以是开发人员在应用程序中预先设置的比例阈值。

步骤405，通过应用程序的第二组件从该缓冲区中提取该图片数据。

在本申请实施例中，由于上述缓冲区是由第一组件和第二组件共享的，因此，计算机设备可以通过第二组件从缓冲区中提取待解码的图片数据，以便后续解码。

其中，在通过第一组件将图片数据写入缓冲区之后，计算机设备可以通过第一组件调用第二组件对应的方法，将缓冲区的内存地址作为参数传入，使得第二组件可以提取缓冲区中的图片数据。

步骤406，通过该第二组件，在分配给该第二组件的内存中对该图片数据进行解码。

在本申请实施例中，计算机设备可以通过第二组件，调用该第二组件可用的解码库进行解码。

例如，以上述第二组件是Native组件为例，Native组件可以在Native堆内存中，调用libjpeg/libpng等图片解码库对图片数据进行解码。可选的，Native组件也可以使用其他解码库进行图片解码，比如使用Skia图形库等，以提高解码效率。

可选的，计算机设备还通过该第二组件将对该图片数据的解码结果存储在分配给该第二组件的内存中。

在本申请实施例中，通过第二组件对图片数据的解码结果可以存储在分配给该第二组件的内存，以减少对分配给第一组件的内存的占用。

例如，以上述第二组件是Native组件为例，解码结果可以存储在Native堆内存中。

此外，由于在图片加载过程中，解码后的图片数据后续需要被其它Native组件(比如渲染引擎)调用，而如果解码结果存储在Java堆内存中，则其它Native组件调用解码后的图片数据时，需要通过指定的方法来从Java堆内存中获取，该获取方式的效率和成功率都较低。而本申请实施例所示的方案，解码结果存储在Native堆内存中，其它Native组件需要时可以直接从Native堆内存调用，从而提高了解码后的图片数据的调用效率和成功率。

可选的，计算机设备通过该第二组件，在分配给该第二组件的内存中对该图片数据进行解码时，可以通过该第二组件创建独立线程；并通过该独立线程对该图片数据进行解码。

在本申请实施例中，通过第二组件可以对不同的图片数据创建不同的独立线程，对不同的图片数据并行的进行解码。

例如，以第一组件是Java组件，第二组件是Native组件为例，Java组件将图片数据1的缓冲区地址传入Native组件后，Native组件创建一个线程A对图片数据1进行解码，在解码过程中，Java组件又将图片数据2的缓冲区地址传入Native组件，则Native组件创建一个线程B对图片数据2进行解码，这样图片数据1和图片数据2可以并行的解码，从而在待解码的图片较多时，能够显著的提高图片解码的效率。

可选的，在通过该第二组件对该图片数据解码成功后，回收该缓冲区占用的内存。

在本申请实施例中，第二组件对图片数据解码成功后，可以主动的回收缓冲区占用的内容，避免第二组件对应的内存资源的浪费。

比如，以第一组件是Java组件，第二组件是Native组件为例，在Java语言中，由于存在了垃圾自动回收机制，一般不去主动释放不用的对象所占的内存，而在C/C++语言中，需要代码组件主动去释放不使用的内存资源。在本申请实施例中，由于缓冲区是有Java组件来申请的，而Java组件并不会主动释放不实用的内存资源，而通过Native组件来执行缓冲区资源回收的逻辑，可以减少Native堆内存的资源浪费，提高Native堆内存的有效利用率。

步骤407，通过该第二组件将该解码结果的内存地址返回给该第一组件。

在本申请实施例中，通过第二组件对图片数据进行解码之后，还需要将解码结果通知给第一组件，在此过程中，计算机设备可以通过第二组件将解码结果的内存地址返回给该第一组件。

可选的，在通过该第二组件，将该解码结果的内存地址返回给该第一组件时，计算机设备可以通过该第二组件，将该解码结果的内存地址写入指定类型对象，该指定类型对象是该第一组件支持的对象；然后将写入该解码结果的内存地址的该指定类型对象返回给该第一组件。

例如，以第一组件是Java组件，第二组件是Native组件为例，在本申请实施例中，计算机设备可以通过Native组件，将解码结果的内存地址写入到Java对象中，并将Java对象返回给Java组件，由Java组件获取Java对象中的解码结果的内存地址。

步骤408，通过第一组件向渲染引擎返回加载完成响应。

其中，第一组件获取到第二组件对图片数据进行解码后的解码结果的内存地址后，可以将解码结果的内存地址携带在加载完成响应中发送给渲染引擎，以通知渲染引擎继续执行后续步骤。

比如，第一组件在接收到加载请求时，可以对应该加载请求注册一个回调函数，当第一组件获取到第二组件返回的解码结果的内存地址后，可以通过该回调函数，将解码结果的内存地址返回给渲染引擎。

可选的，上述加载完成响应中还可以包含图片数据的其它信息，比如尺寸信息等等。

综上所述，本申请实施例提供的方案，当应用程序中的第一组件接收到外部输入的加载图片的加载请求时，可以不直接在第一组件对应的内存中进行图片解码，而是通过共享内存的方式将图片数据传递给使用不同内存的第二组件，由第二组件进行解码，且解码得到的解码结果存储在分配给第二组件的内存中，从而可以避免图片解码过程，以及解码后的图片数据占用第一组件的内存而导致的内存溢出异常，从而减少图片解码时对第一组件的内存占用，提高解码效率。

此外，本申请实施例提供的方案中，第二组件在进行解码时，通过独立的解码线程对图片数据进行解码，也就是说，多个图片对应的图片数据可以并行的进行解码，从而提高了图片解码效率。

另外，由于解码得到的解码结果存储在分配给第二组件的内存中，当上述第二组件是Native组件时，解码结果可以由后续其它的Native组件直接进行调用，提高了解码后的图片数据的调用效率和成功率。

其中，本申请上述实施例所示的方案以第一组件是安卓平台中的Java组件，第二组件是安卓平台中的Native组件为例进行说明，可选的，上述实施例所示的方案也可以应用到其他平台中的其它类型组件中。

图5是根据一示例性实施例示出的一种图片解码的框架图，以第一组件是Java组件，第二组件是Native组件为例，如图5所示，本申请实施例提出了一种在安卓平台上使用Native解码图片的通用方案。请参考图5，应用程序中的解码组件包括第一组件(即Java组件)和第二组件(即Native组件)，应用程序的渲染引擎有图片解码需求时，向Java组件发送加载请求(S51)，在Java组件中根据图片输入源的类型(文件路径/Url等)选择合适的处理器将输入源转换为输入流，再从输入流中加载数据储存在字节缓冲区ByteBuffer中与Native组件共享(S52)，然后在Native组件中使用libjpeg/libpng等图片解码库在独立的线程中进行图片解码，得到解码后储存在Native堆内存(即分配给第二组件的内存)中的图片数据(S53)；之后，在Native组件向Java组件返回解码结果的内存地址(S54)，由Java组件向渲染引擎返回解码结果的内存地址和图片尺寸(S55)。该方案可以有效地降低图片解码过程占用的Java堆内存，得到的Native堆内存中的图片数据可以安全地供其他Native组件后续使用，异步的解码过程在同时并行解码大量图片时可以显著地降低对主线程(即Java线程)的占用，提高应用流畅度。

请参考图6，其实出本申请实施例涉及的一种图片解码流程示意图。如图6所示，上述图5中的图片解码框架实现的解码流程可以如下：

S61，在系统初始化过程中，外部可以注册一系列的资源获取类。

其中，该资源获取类具有两个方法，一是判断某个输入是否可以用该资源获取类获取图片资源；二是使用该获取类获取图片资源，返回InputStream。

例如，当输入的加载请求中包含一个文件路径时，该获取类使用该路径创建一个FileInputStream并返回。

注册资源获取类允许外部自定义系统可以处理的输入类型，并根据不同的输入类型获取统一的图片资源，这些资源获取类被保存在一个列表中供之后的获取过程使用。

S62，当外部请求加载图片时，输入一个对象(如文件路径/url等)至Java组件，系统通过Java组件保存该次加载请求，并新建一个线程用于该次解码过程。

S63，Java组件保存加载请求，注册回调。

S64，Java组件遍历已注册的资源获取类列表。

S65，依次检查是否有资源获取类可以处理该输入的加载请求。

S66，判断是否找到可处理该输入的获取类，若是，则异常退出，反之，则进入S67。

S67，使用获取类获取到对应的InputStream输入流。

S68，获取到对应的InputStream输入流后，Java组件首先使用BitmapFactory的decodeStream方法，传入inJustDecodeBounds参数，设置只解码出图片的长宽信息。

S69，Java组件使用ByteBuffer的allocDirect方法申请一块1KB的内存空间作为缓冲区，使用ByteBuffer的原因是其申请的内存空间存在于Native堆内存中，可以由Native组件直接获取。

S610，Java组件循环读取InputStream的内容并存放在缓冲区ByteBuffer。

S611，Java组件统计读取的字节数，并判断ByteBuffer目前容量是否充足，如果容量不足，则进入S612，否则，进入S613。

S612，重新申请一块当前容量+1KB的缓冲区ByteBuffer，将旧ByteBuffer中内容复制到新的中并释放旧ByteBuffer，直到当前ByteBuffer可以存放所有的输入数据。

S613，ByteBuffer生成完毕后，Java组件通过jni调用Native组件，将ByteBuffer的内存地址作为参数传入。

S614，Native组件获取ByteBuffer的内存地址，并从ByteBuffer中提取图片数据。

S615，Native组件使用libpng/libjpeg的相关接口判断数据类型，并将数据进行解码，将解码后的结果内存地址保存在新建的Java对象中。

S616，Native组件向Java组件返回该Java对象，并回收ByteBuffer占用的内存。

Java组件接收到Native组件解码返回的Java对象后，根据保存的加载请求找到对应的回调函数，通知请求方(即渲染引擎)加载已完成。

其中，在请求加载时，调用方(即请求方)会传入一个Callback对象，该对象拥有用于通知调用方的onDecodeResult方法，当加载完成时，Java组件会调用该方法传回加载完成的对象，该对象中包含：图片解码后像素数据的内存地址、图片的宽高等。

本申请所示的方案可以作为小游戏引擎的图片解码模块，小游戏引擎中需要接受来自小游戏的图片加载请求，请求的图片通常为存放在资源文件夹中的图片源文件或网络上的图片url，小游戏引擎需要加载图片并解码为图像数据供native的游戏引擎渲染使用。

传统的加载方案占用Java内存过高，并且无法及时回收Bitmap资源，在小游戏需要加载大量图片的场合容易造成OOM异常，采用本方案后可以显著降低内存占用，并行的加载线程提高了图片加载的效率，可以提高应用的流畅度及减少加载时间。

此外，本申请所示方案的扩展性较强，可以通过自定义资源获取类扩展能处理的输入类型；底层的图形解码由开发者控制，可以自定义解码的过程，实现更多图片类型的解码等等。

请参考图7，其示出了本申请一个示例性实施例提供的图片解码装置的方框图，该图片解码装置可以通过硬件或者软硬结合的方式实现为计算机设备的全部或者部分，以实现如上述图2或图4所示实施例中的全部或者部分步骤。如图7所示，该图片解码装置包括：

图片数据获取模块701，用于通过应用程序中的第一组件获取待解码的图片数据；

写入模块702，用于通过所述第一组件将所述图片数据写入缓冲区，所述缓冲区由所述第一组件与所述应用程序中的第二组件共享；所述第一组件与所述第二组件被分配不同的内存；

提取模块703，用于通过所述第二组件从所述缓冲区中提取所述图片数据；

解码模块704，用于通过所述第二组件，在分配给所述第二组件的内存中对所述图片数据进行解码。

可选的，所述装置还包括：

存储模块，用于通过所述第二组件将对所述图片数据的解码结果存储在分配给所述第二组件的内存中。

可选的，所述装置还包括：

地址返回模块，用于通过所述第二组件将所述解码结果的内存地址返回给所述第一组件。

可选的，所述地址返回模块，包括：

地址写入单元，用于通过所述第二组件，将所述解码结果的内存地址写入指定类型对象，所述指定类型对象是所述第一组件支持的对象；

对象返回单元，用于将写入所述解码结果的内存地址的所述指定类型对象返回给所述第一组件。

可选的，所述装置还包括：

预解码模块，用于在所述写入模块702通过所述第一组件将所述图片数据写入缓冲区之前，通过所述第一组件对所述图片数据进行预解码，获得所述图片数据对应的图片的图片信息，所述图片信息包括图片格式以及图片尺寸中的至少一种；

所述写入模块702，用于，

当所述图片信息满足解码条件时，通过所述第一组件将所述图片数据写入缓冲区。

可选的，所述解码模块704，包括：

线程创建单元，用于通过所述第二组件创建独立线程；

解码单元，用于通过所述独立线程对所述图片数据进行解码。

可选的，所述装置还包括：

内存回收模块，用于通过所述第二组件对所述图片数据解码成功后，回收所述缓冲区占用的内存。

可选的，所述装置还包括：

缓冲区申请模块，用于在所述写入模块702通过所述第一组件将所述图片数据写入缓冲区之前，通过所述第一组件申请所述缓冲区，所述缓冲区占用的内存是分配给所述第二组件的内存中的一部分。

可选的，所述装置还包括：

第一占用率获取模块，用于在所述写入模块702通过所述第一组件将所述图片数据写入缓冲区之前，通过所述第一组件获取所述第二组件的内存占用率，所述第二组件层的内存占用率用于指示分配给所述第二组件的内存被占用的比例；

所述写入模块702，用于当所述第二组件的内存占用率小于第一比例时，通过所述第一组件将所述图片数据写入缓冲区。

可选的，所述装置还包括：

第二占用率获取模块，用于在所述写入模块702通过所述第一组件将所述图片数据写入缓冲区之前，通过所述第一组件获取所述第一组件的内存占用率，所述第一组件的内存占用率用于指示分配给所述第一组件的内存被占用的比例；

所述写入模块702，用于当所述第一组件的内存占用率大于第二比例时，通过所述第一组件将所述图片数据写入缓冲区。

可选的，

所述第一组件是Java组件，分配给所述第一组件的内存为Java堆内存；

所述第二组件是Native组件，分配给所述第二组件的内存为Native堆内存。

综上所述，本申请实施例提供的方案，当应用程序中的第一组件接收到外部输入的加载图片的加载请求时，可以不直接在第一组件对应的内存中进行图片解码，而是通过共享内存的方式将图片数据传递给使用不同内存的第二组件，由第二组件进行解码，且解码得到的解码结果存储在分配给第二组件的内存中，从而可以避免图片解码过程，以及解码后的图片数据占用第一组件的内存而导致的内存溢出异常，从而减少图片解码时对第一组件的内存占用，提高解码效率。

此外，本申请实施例提供的方案中，第二组件在进行解码时，通过独立的解码线程对图片数据进行解码，也就是说，多个图片对应的图片数据可以并行的进行解码，从而提高了图片解码效率。

另外，由于解码得到的解码结果存储在分配给第二组件的内存中，当上述第二组件是Native组件时，解码结果可以由后续其它的Native组件直接进行调用，提高了解码后的图片数据的调用效率和成功率。

图8是根据一示例性实施例示出的计算机设备800的结构框图。

通常，计算机设备800包括有：处理器801和存储器802。

处理器801可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器801可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器801也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器801可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器801还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器802可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器802还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器802中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器801所执行以实现本申请中方法实施例提供的方法的全部或者部分步骤。

在一些实施例中，计算机设备800还可选包括有：外围设备接口803和至少一个外围设备。处理器801、存储器802和外围设备接口803之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口803相连。具体地，外围设备包括：射频电路804、触摸显示屏805、摄像头806、音频电路807和电源808中的至少一种。

外围设备接口803可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器801和存储器802。在一些实施例中，处理器801、存储器802和外围设备接口803被集成在同一芯片或电路板上；在一些其他实施例中，处理器801、存储器802和外围设备接口803中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路804用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路804通过电磁信号与通信网络以及其他通信设备进行通信。射频电路804将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路804包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路804可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：万维网、城域网、内联网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路804还可以包括NFC(Near Field Communication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏805用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏805是触摸显示屏时，显示屏805还具有采集在显示屏805的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器801进行处理。此时，显示屏805还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏805可以为一个，设置计算机设备800的前面板；在另一些实施例中，显示屏805可以为至少两个，分别设置在计算机设备800的不同表面或呈折叠设计；在再一些实施例中，显示屏805可以是柔性显示屏，设置在计算机设备800的弯曲表面上或折叠面上。甚至，显示屏805还可以设置成非矩形的不规则图形，也即异形屏。显示屏805可以采用LCD(Liquid Crystal Display，液晶显示屏)、OLED(Organic Light-EmittingDiode,有机发光二极管)等材质制备。

摄像头组件806用于采集图像或视频。可选地，摄像头组件806包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件806还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路807可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器801进行处理，或者输入至射频电路804以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在计算机设备800的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器801或射频电路804的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路807还可以包括耳机插孔。

电源808用于为计算机设备800中的各个组件进行供电。电源808可以是交流电、直流电、一次性电池或可充电电池。当电源808包括可充电电池时，该可充电电池可以是有线充电电池或无线充电电池。有线充电电池是通过有线线路充电的电池，无线充电电池是通过无线线圈充电的电池。该可充电电池还可以用于支持快充技术。

在一些实施例中，计算机设备800还包括有一个或多个传感器810。该一个或多个传感器810包括但不限于：加速度传感器811、陀螺仪传感器812、压力传感器813、光学传感器814以及接近传感器815。

加速度传感器811可以检测以计算机设备800建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器811可以用于检测重力加速度在三个坐标轴上的分量。处理器801可以根据加速度传感器811采集的重力加速度信号，控制触摸显示屏805以横向视图或纵向视图进行用户界面的显示。加速度传感器811还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器812可以检测计算机设备800的机体方向及转动角度，陀螺仪传感器812可以与加速度传感器811协同采集用户对计算机设备800的3D动作。处理器801根据陀螺仪传感器812采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器813可以设置在计算机设备800的侧边框和/或触摸显示屏805的下层。当压力传感器813设置在计算机设备800的侧边框时，可以检测用户对计算机设备800的握持信号，由处理器801根据压力传感器813采集的握持信号进行左右手识别或快捷操作。当压力传感器813设置在触摸显示屏805的下层时，由处理器801根据用户对触摸显示屏805的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

光学传感器814用于采集环境光强度。在一个实施例中，处理器801可以根据光学传感器814采集的环境光强度，控制触摸显示屏805的显示亮度。具体地，当环境光强度较高时，调高触摸显示屏805的显示亮度；当环境光强度较低时，调低触摸显示屏805的显示亮度。在另一个实施例中，处理器801还可以根据光学传感器814采集的环境光强度，动态调整摄像头组件806的拍摄参数。

接近传感器815，也称距离传感器，通常设置在计算机设备800的前面板。接近传感器815用于采集用户与计算机设备800的正面之间的距离。在一个实施例中，当接近传感器815检测到用户与计算机设备800的正面之间的距离逐渐变小时，由处理器801控制触摸显示屏805从亮屏状态切换为息屏状态；当接近传感器815检测到用户与计算机设备800的正面之间的距离逐渐变大时，由处理器801控制触摸显示屏805从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图8中示出的结构并不构成对计算机设备800的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

在一示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括至少一条指令、至少一段程序、代码集或指令集的存储器，上述至少一条指令、至少一段程序、代码集或指令集可由处理器执行以完成上述图2、或图4对应实施例所示的方法的全部或者部分步骤。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (9)

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

通过应用程序中的第一组件获取待解码的图片数据；

通过所述第一组件申请缓冲区，所述缓冲区占用的内存是分配给第二组件的内存中的一部分；

通过所述第一组件将所述图片数据写入所述缓冲区，所述缓冲区由所述第一组件与所述应用程序中的所述第二组件共享；所述第一组件与所述第二组件被分配不同的内存；

通过所述第二组件从所述缓冲区中提取所述图片数据；

通过所述第二组件创建独立线程，所述第二组件支持针对不同图片数据创建不同的独立线程，以实现对不同图片数据进行并行解码；

通过所述独立线程基于所述第二组件可用的解码库对所述图片数据进行解码；

通过所述第二组件将对所述图片数据的解码结果存储在分配给所述第二组件的内存中，所述第二组件是Native组件，分配给所述第二组件的内存为Native堆内存；

通过所述第二组件，将所述解码结果的内存地址写入指定类型对象，所述指定类型对象是所述第一组件支持的对象；

将写入所述解码结果的内存地址的所述指定类型对象返回给所述第一组件。

2.根据权利要求1所述的方法，其特征在于，所述通过所述第一组件将所述图片数据写入缓冲区之前，还包括：

通过所述第一组件对所述图片数据进行预解码，获得所述图片数据对应的图片的图片信息，所述图片信息包括图片格式以及图片尺寸中的至少一种；

所述通过所述第一组件将所述图片数据写入缓冲区，包括：

当所述图片信息满足解码条件时，通过所述第一组件将所述图片数据写入缓冲区。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

通过所述第二组件对所述图片数据解码成功后，回收所述缓冲区占用的内存。

4.根据权利要求1所述的方法，其特征在于，所述通过所述第一组件将所述图片数据写入缓冲区之前，还包括：

通过所述第一组件获取所述第二组件的内存占用率，所述第二组件层的内存占用率用于指示分配给所述第二组件的内存被占用的比例；

所述通过所述第一组件将所述图片数据写入缓冲区，包括：

当所述第二组件的内存占用率小于第一比例时，通过所述第一组件将所述图片数据写入缓冲区。

5.根据权利要求1所述的方法，其特征在于，所述通过所述第一组件将所述图片数据写入缓冲区之前，还包括：

通过所述第一组件获取所述第一组件的内存占用率，所述第一组件的内存占用率用于指示分配给所述第一组件的内存被占用的比例；

所述通过所述第一组件将所述图片数据写入缓冲区，包括：

当所述第一组件的内存占用率大于第二比例时，通过所述第一组件将所述图片数据写入缓冲区。

6.根据权利要求1至5任一所述的方法，其特征在于，

所述第一组件是Java组件，分配给所述第一组件的内存为Java堆内存。

7.一种图片解码装置，其特征在于，所述装置包括：

图片数据获取模块，用于通过应用程序中的第一组件获取待解码的图片数据；

缓冲区申请模块，用于通过所述第一组件申请缓冲区，所述缓冲区占用的内存是分配给第二组件的内存中的一部分；

写入模块，用于通过所述第一组件将所述图片数据写入所述缓冲区，所述缓冲区由所述第一组件与所述应用程序中的所述第二组件共享；所述第一组件与所述第二组件被分配不同的内存；

提取模块，用于通过所述第二组件从所述缓冲区中提取所述图片数据；

解码模块，用于通过所述第二组件创建独立线程，所述第二组件支持针对不同图片数据创建不同的独立线程，以实现对不同图片数据进行并行解码；

所述解码模块，还用于通过所述独立线程基于所述第二组件可用的解码库对所述图片数据进行解码；

存储模块，用于通过所述第二组件将对所述图片数据的解码结果存储在分配给所述第二组件的内存中，所述第二组件是Native组件，分配给所述第二组件的内存为Native堆内存；

地址返回模块，用于通过所述第二组件，将所述解码结果的内存地址写入指定类型对象，所述指定类型对象是所述第一组件支持的对象；

所述地址返回模块，还用于将写入所述解码结果的内存地址的所述指定类型对象返回给所述第一组件。

8.一种计算机设备，其特征在于，所述计算机设备包括处理器和存储器，所述存储器中存储有指令，所述指令由所述处理器执行，以实现如权利要求1至6任一所述的图片解码方法。

9.一种计算机可读存储介质，其特征在于，所述存储介质中存储有指令，所述指令由计算机设备的处理器执行以实现如权利要求1至6任一所述的图片解码方法。