由以上2.1~2.6對原始碼的分析，可以得到以下結論：
3.1 activity、window和view的依賴關係：
3.2 setcontentview()執行的序列圖：
activity展示的其實是phonewindow上的內容。那麼其實 setcontentview 實際上是呼叫的 phonwwindow的setcontentview。可以看出window是做為中介者連線了activity和view。
3.3.activity的檢視框架結構（
3.4 解釋一下decorview的布局資源的載入邏輯，features變數是怎麼來的：
再觀察generatelaout()的實現如下：
protected viewgroup generatelayout(decorview decor) else if ((features & ((1 << feature_left_icon) | (1 << feature_right_icon))) != 0) else
removefeature(feature_action_bar);
} ...
mdecor.startchanging();
mdecor.onresourcesloaded(mlayoutinflater, layoutresource);
viewgroup contentparent = (viewgroup)findviewbyid(id_android_content);
...}12
3456
78910
1112
1314
1516
1718
1920
2122
2324
那麼，mlocalfeatures的值是怎麼來的？直接搜尋mlocalfeatures被賦值的地方，發現是通過getdefaultfeatures()方法拿到的，但是這個只是拿到預設的features值，這是不夠的。反推，上面都是位操作，我們要搜尋mfeatures和mlocalfeaures的位操作地方了，原始碼裡面用乙個int值代表一堆標記位的事情也不少了。果然，發現，是在phonwwindow的requestfeature()中設定的標記位：
public boolean requestfeature(int featureid)
final int features = getfeatures();
final int newfeatures = features | (1 << featureid);
if ((newfeatures & (1 << feature_custom_title)) != 0 &&
(newfeatures & ~custom_title_compatible_features) != 0)
...//window的requestfeature()會將featureid通過按位或運算記錄到mfeatures變數中
return super.requestfeature(featureid);}1
2345
6789
1011
1213
1415
這樣也能解釋的通了，為什麼在activity中使用requestfeature()要在setcontentview()前呼叫了，以為這個值是給activity的decorview選擇載入那種樣式的布局檔案用的。如果在setcontentview之後呼叫，這個時候phonewindow::generatelayout(decorview)已經執行完成了，並不會生效。
spring原始碼分析 spring原始碼分析
1.spring 執行原理 spring 啟動時讀取應用程式提供的 bean 配置資訊，並在 spring 容器中生成乙份相應的 bean 配置登錄檔，然後根據這張登錄檔例項化 bean，裝配好 bean 之間的依賴關係，為上 層應用提供準備就緒的執行環境。二 spring 原始碼分析 1.1spr...
思科VPP原始碼分析（dpo機制原始碼分析）
vpp的dpo機制跟路由緊密結合在一起。路由表查詢 ip4 lookup 的最後結果是乙個load balance t結構。該結構可以看做是乙個hash表，裡面包含了很多dpo，指向為下一步處理動作。每個dpo都是新增路由時的乙個path的結果。dpo標準型別有 dpo drop,dpo ip nu...
redux原始碼分析（三） 原始碼部分
下面是每個部分的一些解讀 createstore apicreatestore reducer,initialstate enhancer 曾經非常好奇這個函式的第二個引數到底是initialstate還是enhancer，因為見過兩種寫法都有的，以為是版本問題。看了原始碼才發現，都可以的。如果你不...