图片加载方法及装置
技术领域
本说明书涉及互联网领域。
背景技术
目前,互联网领域中的图片加载技术的应用已经十分普及,尤其在手机应用程序(APP)中的应用得到快速发展。
因此,如何提升各种应用场景下图片加载效率,成为目前被广泛关注的问题。
发明内容
本说明书提供了一种图片加载方法及装置,能够在拥有许多大量Bundle(即,工程包)的应用程序(APP)冷启动加载图片的情况下,既有效解决应用程序(APP)第一次加载图片速度慢的问题,又提升了再次加载相同图片的速度,从而总体上降低展示本地图片的耗时。
本申请公开了一种图片加载方法,包括:
响应所述应用程序(APP)的启动指令,确定需要加载的图片在Bundle中的路径,并根据需要加载的图片在Bundle中的路径确定需要加载的图片对应的图片标识;
若内存中存有所述需要加载的图片,则根据需要加载的图片对应的图片标识,从所述内存中读取所述需要加载的图片并展示;否则,根据所述需要加载的图片在Bundle中的路径加载所述图片并展示;
将所述加载过的图片写入所述内存中缓存,其中,根据所述需要加载的图片在Bundle中的路径确定所述图片对应的图片标识。
在一个优选例中,所述若内存中存有所述需要加载的图片,则根据需要加载的图片对应的图片标识,从所述内存中读取所述需要加载的图片并展示;否则,根据所述需要加载的图片在Bundle中的路径加载所述图片并展示的步骤,以及所述将所述加载过的图片写入所述内存中缓存的步骤包括子步骤:
根据所述需要加载的图片对应的图片标识,判断内存中是否存有所述需要加载的图片;
若所述内存中存有所述需要加载的图片,则根据需要加载的图片对应的图片标识,从所述内存中读取所述需要加载的图片并展示;
若所述内存中没有所述需要加载的图片,则根据所述需要加载的图片在Bundle中的路径加载所述图片并展示,并且,将所述需要加载的图片写入所述内存中缓存。
在一个优选例中,所述根据需要加载的图片在Bundle中的路径确定需要加载的图片对应的图片标识的步骤中,将需要加载的图片在Bundle中的路径确定为所述图片对应的图片标识。
在一个优选例中,所述需要加载的图片是指存放在所述应用程序(APP)的安装包里的图片。
在一个优选例中,在所述根据所述需要加载的图片对应的图片标识,判断内存中是否存有所述需要加载的图片的步骤中,如果所述内存中存在与所述需要加载的图片对应的图片标识相同的图片,则确定所述内存中已存有所述需要加载的图片;否则,确定所述内存中没有所述需要加载的图片。
本申请还公开了一种图片加载装置包括:
图片标识确定模块,用于响应所述应用程序(APP)的启动指令,确定需要加载的图片在Bundle中的路径,并根据需要加载的图片在Bundle中的路径确定需要加载的图片对应的图片标识;
内存读取及展示模块,用于若内存中存有所述需要加载的图片,则根据需要加载的图片对应的图片标识,从所述内存中读取所述需要加载的图片并展示;
路径加载及展示模块,用于若内存中没有所述需要加载的图片,则根据所述需要加载的图片在Bundle中的路径加载所述图片并展示;
缓存模块,用于将所述加载过的图片写入所述内存中缓存,其中,根据所述需要加载的图片在Bundle中的路径确定所述图片对应的图片标识。
在一个优选例中,所述需要加载的图片是指存放在所述应用程序(APP)的安装包里的图片。
在一个优选例中,所述内存读取及展示模块中,如果所述内存中存在与所述需要加载的图片对应的图片标识相同的图片,则确定所述内存中已存有所述需要加载的图片;
所述路径加载及展示模块中,如果所述内存中没有与所述需要加载的图片对应的图片标识相同的图片,则确定所述内存中没有所述需要加载的图片。
本申请还公开了一种图片加载设备包括:
存储器,用于存储计算机可执行指令;以及,
处理器,用于在执行所述计算机可执行指令时实现如前文描述的方法中的步骤。
本申请还公开了一种计算机可读存储介质所述计算机可读存储介质中存储有计算机可执行指令,所述计算机可执行指令被处理器执行时实现如前文描述的方法中的步骤。
本说明书实施方式中,在内存中缓存有已加载过的图片,所述图片对应的图片标识为所述图片在Bundle中的路径,当需要加载图片时,将需要加载的图片在Bundle中的路径确定为所述图片对应的图片标识,然后,根据所述图片标识判断内存缓存中是否存有所述需要加载的图片,如果是,则根据所述图片的图片标识,从所述内存缓存中读取所述图片,并展示。否则,根据需要加载的图片在Bundle中的路径加载所述图片,并展示。然后将所述已加载过的图片写入内存缓存,其中,将所述图片在Bundle中的路径确定为所述图片对应的图片标识。由此,在下一次加载相同的图片时,可以根据所述图片的图片标识与图片在Bundle中的路径之间的对应关系,直接在内存中查找并读取及展示。
这样做的好处在于,在拥有许多大量Bundle的应用程序(APP)冷启动加载图片的情况下,既有效解决应用程序(APP)第一次加载图片速度慢的问题,又提升了再次加载相同图片的速度,从而总体上降低展示本地图片的耗时。
本说明书中记载了大量的技术特征,分布在各个技术方案中,如果要罗列出本申请所有可能的技术特征的组合(即技术方案)的话,会使得说明书过于冗长。为了避免这个问题,本说明书上述发明内容中公开的各个技术特征、在下文各个实施方式和例子中公开的各技术特征、以及附图中公开的各个技术特征,都可以自由地互相组合,从而构成各种新的技术方案(这些技术方案均应该视为在本说明书中已经记载),除非这种技术特征的组合在技术上是不可行的。例如,在一个例子中公开了特征A+B+C,在另一个例子中公开了特征A+B+D+E,而特征C和D是起到相同作用的等同技术手段,技术上只要择一使用即可,不可能同时采用,特征E技术上可以与特征C相组合,则,A+B+C+D的方案因技术不可行而应当不被视为已经记载,而A+B+C+E的方案应当视为已经被记载。
附图说明
图1是根据本说明书第一实施方式的图片加载方法的流程示意图;
图2是根据本说明书第二实施方式的图片加载装置的结构示意图。
具体实施方式
在以下的叙述中,为了使读者更好地理解本申请而提出了许多技术细节。但是,本领域的普通技术人员可以理解,即使没有这些技术细节和基于以下各实施方式的种种变化和修改,也可以实现本申请所要求保护的技术方案。
部分概念的说明:
APP冷启动:指移动终端上的应用程序(APP)从非后台任务启动。
bundle:也可以称为“工程包”,具体是指资源文件、二进制文件、插件等的集合,例如HiChat.bundle,就是聊天功能所需的资源文件、二进制文件、插件等的集合。更具体地,指移动终端上的应用程序(APP)的一个具有标准层级结构的工程包,该工程包包含可执行二进制代码,以及相关的资源文件,以及插件等。一般一个业务模块对应一个bundle(工程包),属于这个业务所用到的图片都会放在该bundle(工程包)下。
Bundle资源文件:指移动终端上的应用程序(APP)的资源包,该移动终端可以是智能手机、平板电脑等等。
Bundle中的路径:指图片在应用程序(APP)安装包里的实际物理路径,例如:
/var/containers/Bundle/Application/20669CE6-AEEE-464C-B54B-4858C77018A0/AlipayWallet.APP/HiChat.bundle/chat_icon。
下面将结合附图对本说明书的实施方式作进一步地详细描述。
本申请的发明人发现,现有的加载bundle中图片的方式为:系统提供的+(UIImage*)imageNamed:(NSString*)name方法。具体的,这种方法是:通过传入的文件名对整个工程(即,一个应用程序)进行遍历,并且自动缓存图片。
上述方法存在展示图片非常耗时的缺点,具体的:
如果应用程序(APP)的bundle很多,例如,对于一个大型应用程序(APP),开发时按照业务划分了许多业务模块,一个业务模块对应一个bundle,在这种情况下,冷启动第一次加载图片,将会很耗时。例如,对于某些特定的APP应用(比如支付类APP),每加载一张图片耗时约30ms。具体的,如果诸如支付宝应用程序(APP)中采用上述方式,该应用的bundle资源文件过多,属于每个业务所用到的图片都会放在该业务对应的bundle下。
在这种情况下,第一次加载图片时,由于需要遍历整个应用程序(APP),所以非常耗时。并且,这种情况在支付宝应用程序(APP)的聊天功能,以及支付宝应用程序(APP)在春节期间的活动业务(例如集五福业务)中,也十分明显。
由此,本申请的实施例要解决的技术问题至少包括:在拥有许多大量Bundle的应用程序(APP)冷启动加载图片的情况下,既有效解决应用程序(APP)第一次加载图片速度慢的问题,又提升了再次加载相同图片的速度,从而总体上降低展示本地图片的耗时。
本申请的实施例的核心思想至少包括:在内存中缓存有已加载过的图片,所述图片对应的图片标识为所述图片在Bundle中的路径,当需要加载图片时,将需要加载的图片在Bundle中的路径确定为所述图片对应的图片标识,然后,根据所述图片标识判断内存缓存中是否存有所述需要加载的图片,如果是,则根据所述图片的图片标识,从所述内存缓存中读取所述图片,并展示。否则,根据需要加载的图片在Bundle中的路径加载所述图片,并展示。然后将所述已加载过的图片写入内存缓存,其中,将所述图片在Bundle中的路径确定为所述图片对应的图片标识。由此,在下一次加载相同的图片时,可以根据所述图片的图片标识与图片在Bundle中的路径之间的对应关系,直接在内存中查找并读取及展示。
需指出,本申请的图片加载方法可以用于智能设备中,所述智能设备可以包括智能手机、平板电脑、PDA(Personal Digital Assistant,掌上电脑)、诸如iWatch之类的可穿戴设备等设备。
本说明书的第一实施方式涉及一种图片加载方法,其流程如图1所示,该方法包括以下步骤:
步骤110:接收应用程序(APP)的启动指令。
需指出,本步骤中的图片是指本地图片,即,应用程序(APP)安装包里的图片。
步骤120:响应所述应用程序(APP)的启动指令,确定需要加载的图片在Bundle中的路径,并根据需要加载的图片在Bundle中的路径确定需要加载的图片对应的图片标识。
换句话说,所述需要加载的图片对应的图片标识与所述图片在Bundle中的路径对应,即,将需要加载的图片在Bundle中的路径,确定为所述图片对应的图片标识。需指出,在本说明书的实施方式中,可以是该需要加载的图片在Bundle中的路径,也可以是该路径中的一部分,下面会具体举例。
需指出,本申请的实施例中需要加载的图片,是指存放在所述应用程序(APP)的安装包里的图片,可以是png或jpg格式。
举例来说,需要加载的图片在应用程序(APP)安装包里的实际物理路径为:
/var/containers/Bundle/Application/20669CE6-AEEE-464C-B54B-4858C77018A0/AlipayWallet.APP/HiChat.bundle/chat_icon
则将该需要加载的图片对应的图片标识确定为:
HiChat.bundle/chat_icon
需指出,本步骤中,所述需要加载的图片对应的图片标识与所述图片在Bundle中的路径之间,有特定的对应关系。
这样做的好处在于,通过需要加载的图片对应的图片标识,可以转化为图片在Bundle中的路径,由此,可以直接通过路径加载图片,明显减少加载图片所需的耗时。
接下来,在步骤130-160中,若内存中存有所述需要加载的图片,则根据需要加载的图片对应的图片标识,从所述内存中读取所述需要加载的图片并展示;否则,根据所述需要加载的图片在Bundle中的路径加载所述图片并展示;然后,将所述加载过的图片写入所述内存中缓存,其中,根据所述需要加载的图片在Bundle中的路径确定所述图片对应的图片标识。具体的:
步骤130:根据所述需要加载的图片对应的图片标识判断内存中是否存有所述需要加载的图片,如果是,则执行步骤140,否则,执行步骤150。
需指出,上述内存是指应用程序(APP)启动时,iOS系统为应用程序(APP)分配的空间,在其上读写操作速度比在磁盘上读写操作速度快。
需指出,在本说明书的一个或多个实施例中,预先在内存中缓存有已加载过的图片。其中,这些已加载过的图片对应的图片标识为该图片在Bundle中的路径。
因此,当需要加载图片时,为需要加载的图片确定对应的图片标识,其中,所述需要加载的图片对应的图片标识与所述图片在Bundle中的路径对应,然后就可以根据需要加载的图片对应的图片标识判断内存中是否已存在需要加载的图片,换句话说,是判断该需要加载的图片以前是否已经加载过。
具体的,如果内存中存在与需要加载的图片对应的图片标识相同的图片,则确定内存中已存有需要加载的图片,即,该图片已经加载过并缓存,这种情况下,执行步骤140;否则,确定内存中没有需要加载的图片,这种情况下,执行步骤150。
步骤140:根据需要加载的图片对应的图片标识,从所述内存中读取所述需要加载的图片,并展示。
步骤150:根据所述需要加载的图片在Bundle中的路径加载所述图片,并展示。然后执行步骤160。
需指出,在本步骤中,使用系统方法:
+(UIImage*)imageWithContentsOfFile:(NSString*)path方法。
具体的,上述方法中,传入需要加载的图片在Bundle中的路径(path)参数,如上所述,该参数即需要加载的图片在应用程序(APP)安装包里的实际物理路径,系统直接用该路径加载图片。需指出,根据需要加载的图片在Bundle中的路径加载所述图片是本领域技术人员公知的技术,在此不做赘述。
需指出,在本步骤中,当根据需要加载的图片对应的图片标识确定内存缓存中不存有所述图片的缓存时,并不是通过遍历整个应用程序加载图片文件,而是根据需要加载的图片在Bundle中的路径加载所述图片。
需指出,现有技术中遍历整个应用程序加载图片文件,是指根据图片标识,遍历该应用程序所有的bundle,直到找到指定的图片。对于支付宝之类的具有很多bundle的应用程序(APP),十分耗时。
可见,这样做的好处在于,显著提高了图片加载的速度,具体的,采用上述方式加载一张图片的耗时约1ms,而采用上述现有技术中的通过遍历整个工程加载文件的方式,耗时约30ms,相比之下,加载速度显著提高。
步骤160,将上述需要加载的图片,即已经被加载的图片写入内存缓存,其中,根据所述需要加载的图片在Bundle中的路径确定所述图片对应的图片标识。
进一步需指出,当内存缓存中不存在所述需要加载的图片时,在根据需要加载的图片在Bundle中的路径加载所述图片并展示后,进一步将所述图片写入内存缓存,并且根据该图片在Bundle中的路径确定该图片的图片标识,以供下一次加载使用。
这样做的好处在于,该方式自行实现了已加载的图片的内存缓存机制,弥补了+(UIImage*)imageWithContentsOfFile:(NSString*)path方法本身不会自动缓存图片的缺点。
具体的,将根据需要加载的图片在Bundle中的路径加载所述图片的手段,与根据该加载的图片在Bundle中的路径确定相应的图片标识,并以该图片标识对加载的图片写入内存缓存的手段相结合,使得当下一次需要加载同一个图片时,可以更加方便地先确定需要加载的图片在Bundle中的路径,然后根据需要加载的图片在Bundle中的路径确定该图片对应的图片标识,再根据该图片标识直接在内存缓存中查询到,并进行读取和展示,而不需要再次地根据需要加载的图片在Bundle中的路径加载所述图片,这样进一步提高了整体的图片加载的效率。
进一步需指出,将图片在Bundle中的路径既用于加载该图片,又用于确定该图片在内存缓存时对应的图片标识,即,使图片在Bundle中的路径与该图片在内存缓存时的图片标识对应。
这样做的好处在于,既有效解决了应用程序(APP)第一次加载图片速度慢的问题,又提升了再次加载相同图片的速度。
总的来说,通过上述实施例的图片加载方法,在拥有许多Bundle的应用程序(APP)冷启动加载图片的情况下,既有效解决应用程序(APP)第一次加载图片速度慢的问题,又提升了再次加载相同图片的速度,从而总体上降低展示本地图片的耗时。
实验数据表明,一些社交会话软件的若采用上述图片加载方法,冷启动第一次界面打开速度能够明显提升约1s。
本说明书的第二实施方式涉及一种图片加载装置,其结构如图2所示,该图片加载装置包括:图片标识确定模块,内存读取及展示模块,路径加载及展示模块,以及缓存模块,具体的:
图片标识确定模块,用于响应所述应用程序(APP)的启动指令,确定需要加载的图片在Bundle中的路径,并根据需要加载的图片在Bundle中的路径确定需要加载的图片对应的图片标识;
内存读取及展示模块,用于若内存中存有所述需要加载的图片,则根据需要加载的图片对应的图片标识,从所述内存中读取所述需要加载的图片并展示;
路径加载及展示模块,用于若内存中没有所述需要加载的图片,则根据所述需要加载的图片在Bundle中的路径加载所述图片并展示;
缓存模块,用于将所述加载过的图片写入所述内存中缓存,其中,根据所述需要加载的图片在Bundle中的路径确定所述图片对应的图片标识。
第一实施方式是与本实施方式相对应的方法实施方式,第一实施方式中的技术细节可以应用于本实施方式,本实施方式中的技术细节也可以应用于第一实施方式。
需要说明的是,本领域技术人员应当理解,上述图片加载装置的实施方式中所示的各模块的实现功能可参照前述图片加载方法的相关描述而理解。上述图片加载装置的实施方式中所示的各模块的功能可通过运行于处理器上的程序(可执行指令)而实现,也可通过具体的逻辑电路而实现。本说明书实施例上述图片加载装置如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。基于这样的理解,本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本说明书各个实施例所述方法的全部或部分。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。这样,本说明书实施例不限制于任何特定的硬件和软件结合。
相应地,本说明书实施方式还提供一种计算机可读存储介质,其中存储有计算机可执行指令,该计算机可执行指令被处理器执行时实现本说明书的各方法实施方式。计算机可读存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于,相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读存储介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
此外,本说明书实施方式还提供一种图片加载设备,其中包括用于存储计算机可执行指令的存储器,以及,处理器;该处理器用于在执行该存储器中的计算机可执行指令时实现上述各方法实施方式中的步骤。其中,该处理器可以是中央处理单元(CentralProcessing Unit,简称“CPU”),还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor,简称“DSP”)、专用集成电路(Application Specific IntegratedCircuit,简称“ASIC”)等。前述的存储器可以是只读存储器(read-only memory,简称“ROM”)、随机存取存储器(random access memory,简称“RAM”)、快闪存储器(Flash)、硬盘或者固态硬盘等。本发明各实施方式所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。
需要说明的是,在本专利的申请文件中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。本专利的申请文件中,如果提到根据某要素执行某行为,则是指至少根据该要素执行该行为的意思,其中包括了两种情况:仅根据该要素执行该行为、和根据该要素和其它要素执行该行为。多个、多次、多种等表达包括2个、2次、2种以及2个以上、2次以上、2种以上。
在本说明书提及的所有文献都被认为是整体性地包括在本说明书的公开内容中,以便在必要时可以作为修改的依据。此外应理解,以上所述仅为本说明书的较佳实施例而已,并非用于限定本说明书的保护范围。凡在本说明书一个或多个实施例的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例的保护范围之内。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。