原文連結：http://www.jianshu.com/p/d507e3514b65

一、自定義View，你真的掌握了嗎？

什麼？你說你掌握了自定義View？來來來，回答老衲如下問題：

• 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，它按照
自己的小弟數量，把自己豎向裁成不同的區域，如下圖所示：

LinearLayout-sample.png

雖然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的要求是什麼吧，於是，它從傳入的兩個物件中解譯出如下資訊：

int widthMode = MeasureSpec.getMode(widthMeasureSpec);
int widthSize =  MeasureSpec.getSize(widthMeasureSpec);
int heightMode = MeasureSpec.getMode(heightMeasureSpec);
int heightSize =  MeasureSpec.getSize(heightMeasureSpec);

Mode與Size一起，準確表達出了ViewGroup的要求。下面我們舉例說明，假設Size是100dp，
Mode的取值有三種，它們代表了ViewGroup的總體態度：

1. EXACTLY 表示，ViewGroup對View說，你只能用100dp，原因是多樣的，可能是你的使用者說要你完全佔據我的空間，而我只有100dp。也可能這是你的使用者的要求，他需要你佔這麼大的空間，而我恰好也有這麼多的空間，你的使用者讓你佔這麼大的空間，肯定有他自己的考慮，你不能不理不顧，不然你達不到他的要求，他可能就不用你了。
2. AT_MOST表示，你最多隻能用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，雖然我告訴你的我要求的尺寸是遵照你的旨意來的，但實際上我是委屈求全的，我真實想要的大小不是這樣的,你能不能再考慮一下。答案是：有。那就是如下呼叫：

    resolveSizeAndState((int)(wantedWidth), widthMeasureSpec, 0),    
    resolveSizeAndState((int) (wantedHeight), heightMeasureSpec, 0);

View可以把自己想要的寬和高進行一個resolveSizeAndState處理，就可以達到上述目的。即如果想要的大小沒超過要求，一切都Ok，如果超過了，在該方法內部，就會把尺寸調整成符合ViewGroup要求的，但是也會在尺寸中設定一個標記，告訴ViewGroup，這個大小是子View委屈求全的結果。至於ViewGroup會不會理會這一標記，要看不同的ViewGroup了。如果你實現自己的ViewGroup，最好還是關注下這個標記，畢竟作為大哥的你，最主要的職責就是把自己的小弟（子View）安排好，讓它們都滿意嘛。（這一點，我沒有看到任何一篇講解自定義View的文章提到過！）
什麼？好奇的你想看看究竟是怎樣設定標記的？來來來，滿足你：

public static int resolveSizeAndState(int size, int measureSpec, int childMeasuredState) {  
      final int specMode = MeasureSpec.getMode(measureSpec);  
      final int specSize = MeasureSpec.getSize(measureSpec);  
      final int result;  
      switch (specMode) {     
         case MeasureSpec.AT_MOST:         
             if (specSize < size) {            
                  result = specSize | MEASURED_STATE_TOO_SMALL;         
             } else {            
                  result = size;      
             }         
             break;      
         case MeasureSpec.EXACTLY:          
              result = specSize;      
              break;       
         case MeasureSpec.UNSPECIFIED:   
         default:        
              result = size;   
       }   
       return result | (childMeasuredState & MEASURED_STATE_MASK);
}

上面的程式碼中的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-Method-For-Override.png

把這些方法都搞明白了，你也就理解了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

每個介面都有自己的作用。

KeyEvent回撥介面，是用來處理鍵盤事件的，這與onTouchEvent用來處理觸控事件是相對的。

Drawable回撥介面是用來讓View中的Drawable能夠與View通訊的，尤其是AnimationDrawable，更是必須依賴該回調才能實現動畫效果，關於這一點，我深入地研究了FrameWork的原始碼，對AnimationDrawable如何實現動畫，有了深入徹底的掌握，我也在考慮要不要就此寫一篇文章，看大家需要吧，如果本文贊數過百，我就寫，絕不食言。

第三個回撥介面，我沒有細緻研究，不便多說。

寫到這裡你應該發現，我們的第三個問題，自定義View，應該覆寫哪些方法，能夠實現哪些功能也已經解決了。

五、光說不練假把式，實戰自定義View

說了這麼多，不自定一個View，怎麼對的起你辛苦讀到這裡呢。好，我們現在就來自定義一個鐘錶，而且可以自己走的。如下圖所示：

screenshot0.png

這個時鐘可是能夠走動的哈。下面我們就開始吧。首先，準備三張圖片資源，如下：

clock_dial.png
clock_hand_hour.png
clock_hand_minute.png

聰明如你，一看就應該知道這是做什麼用的了。準備圖片時，使用了一個小技巧，就是時針和分針，你所看到的影象只是圖片的一半，在影象的下方，還有同樣大小的空白，這個是做什麼用的呢？主要是為了繪製圖片時的方便，待會兒就可以明白了。

材料齊全，開工！

public class AnalogClock extends View {   

      private Time mCalendar;    //用來記錄當前時間

      //用來存放三張圖片資源
      private Drawable mHourHand;  
      private Drawable mMinuteHand; 
      private Drawable mDial;   

    //用來記錄錶盤圖片的寬和高，
    //以便幫助我們在onMeasure中確定View的大
    //小，畢竟，我們的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;
...
}

下面，我們來確定自定義View 的構造方法，檢視View類，我們知道，View類有四個構造方法，我們相應地，也寫四個構造方法，並且初始化相關變數：

//第一個構造方法
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();}

請注意，以上為自定義View設定的構造方法是適用性最廣的一種寫法，這樣寫，可以確保我們的自定義View能夠被最大多數的開發者使用，是一種最佳實踐。
接下來，確定我們的自定義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想要的尺寸當然就是與錶盤一樣大的尺寸，這樣可以保證我們的View有最佳的展示，可是如果ViewGroup給的尺寸比較小，我們就根據錶盤圖片的尺寸，進行適當的按比例縮放。注意，這裡我們沒有直接使用ViewGroup給我們的較小的尺寸，而是對我們的錶盤圖片的寬高進行相同比例的縮放後，設定的尺寸，這樣的好處是，可以防止錶盤圖片繪製時的拉伸或者擠壓變形。

確定了大小，是不是就可以繪製了，先不著急，我們先要處理兩件事，一件就是讓我們的自定義View能夠感知自己尺寸的變化，這樣每次繪製時，可以先判斷下尺寸是否發生了變化，如果有變化，就及時調整我們的繪製策略。程式碼如下：

protected void onSizeChanged(int w, int h, int oldw, int oldh) {    
       super.onSizeChanged(w, h, oldw, oldh);   
       mChanged = true;
}

我們會在onDraw使用mChanged變數的。

第二件事就是讓我們的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;
}

然後我們還要實現一個廣播接收器，接收系統發出的時間變化廣播，然後更新該View的mCalendar，如下：

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();   
         }
};

現在，我們要給我們的View動態地註冊廣播接收器，沒錯，我們就是要在
onAttachedToWindow和onDetachedFromWindow中完成這一功能。程式碼如下：

@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;   
           }
}

萬事具備，只欠東風，開始繪製我們的View吧。程式碼如下：

@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();   
              }

}

大功告成，現在我們的時鐘終於完成了，任何開發者都可以使用我們的View，獲得一個不斷走動的模擬時鐘。該View的完整程式碼已經上傳到Github，猛戳https://github.com/like4hub/CustomViewForClock。（注：該時鐘的實現，主要參考了AOSP中模擬時鐘）

文／milter（簡書作者）
原文連結：http://www.jianshu.com/p/d507e3514b65
著作權歸作者所有，轉載請聯絡作者獲得授權，並標註“簡書作者”。