粗暴的方式，替换全局字体

序

在 Android 下使用自定义字体已是一个比较常见的需求了，最近也作了个比较深刻的研究。

那么按照惯例我又要出个一篇有关 Android 修改字体相关的文章，可是写下来发现内容还挺多的，因此我决定将它们拆分一下，分几篇来详细的讲解（多是五篇）。主要会是一些经常使用的替换字体的方案，最后还会介绍一些全局替换的方案，固然也会包含最新的 『Fonts in XML』的方案。

期待你持续关注。

本篇是本系列的第三篇，以前已经发布的文章，有兴趣能够先看看。

• Android 字体修改概述|开篇
• 修改字体须要了解 Typeface 的全部细节

1、前言

前面已经分析了修改字体的全部细节，以及与修改字体相关的 Typeface 类，接下来就开始讨论如何修改全局字体。

本篇会先介绍两种比较粗暴的方式来修改全局的字体。

2、自定义字体相关的控件类

在开始一个新的项目的时候，通常习惯好点的都会定义一个 BaseActivity 和 BaseFragment 来做为页面的基类，这样能够方便咱们在以后的时候，对全部页面增长一些统一的逻辑。

不过应该不会有人提早想到要给全部的控件，提早定义一个自定义的控件实现。

可是若是在开发的初期，就已经考虑到字体须要修改的状况的话，是能够重写一些字体显示相关的控件。来达到全局替换字体的做用的。

Android 中，最经常使用的用来显示字体的控件，就是 TextView，这里就重写一个 TextView 来达到替换字体的效果。

在 TextView 中，能够经过 setTypeface() 方法，为 TextView 设置一个字体，setTypeface() 方法有两个重载方法，无非就是多传递了一个须要设置的 textStyle，用来标记粗体和斜体。

其实最终都是调用一个参数的 setTypeface(，它才是设置的关键。

能够看到，设置字体其实是操做的 mTextPaint，mTextPaint 是 TextPaint 类的对象，直接继承自 Paint，就是一个用来绘制文字的画笔。

那么，咱们就能够直接自定义一个 TextView ，在构造函数中，经过 setTypeface() 方法，来修改 TextView 的字体。

主要代码以下：

注意，这里还须要考虑在布局中，为咱们设定的 FontTextView 设置的 textStyle 属性，多是粗体或者斜体。

一般设计师为了考虑 App 的 UI 统一性和协调性，通常都会选用一个字体，因此将须要替换的字体封装在 FontTextView 中，也没有什么大的问题。

那么来验证看看实现出来的效果，这里专门选择了一个比较特殊的字体。在布局 xml 文件中，添加三个 FontTextView。

再来看看运行的效果。

这里也考虑了在布局中设置的 textStyle，而且一个已经比较倾斜的字体，使用 italic 标记以后，更倾斜了。

这个方法，若是在开发初期，还能够接受，无非就是写布局的时候，须要注意使用自定义的控件，同时还除了 TextView ，还须要重写 Button、EditText 等一系列须要显示文字的控件，说到底仍是有点麻烦的。

并且若是是在一个已经成熟的项目上再使用这种方案，改动起来仍是很费劲的，基本上就是一通文本替换，改动会比较大一些。

3、遍历 ViewTree，替换字体

在 Android 中，用于显示文本的控件，都是直接或者间接集成自 TextView 的，那么咱们只须要找一个合适的时机，遍历布局的 ViewTree，将其中全部 TextView 的子类都获取出来，而后批量修改它们的字体，一样也能够达到全局替换的效果。

在这个 replaceCustomFont() 的方法里，回去判断是否继承自 TextView，若是是就替换字体。若是不是，再判断是不是一个 ViewGroup，若是是的话，从其内取出全部的子 View，再递归调用 replaceCustomFont() 方法。

一般，为了在合适的时机修改字体，咱们能够将这个方法加在 Activity.onCreate() 方法，或者 Fragment.onCreateView() 方法的后面，修改的地方，相对少一些，不过还须要考虑 ListView、RecyclverView 这种动态生成 View 的逻辑，也须要注意不能遗漏。

举个例子，写一个布局，在 Activity.onCreate() 方法中，调用 replaceCustomFont() 方法。

最后展示的效果以下。

使用这种方式，优势是，不须要修改 XML 布局，不须要重写多个控件。只须要在 Inflater View 的以后，调用一下 replaceCustomFont() 方法便可。

缺点也很是的明显，每一个页面都须要修改，有动态加载 View 的地方可能会被遗漏，改动相比较以前的方案，稍微少一点。而且违背了组件的设计原则，实现方式也略显粗暴。同时它每次都会递归遍历 ViewTree，性能上多少都会有点影响。

4、小结

本文介绍的几个办法，在实际开发中，可能也用不上。不过不影响咱们了解这样的方法。

下期预告

到如今为止，介绍的替换字体的方案，其实并不够优雅。从下期开始，就会开始介绍一些更优雅的方式，在现有项目上，全局的替换字体的一些方案。期待你的持续关注。