本篇內(nèi)容主要目的在從整體上了解Android 龐大的系統(tǒng)架構(gòu)，根據(jù)系統(tǒng)架構(gòu)中的不同模塊和分層找到和梳理一條學習路徑，這樣能更好的切入到不同的模塊學習，直到最后全部打通。
成都創(chuàng)新互聯(lián)是一家朝氣蓬勃的網(wǎng)站建設公司。公司專注于為企業(yè)提供信息化建設解決方案。從事網(wǎng)站開發(fā)，網(wǎng)站制作，網(wǎng)站設計，網(wǎng)站模板，微信公眾號開發(fā)，軟件開發(fā)，微信平臺小程序開發(fā)，十余年建站對成都木托盤等多個方面，擁有多年的網(wǎng)站推廣經(jīng)驗。
接下來我們從兩個角度來分析
下面這張圖是Android官方提供的一張Android系統(tǒng)的預覽圖。
從上面這個圖中我們可以知道，Android系統(tǒng)一共有5部分組成，他們分別是
從縱向?qū)蛹壖軜?gòu)的角度來看，我們了解了android系統(tǒng)經(jīng)典5層結(jié)構(gòu)，他們?nèi)鐗敬u一般縱向堆疊在一起。但是其實每一層都包含了大量的子模塊子系統(tǒng)，并不能體現(xiàn)出Android整個系統(tǒng)的內(nèi)部架構(gòu)、運行機理，以及各個模塊之間是如何銜接與配合工作的。接下來借鑒了gityuan總結(jié)的一張系統(tǒng)進程圖，從系統(tǒng)進程的角度來看Android系統(tǒng)的工作原理。
Loader層： 引導kernel啟動
Kernel層： Android內(nèi)核空間
Native層： 進入用戶空間
Framework層： 給app層提供api以及系統(tǒng)服務,
App層： 各種各樣的應用程序apk
參考文獻：
在App運行過程中，我們的視圖層級可能會由于用戶的操作一直在發(fā)生改變，甚至可能會有一些出乎預料的變化，本文將會介紹 如何進行Android視圖實時分析，分析View的視圖層級及屬性變化。
首先，筆者先來一個簡單的Demo實例。我們使用Android Studio新建一個Empty Android工程，跑一下程序，界面如下圖所示：
接下來，我們要對視圖層級進行分析，但分析之前先給各位介紹兩個視圖分析工具。
1. Android SDK 中 tools 包下的 hierarchyviewer ，最終展現(xiàn)的視圖效果如下：
2. Android Studio 也有自帶的視圖分析工具 Layout Inspector（布局檢查器） ,打開方式如下圖所示：
可以看到Layout Inspector最右側(cè)的屬性欄可以查看 每一個View的所附帶的屬性及屬性值 。
從根視圖開始分析視圖層級，如下圖所示：
DecorView的第一個子View（LinearLayout）, 如下圖所示：
DecorView的第二個子View（View）,如下圖所示：
DecorView的第三個子View（View）,如下圖所示：
至此，DecorView的最外層View全部分析完畢。
接下來，分析DecorView的第一個子View(LinearLayout)，如下圖所示：
ViewStub的屬性信息，如下圖所示：
FrameLayout的屬性信息，如下圖所示：
接下來，繼續(xù)分析FrameLayout的子View，如下圖所示：
ContentFrameLayout的視圖屬性，如下圖所示：
ActionBarContainer的視圖屬性，如下圖所示：
不過，還有個問題需要提醒一下， 不同機型，不同系統(tǒng)主題設置 生成的視圖結(jié)構(gòu)可能會不一樣，舉兩個例子：
例一：筆者把使用的模擬器換成自己的手機（360N5 Android 6.0.1） ，運行后視圖布局如下:
可以看到 筆者的手機是沒有NavigationBar(底部導航欄)的 。
例二：筆者把Activity的主題"Theme.AppCompat.Light.DarkActionBar"換成無標題欄主題"Theme.AppCompat.Light.NoActionBar" ，運行后視圖布局如下：
可以看到視圖結(jié)構(gòu)與我們之前分析的相比，發(fā)生了一些變化。
最后，還有個細節(jié)給各位補充下： Layout Inspector 只能分析出Android Studio當前 “正在運行的APP” 的視圖布局結(jié)構(gòu)，其他應用的視圖布局結(jié)構(gòu)是無法顯示的。
如果我們想要分析一個第三方應用（如：微信、QQ）的視圖結(jié)構(gòu)可以使用 Android Device Monitor(安卓設備監(jiān)視器) ，具體打開步驟如下圖所示：
以QQ為例，我們先打開手機QQ，顯示出QQ主界面，然后按照下圖的 "紅色圈選" ,依次點擊,當前的視圖結(jié)構(gòu)就出來了，但是相比于 Layout Inspector 工具，視圖屬性信息提供的較少...
視圖層級分析 到此結(jié)束，有時間再補篇源碼，分析一下布局加載的流程。
寫這篇文章的時候被IOS同事嘲諷了，它們吐槽Android的視圖分析工具太渣，最后對比看了下，Android的視圖分析工具確實沒有IOS的高大上......╮(╯▽╰)╭
最后，秀一下IOS的視圖分析工具 Reveal ，如下圖所示：
上一次說了android的啟動原理，這次說下android的進程間的通信。
linux 本身是提供了通信機制的。大概有7種左右。然后但是為什么android不用。反而要自己搞一套。主要分析到2個方面: 安全性 和性能。因為前期的移動手機性能不高。還有就是繞開Linux內(nèi)核的開源限制。
總結(jié)就是----避免內(nèi)核空間到數(shù)據(jù)接受端的直接的數(shù)據(jù)拷貝；數(shù)據(jù)接受端接收數(shù)據(jù)的時候，由于數(shù)據(jù)大小不確定，要么分配一個很大的空間裝數(shù)據(jù)，要么動態(tài)擴容；兩種方式都有問題；Binder使用mmap直接把接受端的內(nèi)存映射到內(nèi)存空間，避免了數(shù)據(jù)的直接拷貝；另外通過data_buffer等方式讓數(shù)據(jù)僅包含定長的消息頭，解決了接受端內(nèi)存分配的問題.
android內(nèi)部的進程間的通信都是通過binlder 來實現(xiàn)的。這個是很重要的一點。
我們面試問道的 aild Content Provider 調(diào)用撥打電話 Intent跳轉(zhuǎn) 其底層都是調(diào)用的bindler機制.
關于binlder的運行原理 我只寫一個大概。
在其底層的Linux中 /etc/bindler/ 有這個c 文件 就是binlder 的程序文件了。其內(nèi)部是采用的引用計數(shù)器來為何對象。要知道 我們的bindler是支持多進程。如何一個service端要對應多個客戶端 也就是說要實現(xiàn)多對多。在看內(nèi)部源碼的時候我發(fā)現(xiàn)其內(nèi)部是用2個紅黑樹來維持 一個service 對專門提供一個客戶端調(diào)用。如果還有其他的客戶端調(diào)用就在生成一個servicebindler 對象來提供調(diào)用 然后根據(jù)內(nèi)存管理的引用計數(shù)器來回收掉不需要的servicebindler對象。
如果你想深究 我推薦這個
一：?HierarchyView?
老牌分析工具，在早期的SDK中是有快捷方式的，新版的找不到快捷方式了，后來找了很久才找到入口
首先找到Android Device Monitor
可以進入到sdk的安裝目錄下 從tools目錄下點擊monitor.bat 啟動 Android Device Monitor
然后找到下圖紅框位置 點擊?HierarchyView 按鈕就可以打開 如果沒有HierarchyView 按鈕就點擊DDMS按鈕左邊的更多按鈕，里面會列出來HierarchyView 按鈕
HierarchyView 最大的好處是以這種結(jié)構(gòu)樹圖的方式展示ViewTree 能夠一目了然的看清結(jié)構(gòu)，并且可以評估繪制時間
但是在新的android版本里面?HierarchyView會提示找不到Service 遇到這種情況 參照如下文章解決
二：UI Automator
比較常見的工具，在很長一段時間內(nèi)，找不到HierarchyView用的就是他，但是這個工具不是很好用，有時候顯示的層級也不準，可能是我不太會用
入口如下圖
點擊紅框處進入
三：Layout Inspector
入口
打開之后是這個樣子
三種工具各有各的特點，大家可以根據(jù)自己的需求進行選擇
重慶分公司
重慶分公司
