本系列文章
本文介紹 VirtualView 方案裡虛擬化控制元件的原理，包括尺寸計算與佈局的實現，以及它與原生控制元件組合使用時的邏輯互動。
相關開源庫
Android
iOS
名詞解釋
-
VirtualView：如果還不清楚，可以閱讀《天貓客戶端元件動態化的方案——VirtualView 上手體驗》大概瞭解下；
-
原生控制元件：就是通過封裝了系統原生 View 來實現的控制元件；
-
虛擬化控制元件：使用 canvas 繪製建立的控制元件，它需要依託一個原生容器控制元件作為宿主容器，承重其最終的展示；
控制元件體系與介面設計
先了解一下內建的控制元件組織關係：
IView 定義協議介面，包括三個過程:
- comMeasure/onComMeasure：尺寸計算；
- comLayout/onComLayout：尺寸佈局；
- comDraw/onComDraw：元件檢視繪製；
系統渲染元件的時候分別會呼叫這幾個過程。ViewBase 定義控制元件的基礎屬性；虛擬控制元件都繼承自 VirtualViewBase，虛擬容器控制元件都繼承自 Layout，原生控制元件需要按照本 IView 的協議進行封裝，這個封裝成就是需要繼承自 NativeViewBase；這樣虛擬元件和原生元件都有共同的對外介面，當系統渲染的時候不論虛擬化控制元件還是原生控制元件都可以用通用的方式呼叫，為混合方式搭建業務元件提供了可能性。
一個虛擬化控制元件與原生控制元件混合使用的例子
通過在宿主容器裡，掛了一個虛擬容器控制元件、一個虛擬文字控制元件、兩個原生圖片控制元件，可以組合成一個複雜的業務場景下的元件，當它被最終渲染出來的時候，系統只看到宿主容器和連個原生圖片元件，而且系統看到的是宿主容器下直接掛載了圖片控制元件；如果按照常規的方法開發，這種佈局結構，系統就看到了宿主容器、一層佈局、一個文字、兩個圖片，而且總共有 3 層結構，所以本方案能通過檢視結構扁平化、虛實結合的方式搭建檢視。
當這樣一個 VirtualView 掛載到系統佈局容器裡的時候，系統就要對他進行測量、佈局、繪製三個階段，才能顯示出來。而這三個階段觸發的入口便是宿主容器的 onMeasure，onLayout，onDraw 三個階段。對於從 XML 里載入出來的整個元件來說，會構造一棵 ViewBase 樹掛載到宿主容器裡，在宿主容器的 onMeasure，onLayout，onDraw 三個階段裡呼叫 ViewBase 樹根節點的 onComMeasure，onComLayout，onComDraw，然後再進一步遞迴呼叫子節點的這些方法，就配合系統顯示流程完成了對應的邏輯。虛擬化控制元件的尺寸計算協議與 Android 系統的協議一致。對於原生控制元件來說，IView 的實現就是呼叫 View 的對應方法，而對於虛擬化控制元件來說，onComMeasure 過程與實現自定義 View 一樣完成計算邏輯，而 onComLayout 過程需要根據計算結果控制子節點的佈局位置或者繪製位置，而 onComDraw 階段就是操作 canvas 物件，偏移一定位置，然後開始繪製。
例項
上圖例項中，圖示都是原生控制元件，而標題都是虛擬控制元件。
一個不足之處
如上所述，虛擬化控制元件的展示其實是依賴於一個宿主容器 View，那麼對於所有虛擬化控制元件來說，最終都是繪製到同一個宿主容器上的，宿主容器的繪製層級總是在最底層，因此當虛實結合使用的時候，原生控制元件會擋住虛擬化控制元件，因此實際的顯示順序會和 XML 裡控制元件的編寫順序不一致，只有當全部採用虛擬化控制元件搭建元件的時候，才不會出現這種情況。
體驗一下
講得再多，不如親自上手體驗一下，可以參考這篇文章來體驗。