CN109492195B - 一种字体加载方法、装置、终端及存储介质 - Google Patents

Abstract

本发明实施例公开了一种字体加载方法、装置、终端及存储介质。该方法包括：将字体文件分解为至少两个子字体文件；通过至少两个子线程将各子字体文件并行转换为各字体承载集Typeface；将各字体承载集Typeface合并得到总字体承载集，并将总字体承载集加载至字体映射表SystemFontMap中。本发明实施例的技术方案，解决了非系统字体文件加载速度较慢而导致应用程序无响应的问题，使得应用程序可以快速加载全部的系统字体文件和非系统字体文件，以便同时兼顾响应速度和各种字体的显示效果。

Description

一种字体加载方法、装置、终端及存储介质

技术领域

本发明实施例涉及计算机应用技术，尤其涉及一种字体加载方法、装置、终端及存储介质。

背景技术

安卓应用程序(Android Application)在首次启动的过程中会加载非系统字体，其需要将字体文件初始化以转化为字体承载集(Typeface)后，方可供应用程序的逻辑层读取使用。当字体文件过大时，加载过程较为耗时，使得应用程序的启动速度较慢，容易出现应用程序无响应(Application Not Responding，ANR)的现象。

现有技术中通常采用压缩字体的方式以减小字体的体积，例如剔除倾斜字体(Italic)和粗壮字体(Bold)，只保留常规字体(Regular)等，进而加快字体的加载速度。但是，上述方案使得一些界面的显示效果较差，影响了用户的体验，无法同时兼顾应用程序的响应速度和显示效果。

发明内容

本发明实施例提供了一种字体加载方法、装置、终端及存储介质，解决了非系统字体加载速度较慢而导致ANR问题，使得应用程序可以同时兼顾响应速度和显示效果。

第一方面，本发明实施例提供了一种字体加载方法，可以包括：

将字体文件分解为至少两个子字体文件；

通过至少两个子线程将各子字体文件并行转换为各字体承载集Typeface；

将各字体承载集Typeface合并得到总字体承载集，并将总字体承载集加载至字体映射表SystemFontMap中。

可选的，将字体文件分解为至少两个子字体文件，可以包括：

以英文字母a-z作为类型标识，基于预设的聚类算法将字体文件分解为至少两个子字体文件。

可选的，以英文字母a-z作为类型标识，基于预设的聚类算法将字体文件分解为至少两个子字体文件，可以包括：

创建以英文字母a-z为类型标识的各空字符集，以及分别与各空字符集匹配的相似矩阵A_i，其中相似矩阵A_i是与以索引为i的英文字母为类型标识的空字符集匹配，i取0-25的正整数；

建立对角线长度为字体文件的长度的单位矩阵A^T；

根据字体文件中各字符的类型标识，确定与各字符分别对应的相似矩阵A_i，并根据如下公式确定特征向量v_i：v_i＝A_iA^T；

基于特征向量v_i将字体文件中各字符分解至各空字符集中，将得到的各空字符集作为各子字体文件。

可选的，将各字体承载集Typeface合并得到总字体承载集，可以包括：

建立用于存储各字体承载集Typeface的第一数组，其中，第一数组的长度是字体承载集Typeface的个数；

创建以两个相邻英文字母为对角线元素的对角矩阵L；

基于第一数组和对角矩阵L将各字体承载集Typeface进行结构化合并，得到总字体承载集。

可选的，将各字体承载集Typeface进行结构化合并，得到总字体承载集，可以包括：

建立用于存储总字体承载集的第二数组，其中，第二数组的长度是字体文件的长度；

L[j]表示对角矩阵L中索引为j的元素，将j初始化为0；

以第一数组的首个字体承载集Typeface作为当前元素，根据当前元素的首字母α和下一个元素的首字母β组成二元转置矩阵

判断m×L[j]＝0是否成立；若是，则将当前元素拷贝至第二数组中；否则，将下一个元素更新为当前元素，返回执行根据当前元素的首字母α和下一个元素的首字母β组成二元转置矩阵m的操作，直至m×L[j]＝0成立；

将j+1的结果更新为j，返回执行以第一数组的首个字体承载集Typeface作为当前元素的操作，直至j＝26，并以第二数组存储的元素作为总字体承载集。

可选的，通过至少两个子线程将各所述子字体文件并行转换为各字体承载集Typeface，可以包括：

根据已创建的线程池，得到至少两个子线程；

在各子线程中基于预设的字符编码标准将各子字体文件并行转换为各字体承载集Typeface。

可选的，所述方法还可以包括：

根据线程池的构建算法创建线程池ThreadPool²⁶，其中，构建算法包括：

ThreadPool²⁶＝2^core+k；

其中，core表示线程池核心数且取值2或是4，K表示闲置线程数；当core＝2时，k＝22；当core＝4时，k＝10。

第二方面，本发明实施例还提供了一种字体加载装置，该装置可以包括：

字体文件分解模块，用于将字体文件分解为至少两个子字体文件；

子字体文件转换模块，用于通过至少两个子线程将各子字体文件并行转换为各字体承载集Typeface；

各字体承载集合并模块，用于将各字体承载集Typeface合并得到总字体承载集，并将总字体承载集加载至字体映射表SystemFontMap中。

第三方面，本发明实施例还提供了一种终端，该终端可以包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，

当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现本发明任意实施例所提供的字体加载方法。

第四方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现本发明任意实施例所提供的字体加载方法。

本发明实施例的技术方案，通过将字体文件分解为至少两个子字体文件以减小单个字体文件的体积；通过至少两个子线程将各子字体文件并行转换为各字体承载集Typeface，各子字体文件同时转换的方式从整体上缩短了子字体文件的转换时间；将各字体承载集Typeface合并得到总字体承载集，并将总字体承载集加载至字体映射表SystemFontMap中，以缩短业务逻辑层的读取时间。上述技术方案解决了非系统字体文件加载速度较慢而导致应用程序无响应的问题，使得应用程序可以快速加载全部的系统字体文件和非系统字体文件，以便同时兼顾响应速度和各种字体的显示效果。

附图说明

图1是本发明实施例一中的一种字体加载方法的流程图；

图2是本发明实施例一中的一种字体加载方法的示意图；

图3是本发明实施例二中的一种字体加载方法的流程图；

图4是本发明实施例三中的一种字体加载方法中的流程图；

图5是本发明实施例四中的一种字体加载装置的结构框图；

图6是本发明实施例五中的一种终端的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

实施例一

图1是本发明实施例一中提供的一种字体加载方法的流程图。本实施例可适用于安卓应用程序中字体文件加载的情况，尤其适合于安卓应用程序中较大的非系统字体文件加载的情况。该方法可以由本发明实施例提供的字体加载装置来执行，该装置可以由软件和/或硬件的方式实现，该装置可以集成在各种用户终端或服务器上。参见图1，本发明实施例的方法具体包括如下步骤：

S110、将字体文件分解为至少两个子字体文件。

其中，Android系统中的字体文件通常以.TTF格式或是.OTF格式存储，可以包括两种字库：postscript汉字库和truetype字库。其中，非系统字体字库主要采用postscript汉字库，例如倾斜字体(Italic)、粗壮字体(Bold)等系统字体；系统字体字库主要采用采用truetype字库，例如西符字体、符号字体、中日韩等非系统字体。相较于truetype字库，postscript汉字库使用较为方便，但是由于汉字字符较多，在整个字库中占据的比重较大。

而系统字体字库中的系统字体文件是在Android系统体系架构下Framework层，完成加载工作；而非系统字体字库中的非系统字体文件只能在应用程序首次启动的过程中通过读取存储于APP/res/fonts文件目录下的非系统字体文件，完成加载工作。考虑到fonts文件目录下的非系统字体文件的读取工作是在主线程(Main Thread)中进行，因此针对于体积较大的字体文件，可以在主线程中对字体文件(Main-Fonts)进行分解，得到至少两个体积较小的子字体文件(Sub-Fonts)。

其中，本实施例涉及到的主线程(Main Thread)是Android应用程序运行时的主线程，其主要负责向UI组件分发事件，该线程通常不能进行耗时操作，例如网络请求、数据库操作等，否则容易引发ANR异常。

S120、通过至少两个子线程将各子字体文件并行转换为各字体承载集Typeface。

其中，字体承载集(Typeface)是Android系统中的字体承载类，.TTF格式或是.OTF格式的子字体文件需要转换为Typeface格式后，才可被应用程序直接读取；线程(Thread)有时被称为轻量级进程(Lightweight Process，LWP)，是程序执行流的最小单元；而子线程(Sub Thread)是非系统创建的线程，通常是用户自行创建的线程，其一般处理耗时操作。

考虑到当子字体文件的个数较多时，若将各子字体文件均在单线程进行Typeface格式的转换，依然会出现耗时较多的问题。而且主线程不适合进行耗时操作，容易引发ANR异常。相较于主线程，子线程更适合处理耗时操作，而且即使转换任务出现问题也不会对主线程造成影响，导致应用程序崩溃，因此可以通过至少两个子线程将各子字体文件转换为Typeface格式。

可以理解的是，子线程的个数可以小于等于子字体文件的个数，换言之，每个子线程可以处理至少一个子字体文件的转换任务。可选的，为了在较短的时间内完成各子字体文件的转换任务，可以为每个子字体文件创建单独的任务，使得各子线程分别将子字体文件并行转换为Typeface格式。那么，每个子字体文件在单独的线程中转换为Typeface且各子字体文件并行转换，较大程度上解决了字体文件加载过程较为耗时的问题。

S130、将各字体承载集Typeface合并得到总字体承载集，并将总字体承载集加载至字体映射表SystemFontMap中。

其中，字体映射表(SystemFontMap)是Android系统的字体类型映射表，应用程序所需要加载的系统字体文件和非系统字体文件都会装载至SystemFontMap中，以供应用程序的查询和读取。具体地，系统会为每个应用程序创建一个单独的静态对象(sSystemFontMap)，静态对象内部所存储的元素以键值对<FontName,Typeface>格式进行存储，其中FontName是字体文件的名称，Typeface是与FontName对应的字体承载集。系统可以通过调用函数sSystemFontMap.put(<FontName,Typeface>)将Typeface存储至sSystemFontMap，然后业务逻辑层通过调用函数sSystemFontMap.get(FontName)读取对应的Typeface，以完成字体文件的加载工作。

因此，当各子字体文件转换为Typeface格式后，还需要将各Typeface装载至SystemFontMap中。但是，如果直接将各Typeface装载至SystemFontMap中会过于分散，导致业务逻辑层需要读取至少两个Typeface后才可以完成字体文件的加载工作，较为耗时。那么，可以将各Typeface合并得到总字体承载集，并将总字体承载集直接加载至SystemFontMap中。可以理解的是，在主线程中将字体文件分解为至少两个子字体文件，同样地，可以在主线程中将各Typeface合并得到总字体承载集。进一步地，业务逻辑层通过字体文件的名称即可读取对应的总字体承载集，实现字体文件的加载。

为了更好地理解上述步骤的具体实现过程，下面结合图2对本实施例的字体加载方法进行示例性的说明。

可以理解的是，无论是系统字体文件还是非系统字体文件，都是由多个字符组成的字符集。其中，所述字符(Character)可以是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等；而由多个字符组成的字符集(Characterset)种类较多，每个字符集包括的字符个数不同，例如ASCII字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。

如图2所示，以.TTF格式存储的字体文件为例，字体文件是由各字符400组成的字符集30，在主线程10中将存储于fonts文件目录下字符集30分解为各子字体文件，即由各字符400组成的子字符集301-303，字符集30和各子字符集301-303都是以TTF格式存储；通过至少两个子线程20将各子字符集301-303并行转换为各字体承载集501-503；在主线程10中将各字体承载集501-503合并得到总字体承载集60，并将总字体承载集60加载至SystemFontMap中，以完成字体文件的加载工作。

本发明实施例的技术方案，通过将字体文件分解为至少两个子字体文件以减小单个字体文件的体积；通过至少两个子线程将各子字体文件并行转换为各字体承载集Typeface，各子字体文件同时转换的方式从整体上缩短了子字体文件的转换时间；将各字体承载集Typeface合并得到总字体承载集，并将总字体承载集加载至字体映射表SystemFontMap中，以缩短业务逻辑层的读取时间。上述技术方案解决了非系统字体文件加载速度较慢而导致应用程序无响应的问题，使得应用程序可以快速加载全部的系统字体文件和非系统字体文件，以便同时兼顾响应速度和各种字体的显示效果。

一种可选的技术方案，通过至少两个子线程将各子字体文件并行转换为各字体承载集Typeface，具体可以包括：根据已创建的线程池，得到至少两个子线程；在各子线程中基于预设的字符编码标准将各子字体文件并行转换为各字体承载集Typeface。

其中，已创建的线程池可以是可并行执行转换任务的线程池，那么根据已创建的线程池可以得到至少两个子线程。而预设的字符编码标准可以是UTF-8标准，那么.TTF格式或是.OTF格式的各子字体文件可以基于UTF-8标准转换为各Typeface格式。更具体地，Resourse资源管理器可以直接读取各子字体文件，然后输出Typeface格式的对象。上述步骤根据已创建的线程池将各子字体文件并行转换为Typeface，执行简单、效率高。

一种可选的方案，所述方法还可以包括，根据线程池的构建算法创建线程池ThreadPool²⁶，其中，构建算法包括：ThreadPool²⁶＝2^core+k；其中，core表示线程池核心数且core可以取值2或是4，K表示闲置线程数；当core＝2时，k＝22；当core＝4时，k＝10。

其中，为了在较短的时间内完成各子字体文件的转换任务，建立可以并行执行26个任务的线程池ThreadPool²⁶，为各子字体文件创建单独的子线程以执行转换任务。相对于现有的算法，上述线程池的构建算法尤其适合于并行执行26个任务的情况，尤其可以适用于双核CPU设备或是四核CPU设备。上述步骤可以根据线程池核心数动态创建26个子线程以并行执行转换任务，相较于在主线程中单线程的转换方式，明显提升了转换效率。

实施例二

图3是本发明实施例二中提供的一种字体加载方法的流程图。本实施例以上述实施例一为基础进行优化。在本实施例中，将“将字体文件分解为至少两个子字体文件”具体优化为“以英文字母a-z作为类型标识，基于预设的聚类算法将字体文件分解为至少两个子字体文件”。相应的，如图3所示，本实施例的方法具体可以包括如下步骤：

S210、以英文字母a-z作为类型标识，基于预设的聚类算法将字体文件分解为至少两个子字体文件。

其中，考虑到字体文件在SystemFontMap中可以以拉丁符号的形式存储，即字体文件中的各字符的首字母可以是英文字母a-z中的任一个字母。那么，以英文字母a-z作为类型标识，基于预设的聚类算法可以将字体文件分解为至少两个子字体文件。示例性的，英文字母a-z可以划分为元音和辅音，那么根据各字符的首字母是元音字母还是辅音字母为判断原则可以将字体文件分解为两个子字体文件；或者，根据各字符的首字母是英文字母a-z中哪一个字母为判断原则可以将字体文件分解为26个子字体文件。

其中，预设的聚类算法可以是K均值(K-Means)聚类算法、均值漂移聚类算法、基于密度的聚类方法(DBSCAN)、谱聚类(Spectral Clustering)算法等任意现有的聚类算法。基于预设的聚类算法可以逐一判断各字符分别属于哪个子字体文件，以实现字体文件的分解。

S220、通过至少两个子线程将各子字体文件并行转换为各字体承载集Typeface。

S230、将各字体承载集Typeface合并得到总字体承载集，并将总字体承载集加载至字体映射表SystemFontMap中。

本发明实施例的技术方案，以字体文件中各字符的首字母作为特征向量，基于预设的聚类算法分解字体文件的方式是符合字体文件自身的特性的，可以准确地将字体文件分解为至少两个子字体文件，符合用户的实际需求，减小了单个字体文件的体积。

一种可选的方案，当根据各字符的首字母是英文字母a-z中哪一个字母为判断原则将字体文件分解为26个子字体文件时，以英文字母a-z作为类型标识，基于预设的聚类算法将字体文件分解为至少两个子字体文件，具体可以包括：

创建以英文字母a-z为类型标识的各空字符集，以及分别与各空字符集匹配的相似矩阵A_i，其中相似矩阵A_i是与以索引为i的英文字母为类型标识的空字符集匹配，i取0-25的正整数；建立对角线长度为字体文件的长度的单位矩阵A^T；根据字体文件中各字符的类型标识，确定与各字符分别对应的相似矩阵A_i，并根据如下公式确定特征向量v_i：v_i＝A_iA^T；基于特征向量v_i将字体文件中各字符分解至各空字符集中，将得到的各空字符集作为各子字体文件。

其中，分别创建以英文字母a-z为类型标识的26个空字符集，各空字符集不包括任何字符。而各英文字母a-z的索引分别是0-25，例如，索引为0的英文字母是a，索引为1的英文字母是b。因此，相似矩阵A_i可以理解为是与以索引为i的英文字母为类型标识的空字符集匹配，i取0-25的正整数。例如，相似矩阵A₀是与以英文字母a为类型标识的空字符集匹配，相似矩阵A₁是与以英文字母b为类型标识的空字符集匹配，以此类推。单位矩阵是一个主对角线之外的元素皆为0，主对角线上的元素全是1的矩阵。根据待加载的字体文件的长度，即根据待加载的字体文件中字符的个数确定待建立的单位矩阵A^T的对角线长度，并根据所述对角线长度建立单位矩阵A^T。

其中，根据字体文件中各字符的首字母可以确定各字符的类型标识，例如若字符的首字母是a，则与所述字符对应的类型标识是a。若字体文件中的字符的首字母是a-z中任一英文字母，则返回与所述字符对应的相似矩阵是A₀。另外，特征向量v_i和相似矩阵A_i是一一对应关系，根据公式v_i＝A_iA^T可以确定特征向量v_i。例如，当字体文件中的字符的类型标识是a时，特征向量v₀＝A₀A^T。基于上述公式可以确定26个特征向量，字体文件中的各字符都匹配有自身的特征向量。那么，考虑到各空字符集和字体文件中各字符均是以英文字母a-z为类型标识，可以将各字符分解至各空字符集中。例如，可以基于特征向量v_i直接调用谱聚类(Spectral Clustering)算法，将各所述字符分解至各空字符集中，并将得到的各空字符集作为子字体文件。例如，当字符与特征向量v₀相对应时，根据特征向量v₀调用谱聚类算法可以将所述字符分解至以a为类型标识的空字符集。上述技术方案以26个英文字母为分解特征，采用预设的聚类算法将字体文件中的各字符逐一分解，得到各子字体文件。

实施例三

图4是本发明实施例三中提供的一种字体加载方法的流程图。本实施例以上述实施例二为基础进行优化。在本实施例中，将“将各字体承载集Typeface合并得到总字体承载集”具体优化为“建立用于存储各字体承载集Typeface的第一数组，其中，第一数组的长度是字体承载集Typeface的个数；创建以两个相邻英文字母为对角线元素的对角矩阵L；基于第一数组和对角矩阵L将各字体承载集Typeface进行结构化合并，得到总字体承载集”。相应的，如图3所示，本实施例的方法具体可以包括如下步骤：

S310、以英文字母a-z作为类型标识，基于预设的聚类算法将字体文件分解为至少两个子字体文件。

S320、通过至少两个子线程将各子字体文件并行转换为各字体承载集Typeface。

S330、建立用于存储各字体承载集Typeface的第一数组，其中，第一数组的长度是字体承载集Typeface的个数。

其中，建立用于存储各Typeface的第一数组，那么第一数组的长度是各Typeface的个数，所述长度可以是行数也可以是列数。第一数组创建后，将各Typeface存储至第一数组中。

S340、创建以两个相邻英文字母为对角线元素的对角矩阵L。

其中，对角矩阵(diagonal matrix)是一个主对角线之外的元素皆为0的矩阵，示例性的，对角矩阵L的对角线元素可以是两个相邻英文字母，例如对角矩阵

那么，创建以两个相邻英文字母为对角线元素的对角矩阵L可以用于判断各Typeface的排列顺序。

S350、基于第一数组和对角矩阵L将各字体承载集Typeface进行结构化合并，得到总字体承载集。

其中，各子字体文件转换后得到的各Typeface的顺序可能与字体文件中各字符的顺序不同，因此根据存储有各Typeface的第一数组和以两个相邻英文字母为对角线元素的对角矩阵L可以对各Typeface重新排列，使得各Typeface按照英文字母a-z的顺序排列。进一步地，将重新排列后的各Typeface进行结构化合并得到总字体承载集。所述总字体承载集中各字符的排列顺序，与字体文件中各字符的排列顺序相同。

S360、将总字体承载集加载至字体映射表SystemFontMap中。

本发明实施例的技术方案，通过创建用于存储各Typeface的第一数组和以两个相邻英文字母为对角线元素的对角矩阵L，可以对各Typeface重新排列，使得结构化合并后得到的总字体承载集中各字符按照英文字母a-z的顺序排列，符合Android系统常规的读取字体文件的规则。特别地，以26个英文字母组成的对角线元素的对角矩阵作为关联数组结构，还可以应用于其它的结构化合并的场景中，具有一定的可扩展性。

一种可选的技术方案，将各字体承载集Typeface进行结构化合并，得到总字体承载集，具体可以包括：

建立用于存储总字体承载集的第二数组，其中，第二数组的长度是字体文件的长度；L[j]表示对角矩阵L中索引为j的元素，将j初始化为0；以第一数组的首个字体承载集Typeface作为当前元素，根据当前元素的首字母α和下一个元素的首字母β组成二元转置矩阵

判断m×L[j]＝0是否成立，若是，则将当前元素拷贝至第二数组中；否则，将下一个元素更新为当前元素，返回执行根据当前元素的首字母α和下一个元素的首字母β组成二元转置矩阵m的操作，直至m×L[j]＝0成立；将j+1的结果更新为j，返回执行以第一数组的首个字体承载集Typeface作为当前元素的操作，直至j＝26，并以第二数组存储的元素作为总字体承载集。

其中，第二数组的长度是总字体承载集的长度，可以理解为第二数组的行数或是列数是总字体承载集中各字符的个数。L[j]可以是对角矩阵L中索引为j的元素，示例性的，当j＝0时，

其中A^-1是A的转置，B^-1是B的转置。而m×L[j]＝0，可以理解为

为了更好地理解上述步骤的具体实现过程，以下述具体示例为基础，对本实施例的字体加载方法中如何将各字体承载集Typeface进行结构化合并，得到总字体承载集进行说明。

示例性的，假设存储于第一数组中的各Typeface的首字母依次是d、h、a、b、c、x……仅列出26个英文字母中6个英文字母为例。依次扫描第一数组中相邻Typeface元素，确定相邻元素的首字母，并将首字母由小写字母转换为大写字母。上述技术方案的实现过程可以是：

当j＝0时，

此时当前元素的首字母是D，下一个元素的首字母是H，那么二元转置矩阵

由此可知，m×L[0]＝0不成立；则将下一个元素更新为当前元素，即当前元素的首字母是H，下一个元素的首字母是A，那么二元转置矩阵

由此可知，m×L[0]＝0不成立；则将下一个元素更新为当前元素，即当前元素的首字母是A，下一个元素的首字母是B，那么二元转置矩阵

由此可知，m×L[0]＝0成立；则将当前元素拷贝至第二数组中，并与第二数组中的已有元素进行拼接。可以理解的是，当第二数组中未包含任何元素时，直接将当前元素拷贝至第二数组即可。

当j＝1时，

此时当前元素的首字母是D，下一个元素的首字母是H，那么二元转置矩阵

由此可知，m×L[1]＝0不成立；则将下一个元素更新为当前元素，具体实现过程与j＝0类似，直至当前元素的首字母是B，下一个元素的首字母是C，那么二元转置矩阵

由此可知，m×L[1]＝0成立；则将当前元素拷贝至第二数组中，并与第二数组中的已有元素进行拼接。

当j＝2时，以此类推，将符合m×L[j]＝0的当前元素拷贝至第二数组中，直至j＝26时不再返回执行以第一数组的首个字体承载集Typeface作为当前元素的操作。此时第一数组中的各Typeface都拷贝至第二数组中并拼接为一个按照英文字母a-z排序的Typeface元素，由此将第二数组存储的Typeface元素作为总字体承载集。上述技术方案，根据二元转置矩阵m和关联数组结构L可以实现各Typeface的结构化合并，得到了总字体承载集，具有较高的执行效率。

实施例四

图5为本发明实施例四提供的字体加载装置的结构框图，该装置用于执行上述任意实施例所提供的字体加载方法。该装置与上述各实施例的字体加载方法属于同一个发明构思，在字体加载装置的实施例中未详尽描述的细节内容，可以参考上述字体加载方法的实施例。参见图5，该装置具体可包括：字体文件分解模块410、子字体文件转换模块420和各字体承载集合并模块430。

其中，字体文件分解模块410，用于将字体文件分解为至少两个子字体文件；

子字体文件转换模块420，用于通过至少两个子线程将各子字体文件并行转换为各字体承载集Typeface；

各字体承载集合并模块430，用于将各字体承载集Typeface合并得到总字体承载集，并将总字体承载集加载至字体映射表SystemFontMap中。

可选的，字体文件分解模块410，具体可以包括：

字体文件分解单元，用于以英文字母a-z作为类型标识，基于预设的聚类算法将字体文件分解为至少两个子字体文件。

可选的，字体文件分解单元，还具体可以包括：

相似矩阵创建子单元，用于创建以英文字母a-z为类型标识的各空字符集，以及分别与各空字符集匹配的相似矩阵A_i，其中相似矩阵A_i是与以索引为i的英文字母为类型标识的空字符集匹配，i取0-25的正整数；

单位矩阵建立子单元，用于建立对角线长度为字体文件的长度的单位矩阵A^T；

特征向量确定子单元，用于根据字体文件中各字符的类型标识，确定与各字符分别对应的相似矩阵A_i，并根据如下公式确定特征向量v_i：v_i＝A_iA^T；

字体文件分解子单元，用于基于特征向量v_i将字体文件中各字符分解至各空字符集中，将得到的各空字符集作为各子字体文件。

可选的，各字体承载集合并模块430，具体可以包括：

第一数组建立单元，用于建立用于存储各字体承载集Typeface的第一数组，其中，第一数组的长度是字体承载集Typeface的个数；

对角矩阵创建单元，用于创建以两个相邻英文字母为对角线元素的对角矩阵L；

总字体承载集确定单元，用于基于第一数组和对角矩阵L将各字体承载集Typeface进行结构化合并，得到总字体承载集。

可选的，总字体承载集确定单元，具体可以包括：

第二数组建立子单元，用于建立用于存储总字体承载集的第二数组，其中，第二数组的长度是字体文件的长度；

对角矩阵细化子单元，用于L[j]表示对角矩阵L中索引为j的元素，将j初始化为0；

二元转置矩阵组成子单元，用于以第一数组的首个字体承载集Typeface作为当前元素，根据当前元素的首字母α和下一个元素的首字母β组成二元转置矩阵

判断子单元，用于判断m×L[j]＝0是否成立；若是，则将当前元素拷贝至第二数组中；否则，将下一个元素更新为当前元素，返回执行根据当前元素的首字母α和下一个元素的首字母β组成二元转置矩阵m的操作，直至m×L[j]＝0成立；

总字体承载集确定子单元，用于将j+1的结果更新为j，返回执行以第一数组的首个字体承载集Typeface作为当前元素的操作，直至j＝26，将第一数组的字体承载集Typeface存入第二数组中，并以第二数组存储的元素作为总字体承载集。

可选的，子字体文件转换模块420，具体可以包括：

子线程确定单元，用于根据已创建的线程池，得到至少两个子线程；

子字体文件转换单元，用于在各子线程中基于预设的字符编码标准将各子字体文件并行转换为各字体承载集Typeface。

可选的，所述装置还可以包括：

线程池创建模块，用于根据线程池的构建算法创建线程池ThreadPool²⁶，其中，构建算法包括：ThreadPool²⁶＝2^core+k；

其中，core表示线程池核心数且取值2或是4，K表示闲置线程数；当core＝2时，k＝22；当core＝4时，k＝10。

本发明实施例四提供的字体加载装置，通过字体文件分解模块减小了单个字体文件的体积；子字体文件转换模块使得各子字体文件同时转换的方式从整体上缩短了子字体文件的转换时间；各字体承载集合并模块缩短了业务逻辑层的读取时间。上述装置解决了非系统字体文件加载速度较慢而导致应用程序无响应的问题，使得应用程序可以快速加载全部的系统字体文件和非系统字体文件，以便同时兼顾响应速度和各种字体的显示效果。

本发明实施例所提供的字体加载装置可执行本发明任意实施例所提供的字体加载方法，具备执行方法相应的功能模块和有益效果。

值得注意的是，上述字体加载装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

实施例五

图6为本发明实施例五提供的一种终端的结构示意图，如图6所示，该终端包括存储器510、处理器520、输入装置530和输出装置540。终端中的处理器520的数量可以是一个或多个，图6中以一个处理器520为例；终端中的存储器510、处理器520、输入装置530和输出装置540可以通过总线或其它方式连接，图6中以通过总线550连接为例。

存储器510作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的字体加载方法对应的程序指令/模块(例如，字体加载装置中的字体文件分解模块410、子字体文件转换模块420和各字体承载集合并模块430)。处理器520通过运行存储在存储器510中的软件程序、指令以及模块，从而执行终端的各种功能应用以及数据处理，即实现上述的字体加载方法。

存储器510可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器510可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器510可进一步包括相对于处理器520远程设置的存储器，这些远程存储器可以通过网络连接至设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置530可用于接收输入的数字或字符信息，以及产生与装置的用户设置以及功能控制有关的键信号输入。输出装置540可包括显示屏等显示设备。

实施例六

本发明实施例六提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种字体加载方法，该方法包括：

将字体文件分解为至少两个子字体文件；

通过至少两个子线程将各子字体文件并行转换为各字体承载集Typeface；

将各字体承载集Typeface合并得到总字体承载集，并将总字体承载集加载至字体映射表SystemFontMap中。

当然，本发明实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本发明任意实施例所提供的字体加载方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。依据这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (8)

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

将字体文件分解为至少两个子字体文件；

通过至少两个子线程将各所述子字体文件并行转换为各字体承载集Typeface；

将各所述字体承载集Typeface合并得到总字体承载集，并将所述总字体承载集加载至字体映射表SystemFontMap中；

其中，所述将字体文件分解为至少两个子字体文件，包括：

创建以英文字母a-z为类型标识的各空字符集，以及分别与各所述空字符集匹配的相似矩阵A_i，其中相似矩阵A_i是与以索引为i的英文字母为类型标识的空字符集匹配，i取0-25的正整数；

建立对角线长度为所述字体文件的长度的单位矩阵A^T；

根据所述字体文件中各字符的类型标识，确定与各所述字符分别对应的所述相似矩阵A_i，并根据如下公式确定特征向量v_i：

v_i＝A_iA^T；

基于所述特征向量v_i将所述字体文件中各所述字符分解至各所述空字符集中，将得到的各空字符集作为各子字体文件。

2.根据权利要求1所述的方法，其特征在于，所述将各所述字体承载集Typeface合并得到总字体承载集，包括：

建立用于存储各所述字体承载集Typeface的第一数组，其中，所述第一数组的长度是所述字体承载集Typeface的个数；

创建以两个相邻英文字母为对角线元素的对角矩阵L；

基于所述第一数组和所述对角矩阵L将各所述字体承载集Typeface进行结构化合并，得到所述总字体承载集。

3.根据权利要求2所述的方法，其特征在于，将各所述字体承载集Typeface进行结构化合并，得到所述总字体承载集，包括：

建立用于存储所述总字体承载集的第二数组，其中，所述第二数组的长度是所述字体文件的长度；

L[j]表示对角矩阵L中索引为j的元素，将j初始化为0；

以所述第一数组的首个字体承载集Typeface作为当前元素，根据当前元素的首字母α和下一个元素的首字母β组成二元转置矩阵

判断m×L[j]＝0是否成立；若是，则将所述当前元素拷贝至所述第二数组中；否则，将下一个元素更新为当前元素，返回执行根据当前元素的首字母α和下一个元素的首字母β组成二元转置矩阵m的操作，直至m×L[j]＝0成立；

将j+1的结果更新为j，返回执行以所述第一数组的首个字体承载集Typeface作为当前元素的操作，直至j＝26，并以所述第二数组存储的元素作为总字体承载集。

4.根据权利要求1所述的方法，其特征在于，所述通过至少两个子线程将各所述子字体文件并行转换为各字体承载集Typeface，包括：

根据已创建的线程池，得到至少两个子线程；

在各子线程中基于预设的字符编码标准将各所述子字体文件并行转换为各字体承载集Typeface。

5.根据权利要求4所述的方法，其特征在于，还包括：根据所述线程池的构建算法创建线程池ThreadPool²⁶，其中，所述构建算法包括：

ThreadPool²⁶＝2^core+k；

其中，core表示线程池核心数且取值2或是4，K表示闲置线程数；当core＝2时，k＝22；当core＝4时，k＝10。

6.一种字体加载装置，其特征在于，包括：

字体文件分解模块，用于将字体文件分解为至少两个子字体文件；

子字体文件转换模块，用于通过至少两个子线程将各所述子字体文件并行转换为各字体承载集Typeface；

各字体承载集合并模块，用于将各所述字体承载集Typeface合并得到总字体承载集，并将所述总字体承载集加载至字体映射表SystemFontMap中；

其中，所述字体文件分解模块，包括：

相似矩阵创建子单元，用于创建以英文字母a-z为类型标识的各空字符集，以及分别与各所述空字符集匹配的相似矩阵A_i，其中相似矩阵A_i是与以索引为i的英文字母为类型标识的空字符集匹配，i取0-25的正整数；

单位矩阵建立子单元，用于建立对角线长度为所述字体文件的长度的单位矩阵A^T；

特征向量确定子单元，用于根据所述字体文件中各字符的类型标识，确定与各所述字符分别对应的所述相似矩阵A_i，并根据如下公式确定特征向量v_i：

v_i＝A_iA^T；

字体文件分解子单元，用于基于所述特征向量v_i将所述字体文件中各所述字符分解至各所述空字符集中，将得到的各空字符集作为各子字体文件。

7.一种终端，其特征在于，所述终端包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-5中任一所述的字体加载方法。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-5中任一所述的字体加载方法。

Images