可以看到，它一共需要的类非常的少，算是一个比较精简的库了，并且它并没有重写 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 的时候，都需要用到它，相信下面这段代码，应该大家都不陌生。
