实现图片加载库的方法及装置与流程

本申请涉及软件开发技术领域，尤其涉及一种实现图片加载库的方法及装置。

背景技术：

在很多应用app中都需要对图片进行展示，而app一般依赖于图片加载库来实现图片的展示功能。目前，可供开发者选用的开源的图片加载库较多，不同的app往往选用不同的图片加载库来实现图片展示。在相关技术中，由于当前不同的图片加载库在实现代码上存在较大差异，当需要切换某app依赖的图片加载库时，通常需要较大幅度地修改app的业务代码，使得图片加载库切换过程较为低效。

技术实现要素：

有鉴于此，本申请提供一种实现图片加载库的方法及装置。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种实现图片加载库的方法，包括：

定义在多个图片加载库通用的应用程序编程接口api，所述应用程序编程接口api用于在业务代码中被调用；

在每一图片加载库的功能实现文件中分别通过代码实现所述应用程序编程接口api的功能。

根据本申请的第二方面，提出了一种实现图片加载库的方法，包括：

在接收到代码编译指令后，根据配置文件，确定业务代码依赖的目标图片加载库；

从多个待选图片加载库的功能实现文件中，选取与所述目标图片加载库对应的功能实现文件；其中每一功能实现文件分别用于实现在业务代码中被调用的应用程序编程接口api的功能，所述应用程序编程接口api在多个图片加载库通用；

利用选取的功能实现文件进行编译。

根据本申请的第三方面，提出了一种实现图片加载库的装置，包括：

api定义单元，用于定义在多个图片加载库通用的应用程序编程接口api，所述应用程序编程接口api用于在业务代码中被调用；

功能实现单元，用于在每一图片加载库的功能实现文件中分别通过代码实现所述应用程序编程接口api的功能。

根据本申请的第四方面，提出了一种实现图片加载库的装置，包括：

加载库确定单元，用于在接收到代码编译指令后，根据配置文件，确定业务代码依赖的目标图片加载库；

选取单元，用于从多个待选图片加载库的功能实现文件中，选取与所述目标图片加载库对应的功能实现文件，其中每一功能实现文件分别用于实现在业务代码中被调用的应用程序编程接口api的功能，所述应用程序编程接口api在多个图片加载库通用；

编译单元，用于利用选取的功能实现文件进行编译。

本申请实施例中，通过定义在多个图片加载库通用的应用程序编程接口api，在业务代码中调用所述通用的应用程序编程接口api，并在每一图片加载库的功能实现文件中，分别通过代码实现所述应用程序编程接口api的功能。使得当需要切换应用app依赖的图片加载库时，用户只需要通过修改配置文件来修改业务代码依赖的图片加载库，而不需要修改业务代码，从而实现高效的图片加载库切换过程。

另一方面，在代码编译时，可以根据用户在切换图片加载库时修改的配置文件，确定所需切换使用的图片加载库，以从多个待选图片加载库的功能实现文件中，选定与所述目标图片加载库对应的功能实现文件进行编译。可见，用户只需要修改配置文件中的依赖关系并重新编译代码，便可实现高效的图片加载库切换过程。

附图说明

图1是本申请一示例性实施例提供的一种实现图片加载库的方法的流程图；

图2是本申请一示例性实施例中的app代码架构图；

图3示出了本申请一示例性实施例中定义的通用api及通用image控件属性；

图4是本申请另一实施例提供的实现图片加载库的方法的流程图；

图5是本申请一示例性实施例提供的一种实现图片加载库的装置的框图；

图6是本申请一示例性实施例提供的另一种实现图片加载库的装置的框图。

具体实施方式

在很多智能设备的操作系统中，均需要采用图片加载库来实现加载图片并展示。以android系统为例，目前开源的图片加载库包括但不限于：google推出的glide图片加载库、facebook推出的fresco图片加载库及square推出的picasso图片加载库等。在各种app的开发过程中都会选用合适的图片加载库用以实现图片展示，图片展示效果及性能的好坏往往决定了用户对app的使用体验，所以，如何选择合适的图片加载库是app开发者所关注的重点之一。当前，随着技术发展，很多功能更强大、性能更优异的图片加载库也不断涌现，所以，将已有的图片加载库代码进行扩展或迁移到业务代码中，已成为了很多app开发者的需求。然而，由于各app使用不同的图片加载库，代码基本无法被复用。由于目前不同的图片加载库在实现代码(如api的差异)上存在较大差异，其增加了学习成本、bug出现概率以及bug的修复成本。当需要切换某app依赖的图片加载库或将某图片加载库代码进行迁移时，通常需要较大幅度地修改app的业务代码，使得图片加载库切换过程较为低效。举例而言，假设某app原先使用的是fresco图片加载库，此时需要将picasso图片加载库的代码迁移到该app(即将原先的fresco图片加载库代码替换为picasso图片加载库代码)，在此过程中，开发者除了需要删除fresco图片加载库的实现代码文件，并增加picasso图片加载库的实现代码文件，还需要修改app业务代码中所有调用fresco图片加载库的api的地方，这极大地增加了代码迁移的困难性。鉴于上述问题，本文提出了一种便于实现图片加载库迁移的方案。

图1是本申请一示例性实施例提供的一种实现图片加载库的方法的流程图。如图1所示，本申请实施例中，该方法包括下述步骤101～102，其中：

在步骤101中，定义在多个图片加载库通用的api，其中，所述api用于在业务代码中被调用。

图片加载库一般提供一些供app业务层(业务代码)调用的api

(applicationprogramminginterface,应用程序编程接口)，这些api可以用于通过某种逻辑或方法实现某些功能(如：图片下载、加载、展示等功能)。

参图2所示，本申请实施例提出的一种新的app代码架构包括：业务层(businesslayer)、架构层(frameworklayer)及插件实现层(pluginlayer)。其中，通过架构层将业务层代码和图片加载库的具体实现代码分离，通过定义在各图片加载库的通用的api，在插件实现层以插件的形式具体实现各个图片加载库的api功能。其中，本实施例中，可以在架构层通过java文件定义通用api，以使得业务层可以通过架构层的java文件确定可以调用图片加载库的哪些通用api。

在定义通用api之前，可以抽象出各个待选图片加载库的图片绘制行为(imageviewaction)及一些扩展功能，并根据抽象出的图片绘制行为(imageviewaction)及一些扩展功能来分别定义通用api。参图3所示，举例来说，与图片绘制行为(imageviewaction)对应的通用api可以包括：“render”、“setloadinglistener”、“setprogresslistener”等。与扩展功能对应的通用api可以包括：“setimageuri”、“setboarder”、“setplaceholderimage”等。

在步骤102中，在每一图片加载库的功能实现文件中分别通过代码实现所述应用程序编程接口api的功能。

如图2所示，在插件实现层，每一个图片加载库可以分别通过相应的功能实现文件，来实现上述架构层定义的通用api的功能。本申请实施例中，以插件形式实现的图片加载库可以包括但不限于：picasso图片加载库、fresco图片加载库、glide图片加载库、phenix图片加载库等。以picasso图片加载库为例，在定义了通用api之后，示例性的实现代码如下：

以fresco图片加载库为例，在定义了通用api之后，示例性的实现代码如下：

通过以上示例代码可以看出，picasso图片加载库、fresco图片加载库分别通过代码实现了以上定义的通用api：“render”、“setloadinglistener”、“setprogresslistener”等的功能。

本申请实施例中，还可以进一步定义在多个图片加载库通用的image控件属性，其中，所述通用的image控件属性在实现所述应用程序编程接口api的功能时被使用。举例来说，通用的image控件属性可以包括：“anyfailureimage”、“anyroundbottomleft”、“anyprogressbarimage”等。在插件实现层的实现代码中，可以对这些通用的image控件属性进行赋值。此外，本申请可以根据实际需要，扩展需要定义的image控件属性。

本申请实施例中，通过定义在多个图片加载库通用的应用程序编程接口api，在业务代码中调用所述通用的应用程序编程接口api，并在每一图片加载库的功能实现文件中，分别通过代码实现所述应用程序编程接口api的功能。通过定义通用api，可以使用业务代码和图片加载库实现代码分离。当需要切换应用app依赖的图片加载库时，用户只需要通过修改配置文件来修改业务代码依赖的图片加载库，而不需要修改业务代码，从而实现高效的图片加载库切换过程。

图4是本申请另一实施例提供的实现图片加载库的方法的流程图。如图4所示，本申请实施例中，该方法用于实现快递的图片加载库切换过程，包括如下步骤201～202，其中：

在步骤201中，在接收到代码编译指令后，根据配置文件，确定业务代码依赖的目标图片加载库。

其中，配置文件(如：gradle文件)用于描述app业务代码所依赖的图片加载库。举例而言，配置文件中的依赖内容如下：

dependencies{

compile'com.alibaba.android.anyimageview-fresco:1.0.0'

}

其中，“anyimageview-fresco:1.0.0”便是业务代码依赖的目标图片加载库。

在步骤202中，从多个待选图片加载库的功能实现文件中，选取与所述目标图片加载库对应的功能实现文件，其中，每一功能实现文件分别用于实现在业务代码中被调用的应用程序编程接口api的功能，所述应用程序编程接口api在多个图片加载库通用。

在步骤203中，利用选取的功能实现文件进行编译。

如上述实施例，在定义了通用api之后，可以通过各个待选图片加载库的功能实现文件分别实现通用api的功能。例如，已插件的形式分别实现picasso图片加载库、fresco图片加载库，并在打包picasso图片加载库、fresco图片加载库对应的功能实现文件时均命名为：“com.alibaba.android.anyimageview”，并存于不同的目录下。这样，根据上述步骤201确定的目标图片加载库：“anyimageview-fresco:1.0.0”，并可以选定fresco图片加载库对应目录下的名为“com.alibaba.android.anyimageview”功能实现文件，并将其代码加载进来进行编译。

可见，用户在需要切换app使用的图片加载库时，只需要修改配置文件中的一行用于描述依赖对象的代码并重新进行代码编译即可，例如：将“compile'com.alibaba.android.anyimageview-fresco:1.0.0'”修改为“compile'com.alibaba.android.anyimageview-picasso:1.0.0'”，而避免了大幅修改业务代码中依赖的api的过程，实现高效的图片加载库切换过程，提升app开发效率，使得图片加载库的代码可复用性、可迁移性更好。

通过本申请实施例提供的上述方法，能够解决电子设备上的app依赖的图片加载库扩展、切换或迁移的问题。一种应用场景例如是：根据实际业务需求，需要在app1中集成app2的业务，但是，app1和app2使用不同的图片加载库实现图片展示功能，使得在app1中集成app2的业务的开发成本很高。利用本申请实施例提供的上述方法，通过定义各个图片加载库统一通用的api及图片控件属性，并在app1和app2中的图片加载库实现代码中实现这些通用的api，使得需要在app1中集成app2的业务时，并通过修改配置文件的方式，使得app1和app2的业务可以依赖各自的图片加载库，使得app集成成本大大降低。

图5是本申请一示例性实施例提供的一种实现图片加载库的装置的框图。在硬件层面，该装置可以被应用于电子设备上，所述电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成上述图5所示的装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。基于以上方法的实现逻辑，该装置包括：

api定义单元301，用于定义在多个图片加载库通用的应用程序编程接口api，其中，所述应用程序编程接口api用于在业务代码中被调用。

功能实现单元302，用于在每一图片加载库的功能实现文件中分别通过代码实现所述应用程序编程接口api的功能。

其中，以java为例，api定义单元301和功能实现单元302可以分别通过相应的java文件来实现以上api定义及api实现过程。

本申请一可选实施例中，所述装置还包括：

控件属性定义单元，用于定义在多个图片加载库通用的image控件属性；

所述功能实现单元在实现所述应用程序编程接口api的功能时使用上述通用的image控件属性。

图6是本申请一示例性实施例提供的另一种实现图片加载库的装置的框图。在硬件层面，该装置可以被应用于电子设备上，所述电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成上述图6所示的装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。基于以上方法的实现逻辑，该装置包括：

加载库确定单元401，用于在接收到代码编译指令后，根据所述配置文件，确定业务代码依赖的目标图片加载库；

选取单元402，用于从多个待选图片加载库的功能实现文件中，选取与所述目标图片加载库对应的功能实现文件，每一功能实现文件分别用于实现在业务代码中被调用的应用程序编程接口api的功能，所述应用程序编程接口api在多个图片加载库通用。

编译单元403，用于利用选取的功能实现文件进行编译。

本申请一可选实施例中，每一功能实现文件在实现所述在多个图片加载库通用的功能时使用在多个图片加载库通用的image控件属性。

需说明的是，上述装置实施例和上述方法实施例，在不相违背的前提下，可以互为补充。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。