轉載：

微軟亞洲研究院

編者按：移動和雲端計算作為新的計算平臺已經出現，並逐步融合成為一個強大的雲-移動計算平臺。本文提出了一個虛擬螢幕的構想，作為上述平臺的一個新的研發方向，將進一步優化使用者的整體計算體驗。對於這種虛擬螢幕，螢幕渲染工作在雲中完成，並以影象形式傳遞至客戶端，用於互動顯示。這樣，使用者就能通過瘦客戶端移動裝置享受到許多計算密集型和含有豐富圖形的服務。本文對其中的技術挑戰進行了討論，並嘗試加以解決。文中通過對兩種新型的雲移動應用——雲瀏覽器和雲手機的介紹，闡明瞭虛擬螢幕的優勢。

——曾文軍教授，密蘇里大學哥倫比亞分校

 

作者：微軟亞洲研究院 呂岩、李世鵬、沈慧鋒

 

近年來，我們見證了雲端計算的強勁增長，其中既有作為服務並通過網際網路交付的應用程式，也有資料中心內支援這些服務的硬體和軟體等基礎設施（注1）。一般來說，雲端計算提供了一個集中的平臺，用於執行程式和儲存資料。建立在這一平臺上的雲服務已經可以處理以前通常由客戶端裝置獨立完成的任務，並可以隨時隨地即時訪問。然而直到最近，本地客戶端裝置仍然承擔著一大部分以使用者互動為目的的螢幕影象渲染工作。

 

我們認為，螢幕渲染（screen rendering）也可以遷移至雲中，而經過渲染的螢幕影象可以作為雲服務的一部分提供給使用者。一般來說，螢幕代表著顯示影象的部分或全部。從廣義上講，它也代表著使用者介面中所涉及的資料集，例如顯示影象、音訊資料、滑鼠、鍵盤、手寫筆和觸控輸入，以及其他多模態輸入和輸出（multimodality inputs and outputs

）。在本文中，我們使用“螢幕”這一術語指代顯示影象。把螢幕渲染遷移至雲中，會帶來很多優勢。

 

首先，由於螢幕渲染與程式執行和資料儲存密切相關，而將螢幕渲染遷移至資料儲存和程式執行集中進行的雲中，實際上簡化了雲端計算架構。其次，螢幕渲染，特別是含有豐富圖形的螢幕渲染，並不是簡單的任務。它往往需要在客戶端裝置上配備強大的CPU和GPU。而把螢幕渲染遷移到雲中，將大大降低對客戶端裝置的硬體要求，從而使降低客戶端裝置成本成為可能。第三，即使客戶端裝置配備了強大的CPU和GPU處理器，將螢幕渲染工作的部分或全部解除安裝到雲中，就能夠騰出客戶端的處理能力，更有效地處理高優先順序的任務（例如本地使用者介面）和豐富的使用者互動（例如觸控和手勢識別），這些都要求快速的本地響應。最後，將螢幕渲染遷移至雲中也為整體計算體驗的優化帶來了新的途徑。

 

螢幕虛擬化（screen virtualization），或將螢幕渲染遷移至雲中，並不總是意味著將全部的螢幕渲染任務放入雲中。根據實際情況，例如本地處理能力、頻寬和網路延遲、資料依賴和資料流量以及顯示解析度等，螢幕渲染任務可以有一部分在雲中完成，另一部分在客戶端完成（即可伸縮的螢幕虛擬化）；通過這樣的協作，將經過渲染的完整的畫面呈現給使用者。這非常類似於傳統的雲端計算：我們​​必須決定將程式執行和資料儲存是放在雲中遠端執行，還是留在本地裝置上執行，以獲得最佳的計算體驗。螢幕虛擬化所帶來的靈活性讓我們得以通過平衡本地客戶端裝置和遠端雲裝置上的資料儲存、程式執行和螢幕渲染等負載，提供進一步優化的計算體驗。

 

然而，如果客戶需要維持較高保真度的顯示影象，或要求響應性更好的使用者互動，那麼在雲中渲染螢幕的做法就會給客戶端裝置對虛擬螢幕的訪問增加難度。幸運的是，我們已經開發了一系列先進的多媒體和網路技術，用於解決這些問題。最終，我們希望為可伸縮螢幕虛擬化的雲端計算過程定義一套通用的雲API，這樣開發商就無須關心其中的資料儲存、程式執行和螢幕渲染任務實際發生在何處，因為針對雲服務的API將自適應、最優化地在雲裝置和客戶端裝置之間分配儲存、執行和渲染任務。與曾經推動了個人電腦大規模普及的GUI相似，雲API在雲和各種各樣的客戶端裝置之間架起了一座橋樑，能夠在本地和遠端兩個層面上引入新的計算體驗。這將促使雲-移動計算的演進轉化成為一場革命。

 

雲中的螢幕（Screen in the Cloud）

 

網際網路的迅速發展為我們提供了得以利用託管在公共或私人資料中心內的強大、並行、分散式虛擬機器中的遠端計算和儲存資源的機會。在典型的雲-端計算架構內，資料和程式可以遠端和（或）本地儲存、載入和執行。為了利用雲優勢，計算密集型任務通常在雲中執行，以生成一些中間結果（例如HTML資料），然後再傳遞到客戶端裝置上進一步處理，生成顯示螢幕。換言之，本地螢幕渲染從資料儲存和程式執行中分離出去，並通過網際網路與後兩者實現連線。

 

 

直至現在，雲屏幕虛擬化仍然是雲端計算領域內進展不盡如人意的分支。相比之下，更加缺乏關注的領域是如何在雲中利用虛擬螢幕，並將其與本地渲染能力相結合，通過各種不同的裝置，提供相等甚至更好的使用者體驗，而不論其計算能力、渲染能力、頻寬和螢幕解析度的高下。圖1描述了雲-端計算概念性架構，其中的虛擬螢幕是在雲中進行渲染的。螢幕的行為與資料和程式類似，可以根據雲和客戶端的具體能力狀況，在兩者之間進行自適應性和協作性處理。正如我們前面提到的，帶有螢幕自適應（screen adaptation）功能的雲-端架構可以提供以下好處：

• 通過膝上型電腦、電視和電話等各種不同的螢幕，為終端使用者提供優化的互動體驗；
• 為開發者簡化程式設計模型，就像編寫本地應用程式，而無需糾結於各種型別的實時資料通訊；
• 通過虛擬機器機制和螢幕遠端處理能力，為軟體供應商提供部署雲軟體服務的快速模型，例如，這種模型能夠幫助快速​​部署試用版軟體，而無需擔心盜版問題。

現在，我們能否通過網際網路，將螢幕作為一種實時服務交付給使用者，實現近似本地的互動體驗？螢幕作為顯示影象，確實包含了大量的資料。幸運的是，它表現為影象序列時，其中存在很多可以有效去除的冗餘成分。此外，帶有全幀單元的螢幕重新整理可以使客戶端一側的螢幕更新延遲變得相對固定。雖然多媒體、硬體和網路技術的突破指日可待，但我們在虛擬螢幕遠端計算系統方面的最新進展表明，即便使用現有的技術，螢幕壓縮和傳輸技術也可以做得非常高效。

 

虛擬螢幕的遠端計算（Remote Computing with Virtualized Screen）

 

按照如圖1所示的雲端計算概念結構，我們已經開發出一種能夠利用互動式螢幕遠端處理技術的瘦客戶端遠端計算系統。

 

（1）系統架構（System Architecture）

 

瘦客戶端遠端計算系統可以為終端使用者提供高保真顯示和高響應性的互動，就好像使用本地計算機一樣。然而，複雜的圖形介面和多媒體應用往往會向瘦客戶端的開發者提出挑戰：如何利用低頻寬連線實現高效的傳輸。圖2描述我們所提議的瘦客戶端遠端計算系統，該系統實現了應用程式邏輯（遠端）和使用者介面（本地）的脫鉤，客戶端因而能夠使用作為雲虛擬機器部署的遠端伺服器。伺服器和客戶端之間通過互動螢幕遠端處理機制，實現了網上雙向溝通。客戶端將使用者輸入傳送到遠端伺服器，作為響應，伺服器將螢幕更新返回給客戶端。

 

螢幕更新模式決定了螢幕能否有效地壓縮並傳輸到客戶端。現有的瘦客戶端系統，例如虛擬網路計算（VNC）（注2）和遠端桌面協議（RDP）（注3），大多數情況下將螢幕更新表現為任意大小區域的基本圖形。這種機制允許伺服器簡單地將需要更新的基本圖形轉發至壓縮模組，而直接丟棄其它的穩定區域資訊。在客戶端，螢幕顯示模組對所收到基本圖形加以渲染，並覆蓋指定部分矩形區域的畫素。然而，需要更新的區域往往較小，而且可能出現在任意位置，如選單或編輯框等。對這些小區域和任意位置進行編碼，將導致系統受制於壓縮效率的衰減。

 

 

與基於任意尺寸區域的架構不同，我們的瘦客戶端系統採用了基於幀的螢幕表現模型（frame-based screen-representation model）。這種模型從幀緩衝區中一次性讀取螢幕上的所有畫素，並將整個螢幕影象送入壓縮模組和傳送模組。在客戶端，螢幕顯示模組將整個螢幕替換為新解碼的螢幕。如圖2所示，伺服器和客戶端儲存著相同的參照幀，用於清除連續幀之間的冗餘資料。除了在壓縮方面的優勢外，基於幀的螢幕表現模型還簡化系統架構，免去了排程螢幕區域更新所需的固定頻寬佔用。此外，基於幀的螢幕表現模式還可以非常迅速地恢復由於丟包（packet loss）而導致的錯誤，無須通過關鍵幀重新整理進行重傳。

 

相對於VNC和RDP等現有的遠端計算系統，我們所提出的解決方案能顯著改善使用者體驗，它同時反映在螢幕更新和互動反應的平滑度上；而使之成為現實的，就是我們下面要介紹的高階螢幕壓縮和傳輸技術。

 

（2）螢幕壓縮（Screen Compression）

 

螢幕影象可能包括但不限於網頁、幻燈片、海報、影象、視訊以及其他任何顯示在計算機螢幕上的內容。對於自然圖片，許多現有的影象和視訊編碼標準（如JPEG2000和H.264/高階視訊編碼）已具有出色的編碼效能。但是它們在螢幕影象壓縮（大多數情況下包含富文字）方面的效率卻不高。螢幕影象壓縮所面臨的挑戰歸納如下：

• 計算複雜性（computational complexity）。螢幕編解碼器不得不處理大量資料，以保持螢幕更新的高解析度和高幀率。同時，編解碼器還必須騰出絕大部分處理資源用於執行其它的常規應用；
• 壓縮效能（compression performance）。組成螢幕影象的文字、圖形和圖片都有各自不同的特點和對編碼工具的敏感性。螢幕編解碼器必須在一個框架內有效處理各類資料，並同時維持較低的計算成本。

一般來說，典型的螢幕影象可以劃分成四類區域：平滑、文字、圖片和圖片上的文字。根據我們的統計分析，平滑和圖片區域更適合於變換域的編碼；而文字和圖片上的文字區域則更合適於畫素域的有效壓縮。為了簡化編解碼器的架構，我們提出了一種基於塊的編碼演算法，它僅包含兩種編碼型別：圖片和文字。文字塊編碼方案還包含“逃脫畫素編碼（escape pixel-coding technique）”技術，它專門用於處理“圖片上的文字”區域內的背景圖片畫素。

 

 

圖3描述了我們所提出的螢幕壓縮演算法。捕獲的螢幕影象被分割成互不重疊的16×16區塊。與前一幀影象進行比較後，每個區塊被都被識別為“可跳過”或“不可跳過”兩類。接著，分類操作將不可跳過的區塊劃分成圖片塊和文字塊，然後呼叫與這兩類區塊相關聯的自適應編碼方案。在區塊分類中運用了統計梯度直方圖（statistical gradient histogram）。100％準確的區塊分類是幾乎不可能的，因為“圖片上的文字”區域本身是千變萬化的。幸運的是，我們提出的“逃脫畫素”編碼方案可避免在分類失當的情況下避免畫質損失，並僅有微小的位元速率增加。

 

這種螢幕編解碼器在編碼速度、質量和計算複雜性等方面的表現都超過了用於螢幕影象編碼的傳統自然影象和視訊編解碼器。編碼和解碼過程對GPU也十分友好。主流顯示卡的GPU加速能夠輕而易舉地使螢幕捕捉和編碼的幀速率達到無GPU加速系統的兩倍。

 

（3）螢幕傳輸（Screen Transmission）

 

在遠端計算系統中，螢幕傳輸延遲可能是影響使用者體驗的最重要因素。由於螢幕影象是按照與視訊類似的時間序列加以組織的，我們在其中利用了一些現有的視訊傳輸技術。經過預測式編碼的各幀之間具有強烈的相互依賴性，使得視訊流對傳輸錯誤異常敏感。因此，必須運用一些緩衝和錯誤控制機制，這樣，在固有的網路傳輸延遲以外，又產生了額外的延遲。

 

此外，互動螢幕遠端處理（interactive screen remoting）對延遲的要求要比實時視訊通訊嚴格得多。例如，使用者通常期望在點選某個按鈕後，本地顯示器立即做出反應，就像使用本地計算機一樣。為了達到這一效能，要求雲虛擬螢幕和本地裝置顯示器之間的快速往返訊息處理以及幾乎即時的更新速度。因此，現有的視訊傳輸技術可能無法滿足互動式螢幕遠端處理場景的要求。

 

幸運的是，我們提出的螢幕編解碼器並不會引起連續幀之間的高度依賴性，它可以在一定程度上緩解經過解碼的螢幕影象中由傳輸錯誤引起的漂移誤差​​。此外，螢幕遠端處理還具有與視訊傳輸場景迥然相異的獨特功能。例如，它並不需要每次都對整個螢幕畫面進行更新。相反，一些出現問題的螢幕區域可以在得到訊號時立即呈現。因此，有可能通過一些具有內容感知能力的排程方案來幫助最大程度地減少傳輸延遲。

 

 

圖4描述了我們所提出的螢幕傳輸演算法，其基礎是螢幕壓縮和傳輸的聯合優化。螢幕影象處理分為三個層面：

• 在編解碼器層面，螢幕影象編碼通過一種靈活的切片結構（slicing structure），幫助客戶端對隱藏了錯誤的螢幕進行重構。此外，螢幕解碼器可以處理外出現故障的螢幕資料包，而不會產生漂移誤差（drifting errors）；
• 在控制層面，擁塞-失真優化演算法（congestion-distortion optimization algorithm）可以排程傳送緩衝區中的資料包。這些資料包的排程依據是其對網路擁塞和顯示失真的影響程度。有些資料包可能會被丟棄，而不會對後續幀進行重新編碼；

    在傳輸層面，我們運用了帶有自動重複請求的UDP傳輸協議，以平衡傳輸速率和錯誤控制。為了避免網路擁塞，我們利用TCP友好型速率控制器來估計可用頻寬。

 

注：本文譯自Virtualized Screen: A Third Element for Cloud_Mobile Convergence，原文發表於IEEE MultiMedia.  

 

@[TOC]

歡迎使用Markdown編輯器

你好！ 這是你第一次使用 Markdown編輯器 所展示的歡迎頁。如果你想學習如何使用Markdown編輯器, 可以仔細閱讀這篇文章，瞭解一下Markdown的基本語法知識。

新的改變

我們對Markdown編輯器進行了一些功能拓展與語法支援，除了標準的Markdown編輯器功能，我們增加了如下幾點新功能，幫助你用它寫部落格：

1. 全新的介面設計 ，將會帶來全新的寫作體驗；
2. 在創作中心設定你喜愛的程式碼高亮樣式，Markdown 將程式碼片顯示選擇的高亮樣式 進行展示；
3. 增加了 圖片拖拽 功能，你可以將本地的圖片直接拖拽到編輯區域直接展示；
4. 全新的 KaTeX數學公式 語法；
5. 增加了支援甘特圖的mermaid語法¹ 功能；
6. 增加了 多螢幕編輯 Markdown文章功能；
7. 增加了 焦點寫作模式、預覽模式、簡潔寫作模式、左右區域同步滾輪設定 等功能，功能按鈕位於編輯區域與預覽區域中間；
8. 增加了 檢查列表 功能。

功能快捷鍵

撤銷：Ctrl/Command + Z
重做：Ctrl/Command + Y
加粗：Ctrl/Command + B
斜體：Ctrl/Command + I
標題：Ctrl/Command + Shift + H
無序列表：Ctrl/Command + Shift + U
有序列表：Ctrl/Command + Shift + O
檢查列表：Ctrl/Command + Shift + C
插入程式碼：Ctrl/Command + Shift + K
插入連結：Ctrl/Command + Shift + L
插入圖片：Ctrl/Command + Shift + G

合理的建立標題，有助於目錄的生成

直接輸入1次#，並按下space後，將生成1級標題。
輸入2次#，並按下space後，將生成2級標題。
以此類推，我們支援6級標題。有助於使用TOC語法後生成一個完美的目錄。

如何改變文字的樣式

強調文字 強調文字

加粗文字 加粗文字

標記文字

刪除文字

引用文字

H₂O is是液體。

2¹⁰ 運算結果是 1024.

插入連結與圖片

連結: link.

圖片:

帶尺寸的圖片:

當然，我們為了讓使用者更加便捷，我們增加了圖片拖拽功能。

如何插入一段漂亮的程式碼片

去部落格設定頁面，選擇一款你喜歡的程式碼片高亮樣式，下面展示同樣高亮的 程式碼片.

// An highlighted block
var foo = 'bar';

生成一個適合你的列表

• 專案
  • 專案
    • 專案

1. 專案1
2. 專案2
3. 專案3

• 計劃任務
• 完成任務

建立一個表格

一個簡單的表格是這麼建立的：

專案	Value
電腦	$1600
手機	$12
導管	$1

設定內容居中、居左、居右

使用:---------:居中
使用:----------居左
使用----------:居右

第一列	第二列	第三列
第一列文字居中	第二列文字居右	第三列文字居左

SmartyPants

SmartyPants將ASCII標點字元轉換為“智慧”印刷標點HTML實體。例如：

TYPE	ASCII	HTML
Single backticks	'Isn't this fun?'	‘Isn’t this fun?’
Quotes	"Isn't this fun?"	“Isn’t this fun?”
Dashes	-- is en-dash, --- is em-dash	– is en-dash, — is em-dash

建立一個自定義列表

Markdown

Text-to- HTML conversion tool

Authors

John

Luke

如何建立一個註腳

一個具有註腳的文字。²

註釋也是必不可少的

Markdown將文字轉換為 HTML。

KaTeX數學公式

您可以使用渲染LaTeX數學表示式 KaTeX:

Gamma公式展示 $\Gamma(n) = (n-1)!\quad\forall n\in\mathbb N$ 是通過尤拉積分

$\Gamma(z) = \int_0^\infty t^{z-1}e^{-t}dt\,.$

你可以找到更多關於的資訊 LaTeX 數學表示式here.

新的甘特圖功能，豐富你的文章

• 關於 甘特圖 語法，參考 這兒,

UML 圖表

可以使用UML圖表進行渲染。 Mermaid. 例如下面產生的一個序列圖：:

這將產生一個流程圖。:

• 關於 Mermaid 語法，參考 這兒,

FLowchart流程圖

我們依舊會支援flowchart的流程圖：

• 關於 Flowchart流程圖 語法，參考 這兒.

匯出與匯入

匯出

如果你想嘗試使用此編輯器, 你可以在此篇文章任意編輯。當你完成了一篇文章的寫作, 在上方工具欄找到 文章匯出 ，生成一個.md檔案或者.html檔案進行本地儲存。

匯入

如果你想載入一篇你寫過的.md檔案或者.html檔案，在上方工具欄可以選擇匯入功能進行對應副檔名的檔案匯入，
繼續你的創作。

---

1. mermaid語法說明 ↩︎

2. 註腳的解釋 ↩︎

轉載：

微軟亞洲研究院

編者按：移動和雲端計算作為新的計算平臺已經出現，並逐步融合成為一個強大的雲-移動計算平臺。本文提出了一個虛擬螢幕的構想，作為上述平臺的一個新的研發方向，將進一步優化使用者的整體計算體驗。對於這種虛擬螢幕，螢幕渲染工作在雲中完成，並以影象形式傳遞至客戶端，用於互動顯示。這樣，使用者就能通過瘦客戶端移動裝置享受到許多計算密集型和含有豐富圖形的服務。本文對其中的技術挑戰進行了討論，並嘗試加以解決。文中通過對兩種新型的雲移動應用——雲瀏覽器和雲手機的介紹，闡明瞭虛擬螢幕的優勢。

——曾文軍教授，密蘇里大學哥倫比亞分校

 

作者：微軟亞洲研究院 呂岩、李世鵬、沈慧鋒

 

近年來，我們見證了雲端計算的強勁增長，其中既有作為服務並通過網際網路交付的應用程式，也有資料中心內支援這些服務的硬體和軟體等基礎設施（注1）。一般來說，雲端計算提供了一個集中的平臺，用於執行程式和儲存資料。建立在這一平臺上的雲服務已經可以處理以前通常由客戶端裝置獨立完成的任務，並可以隨時隨地即時訪問。然而直到最近，本地客戶端裝置仍然承擔著一大部分以使用者互動為目的的螢幕影象渲染工作。

 

我們認為，螢幕渲染（screen rendering）也可以遷移至雲中，而經過渲染的螢幕影象可以作為雲服務的一部分提供給使用者。一般來說，螢幕代表著顯示影象的部分或全部。從廣義上講，它也代表著使用者介面中所涉及的資料集，例如顯示影象、音訊資料、滑鼠、鍵盤、手寫筆和觸控輸入，以及其他多模態輸入和輸出（multimodality inputs and outputs）。在本文中，我們使用“螢幕”這一術語指代顯示影象。把螢幕渲染遷移至雲中，會帶來很多優勢。

 

首先，由於螢幕渲染與程式執行和資料儲存密切相關，而將螢幕渲染遷移至資料儲存和程式執行集中進行的雲中，實際上簡化了雲端計算架構。其次，螢幕渲染，特別是含有豐富圖形的螢幕渲染，並不是簡單的任務。它往往需要在客戶端裝置上配備強大的CPU和GPU。而把螢幕渲染遷移到雲中，將大大降低對客戶端裝置的硬體要求，從而使降低客戶端裝置成本成為可能。第三，即使客戶端裝置配備了強大的CPU和GPU處理器，將螢幕渲染工作的部分或全部解除安裝到雲中，就能夠騰出客戶端的處理能力，更有效地處理高優先順序的任務（例如本地使用者介面）和豐富的使用者互動（例如觸控和手勢識別），這些都要求快速的本地響應。最後，將螢幕渲染遷移至雲中也為整體計算體驗的優化帶來了新的途徑。

 

螢幕虛擬化（screen virtualization），或將螢幕渲染遷移至雲中，並不總是意味著將全部的螢幕渲染任務放入雲中。根據實際情況，例如本地處理能力、頻寬和網路延遲、資料依賴和資料流量以及顯示解析度等，螢幕渲染任務可以有一部分在雲中完成，另一部分在客戶端完成（即可伸縮的螢幕虛擬化）；通過這樣的協作，將經過渲染的完整的畫面呈現給使用者。這非常類似於傳統的雲端計算：我們​​必須決定將程式執行和資料儲存是放在雲中遠端執行，還是留在本地裝置上執行，以獲得最佳的計算體驗。螢幕虛擬化所帶來的靈活性讓我們得以通過平衡本地客戶端裝置和遠端雲裝置上的資料儲存、程式執行和螢幕渲染等負載，提供進一步優化的計算體驗。

 

然而，如果客戶需要維持較高保真度的顯示影象，或要求響應性更好的使用者互動，那麼在雲中渲染螢幕的做法就會給客戶端裝置對虛擬螢幕的訪問增加難度。幸運的是，我們已經開發了一系列先進的多媒體和網路技術，用於解決這些問題。最終，我們希望為可伸縮螢幕虛擬化的雲端計算過程定義一套通用的雲API，這樣開發商就無須關心其中的資料儲存、程式執行和螢幕渲染任務實際發生在何處，因為針對雲服務的API將自適應、最優化地在雲裝置和客戶端裝置之間分配儲存、執行和渲染任務。與曾經推動了個人電腦大規模普及的GUI相似，雲API在雲和各種各樣的客戶端裝置之間架起了一座橋樑，能夠在本地和遠端兩個層面上引入新的計算體驗。這將促使雲-移動計算的演進轉化成為一場革命。

 

雲中的螢幕（Screen in the Cloud）

 

網際網路的迅速發展為我們提供了得以利用託管在公共或私人資料中心內的強大、並行、分散式虛擬機器中的遠端計算和儲存資源的機會。在典型的雲-端計算架構內，資料和程式可以遠端和（或）本地儲存、載入和執行。為了利用雲優勢，計算密集型任務通常在雲中執行，以生成一些中間結果（例如HTML資料），然後再傳遞到客戶端裝置上進一步處理，生成顯示螢幕。換言之，本地螢幕渲染從資料儲存和程式執行中分離出去，並通過網際網路與後兩者實現連線。

 

 

直至現在，雲屏幕虛擬化仍然是雲端計算領域內進展不盡如人意的分支。相比之下，更加缺乏關注的領域是如何在雲中利用虛擬螢幕，並將其與本地渲染能力相結合，通過各種不同的裝置，提供相等甚至更好的使用者體驗，而不論其計算能力、渲染能力、頻寬和螢幕解析度的高下。圖1描述了雲-端計算概念性架構，其中的虛擬螢幕是在雲中進行渲染的。螢幕的行為與資料和程式類似，可以根據雲和客戶端的具體能力狀況，在兩者之間進行自適應性和協作性處理。正如我們前面提到的，帶有螢幕自適應（screen adaptation）功能的雲-端架構可以提供以下好處：

• 通過膝上型電腦、電視和電話等各種不同的螢幕，為終端使用者提供優化的互動體驗；
• 為開發者簡化程式設計模型，就像編寫本地應用程式，而無需糾結於各種型別的實時資料通訊；
• 通過虛擬機器機制和螢幕遠端處理能力，為軟體供應商提供部署雲軟體服務的快速模型，例如，這種模型能夠幫助快速​​部署試用版軟體，而無需擔心盜版問題。

現在，我們能否通過網際網路，將螢幕作為一種實時服務交付給使用者，實現近似本地的互動體驗？螢幕作為顯示影象，確實包含了大量的資料。幸運的是，它表現為影象序列時，其中存在很多可以有效去除的冗餘成分。此外，帶有全幀單元的螢幕重新整理可以使客戶端一側的螢幕更新延遲變得相對固定。雖然多媒體、硬體和網路技術的突破指日可待，但我們在虛擬螢幕遠端計算系統方面的最新進展表明，即便使用現有的技術，螢幕壓縮和傳輸技術也可以做得非常高效。

 

虛擬螢幕的遠端計算（Remote Computing with Virtualized Screen）

 

按照如圖1所示的雲端計算概念結構，我們已經開發出一種能夠利用互動式螢幕遠端處理技術的瘦客戶端遠端計算系統。

 

（1）系統架構（System Architecture）

 

瘦客戶端遠端計算系統可以為終端使用者提供高保真顯示和高響應性的互動，就好像使用本地計算機一樣。然而，複雜的圖形介面和多媒體應用往往會向瘦客戶端的開發者提出挑戰：如何利用低頻寬連線實現高效的傳輸。圖2描述我們所提議的瘦客戶端遠端計算系統，該系統實現了應用程式邏輯（遠端）和使用者介面（本地）的脫鉤，客戶端因而能夠使用作為雲虛擬機器部署的遠端伺服器。伺服器和客戶端之間通過互動螢幕遠端處理機制，實現了網上雙向溝通。客戶端將使用者輸入傳送到遠端伺服器，作為響應，伺服器將螢幕更新返回給客戶端。

 

螢幕更新模式決定了螢幕能否有效地壓縮並傳輸到客戶端。現有的瘦客戶端系統，例如虛擬網路計算（VNC）（注2）和遠端桌面協議（RDP）（注3），大多數情況下將螢幕更新表現為任意大小區域的基本圖形。這種機制允許伺服器簡單地將需要更新的基本圖形轉發至壓縮模組，而直接丟棄其它的穩定區域資訊。在客戶端，螢幕顯示模組對所收到基本圖形加以渲染，並覆蓋指定部分矩形區域的畫素。然而，需要更新的區域往往較小，而且可能出現在任意位置，如選單或編輯框等。對這些小區域和任意位置進行編碼，將導致系統受制於壓縮效率的衰減。

 

 

與基於任意尺寸區域的架構不同，我們的瘦客戶端系統採用了基於幀的螢幕表現模型（frame-based screen-representation model）。這種模型從幀緩衝區中一次性讀取螢幕上的所有畫素，並將整個螢幕影象送入壓縮模組和傳送模組。在客戶端，螢幕顯示模組將整個螢幕替換為新解碼的螢幕。如圖2所示，伺服器和客戶端儲存著相同的參照幀，用於清除連續幀之間的冗餘資料。除了在壓縮方面的優勢外，基於幀的螢幕表現模型還簡化系統架構，免去了排程螢幕區域更新所需的固定頻寬佔用。此外，基於幀的螢幕表現模式還可以非常迅速地恢復由於丟包（packet loss）而導致的錯誤，無須通過關鍵幀重新整理進行重傳。

 

相對於VNC和RDP等現有的遠端計算系統，我們所提出的解決方案能顯著改善使用者體驗，它同時反映在螢幕更新和互動反應的平滑度上；而使之成為現實的，就是我們下面要介紹的高階螢幕壓縮和傳輸技術。

 

（2）螢幕壓縮（Screen Compression）

 

螢幕影象可能包括但不限於網頁、幻燈片、海報、影象、視訊以及其他任何顯示在計算機螢幕上的內容。對於自然圖片，許多現有的影象和視訊編碼標準（如JPEG2000和H.264/高階視訊編碼）已具有出色的編碼效能。但是它們在螢幕影象壓縮（大多數情況下包含富文字）方面的效率卻不高。螢幕影象壓縮所面臨的挑戰歸納如下：

• 計算複雜性（computational complexity）。螢幕編解碼器不得不處理大量資料，以保持螢幕更新的高解析度和高幀率。同時，編解碼器還必須騰出絕大部分處理資源用於執行其它的常規應用；
• 壓縮效能（compression performance）。組成螢幕影象的文字、圖形和圖片都有各自不同的特點和對編碼工具的敏感性。螢幕編解碼器必須在一個框架內有效處理各類資料，並同時維持較低的計算成本。

一般來說，典型的螢幕影象可以劃分成四類區域：平滑、文字、圖片和圖片上的文字。根據我們的統計分析，平滑和圖片區域更適合於變換域的編碼；而文字和圖片上的文字區域則更合適於畫素域的有效壓縮。為了簡化編解碼器的架構，我們提出了一種基於塊的編碼演算法，它僅包含兩種編碼型別：圖片和文字。文字塊編碼方案還包含“逃脫畫素編碼（escape pixel-coding technique）”技術，它專門用於處理“圖片上的文字”區域內的背景圖片畫素。

 

 

圖3描述了我們所提出的螢幕壓縮演算法。捕獲的螢幕影象被分割成互不重疊的16×16區塊。與前一幀影象進行比較後，每個區塊被都被識別為“可跳過”或“不可跳過”兩類。接著，分類操作將不可跳過的區塊劃分成圖片塊和文字塊，然後呼叫與這兩類區塊相關聯的自適應編碼方案。在區塊分類中運用了統計梯度直方圖（statistical gradient histogram）。100％準確的區塊分類是幾乎不可能的，因為“圖片上的文字”區域本身是千變萬化的。幸運的是，我們提出的“逃脫畫素”編碼方案可避免在分類失當的情況下避免畫質損失，並僅有微小的位元速率增加。

 

這種螢幕編解碼器在編碼速度、質量和計算複雜性等方面的表現都超過了用於螢幕影象編碼的傳統自然影象和視訊編解碼器。編碼和解碼過程對GPU也十分友好。主流顯示卡的GPU加速能夠輕而易舉地使螢幕捕捉和編碼的幀速率達到無GPU加速系統的兩倍。

 

（3）螢幕傳輸（Screen Transmission）

 

在遠端計算系統中，螢幕傳輸延遲可能是影響使用者體驗的最重要因素。由於螢幕影象是按照與視訊類似的時間序列加以組織的，我們在其中利用了一些現有的視訊傳輸技術。經過預測式編碼的各幀之間具有強烈的相互依賴性，使得視訊流對傳輸錯誤異常敏感。因此，必須運用一些緩衝和錯誤控制機制，這樣，在固有的網路傳輸延遲以外，又產生了額外的延遲。

 

此外，互動螢幕遠端處理（interactive screen remoting）對延遲的要求要比實時視訊通訊嚴格得多。例如，使用者通常期望在點選某個按鈕後，本地顯示器立即做出反應，就像使用本地計算機一樣。為了達到這一效能，要求雲虛擬螢幕和本地裝置顯示器之間的快速往返訊息處理以及幾乎即時的更新速度。因此，現有的視訊傳輸技術可能無法滿足互動式螢幕遠端處理場景的要求。

 

幸運的是，我們提出的螢幕編解碼器並不會引起連續幀之間的高度依賴性，它可以在一定程度上緩解經過解碼的螢幕影象中由傳輸錯誤引起的漂移誤差​​。此外，螢幕遠端處理還具有與視訊傳輸場景迥然相異的獨特功能。例如，它並不需要每次都對整個螢幕畫面進行更新。相反，一些出現問題的螢幕區域可以在得到訊號時立即呈現。因此，有可能通過一些具有內容感知能力的排程方案來幫助最大程度地減少傳輸延遲。

 

 

圖4描述了我們所提出的螢幕傳輸演算法，其基礎是螢幕壓縮和傳輸的聯合優化。螢幕影象處理分為三個層面：

• 在編解碼器層面，螢幕影象編碼通過一種靈活的切片結構（slicing structure），幫助客戶端對隱藏了錯誤的螢幕進行重構。此外，螢幕解碼器可以處理外出現故障的螢幕資料包，而不會產生漂移誤差（drifting errors）；
• 在控制層面，擁塞-失真優化演算法（congestion-distortion optimization algorithm）可以排程傳送緩衝區中的資料包。這些資料包的排程依據是其對網路擁塞和顯示失真的影響程度。有些資料包可能會被丟棄，而不會對後續幀進行重新編碼；

    在傳輸層面，我們運用了帶有自動重複請求的UDP傳輸協議，以平衡傳輸速率和錯誤控制。為了避免網路擁塞，我們利用TCP友好型速率控制器來估計可用頻寬。

 

注：本文譯自Virtualized Screen: A Third Element for Cloud_Mobile Convergence，原文發表於IEEE MultiMedia.