【UML】如何看Android的UML圖

標籤：android   style   blog   http   io   color   ar   os   使用   

    UML圖有很多類型，這裡只討論最重要也最常用的兩種 - 類圖和時序圖。1. 類圖

    通過類圖，我們可以很容易的瞭解代碼架構，理清模組之間的關係,

    包括繼承(Inheritance)，實現(realization)，依賴(dependency)，組合（Composition), 彙總（Aggregation), 關聯 （Association) 等等。

    下面就圖中給出的7種關係一一解讀。

    1.1 Composition

    Compostion 是一種 Association 關係，但它更強調兩個類之間整體和局部關係，它暗示兩個類之間有著相同的生命週期，

    比如說圖中的三個1.

•   W 是 ViewRootImpl的成員變數之一，ViewRootImpl 對象的建構函式裡也構造了W，因此，當ViewRootImpl 析構時，W也被析構，他們的生命週期是一致的。

  public final class ViewRootImpl implements ViewParent,        View.AttachInfo.Callbacks, HardwareRenderer.HardwareDrawCallbacks {  ...  final W mWindow;  ...    mWindow = new W(this); //互相引用，所以當一個銷毀時，另外一個也無法存在。｝

  View Code
• 同樣類似的關係存在於 WindowManagerService 和 WindwoState 之間。

1.2  Realization

       Realization就是實現，在Java中體現為implements 一個介面類interface, 在標準的C++中沒有明確的介面概念，但抽象類別實際上起著和介面類似的功能，因為C++的Realization可以體現為繼承一個抽象類別。在Android 的C++代碼中，有一個特殊的抽象類別IInterface, 定義了PC介面類的一些基本方法。

1.3  Association

      有介面就會有引用，在UML中一根最普通的單向箭頭即是引用（關聯）關係。它的含義是，某個對象用到了一個其他對象的介面或屬性。通常，Assocation 通過兩種方式擷取

•  依賴注入，通過建構函式或SetXXX()介面，比如說 WindowState 通過構造時傳入的參數擷取了對IWindow對象的引用

  WindowState(WindowManagerService service, Session s, IWindow c, WindowToken token,           WindowState attachedWindow, int appOp, int seq, WindowManager.LayoutParams a,           int viewVisibility, final DisplayContent displayContent)

  View Code
• 間接擷取，通過調用其他對象方法返回。

  mActivityManager = ActivityManagerNative.getDefault();

  View Code 

1.4 Android 的 IPC interface.

    C++和Java 的介面都只支援進程內的調用。為了支援專門用於跨進程的介面調用，Android 專門做了一些規定。

    凡是以IXXXX 定義的介面類均可以支援IPC(當然，進程內也可以調用IXXXX定義的介面）。

    當我們在圖中看到一個IXXX 介面類，我們便可以認為這是一個進程的邊界，他的實現端和調用端對象運行在不同的進程裡（至少是不同的線程）。

    如中，IWindow的兩端W對象 和 WindowState 對象就用不同的顏色來標明它們分屬於不同的進程，W運行在應用程式的進程裡，而WinState存在與System Server 進程裡。

1.5 Aggregation

    彙總表達了兩個類的從屬關係，但和Composition不同，他們的生命週期並不一樣。

    一個經典的例子就是工廠和車子，車子是工廠造出來的，工廠倒閉了，車子可以繼續開，反之亦然。

    圖中PolicyManager 和 PhoneWindow就是類似的關係。

1.6 Inherritance

    就是最常見的繼承關係了。

    複雜的繼承關係很難閱讀和記憶，通過UML圖則方便很多，你可以清楚到看出繼承關係，同時能夠理解繼承的設計思想。

    比如說圖中右上方，PhoneWindow 繼承了Window 類，Activity 引用的是其基類Window的對象，但背後真正幹事的是PhoneWindow對象, 因為Acitivy 用的Window類對象是PolicyManager構造出來的。通過這種方式，PhoneWindow的實現細節被PolicyManager 和 Window 基類隱藏起來，從而大大降低了應用程式（Activity) 改變的幾率。

    這個正是設計模式裡有名的原廠模式之一。

1.7  依賴

    依賴不同於引用，依賴者和被依賴著之間沒有直接的對象引用，通常是常量或靜態方法的使用。

    比中，Activity使用了PolicyManager類的靜態方法 makeNewWindow() 建立了PhoneWindow對象，我們說Acitivy 依賴PolicyManager 這個模組，但它並沒有引用PoclicyManager的對象。

    依賴通常用一根單向虛線箭頭表示。

2. 時序圖

    通過時序圖，我們可以瞭解代碼的調用流程， 並可以檢查調用過程中可能產成的潛在問題，如死結等。

    時序圖可以從兩個方向去看，縱向和橫向。

    縱向描述了一個對象在時間軸上所做的事情，一個方塊通過代表一個函數的調用。

    橫向則描述了各個對象之間的調用關係, 包括同步調用，非同步呼叫，返回等等。

    此外，在時序圖中，我們可以給執行塊賦予不同的顏色，代表了他們分別運行在不同的進程或線程裡。

    下面就是一張時序圖的例子，它描述了Android中一個System server 進程啟動的過程， 圖中的粉紅色注釋列舉了我們可以獲知的一些資訊。

 
    剛才不是說從時序圖中能看出死結？ 就這樣一樣圖？誇張了吧！ 沒錯，看看下面一個例子吧！   

    這是一個很簡單的例子，圖中有兩個線程，綠色是app線程，它通過調用MediaPlayer 對象的函數來控制播放器，這裡它做了兩件事，Start() 然後 Stop (). 而粉色部分代表Driver 線程，它通過回呼函數告知Mediaplayer 一下底層的事件。也就是說Mediaplayer 是一個被兩個線程同時引用的對象，是一個共用的資源。

    想當然的，我們用了一把鎖來保護它，防止他被同時使用產生衝突。所以，圖中，綠色的app在Stop()時候首先拿到了鎖。這時問題發生了，Stop()的過程可能會比較長，中途來了一個事件， 圖中黃色注釋的右方顯示了這個情況，兩個顏色的長條重疊在一起。這表明有資源衝突發生，也意味著潛在的死結風險。我們假設Stop()的最終目的就是要析構VideoDecoder 對象，但此時，VideoDecoder調用的eventHandler() 在另外一個線程還沒返回，理所當然的我們需要等待它。不幸的是，這個時候死結發生了，中紅色注釋所示。

    通過簡單的畫這麼一個圖，可以很輕易的分析出一個死結的情況。那怎麼解決它的，盡可以的避免圖中不同顏色的條塊重疊在一起。看看下面的解決方案

    這回，我們取消了鎖的操作，通過添加一個新的線程(變成3個線程，3種顏色）Thread，將同步的調用變成非同步，，交由Thread做幕後處理。    因此圖中不再有顏色塊重疊（非同步呼叫產生的重疊不算), Stop()和EventHandler都很快返回（非同步呼叫), 從而消除了死結的存在。    這也是為什麼Andriod 設計了Looper, MessageQueue 和 Handler 的非同步訊息處理機制，並在Framework 中大量的使用，因為Android 是個極其複雜的多線程/多進程應用環境，基於鎖的同步調用機制是難於保證完全避免死結的發生。

    這下同意了吧，時序圖對分析多線程的編程分析有很大的協助。我們應該在設計階段儘可能的用類圖和時序圖來協助我們避免一些常見的問題，協助我們得出一個儘可能好的設計。

3.  怎樣畫Android UML 圖？

    工具！必須依賴工具，市面上有太多的UML工具，你只需要找一款支援逆向工程的，即將代碼轉換成UML的資料結構，然後將類圖或時序圖一步步的繪製出來。

參考文章    http://www.cnblogs.com/samchen2009/p/3315999.html

【UML】如何看Android的UML圖