源碼分析圖

⑴ Android socket源碼解析(三)socket的connect源碼解析

上一篇文章著重的聊了socket服務端的bind，listen，accpet的邏輯。本文來著重聊聊connect都做了什麼？

如果遇到什麼問題，可以來本文 https://www.jianshu.com/p/da6089fdcfe1 下討論

當服務端一切都准備好了。客戶端就會嘗試的通過 connect 系統調用，嘗試的和服務端建立遠程連接。

首先校驗當前socket中是否有正確的目標地址。然後獲取IP地址和埠調用 connectToAddress 。

在這個方法中，能看到有一個 NetHooks 跟蹤socket的調用，也能看到 BlockGuard 跟蹤了socket的connect調用。因此可以hook這兩個地方跟蹤socket，不過很少用就是了。

核心方法是 socketConnect 方法，這個方法就是調用 IoBridge.connect 方法。同理也會調用到jni中。

能看到也是調用了 connect 系統調用。

文件：/ net / ipv4 / af_inet.c

在這個方法中做的事情如下：

注意 sk_prot 所指向的方法是， tcp_prot 中 connect 所指向的方法，也就是指 tcp_v4_connect .

文件：/ net / ipv4 / tcp_ipv4.c

本質上核心任務有三件:

想要能夠理解下文內容，先要明白什麼是路由表。

路由表分為兩大類：

每個路由器都有一個路由表(RIB)和轉發表 (fib表)，路由表用於決策路由，轉發表決策轉發分組。下文會接觸到這兩種表。

這兩個表有什麼區別呢？

網上雖然給了如下的定義：

但實際上在Linux 3.8.1中並沒有明確的區分。整個路由相關的邏輯都是使用了fib轉發表承擔的。

先來看看幾個和FIB轉發表相關的核心結構體：

熟悉Linux命令朋友一定就能認出這裡面大部分的欄位都可以通過route命令查找到。

命令執行結果如下：

在這route命令結果的欄位實際上都對應上了結構體中的欄位含義：

知道路由表的的內容後。再來FIB轉發表的內容。實際上從下面的源碼其實可以得知，路由表的獲取，實際上是先從fib轉發表的路由字典樹獲取到後在同感加工獲得路由表對象。

轉發表的內容就更加簡單

還記得在之前總結的ip地址的結構嗎？

需要進行一次tcp的通信，意味著需要把ip報文准備好。因此需要決定源ip地址和目標IP地址。目標ip地址在之前通過netd查詢到了，此時需要得到本地發送的源ip地址。

然而在實際情況下，往往是面對如下這么情況：公網一個對外的ip地址，而內網會被映射成多個不同內網的ip地址。而這個過程就是通過DDNS動態的在內存中進行更新。

因此 ip_route_connect 實際上就是選擇一個緩存好的，通過DDNS設置好的內網ip地址並找到作為結果返回，將會在之後發送包的時候填入這些存在結果信息。而查詢內網ip地址的過程，可以成為RTNetLink。

在Linux中有一個常用的命令 ifconfig 也可以實現類似增加一個內網ip地址的功能：

比如說為網卡eth0增加一個IPV6的地址。而這個過程實際上就是調用了devinet內核模塊設定好的添加新ip地址方式，並在回調中把該ip地址刷新到內存中。

注意 devinet 和 RTNetLink 嚴格來說不是一個存在同一個模塊。雖然都是使用 rtnl_register 注冊方法到rtnl模塊中：

文件：/ net / ipv4 / devinet.c

文件：/ net / ipv4 / route.c

實際上整個route模塊，是跟著ipv4 內核模塊一起初始化好的。能看到其中就根據不同的rtnl操作符號注冊了對應不同的方法。

整個DDNS的工作流程大體如下：

當然，在tcp三次握手執行之前，需要得到當前的源地址，那麼就需要通過rtnl進行查詢內存中分配的ip。

文件：/ include / net / route.h

這個方法核心就是 __ip_route_output_key .當目的地址或者源地址有其一為空，則會調用 __ip_route_output_key 填充ip地址。目的地址為空說明可能是在回環鏈路中通信，如果源地址為空，那個說明可能往目的地址通信需要填充本地被DDNS分配好的內網地址。

在這個方法中核心還是調用了 flowi4_init_output 進行flowi4結構體的初始化。

文件：/ include / net / flow.h

能看到這個過程把數據中的源地址，目的地址，源地址埠和目的地址埠，協議類型等數據給記錄下來，之後內網ip地址的查詢與更新就會頻繁的和這個結構體進行交互。

能看到實際上 flowi4 是一個用於承載數據的臨時結構體，包含了本次路由操作需要的數據。

執行的事務如下：

想要弄清楚ip路由表的核心邏輯，必須明白路由表的幾個核心的數據結構。當然網上搜索到的和本文很可能大為不同。本文是基於LInux 內核3.1.8.之後的設計幾乎都沿用這一套。

而內核將路由表進行大規模的重新設計，很大一部分的原因是網路環境日益龐大且復雜。需要全新的方式進行優化管理系統中的路由表。

下面是fib_table 路由表所涉及的數據結構：

依次從最外層的結構體介紹：

能看到路由表的存儲實際上通過字典樹的數據結構壓縮實現的。但是和常見的字典樹有點區別，這種特殊的字典樹稱為LC-trie 快速路由查找演算法。

這一篇文章對於快速路由查找演算法的理解寫的很不錯: https://blog.csdn.net/dog250/article/details/6596046

首先理解字典樹：字典樹簡單的來說，就是把一串數據化為二進制格式，根據左0，右1的方式構成的。

如圖下所示：

這個過程用圖來展示，就是沿著字典樹路徑不斷向下讀，比如依次讀取abd節點就能得到00這個數字。依次讀取abeh就能得到010這個數字。

說到底這種方式只是存儲數據的一種方式。而使用數的好處就能很輕易的找到公共前綴，在字典樹中找到公共最大子樹，也就找到了公共前綴。

而LC-trie 則是在這之上做了壓縮優化處理，想要理解這個演算法，必須要明白在 tnode 中存在兩個十分核心的數據：

這負責什麼事情呢？下面就簡單說說整個lc-trie的演算法就能明白了。

當然先來看看方法 __ip_dev_find 是如何查找

文件：/ net / ipv4 / fib_trie.c

整個方法就是通過 tkey_extract_bits 生成tnode中對應的葉子節點所在index，從而通過 tnode_get_child_rcu 拿到tnode節點中index所對應的數組中獲取葉下一級別的tnode或者葉子結點。

其中查找index最為核心方法如上，這個過程，先通過key左移動pos個位，再向右邊移動（32 - bits）演算法找到對應index。

在這里能對路由壓縮演算法有一定的理解即可，本文重點不在這里。當從路由樹中找到了結果就返回 fib_result 結構體。

查詢的結果最為核心的就是 fib_table 路由表，存儲了真正的路由轉發信息

文件：/ net / ipv4 / route.c

這個方法做的事情很簡單，本質上就是想要找到這個路由的下一跳是哪裡？

在這裡面有一個核心的結構體名為 fib_nh_exception 。這個是指fib表中去往目的地址情況下最理想的下一跳的地址。

而這個結構體在上一個方法通過 find_exception 獲得.遍歷從 fib_result 獲取到 fib_nh 結構體中的 nh_exceptions 鏈表。從這鏈表中找到一模一樣的目的地址並返回得到的。

文件：/ net / ipv4 / tcp_output.c

⑵ Android TV 焦點原理源碼解析

相信很多剛接觸AndroidTV開發的開發者，都會被各種焦點問題給折磨的不行。不管是學技術還是學習其他知識，都要學習和理解其中原理，碰到問題我們才能得心應手。下面就來探一探Android的焦點分發的過程。

Android焦點事件的分發是從ViewRootImpl的processKeyEvent開始的，源碼如下：

源碼比較長，下面我就慢慢來講解一下具體的每一個細節。

dispatchKeyEvent方法返回true代表焦點事件被消費了。

ViewGroup的dispatchKeyEvent()方法的源碼如下：

（2）ViewGroup的dispatchKeyEvent執行流程

（3）下面再來瞧瞧view的dispatchKeyEvent方法的具體的執行過程

驚奇的發現執行了onKeyListener中的onKey方法，如果onKey方法返回true，那麼dispatchKeyEvent方法也會返回true

可以得出結論：如果想要修改ViewGroup焦點事件的分發，可以這么干：

注意：實際開發中，理論上所有焦點問題都可以通過給dispatchKeyEvent方法增加監聽來來攔截來控制。

（1）dispatchKeyEvent方法返回false後，先得到按鍵的方向direction值，這個值是一個int類型參數。這個direction值是後面來進行焦點查找的。

（2）接著會調用DecorView的findFocus()方法一層一層往下查找已經獲取焦點的子View。
ViewGroup的findFocus方法如下：

View的findFocus方法

說明：判斷view是否獲取焦點的isFocused()方法， (mPrivateFlags & PFLAG_FOCUSED) != 0 和view 的isFocused()方法是一致的。

其中isFocused()方法的作用是判斷view是否已經獲取焦點，如果viewGroup已經獲取到了焦點，那麼返回本身即可，否則通過mFocused的findFocus()方法來找焦點。mFocused其實就是ViewGroup中獲取焦點的子view，如果mView不是ViewGourp的話，findFocus其實就是判斷本身是否已經獲取焦點，如果已經獲取焦點了，返回本身。

（3）回到processKeyEvent方法中，如果findFocus方法返回的mFocused不為空，說明找到了當前獲取焦點的view（mFocused），接著focusSearch會把direction（遙控器按鍵按下的方向）作為參數，找到特定方向下一個將要獲取焦點的view，最後如果該view不為空，那麼就讓該view獲取焦點。

（4）focusSearch方法的具體實現。

focusSearch方法的源碼如下：

可以看出focusSearch其實是一層一層地網上調用父View的focusSearch方法，直到當前view是根布局（isRootNamespace()方法），通過注釋可以知道focusSearch最終會調用DecorView的focusSearch方法。而DecorView的focusSearch方法找到的焦點view是通過FocusFinder來找到的。

（5）FocusFinder是什麼？

它其實是一個實現 根據給定的按鍵方向，通過當前的獲取焦點的View，查找下一個獲取焦點的view這樣演算法的類。焦點沒有被攔截的情況下，Android框架焦點的查找最終都是通過FocusFinder類來實現的。

（6）FocusFinder是如何通過findNextFocus方法尋找焦點的。

下面就來看看FocusFinder類是如何通過findNextFocus來找焦點的。一層一層往下看，後面會執行findNextUserSpecifiedFocus()方法，這個方法會執行focused(即當前獲取焦點的View)的findUserSetNextFocus方法，如果該方法返回的View不為空，且isFocusable = true && isInTouchMode() = true的話，FocusFinder找到的焦點就是findNextUserSpecifiedFocus()返回的View。

（7）findNextFocus會優先根據XML里設置的下一個將獲取焦點的View ID值來尋找將要獲取焦點的View。

看看View的findUserSetNextFocus方法內部都幹了些什麼，OMG不就是通過我們xml布局裡設置的nextFocusLeft，nextFocusRight的viewId來找焦點嗎，如果按下Left鍵，那麼便會通過nextFocusLeft值里的View Id值去找下一個獲取焦點的View。

可以得出以下結論：

1. 如果一個View在XML布局中設置了focusable = true && isInTouchMode = true，那麼這個View會優先獲取焦點。

2. 通過設置nextFocusLeft，nextFocusRight，nextFocusUp，nextFocusDown值可以控制View的下一個焦點。

Android焦點的原理實現就這些。總結一下：

為了方便同志們學習，我這做了張導圖，方便大家理解~

⑶ Hermes源碼分析（二）——解析位元組碼

前面一節 講到位元組碼序列化為二進制是有固定的格式的，這里我們分析一下源碼裡面是怎麼處理的

這里可以看到首先寫入的是魔數，他的值為

對應的二進制見下圖，注意是小端位元組序

第二項是位元組碼的版本，筆者的版本是74，也即 上圖中的4a00 0000
第三項是源碼的hash，這里採用的是SHA1演算法，生成的哈希值是160位，因此佔用了20個位元組

第四項是文件長度，這個欄位是32位的，也就是下圖中的為0aa030，轉換成十進制就是696368，實際文件大小也是這么多

後面的欄位類似，就不一一分析了，頭部所有欄位的類型都可以在 BytecodeFileHeader.h 中看到，Hermes按照既定的內存布局把欄位寫入後再序列化，就得到了我們看到的位元組碼文件。

這里寫入的數據很多，以函數頭的寫入為例，我們調用了visitFunctionHeader方法，並通過byteCodeMole拿到函數的簽名，將其寫入函數表（存疑，在實際的文件中並沒有看到這一部分）。注意這些數據必須按順序寫入，因為讀出的時候也是按對應順序來的。

我們知道react-native 在載入位元組碼的時候需要調用hermes的prepareJavaScript方法， 那這個方法做了些什麼事呢？

這里做了兩件事情：
1. 判斷是否是位元組碼，如果是則調用createBCProviderFromBuffer，否則調用createBCProviderFromSrc，我們這里只關注createBCProviderFromBuffer
2.通過BCProviderFromBuffer的構造方法得到文件頭和函數頭的信息（populateFromBuffer方法），下面是這個方法的實現。

BytecodeFileFields的populateFromBuffer方法也是一個模版方法，注意這里調用populateFromBuffer方法的是一個 ConstBytecodeFileFields對象，他代表的是不可變的位元組碼欄位。

細心的讀者會發現這里也有visitFunctionHeaders方法， 這里主要為了復用visitBytecodeSegmentsInOrder的邏輯，把populator當作一個visitor來按順序讀取buffer的內容，並提前載入到BytecodeFileFields裡面，以減少後面執行位元組碼時解析的時間。

Hermes引擎在讀取了位元組碼之後會通過解析BytecodeFileHeader這個結構體中的欄位來獲取一些關鍵信息，例如bundle是否是位元組碼格式，是否包含了函數，位元組碼的版本是否匹配等。注意這里我們只是解析了頭部，沒有解析整個位元組碼，後面執行位元組碼時才會解析剩餘的部分。

evaluatePreparedJavaScript這個方法，主要是調用了HermesRuntime的 runBytecode方法，這里hermesPrep時上一步解析頭部時獲取的BCProviderFromBuffer實例。

runBytecode這個方法比較長，主要做了幾件事情：

這里說明一下，Domain是用於垃圾回收的運行時模塊的代理， Domain被創建時是空的，並跟隨著運行時模塊進行傳播， 在運行時模塊的整個生命周期內都一直存在。在某個Domain下創建的所有函數都會保持著對這個Domain的強引用。當Domain被回收的時候，這個Domain下的所有函數都不能使用。

未完待續。。。