CN110489576B

CN110489576B - 图片资源处理方法和系统、客户端、服务器、处理器及介质

Info

Publication number: CN110489576B
Application number: CN201910650974.7A
Authority: CN
Inventors: 邓竹立; 吕庆春; 彭飞
Original assignee: Wuba Co Ltd
Current assignee: Wuba Co Ltd
Priority date: 2019-07-18
Filing date: 2019-07-18
Publication date: 2022-07-08
Anticipated expiration: 2039-07-18
Also published as: CN110489576A

Abstract

本发明公开了图片资源处理方法和系统、客户端、服务器、处理器及介质。该图片资源处理方法包括：调用图片获取步骤，在应用程序运行时，通过消息监视机制，从开发工具代码中获取相应的、被调用的图片资源的名称；调用图片汇总步骤，将被调用的图片资源的名称汇总，生成汇总的图片资源集合；清理步骤，将应用程序内置的图片资源之中的、不在所述汇总的图片资源集合中的图片资源删除。通过在应用程序运行时利用消息监视机制来获取和统计被调用的图片资源的名称，能够准确地识别出应用程序中未使用的图片资源，为APP有效瘦身。

Description

图片资源处理方法和系统、客户端、服务器、处理器及介质

技术领域

本发明涉及图片资源处理技术，尤其涉及图片资源处理方法和系统、客户端、服务器、处理器及介质。

背景技术

随着各种应用程序(APP)版本的不断迭代更新，其业务越来越多，引用的图片资源(主要包括应用程序中内置的图片)也越来越多，现有的技术方案很难对图片资源做减法。在很多情况下，虽然某些图片资源已经不再使用了，但是由于无法辨别和梳理出哪些图片是不再使用的，所以往往只能将图片资源整体保留，导致APP的应用包不断变大，使得安装了这些APP的智能设备的存储资源常常不足。

要为应用包瘦身，最常见的方式是通过脚本来遍历所有的图片资源，查看图片资源是否在代码中存在引用，如果没有存在引用则清除该图片。但是，这种方式将主要导致如下缺陷。

1)很多代码是通过动态的方式调用本地图片的。例如，React-Native(简称RN)开发工具可以通过脚本来加载本地图片，而RN代码又是随时可以修改和下发的，因此可能存在动态使用的图片资源被误删的情况。这种情况也可以认为是未使用的图片资源未能被准确识别的一种方式。

2)图片资源名称存在拼接的情况，例如名为“icon_01”的图片，可能被代码拆分为“icon”+“01”这样的方式来使用。在图片资源的名称已经被拆分的这种情况下，脚本很难识别出来这样的图片资源。

因此，亟需一种能够准确地识别出APP内不使用的图片资源以便为APP有效瘦身的解决方案。

发明内容

为了解决以上问题之一，本发明提供了一种图片资源处理方法和系统、客户端、服务器、处理器及介质，以便能够准确地识别出APP内不再使用的图片资源，为APP有效瘦身。

根据本发明的一个实施例，提供一种图片资源处理方法，包括：调用图片获取步骤，其中，在应用程序运行时，通过消息监视机制，从开发工具代码中获取相应的、被调用的图片资源的名称；调用图片汇总步骤，将被调用的图片资源的名称汇总，生成汇总的图片资源集合；清理步骤，将应用程序内置的图片资源之中的、不在所述汇总的图片资源集合中的图片资源删除。

可选地，所述方法还包括：被调用图片集合创建步骤，其中，在应用程序初始化加载时，创建一个被调用图片集合，以用于存放将要在调用图片获取步骤中获取到的、被调用图片资源的名称。

可选地，所述开发工具包括：objective-c、Xib、React-Native。

可选地，所述被调用图片集合创建步骤、所述调用图片获取步骤、所述调用图片汇总步骤、所述清理步骤均在应用程序的客户端进行。

可选地，所述被调用图片集合创建步骤、所述调用图片获取步骤在应用程序的客户端进行，并且，将各客户端将获取的被调用的图片资源的名称传送到服务器，由服务器执行所述调用图片汇总步骤和所述清理步骤。

根据本发明的一个实施例，提供一种客户端，包括：调用图片获取装置，被配置用于在应用程序运行时，通过消息监视机制，从开发工具代码中获取相应的、被调用的图片资源的名称；调用图片汇总装置，被配置用于将被调用的图片资源的名称汇总，生成汇总的图片资源集合；清理装置，被配置用于将应用程序内置的图片资源之中的、不在所述汇总的图片资源集合中的图片资源删除。

根据本发明的一个实施例，提供一种客户端，包括：调用图片获取装置，被配置用于在应用程序运行时，通过消息监视机制，从开发工具代码中获取相应的、被调用的图片资源的名称；发送装置，被配置用于将获取的被调用的图片资源的名称发送给服务器，以使得服务器能够对被调用的图片资源进行汇总，由此清理未被使用的图片资源。

可选地，所述开发工具包括：objective-c、Xib、React-Native。

可选地，上述客户端还包括：被调用图片集合创建装置，被配置用于在应用程序初始化加载时，创建一个被调用图片集合，以用于存放由调用图片获取装置获取的、被调用图片资源的名称。

根据本发明的一个实施例，提供一种服务器，包括：接收装置，被配置用于从客户端接收被调用的图片资源的名称；调用图片汇总装置，被配置用于将接收的、被调用的图片资源的名称汇总，生成汇总的图片资源集合；清理装置，被配置用于将应用程序内置的图片资源之中的、不在所述汇总的图片资源集合中的图片资源删除。

根据本发明的一个实施例，提供一种图片资源处理系统，包括：上述的至少一个客户端；以及上述的服务器之一。

根据本发明的再一个实施例，提供一种图片处理器，包括：处理器；以及存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行上面描述的方法之一。

根据本发明的又一个实施例，提供一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被处理器执行时，使所述处理器执行上面描述的方法之一。

本发明通过在应用程序运行时获取被调用的图片资源的名称，能够避免背景技术中描述的现有技术中由于动态修改和下发程序代码导致的误删图片资源的缺陷。而且，本发明通过消息监视机制，能够获取到被使用的图片资源的全称，由此能够准确识别出未使用的图片资源，而不是像现有技术中那样，在代码中获取到的图片资源的名称可能是拆分的，而拆分的名称又不容易拼接，导致图片资源识别不准确。

综上可知，通过本发明的技术方案，能够准确识别出APP中未使用的图片资源，从而能够方便地对APP进行有效瘦身。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的附图标记通常代表相同部件。

图1给出了根据本发明的一个示例性实施例的图片资源处理方法的示意性流程图。

图2给出了根据本发明的一个示例性实施例的客户端的示意性框图。

图3给出了根据本发明的另一个示例性实施例的客户端的示意性框图。

图4给出了根据本发明的一个示例性实施例的服务器的示意性框图。

图5给出了根据本发明的一个示例性实施例的图片资源处理系统的示意性框图。

图6给出了根据本发明的一个示例性实施例的图片资源处理器的示意性框图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。这里需要说明的是，本申请中的数字、序号以及附图标记仅是为了方便描述而出现的，对于本发明的步骤、顺序等等均不构成任何限制，除非在说明书中明确指出了步骤的执行有特定的先后顺序。

如前所述，本发明是为了能够准确地识别和统计出哪些图片资源是不再被APP使用的，即已经被彻底废弃的，从而达到为APP瘦身的目的。

如图1所示，在被调用图片集合创建步骤S110，在应用程序初始化加载时，创建一个被调用图片集合，以用于存放将要在调用图片获取步骤S120中获取到的、被调用图片资源的名称。由此，可以方便被调用的图片资源的名称的存放和管理。

这里，“被调用图片集合”将用于存放APP中使用的图片资源的名称，用于列出使用的图片资源，以方便辨识出未使用的图片资源。

即，具体地，在开始获取一个APP内被调用(被使用)的图片资源(例如在客户端)之前，可以先初始化创建一个“被调用图片集合(也可称为“被调用图片表”)”)。其中，初始化创建的该表可以为空。

创建的方式包括可以在例如类加载方法(+load方法)中初始化创建该表，也可以使用其它方法来创建，本发明对此不作额外限制。

另外，为了举例说明，该表例如可以是NSMutableSet类型的。当然，本发明无需对该表的类型进行限制。

这里，步骤S110不是必需的，即，也可以不建立该表，而是在下面的调用图片获取步骤S120获得被调用的图片资源的名称之后，直接进行后续处理。

在调用图片获取步骤S120，在应用程序运行时，通过消息监视机制，从开发工具代码中获取相应的、被调用的图片资源的名称。

在创建了被调用图片集合的情况下，可以将在本步骤中获取的被调用的各图片资源的名称存放在该集合中，以方便被调用的图片资源的名称的存放和管理。

进一步地，要获取和统计使用(即，被调用)的图片资源的情况，不同的系统具体使用不同的方式，本发明对此不作额外的限制。

但是，为了方便理解，在此将以iOS系统为例来更详细地描述。请注意，本领域技术人员基于本发明的描述，将明白其他的获取和统计被调用图片资源的方式。

例如，在iOS系统的情况下，可以主要从Objective-C代码(简称OC代码，其为iOS开发的核心语言)、Xib文件、RN(React-Native)开发工具这三个方面来进行被调用图片资源的获取和统计操作。

其中，OC代码、Xib、RN这三种开发工具是APP开发人员画界面的不同方式。即，APP开发人员可以使用这三种开发工具来进行iOS APP开发。

具体地，首先，界面可以直接使用OC代码来生成。

其次，Xib文件是一个轻量级的用来描述局部界面的文件。Xib是可视化的开发，在一个面板上拖拽若干个控件来生成一个界面，也可以对图片进行设置。另外，Xib文件会转化为代码以生成界面。

再者，RN是通过例如JavaScript之类的脚本，动态地将脚本代码转化为OC代码来绘制界面的。

下面，将分别针对上述的三种开发方式之一，描述如何通过消息监视机制，来获取和统计被调用的图片资源的名称。

1、OC代码方式

针对OC代码方式，通过消息监视机制，获取和统计被调用的图片资源的名称的具体方法可以包括如下两种。

这里，本发明所述的消息监视机制可以监视系统或者进程中的各种事件消息，截获消息以及其中的参数，并进行处理。

例如，该消息监视机制可以包括例如钩子(Hook)技术。Hook是一种特殊的消息处理机制，它可以监视系统或者进程中的各种事件消息，截获发往目标窗口的消息并进行处理。因此，可以自定义钩子，用来监视特定事件的发生，完成特定功能，如屏幕取词、监视日志、截获键盘、鼠标输入等等。

钩子的种类很多，每种钩子可以截获相应的消息，如键盘钩子可以截获键盘消息，外壳钩子可以截取、启动和关闭应用程序的消息等。钩子可以分为线程钩子和系统钩子。线程钩子可以监视指定线程的事件消息，系统钩子可以监视系统中的所有线程的事件消息。由此可见，钩子是一个消息拦截机制，可以拦截单个进程的消息(线程钩子)，也可以拦截所有进程的消息(系统钩子)，还可以进一步对拦截的消息进行自定义的处理，在此不再赘述。

为了更容易理解，下面将举例描述“通过消息监视机制，来获取和统计被调用的图片资源的名称的两种具体方法”。

1)通过消息监视机制，获取imageNamed:方法(一种程序代码加载图片的方法)中被调用的图片资源的名称，并且，可以将获取的、被调用的图片资源的名称存放到在上述的S110中创建的“被调用图片集合”中。

具体地，对于本发明，例如，可以通过使用hook UIImageView()的imageNamed：方法，拦截imageNamed:的参数，得到被调用的图片资源的名称(例如“xxx.png”等等的图片名称)。这是因为，在imageNamed:的参数中包含被调用的图片资源的名称。

由此，实现“通过消息监视机制，获取imageNamed:方法(一种程序代码加载图片的方法)中被调用的图片资源的名称”，并且，可以将获取的、被调用的图片资源的名称存放到在上述的S110中创建的“被调用图片集合”中。

2)通过消息监视机制，获取imageWithContentsOfFile方法中被调用的图片资源的名称，并且，可以将获取的、被调用的图片资源的名称存放到上述的“被调用图片集合”中。

例如，可以通过使用hook imageWithContentsOfFile:方法，拦截其参数，得到被调用的图片资源的名称(例如“xxx.png”等等的图片名称)。这是因为，在imageWithContentsOfFile:的参数中包含被调用的图片资源的名称。

由此实现“通过消息监视机制，获取imageWithContentsOfFile方法中被调用的图片资源的名称中”，并且，可以将获取的、被调用的图片资源的名称存放到上述的“被调用图片集合”。

通过上面的举例和描述，可以看出，在本发明中，通过消息监视机制所获取的被调用的图片资源的名称是该图片资源的全称，而不是像现有技术中那样，可能是被代码分割开的一部分名称。

因此，通过本发明中使用的“在应用程序运行时，通过消息监视机制，从开发工具代码中获取相应的、被调用的图片资源的名称”，能够准确识别出被调用的图片资源的名称。

另外，消息监视机制还可以包括适用于安卓系统的面向切面编程(AspectOriented Programming，AOP)实现框架，它包括AspectJ框架、Spring AOP框架等等方式。在此不再赘述。

上述的消息监视机制的例子都是为了便于理解和实现而给出的，本领域技术人员可知，本发明不限于上述给出的消息监视机制的例子，而是任何可用的消息监视机制都可以适用于本发明。

2、Xib文件方式

针对Xib方式，可以通过消息监视机制，获取Xib加载图片方法中被调用的图片资源的名称，并可以将获取的图片资源名称存放到上述的“被调用图片集合”中。

具体地，例如，可以通过例如hook UINibDecoder类的decodeObjectForKey:方法，获取Xib解码的关键字(key)。这里，Xib解码的关键字是一个字符串，这个字符串能够映射到一个数据。比如人的名字就是一个关键字，这个关键字能映射到一个人(假设每个人的名字都是唯一的)。

然后，针对Xib解码的该关键字，做如下操作。

首先，判断该关键字是否为“UIResourceName”(这里，UIResourceName为iOS系统存储图片时所用图片资源的名称)，如果是，则调用decodeObjectForKey:方法，得到被调用的图片资源的名称。

这里，decodeObjectForKey的作用是解码，通过解码，将被调用的图片资源的名称获取到。

然后，可以将得到的被调用的图片资源的名称存放到上述的“被调用图片集合”中。

3、RN方式

针对RN方式，通过消息监视机制，获取RN加载图片方法中被调用的图片资源的名称，并可以将获取的图片资源名称存放到上述的“被调用图片集合”中。

具体地，可以通过例如hook UIView的sd_internalSetImageWithURL:(nullableNSURL*)url placeholderImage:(nullable UIImage*)placeholder options:(SDWebImageOptions)options operationKey:(nullable NSString*)operationKeysetImageBlock:(nullable SDSetImageBlock)setImageBlock progress:(nullable SDWebImageDownloaderProgressBlock)progressBlock completed:(nullableSDExternalCompletionBlock)completedBlock方法(该方法是RN获取内置图片的方式)，获取到参数url。

这里，已经获取的url虽然包含了被调用的图片资源的名称，但是由于其是nsurl类型，不是字符串类型，并没有直接得到所需的字符串类型的名称。此时，可以将url再转成字符串，提取其中的被调用的图片资源的名称(例如“/xxx.png”)。然后，可以将得到的被调用的图片资源的名称存放到上述的“被调用图片集合”中。

在调用图片汇总步骤S130，将被调用的图片资源的名称汇总，生成汇总的图片资源集合。

这里的“汇总”处理，包括将被调用的图片资源的名称汇集或者集合起来，以方便统一管理和存放。

在通过上述例举的方法获取了被调用的图片资源的名称之后，可以直接在客户端进行后续的汇总处理(以及后续的清理处理)，为应用程序瘦身。

另一方面，也可以在获取了被调用的图片资源的名称之后，将其上传到服务器，在服务器进行汇总处理(以及后续的清理处理)。

这里，上传的数据格式例如可以如下：

{

appVersion:xxx，//客户端版本号

client:”ios”，//客户端区分

data:[“icon0”，“icon1”…]//图片资源名称数据

}。

上面的数据格式仅是一个例子，本发明对于其数据格式不做特别限制。

然后，可以在服务器对接收到的所有的“被调用图片集合”进行合并(汇集)，生成一个汇总的被调用图片资源集合(简称为“汇总的图片资源集合”)。

在清理步骤S140，将应用程序内置的图片资源之中的、不在上述的汇总的图片资源集合中的图片资源删除。

由此，实现了应用程序的瘦身。

尤其，本发明的调用图片获取步骤S120是在应用程序运行时进行的，这样可以避免背景技术中描述的现有技术中由于动态修改和下发程序代码导致的误删图片资源的缺陷。

而且，本发明的调用图片获取步骤S120通过消息监视机制，能够获取到图片资源的全称，而不是像现有技术中那样，在代码中获取到的图片资源的名称可能是拆分的，而拆分的名称又不容易拼接，导致图片资源识别不准确。

其中，上述的开发工具可以包括objective-c、Xib、React-Native等。

另外，上述的调用图片获取步骤S120、调用图片汇总步骤S130、清理步骤S140均可以在应用程序的客户端进行。

另外，上述的被调用图片集合创建步骤S110也可以在应用程序的客户端进行。

通过在客户端执行上述的那些步骤，能够在客户端准确识别和统计出未被使用的图片资源，由此在客户端执行应用程序的瘦身。

另外，也可以在应用程序的客户端仅执行上述的被调用图片集合创建步骤S110、上述的调用图片获取步骤S120，然后，将各客户端获取的被调用的图片资源的名称传送到服务器，由服务器执行所述调用图片汇总步骤和所述清理步骤。

由此，通过在服务器汇总和统计被调用的图片资源的名称，然后确定在应用程序中内置的哪个或哪些图片资源未被使用，并且从应用程序内清理出这些图片资源，实现应用程序的瘦身。

例如，在这种情况下，开发人员可以通过后台查看该“汇总的图片资源集合”，来了解图片的使用情况，获取所有被使用的图片名称，并且，可以将不在该“汇总的图片资源集合”中的图片资源删除，以便给APP瘦身，减少其占用的资源。

通过本发明，使得能够根据线上的使用情况，对APP内置的图片资源进行合理的清理。而且，能够避免现有技术中因图片动态加载而被误删的情况。另外，还可以通过在应用程序运行时，使用消息监视机制，准确识别得到未被使用的图片资源。

如图2所示，根据本发明的一个示例性实施例的客户端1000可以包括调用图片获取装置120、调用图片汇总装置130、清理装置140。

其中，调用图片获取装置120可以被配置用于在应用程序运行时，通过消息监视机制，从开发工具代码中获取相应的、被调用的图片资源的名称。

调用图片汇总装置130可以被配置用于将被调用的图片资源的名称汇总，生成汇总的图片资源集合。

清理装置140可以被配置用于将应用程序内置的图片资源之中的、不在所述汇总的图片资源集合中的图片资源删除。

由此，通过在客户端包括上述的各装置，能够在客户端准确识别和统计出未被使用的图片资源，由此在客户端执行应用程序的瘦身。

另外，可选地，根据本发明的一个示例性实施例的客户端1000还可以包括被调用图片集合创建装置110，其可以被配置用于在应用程序初始化加载时，创建一个被调用图片集合，以用于存放由调用图片获取装置获取的、被调用图片资源的名称。

通过使用被调用图片集合，可以方便被调用图片资源的存放和管理。

另外，上述的各装置110-140的操作与前面描述的步骤S110-S140的处理类似，在此不再赘述。

图3给出了根据本发明的另一个示例性实施例的客户端1000’的示意性框图。

如图3所述，根据本发明的一个示例性实施例的客户端1000’可以包括调用图片获取装置120、发送装置150。

发送装置150可以被配置用于将获取的、被调用的图片资源的名称发送给服务器，以使得服务器能够对被调用的图片资源进行汇总，由此清理未被使用的图片资源。

另外，可选地，客户端1000’也可以包括被调用图片集合创建装置110，其可以被配置用于在应用程序初始化加载时，创建一个被调用图片集合，以用于存放由调用图片获取装置获取的、被调用图片资源的名称。

如图4所示，根据本发明的一个示例性实施例的服务器2000可以包括：接收装置210、调用图片汇总装置220、清理装置230。

其中，接收装置210可以被配置用于从客户端1000’接收被调用的图片资源的名称。

调用图片汇总装置220可以被配置用于将接收的、被调用的图片资源的名称汇总，生成汇总的图片资源集合。

清理装置230可以被配置用于将应用程序内置的图片资源之中的、不在所述汇总的图片资源集合中的图片资源删除。

这里，图3的至少一个客户端1000’与图4的服务器2000可以构成一个图片资源处理系统，如图5所示。

通过该图片资源处理系统，可以在服务器端收集各客户端上传的、被调用的图片资源的名称，由此可以从总体上确定该应用程序所使用到的图片资源，基于此，可以将未被使用到的图片资源清理掉，由此实现应用程序的瘦身。

参见图6，该图片资源处理器1包括存储器10和处理器20。

处理器20可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器20可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中，处理器20可以使用定制的电路实现，例如特定用途集成电路(ASIC，Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA，Field Programmable Gate Arrays)。

存储器10上存储有可执行代码，当所述可执行代码被所述处理器20执行时，使所述处理器20执行上面描述的方法之一。其中，存储器10可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器20或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器10可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器10可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

此外，根据本发明的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

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

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims

1.一种图片资源处理方法，其特征在于，包括：

调用图片获取步骤，其中，在应用程序运行时，通过消息监视机制，从开发工具代码中获取相应的、被调用的图片资源的名称；所述被调用的图片资源的名称为所述被调用的图片资源的全称；

所述从开发工具代码中获取相应的、被调用的图片资源的名称包括：从Objective-C代码、Xib文件、React-Native开发工具这三个方面来进行所述被调用图片资源的获取和统计操作；

调用图片汇总步骤，其中，将被调用的图片资源的名称汇总，生成汇总的图片资源集合；

清理步骤，其中，将应用程序内置的图片资源之中的、不在所述汇总的图片资源集合中的图片资源删除。

2.如权利要求1所述的图片资源处理方法，其特征在于，还包括：

被调用图片集合创建步骤，其中，在应用程序初始化加载时，创建一个被调用图片集合，以用于存放将要在调用图片获取步骤中获取到的、被调用图片资源的名称。

3.如权利要求2所述的图片资源处理方法，其特征在于，其中，所述调用图片汇总步骤包括将在每个客户端获取到的、被调用图片资源的名称，在该客户端合并成为一个汇总的图片资源集合。

4.如权利要求2所述的图片资源处理方法，其特征在于，所述调用图片汇总步骤包括将在各客户端获取到的、被调用图片资源的名称，上传到服务器，并在服务器将在各客户端获取到的、被调用图片资源的名称合并成为一个汇总的图片资源集合。

5.如权利要求2所述的图片资源处理方法，其特征在于，

其中，所述消息监视机制包括钩子技术。

6.一种客户端，其特征在于，包括：

调用图片获取装置，被配置用于在应用程序运行时，通过消息监视机制，从开发工具代码中获取相应的、被调用的图片资源的名称；所述被调用的图片资源的名称为所述被调用的图片资源的全称；

调用图片汇总装置，被配置用于将被调用的图片资源的名称汇总，生成汇总的图片资源集合；

清理装置，被配置用于将应用程序内置的图片资源之中的、不在所述汇总的图片资源集合中的图片资源删除。

7.一种客户端，其特征在于，包括：

发送装置，被配置用于将获取的被调用的图片资源的名称发送给服务器，以使得服务器能够对被调用的图片资源进行汇总，由此清理未被使用的图片资源。

8.如权利要求7所述的客户端，其特征在于，还包括：

被调用图片集合创建装置，被配置用于在应用程序初始化加载时，创建一个被调用图片集合，以用于存放由调用图片获取装置获取的、被调用图片资源的名称。

9.一种服务器，其特征在于，包括：

接收装置，被配置用于从客户端接收被调用的图片资源的名称；在应用程序运行时，通过消息监视机制，从开发工具代码中获取相应的、所述被调用的图片资源的名称；所述被调用的图片资源的名称为所述被调用的图片资源的全称；

调用图片汇总装置，被配置用于将接收的、被调用的图片资源的名称汇总，生成汇总的图片资源集合；

10.一种图片资源处理系统，其特征在于，包括：

至少一个如权利要求6～8中的任何一项所述的客户端；以及

如权利要求9所述的服务器。

11.一种图片资源处理器，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1～5中任何一项所述的方法。

12.一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被处理器执行时，使所述处理器执行如权利要求1～5中任何一项所述的方法。