CN112947905A - 一种图片加载方法、装置 - Google Patents

Abstract

本申请的实施例提供了一种图片加载方法、装置。该图片加载方法包括：跨平台移动UI端的图片控件将图片加载请求发送至原生端，所述图片加载请求中包括图片地址和所述图片控件的标识；所述原生端基于所述图片控件的标识建立图片载体以实现所述图片控件和所述图片载体的关联；所述原生端基于所述图片地址获取目标图片，并将所述目标图片存储在所述图片载体上；所述跨平台移动UI端基于所述图片控件和所述图片载体之间的关联关系调用所述目标图片进行加载。本申请实施例的技术方案能够复用已经加载过的图片，并根据需要进行加载，减少内存占用。

Description

一种图片加载方法、装置

技术领域

本申请涉及计算机及通信技术领域，具体而言，涉及一种图片加载方法、装置。

背景技术

Flutter是Google开发的一套全新的跨平台、开源UI框架，支持iOS、Android系统开发，可以快速在IOS和Android上构建高质量的原生用户界面，许多程序员在源码编写过程中会选择使用Flutter框架进行编写。但由于Flutter框架本身具有限制，在图片加载的场景中，已经在原生端(Native)加载过的图片在Flutter端会二次加载，图片像素数据被完整加载到内存中，从而触发内存溢出，甚至崩溃，大量图片频繁展示，导致频繁的垃圾回收，引发界面卡顿，严重影响用户的使用体验。

发明内容

本申请的实施例提供了一种图片加载方法、装置，进而至少在一定程度上能够复用已经加载过的图片，并根据需要进行加载，减少内存占用。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请实施例的一个方面，提供了一种图片加载方法，包括：跨平台移动UI端的图片控件将图片加载请求发送至原生端，所述图片加载请求中包括图片地址和所述图片控件的标识；所述原生端基于所述图片控件的标识建立图片载体以实现所述图片控件和所述图片载体的关联；所述原生端基于所述图片地址获取目标图片，并将所述目标图片存储在所述图片载体上；所述跨平台移动UI端基于所述图片控件和所述图片载体之间的关联关系调用所述目标图片进行加载。

根据本申请实施例的一个方面，提供了一种图片加载装置，包括：发送模块，用于跨平台移动UI端的图片控件将图片加载请求发送至原生端，所述图片加载请求中包括图片地址和所述图片控件的标识；建立模块，用于所述原生端基于所述图片控件的标识建立图片载体以实现所述图片控件和所述图片载体的关联；获取模块，用于所述原生端基于所述图片地址获取目标图片，并将所述目标图片存储在所述图片载体上；加载模块，用于所述跨平台移动UI端基于所述图片控件和所述图片载体之间的关联关系调用所述目标图片进行加载。

在本申请的一些实施例中，基于前述方案，所述图片加载装置还包括：关联模块，用于所述跨平台移动UI端基于所述图片控件的标识建立所述跨平台移动UI端的纹理层与所述图片控件的关联，从而基于所述图片控件和所述图片载体之间的关联关系实现所述纹理层与所述图片载体的关联；渲染模块，用于所述跨平台移动UI端基于所述纹理层与所述图片载体之间的关联关系对所述目标图片进行渲染，生成待展示图片。

在本申请的一些实施例中，基于前述方案，所述渲染模块包括：发送单元，用于基于所述纹理层与所述图片载体之间的关联关系，所述纹理层向所述图片载体发送图片渲染请求；绑定单元，用于所述图片载体在接收到所述图片渲染请求后，将所述目标图片绑定至纹理标识，并共享所述纹理标识至所述跨平台移动UI端；生成单元，用于所述跨平台移动UI端对所述纹理标识对应的纹理进行渲染，生成待展示图片。

在本申请的一些实施例中，基于前述方案，所述获取模块被配置为：所述原生端将所述图片地址发送至所述原生端的图片加载器；所述原生端的图片加载器根据所述图片地址返回目标图片。

在本申请的一些实施例中，基于前述方案，所述发送模块被配置为：跨平台移动UI端的图片控件将图片加载请求发送至所述跨平台移动UI端的通道代理，以使所述跨平台移动UI端的通道代理将所述图片加载请求发送至原生端的通道代理；所述原生端的通道代理在接收到所述图片加载请求后，将所述图片加载请求发送至所述原生端。

在本申请的一些实施例中，基于前述方案，所述图片加载装置还用于：所述图片控件获取所述目标图片的图片参数信息；根据所述目标图片的图片参数信息调整所述图片控件的大小及比例。

在本申请的一些实施例中，基于前述方案，在所述绑定单元用于所述图片载体在接收到所述图片渲染请求后，将所述目标图片绑定至纹理标识，并共享所述纹理标识至所述跨平台移动UI端之前，所述图片加载装置还用于：跨平台移动UI端将所述跨平台移动UI端的上下文共享于原生端；根据所述上下文的共享实现所述跨平台UI端与所述原生端之间的纹理共享。

在本申请的一些实施例中，基于前述方案，所述发送单元包括：获取子单元，用于基于所述纹理层与所述图片载体之间的关联关系，所述纹理层从所述跨平台移动UI端的渲染代理中心获取与所述图片载体对应的渲染代理对象；发送子单元，用于通过所述渲染代理对象，所述纹理层将所述图片渲染请求发送至所述图片载体。

在本申请的一些实施例中，基于前述方案，所述获取子单元用于基于所述纹理层与所述图片载体之间的关联关系，所述纹理层从所述跨平台移动UI端的渲染代理中心获取与所述图片载体对应的渲染代理对象之前，所述图片加载装置还用于：所述图片载体将与所述图片载体对应的渲染代理对象注册到所述跨平台移动UI端的渲染代理中心中。

根据本申请实施例的一个方面，提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的图片加载方法。

根据本申请实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的图片加载方法。

在本申请的一些实施例所提供的技术方案中，跨平台移动UI端的图片控件通过将图片加载请求发送至原生端，原生端根据图片加载请求中的图片控件的标识创建图片载体，从而实现原生端的图片载体与跨平台移动UI端的图片控件之间的关联，原生端在根据图片加载请求中的图片地址获取到目标图片后，将目标图片存储在图片载体上，从而使得跨平台移动UI端基于图片控件与图片载体的关联关系可以调用目标图片进行加载。可见，在本申请中的技术方案中，跨平台移动UI端通过建立与原生端的关联关系，基于关联关系从原生端获取图片进行加载，从而能够实现对原生端已经加载过的图片的复用，同时由于原生端已经加载过的图片是按需加载的，从而在跨平台移动UI端也能够实现对图片的按需加载，从而减少了对内存的占用。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了可以应用本申请实施例的技术方案的一个示例性系统架构的示意图；

图2示出了根据本申请的一个实施例的图片加载方法的流程图；

图3示出了根据本申请的一个实施例的图片加载方法的流程图；

图4示出了根据本申请的一个实施例的图片加载方法的流程图；

图5示出了根据本申请的一个实施例的图片加载方法的流程图；

图6示出了根据本申请的一个实施例的图片加载方法的流程图；

图7示出了根据本申请的一个实施例的图片加载方法的流程图；

图8示出了根据本申请的一个实施例的图片加载方法的流程图；

图9示出了根据本申请的一个实施例的共享渲染环境的流程示意图；

图10示出了根据本申请的一个实施例的图片加载的流程示意图；

图11示出了根据本申请的一个实施例的图片渲染的流程示意图；

图12示出了根据本申请的一个实施例的图像处理装置的框图；

图13示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

图1示出了可以应用本申请实施例的技术方案的示例性系统架构的示意图。

如图1所示，系统架构可以包括跨平台移动UI端101和原生端102，跨平台移动UI端101是跨平台移动UI开发端，通过业务框架构建在Android系统或iOS系统上同时运行的用户界面应用，用户界面应用不会受限于终端设备的操作系统类型，保证跨平台的运行用户界面应用。跨平台移动UI端101的业务框架支持一系列的服务和组件，例如，图1中所示出的图片控件，以用于构建跨平台用户界面应用，进而在所构建的跨平台用户界面应用中实现列表、网格、文本框和按钮，甚至内嵌的网页浏览器等基本的支撑功能，并且通过数据的交互而达成自身与外部的交互。在一个示例性实施例的具体实现中，跨平台移动UI端101的业务框架可以是Flutter开发框架。

应当理解，对于跨平台用户界面应用而言，业务框架包含了其业务逻辑的全部实现，跨平台用户界面应用所需实现的所有业务和功能，都在业务框架内构建了所对应的业务逻辑。

原生端102与终端设备的操作系统相关，原生端102通过原生方法可以实现一系列原生功能，比如，可以使用操作系统直接支持的编程语言编写应用，可以调用操作系统的硬件功能等。原生方法，即为本地(Native)方法(函数)，是指对实现某特定功能(如图片处理、加密解密、数据库或任意的扩展功能)的一系列本地代码，每一原生方法都是由一系列的本地代码，即Native Code形成的，本地代码是使用计算机语言，比如C系语言(包括C/C++语言)编写的代码，用来在终端设备的处理器上运行。

应该理解，图1中的跨平台移动UI端101所示出的图片控件，原生端102所示出的图片载体的数目仅仅是示意性的。根据实现需要，可以具有任意数目的图片控件以及图片载体等。

在本申请的一个实施例中，跨平台移动UI端101的图片控件将图片加载请求发送至原生端102，图片加载请求中包括图片地址和图片控件的标识，原生端102基于图片控件的标识建立图片载体以实现图片控件和图片载体的关联。

在本申请的一个实施例中，在原生端102接收到图片加载请求并建立图片载体后，原生端102的图片载体可以根据图片地址获取目标图片，并将获取到的目标图片存储在图片载体上。

在本申请的一个实施例中，原生端102的图片载体可以将图片加载请求转发至图片加载器中，图片加载器根据图片加载请求中包含的图片地址判断图片缓冲池中是否存在目标图片，若存在，图片加载器则向图片载体返回目标图片，若不存在，图片加载器则根据图片地址远程获取目标图片，然后向图片载体返回目标图片。

在本申请的一个实施例中，在目标图片被存储在图片载体上之后，跨平台移动UI端101可以基于图片控件和图片载体之间的关联关系调用目标图片进行加载。

在本申请的一个实施例中，目标图片被存储在原生端102的图片载体上后，图片载体可以向跨平台移动UI端101的图片控件返回目标图片数据，图片控件可以获取目标图片的宽高信息，从而根据该宽高信息调整图片控件的大小及比例。

在本申请的一个实施例中，跨平台移动UI端101还可以与原生端102进行渲染环境的共享，跨平台移动UI端101将渲染环境的上下文共享于原生端102，从而实现在跨平台UI端101与原生端102之间的渲染环境的共享。

在本申请的一个实施例中，在跨平台UI端101与原生端102之间实现渲染环境的共享之后，跨平台UI端101可以将图片渲染请求发送至原生端102，原生端102根据图片渲染请求将目标图片绑定至纹理标识，然后向跨平台UI端101共享该纹理标识，从而使得跨平台UI端101对该纹理标识对应的纹理进行渲染，生成待展示图片。

在本申请的一个实施例中，跨平台移动UI端101可以基于图片控件的标识建立跨平台移动UI端101的纹理层与图片控件的关联，从而基于图片控件和图片载体之间的关联关系实现跨平台UI端101的纹理层将图片渲染请求发送至原生端102的图片载体。

以下对本申请实施例的技术方案的实现细节进行详细阐述：

图2示出了根据本申请的一个实施例的图片加载方法的流程图，参照图2所示，所述方法包括：

步骤S210、跨平台移动UI端的图片控件将图片加载请求发送至原生端，所述图片加载请求中包括图片地址和所述图片控件的标识；

步骤S220、所述原生端基于所述图片控件的标识建立图片载体以实现所述图片控件和所述图片载体的关联；

步骤S230、所述原生端基于所述图片地址获取目标图片，并将所述目标图片存储在所述图片载体上；

步骤S240、所述跨平台移动UI端基于所述图片控件和所述图片载体之间的关联关系调用所述目标图片进行加载。

下面对这些步骤进行详细描述。

在步骤S210中，跨平台移动UI端的图片控件将图片加载请求发送至原生端，所述图片加载请求中包括图片地址和所述图片控件的标识。

其中，跨平台移动UI端是跨平台移动UI开发端，通过业务框架构建在Android系统或iOS系统上同时运行的用户界面应用，用户界面应用不会受限于终端设备的操作系统类型，保证跨平台的运行用户界面应用。跨平台移动UI端的业务框架支持一系列的服务和组件，例如，解析引擎、ImageWidget，以用于构建一个跨平台用户界面应用，进而在所构建的跨平台用户界面应用中实现列表、网格、文本框和按钮，甚至内嵌的网页浏览器等基本的支撑功能，并且通过数据的交互而达成自身与外部的交互。在一个示例性实施例的具体实现中，跨平台移动UI端的业务框架为Flutter开发框架。

应当理解，对于跨平台用户界面应用而言，业务框架包含了其业务逻辑的全部实现，跨平台用户界面应用所需实现的所有业务和功能，都在业务框架内构建了所对应的业务逻辑。

原生端与终端设备的操作系统相关，原生端通过原生方法可以实现一系列原生功能，比如，可以使用操作系统直接支持的编程语言编写应用，可以调用操作系统的硬件功能等。原生方法，即为本地(Native)方法(函数)，是指对实现某特定功能(如图像处理、加密解密、数据库或任意的扩展功能)的一系列本地代码，每一原生方法都是由一系列的本地代码，即Native Code形成的，本地代码是使用计算机语言，比如C系语言(包括C/C++语言)编写的代码，用来在终端设备的处理器上运行。

在本申请的一个实施例中，经由跨平台移动UI端的业务框架而搭建的跨平台用户界面应用，都是由此业务框架内指定计算机语言的代码开发实现，并运行于此业务框架内。经由此业务框架而搭建的跨平台用户界面应用，其虽然通过业务框架内业务逻辑的执行而实现自身页面的显示以及业务、功能的实现，但是，在图片加载的场景中，已经在原生端加载过的图片在跨平台移动UI端会二次加载，图片像素数据被完整加载到内存中，从而触发内存溢出，甚至崩溃，因此，本申请可以由跨平台移动UI端的图片控件向原生端发送图片加载请求，从而在跨平台移动UI端复用原生端已经加载过的图片。

在本申请的一个实施例中，图片控件是跨平台移动UI端业务框架所支持的用于显示图片的控件，图片控件向原生端发送的图片加载请求中包括了图片地址以及图片控件的标识。其中，图片地址可以包括图片对应的统一资源定位符(Uniform ResourceLocator，URL)，例如图片的URL地址是：http://img1.gtimg.com/news/pics/hv1/184/217/1227/79841194.jpg。将跨平台移动UI端用户界面展示的内容全部抽象为独立的控件，每一个控件有一个控件名称，并配有唯一的标识，即图片控件的标识。

在本申请的一个实施例中，跨平台移动UI端的图片控件将图片加载请求发送至原生端的方式可以是跨平台移动UI端的图片控件向跨平台移动UI端的通道代理发送图片加载请求，然后由跨平台移动UI端的通道代理将图片加载请求发送至原生端的通道代理，最后由原生端的通道代理发送至原生端，如图3所示，步骤S230具体包括：

步骤S2301、跨平台移动UI端的图片控件将图片加载请求发送至所述跨平台移动UI端的通道代理，以使所述跨平台移动UI端的通道代理将所述图片加载请求发送至原生端的通道代理；

步骤S2302、所述原生端的通道代理在接收到所述图片加载请求后，将所述图片加载请求发送至所述原生端。

在步骤S2301中，跨平台移动UI端的图片控件将图片加载请求发送至所述跨平台移动UI端的通道代理，以使所述跨平台移动UI端的通道代理将所述图片加载请求发送至原生端的通道代理。

跨平台移动UI端的通道代理与原生端的通道代理之间通过通信信道相连接，因此在跨平台移动UI端的图片控件发起图片加载请求后，图片控件可以首先将图片加载请求发送至跨平台移动UI端的通道代理，以使跨平台移动UI端的通道代理将图片加载请求通过通信信道传递到原生端的通道代理。

在步骤S2302中，所述原生端的通道代理在接收到所述图片加载请求后，将所述图片加载请求发送至所述原生端。

原生端的通道代理通过通信通道接收到图片加载请求后，再将图片加载请求发送至原生端。

继续参见图2，在步骤S220中，所述原生端基于所述图片控件的标识建立图片载体以实现所述图片控件和所述图片载体的关联。

在本申请的一个实施例中，原生端在接收到图片加载请求后，可基于图片控件的标识建立图片载体，图片载体，顾名思义是用于承载图片的载体。基于图片控件的标识实现图片控件与图片载体的关联可以是通过图片控件的标识将图片控件与图片载体进行绑定，也就是图片载体被赋予了图片控件的标识。如前所述，每一个图片控件配有唯一的标识，每一个图片控件具有对应的图片载体，因此每一个图片载体也具有唯一的标识，该标识即为对应的图片控件的标识。通过图片控件与图片载体的关联可以实现跨平台移动UI端与原生端之间的关联。

在步骤S230中，所述原生端基于所述图片地址获取目标图片，并将所述目标图片存储在所述图片载体上。

原生端根据图片地址可以首先判断本地是否已经加载过图片地址对应的目标图片，如果确定本地已经加载过目标图片，则将从本地存储空间中获取目标图片，并将目标图片存储在图片载体上，如果确定本地没有加载过目标图片，则基于图片地址从远程获取目标图片，例如从服务器上进行下载。

在本发明的一个实施例中，原生端基于图片地址获取与图片地址对应的目标图片还可以是将图片加载请求发送到图片加载器，图片加载器是原生端用于进行图片加载的处理器，图片加载器可以实现对图片进行按需加载，如图4所示，原生端基于所述图片地址获取目标图片具体包括：

步骤S410、所述原生端将所述图片地址发送至所述原生端的图片加载器；

步骤S420、所述原生端的图片加载器根据所述图片地址返回目标图片。

在本申请的一个实施例中，图片加载器根据图片地址判断图片缓冲池中是否存在目标图片，如果存在，则从图片缓冲池中返回目标图片，图片缓冲池存储有原生端加载过的图片。

应该理解的是，如果图片加载器判断出图片缓冲池中不存在目标图片，则图片加载器可以通过图片地址从远程下载目标图片，加载至图片缓冲池中。

继续参见图2，在步骤S240中，所述跨平台移动UI端基于所述图片控件和所述图片载体之间的关联关系调用所述目标图片进行加载。

随着终端设备所安装跨平台用户界面应用的启动以及在此业务框架内业务逻辑的执行，跨平台移动UI端可以基于图片控件和图片载体之间的关联关系从原生端调用目标图片进行加载。

上述实施例所提供的技术方案中，跨平台移动UI端通过建立与原生端的关联关系，并基于此关联关系从原生端获取图片进行加载，从而能够实现对原生端已经加载过的图片的复用，同时由于原生端已经加载过的图片是按需加载的，从而在跨平台移动UI端也能够实现对图片的按需加载，减少对内存的占用。

在本申请的一个实施例中，在原生端获取到目标图片，并存储在图片载体上后，跨平台移动UI端的图片控件可以从原生端的图片载体上获取目标图片的图片参数信息，图片参数信息可以包括图片的宽、高等信息，图片控件可以根据目标图片的宽高信息相应地调整图片控件的大小及比例，这样图片控件可以适配于目标图片的大小，从而能够对目标图片进行准确地展示。

可以理解的是，跨平台移动UI端用户界面展示的内容类型大小各不相同，相应地，在获取目标图片后，为了便于展示，需要根据目标图片的宽高等信息相应调整图片控件初始化默认的大小及比例。

终端设备所安装跨平台用户界面应用要显示图片，其中，图片加载和图片渲染是必不可少的过程，跨平台移动UI端通过建立与原生端的关联关系，基于关联关系从原生端获取目标图片进行加载后，需要通过对目标图片进行渲染才能显示于用户界面之上，如图5所示，所述方法还包括：

步骤S510、所述跨平台移动UI端基于所述图片控件的标识建立所述跨平台移动UI端的纹理层与所述图片控件的关联，从而基于所述图片控件和所述图片载体之间的关联关系实现所述纹理层与所述图片载体的关联；

步骤S520、所述跨平台移动UI端基于所述纹理层与所述图片载体之间的关联关系对所述目标图片进行渲染，生成待展示图片。

在步骤S510中，所述跨平台移动UI端基于所述图片控件的标识建立所述跨平台移动UI端的纹理层与所述图片控件的关联，从而基于所述图片控件和所述图片载体之间的关联关系实现所述纹理层与所述图片载体的关联。

跨平台移动UI端的纹理层用于接收图片渲染请求，并将该图片渲染请求发送至原生端。因此，在通过纹理层发送图片渲染请求之前，还需要建立跨平台移动UI端的纹理层与原生端的图片载体之间的关联关系。而原生端的图片载体与跨平台移动UI端的图片控件是基于图片控件的标识建立了关联关系，因而，可以通过赋予跨平台移动UI端的纹理层以图片控件的标识，从而使得纹理层与图片控件基于图片控件的标识建立关联关系，而图片控件与原生端的图片载体同样基于图片控件的标识进行关联，从而图片控件、纹理层以及图片载体三者建立起了关联关系。

继续参见图5，在步骤S520中，所述跨平台移动UI端基于所述纹理层与所述图片载体之间的关联关系对所述目标图片进行渲染，生成待展示图片。

在本申请的一个实施例中，跨平台移动UI端的渲染线程触发渲染，将图片渲染请求发送至纹理层，纹理层接收到图片渲染请求后，可以基于纹理层与图片载体之间的关联关系将图片渲染请求发送至图片载体，图片载体在接收到图片渲染请求后，可以向纹理层返回图片渲染请求对应的目标图片，跨平台移动UI端根据接收到的目标图片生成纹理标识，从而对纹理标识对应的纹理数据进行渲染，生成待展示图片。

在本申请的一个实施例中，原生端的图片载体可以通过与跨平台移动UI端共享渲染环境，从而使得跨平台移动UI端可以基于渲染环境的共享实现对目标图片的渲染，如图6所示，步骤S520具体包括：

步骤S5201、基于所述纹理层与所述图片载体之间的关联关系，所述纹理层向所述图片载体发送图片渲染请求；

步骤S5202、所述图片载体在接收到所述图片渲染请求后，将所述目标图片绑定至纹理标识，并共享所述纹理标识至所述纹理层；

步骤S5203、所述纹理层对所述纹理标识对应的纹理进行渲染，生成待展示图片。

在步骤S5201中，基于所述纹理层与所述图片载体之间的关联关系，所述纹理层向所述图片载体发送图片渲染请求。

如前所述，纹理层与图片载体通过图片控件的标识建立了关联关系，因此在纹理层接收到图片渲染请求后，可以基于与图片载体的关联关系，将图片渲染请求发送至对应的图片载体。

在本申请的一个实施例中，纹理层向图片载体发送图片渲染请求的方式可以是纹理层根据图片渲染请求从跨平台移动UI端的渲染代理中心获取图片载体对应的渲染代理对象，然后通过渲染代理对象将图片渲染请求发送至原生端的图片载体，如图7所示，步骤S5201具体包括：

步骤S52011、基于所述纹理层与所述图片载体之间的关联关系，所述纹理层从所述跨平台移动UI端的渲染代理中心获取与所述图片载体对应的渲染代理对象；

步骤S52012、通过所述渲染代理对象，所述纹理层将所述图片渲染请求发送至所述图片载体。

在步骤S52011中，基于所述纹理层与所述图片载体之间的关联关系，所述纹理层从所述跨平台移动UI端的渲染代理中心获取与图片载体对应的渲染代理对象。

在本申请的一个实施例中，为了实现原生端与跨平台移动UI端之间的互访，原生端的图片载体可以通过渲染代理对象与跨平台移动UI端进行通信，图片载体与渲染代理对象是一一对应的关系，而跨平台移动UI端通过渲染代理中心实现与原生端的渲染代理对象之间进行通信。因此纹理层在接收到图片渲染请求后，可以从跨平台移动UI端的渲染代理中心获取与图片载体对应的渲染代理对象，然后通过该渲染代理对象将图片渲染请求发送至图片载体。

在本申请的一个实施例中，所述纹理层从所述跨平台移动UI端的渲染代理中心获取与所述图片载体对应的渲染代理对象之前，还包括：

所述图片载体将与所述图片载体对应的渲染代理对象注册到所述跨平台移动UI端的渲染代理中心中。

在该实施例中，跨平台移动UI端通过渲染代理中心对原生端的渲染代理对象进行管理，原生端的渲染代理对象必须在渲染代理中心中进行注册，可选的，原生端的图片载体可以将该图片载体绑定的图片控件标识和该图片载体对应的渲染代理对象共同发送至跨平台移动UI端的渲染代理中心中进行注册。渲染代理中心将渲染代理对象和该渲染代理对象对应的标识进行绑定并存储。

继续参见图7，在步骤S52012中，通过所述渲染代理对象，所述纹理层将所述图片渲染请求发送至所述图片载体。

由于纹理层与图片载体通过图片控件的标识建立了关联关系，因此在纹理层接收到图片渲染请求后，可以基于与图片载体的关联关系，获取到与图片载体对应的渲染代理对象，并基于该渲染代理对象将图片渲染请求发送至图片载体。

继续参见图6，在步骤S5202中，所述图片载体在接收到所述图片渲染请求后，将所述目标图片绑定至纹理标识，并共享所述纹理标识至所述纹理层。

在本申请的一个实施例中，图片载体在接收到图片渲染请求之后，可以从原生端的渲染环境中获取纹理标识，并将存储在图片载体上的目标图片绑定至该纹理标识。纹理标识是纹理的标识，纹理标识与纹理一一对应的关系，纹理属于图形学中概念，可以理解为一张二维的位图，具有颜色信息。图片载体将目标图片绑定至纹理标识后，可以将该纹理标识共享至跨平台移动UI端，以实现图片渲染，生成待展示图片。

在本申请的一个实施例中，参见图8，在所述图片载体在接收到所述图片渲染请求后，将所述目标图片绑定至纹理标识，并共享所述纹理标识至所述纹理层之前还包括步骤S810-步骤S820，下面对这些步骤详细进行阐述：

步骤S810、跨平台移动UI端将所述跨平台移动UI端的上下文共享于原生端。

跨平台移动UI端和原生端在对图片进行渲染处理时，为了实现各自的功能，需要各自开启一个线程进行操作，但是如果创建两个独立的渲染线程，无法将渲染的效果同时显示在同一图片中，这时就需要使用共享渲染上下文的方案，即共享渲染环境，可以在两个线程中共享同一渲染资源。

在本申请的一个实施例中，在跨平台移动UI端使用OpenGL渲染引擎，OpenGL(OpenGraphics Library，开放性图形库)是指定义了一个跨编程语言、跨平台的编程接口规格的专业的图形程序接口，它用于二维或者三维图像，是一个功能强大，调用方便的底层图形库。在实际应用中，很多图像处理器都应用了OpenGL进行图像的渲染处理。为了实现跨平台移动UI端和原生端共享渲染上下文，需要构造两者共享的OpenGL Context。OpenGLContext封装了用于OpenGL渲染的场景。例如，在Android系统中，为了实现渲染上下文共享，需要在图片处理时调用eglCreateContext的时候将上一个已经创建好的Context传入即可。

在本申请的一个实施例中，当跨平台移动UI端业务框架内业务逻辑开始执行时，启动OpenGL渲染引擎，创建OpenGL渲染环境，原生端根据跨平台移动UI端的OpenGL渲染环境启动原生端渲染线程，通过原生端渲染线程获取跨平台移动UI端的OpenGL渲染环境中的渲染上下文，创建原生端的OpenGL渲染环境。

继续参见图8，在步骤S820中，根据所述上下文的共享实现所述跨平台UI端与所述原生端之间的纹理共享。

由于跨平台移动UI端与原生端实现了上下文的共享，因此两个OpenGL渲染环境可以实现纹理共享。

继续参见图6，在步骤S5203中，所述跨平台移动UI端对所述纹理标识对应的纹理进行渲染，生成待展示图片。

本申请可以目标图片绑定至一块纹理标识上，将这块纹理标识共享于跨平台移动UI端，通过跨平台移动UI端对该纹理标识对应的纹理进行渲染，生成待展示图片。

图9示出了根据本申请的一个实施例的共享渲染环境的流程示意图。主要包括步骤S910-步骤S950。

步骤S910、判断跨平台移动UI端是否启动，若已经启动，则执行步骤S920，否则执行步骤S930。

步骤S920、启动跨平台移动UI端OpenGL渲染引擎，创建跨平台移动UI端的OpenGL渲染环境。

步骤S930、判断原生端渲染线程是否已创建，若已经创建，则执行步骤S940，否则执行步骤S950。

步骤S940、原生端渲染线程获取跨平台移动UI端的OpenGL渲染环境中的渲染上下文，创建原生端OpenGL渲染环境。

步骤S950、启动原生端渲染线程。

图10示出了根据本申请的一个实施例的图片加载的流程示意图。跨平台移动UI端包括了图片控件1、图片控件2、图片控件3，原生端包括了图片载体1、图片载体2、图片载体3。应当理解的是，图中的图片控件、图片载体可以是任意数目的图片控件和图片载体，本实施例对此不进行限定。

如图10所示，图片加载过程主要包括了步骤S1010-步骤S1080，在进行步骤S1010-步骤S1080的详细说明中以图片控件1进行说明，可以理解步骤S1010-步骤S1080的描述中的图片控件1也可以是图片控件2或者图片控件3。

在步骤S1010中，图片控件1将图片加载请求发送至跨平台移动UI端的通道代理1，图片加载请求中包括了图片地址和图片控件1的标识。

在步骤S1020中，通道代理1在接收到图片加载请求之后，通过通信通道将图片加载请求发送至原生端的通道代理2。

在步骤S1030中，通道代理2在接收到图片加载请求之后，将图片加载请求发送至原生端，原生端根据图片加载请求中的图片控件1的标识创建图片载体1，实现图片控件1与图片载体1一一对应的绑定关系。

在步骤S1040中，图片载体1接收到图片加载请求后，将图片加载请求发送给图片加载器，图片加载器根据图片加载请求中的图片地址获取目标图片。

在步骤S1050中，图片加载器获取与图片地址对应的目标图片之后将向图片载体1返回目标图片数据，目标图片数据包括目标图片的宽高等信息。

在步骤S1060中，图片载体1在接收到图片加载器返回的目标图片后，向通道代理2发送目标图片数据。

在步骤S1070中，通道代理2通过通信通道将目标图片数据发送至通道代理1。

在步骤S1080中，通道代理1向图片控件1返回目标图片数据。

图11示出了根据本申请的一个实施例的图片渲染的流程示意图。在图片渲染阶段，跨平台移动UI端存在一个纹理层1，纹理层1与图片控件1、图片载体1通过图片控件1的标识建立了关联关系。跨平台移动UI端的OpenGL渲染线程根据用户界面应用的刷新频繁触发渲染操作，具体渲染过程包括步骤S1110-步骤S1150：

在步骤S1110中，原生端的图片载体1将渲染代理对象1注册到跨平台移动端的渲染注册中心中，图片载体1与渲染代理对象1具有对应关系。

在步骤S1120中，跨平台移动端的渲染线程触发纹理层1渲染。

在步骤S1130中，纹理层1根据渲染线程触发的图片渲染请求从渲染注册中心获取渲染代理对象1，并将图片渲染请求发送给渲染代理对象1。

由于纹理层1与图片载体1基于图片控件的标识建立了关联关系，而图片载体1与渲染代理对象1也具有对应关系，所以纹理层1基于图片控件的标识可以获取到与图片载体1对应的渲染代理对象1。

步骤S1140，渲染代理对象1接收到图片渲染请求后，将该图片渲染请求发送至图片载体1。

步骤S1150，图片载体1根据图片渲染请求从OpenGL渲染环境中获取纹理标识，并将存储在图片载体1上的目标图片绑定至纹理标识，并将该纹理标识共享至跨平台移动UI端。

跨平台移动UI端获取纹理标识后，对该纹理标识对应的纹理进行渲染，生成待展示图片。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的图像处理方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的图像处理方法的实施例。

图12示出了根据本申请的一个实施例的图片加载装置的框图。

参见图12所示，根据本申请的一个实施例的通信处理装置1200，包括：发送模块1202、建立模块1204、获取模块1206和加载模块1208。

发送模块1202，用于跨平台移动UI端的图片控件将图片加载请求发送至原生端，所述图片加载请求中包括图片地址和所述图片控件的标识；建立模块1204，用于所述原生端基于所述图片控件的标识建立图片载体以实现所述图片控件和所述图片载体的关联；获取模块1206，用于所述原生端基于所述图片地址获取目标图片，并将所述目标图片存储在所述图片载体上；加载模块1208，用于所述跨平台移动UI端基于所述图片控件和所述图片载体之间的关联关系调用所述目标图片进行加载。

在本申请的一些实施例中，所述图片加载装置还包括：关联模块，用于所述跨平台移动UI端基于所述图片控件的标识建立所述跨平台移动UI端的纹理层与所述图片控件的关联，从而基于所述图片控件和所述图片载体之间的关联关系实现所述纹理层与所述图片载体的关联；渲染模块，用于所述跨平台移动UI端基于所述纹理层与所述图片载体之间的关联关系对所述目标图片进行渲染，生成待展示图片。

在本申请的一些实施例中，所述渲染模块包括：发送单元，用于基于所述纹理层与所述图片载体之间的关联关系，所述纹理层向所述图片载体发送图片渲染请求；绑定单元，用于所述图片载体在接收到所述图片渲染请求后，将所述目标图片绑定至纹理标识，并共享所述纹理标识至所述跨平台移动UI端；生成单元，用于所述跨平台移动UI端对所述纹理标识对应的纹理进行渲染，生成待展示图片。

在本申请的一些实施例中，所述获取模块1206被配置为：所述原生端将所述图片地址发送至所述原生端的图片加载器；所述原生端的图片加载器根据所述图片地址返回目标图片。

在本申请的一些实施例中，所述发送模块1202被配置为：跨平台移动UI端的图片控件将图片加载请求发送至所述跨平台移动UI端的通道代理，以使所述跨平台移动UI端的通道代理将所述图片加载请求发送至原生端的通道代理；所述原生端的通道代理在接收到所述图片加载请求后，将所述图片加载请求发送至所述原生端。

在本申请的一些实施例中，所述图片加载装置还用于：所述图片控件获取所述目标图片的图片参数信息；根据所述目标图片的图片参数信息调整所述图片控件的大小及比例。

在本申请的一些实施例中，在所述绑定单元用于所述图片载体在接收到所述图片渲染请求后，将所述目标图片绑定至纹理标识，并共享所述纹理标识至所述跨平台移动UI端之前，所述图片加载装置还用于：跨平台移动UI端将所述跨平台移动UI端的上下文共享于原生端；根据所述上下文的共享实现所述跨平台UI端与所述原生端之间的纹理共享。

在本申请的一些实施例中，所述发送单元包括：获取子单元，用于基于所述纹理层与所述图片载体之间的关联关系，所述纹理层从所述跨平台移动UI端的渲染代理中心获取与所述图片载体对应的渲染代理对象；发送子单元，用于通过所述渲染代理对象，所述纹理层将所述图片渲染请求发送至所述图片载体。

在本申请的一些实施例中，所述获取子单元用于基于所述纹理层与所述图片载体之间的关联关系，所述纹理层从所述跨平台移动UI端的渲染代理中心获取与所述图片载体对应的渲染代理对象之前，所述图片加载装置还用于：所述图片载体将与所述图片载体对应的渲染代理对象注册到所述跨平台移动UI端的渲染代理中心中。

图13示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图13示出的电子设备的计算机系统1300仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图13所示，计算机系统1300包括中央处理单元(Central Processing Unit，CPU)1301，其可以根据存储在只读存储器(Read-Only Memory，ROM)1302中的程序或者从存储部分1308加载到随机访问存储器(Random Access Memory，RAM)1303中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 1303中，还存储有系统操作所需的各种程序和数据。CPU 1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(Input/Output，I/O)接口1305也连接至总线1304。

以下部件连接至I/O接口1305：包括键盘、鼠标等的输入部分1306；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1307；包括硬盘等的存储部分1308；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1309。通信部分1309经由诸如因特网的网络执行通信处理。驱动器1310也根据需要连接至I/O接口1305。可拆卸介质1311，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1310上，以便于从其上读出的计算机程序根据需要被安装入存储部分1308。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分1309从网络上被下载和安装，和/或从可拆卸介质1311被安装。在该计算机程序被中央处理单元(CPU)1301执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

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

Claims (10)

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

跨平台移动UI端的图片控件将图片加载请求发送至原生端，所述图片加载请求中包括图片地址和所述图片控件的标识；

所述原生端基于所述图片控件的标识建立图片载体以实现所述图片控件和所述图片载体的关联；

所述原生端基于所述图片地址获取目标图片，并将所述目标图片存储在所述图片载体上；

所述跨平台移动UI端基于所述图片控件和所述图片载体之间的关联关系调用所述目标图片进行加载。

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

所述跨平台移动UI端基于所述图片控件的标识建立所述跨平台移动UI端的纹理层与所述图片控件的关联，从而基于所述图片控件和所述图片载体之间的关联关系实现所述纹理层与所述图片载体的关联；

所述跨平台移动UI端基于所述纹理层与所述图片载体之间的关联关系对所述目标图片进行渲染，生成待展示图片。

3.根据权利要求2所述的方法，其特征在于，所述跨平台移动UI端基于所述纹理层与所述图片载体之间的关联关系对所述目标图片进行渲染，生成待展示图片，包括：

基于所述纹理层与所述图片载体之间的关联关系，所述纹理层向所述图片载体发送图片渲染请求；

所述图片载体在接收到所述图片渲染请求后，将所述目标图片绑定至纹理标识，并共享所述纹理标识至所述跨平台移动UI端；

所述跨平台移动UI端对所述纹理标识对应的纹理进行渲染，生成待展示图片。

4.根据权利要求1所述的方法，其特征在于，所述原生端基于所述图片地址获取目标图片，包括：

所述原生端将所述图片地址发送至所述原生端的图片加载器；

所述原生端的图片加载器根据所述图片地址返回目标图片。

5.根据权利要求1所述的方法，其特征在于，所述跨平台移动UI端的图片控件将图片加载请求发送至原生端，包括：

跨平台移动UI端的图片控件将图片加载请求发送至所述跨平台移动UI端的通道代理，以使所述跨平台移动UI端的通道代理将所述图片加载请求发送至原生端的通道代理；

所述原生端的通道代理在接收到所述图片加载请求后，将所述图片加载请求发送至所述原生端。

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

所述图片控件获取所述目标图片的图片参数信息；

根据所述目标图片的图片参数信息调整所述图片控件的大小及比例。

7.根据权利要求1所述的方法，其特征在于，所述图片载体在接收到所述图片渲染请求后，将所述目标图片绑定至纹理标识，并共享所述纹理标识至所述跨平台移动UI端之前，包括：

跨平台移动UI端将所述跨平台移动UI端的上下文共享于原生端；

根据所述上下文的共享实现所述跨平台UI端与所述原生端之间的纹理共享。

8.根据权利要求3所述的方法，其特征在于，所述基于所述纹理层与所述图片载体之间的关联关系，所述纹理层向所述图片载体发送图片渲染请求，包括：

基于所述纹理层与所述图片载体之间的关联关系，所述纹理层从所述跨平台移动UI端的渲染代理中心获取与所述图片载体对应的渲染代理对象；

通过所述渲染代理对象，所述纹理层将所述图片渲染请求发送至所述图片载体。

9.根据权利要求8所述的方法，其特征在于，所述纹理层从所述跨平台移动UI端的渲染代理中心获取与所述图片载体对应的渲染代理对象之前，还包括：

所述图片载体将与所述图片载体对应的渲染代理对象注册到所述跨平台移动UI端的渲染代理中心中。

10.一种图片加载装置，其特征在于，包括：

发送模块，用于跨平台移动UI端的图片控件将图片加载请求发送至原生端，所述图片加载请求中包括图片地址和所述图片控件的标识；

建立模块，用于所述原生端基于所述图片控件的标识建立图片载体以实现所述图片控件和所述图片载体的关联；

获取模块，用于所述原生端基于所述图片地址获取目标图片，并将所述目标图片存储在所述图片载体上；

加载模块，用于所述跨平台移动UI端基于所述图片控件和所述图片载体之间的关联关系调用所述目标图片进行加载。

Images