從源碼的角度說說Activity的setContentView的原理(二)

1.在PhoneWindow的setContentView裡我們看到了一個mLayoutInflater對象，我們還沒清楚它從哪來？

2.mLayoutInflater對象後來所調用的那些方法有沒有被重載？

3.mFactory，mFactory2， mPrivateFactory這三個對象是否不為空？如果系統預設給它設定了值，那麼後來生成的View是不是就是通過它們來設定的呢？

好，接下來就讓我們一起把這些問題解開：

1.

我們先來看看mLayoutInflater從哪來，我們推測它極有可能和我們一樣是使用這樣的方式得來的：

但，這僅僅是推測，我們要看到實際的代碼：

通過檢視源碼我們可以得知，在PhoneWindow的構造方法裡是LayoutInflater.from(context);的方式對mLayoutInflater對象進行了初始化，看來，它也是和我們一樣使用了同一個系統提供的LayoutInflater對象，那麼，系統提供的這個LayoutInflater對象是在哪被構造和添加進去的呢？這我們就需要去Context.getSystemService方法裡一探究竟了：

我們知道getSystemService其實調用的就是ContextImpl的方法，ContextImpl是Context的具體實作類，我們進入ContextImpl的getSystemService中一探究竟：

好，看來所有的服務都是通過SYSTEM_SERVICE_MAP取出來的，那麼我們看看這些服務什麼時候被添加進去的，在ContextImpl這個類中我們看到有個靜态方法：

看來所有的服務都是通過它加進去的，那什麼時候加進去的呢，我們在這個類當中可以看到一段很長的靜态代碼塊，在代碼塊中發現了它的身影：

噢，原來所有的工作都是它在幹啊！到這裡，我們第一個問題就清楚了。

2.mLayoutInflater對象後來所調用的那些方法有沒有被重載？其實這個問題我們直接進PhoneLayoutInflater中就可以知道答案：

噢，原來我們在上一篇文章當中分析的onCreateView方法是沒有被調用的，那看來父類中的這個方法的功能是不滿足的，那我們分析分析被複寫的這個方法：

我們可以看到這個方法内部在周遊一個字元串數組，這個字元串數組被定義在類裡：

在上一篇文章當中，我請大家在onCreateView中注意調用createView方法的第二個參數是"android.view."，這裡被重寫，看來是不滿足了，子類實作了更為強大的功能，支援了更多的包進行加載，它這個過程一直在嘗試去建立View,直到成功。好，我們第二個問題也解決完了。

3.mFactory，mFactory2， mPrivateFactory這三個對象是否不為空？看來這個問題我們就都知道了，PhoneLayoutInflater在構造的時候調用的是：

後來也沒有對它進行什麼設定，是以看來它們都是空，這裡這3個對象是開放給我們使用的，我們可以在View被加載的時候動态的修改它們的效果，這是個很強大的功能，比如動态修改皮膚什麼的，希望你們可以手動去實作一下，，謝謝。