androidvlc源碼分析

㈠ Android源碼解析RPC系列(一)---Binder原理

看了幾天的Binder，決定有必要寫一篇博客，記錄一下學習成果，Binder是Android中比較綜合的一塊知識了，目前的理解只限於JAVA層。首先Binder是幹嘛用的？不用說，跨進程通信全靠它，操作系統的不同進程之間，數據不共享，對於每個進程來說，它都天真地以為自己獨享了整個系統，完全不知道其他進程的存在，進程之間需要通信需要某種系統機制才能完成，在Android整個系統架構中，採用了大量的C/S架構的思想，所以Binder的作用就顯得非常重要了，但是這種機制為什麼是Binder呢？在linux中的RPC方式有管道，消息隊列，共享內存等，消息隊列和管道採用存儲-轉發方式，即數據先從發送方緩存區拷貝到內核開辟的緩存區中，然後再從內核緩存區拷貝到接收方緩存區，這樣就有兩次拷貝過程。共享內存不需要拷貝，但控制復雜，難以使用。Binder是個折中的方案，只需要拷貝一次就行了。其次Binder的安全性比較好，好在哪裡，在下還不是很清楚，基於安全性和傳輸的效率考慮，選擇了Binder。Binder的英文意思是粘結劑，Binder對象是一個可以跨進程引用的對象，它的實體位於一個進程中，這個進程一般是Server端，該對象提供了一套方法用以實現對服務的請求，而它的引用卻遍布於系統的各個進程（Client端）之中，這樣Client通過Binder的引用訪問Server，所以說，Binder就像膠水一樣，把系統各個進程粘結在一起了，廢話確實有點多。

為了從而保障了系統的安全和穩定，整個系統被劃分成內核空間和用戶空間
內核空間：獨立於普通的應用程序，可以訪問受保護的內存空間，有訪問底層硬體設備的所有許可權。
用戶空間：相對與內核空間，上層運用程序所運行的空間就是用戶空間，用戶空間訪問內核空間的唯一方式就是系統調用。一個4G的虛擬地址空間，其中3G是用戶空間，剩餘的1G是內核空間。如果一個用戶空間想與另外一個用戶空間進行通信，就需要內核模塊支持，這個運行在內核空間的，負責各個用戶進程通過Binder通信的內核模塊叫做Binder驅動，雖然叫做Binder驅動，但是和硬體並沒有什麼關系，只是實現方式和設備驅動程序是一樣的，提供了一些標准文件操作。

在寫AIDL的時候，一般情況下，我們有兩個進程，一個作為Server端提供某種服務，然後另外一個進程作為Client端,連接Server端之後，就 可以使用Server裡面定義的服務。這種思想是一種典型的C/S的思想。值得注意的是Android系統中的Binder自身也是C/S的架構，也有Server端與Client端。一個大的C/S架構中，也有一個小的C/S架構。

先籠統的說一下，在整個Binder框架中，由系列組件組成，分別是Client、Server、ServiceManager和Binder驅動程序，其中Client、Server和ServiceManager運行在用戶空間，Binder驅動程序運行內核空間。運行在用戶空間中的Client、Server和ServiceManager，是在三個不同進程中的，Server進程中中定義了服務提供給Client進程使用，並且Server中有一個Binder實體，但是Server中定義的服務並不能直接被Client使用，它需要向ServiceManager注冊，然後Client要用服務的時候，直接向ServiceManager要，ServiceManager返回一個Binder的替身（引用）給Client，這樣Client就可以調用Server中的服務了。

場景 ：進程A要調用進程B裡面的一個draw方法處理圖片。

分析 ：在這種場景下，進程A作為Client端，進程B做為Server端，但是A/B不在同一個進程中，怎麼來調用B進程的draw方法呢，首先進程B作為Server端創建了Binder實體，為其取一個字元形式，可讀易記的名字，並將這個Binder連同名字以數據包的形式通過Binder驅動發送給ServiceManager，也就是向ServiceManager注冊的過程，告訴ServiceManager，我是進程B，擁有圖像處理的功能，ServiceManager從數據包中取出名字和引用以一個注冊表的形式保留了Server進程的注冊信息。為什麼是以數據包的形式呢，因為這是兩個進程，直接傳遞對象是不行滴，只能是一些描述信息。現在Client端進程A聯系ServiceManager，說現在我需要進程B中圖像處理的功能，ServiceManager從注冊表中查到了這個Binder實體，但是呢，它並不是直接把這個Binder實體直接給Client,而是給了一個Binder實體的代理，或者說是引用，Client通過Binder的引用訪問Server。分析到現在，有個關鍵的問題需要說一下，ServiceManager是一個進程，Server是另一個進程，Server向ServiceManager注冊Binder必然會涉及進程間通信。當前實現的是進程間通信卻又要用到進程間通信，這就好象蛋可以孵出雞前提卻是要找只雞來孵蛋，確實是這樣的，ServiceManager中預先有了一個自己的Binder對象（實體），就是那隻雞，然後Server有個Binder對象的引用，就是那個蛋，Server需要通過這個Binder的引用來實現Binder的注冊。雞就一隻，蛋有很多，ServiceManager進程的Binder對象（實體）僅有一個，其他進程所擁有的全部都是它的代理。同樣一個Server端Binder實體也應該只有一個，對應所有Client端全部都是它的代理。

我們再次理解一下Binder是什麼？在Binder通信模型的四個角色裡面；他們的代表都是「Binder」，一個Binder對象就代表了所有，包括了Server，Client,ServiceManager,這樣，對於Binder通信的使用者而言，不用關心實現的細節。對Server來說，Binder指的是Binder實體，或者說是本地對象，對於Client來說，Binder指的是Binder代理對象，也就是Binder的引用。對於Binder驅動而言，在Binder對象進行跨進程傳遞的時候，Binder驅動會自動完成這兩種類型的轉換。

簡單的總結一下，通過上面一大段的分析，一個Server在使用的時候需要經歷三個階段

1、定義一個AIDL文件
Game.aidl

GameManager .aidl

2、定義遠端服務Service
在遠程服務中的onBind方法，實現AIDL介面的具體方法，並且返回Binder對象

3、本地創建連接對象

以上就是一個遠端服務的一般套路，如果是在兩個進程中，就可以進程通信了，現在我們分析一下，這個通信的流程。重點是GameManager這個編譯生成的類。

從類的關系來看，首先介面GameManager 繼承 IInterface ，IInterface是一個介面，在GameManager內部有一個內部類Stub，Stub繼承了Binder，（Binder實現了IBinder），並且實現了GameManager介面，在Stub中還有一個內部類Proxy，Proxy也實現了GameManager介面，一個整體的結構是這樣的

現在的問題是，Stub是什麼？Proxy又是什麼？在上面說了在Binder通信模型的四個角色裡面；他們的代表都是「Binder」，一個Binder對象就代表了所有，包括了Server，Clinet，ServiceManager，為了兩個進程的通信，系統給予的內核支持是Binder,在抽象一點的說,Binder是系統開辟的一塊內存空間，兩個進程往這塊空間裡面讀寫數據就行了，Stub從Binder中讀數據，Proxy向Binder中寫數據,達到進程間通信的目的。首先我們分析Stub。

Stub 類繼承了Binder ，說明了Stub有了跨進程傳輸的能力，實現了GameManager介面，說明它有了根據游戲ID查詢一個游戲的能力。我們在bind一個Service之後，在onServiceConnecttion的回調裡面，就是通過asInterface方法拿到一個遠程的service的。

asInterface調用queryLocalInterface。

mDescriptor，mOwner其實是Binder的成員變數，Stub繼承了Binder，在構造函數的時候，對著兩個變數賦的值。

如果客戶端和服務端是在一個進程中，那麼其實queryLocalInterface獲取的就是Stub對象，如果不在一個進程queryLocalInterface查詢的對象肯定為null，因為不同進程有不同虛擬機，肯定查不到mOwner對象的，所以這時候其實是返回的Proxy對象了。拿到Stub對象後，通常在onServiceConnected中，就把這個對象轉換成我們多定義AIDL介面。

比如我們這里會轉換成GameManager，有了GameManager對象，就可以調用後querryGameById方法了。如果是一個進程，那直接調用的是自己的querryGameById方法，如果不是一個進程，那調用了就是代理的querryGameById方法了。

看到其中關鍵的一行是

mRemote就是一個IBinder對象，相對於Stub，Proxy 是組合關系（HAS-A），內部有一個IBinder對象mRemote，Stub是繼承關系(IS-A)，直接實現了IBinder介面。

transact是個native方法，最終還會回掉JAVA層的onTransact方法。

onTransact根據調用號（每個AIDL函數都有一個編號，在跨進程的時候，不會傳遞函數，而是傳遞編號指明調用哪個函數）調用相關函數；在這個例子裡面，調用了Binder本地對象的querryGameById方法；這個方法將結果返回給驅動，驅動喚醒掛起的Client進程裡面的線程並將結果返回。於是一次跨進程調用就完成了。

***Please accept mybest wishes for your happiness and success ! ***

㈡ 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源碼解析Window系列第（一）篇---Window的基本認識和Activity的載入流程

您可能聽說過View ,ViewManager,Window,PhoneWindow,WindowManager,WindowManagerService,可是你知道這幾個類是什麼關系，幹嘛用的。概括的來說，View是放在Window中的，Window是一個抽象類，它的具體實現是PhoneWindow，PhoneWindow還有個內部類DecorView，WindowManager是一個interface，繼承自ViewManager，它是外界訪問Window的入口，，提供了add/remove/updata的方法操作View，WindowManager與WindowManagerSerice是個跨進程的過程，WindowManagerService的職責是對系統中的所有窗口進行管理。如果您不太清楚，建議往下看，否則就不要看了。

Android系統的Window有很多種，大體上來說，Framework定義了三種窗口類型；

這就是Framework定義了三種窗口類型，這三種類型定義在WindowManager的內部類LayoutParams中，WindowManager講這三種類型 進行了細化，把每一種類型都用一個int常量來表示，這些常量代表窗口所在的層，WindowManagerService在進行窗口疊加的時候，會按照常量的大小分配不同的層，常量值越大，代表位置越靠上面， 所以我們可以猜想一下，應用程序Window的層值常量要小於子Window的層值常量，子Window的層值常量要小於系統Window的層值常量。 Window的層級關系如下所示。

上面說了Window分為三種，用Window的type區分，在搞清楚Window的創建之前，我們需要知道怎麼去描述一個Window，我們就把Window當做一個實體類，給我的感覺，它必須要下面幾個欄位。

實際上WindowManager.LayoutParams對Window有很詳細的定義。

提取幾個重要的參數

Window是一個是一個抽象的概念，千萬不要認為我們所看到的就是Window,我們平時所看到的是視圖，每一個Window都對應著一個View，View和Window通過ViewRootImpl來建立聯系。有了View，Window的存在意義在哪裡呢，因為View不能單獨存在，它必須依附著Window，所以有視圖的地方就有Window,比如Activity,一個Dialog,一個PopWindow,一個菜單，一個Toast等等。

通過上面我們知道視圖和Window的關系，那麼有一個問題，是先有視圖，還是先有Window。這個答案只有在源碼中找了。應用程序的入口類是ActivityThread，在ActivityThread中有performLaunchActivity來啟動Activity，這個performLaunchActivity方法內部會創建一個Activity。

如果activity不為null,就會調用attach,在attach方法中通過PolicyManager創建了Window對象，並且給Window設置了回調介面。

PolicyManager的實現類是Policy

這樣Window就創建出來了， 所以先有Window，後有視圖，視圖依賴Window存在 ，再說一說視圖（Activity）為Window設置的回調介面。

Activity實現了這個回調介面，當Window的狀態發生變化的時候，就會回調Activity中實現的這些介面，有些回調介面我們還是熟悉的，dispatchTouchEvent，onAttachedToWindow，onDetachedFromWindow等。

下面分析view是如何附屬到window上的，通過上面可以看到，在attach之後就要執行callActivityOnCreate，在onCreate中我們會調用setContentView方法。

getWindow獲取了Window對象，Window的具體實現類是PhoneWindow,所以要看PhoneWindow的setContentView方法。

這里涉及到一個mContentParent變數，他是一個DecorView的一部分，DecorView是PhoneWindow的一個內部類，我先介紹一下關於DecorView的知識。

DecorView是Activity的頂級VIew，DecorView繼承自FrameLayout,在DecorView中有上下兩個部分，上面是標題欄，下面是內容欄，我們通過PhoneWindow的setContentView所設置的布局文件是加到內容欄（mContentParent）裡面的，View層的事件都是先經過DecorView在傳遞給我們的View的。

OK在回到setContentView的源碼分析，我們可以得到Activity的Window創建需要三步。

- 1、 如果沒有DecorView，在installDecor中創建DecorView。

- 2、將View添加到decorview中的mContentParent中。

- 3、回調Activity的onContentChanged介面。

先看看第一步，installDecor的源碼

installDecor中調用了generateDecor，繼續看

直接給new一個DecorView，有了DecorView之後，就可以載入具體的布局文件到DecorView中了，具體的布局文件和系統和主題有關系。

在看第二步，將View添加到decorview中的mContentParent中。

直接將Activity視圖加到DecorView的mContentParent中，最後一步，回調Activity的onContentChanged介面。在Activity中尋找onContentChanged方法，它是個空實現，我們可以在子Activity中處理。

到此DecorView被創建完畢，我們一開始從Thread中的handleLaunchActivity方法開始分析，首先載入Activity的位元組碼文件，利用反射的方式創建一個Activity對象，調用Activity對象的attach方法，在attach方法中，創建系統需要的Window並為設置回調，這個回調定義在Window之中，由Activity實現，當Window的狀態發生變化的時候，就會回調Activity實現的這些回調方法。調用attach方法之後，Window被創建完成，這時候需要關聯我們的視圖，在handleLaunchActivity中的attach執行之後就要執行handleLaunchActivity中的callActivityOnCreate，在onCreate中我們會調用setContentView方法。通過setContentView，創建了Activity的頂級View---DecorView,DecorView的內容欄（mContentParent）用來顯示我們的布局。 這個是我們上面分析得到了一個大致流程，走到這里，這只是添加的過程，還要有一個顯示的過程，顯示的過程就要調用handleLaunchActivity中的handleResumeActivity方法了。最後會調用makeVisible方法。

這裡面首先拿到WindowManager對象，用tWindowManager 的父介面ViewManager接收，ViewManager可以
最後調用 mDecor.setVisibility(View.VISIBLE)設置mDecor可見。到此，我們終於明白一個Activity是怎麼顯示在我們的面前了。
參考鏈接：
http://blog.csdn.net/feiclear_up/article/details/49201357

㈣ 編譯android-vlc支持rtsp,是不是需要添加live555誰有詳細的步驟呢給說下，最好有編譯好的源碼

vlc-android是直接支持rtsp的，可以播放rtsp。http，mms網路流 我編譯好了一份源代碼，你可以下載看看 http://download.csdn.net/detail/wng2010/4971056

㈤ 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焦點的原理實現就這些。總結一下：

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

㈥ Android RecyclerView的布局管理器 GridLayoutManager源碼分析<三>

Android RecyclerView繪制頁面的源碼分析<一>

Android RecyclerView布局管理器LinearLayoutManager源碼分析<二>

以上兩篇講述了RecycerView LinearLayoutManager 頁面繪制以及子條目的布局,LinearLayoutManager 是一個線性的管理器即是控制垂直以及水平展示 一個條目表示一行,然而顯示生活中有很多需求是一行展示多個子條目這個時候就用到了 GridLayoutManager 表格布局管理器 來實現這種需求
GridLayoutManager :繼承於LinearLayoutManager的網格狀布局管理器 默認一行展示一個

GridLayoutManager網格布局管理器 實現一行展示多個條目,本章解釋了GridLayoutManager的簡單源碼實現表格布局的大概調用,下一章展示復雜的表格布局即展示不顧地條目數的表格布局

㈦ vlc for android 源碼能不能在windows環境下編譯

1. 准備編譯環境

基本上按照這篇wiki的介紹就足夠了，為了順利完成編譯，建議首先保證相關的軟體或者依賴庫都已經下載好了，我再強調一下幾個重點注意事項。

（1） Android SDK：必須使用SDK Platform Android 5.0, API 21，因為VLC-for-android用到了Android 5.0 的一些API。

（2） 最好通過apt-get install 把下面這些依賴的軟體都安裝一遍，或更新到最新版

git,apache-ant (or ant), autoconf, automake, autopoint, cmake,
gawk (or nawk), gcc, g++, libtool, m4, patch, pkg-config, ragel,
subversion, unzip.

2. 下載源碼包

直接通過git下載VLC-for-android最新的源碼即可：

git clone git://git.videolan.org/vlc-ports/android.git

3. 編譯VLC源碼和VLC Android工程

（1） 配置編譯環境變數

具體參考wiki的介紹，你可以寫個shell腳本來執行，避免每次編譯都要配置，下面是我的環境變數，可以根據你的路徑修改：

#! /bin/sh

export ANDROID_SDK=/opt/android/sdk/

export ANDROID_NDK=/opt/android/android-ndk-r10/

export ANT_DIR=/opt/android/ant/

export PATH=$PATH:$ANDROID_SDK/platform-tools:$ANDROID_SDK/tools:$ANT_DIR

export ANDROID_ABI=armeabi-v7a

（2） 執行編譯

sh compile.sh

VLC不愧是使用這么廣泛的播放器，它的編譯腳本寫得非常強大和智能，直接通過執行compile.sh，它會自動check所有的依賴，並通過網路去下載缺失的庫。

首先，它會下載vlc的源碼，並存放在當前目錄下。然後去下載依賴的第三方庫文件。

當然，由於GFW的存在，有的時候下載會失敗，這個時候，就需要你手動去Google搜索它正在下載的依賴文件，手動下載好了之後放到 vlc/contrib/tarballs目錄下，然後再回到命令行重新執行 sh compile.sh

它依賴的全部第三方庫文件如圖所示：

（3） 編譯問題

編譯過程還算順利，只出現過一個大問題，如下：

google/protobuf/unittest.proto:853:21: Missing field number.

google/protobuf/unittest.proto:862:1: Reached end of input in message definition (missing '}').

make[3]: *** [unittest_proto_middleman] Error 1

網上也搜不到解決方案，我看了下GitHub上Protobuf的Readme，然後下載了最新的protobuf放到vlc/contrib
/tarballs/contrib-android-arm-linux-androideabi/protobuf目錄下，執行.
/configure --disable-shared，再編譯，沒想到就直接過了。

4. 載入VLC-For-Android的Java工程

編譯通過後，就可以直接在vlc-android/bin目錄下看到debug版的apk了，下面簡單說說在Eclipse中載入vlc-android的整個工程。

打開Eclipse，選擇Import，把vlc-for-android目錄下所有的工程到導入到Eclipse中（我去掉了TV工程），如圖所
示，有5個必須的工程，其中，VLC是主工程，其他四個都是Lib工程。沒有什麼意外的話，直接運行VLC工程，就可以在Android手機上看到VLC
播放器應用了！

㈧ Android-ViewPager源碼解析與性能優化

ViewPager高度設置為wrap_content或者具體的高度值無效，是因為ViewPager的onMeasure方法在度量寬高的時候，在方法體的最開始就直接調用了setMeasuredDimension()方法將自身的寬高度量，但是並沒有在其onMeasure()計算完其具體的子View的寬高之後，重新度量一次自身的寬高

從這里我們可以看到，ViewPager的寬高會受其父容器的寬高的限制，但是並不會因為自身子View的寬高而影響ViewPager的寬高。

看setMeasuredDimension的源碼調用可以看出，當父容器的高度確定時，ViewPager的寬高其實就是父容器的寬高，ViewPager就是在onMeasure方法一進來的時候就直接填充滿整個父容器的剩餘空間。在計算孩子節點之前，就已經計算好了ViewPager的寬高，在計算完孩子節點之後，並不會再去重新計算ViewPager的寬高。

自定義一個ViewPager，根據子View的寬高重新度量ViewPager的寬高。其實做法就是在自定義onMeasure的super.onMeasure(widthMeasureSpec, heightMeasureSpec);之前重新計算heightMeasureSpec，將原本ViewPager接收的父容器的限定的heightMeasureSpec替換成我們自定義的heightMeasureSpec。

但是這樣的做法，會有種問題，即在ViewPager的子View是採用LinearLayout作為根布局的時候，並且給LinearLayout設置了固定的高度值，那麼會出現ViewPager動態高度無效的問題
其實具體的做法，就是仿造measureChild的做法，自定義子View的heightMeasureSpec然後度量整個子View，其實子View的寬度也可以這樣做。

這里其實是源碼層做了限制，在setOffscreenPageLimit中設置了一個默認值，而這個默認值的大小為1

所以從這里可以看出，ViewPager的最小緩存的limit是1，而不能小於1，當小於1的時候就會被強制的設置為1。
而populate()函數就是用來處理ViewPager的緩存的。
populate()的生命周期是與Adapter的生命周期綁定的。
其實在setOffscreenPageLimit()的時候，調用的populate()，而populate()內部調用的

而pupulate(int newCurrentItem)方法在另一處調用的地方就是在setCurrentItem。
其實ViewPager緩存都是基於ItemInfo這個類來進行的，

看下ViewPager.addNewItem的源碼
其實ViewPager.addNewItem就是通過調用Adapter.instantiateItem來創建對應的View，並且將View保存到ItemInfo中的object屬性，並且判斷ViewPager緩存中是否已經有ItemInfo，如果沒有，則添加，如果有則做修改替換

從分析FragmentStatePagerAdapter來看，setUserVisibleHint方法會優先於Fragment的生命周期函數 執行。因為在FragmentStatePagerAdapter中提交事務，是在調用finishUpdate方法中進行的，只有提交事務的時候，才會去執行Fragment的生命周期。
FragmentStatePagerAdapter中的instantiateItem和destroyItem都實現了對fragment的事務的添加和刪除，而finishUpdate實現了事務的提交，所以在實現FragmentStatePagerAdapter的時候，並不需要重寫instantiateItem和destroyItem

㈨ 怎樣評價羅升陽的android系統源代碼分析

我幹了3年Android sdk開發，覺得到了瓶勁沒法更進一步，於是花了一年多點時間，大概摸到點門徑。根據前輩的經驗，Android底層完全入門需要兩年。 先說下我的入門過程： 第零步，下載源碼，我下的4.2的，框架層源碼10G，內核2G多，ctags給框架層建的標簽文件都有600M，當時讓我有點震撼，用的vim+ctags+cscope來閱讀，還算不錯，架構挺清晰的。 第一步，我找到了一本好書《Android的設計與實現 第一卷》它講了Android框架層的啟動，初始化，服務框架初始化，Binder，消息循環，PackageManagerService，ActivityManagerService。據作者說後面會出講UI子系統的第二卷，拭目以待。其實這本書看了幾十頁我就發現需要第二步的知識，否則看不下去，於是跳去第二步。 第二步，學習Linux系統編程，在看《Android的設計與實現》的時候我發現，框架層的Native部分，全是Linux編程。為了掌握這部分知識，我花了4個月學習了《Linux系統編程手冊》（TLPI）這本1000多頁的書，我以前是搞WIndows文件系統這塊的，所以C語言還比較熟，TLPI的習題很有意思，量也比較大，堅持下來還是收獲很多。 第三步，花了4個月學習了一些Linux內核的知識，看了LKD，PLKA看了一半多。越學越沒底，覺得不懂得越來越多，不過這個也正常，只有靠慢慢磨，估計以後要不斷的磨這塊。 第四步，回頭看Android源碼，這次一口氣看完了《Android的設計與實現 第一卷》，終於對框架層有了譜。同時真的數次把我看暈，前面看Linux內核源碼都沒這么暈，不斷在Java層和Native層之間跳有點磨腦漿。其中我又覺得Java的基礎沒有打太牢，回去補了一個月的《Core Java》第八版。但是這書沒有涉及UI子系統，於是又看了《Android內核剖析》 第五步，《Android內核剖析》（這本書實際上是講框架層的，作者也是個搞嵌入式的，所以他在寫框架層的時候文筆不太好，很羅嗦，不過還是有很多看點，到他後來寫做ROM，玩開發板時估計是說到了他的本行，一下子遛起來了看得出還是挺有水平的，這本書知識有點舊畢竟講的是2.3很多代碼已經過時，但是作者很多點子很有參考價值）這本書講UI子系統和按鍵/觸摸消息處理系統還是很有分量的，尤其13章View繪制那裡，結合源碼研究很有收獲。而後面他講編譯框架和ROM相關的東西都是挺寶貴的資料。 第六步，為了再補一下其他諸如電源管理模塊等子系統的知識看了，《深入理解android》系列，個人認為這個系列看起來有點不太舒服，不過作為補充印證還是比較有價值。 第七步，《Android系統源代碼情景分析》，羅升陽的源碼分析大作，比《Android的設計與實現》分析得更細致，但缺點是涉及到模塊比較少，選用的源碼也比《Android的設計與實現》更舊一點。看完書後需要去研究作者的博客，東西挺多的，一定讓你滿意。 第八步，買塊開發板自己玩。這步我還沒走到，原因是我覺得我還差點准備知識。可能要再幾個月，到時准備入塊6410或者樹莓派。 最後，由於我11年以前都是搞Windows這塊的，所以對Linux知識不是很了解，不得已看了這么些書，如果是一直做Linux的人，很多步驟估計可以省掉了。直接上源碼才是正道。 我本身做著移動GIS開發的工作，學框架層全是因為興趣，但招聘平台Android框架層開發人員還是蠻有競爭力的有不少定製ROM，智能電視的工作都處於人才難求狀態，畢竟有一定的門檻，現在各種ios培訓，讓奔著錢干開發的人紛紛湧入，而ios只能幹sdk開發的缺點就暴露出來了，一堆新手老手，菜鳥大牛全擠在SDK開發這塊，我覺得不太妙。 反觀Android這邊，雖然入門菜鳥沒有搞ios來錢，但是可持續性很好，從sdk-》框架》驅動》內核這樣幹下去。干著干著發現自己漸漸變成了Linux開發者/嵌入式開發者的人也不少，新人，老手，菜鳥大牛各居其位，層次性很好。 轉載