Google提出View這個概念的目的是什麼？
View這個概念與Activtiy、Fragment以及Drawable之間是一種什麼樣的關係？
View能夠感知Activity的生命週期事件嗎？爲什麼？
View的生命週期是什麼？
當View所在的Activity進入stop狀態後，View去哪了？如果我在一個後臺線程中持有一個View的引用，我此時能夠改變它的狀態嗎？爲什麼？
View能夠與其他的View交叉重疊嗎？重疊區域發生的點擊事件交給誰去處理呢？可不可以重疊的兩個View都處理？
View控制一個Drawable的方法途徑有哪些？Drawable能不能與View通信？如果能如何通信？
假如View所在的ViewGroup中的子View減少了，View因此獲得了更大的空間，View如何及時有效地利用這些空間，改變自己的繪製？
假如我要在View中動態地註冊與解除廣播接收器，應該在哪裏完成呢？
假如我的手機帶鍵盤（自帶或者外接），你的自定義View應該如何響應鍵盤事件。
AnimationDrawable作爲View的背景，會自動進行動畫，View在其中扮演了怎樣的角色？
假如以上問題你都能準確地回答出來，那麼，恭喜你！我覺得你的自定義View已經學到家了，如果有那麼幾個問題你還搞不清楚，或者不是很確定，那麼，請上終南山，閉關三個月，繼續參悟自定義View的內在玄機。
爲什麼看了那麼多文章，還是無法愉快地與自定義View玩耍？是那些文章不好嗎？非也，是你沒有掌握學習自定義View的正確姿勢（即使你會很多姿勢，也木有用，嘎嘎）。你看那些作者，輕輕鬆鬆整出一個漂亮的自定義View，你依葫蘆畫瓢也整出一個，就覺得自己好像也會了，年輕人，你太傲嬌了！你想過沒有,寫這些文章的人是怎麼掌握自定義View的？請把這個問題在心中默唸三遍。以後讀任何技術文章，都問自己這樣的問題，相信不久的將來，你也會成爲Android大牛的，至少也是小壯牛一頭！因爲，你已經從學習別人的知識，進入到學習別人的方法的境界了，功力怎能不大增！
好了，說了這麼多，到底怎樣才能學好自定義View？其實只需掌握三個問題，就可以輕鬆搞定它：
問題一：從Android系統設計者的角度，View這個概念究竟是做什麼的？
問題二：Android系統中那個View類，它有哪些默認功能和行爲，能幹什麼，不能幹什麼？（知己知彼，纔好自定義！）
問題三：我要改變這個View的行爲，外觀，肯定是覆寫View類中的方法，但是怎麼覆寫，覆寫哪些方法能夠改變哪些行爲？
以上三個問題，從抽象到具體，我覺得適用於學習任何技術知識，只是每個問題的問法可能因具體技術而有所調整，總體上就是從概念上，從默認實現上，從自己定製上去提問，比如你學習RecyclerView，也可以問以上三個問題，按照這三個問題的順序一個一個搞懂了，也就完全掌握了這一知識點。
下面，我們就一個問題一個問題地來解答。
二、從Android系統設計者的角度，View這個概念究竟是做什麼的？
關於這個問題，最權威的當然是官方文檔，如下：
This class represents the basic building block for user interface components. A View occupies a rectangular area on the screen and is responsible for drawing and event handling.
這句話言簡意賅，高屋建瓴，一針見血，力透紙背，入木三分，令人銷魂佩服！需要我們認真體會，它包含三層含義：
View是用戶接口組件的基本構建塊。通俗講，在Android中，一個用戶與一個應用的交互，其實就是與這個應用中的許許多多的View的交互，這些View既可以是簡單的View，也可以是若干View組合而成的一個複合View。由此我們可以明白，所謂View是基本構件塊，原因就在於它是複合View(就是ViewGroup）的基本組成單元。這層含義，就是告訴你，View就是用來與用戶交互的，那麼很自然地，我們要問，我們用戶在哪裏與View交互，以及怎樣與View交互呢？
View在屏幕上佔據一個矩形區域。這是說，既然View是用戶與應用交互的基本構建塊，而用戶使用Android設備時，主要是通過一個觸摸屏來交互的，相應的，Andorid的設計者們，就讓一個View就在屏幕上佔據一個矩形區域，用戶在這個區域中發生的交互動作（點擊、滑動、拖動等），就是與這個View的交互。什麼？爲什麼不讓View佔據一個圓形區域或者五角星區域呢？當然是爲了簡單。這就解決了在哪裏與View交互的問題。很自然地，我們又想問，View在屏幕上佔據一個矩形區域，這個區域的大小、位置怎麼確定，它們會不會變化，誰來決定這個變化呢？如果這個變化不是由View自己來決定的，而是其他外界因素決定的，View又要怎樣響應這種變化呢？不要急，後面都會有答案。
View通過繪製自己與事件處理兩種方式與用戶交互。這是解決了如何交互的問題。簡單講，View與用戶交互就兩個辦法，一個是改變自己的模樣，也就是通過繪製自己與用戶交互，比如，當用戶點擊自己時，就改變自己的背景顏色，以此來告訴用戶：“本View已經響應你的點擊了！”第二個方式就是事件處理，比如，當用戶點擊View時，就完成一定的任務，然後彈出一個Toast，告訴用戶該View完成了什麼任務，這樣，用戶也就知道這次交互結果如何。
看到沒，這就是官方文檔的魅力，短短一句話，勝君讀千篇水文。現在我們明白了，設計View，主要是爲了讓應用能夠與用戶交互，要想完成交互，這個View就要在屏幕上佔據一個矩形區域，然後利用這塊屏幕區域與用戶交互，交互的方式就兩種，繪製自己與事件處理。
三、Android系統中那個View類，它有哪些默認功能和行爲，能幹什麼，不能幹什麼？
解決了第一個問題，我們很可能有更多的疑問，我們想知道：
View是怎樣被顯示到屏幕上的？
View在屏幕上的位置是怎樣決定的？
View所佔據的矩形大小是怎樣決定的？
屏幕上肯定不止一個View，View之間互相知道對方嗎？它們之間能協作嗎？
View完成與用戶的交互後，能夠自動隱藏，在需要交互的時候重新顯示在屏幕上嗎？
......
現在我們就一點點來講，學習的同時，最好能夠用心體會Google工程師設計時的思路。這樣學習效果最好。
首先，一個用戶界面，上面有許多View，既有基本View，也有複合View，把它們組織起來還讓它們很好地協作確實是一個難題，Google的解決方案是：首先，一套完整的用戶界面用一個Window來表示，Window這個概念和我們在計算機上所說的Window很相似。Window負責管理所有的View們，怎麼管理？很簡單，借鑑複合View的思路，Window首先加載一個超級複合View，用它來包含住所有的其他View，這個超級複合View就叫做DecorView。但是這個DecorView除了包含我們的用戶界面上那些View，還包含了作爲一個Window特有的View，叫做titlebar，這個我們就不細說了。
這樣，在Window中的View們被組織起來了，一個巨大的ViewGroup（以後，我們不再用複合View這個說法，而代之以ViewGroup，二者是一回事），下面有若干ViewGroup和若干View，每個ViewGroup下面又有若干ViewGroup和若干View，很像數據結構中的樹，葉子節點就是基本View。
好了，這些View已經被組織起來了，DecorView已經能夠完全控制它們了，同時，DecorView掌握着能夠分配給這些View的屏幕區域，包括區域的大小和位置。我們知道，屏幕的大小是有限的，一個Window的DecorView能夠控制的屏幕區域更加有限，AndroidN中引入多Window機制後，DecorView能掌控的屏幕區域更加小了，因爲屏幕上有多個Window將成爲常態。這些有限的區域還要被Window特有的View（titlebar）佔去一小部分，剩下的纔是留給用戶界面上的View們分的，如果你是DecorView,你肯定爲難了，如何將這些有限的屏幕區域分給這些View們？分給他們後還得爲每個View排好在屏幕上的位置，難上加難。
首先，不同的View是爲了完成特定的交互任務的，比如，Button就是用來點擊的，TextView就是用來顯示字符的，等等。DecorView知道，不同的View爲了完成自己的交互任務所需要的屏幕區域大小是不同的，所以DecorView在確定給每個View分配的屏幕區域大小時，是允許View參與進來，與它一起商量的。但是每個View在屏幕區域中的位置就不能讓View自己來決定了，而是由DecorView一手操辦，這個比較簡單，我們就先來看看DecorView是怎樣決定每個View的位置的吧。
1、確定每個View的位置
我們在Activity中，調用了setContentView（View），實際上就是將用戶界面的所有的View交給了DecorView中的一個FrameLayout，這個FrameLayou代表着可以分配給用戶界面使用的屏幕區域。而用戶界面View既可以是一個簡單的View，也可以是一個ViewGroup，如果是一個簡單的View，比如就是一個TextView，那麼這個TextView就會佔據整個FrameLayout的屏幕區域，也就是說，此時用戶在FrameLayout的屏幕區域內的所有交互都是與這個TextView交互。但是更常見的情況時，我們的用戶界面是一個ViewGroup（想想常用的佈局五大金剛），裏面包含着其他的ViewGroup和View。這個時候，首先這個ViewGroup就會佔據FrameLayout所代表的屏幕區域，剩下的任務，就是這個ViewGroup給它內部的小弟們（各種ViewGroup和各種View）分配區域了。至於怎麼分，不同的ViewGroup有不同的分法，總體來看，可說是有總有分。所謂總，舉例來講，像vertical的LinearLayout，它按照自己的小弟數量，把自己豎向裁成不同的區域，如下圖所示：
雖然View無法決定自己在ViewGroup中的位置，但是開發者在使用View時，可以向ViewGroup表達自己所用的View要放在哪裏，以vertical LinearLayout爲例，開發者書寫佈局文件時，子View在LinearLayout中的出現順序將決定它們在屏幕上的上下順序，同時還可以藉助layout_margin ,layout_gravity等配置進一步調整子View在分給自己的矩形區域中的位置。到這裏，我們可以理解，layout_*之類的配置雖然在書寫上與View的屬性在一起，但它們並不是View的屬性，它們只是使用該View的使用者用來細化調整該View在ViewGroup中的位置的，同時，這些值在Inflate時，是由ViewGroup讀取，然後生成一個ViewGroup特定的LayoutParams對象，再把這個對象存入子View中的，這樣，ViewGroup在爲該子View安排位置時，就可以參考這個LayoutParams中的信息了。進一步思考，我們發現，調用inflate時，除了輸入佈局文件的id外，一般要求傳入parent
ViewGroup，傳入這個參數的目的，就是爲了讀取佈局文件中的layout配置信息，如果沒有傳入，這些信息將會丟失，感興趣的同學可以自己試驗驗證下，這裏就不展開了。
不同的ViewGroup擁有不同的LayoutParams內部類，這是因爲，它們所允許的子View微微調整自己的位置的方式是不一樣的，具體講就是配置子View時，允許使用的layout_*是不一樣的，比如，RelativeLayout就允許layout_toRightOf等配置，其他的ViewGroup沒有這些配置。
這些確定View的位置的過程，被包裝在View 的layout方法中，這樣我們也很容易理解，對於基本View而言，這個方法是沒有用的，所以都是空的，你可以查看下ImageView、TextView等的源代碼，驗證下這一點。對於ViewGroup而言，它們會用該方法爲自己的子View安排位置。
2、確定View大小
下面，是要確定View的大小了，這是一個開發者、View與ViewGroup三方相互商量的過程。（這裏的講解可能與一般的文章不同，是我個人的理解，一般的文章都不會說是三方商量，而是直接說View與ViewGroup兩方商量）
第一步，開發者在書寫佈局文件時，會爲一個View寫上android:layout_width="***"android:layout_height="***"兩個配置，這是開發者向ViewGroup表達的，我這個View需要的大小是多少。星號的取值有三種：
*具體值，如50dp，很簡單，不多講
*match_parent ，表示開發者向ViewGroup說，把你所有的屏幕區域都給這個View吧。
*wrap_parent，表示開發者向ViewGroup說，只要給這個View夠他展示自己的空間就行，至於到底給多少，你直接跟View溝通吧，看它怎麼說。
第二步，ViewGroup收到了開發者對View大小的說明，然後ViewGroup會綜合考慮自己的空間大小以及開發者的請求，然後生成兩個MeasureSpec對象（width與height）傳給View，這兩個對象是ViewGroup向子View提出的要求，就相當於告訴子View：“我已經與你的使用者（開發者）商量過了，現在把我們商量確定的結果告訴你，你的寬度不能違反width MeasureSpec對象的要求，你的高度不能違反height MeasureSpec對象的要求，現在，你趕緊根據這個要求確定下自己要多大空間，只許少，不許多哦。”
然後，這兩個對象將會傳到子View的protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec)方法中。子View能怎麼辦呢？它肯定是要先看看ViewGroup的要求是什麼吧，於是，它從傳入的兩個對象中解譯出如下信息：
Mode與Size一起，準確表達出了ViewGroup的要求。下面我們舉例說明，假設Size是100dp，
Mode的取值有三種，它們代表了ViewGroup的總體態度：
1.EXACTLY 表示，ViewGroup對View說，你只能用100dp，這可是你的使用者要求的哦，他需要你佔這麼大的空間，而我恰好也有這麼多的空間，你的使用者讓你佔這麼大的空間，肯定有他自己的考慮，你不能不理不顧，不然你達不到他的要求，他可能就不用你了。
2.AT_MOST表示，你最多隻能用100dp，原因是多樣的，可能是你的使用者說要你完全佔據我的空間，而我只有100dp。也有可能是你的使用者說讓你佔據wrap_content的大小，讓我跟你商量，我又不知道你到底要佔多大區域，但是我告訴你，我只有100dp，你最多也只能用這麼多哈。(這裏，可以看出，當使用者在佈局文件中要求一個View是wrap_content時，此時，View的大小決定權就交給View自己了，默認的View類中的實現，比較粗暴，就是將此時ViewGroup提供的空間全佔據，完全沒有真正根據自己的內容來確定大小，爲什麼這麼粗暴？因爲View是一個基類，所有的組件都是它的子類，每個子類的content都各不相同，View怎麼可能知道content的大小呢，所以，它把wrap_content情況下，自己尺寸大小的決定權下放給了不同的子組件，讓它們自己根據自己的內容去決定自己的大小，同樣，我們自定義View時，也要考慮這一點)
3.UNSPECIFIED表示，你自己看着辦，把你最理想的大小告訴我，我考慮考慮。
第三步，好了，子View已經清楚地理解了ViewGroup和它的使用者對它的大小的期望和要求了。下步就要在該要求下來確定自己的大小並告訴ViewGroup了。（廢話，不告訴ViewGroup大小，它怎麼給你安排位置（layout），無法給你layout，你也就佔據不了一塊屏幕區域，佔不了屏幕區域，你就無法與用戶交互，無法與用戶交互，要你何用啊！）
關於子View怎麼確定自己的大小，不同的View有不同的態度，但是有幾點基本的規矩是要遵守的：
規矩一就是，不要違反ViewGroup的規定，最後設置的尺寸一定要在ViewGroup要求的範圍內（不論是寬度還是高度），但是你說，假如我就是想要更大的空間，難道就沒有辦法了嗎，我能不能遵守要求的情況下，同時告訴ViewGroup，雖然我告訴你的我要求的尺寸是遵照你的旨意來的，但實際上我是委屈求全的，我真實想要的大小不是這樣的,你能不能再考慮一下。答案是：有。那就是如下調用：
View可以把自己想要的寬和高進行一個resolveSizeAndState處理，就可以達到上述目的。即如果想要的大小沒超過要求，一切都Ok，如果超過了，在該方法內部，就會把尺寸調整成符合ViewGroup要求的，但是也會在尺寸中設置一個標記，告訴ViewGroup，這個大小是子View委屈求全的結果。至於ViewGroup會不會理會這一標記，要看不同的ViewGroup了。如果你實現自己的ViewGroup，最好還是關注下這個標記，畢竟作爲大哥的你，最主要的職責就是把自己的小弟（子View）安排好，讓它們都滿意嘛。
什麼？好奇的你想看看究竟是怎樣設置標記的？來來來，滿足你：
上面的代碼中的MEASURED_STATE_TOO_SMALL就是在子View想要的空間太大時設置的標記了。
規矩二就是要在該方法中調整自己的繪製參數，這一點很好理解，畢竟ViewGroup提出了尺寸要求，要及時根據這一要求調整自己的繪製，比如，如果自己的背景圖片太大，那就算算要縮放多少才合適，並且設置一個合理的縮放值。
規矩三就是一定要設置自己考慮後的尺寸，如果不設置就相當於沒有告訴ViewGroup自己想要的大小，這會導致ViewGroup無法正常工作，設置的辦法就是在onMeasure方法的最後，調用setMeasuredDimension方法。爲什麼調用這個方法就可以了呢？這只是一個約定，沒有必要深究了。
關於View的繪製，非常簡單，就是一個方法onDraw，後面的自定義View實戰部分會細說，這裏先略過了。
以上，View的三個基本知識點，我們都瞭解了，即View 的位置如何確定，大小如何確定以及如何繪製自己。這都是默認的View類中爲我們準備好的。
四、我要改變這個View的行爲，外觀，肯定是覆寫View類中的方法，但是怎麼覆寫，覆寫哪些方法能夠改變哪些行爲？
好了，View的位置和大小怎麼確定我們都清楚了，現在，是時候開始自定義View了。
首先，關於View所要具備的一般功能，View類中都有了基本的實現，比如確定位置，它有layout方法，當然，這個只適用於ViewGroup，實現自己的ViewGroup時，才需要修改該方法。確定大小，它有onMeasure方法，如果你不滿意默認的確認大小的方法，也可以自己定義。改變默認的繪製，就覆寫onDraw方法。下面，我們通過一張圖，來看看，自定義View時，我們最可能需要修改的方法是哪些：
把這些方法都搞明白了，你也就理解了View的生命週期了。
比如View被inflated出來後，系統會回調該View的onFinishInflate方法，你的View可以在這個方法中，做一些準備工作。
如果你的View所屬的Window可見性發生了變化，系統會回調該View的onWindowVisibilityChanged方法，你也可以根據需要，在該方法中完成一定的工作，比如，當Window顯示時，註冊一個監聽器，根據監聽到的廣播事件改變自己的繪製，當Window不可見時，解除註冊，因爲此時改變自己的繪製已經沒有意義了，自己也要跟着Window變成不可見了。
當ViewGroup中的子View數量增加或者減少，導致ViewGroup給自己分配的屏幕區域大小發生變化時，系統會回調View的onSizeChanged方法，該方法中，View可以獲取自己最新的尺寸，然後根據這個尺寸相應調整自己的繪製。
當用戶在View所佔據的屏幕區域發生了觸摸交互，系統會將用戶的交互動作分解成如DOWN、MOVE、UP等一系列的MotionEvent，並且把這些事件傳遞給View的onTouchEvent方法，View可以在這個方法中進行與用戶的交互處理。當然這個是基本的流程，實際的流程會稍複雜些，你可以閱讀我的另一篇文章，是專門講解事件分發的，文章非常經典，你讀了一定不後悔。
除了這些方法，View還實現了三個接口，如下：
View-Hierachy.png
三個接口是：
Drawable.Callback
KeyEvent.Callback
AccessibilityEventSource
每個接口都有自己的作用。
KeyEvent回調接口，是用來處理鍵盤事件的，這與onTouchEvent用來處理觸摸事件是相對的。
Drawable回調接口是用來讓View中的Drawable能夠與View通信的，尤其是AnimationDrawable，更是必須依賴該回調才能實現動畫效果，關於這一點，我深入地研究了FrameWork的源碼，對AnimationDrawable如何實現動畫，有了深入徹底的掌握，我也在考慮要不要就此寫一篇文章，看大家需要吧，如果本文贊數過百，我就寫，絕不食言。
第三個回調接口，我沒有細緻研究，不便多說。
寫到這裏你應該發現，我們的第三個問題，自定義View，應該覆寫哪些方法，能夠實現哪些功能也已經解決了。
五、光說不練假把式，實戰自定義View
說了這麼多，不自定一個View，怎麼對的起你辛苦讀到這裏呢。好，我們現在就來自定義一個鐘錶，而且可以自己走的。如下圖所示：
這個時鐘可是能夠走動的哈。下面我們就開始吧。首先，準備三張圖片資源，如下：
聰明如你，一看就應該知道這是做什麼用的了。準備圖片時，使用了一個小技巧，就是時針和分針，你所看到的圖像只是圖片的一半，在圖像的下方，還有同樣大小的空白，這個是做什麼用的呢？主要是爲了繪製圖片時的方便，待會兒就可以明白了。
材料齊全，開工！
public class AnalogClock extends View {
private Time mCalendar; //用來記錄當前時間
//用來存放三張圖片資源
private Drawable mHourHand;
private Drawable mMinuteHand;
private Drawable mDial;
//用來記錄錶盤圖片的寬和高，<span style="font-family: Arial, Helvetica, sans-serif;">以便幫助我們在onMeasure中確定View的大</span>小，
//畢竟，我們的View中最大的一個Drawable就是它了。
private int mDialWidth;
private int mDialHeight;
//用來記錄View是否被加入到了Window中，我們在View attached到
//Window時註冊監聽器，監聽時間的變更，並根據時間的變更，改變自己
//的繪製，在View從Window中剝離時，解除註冊，因爲我們不需要再監聽
//時間變更了，沒人能看得到我們的View了。
private boolean mAttached;
//看名字
private float mMinutes;
private float mHour;
//用來跟蹤我們的View 的尺寸的變化，
//當發生尺寸變化時，我們在繪製自己
//時要進行適當的縮放。
private boolean mChanged;
...
}//第一個構造方法
public AnalogClock(Context context) {
this(context, null);
}
//第二個構造方法
public AnalogClock(Context context, AttributeSet attrs) {
this(context, attrs, 0);
}
//第三個構造方法
public AnalogClock(Context context, AttributeSet attrs, int defStyleAttr) {
this(context, attrs, defStyleAttr, 0);
}
//第四個構造方法
public AnalogClock(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) {
super(context, attrs, defStyleAttr, defStyleRes);
final Resources r = context.getResources();
if (mDial == null) {
mDial = context.getDrawable(R.drawable.clock_dial);
}
if (mHourHand == null) {
mHourHand = context.getDrawable(R.drawable.clock_hand_hour);
}
if (mMinuteHand == null) {
mMinuteHand =
context.getDrawable(R.drawable.clock_hand_minute);
}
mCalendar = new Time();
mDialWidth = mDial.getIntrinsicWidth();
mDialHeight = mDial.getIntrinsicHeight();
<span style="font-family: Arial, Helvetica, sans-serif;">}</span>接下來，確定我們的自定義View 的大小，也就是改寫onMeasure方法：
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
int widthMode = MeasureSpec.getMode(widthMeasureSpec);
int widthSize = MeasureSpec.getSize(widthMeasureSpec);
int heightMode = MeasureSpec.getMode(heightMeasureSpec);
int heightSize = MeasureSpec.getSize(heightMeasureSpec);
float hScale = 1.0f;
float vScale = 1.0f;
if (widthMode != MeasureSpec.UNSPECIFIED && widthSize < mDialWidth) {
hScale = (float) widthSize / (float) mDialWidth;
}
if (heightMode != MeasureSpec.UNSPECIFIED && heightSize < mDialHeight) {
vScale = (float )heightSize / (float) mDialHeight;
}
float scale = Math.min(hScale, vScale);
setMeasuredDimension(
resolveSizeAndState((int) (mDialWidth * scale), widthMeasureSpec, 0),
resolveSizeAndState((int) (mDialHeight * scale), heightMeasureSpec, 0)
);
}確定了大小，是不是就可以繪製了，先不着急，我們先要處理兩件事，一件就是讓我們的自定義View能夠感知自己尺寸的變化，這樣每次繪製時，可以先判斷下尺寸是否發生了變化，如果有變化，就及時調整我們的繪製策略。代碼如下：
protected void onSizeChanged(int w, int h, int oldw, int oldh) {
super.onSizeChanged(w, h, oldw, oldh);
mChanged = true;
}第二件事就是讓我們的View能夠監聽時間變化，並及時更新該View中的mCalendar變量，然後根據它來更新自身的繪製。爲此，我們先寫一個更新時間的方法，代碼如下：
private void onTimeChanged() {
mCalendar.setToNow();
int hour = mCalendar.hour;
int minute = mCalendar.minute;
int second = mCalendar.second;
/*這裏我們爲什麼不直接把minute設置給mMinutes，而是要加上
second /60.0f呢，這個值不是應該一直爲0嗎？
這裏又涉及到Calendar的 一個知識點，也就是它可以是Linient模式，
此模式下，second和minute是可能超過60和24的，具體這裏就不展開了，
如果不是很清楚，建議看看Google的官方文檔中講Calendar的部分*/
mMinutes = minute + second / 60.0f;
mHour = hour + mMinutes / 60.0f;
mChanged = true;
}private final BroadcastReceiver mIntentReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
//這個if判斷主要是用來在時區發生變化時，更新mCalendar的時區的，這
//樣，我們的自定義View在全球都可以使用了。
if (intent.getAction().equals(Intent.ACTION_TIMEZONE_CHANGED)) {
String tz = intent.getStringExtra("time-zone");
mCalendar = new Time(TimeZone.getTimeZone(tz).getID());
}
//進行時間的更新
onTimeChanged();
//invalidate當然是用來引發重繪了。
invalidate();
}
};@Override
protected void onAttachedToWindow() {
super.onAttachedToWindow();
if (!mAttached) {
mAttached = true;
IntentFilter filter = new IntentFilter();
//這裏確定我們要監聽的三種系統廣播
filter.addAction(Intent.ACTION_TIME_TICK);
filter.addAction(Intent.ACTION_TIME_CHANGED);
filter.addAction(Intent.ACTION_TIMEZONE_CHANGED);
getContext().registerReceiver(mIntentReceiver, filter);
}
mCalendar = new Time();
onTimeChanged();
}
@Override
protected void onDetachedFromWindow() {
super.onDetachedFromWindow();
if (mAttached) {
getContext().unregisterReceiver(mIntentReceiver);
mAttached = false;
}
}@Override
protected void onDraw(Canvas canvas) {
super.onDraw(canvas);
//View尺寸變化後，我們用changed變量記錄下來，
//同時，恢復mChanged爲false，以便繼續監聽View的尺寸變化。
boolean changed = mChanged;
if (changed) {
mChanged = false;
}
/* 請注意，這裏的availableWidth和availableHeight，
每次繪製時是可能變化的，我們可以從mChanged變量的值判斷它是否發生了變化，
如果變化了，說明View的尺寸發生了變化，那麼就需要重新爲時針、分針設置Bounds，
因爲我們需要時針，分針始終在View的中心。*/
int availableWidth = super.getRight() - super.getLeft();
int availableHeight = super.getBottom() - super.getTop();
/* 這裏的x和y就是View的中心點的座標，
注意這個座標是以View的左上角爲0點，向右x，向下y的座標系來計算的。
這個座標系主要是用來爲View中的每一個Drawable確定位置。
就像View的座標是用parent的左上角爲0點的座標系計算得來的一樣。
簡單來講，就是ViewGroup用自己左上角爲0點的座標系爲各個子View安排位置，
View同樣用自己左上角爲0點的座標系爲它裏面的Drawable安排位置。
注意不要搞混了。*/
int x = availableWidth / 2;
int y = availableHeight / 2;
final Drawable dial = mDial;
int w = dial.getIntrinsicWidth();
int h = dial.getIntrinsicHeight();
boolean scaled = false;
/*如果可用的寬高小於錶盤圖片的實際寬高，
就要進行縮放，不過這裏，我們是通過座標系的縮放來實現的。
而且，這個縮放效果影響是全局的，
也就是下面繪製的錶盤、時針、分針都會受到縮放的影響。*/
if (availableWidth < w || availableHeight < h) {
scaled = true;
float scale = Math.min((float) availableWidth / (float) w,
(float) availableHeight / (float) h);
canvas.save();
canvas.scale(scale, scale, x, y);
}
/*如果尺寸發生變化，我們要重新爲錶盤設置Bounds。
這裏的Bounds就相當於是爲Drawable在View中確定位置，
只是確定的方式更直接，直接在View中框出一個與Drawable大小相同的矩形，
Drawable就在這個矩形裏繪製自己。
這裏框出的矩形，是以(x,y)爲中心的，寬高等於錶盤圖片的寬高的一個矩形，
不用擔心錶盤圖片太大繪製不完整， 因爲我們已經提前進行了縮放了。*/
if (changed) {
dial.setBounds(x - (w / 2), y - (h / 2), x + (w / 2), y + (h / 2));
}
dial.draw(canvas);
canvas.save();
/*根據小時數，以點(x,y)爲中心旋轉座標系。
如果你對來回旋轉的座標系感到頭暈，摸不着頭腦，
建議你看一下徐宜生《安卓羣英傳》中講解2D繪圖部分中的Canvas一節。*/
canvas.rotate(mHour / 12.0f * 360.0f, x, y);
final Drawable hourHand = mHourHand;
//同樣，根據變化重新設置時針的Bounds
if (changed) {
w = hourHand.getIntrinsicWidth();
h = hourHand.getIntrinsicHeight();
/* 仔細體會這裏設置的Bounds，我們所畫出的矩形，
同樣是以(x,y)爲中心的矩形，時針圖片放入該矩形後，時針的根部剛好在點(x,y)處，
因爲我們之前做時針圖片時，已經讓圖片中的時針根部在圖片的中心位置了，
雖然，看起來浪費了一部分圖片空間（就是時針下半部分是空白的），
但卻換來了建模的簡單性，還是很值的。*/
hourHand.setBounds(x - (w / 2), y - (h / 2), x + (w / 2), y + (h / 2));
}
hourHand.draw(canvas);
canvas.restore();
canvas.save();
//根據分針旋轉座標系
canvas.rotate(mMinutes / 60.0f * 360.0f, x, y);
final Drawable minuteHand = mMinuteHand;
if (changed) {
w = minuteHand.getIntrinsicWidth();
h = minuteHand.getIntrinsicHeight();
minuteHand.setBounds(x - (w / 2), y - (h / 2), x + (w / 2), y + (h / 2));
}
minuteHand.draw(canvas);
canvas.restore();
//最後，我們把縮放的座標系復原。
if (scaled) {
canvas.restore();
}
}