全局替換字體，開源庫更方便?。。?/h1>
序
在 Android 下使用自定義字體已經是一個比較常見的需求了，最近也做了個比較深入的研究。
那么按照慣例我又要出個一篇有關 Android 修改字體相關的文章，但是寫下來發現內容還挺多的，所以我決定將它們拆分一下，分幾篇來詳細的講解。主要會是一些常用的替換字體的方案，最后還會介紹一些全局替換的方案，當然也會包含最新的 『Fonts in XML』的方案。
本篇是本系列的第九篇，之前已經發布的文章，有興趣可以先看看。
利用 AppCompatDelegate ，全局替換全局字體
一、前言
之前已經介紹了很多種，快速、低入侵的替換全局字體的方式。但是大多數情況下，我們需要實現的功能，一定已經有現成的實現方案。
本文就介紹一個 Github 上，比較火的全局替換字體的開源庫，差不多閱讀文檔加集成，一個小時全局替換字體不是夢。
這個開源替換字體庫就是 Calligraphy：
https://github.com/chrisjenx/Calligraphy
二、如何使用Calligraphy
既然是要接入開源庫來全局替換字體，先來看看它可以實現的效果。
接下來，我們開始一步步集成它。
2.1 添加 Gradle 依賴
Calligraphy 支持 Gradle 和 jar 的接入方式，這里使用 Gradle 來接入。
2.2 添加字體文檔到項目內
Calligraphy 支持的文件，可以放在 assets/ 目錄下，當然，我們可以再在其中建立一個文件夾來專門的存放字體文件。
2.3 初始化 Calligraphy
Calligraphy 使用 CalligraphyConfig 類，來進行初始化。它需要在 App 的入口，Application.onCreate() 中調用。
初始化主要是為了指定一些默認的配置，例如：默認字體、默認屬性值。
2.4 替換 Context
Calligraphy 對 Activity 的 Context，進行了一次包裝，需要使用它包裝的 Context，才可以達到替換字體的效果。所以還需要重寫 BaseActivity 中的 attachBaseContext() 方法，將其替換成 Calligraphy 為我們提供的 Context 的包裝類 CalligraphyContextWrapper。
2.5 使用 Calligraphy
到這里，就完成了 Calligraphy 的配置了，我們只需要在 TextView 中，通過屬性去使用它就好了，它配置的是我們字體文件，在 assets 目錄下的路徑。
2.6 查缺補漏
Calligraphy 使用起來還是很方便的，并且也支持更多的配置方式，例如： Style、Theme 都可以。
具體的使用細節，大家還是閱讀文檔了解更方便。
三、Calligraphy的原理
我們使用一個開源庫，當然要理解它的原理才能放心使用在商業項目上，接下來，我們就來分析一下 Calligraphy 的實現原理，看看和之前介紹的方式，有沒有什么區別。
先來看看 Calligraphy 的整體結構。
可以看到，它一共需要的類非常的少，算是一個比較精簡的庫了，并且它并沒有重寫 TextView ，所以應該是通過其它的方式來做到字體的替換的。
我們先來看看在 Application 需要調用的配置類， CalligraphyConfig 的源碼。
CalligraphyConfig 使用 Builder 的模式去初始化自己，可以看到這里只是設置了一些配置項，并沒有實際的業務邏輯。
CalligraphyConfig 初始化之后，就以靜態變量存儲起來，供其它地方使用，是一種單例的模式，但是并沒有考慮線程安全的問題。
既然 CalligraphyConfig 沒有實際的邏輯，那么接下去應該如何追蹤重要的代碼呢?
仔細觀察之前配置項里，需要重寫 Activity.attachBaseContext() 方法，這里會傳遞它重寫的一個 Context 的包裝類 CalligraphyContextWrapper，所以接下來我們再看看 CalligraphyContextWrapper 的源碼邏輯。
讀了 CalligraphyContextWrapper 源碼之后，你會發現它最重要的就是重寫了 getSystemService() 方法，當它是 LAYOUT_INFLATER_SERVICE 的時候，將自己的 CalligraphyLayoutInflater 類，返回回去。
那么，這里的 LAYOUT_INFLATER_SERVICE 到底是什么呢?
我想大家應該對 LayoutInflater 不陌生，從 layout-xml 加載 View 的時候，都需要用到它，相信下面這段代碼，應該大家都不陌生。
再仔細看看 LayoutInflater.from() 方法的源碼。
可以看到，這里獲得 LayoutInflater 對象的時候，用到的就是 LAYOUT_INFLATER_SERVICE。
所以 CalligraphyContextWrapper.getSystemService() 方法被重寫的目的，就是為了替換掉 LayoutInflater 對象，所以可以猜想，設置自定義字體的地方，就在自定義的 LayoutInflater 中。
繼續查看 CalligraphyLayoutInflater 的源碼，最終修改字體的邏輯，是在 CalligraphyContextWrappe 的 onViewCreatedInternal() 方法里面。
它會取出我們自定義屬性上設置的值，然后設置到初始化好的 TextView 上去。
四、Calligraphy 小結
到此就完成了 Calligraphy 的主要邏輯追蹤，幾個核心技術點：
Calligraphy 不需要重寫 TextView 之類的控件。
Calligraphy 重寫了 LayoutInflater 。
Calligraphy 在 attachBaseContext() 方法中，替換掉 ContextWrapper。
又通過自定義的 ContextWrapper 的 getSystemService() 方法，將 LayoutInflater 替換成庫里重寫的 CalligraphyLayoutInflater。
在 CalligraphyLayoutInflater 中，攔截我們需要的 TextView 和其子類，對它們的字體替換成我們設置的字體。
當然，實際上，開源庫之所以可以流傳的比較廣，它還做了更多的細節處理，但是我們一般分析開源庫，只需要關心主線邏輯就可以了。
整體來說 Calligraphy 沒有什么大毛病，可以放心使用，當然如果你用了一些同樣依賴此原理的第三方庫，可能會有沖突，這個就只能具體問題具體分析了。
【本文為51CTO專欄作者“張旸”的原創稿件，轉載請通過微信公眾號聯系作者獲取授權】
