【UML】如何看Android的UML图
? ??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() 在另外一個線程還沒返回，理所當然的我們需要等待它。不幸的是，這個時候死鎖發生了，如圖中紅色注釋所示。
? ??通過簡單的畫這么一個圖，可以很輕易的分析出一個死鎖的情況。那怎么解決它的，盡可以的避免圖中不同顏色的條塊重疊在一起?？纯聪旅娴慕鉀Q方案
? ??這回，我們取消了鎖的操作，通過添加一個新的線程(變成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轉載于:https://www.cnblogs.com/lcw/p/4073755.html
總結
以上是生活随笔為你收集整理的【UML】如何看Android的UML图的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： gVim 中文内容显示为乱码的解决办法
- 下一篇： Android系统匿名共享内存Ashme