CN109144619B - 图标字体信息处理方法、装置及*** - Google Patents

Abstract

本申请实施例公开了图标字体信息处理方法、装置及***，其中，所述***包括：第一服务端，用于为图标字体包分配唯一性地址标识，并为图标生成图标编码；第一客户端，用于在编辑目标应用程序的目标界面过程中，将目标界面、目标显示区域与目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端；所述第二服务端，用于接收到第二客户端的界面访问请求时，向所述第二客户端提供所述对应关系信息；所述第二客户端用于：根据所述目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。通过本申请实施例，能够提高应用程序的上线效率。

Description

图标字体信息处理方法、装置及***

技术领域

本申请涉及图标字体信息处理技术领域，特别是涉及图标字体信息处理方法、装置及***。

背景技术

在移动终端应用程序开发项目中，经常会遇到小图标在手机等移动终端设备中显示比较模糊的问题。例如，在微社区项目中，有很多小的Icon(图标)，如分享、回复、赞、返回、话题、访问、箭头等，这些Icon一般都是纯色的。开始制作时考虑用双倍大小的Sprite(图片整合技术)图，通过CSS(Cascading Style Sheets，层叠样式表)样式设置只显示二分之一尺寸，这样在Retina(一种显示技术)屏上显示的大小是正常的，可一旦放大屏幕后图标又变得模糊不清，测试的效果不是很理想。经过反复实践，发现了一种比较好的解决方案，即图标字体化方案。

所谓的图标字体(icon font)，是指将矢量图标做成字体来供开发者使用，也就是说，供开发者使用的字体，不再是传统认知上的“文字”，而是一个个的图标。这种方式具有体积小、缩放保真、颜色可定制等优势，因此，在无线领域icon font受到了越来越广泛的应用，其中不乏手机淘宝、手机天猫等大型无线客户端。然而，随着应用场景的增多，其中存在的问题也在逐渐暴露出来。

例如，在现有技术中，图标字体包通常是与应用程序一一对应的，也即，一个应用程序中需要用的所有图标，都保存在同一个图标字体包中。如果应用程序开发者需要在开发过程中使用图标字体，则需要将图标字体包内置到待发布的应用程序中。在编辑应用程序界面时，需要在界面代码中指定具体某个显示区域使用图标字体包中哪个的图标。用户在其移动终端设备中安装应用程序客户端时，图标字体包会与安装文件一起保存在终端设备中，用户在访问应用程序时，客户端会根据内置的图标文件，进行界面中图标的展示。

但是，在实际应用中，经常会发生应用程序界面中图标更新的情况。例如，在电子商务销售平台类的应用程序中，当平台中开展一些大型促销活动时，经常会将首页等界面中的一些图标更新为与活动内容相关的样式。如，在某活动开展期间，需要将“手机天猫”客户端首页中的“天猫国际”、“全球精选”、“全球旗舰店”、“国家地区馆”、“分类”等频道的图标，更新为如图1所示的样式。在活动结束后，可能还需要将上述频道的图标更新回原来的样式，等等。由于在现有技术中，图标字体需要内置到应用程序中，因此，每次更新界面内的图标时，都需要伴随应用程序版本的更新，用户需要在终端设备中将应用程序更新到最新版本后，才能够从界面中查看到更新后的图标样式。然而，应用程序版本更新所需的成本较高，会影响应用程序的上线效率。

发明内容

本申请提供了图标字体信息处理方法、装置及***，避免在需要更新界面内显示区域展示的图标时伴随应用程序版本的更新，提高应用程序的上线效率。

本申请提供了如下方案：

一种图标字体信息处理***，包括：

第一服务端，用于保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；

第一客户端，用于在编辑目标应用程序的目标界面过程中，从所述第一服务端查询获得可选的图标字体包信息以及图标字体包内的图标信息，为目标界面中的目标显示区域确定目标字体包以及目标图标，将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端；

第二客户端，用于访问目标界面，并向所述第二服务端请求获取所述目标界面的界面数据；

所述第二服务端，用于接收到所述第二客户端的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息；

所述第二客户端还用于：根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

一种图标字体信息处理方法，包括：

第一服务端保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；

接收到第一客户端的查询请求时，提供可选的图标字体包信息以及图标字体包内的图标信息，由第一客户端为目标界面中的目标显示区域确定目标字体包以及目标图标，并将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息。

一种图标字体信息处理方法，包括：

第一客户端在编辑目标应用程序的目标界面过程中，从所述第一服务端查询获得可选的图标字体包信息以及图标字体包内的图标信息；

为目标界面中的目标显示区域确定目标字体包以及目标图标；

将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端。

一种图标字体信息处理方法，包括：

第二服务端保存第一客户端提交的配置信息，所述配置信息中包括目标界面、目标显示区域与目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；

接收到第二客户端的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

一种图标字体信息处理方法，包括：

第二客户端访问目标界面，并向第二服务端请求获取所述目标界面的界面数据；

接收所述第二服务端提供的界面数据，所述界面数据中包括目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；

根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件；

根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

一种图标字体信息处理装置，包括：

信息分配单元，用于保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；

信息提供单元，用于接收到第一客户端的查询请求时，提供可选的图标字体包信息以及图标字体包内的图标信息，由第一客户端为目标界面中的目标显示区域确定目标字体包以及目标图标，并将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端。

一种图标字体信息处理装置，包括：

查询单元，用于在编辑目标应用程序的目标界面过程中，从所述第一服务端查询获得可选的图标字体包信息以及图标字体包内的图标信息；

图标确定单元，用于为目标界面中的目标显示区域确定目标字体包以及目标图标；

对应关系信息提交单元，用于将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端。

一种图标字体信息处理装置，包括：

配置信息保存单元，用于保存第一客户端提交的配置信息，所述配置信息中包括目标界面、目标显示区域与目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；

对应关系信息实时下发单元，用于接收到第二客户端的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

一种图标字体信息处理装置，包括：

访问请求提交单元，用于访问目标界面，并向第二服务端请求获取所述目标界面的界面数据；

界面数据接收单元，用于接收所述第二服务端提供的界面数据，所述界面数据中包括目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；

字体文件加载单元，用于根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件；

图标展示单元，用于根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

一种计算机***，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:

保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内每个的图标生成图标编码；

在编辑目标应用程序的目标界面过程中，为目标界面中的目标显示区域确定目标字体包以及目标图标，将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端；

通过所述第二服务端接收到第二客户端的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

一种计算机***，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:

访问目标界面，并向第二服务端请求获取所述目标界面的界面数据；

接收所述第二服务端提供的界面数据，所述界面数据中包括目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；

根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件；

根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以将图标字体包统一通过第一服务端进行保存，并且，第一服务端能够为图标字体包分配唯一性的地址标识，还可以为每个字体包内的各个图标分别生成各自的图标编码，这样，可以通过字体包的地址标识+图标的图标编码这两方面的信息，唯一确定一个图标。在应用程序开发者编辑界面的过程中，可以为界面中具体的显示区域指定目标字体包的地址标识，以及目标图标的图标编码，并将这种对应关系信息保存到第二服务端。用户在通过第二客户端访问目标界面时，第二服务端可以向第二客户端提供界面数据，其中就可以包括上述对应关系信息，也即，关于界面中具体显示区域需要展示怎样的图标，可以是由第二服务端实时下发给第二客户端的。之后，第二客户端可以根据第二服务端提供的地址标识，加载对应的字体文件，并根据图标编码，在对应的显示区域内展示出对应的图标。通过这种方式，可以实现对图标字体的统一管理，并且，通过第二服务端实时下发对应关系的方式，使得应用程序开发者不需要在待发布的应用程序中内置图标字体包，实现应用程序与图标字体包之间的解耦。后续需要对界面内具体显示区域显示的图标进行更新时，也只需要对第二服务端保存的对应关系进行更新，之后，第二客户端就可以实时接收到更新后的对应关系信息，实现界面中对应显示区域内图标的更新，而不再需要对应用程序的版本进行更新，因此，可以降低成本，提高应用程序的上线效率。

另外，通过为每个图标字体包分配唯一性的地址标识，还可以实现图标字体包的拆解，也即，同一个应用程序所需要用到的图标字体不再需要打包在同一个图标字体包中，而是可以为同一个应用程序提供多个图标字体包，例如，可以从业务线维度上拆解为多个字体包，等等。这样，可以避免同一个图标字体包内包含的图标数量过多而导致字体包体积过于庞大，降低对字体包的管理及维护难度。

再者，在图标字体的使用方式上，本申请实施例还可以在从网络加载了字体文件后，首先进行转换，将字体文件转换为操作***可识别的结构体，之后再写入内存中，这样就可以由操作***原生的视觉组件来实现对图标字体的展示，而不再需要应用程序开发者预先定制视觉组件，因此，可以降低应用程序开发者的工作量，提高应用程序的开发效率。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的图标字体示意图；

图2是本申请实施例提供的***架构的示意图；

图3是本申请实施例提供的图标字体包分拆示意图；

图4是本申请实施例提供的交互示意图；

图5是本申请实施例提供的***的示意图；

图6是本申请实施例提供的第一方法的流程图；

图7是本申请实施例提供的第二方法的流程图；

图8是本申请实施例提供的第三方法的流程图；

图9是本申请实施例提供的第四方法的流程图；

图10是本申请实施例提供的图标字体加载过程流程图；

图11是本申请实施例提供的另一图标字体加载过程的流程图；

图12是本申请实施例提供的一个实例中的接***互示意图；

图13是本申请实施例提供的第一装置的示意图；

图14是本申请实施例提供的第二装置的示意图；

图15是本申请实施例提供的第三装置的示意图；

图16是本申请实施例提供的第四装置的示意图；

图17是本申请实施例提供的计算机***的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，提供了图标字体的统一管理平台，在这种平台中，可以对图表字体包进行统一的保存，并为每个字体包分配唯一存储地址标识，具体可以是URL(UniformResource Locator，统一资源定位符)等形式，还可以为字体包内的每个图标生成图标编码，这样，通过指定一个字体包的地址标识以及一个图标编码，可以唯一定位到一个图标。应用程序开发者在编辑一个界面时，如果需要在界面中某个显示区域内显示一个图标，则可以通过指定字体包地址标识+图标编码的方式来进行设置，并且，在本申请实施例中，上述设置的结果并不是固定写死在界面代码中，而是保存在应用程序服务端。也就是说，字体包不需要预先内置在应用程序中，在用户访问应用程序中的界面时，可以由服务端将界面中具体显示区域对应的字体包地址标识以及图标编码，实时下发到客户端，由客户端根据从网络中实时加载字体文件，并将对应的图标显示在对应的显示区域。通过上述方式，如果应用程序开发者需要更新界面中的图标，则可以在服务端中对字体包地址标识以及图标编码进行更新，服务端可以将更新后的地址标识+编码实时提供给客户端，而不需要更新客户端版本，这种方式可以降低成本，提高应用程序的上线效率。

参见图2，从***架构角度而言，首先可以包括一图标字体管理服务端，该服务端用于统一保存图标字体包，为字体包分配URL等唯一性的地址标识，并为字体包内的各个图标生成包内唯一性的编码。其中，具体的图标字体包可以由专门的图标设计者进行设计，在具体实现时，***中还可以包括图标设计客户端，设计者可以通过这种客户端对图标字体进行设计，之后，可以进行打包，将图标字体包上传到图标字体管理服务端，此时，图标字体管理服务端可以对接收到的字体包进行保存，并执行分配地址标识、图标编码等操作。

在上述图标字体设计、保存及地址标识分配过程中，需要进行以下几点说明：

第一，设计者在设计出一种图标字体并生成字体包提交到图标字体管理服务端后，还可能会对字体包进行更新，例如，可以向字体包中添加新的图标，等等。在每次对一个字体包进行更新后，图标字体管理服务端都可以为该字体包重新分配新的地址标识，如果字体包中添加了新的图标，还可以为新增的图标生成对应的图标编码，字体包中原有的图标对应的图标编码可以保持不变。也就是说，在一个字体包发生更新后，如果界面中某显示区域仍显示字体包内原有的某个图标，则该显示区域关联的地址标识会发生变化，但是图标编码可以是不变的。

第二，现有技术中的图标字体管理方法采用了集中式管理策略，即将一个应用程序所需的全部图标做成同一个字体库。各个业务线的图标因此全部耦合在一起，导致了随着应用程序内业务线的增加，图标数量的成倍增长。维护人员很难确定哪些图标是正在使用的，哪些又是已经废弃不用的。这无疑大大增加了后期维护成本。而在本申请实施例中，由于图标字体管理服务端能够为每个字体包分配对应的地址标识，并且可以通过由应用程序服务端实时下发的方式提供给应用程序客户端，因此，可以实现字体包的“拆包”处理。所谓的“拆包”是指，对于一个应用程序而言，可以不必再由同一个图标字体包对所有需要用到的图标进行保存，而是可以拆分成多个图标字体包。例如，由于应用程序内的界面通常是与业务线关联的，某个界面通常是某个业务线下的界面，同一业务线下的不同界面，可能会共用相同的图标字体，而在不同的业务线之间，这种共用的情况则可能会比较少见。因此，可以在业务线维度上，根据应用程序内业务线的不同，拆分为多个字体包，设计者可以分别为各个不同的业务线设计不同的图标字体包，等等。例如，“手机天猫”应用程序中包括“天猫超市”、“天猫国际”等多个不同的业务线，则可以分别为这些业务线设计各自的图标字体包。这样，每个应用程序可以使用的字体包可以有多个，每个字体包具有各自不同的地址标识，每个字体包内可以包括多个图标，每个图标也具有各自的编码。应用程序开发人员在编辑界面时，可以根据当前界面所属的业务线，选择对应的字体包，并从该字体包内指定具体的图标编码。当然，在实际应用中，也可能存在同一个界面中使用多个字体包的情况。总之，通过这种方式，可以方便对字体包的管理，避免字体包内的图标数量过大。另外，后续在从网络实时加载字体包时，也可以仅对当前界面使用到的字体包进行加载，其他字体包即使与当前应用程序相关，但是由于与当前界面无关，也可以暂时不必加载，因此，可以实现按需加载，降低用户流量消耗，提高加载速度。

例如，假设某应用程序中包括两个业务线，如果不进行拆解，则该应用程序对应一个图标字体包，该应用程序使用到的所有图标，都保存在同一个图标字体包A中，该字体包A的地址标识可以为：http://at.alicdn.com/t/font_1471422397_5694983.ttf。但是，按照本申请实施例提供的方案，则可以将上述字体包按照业务线的不同，拆解为两个不同的字体包，分别为图标字体包B，和图标字体包C，并分别为字体包B、C分配对应的地址标识。例如，字体包B的地址标识可以为：http://at.alicdn.com/t/font_1464240514_5821292.ttf，字体包C的地址标识为：http://at.alicdn.com/t/font_1466064740_582372.ttf。进而，每个拆解后的字体包中可以分别包括多个图标，还可以分别为各个图标生成图标编码。这样，就可以通过字体包的地址标识+图标编码唯一定位到一个图标。例如，在字体包B中，图标编码为“&#xe607”的图标，为一个名称为“医疗服务”的图标，图标样式如图3所示。在在字体包C中，图标编码为“&#xe603”的图标，为一个名称为“母婴”的图标，图标样式如图3所示。需要说明的是，具体的字体包拆解操作可以是由图标字体的设计者进行的，也即，提交到图标字体管理服务端的字体包，可以是已经进行拆解后的字体包。

第三，在具体实现时，设计者在生成字体包后，还可以为字体包进行命名，提交到图标字体管理服务端的信息，除了字体包本身，还可以包括字体包的名称等信息，相应的，图标字体管理服务端在对字体包进行保存时，还可以保存字体包的名称信息。例如，在上述按照业务线对字体包进行拆分的情况下，分别为“天猫超市”、“天猫国际”等不同的业务线设计的图标字体包，可以分别名称为“天猫超市”、“天猫国际”等等。

图标字体管理服务端在保存了图标设计客户端上传的字体包，并分配对应的地址标识、图标编码等之后，就可以提供给应用程序开发者使用。具体的，***架构中还可以包括应用程序开发客户端，顾名思义，该客户端是应用程序开发者在开发应用程序过程中使用的客户端。具体实现时，图标字体管理服务端可以提供查询接口，应用程序开发者可以对其中保存的字体包的信息进行查询，包括查询具体包括哪些字体包，每个字体包的名称、地址标识、字体包内包括哪些图标、每个图标对应的编码，等等，上述信息都可以通过界面化的方式展示给应用程序开发者，应用程序开发者能够查看到具体的字体包名称、每个图标的样式等。这样，应用程序开发者就可以根据当前编辑的界面中具体显示区域的需要，从展示出的字体包列表中选择目标字体包，再从该目标字体包对应的图标列表中，选择所需的目标图标，通过目标字体包的地址标识以及目标图标的图标编码，来指定对界面内具体显示区域的图标信息。

另外，***中还可以包括应用程序服务端，该应用程序服务端是指保存应用程序界面数据的服务端，也即，用户在终端设备中加载应用程序的某个界面时，该界面的数据就来自于该服务端。在本申请实施例中，应用程序开发客户端为界面内具体显示区域指定的目标字体包的地址标识以及目标图标的图标编码，并不是写在界面代码中，而是可以保存在上述应用程序服务端中。这样，用户在访问应用程序中的具体界面时，可以由应用程序服务端向应用程序客户端实时下发上述地址标识以及图标编码，由应用程序客户端根据具体的地址标识，来加载对应的字体文件，再根据具体的图标编码，从字体文件中确定出具体的图标，展示在对应的显示区域内。

需要说明的是，字体文件的加载以及图标的展示的过程由应用程序客户端来完成。在本申请实施例中，可以为应用程序开发者提供SDK(Software Development Kit，软件开发工具包)，应用程序可以依赖这种SDK，实现字体文件的加载以及图标的展示。这样，应用程序开发者利用上述SDK，使得应用程序客户端实现上述字体文件的加载以及图标展示功能。另外，在具体实现时，还可以利用上述SDK，对字体文件的加载以及图标展示过程进行进一步的优化。具体可以体现在以下几个方面：

第一，由于是以字体的形式进行图标的展示，而操作***中通常都会有固定的默认字体，也即普通的文字字体，因此，每次在界面中使用图标字体时，都需要对***的默认字体进行重设，设置为图标字体。为此，在现有技术中，通常需要由应用程序开发者预先定制视觉组件，该定制的视觉组件的主要作用，就是在每次需要使用图标字体时，对***的默认字体进行重设，以使得***能够识别这种图标字体。而在本申请实施例中，为了避免应用程序开发者执行定制视觉组件的操作，还可以提供字体转换功能，也即，可以将加载成功的字体文件，转换为***可识别的结构体，然后再写入到内存中，这样，就可以使用***原生的视觉组件，对具体的图标进行展示，而不再需要预先对视觉组件进行定制。

第二，为了进一步节省用户流量资源，避免每次访问同一个界面，或者共用同一个字体包的界面时，都重新从网络中加载对应的字体包，还可以采用缓存机制。也即，应用程序客户端在从网络中加载一个字体文件后，还可以在终端设备本地进行缓存，并且这种本地缓存还可以分为两级缓存，分别为内存缓存以及磁盘缓存。例如，在将加载成功的字体文件转换为***可识别的结构体后，可以写入到内存中，由***原生的视觉组件对图标进行展示，在此过程中，就可以将转换后的***可识别的结构体加入到内存缓存中。这样，在下次再需要使用该字体文件中的图标时，就可以直接从内存缓存中进行加载。如果内存缓存中的某字体文件长时间未使用，则可以从内存缓存中清除，将该字体文件写入到磁盘缓存中，下次再使用该字体文件中的图标时，则可以从磁盘缓存中进行加载，之后转换为***可识别的结构体，再写入到内存中，由***原生的视觉组件对图标进行展示。在这种使用缓存机制的情况下，图标字体管理服务端可以使用每次更新字体包时，均对其地址标识进行更新的方式。这是因为，如果一个字体包发生了更新，例如其中新增了图标等，如果不采用缓存机制，每次使用都是到网络中加载，则字体包的地址标识其实是可以不必更新的；但是，在采用缓存机制的情况下，如果字体包发生了更新，而不对字体包的地址标识进行更新，则客户端可能会无法获知字体包发生了更新这一事件的发生，仍然加载本地缓存的字体文件，但是，本地缓存中的字体文件中并不存在新增的图标，因此，在具体展示时会出错。为此，在使用缓存机制的情况下，每次对字体包进行更新时，图标字体管理服务端都可以对字体包的地址标识进行更新。这样，应用程序客户端在接收到应用程序服务端实时下发的目标字体的地址标识以及图标编码后，具体的处理逻辑可以是：首先，判断该目标字体的地址标识是否存在于内存缓存或者磁盘缓存中，如果存在，则证明该目标字体之前已经加载过并且未发生更新，因此，直接从内存缓存或者磁盘缓存加载即可；如果内存缓存或者磁盘缓存中不存在该目标字体的地址标识，则证明之前未加载过该目标字体，或者该目标字体发生过更新，其地址标识已经发生了变化，此时，应用程序客户端就可以根据该目标字体的地址标识，从网络中加载对应的字体文件。之后，再按照上述流程，对目标图标进行展示，并对该目标字体的字体文件进行缓存。

第三，在本申请实施例中，同一个应用程序可能关联多个图标字体包，因此，可能存在***内需要同时加载多个图标字体包的情况。而在一些特殊的操作***中，例如，iOS***等，如果要使用第三方或者自定义字体时，必须要将字体包使用特定的API注册进***中，然后将自定义字体包的font name属性(也即字体包的名称属性)与文本绑定才能使用，也就是说，这种操作***中，主要是依据字体包的名称属性，来区分字体包。而通常情况下，图标字体包的font name属性可能是由字体设计者人为指定的，这就存在不同的字体包之间重名的可能，或者，在另外一些情况下，图标字体包的名称可能都默认为“iconfont”，等等。而iOS***中如果已经存在相同的font name的字体包，则后者将无法注册成功。为此，在本申请实施例中，针对上述iOS等操作***中的应用程序，还可以利用字体包地址标识唯一性的特性，在将字体包加载成功后，可以根据字体包地址标识动态产生一个唯一的fontname，例如，可以将字体包地址标识进行哈希运算，将得到的哈希值作为对应字体包的文件名，并将字体包中font name位于字体包中的二进制数据修改并持久化，然后再将具有新的唯一的font name的字体包注册进iOS***中，并提供给调用者。这样，就可以使得不同的字体包具有不同的名称，避免在注册进***时相互覆盖。

为了更好的理解本申请实施例提供的技术方案，下面结合一个实际应用中的例子，对上述***架构内各成员之间的信息交互流程进行详细介绍。参见图4，具体的交互流程可以包括：

步骤1.图标字体设计客户端设计图标字体，并进行打包操作：图标字体设计者可以利用图标字体设计客户端进行图标字体的设计。在设计之前，可以选定具体的目标应用程序，另外，在可选的实现方式中，还可以选定目标应用程序中的目标业务线等，专门为该业务线设计所需使用的图标字体，等等。在设计好一套图标之后，可以进行打包，生成图标字体包。其中，字体包具体可以以字体文件的形式存在。具体实现时，设计者还可以对字体包进行命名等操作。

步骤2.图标字体设计客户端上传字体包：在图标字体设计客户端完成图标字体的设计以及打包操作后，可以上传到统一的图标字体管理服务端。

步骤3.图标字体管理服务端为字体包分配URL，并为各图标生成编码：图标字体管理服务端在接收到图标字体设计客户端上传到字体包后，就可以将字体包进行保存，并为字体包分配地址标识，在图3所示的例子中，以URL作为地址标识。每个字体包具有各自不同的地址标识，通过这种地址标识可以唯一定位到一个字体包。另外，还可以为字体包内的图标生成图标编码，这样，通过字体包的地址标识以及图标编码，即可唯一定位到一个图标。

步骤4.应用程序开发客户端向图标字体管理服务端查询可用字体的URL以及图标编码：图标字体管理服务端可以向应用程序开发者提供查询服务，这样，在开发具体的应用程序时，应用程序开发者可以从图标字体管理服务端查询有哪些可用的字体包，各个字体包内包括哪些图标，这些信息都可以通过界面化的形式进行展示，使得开发者可以查看到每个图标的具体样式等，以便其进行选择。

步骤5.应用程序开发客户端在编辑界面过程中，为界面中的显示区域指定字体URL以及图标编码：在查看了可用的字体包以及各字体包内的图标样式后，可以从中进行选择，并确定出选择的目标字体包的URL以及该目标字体包内目标图标的图标编码。

步骤6.应用程序开发客户端将界面中显示区域与URL+图标编码之间的对应关系提交到应用程序服务端进行保存：在为界面中的指定显示区域选择了目标字体包以及目标图标后，关于目标字体包的URL以及目标图标的图标编码信息，并不是直接写在界面代码中，而是保存到应用程序服务端，这样，可以通过应用程序服务端实时下发的方式，来提供界面中显示区域具体展示哪个图标字体。

步骤7.应用程序服务端接收应用程序客户端的界面访问请求：应用程序服务端在保存了界面数据后，就可以对界面进行发布，用户可以访问对应的界面。在本申请实施例中，应用程序服务端保存的界面数据，除了界面代码、界面中具体展示哪些数据对象(例如，商品对象等)的信息之外，还包括具体某个显示区域内显示的图标字体的信息，包括字体包的URL以及图标编码，这部分信息与数据对象等信息是并列关系。

步骤8.应用程序服务端向应用程序客户端实时下发界面中显示区域与URL+编码之间的对应关系信息：在向客户端提供界面数据时，除了提供界面代码、界面内待展示的数据对象等信息之外，还会另外提供界面中目标显示区域内待展示的图标字体对应的字体包的URL以及图标编码。

步骤9.应用程序客户端判断服务端下发的URL对应的字体文件是否在本地缓存中存在，若存在，则从本地缓存中加载，否则进入到步骤10。在该图3所示的例子提供了一种优选的实现方式，也即采用了缓存机制。也就是说，应用程序客户端在每次从网络加载一个字体文件后，都可以在本地进行缓存，具体还可以包括内存缓存以及磁盘缓存两种；这样，在当前界面访问过程中，收到服务端下发的URL后，就可以首先判断本地缓存中是否存在该URL对应的字体文件，如果存在，就不需要到网络中加载了，直接在本地加载即可。

步骤10.应用程序客户端按照服务端提供的URL从网络加载对应的字体文件：如果本地缓存中不存在当前服务端下发的URL对应的字体文件，则证明之前没有加载过该字体文件，或者该字体文件相当于之前的加载时刻已经发生了更新，因此，可以按照该URL从图标字体管理服务端实时加载对应的字体文件。

步骤11：图标字体管理服务端向应用程序客户端下发该URL对应的字体文件。

步骤12.应用程序客户端将本地加载和/或网络加载的字体文件转换为***可识别的结构体，并写入内存，由***原生的视觉组件进行显示：在该图3所示的例子中，在图标的展示方面也采用了优选的实现方式，也即，通过对字体文件的转换，使得能够使用***原生的视觉组件进行图标字体的展示，而不再需要预先定制视觉组件。需要说明的是，对于iOS等***而言，在从网络加载完成一个字体文件后，还可以根据字体文件的地址标识等信息，为字体文件生成具有唯一性的文件名，然后再注册到***中，避免由于字体包重名问题导致的相互覆盖。

步骤13.应用程序客户端将长时间未使用的字体文件的信息从内存缓存中清除，并写入到磁盘缓存中：对于写入到内存中的结构体，可以在内存缓存中进行保存，下次再使用该字体文件时，可以直接从内存缓存中进行最快速的加载，但是，如果某字体文件长时间未被使用，则会造成会内存缓存资源的浪费，因此，可以从内存缓存中清除，写入到磁盘缓存中。

以上所述通过一个具体应用中的例子，对本申请实施例的实现流程进行了介绍。需要说明的是，上述例子中存在一些步骤，在实际应用中并不是必须的，例如，在不考虑用户流量占用的情况下，可以不必对加载的字体文件进行缓存，在不考虑是否使用***原生视觉组件的情况下，还可以不必对字体文件进行转换，直接使用预先定制的视觉组件进行展示，等等。

根据以上描述，本申请从多种角度提供了多个具体的实施例，下面分别进行介绍。

实施例一

首先，该实施例一提供了一种图标字体信息处理***，参见图5，该***具体可以包括：

第一服务端501，用于保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；

第一客户端502，用于在编辑目标应用程序的目标界面过程中，从所述第一服务端查询获得可选的图标字体包信息以及图标字体包内的图标信息，为目标界面中的目标显示区域确定目标字体包以及目标图标，将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端504；

第二客户端503，用于访问目标界面，并向所述第二服务端504请求获取所述目标界面的界面数据；

所述第二服务端504，用于接收到所述第二客户端503的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息；

所述第二客户端503还用于：根据所述第二服务端504提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

需要说明的是，以上关于第一服务端以及第二服务端，是在功能上进行了区分，而在实际应用中，第一服务端与第二服务端可能是相互独立的，也可能是同一服务器中的不同功能模块，这里不进行限定。

具体实现时，图5中的第一服务端可以是指图2中所示的图标字体管理服务端，第一客户端可以是指应用程序开发客户端，第二服务端可以是指应用程序服务端，第二客户端可以是指应用程序客户端。当然，在实际应用中，上述服务端、客户端可以有多种描述方式，因此，本申请实施例中统一称为“第一”、“第二”服务端或客户端。

具体实现时，所述第一服务端还可以用于，接收到对指定字体包进行更新的请求时，为更新后的字体包分配新的地址标识。

其中，所述第一服务端针对同一目标应用程序保存的图标字体包为多个。并且，在可选的实现方式中，同一目标应用程序关联的各个图标字体包可以分别对应该同一目标应用程序中的不同业务线。当然，在实际应用中，也可以从其他维度上对字体包进行拆解，这里不再一一列举。

在具体实现时，所述第一客户端还可以用于，对所述对应关系进行更新，并将更新后的对应关系保存到所述第二服务端，以便在新接收到第二客户端的访问请求时，向所述第二客户端提供更新后的对应关系信息。

所述第二客户端在加载对应的字体文件时具体可以用于，根据所述目标字体包的地址标识，判断本地缓存中是否存在所述目标字体包，如果存在，则从本地缓存中加载对应的字体文件，否则，从网络加载对应的字体文件，并将从网络加载完成的字体文件的信息写入本地缓存。

其中，所述本地缓存包括内存缓存以及磁盘缓存；

所述第二客户端在将从网络加载完成的字体文件的信息写入本地缓存时具体用于：将从网络加载完成的字体文件的信息写入内存缓存，如果所述内存缓存中的字体文件距离上次被使用的时间超过预置的阈值，则将该字体文件的信息从所述内存缓存中清除，并写入到磁盘缓存；

相应的，所述第二客户端在判断本地缓存中是否存在所述目标字体包时具体可以用于：判断所述内存缓存中是否存在所述目标字体包，如果存在，则从内存缓存中加载，否则，判断所述磁盘缓存中是否存在所述目标字体包，如果存在，则从所述磁盘缓存中加载，否则，再从网络加载。

为了避免应用程序开发者预先定制视觉组件，所述第二客户端在根据所述目标图标的图标编码，在对应的显示区域展示对应的图标时具体可以用于：将加载成功的字体文件转换为操作***可识别的结构体，以便利用操作***原生的视觉组件对所述目标图标进行展示。

另外，对于iOS等操作***，所述第二客户端在加载成功对应的字体文件后还可以用于：根据所述目标字体包的地址标识生成文件名，并利用生成的文件名对所述字体文件的原文件名进行修改后，将所述字体文件注册到操作***中。

通过本申请实施例提供的上述***，可以将图标字体包统一通过第一服务端进行保存，并且，第一服务端能够为图标字体包分配唯一性的地址标识，还可以为每个字体包内的各个图标分别生成各自的图标编码，这样，可以通过字体包的地址标识+图标的图标编码这两方面的信息，唯一确定一个图标。在应用程序开发者编辑界面的过程中，可以为界面中具体的显示区域指定目标字体包的地址标识，以及目标图标的图标编码，并将这种对应关系信息保存到第二服务端。用户在通过第二客户端访问目标界面时，第二服务端可以向第二客户端提供界面数据，其中就可以包括上述对应关系信息，也即，关于界面中具体显示区域需要展示怎样的图标，可以是由第二服务端实时下发给第二客户端的。之后，第二客户端可以根据第二服务端提供的地址标识，加载对应的字体文件，并根据图标编码，在对应的显示区域内展示出对应的图标。通过这种方式，可以实现对图标字体的统一管理，并且，通过第二服务端实时下发对应关系的方式，使得应用程序开发者不需要在待发布的应用程序中内置图标字体包，实现应用程序与图标字体包之间的解耦。后续需要对界面内具体显示区域显示的图标进行更新时，也只需要对第二服务端保存的对应关系进行更新，之后，第二客户端就可以实时接收到更新后的对应关系信息，实现界面中对应显示区域内图标的更新，而不再需要对应用程序的版本进行更新，因此，可以降低成本，提高应用程序的上线效率。

另外，通过为每个图标字体包分配唯一性的地址标识，还可以实现图标字体包的拆解，也即，同一个应用程序所需要用到的图标字体不再需要打包在同一个图标字体包中，而是可以为同一个应用程序提供多个图标字体包，例如，可以从业务线维度上拆解为多个字体包，等等。这样，可以避免同一个图标字体包内包含的图标数量过多而导致字体包体积过于庞大，降低对字体包的管理及维护难度。

再者，在图标字体的使用方式上，本申请实施例还可以在从网络加载了字体文件后，首先进行转换，将字体文件转换为操作***可识别的结构体，之后再写入内存中，这样就可以由操作***原生的视觉组件来实现对图标字体的展示，而不再需要应用程序开发者预先定制视觉组件，因此，可以降低应用程序开发者的工作量，提高应用程序的开发效率。

实施例二

该实施例二从第一服务端的角度，提供了一种图标字体信息处理方法，参见图6，该方法具体可以包括：

S601：保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；

S602：接收到第一客户端的查询请求时，提供可选的图标字体包信息以及图标字体包内的图标信息，由第一客户端为目标界面中的目标显示区域确定目标字体包以及目标图标，并将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端。

所述第二服务端在接收到第二客户端的界面访问请求时，将所述对应关系提供给所述第二客户端，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

具体实现时，还可以在接收到对指定字体包进行更新的请求时，为更新后的字体包分配新的地址标识。

其中，针对同一目标应用程序保存的图标字体包可以为多个。具体可以从业务线等维度，对同一目标应用程序的图标字体包进行拆解。

实施例三

该实施例三是从第一客户端的角度，提供了一种图标字体信息处理方法，参见图7，该方法具体可以包括：

S701：在编辑目标应用程序的目标界面过程中，从所述第一服务端查询获得可选的图标字体包信息以及图标字体包内的图标信息；

S702：为目标界面中的目标显示区域确定目标字体包以及目标图标；

S703：将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端。

所述第二服务端在接收到第二客户端的界面访问请求时，将所述对应关系提供给所述第二客户端，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

具体实现时，还可以对所述对应关系进行更新，并将更新后的对应关系保存到所述第二服务端，以便在新接收到第二客户端的访问请求时，向所述第二客户端提供更新后的对应关系信息。

实施例四

该实施例四是从第二服务端的角度，提供了一种图标字体信息处理方法，参见图8，该方法具体可以包括：

S801：保存第一客户端提交的配置信息，所述配置信息中包括目标界面、目标显示区域与目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；

S802：接收到第二客户端的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

具体实现时，还可以根据所述第一客户端的请求对所述对应关系进行更新，在新接收到第二客户端的访问请求时，向所述第二客户端提供更新后的对应关系信息。

实施例五

该实施例五主要是从第二客户端的角度，提供了一种图标字体信息处理方法，参见图9，该方法具体可以包括：

S901：访问目标界面，并向第二服务端请求获取所述目标界面的界面数据；

S902：接收所述第二服务端提供的界面数据，所述界面数据中包括目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；

S903：根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件；

S904：根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

具体实现时，为了降低对用户流量的占用，可以采用缓存机制，也即，每次从网络加载的字体文件，都可以在用户的终端设备本地进行缓存，这样，具体在根据目标字体包的地址标识加载对应的字体文件时，具体的处理流程可以是：

根据所述目标字体包的地址标识，判断本地缓存中是否存在所述目标字体包；如果存在，则从本地缓存中加载对应的字体文件；否则，从网络加载对应的字体文件，并将从网络加载完成的字体文件的信息写入本地缓存。

具体的，参见图10，上述加载过程可以包括如下步骤：

S1001：判断是否指定了字体包地址标识；如果是，则证明第二服务端提供了目标显示区域对应的字体包地址标识，进入步骤S1003，否则，进入步骤S1002；

S1002：加载操作***的默认字体；

S1003：判断指定的字体包地址标识是否命中本地缓存；如果是，进入步骤S1004，否则进入步骤S1005；

S1004：从本地缓存加载字体文件；

S1005：从网络加载字体文件；

S1006：判断网络记载是否成功，如果不成功进入步骤S1002，否则进入步骤S1007；

S1007：将字体文件写入缓存；

S1008：根据加载成功的字体文件，进行图标字体的展示。

其中，具体实现时，所述本地缓存包括内存缓存以及磁盘缓存，具体写入本地缓存的过程可以是：

首先将从网络加载完成的字体文件的信息写入内存缓存；如果所述内存缓存中的字体文件距离上次被使用的时间超过预置的阈值，则将该字体文件的信息从所述内存缓存中清除，并写入到磁盘缓存。

具体判断本地缓存中是否存在所述目标字体包的过程可以是：

首先，判断所述内存缓存中是否存在所述目标字体包，如果存在，则从内存缓存中加载；否则，判断所述磁盘缓存中是否存在所述目标字体包，如果存在，则从所述磁盘缓存中加载。

也即，参见图11，在一种具体的实现方式下，将具体判断是否命中本地缓存的过程可以包括：

S1101：判断目标字体包的地址标识是否命中内存缓存，如果命中，则进入步骤S1104，否则，进入步骤S1102；

S1102：判断目标字体包的地址标识是否命中磁盘缓存，如果命中，则进入步骤S1103，否则，进入步骤S1105；

S1103：将磁盘缓存中对应的字体文件写入内存缓存；

S1104：返回命中状态；

S1105：返回未命中状态。

在具体实现时，为了避免应用程序开发者自行定制视觉组件，还可以将加载成功的字体文件转换为操作***可识别的结构体，以便利用操作***原生的视觉组件对所述目标图标进行展示。

另外，针对iOS等操作***，由于其根据文件名来识别不同的字体包，因此，为了避免不同的字体包因为文件名相同在注册仅***中相互覆盖，在优选的实现方式中，还可以在加载成功对应的字体文件后，根据所述目标字体包的地址标识生成文件名，并利用生成的文件名对所述字体文件的原文件名进行修改后，将所述字体文件注册到操作***中。

上述第二客户端在具体实现时，根据不同的操作***环境，可以有不同的具体实现方式。例如，图12所示为本申请在Android手机***环境下的具体实施例。从图中可以看到整个框架有两个核心类Jekyll和Dispatcher。其中，Jekyll对外提供完整的功能接口，Dispatcher用于任务的分发和执行。Dispatcher内启用了一个任务分发线程DispatcherThread和任务执行线程池ExecutorService。其中：

Jekyll通过依次调用load和into两个方法生成一个Action对象，即任务。该Action通过DispatcherThread(任务分发线程)被路由到指定的执行模块。

IconfontHunter作为执行模块，被提交到ExecutorService(任务执行线程池)中执行。在执行过程中，IconfontHunter会选择合适的RequestHandler即处理器模块，执行具体的icon font加载工作。加载过程中，IconfontHunter由memory cache(内存缓存)和diskcache(磁盘缓存)提供具体的本地缓存支持。

Icon font加载(或从本地或从网络)成功后，可以被转化为Android***可识别的结构体Typeface，之后可以被设置到显示模块TextView上，该TextView是Android***原生的文本视觉组件。

需要说明的是，关于上述实施例一至实施例五的具体实现，可以参见前述本申请前述内容的记载，这里不再赘述。

与实施例二相对应，本申请实施例还提供了一种图标字体信息处理装置，参见图13，该装置可以包括：

信息分配单元1301，用于保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；

信息提供单元1302，用于接收到第一客户端的查询请求时，提供可选的图标字体包信息以及图标字体包内的图标信息，由第一客户端为目标界面中的目标显示区域确定目标字体包以及目标图标，并将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端。

其中，所述第二服务端在接收到第二客户端的界面访问请求时，将所述对应关系提供给所述第二客户端，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

具体实现时，该装置还可以包括：

地址标识更新单元，用于接收到对指定字体包进行更新的请求时，为更新后的字体包分配新的地址标识。

其中，针对同一目标应用程序保存的图标字体包可以为多个。

与实施例三相对应，本申请实施例还提供了一种图标字体信息处理装置，参见图14，该装置可以包括：

查询单元1401，用于在编辑目标应用程序的目标界面过程中，从所述第一服务端查询获得可选的图标字体包信息以及图标字体包内的图标信息；

图标确定单元1402，用于为目标界面中的目标显示区域确定目标字体包以及目标图标；

对应关系信息提交单元1403，用于将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端。

其中，所述第二服务端在接收到第二客户端的界面访问请求时，将所述对应关系提供给所述第二客户端，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

具体实现时，该装置还可以包括：

对应关系更新单元，用于对所述对应关系进行更新，并将更新后的对应关系保存到所述第二服务端，以便在新接收到第二客户端的访问请求时，向所述第二客户端提供更新后的对应关系信息。

与实施例四相对应，本申请实施例还提供了一种图标字体信息处理装置，参见图15，该装置可以包括：

配置信息保存单元1501，用于保存第一客户端提交的配置信息，所述配置信息中包括目标界面、目标显示区域与目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；

对应关系信息实时下发单元1502，用于接收到第二客户端的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

具体实现时，该装置还可以包括：

对应关系更新单元，用于根据所述第一客户端的请求对所述对应关系进行更新，在新接收到第二客户端的访问请求时，向所述第二客户端提供更新后的对应关系信息。

与实施例五相对应，本申请实施例还提供了一种图标字体信息处理装置，参见图16，该装置可以包括：

访问请求提交单元1601，用于访问目标界面，并向第二服务端请求获取所述目标界面的界面数据；

界面数据接收单元1602，用于接收所述第二服务端提供的界面数据，所述界面数据中包括目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；

字体文件加载单元1603，用于根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件；

图标展示单元1604，用于根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

具体实现时，所述字体文件加载单元具体可以包括：

判断子单元，用于根据所述目标字体包的地址标识，判断本地缓存中是否存在所述目标字体包；

本地加载子单元，用于如果本地缓存中存在所述目标字体包，则从本地缓存中加载对应的字体文件；

网络加载子单元，用于如果本地缓存中不存在所述目标字体包，则从网络加载对应的字体文件，并将从网络加载完成的字体文件的信息写入本地缓存。

具体实现时，所述本地缓存包括内存缓存以及磁盘缓存；

所述网络加载子单元具体可以包括：

内存缓存写入子单元，用于将从网络加载完成的字体文件的信息写入内存缓存；

磁盘缓存写入子单元，用于如果所述内存缓存中的字体文件距离上次被使用的时间超过预置的阈值，则将该字体文件的信息从所述内存缓存中清除，并写入到磁盘缓存。

相应的，所述判断子单元具体可以包括：

内存缓存判断子单元，用于判断所述内存缓存中是否存在所述目标字体包，如果存在，则从内存缓存中加载；

磁盘缓存判断子单元，用于如果内存缓存未命中，则判断所述磁盘缓存中是否存在所述目标字体包，如果存在，则从所述磁盘缓存中加载。

具体实现时，所述图标展示单元具体可以用于：

将加载成功的字体文件转换为操作***可识别的结构体，以便利用操作***原生的视觉组件对所述目标图标进行展示。

针对iOS等操作***，该装置还可以包括：

在加载成功对应的字体文件后，根据所述目标字体包的地址标识生成文件名，并利用生成的文件名对所述字体文件的原文件名进行修改后，将所述字体文件注册到操作***中。

与前述实施例相对应，本申请实施例还提供了一种计算机***，该***可以包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:

保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内每个图标生成图标编码；

在编辑目标应用程序的目标界面过程中，为目标界面中的目标显示区域确定目标字体包以及目标图标，将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端；

通过所述第二服务端接收到第二客户端的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

另外，本申请实施例还提供了另一种计算机***，该***可以包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:

访问目标界面，并向第二服务端请求获取所述目标界面的界面数据；

接收所述第二服务端提供的界面数据，所述界面数据中包括目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；

根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件；

根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

其中，图17示例性的展示出了计算机***的架构，具体可以包括处理器1710，视频显示适配器1711，磁盘驱动器1712，输入/输出接口1713，网络接口1714，以及存储器1720。上述处理器1710、视频显示适配器1711、磁盘驱动器1712、输入/输出接口1713、网络接口1714，与存储器1720之间可以通过通信总线1730进行通信连接。

其中，处理器1710可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器1720可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1720可以存储用于控制计算机***1700运行的操作***1721，用于控制计算机***1700的低级别操作的基本输入输出***(BIOS)。另外，还可以存储网页浏览器1723，数据存储管理***1724，以及图标字体信息处理***1725等等。上述图标字体信息处理***1725就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器1720中，并由处理器1710来调用执行。

输入/输出接口1713用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1714用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1730包括一通路，在设备的各个组件(例如处理器1710、视频显示适配器1711、磁盘驱动器1712、输入/输出接口1713、网络接口1714，与存储器1720)之间传输信息。

另外，该计算机***1700还可以从虚拟资源对象领取条件信息数据库1741中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器1710、视频显示适配器1711、磁盘驱动器1712、输入/输出接口1713、网络接口1714，存储器1720，总线1730等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***或***实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的***及***实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的图标字体信息处理方法、装置及***，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (19)

1.一种图标字体信息处理***，其特征在于，包括：

第一服务端，用于保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；还用于针对同一目标应用程序的图标字体包进行拆解，得到多个字体包；

第一客户端，用于在编辑目标应用程序的目标界面过程中，从所述第一服务端查询获得可选的图标字体包信息以及图标字体包内的图标信息，为目标界面中的目标显示区域确定目标字体包以及目标图标，将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端；

第二客户端，用于访问目标界面，并向所述第二服务端请求获取所述目标界面的界面数据；

所述第二服务端，用于接收到所述第二客户端的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息；

所述第二客户端还用于：根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

2.一种图标字体信息处理方法，其特征在于，包括：

第一服务端保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；还用于针对同一目标应用程序的图标字体包进行拆解，得到多个字体包；

接收到第一客户端的查询请求时，提供可选的图标字体包信息以及图标字体包内的图标信息，由第一客户端为目标界面中的目标显示区域确定目标字体包以及目标图标，并将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端。

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

接收到对指定字体包进行更新的请求时，为更新后的字体包分配新的地址标识。

4.根据权利要求2所述的方法，其特征在于，针对同一目标应用程序保存的图标字体包为多个。

5.一种图标字体信息处理方法，其特征在于，包括：

第一客户端在编辑目标应用程序的目标界面过程中，从第一服务端查询获得可选的图标字体包信息以及图标字体包内的图标信息；所述第一服务端用于保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；还用于针对同一目标应用程序的图标字体包进行拆解，得到多个字体包；

为目标界面中的目标显示区域确定目标字体包以及目标图标；

将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端。

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

对所述对应关系进行更新，并将更新后的对应关系保存到所述第二服务端，以便在新接收到第二客户端的访问请求时，向所述第二客户端提供更新后的对应关系信息。

7.一种图标字体信息处理方法，其特征在于，包括：

第二服务端保存第一客户端提交的配置信息，所述配置信息中包括目标界面、目标显示区域与目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；所述第一服务端还用于针对同一目标应用程序的图标字体包进行拆解，得到多个字体包；

接收到第二客户端的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

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

根据所述第一客户端的请求对所述对应关系进行更新，在新接收到第二客户端的访问请求时，向所述第二客户端提供更新后的对应关系信息。

9.一种图标字体信息处理方法，其特征在于，包括：

第二客户端访问目标界面，并向第二服务端请求获取所述目标界面的界面数据；

接收所述第二服务端提供的界面数据，所述界面数据中包括目标界面、目标显示区域与目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；所述第一服务端还用于针对同一目标应用程序的图标字体包进行拆解，得到多个字体包；

根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件；

根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

10.根据权利要求9所述的方法，其特征在于，所述根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，包括：

根据所述目标字体包的地址标识，判断本地缓存中是否存在所述目标字体包；

如果存在，则从本地缓存中加载对应的字体文件；

否则，从网络加载对应的字体文件，并将从网络加载完成的字体文件的信息写入本地缓存。

11.根据权利要求10所述的方法，其特征在于，所述本地缓存包括内存缓存以及磁盘缓存；

所述将从网络加载完成的字体文件的信息写入本地缓存，包括：

将从网络加载完成的字体文件的信息写入内存缓存；

如果所述内存缓存中的字体文件距离上次被使用的时间超过预置的阈值，则将该字体文件的信息从所述内存缓存中清除，并写入到磁盘缓存；

所述判断本地缓存中是否存在所述目标字体包，包括：

判断所述内存缓存中是否存在所述目标字体包，如果存在，则从内存缓存中加载；

否则，判断所述磁盘缓存中是否存在所述目标字体包，如果存在，则从所述磁盘缓存中加载。

12.根据权利要求9所述的方法，其特征在于，所述根据所述目标图标的图标编码，在对应的显示区域展示对应的图标，包括：

将加载成功的字体文件转换为操作***可识别的结构体，以便利用操作***原生的视觉组件对所述目标图标进行展示。

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

在加载成功对应的字体文件后，根据所述目标字体包的地址标识生成文件名，并利用生成的文件名对所述字体文件的原文件名进行修改后，将所述字体文件注册到操作***中。

14.一种图标字体信息处理装置，其特征在于，包括：

信息分配单元，用于保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；还用于针对同一目标应用程序的图标字体包进行拆解，得到多个字体包；

信息提供单元，用于接收到第一客户端的查询请求时，提供可选的图标字体包信息以及图标字体包内的图标信息，由第一客户端为目标界面中的目标显示区域确定目标字体包以及目标图标，并将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端。

15.一种图标字体信息处理装置，其特征在于，包括：

查询单元，用于在编辑目标应用程序的目标界面过程中，从第一服务端查询获得可选的图标字体包信息以及图标字体包内的图标信息；所述第一服务端用于保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；还用于针对同一目标应用程序的图标字体包进行拆解，得到多个字体包；

图标确定单元，用于为目标界面中的目标显示区域确定目标字体包以及目标图标；

对应关系信息提交单元，用于将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端。

16.一种图标字体信息处理装置，其特征在于，包括：

配置信息保存单元，用于保存第一客户端提交的配置信息，所述配置信息中包括目标界面、目标显示区域与目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；所述第一服务端还用于针对同一目标应用程序的图标字体包进行拆解，得到多个字体包；

对应关系信息实时下发单元，用于接收到第二客户端的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息，由所述第二客户端根据第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

17.一种图标字体信息处理装置，其特征在于，包括：

访问请求提交单元，用于访问目标界面，并向第二服务端请求获取所述目标界面的界面数据；

界面数据接收单元，用于接收所述第二服务端提供的界面数据，所述界面数据中包括目标界面、目标显示区域与目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；所述第一服务端还用于针对同一目标应用程序的图标字体包进行拆解，得到多个字体包；

字体文件加载单元，用于根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件；

图标展示单元，用于根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

18.一种计算机***，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:

保存图标字体包，为所述图标字体包分配唯一性地址标识，并为图标字体包内的图标生成图标编码；针对同一目标应用程序的图标字体包进行拆解，得到多个字体包；

在编辑目标应用程序的目标界面过程中，为目标界面中的目标显示区域确定目标字体包以及目标图标，将所述目标界面、目标显示区域与所述目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息，保存到第二服务端；

通过所述第二服务端接收到第二客户端的界面访问请求时，向所述第二客户端提供所述目标界面的界面数据，所述界面数据中包括所述对应关系信息，由所述第二客户端根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件，并根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

19.一种计算机***，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:

访问目标界面，并向第二服务端请求获取所述目标界面的界面数据；

接收所述第二服务端提供的界面数据，所述界面数据中包括目标界面、目标显示区域与目标字体包的地址标识以及目标图标的图标编码之间的对应关系信息；其中，所述字体包的地址标识以及图标编码由第一服务端分配，所述字体包保存在所述第一服务端中；所述第一服务端还用于针对同一目标应用程序的图标字体包进行拆解，得到多个字体包；

根据所述第二服务端提供的目标字体包的地址标识加载对应的字体文件；

根据所述目标图标的图标编码，在对应的显示区域展示对应的图标。

Images