android 4.1(jelly bean)
引入了vsync(vertical syncronization)
用於渲染同步，使得
和su***ceflinger
可以按硬體產生的
vsync
節奏來進行工作。
圖1 vsync模型
上述模型存在以下問題：
1.對於一幀內容，必須先等
畫完了，
su***ceflinger
才能對其進行合併渲染。這樣對於同一幀內容，第乙個
vsync
訊號時的資料開始準備，第二個
vsync
訊號時su***ceflinger
工作，第三個
vsync
訊號時使用者看到內容，這樣就兩個
vsync period(
每個16ms)
過去了。這會影響使用者體驗。
2.計算機資源是有限的，大家一起做事，都搶資源，必然導致工作加倍的慢。
為了解決上述問題，增加系統的流暢性，
android 4.4(kitkat)
引入了vsync
的虛擬化，sf和
不再直接使用
hw vsync
。kitkat
建立了乙個
vsync
模型，該模型對硬體
vsync
進行取樣、處理，然後產生帶有相位偏移的兩個
vsync
訊號供sf
和使用。模型如下圖所示：
的pll模型
需要注意的是
dispsync
內部統計了產生的
sw vsync
和hw vsync
的誤差，在不需要
hw vsync
時會關閉
hw vsync
，在誤差太大的情況下會重
新使能hw vsync
，對hw vsync
進行重新取樣、更新模型引數，這樣
sw vsync
能與hw vsync
更加的精確，不至於誤差太大。
vsync
工作時序圖如下：
工作時序圖
這樣，和sf
既保持一定的節拍，又可以相互錯開，一前一後保持著節奏。需要注意的是其中兩個
phase offset
引數（即
vsync_event_phase_offset_ns
和sf_vsync_event_phase_offset_ns
）是可調的。
相關的類圖如下：
圖4 vsync
模型類圖
dispsync
類表示了乙個基於硬體
vsync
訊號的同步模型，它會根據從
hwcomposer
來的硬體
vsync
訊號的取樣來進行同步。其它兩個
eventthread
分別用了兩個不同的虛擬
vsync
訊號源（用
dispsyncsource
表示，其中包含了與真實
vsync
訊號的偏移），這兩個
vsync
訊號源就是被虛擬出來分別用於控制
和su***ceflinger
渲染的。在
eventthread
的執行緒迴圈中，如果有需要就會向
dispsync
註冊相應的
listener
。dispsyncthread
在主迴圈中會先通過已經向
dispsync
註冊的listener
計算下乙個要產生的虛擬
vsync
訊號還要多久，等待相應時間後就會呼叫相應
listener
的callback
函式。
EventThread執行緒對VSync的分發
eventthread執行緒對vsync的分發 前面提到，eventthread在接收到vsync後再將它們分發給感興趣的註冊者，分發的過程是在其執行緒迴圈threadloop函式中完成的。讀者也可以先閱讀後面一節內容，先了解感興趣的註冊者如何得到vsync通知以及系統中可能存在哪些感興趣的註冊者後...
半虛擬化和全虛擬化的區別
1.全虛擬化比半虛擬化技術先出來 2.全虛擬化，客戶機認為自己執行在硬體之上，優點 不需對客戶機作業系統進行修改 缺點 消耗資源大 3.半虛擬化，客戶機知道自己是執行在虛擬機器上，缺點 需要對客戶機作業系統進行修改，所以對不能修改的系統 windows系統 不支援 優點 消耗資源小效能好，4.隨著，...
KVM虛擬化虛擬機器支援虛擬化
一 開啟的時候需要關閉所有虛擬機器 首先檢查 kvm host 宿主機 母機 上的kvm intel模組是否開啟了巢狀虛擬機器功能 預設是開啟的 1 modinfo kvm intel grep nested parm nested bool 2 cat sys module kvm intel p...