view元素的源碼

1. ViewPager系列文章（一）- ViewPager源碼分析及載入頁面原理圖

1>：點擊 viewPager.setAdapter進入下邊源碼，會調用 populate() 方法，這個方法作用是創建和銷毀子條目（子item）：

在populate()方法中：
創建ItemView：mAdapter.instantiateItem(this, position)；
銷毀ItemView：mAdapter.destroyItem(this, pos, ii.object);
所以由ViewPager的源碼可以看出，ViewPager里邊無論放多少個頁面都不會內存溢出，它會不斷的去創建和銷毀view；

和 ListView、RecyclerView不一樣，ListView、RecyclerView是會不斷的復用view，而viewpager是不斷的創建和銷毀view

輪播圖剛打開默認顯示當前頁，是第一頁，默認會緩存左右兩個頁面，如果左邊沒有，只有右邊有，那麼右邊是第0頁，當前頁是第一頁；
如果你滑動到第1頁，ViewPager會默認把 左邊第0頁 和 右邊第2頁 創建出來；
如果你滑動到第2頁，ViewPager會默認把第1頁和第3頁創建出來，而原來的第0頁就會變成需要銷毀的頁面；

如果想要緩存多頁，可以調用setOffscreenPageLimit()方法：
setOffscreenPageLimit(1)：ViewPager機制默認就是緩存1，表示左邊、右邊各緩存1頁，加上自己，總共是3頁，其餘頁面全部銷毀；
setOffscreenPageLimit(2)：表示默認給左右各緩存2頁，共4頁，加上自己，總共緩存5頁，其餘頁面全部銷毀；
setOffscreenPageLimit(3)：表示默認給左右各緩存3頁，共6頁，加上自己，總共緩存7頁，其餘頁面全部銷毀；

因為 smoothScrollTo()滑動方法也調用populate()，而populate()方法維護了當前顯示頁面和 左右緩存的頁面，就能做到無限滑動而不出問題；

A：從populate()源碼中可知：先判斷頁面是否在緩存范圍內：如果在，則addNewItem添加進來，否則在destroyItem掉；
B：ViewPager會緩存左右兩邊頁面+1（當前顯示頁面），默認認為當前頁面的 左右兩邊各有1個，用戶可以手動調用setOffscreenPageLimit()方法設置數量，如果傳的值小於1，就默認設置為1；
ViewPager實際示意圖如下：

2. 安卓開發中viewpager的源碼是在api多少里

1.首先ViewPager在哪個包下?

答:如圖,就是在v4.view包下,另外,ViewPager也是3.0(api 11)後Google推出的,對於低版本的
可以自行導入v4包來解決低版本兼容的問題!

2.ViewPager的簡單介紹
答:ViewPager就是一個頁面切換的組件而已,我們可以往裡面填多個view,然後
我們左右滑動切換不同的view而已,和ListView一樣,我們也需要一個Adapter(適配器),將要顯示
的View和我們的ViewPager進行綁定,而ViewPager有特定的Adapter——PagerAdapter！
另外,Google官方是建議我們使用Fragment來填充ViewPager的,這樣可以更加方便的生成
每個Page以及管理每個Page的生命周期!當然也給我們提供了兩個不同的Adapter!分別是:
FragmentPageAdapter和FragmentStatePagerAdapter,前者適用於頁面較少的情況,後者
適用於頁面較多的情況,,對於兩個Adapter的區別會在後面進行講解!

3.ViewPager的適配器——PagerAdapter講解
答:ViewPager和Listview這些組件其實都是類似的,只是前者單位是Page(頁面),後者是Item(項)
而PagerAdapter也是特別的!

①必須重寫的四個方法:

②方法簡介:
先說下簡單的兩個吧:
getCount( ):獲得viewpager中有多少個view
destroyItem( ):移除一個給定位置的頁面。適配器有責任從容器中刪除這個視圖。這是為了確保
在finishUpdate(viewGroup)返回時視圖能夠被移除。
而另外兩個就涉及到一個key的概念了:
instantiateItem( ):①將給定位置的view添加到ViewGroup(容器)中,創建並顯示出來
②返回一個代表新增頁面的Object(key),通常都是直接返回view本身就可以了,
當然你也可以自定義自己的key,但是key和每個view要一一對應的關系
isViewFromObject( ):判斷instantiateItem(ViewGroup, int)函數所返回來的Key與一個頁面視圖是否是
代表的同一個視圖(即它倆是否是對應的，對應的表示同一個View),通常我們直接寫
return view == object;就可以了,至於為什麼要這樣講起來比較復雜,後面有機會進行了解吧
貌似是ViewPager中有個存儲view狀態信息的ArrayList,根據View取出對應信息的吧!
③代碼示例:
Fragment的簡單用法:添加三個View到ViewPager,然後滑動
效果圖如下:

④實現流程:
step 1:定義三個布局,等下用來填充ViewPager的,例子比較簡單,直接用不同TextView與背景顏色來區分
view2,view3隻需要一下,然後改下顏色與文字就可以了

view1.xml

step 2:主界面布局文件的編寫,一個TextView + ViewPager,注意ViewPager的標簽:

是這樣的:android.support.v4.view.ViewPager

activity_main.xml:

step 3:編寫我們的自定義PagerAdapter適配器類,繼承PagerAdapter,實現四個基本的方法:
getCount( ),isViewFormObject( ),instantiateItem( ),destoryItem( ),同時還要定義一個View的
集合,用來放viewpager中的view
MyPagerAdapter.java:

package com.jay.example.viewpagerdemo1;

import java.util.ArrayList;

import android.support.v4.view.PagerAdapter;
import android.view.View;
import android.view.ViewGroup;

public class MyPageAdapter extends PagerAdapter {

private ArrayList viewLists;

public MyPageAdapter() {}
public MyPageAdapter(ArrayList viewLists)
{
super();
this.viewLists = viewLists;
}

@Override
public int getCount() {
return viewLists.size();
}

@Override
public boolean isViewFromObject(View view, Object object) {
return view == object;
}

@Override
public Object instantiateItem(ViewGroup container, int position) {
container.addView(viewLists.get(position));
return viewLists.get(position);
}

@Override
public void destroyItem(ViewGroup container, int position, Object object) {
container.removeView(viewLists.get(position));
}
}

step 4:最後就是MainActivity了,也很簡單,實例化ViewPager對象以及View集合,然後通過LayoutInflater動態
載入三個view,通過add方法添加到View集合中,接著把View集合作為參數傳遞給MyPagerAdapter對象,
最後 調用setAdapter(mAdapter);就可以了
MainActivity.java

3. 電腦view控制項視頻錄制源碼，view收到視頻畫面，通過button按鈕將view畫面保

imageView上好像是不好添加組件吧。。。 你一定需要一個imageView嗎？ 如果不一定，其實可以不添加ImageView,直接在你的布局裡設置背景圖片為本來ImageView中要添加的圖片，然後再在該布局上添加Button

4. Android UI繪制之View繪制的工作原理

這是AndroidUI繪制流程分析的第二篇文章，主要分析界面中View是如何繪制到界面上的具體過程。

ViewRoot 對應於 ViewRootImpl 類，它是連接 WindowManager 和 DecorView 的紐帶，View的三大流程均是通過 ViewRoot 來完成的。在 ActivityThread 中，當 Activity 對象被創建完畢後，會將 DecorView 添加到 Window 中,同時會創建 ViewRootImpl 對象，並將 ViewRootImpl 對象和 DecorView 建立關聯。

measure 過程決定了 View 的寬/高， Measure 完成以後，可以通過 getMeasuredWidth 和 getMeasuredHeight 方法來獲取 View 測量後的寬/高，在幾乎所有的情況下，它等同於View的最終的寬/高，但是特殊情況除外。 Layout 過程決定了 View 的四個頂點的坐標和實際的寬/高，完成以後，可以通過 getTop、getBottom、getLeft 和 getRight 來拿到View的四個頂點的位置，可以通過 getWidth 和 getHeight 方法拿到View的最終寬/高。 Draw 過程決定了 View 的顯示，只有 draw 方法完成後 View 的內容才能呈現在屏幕上。

DecorView 作為頂級 View ，一般情況下，它內部會包含一個豎直方向的 LinearLayout ，在這個 LinearLayout 裡面有上下兩個部分，上面是標題欄，下面是內容欄。在Activity中，我們通過 setContentView 所設置的布局文件其實就是被加到內容欄中的，而內容欄id為 content 。可以通過下面方法得到 content:ViewGroup content = findViewById(R.android.id.content) 。通過 content.getChildAt(0) 可以得到設置的 view 。 DecorView 其實是一個 FrameLayout , View 層的事件都先經過 DecorView ，然後才傳遞給我們的 View 。

MeasureSpec 代表一個32位的int值，高2位代表 SpecMode ,低30位代表 SpecSize , SpecMode 是指測量模式，而 SpecSize 是指在某種測量模式下的規格大小。
SpecMode 有三類，如下所示：

UNSPECIFIED

EXACTLY

AT_MOST

LayoutParams需要和父容器一起才能決定View的MeasureSpec，從而進一步決定View的寬/高。

對於頂級View，即DecorView和普通View來說，MeasureSpec的轉換過程略有不同。對於DecorView，其MeasureSpec由窗口的尺寸和其自身的LayoutParams共同確定；

對於普通View，其MeasureSpec由父容器的MeasureSpec和自身的Layoutparams共同決定；

MeasureSpec一旦確定，onMeasure就可以確定View的測量寬/高。

小結一下

當子 View 的寬高採用 wrap_content 時，不管父容器的模式是精確模式還是最大模式，子 View 的模式總是最大模式+父容器的剩餘空間。

View 的工作流程主要是指 measure 、 layout 、 draw 三大流程，即測量、布局、繪制。其中 measure 確定 View 的測量寬/高， layout 確定 view 的最終寬/高和四個頂點的位置，而 draw 則將 View 繪制在屏幕上。

measure 過程要分情況，如果只是一個原始的 view ，則通過 measure 方法就完成了其測量過程，如果是一個 ViewGroup ，除了完成自己的測量過程外，還會遍歷調用所有子元素的 measure 方法，各個子元素再遞歸去執行這個流程。

如果是一個原始的 View，那麼通過 measure 方法就完成了測量過程，在 measure 方法中會去調用 View 的 onMeasure 方法，View 類裡面定義了 onMeasure 方法的默認實現:

先看一下 getSuggestedMinimumWidth 和 getSuggestedMinimumHeight 方法的源碼：

可以看到， getMinimumWidth 方法獲取的是 Drawable 的原始寬度。如果存在原始寬度（即滿足 intrinsicWidth > 0），那麼直接返回原始寬度即可；如果不存在原始寬度（即不滿足 intrinsicWidth > 0），那麼就返回 0。

接著看最重要的 getDefaultSize 方法：

如果 specMode 為 MeasureSpec.UNSPECIFIED 即未指定模式，那麼返回由方法參數傳遞過來的尺寸作為 View 的測量寬度和高度；
如果 specMode 不是 MeasureSpec.UNSPECIFIED 即是最大模式或者精確模式，那麼返回從 measureSpec 中取出的 specSize 作為 View 測量後的寬度和高度。

看一下剛才的表格：

當 specMode 為 EXACTLY 或者 AT_MOST 時，View 的布局參數為 wrap_content 或者 match_parent 時，給 View 的 specSize 都是 parentSize 。這會比建議的最小寬高要大。這是不符合我們的預期的。因為我們給 View 設置 wrap_content 是希望View的大小剛好可以包裹它的內容。

因此：

如果是一個 ViewGroup，除了完成自己的 measure 過程以外，還會遍歷去調用所有子元素的 measure 方法，各個子元素再遞歸去執行 measure 過程。

ViewGroup 並沒有重寫 View 的 onMeasure 方法，但是它提供了 measureChildren、measureChild、measureChildWithMargins 這幾個方法專門用於測量子元素。

如果是 View 的話，那麼在它的 layout 方法中就確定了自身的位置（具體來說是通過 setFrame 方法來設定 View 的四個頂點的位置，即初始化 mLeft ， mRight ， mTop ， mBottom 這四個值）， layout 過程就結束了。

如果是 ViewGroup 的話，那麼在它的 layout 方法中只是確定了 ViewGroup 自身的位置，要確定子元素的位置，就需要重寫 onLayout 方法；在 onLayout 方法中，會調用子元素的 layout 方法，子元素在它的 layout 方法中確定自己的位置，這樣一層一層地傳遞下去完成整個 View 樹的 layout 過程。

layout 方法的作用是確定 View 本身的位置，即設定 View 的四個頂點的位置，這樣就確定了 View 在父容器中的位置；
onLayout 方法的作用是父容器確定子元素的位置，這個方法在 View 中是空實現，因為 View 沒有子元素了，在 ViewGroup 中則進行抽象化，它的子類必須實現這個方法。

1.繪制背景（ background.draw(canvas); ）；
2.繪制自己（ onDraw ）；
3.繪制 children（ dispatchDraw(canvas) ）；
4.繪制裝飾（ onDrawScrollBars ）。

dispatchDraw 方法的調用是在 onDraw 方法之後，也就是說，總是先繪制自己再繪制子 View 。

對於 View 類來說， dispatchDraw 方法是空實現的，對於 ViewGroup 類來說， dispatchDraw 方法是有具體實現的。

通過 dispatchDraw 來傳遞的。 dispatchDraw 會遍歷調用子元素的 draw 方法，如此 draw 事件就一層一層傳遞了下去。dispatchDraw 在 View 類中是空實現的，在 ViewGroup 類中是真正實現的。

如果一個 View 不需要繪制任何內容，那麼就設置這個標記為 true，系統會進行進一步的優化。

當創建的自定義控制項繼承於 ViewGroup 並且不具備繪制功能時，就可以開啟這個標記，便於系統進行後續的優化；當明確知道一個 ViewGroup 需要通過 onDraw 繪制內容時，需要關閉這個標記。

參考：《Android開發藝術探索》

5. View繪制流程（一）

最近在學習 View 的繪制流程，看了幾篇不錯的博客（ ViewRootImpl的獨白，我不是一個View(布局篇) 、 Android應用層View繪制流程與源碼分析 ）自己對照源碼，梳理了一遍。

在Activity的onResume之後，當前Activity的Window對象中的View會被添加在WindowManager中。

整個View樹的繪圖流程是在 ViewRootImpl 類的 performTraversals() 方法（這個方法巨長）開始的，該方法做的執行過程主要是根據之前設置的狀態，判斷是否重新計算視圖大小 (measure) 、是否重新放置視圖的位置 (layout) 、以及是否重繪 (draw) ，其核心也就是通過判斷來選擇順序執行這三個方法。

ViewRootImpl 調用 performMeasure 執行Window對應的View的測量。

int widthMeasureSpec :他由兩部分組成， 高2位表示MODE ，定義在MeasureSpec類（View的內部類）中，有三種類型， MeasureSpec.EXACTLY 表示確定大小， MeasureSpec.AT_MOST 表示最大大小， MeasureSpec.UNSPECIFIED 不確定。 低30位表示size ，也就是父View的大小。對於系統Window類的DecorVIew對象Mode一般都為MeasureSpec.EXACTLY ，而size分別對應屏幕寬高。對於子View來說大小是由父View和子View共同決定的。

默認的尺寸大小即傳入的參數都是通過 getDefaultSize 返回的，我們就看一下該方法的實現。

到此一次最基礎的元素View的 measure 過程就完成了。

View實際是嵌套的，而且measure是遞歸傳遞的，所以每個View都需要 measure ，能夠嵌套的View都是ViewGroup的子類，所以在ViewGroup中定義了 measureChildren , measureChild , measureChildWithMargins 方法來對子視圖進行測量， measureChildren 內部實質只是循環調用 measureChild ， measureChild 和 measureChildWithMargins 的區別就是是否把 margin 和 padding 也作為子視圖的大小。 ViewGroup 本身不調用 measureChildWithMargins 和 measureChildren 方法，由繼承類通過for循環調用此方法進行子View的測量。下面看一下ViewGroup中稍微復雜的 measureChildWithMargins 方法。

getChildMeasureSpec 的邏輯是通過其父View提供的 MeasureSpec 參數得到 specMode 和 specSize ，然後根據計算出來的 specMode 以及子View的 childDimension （layout_width或layout_height）來計算自身的 measureSpec ，如果其本身包含子視圖，則計算出來的 measureSpec 將作為調用其子視圖 measure 函數的參數，同時也作為自身調用 setMeasuredDimension 的參數，如果其不包含子視圖則默認情況下最終會調用 onMeasure 的默認實現，並最終調用到 setMeasuredDimension 。

在 Activity 的 onResume 之後，當前 Activity 的 Window 對象中的View(DecorView)會被添加在 WindowManager 中。也就是在 ActivityThread 的 handleResumeActivity 方法中調用 wm.addView(decor, l); 將DecorView添加到 WindowManager 中；

WindowManager 繼承 ViewManager ，它的實現類為 WindowManagerImpl ，該類中的方法的具體實現是由其代理類 WindowManagerGlobal 實現的；

在它的 addView 方法中會創建 ViewRootImpl 的實例，然後將Window對應的View(DecorView)，ViewRootImpl，LayoutParams順序添加在WindowManager中，最後將Window所對應的View設置給創建的ViewRootImpl，通過 ViewRootImpl 來更新界面並完成Window的添加過程；

設置view調用的是 ViewRootImpl 的 setView 方法，在該方法中調用 requestLayout(); 方法來非同步執行view的繪制方法；之後將 Window 添加到屏幕，通過 WMS （跨進程通信）

在 requestLayout 方法中最終會調用 ViewRootImpl 的 performTraversals(); 方法，該方法做的執行過程主要是根據之前設置的狀態，判斷是否重新計算視圖大小 (measure) 、是否重新放置視圖的位置 (layout) 、以及是否重繪 (draw) ，其核心也就是通過判斷來選擇順序執行這三個方法： performMeasure 、 performLayout 、 performDraw ;

在 performMeasure 方法中調用的是 View 的 measure 方法，該方法是 final 修飾，不能被子類重寫，在該方法中實際調用的是 View 的 onMeasure 方法，子類可以重寫 onMeasure 方法來實現自己的測量規則。

View 默認的 onMeasure 方法很簡單只是調用了 setMeasuredDimension 方法，該方法的作用是給 View 的成員變數 mMeasuredWidth 和 mMeasuredHeight 賦值，View的測量主要就是給這兩個變數賦值，這兩個變數一旦賦值，也就意味著測量過程的結束。

setMeasuredDimension 方法傳入的尺寸是通過 getDefaultSize(int size, int measureSpec); 方法返回的，在
getDefaultSize 方法中解析 measureSpec 的 Mode 和 Size ，如果Mode為 MeasureSpec.AT_MOST 或者 MeasureSpec.EXACTLY ,最終的size的值為解析後的size；如果 Mode 為 MeasureSpec.UNSPECIFIED ，最終的size為建議的最小值= getSuggestedMinimumWidth ,該方法的具體實現為 return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth()); ，建議的最小寬度和高度都是由View的Background尺寸與通過設置View的 miniXXX 屬性共同決定的

measureSpec 是由 getRootMeasureSpec 方法決定的： measureSpec = View.MeasureSpec.makeMeasureSpec(windowSize, View.MeasureSpec.EXACTLY); 根布局的大小是 Window 的大小，Window大小是不能改變的，總是全屏的。

View實際是嵌套的，而且measure是遞歸傳遞的，所以每個View都需要measure，能夠嵌套的View都是ViewGroup的子類，所以在ViewGroup中定義了 measureChildren , measureChild , measureChildWithMargins 方法來對子視圖進行測量， measureChildren 內部實質只是循環調用 measureChild ， measureChild 和 measureChildWithMargins 的區別就是是否把 margin 和 padding 也作為子視圖的大小。

measureChildWithMargins 方法的作用就是對 父View 提供的 measureSpec 參數結合 子View 的 LayoutParams 參數進行了調整，然後再來調用 child.measure() 方法，具體通過方法 getChildMeasureSpec 方法來進行參數調整。計算出來自身的 measureSpec 作為調用其子視圖 measure 方法的參數，同時也作為自身調用 setMeasuredDimension 的參數，如果其不包含子視圖則默認情況下最終會調用 onMeasure 的默認實現，並最終調用到 setMeasuredDimension 。

最終決定 View 的 measure 大小是 View 的 setMeasuredDimension 方法，該方法就是設置mMeasuredWidth和mMeasuredHeight的大小，ViewGroup在 onMeasure 方法調用 setMeasuredDimension 之前調整了 measureSpec 。

6. Android的View類是怎樣定義的源代碼是什麼

view的定義還真不是一兩句話能說清楚的。源碼里代碼2萬多行，最前面的注釋有500多行。

如果你用android studio，直接Ctrl 點擊View應該就能看到源碼。
當然也可以在網頁里查看源碼
http ://androidxref.com

7. android,中像activity 和view 這種常用類的源碼查看方法

1. 打開SDK Manager，下載源碼（sources for android sdk）。

2. 然後在eclipse中，ctrl+左鍵點擊比如View或者Activity，在打開的界面中選擇change attached source。

3. 選擇external location。如果源碼是jar文件，選擇external file。但是通過sdk manager下載的都是文件夾。

4. 指向SDK路徑/sources/android-xx目錄即可。
   

8. View源碼——fitSystemWindows詳解

該方法在窗口的insets發生變化時，被調用。View調用該方法，以調整內容來適應窗口的變化。窗口的insets變化，包括status bar、軟鍵盤、navigation bar等的顯隱。
一般情況下我們不需要關心這個方法。但如果設置 SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN、SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION 等標識開啟沉浸式，默認情況下，我們的內容區域就會被status bar、軟鍵盤等遮擋。
該方法的默認實現會根據insets值來設置view的padding，並返回true，防止該事件繼續傳遞（即只有一個view會真正fitSystemWindows）。要開啟該方法，需要執行 setFitsSystemWindows(true) ，或在XML中設置 android:fitsSystemWindows="true" 。
如果只需要為XML文件的根布局設置fitSystemWindows，該方法的默認實現就能滿足。如果需要適配更加復雜的布局（比如有兩個子View，一個在頂部，一個在底部，則頂部的需要根據insets設置paddingTop，底部的需要根據insets設置paddingBottom），你就需要重寫該方法，自行處理insets。
需要說明的是，如果不做任何處理，所有view接收到的insets都是一樣的（比如top是status bar的高度，bottom是軟鍵盤的高度）。該方法的執行在layout之前。

WindowInsets

該類封裝了幾種不同的insets。 mSystemWindowInsets 對應status bar、軟鍵盤等引起的insets。可用方法如下：

獲取四個邊的inset

消費掉insets，使之不再傳遞

生成新的WindowInsets對象

該方法會被第一個調用，如果設置了listener，則執行自定義的listener，否則執行 onApplyWindowInsets 。

默認情況下該方法會執行第一個分支，即執行上面的 fitSystemWindows 。api20以上，android建議覆寫該方法，而不是已廢棄的 fitSystemWindows 。

監聽fitSystemWindow事件。
listener類如下：

ViewGroup:

可以看到，從根布局開始，先執行本身的 super.dispatchApplyWindowInsets 方法，然後遍歷執行子View的 dispatchApplyWindowInsets 方法，如果被消費掉，則停止傳遞。

布局如下：

設置沉浸式：

設置軟鍵盤適配方式：

現在布局是這個樣子的：

圖1標題欄被狀態欄遮擋，圖2頁面被軟鍵盤遮擋。

再次強調一個概念，默認情況下，設置 android:fitsSystemWindows="true" 只有一個View會生效。

為根布局設置 android:fitsSystemWindows="true" ，同時為了方便觀察，給根布局設置一個灰色背景：

可以看到已經適配了軟鍵盤，但頂部toolbar區域也顯示了根布局的灰色背景，顯然默認實現滿足不了我們的需求。

解決方式有很多，這里介紹兩種比較優雅的方式。

首先需要為Toolbar也設置 android:fitsSystemWindows="true"

達到了預期效果。

自定義根布局

自定義toolbar

兩種方法實際上是等價，不過顯然還是第一種方式更友好，只需要設置一個listener就能搞定，但因為api版本限制，所以很多情況下還是要使用第二種方式。

如果覆寫了 fitSystemWindows(insets) 或者 onApplyWindowInsets(WindowInsets) ，覆寫方法中不調用對應的super方法，則不需要設置 setFitsSystemWindows(true) 或者 android:fitsSystemWindows="true" 。

原因如下：

9. sas中，如何查看viewtable 的源代碼

informat or format 命令可以指定和修改變數格式類型。