TW201706834A

TW201706834A - 應用程式與虛擬機器通訊連接的系統與方法

Info

Publication number: TW201706834A
Application number: TW105112104A
Authority: TW
Inventors: 林修平; 吳齊人; 石鴻賓; 蔡弘毅
Original assignee: 飛搜股份有限公司
Priority date: 2014-08-07
Filing date: 2016-04-19
Publication date: 2017-02-16
Also published as: US20160044139A1

Abstract

本發明關於一種應用程式與虛擬機器通訊連接的系統與方法，其中方法是設置一螢幕畫面上的一互動區域並輸出顯示至一用戶端上，該螢幕畫面可藉由一伺服器所執行的一應用程式而產生，並可藉由該伺服器產生串流至該用戶端，該方法可包含自該伺服器接收一座標與一硬體設定；設置該螢幕畫面上對應於該座標的一點，以形成一互動區域在該螢幕畫面上；調度對應該硬體設定的一功能於該互動區域；以及在該互動區域動作時執行該功能。

Description

應用程式與虛擬機器通訊連接的系統與方法

發明為關於一種透過使用者輸入或硬體輸入而產生使用者介面的系統與方法，特別是指一種在耦接于虛擬機器的應用程式產生使用者介面或螢幕畫面。

應用程式Arowser(以下稱為「Arowser^TM」)是首次被揭露並詳述于美國臨時專利申請案(Provisional Application)第61862967號，名稱為「METHODS AND SYSTEMS FOR IN-APPS SEARCH AND APP BROWSERS」，申請於2013年10月7日。其將一應用程式執行于一遠端伺服器，且該應用程式的螢幕畫面隨後自該遠端伺服器傳輸或串流至一用戶端，並呈現在一用戶端介面上(例如：呈現在Arowser^TM)。藉由Arowser^TM技術的協助，使用者可藉由與串流螢幕畫面的互動而遠端操作一應用程式，不需要在本地端安裝該應用程式。然而，遠端伺服器可能不具有能用於處理相關使用者的輸入或硬體資料/數值的感測器或硬體裝置/模組。舉例來說，當需要使用者的所在位置以提供本機服務時，執行應用程式的遠端伺服器可能不具有用於取得必要座標的全球衛星定位系統(GPS)或輔助全球衛星定位系統(AGPS)模組。而缺少合適的硬體感測器可能造成另一個問題。例如當透過Arowser^TM而與一特定應用程式(如移動遊戲應用程式)互動時，使用者可能需要傾斜/旋轉/搖晃一智慧型裝置(如智慧型手機、平板型電腦等，以下皆稱為智慧型裝置)。舉例而言，在需要類比汽車駕駛的遊戲中，可能需要使用者左右轉動他們的智慧型裝置。最後，網路中斷則也是一個問題，特別是在網路中斷時，自遠端伺服器串流至用戶端的應用程式螢幕畫面可能會受到影響。因此，Arowser^TM技術應有能力在網路中斷前，保留/保存螢幕畫面的最新更新狀態，以在網路服務恢復時，確保傳輸連續性。

本發明為提供一種在用戶端所顯示的螢幕畫面配置一互動區域的方法。其中，該螢幕畫面是由執行於一伺服器上的一應用程式所產生，並自該伺服器串流至該用戶端。該方法可包含步驟：自該伺服器接收一座標與一硬體設定；在該螢幕畫面相對應於該座標的一點上配置形成該互動區域；調度(dispatching)相對應於該硬體設定的一功能至該互動區域，以及在該互動區域作用時執行該功能。

本發明的一實施例為提供一種自用戶端的驅動程式(drivers)傳輸硬體資料至伺服器的方法。該方法可包含步驟：耦接該用戶端至執行一第二應用程式的該伺服器、自該伺服器接收相關于該第二應用程式的一硬體設定；以及調度對應于一第一應用程式的一功能，以依據該硬體設定，自一驅動程式接收一硬體資料；其中，該第一應用程式執行於該用戶端，且該第一應用程式的該功能為耦接該驅動程式，以接收該硬體資料，並傳送該硬體資料至該伺服器。

本發明的另一實施例為提供一種彩現(rendering)應用程式的圖像(graphic)的方法。其中，該應用程式執行於一伺服器，且該圖像彩現於一用戶端。該方法可包含步驟：自該伺服器接收一彩現命令、一參數及/或一紋理(texture)；以及傳送該彩現命令、該參數及/或該紋理至該用戶端的一驅動程式，以藉由該用戶端的一圖形處理單元(GPU)彩現該圖像。

本發明的又一實施例為提供一種第一應用程式，其執行於一用戶端，用以彩現執行於一伺服器的一第二應用程式的一圖像。該第一應用程式可包含一接收器，該接收器可用於接收該伺服器的一彩現命令、一參數及/或一紋理，並且傳送該彩現命令、該參數及/或該紋理至與該用戶端的一圖形處理單元相關的一驅動程式，以基於該彩現命令、該參數及/或該紋理彩現該圖像。

對於本發明的其他特點與優勢，部分將闡述於以下說明當中，部分則可由說明中明顯得知，或者是可由透過實施本發明而明瞭。本發明的特點和優勢可透過元件的操作手段和其組成而被理解及實現，特別是本發明在申請專利範圍所介定的部分。

以上一般所述者以及以下詳細說明，僅為本發明的舉例及說明而已，並非用來限定本發明實施的範圍。

1‧‧‧第一應用程式

2‧‧‧第二應用程式

10、10’‧‧‧記憶體

11‧‧‧顯示裝置

12、12’‧‧‧硬體裝置

13‧‧‧接收器

15‧‧‧調度器

17、17’‧‧‧硬體相關模組

19‧‧‧傳輸器

20‧‧‧記憶體

22‧‧‧圖形處理單元

26‧‧‧常駐程式

28‧‧‧轉譯器

100‧‧‧第一計算裝置

102‧‧‧應用程式層

104‧‧‧應用程式框架

106‧‧‧函式庫

108‧‧‧硬體抽象層

110‧‧‧核心

111、111’‧‧‧驅動程式

116‧‧‧按鍵

118‧‧‧使用者介面

126‧‧‧圖像

200‧‧‧第二計算裝置

202‧‧‧應用程式層

204‧‧‧應用程式框架

206‧‧‧函式庫

208‧‧‧硬體抽象層

210‧‧‧核心

210c‧‧‧vr_io_int

212‧‧‧虛擬機器

214‧‧‧硬體設定模組

216‧‧‧按鍵

218‧‧‧使用者介面

226‧‧‧圖像

圖1A：其為習知移動作業系統的示意圖；圖1B：為習知移動作業系統的彩現模組的示意圖；圖1C：其為習知移動作業系統用於彩現的元件的示意圖；圖2A、2B：其為本發明的一應用程式通訊連接一虛擬機器而產生使用者介面的一較佳實施例的示意圖；圖2B-1：其為圖2B的一彩現命令的示意圖；圖2C、2D：其為本發明的一應用程式與一虛擬機器的通訊連接系統的示意圖；圖3A、3B：其為本發明的一應用程式與一虛擬機器的通訊連接系統的一較佳實施例的示意圖；圖3C：其為圖3A與圖3B的一應用程式通訊連接一虛擬機器的示意圖；圖4A、4B：其為本發明的一應用程式與一虛擬機器的通訊連接系統的另一較佳實施例的示意圖；圖4C：其為圖4A與圖4B的應用程式通訊連接虛擬機器的一實施例的示意圖；圖4D：其為圖4A與圖4B的應用程式通訊連接虛擬機器的另一實施例的示意圖；以及圖5A^~5C：其為本發明的應用程式通訊連接虛擬機器的方法的流程圖。

以下為本發明的詳細實施例說明並佐以圖式，各圖式中相同的符號代表相同或相似的物件。

請參閱圖1A，其為Android作業系統的架構的示意圖，為一種移動作業系統(移動作業系統包含Android、iOS、Windows等)，運行於一智慧型裝置上(如智慧型手機)。熟悉該技術領域者可知，其他移動作業系統可具有相似於圖1A所描述及展示的功能/結構，除了一些具有不同於Android的運行時刻(runtime)的移動作業系統(Android的運行時刻包含 Dalvik虛擬機器或核心函式庫，而該些不同作業系統可能具有其他函式庫或虛擬機器)。一些移動作業系統可能不會包含用於對不同硬體設計作特殊化的一硬體抽象層(HAL)。熟悉該技術領域者亦應理解，這些移動作業系統之間的差異性，並不影響本發明在主張專利權的範圍。

傳統上，在應用層(其在圖1A標注為「應用程式」)中的一移動應用程式(諸如可下載、原生、網頁版或混合版移動應用程式，以下稱為「App」)可能使用一應用程式設計發展介面(API)而自智慧型裝置的硬體資源取得資料。應用程式設計發展介面亦可用於依據使用者的需求或輸入，從而用於產生檔案或資料給硬體裝置(例如：晶片、感測器或硬體模組)。在本說明書中，硬體資料指來自于硬體資源的任一資料，或者是由應用程式設計發展介面所產生給硬體資源的任一資料。舉例來說，使用者可透過智慧型裝置的觸控螢幕或其他輸入方式，將App安裝/執行/運行/操作(下統稱為操作)於智慧型裝置，所謂的其他輸入方式，指可透過驅動程式調用(invoke)對應的硬體裝置的方式。當操作App時，藉由智慧型手機的相機模組而使用相機App，就是一種調用硬體裝置的實施例。在使用者觸碰或按壓快門鍵後，相機App就會指示智慧型裝置的相機模組取得影像(例如產生一個二進位格式影像，諸如raw、jpg、jpeg、png或是其它影像格式)，並且將影像儲存於記憶體中(例如一隨機存取記憶體、一快閃記憶體、一快取、一SD卡或其他儲存空間，例如一雲端)。圖1B為另一種在彩現圖像時調用硬體裝置(例如一顯示裝置或圖形處理單元)的實施例的示意圖。當一個App在執行圖像彩現時，無論應用程式開發者是使用哪種API(或彩現API)，影像會彩現於畫素數據的一緩衝區，稱為「圖層」。傳統上，當App彩現它的內容時，Android的一個圖層會對應於一個離屏緩衝區(off-screen buffer)，而所有在Android平臺所創造的每一個視窗都會被一個圖層所復位(backed)。確切而言，每一個視窗都是一個圖層的顯示結果(形成一視窗的所有畫素會儲存於圖層/緩衝區)。所有可視的圖層經彩現而透過SurfaceFlinger整合於顯示器上，SurfaceFlinger為Android用於管理圖層整合的一種系統服務(或是一種常駐在Android框架的一種全系統圖層整合功能)。SurfaceFlinger自不同App取出資料(也就是圖層)，這些資料可以是二維或三維；其經整合後即取得一主要圖層，用以饋入記憶體(可以包含框架記憶體，或者是設定為包含有一框架記憶體)。此外，SurfaceFlinger也會計算諸如重迭的參數，並調用OpenGL ES。

從一個App的觀點來看，每一個App可對應到至少一個圖形化介面，且每一介面可視為一個擁有其位置、容量大小、內容及其他要素的圖層。參酌Android 3.0的簡介，其對Canvas API的硬體加速是採用了一種被稱OpenGLRenderer的新式繪圖函示庫，該繪圖函示庫可將Canvas的操作轉譯為OpenGL的操作，所以可被執行於圖形化處理單元(例如被硬體加速的Canvas)。現今，支援OpenGL ES 2.0的圖形化處理單元硬體是被託管而供Android裝置執行Android 4.0或其更新版本。Android在android.opengl封包中提供OpenGL ES介面，讓App開發者可利用標準研發套件(SDK)或Android原生研發套件(NDK)所提供的原生API，將的呼叫至開發者的GL實作當中。

如圖1C所示，涉及圖像彩現的元件可包含影像串流產生者(image stream producer)、影像串流消費者(image stream consumer)、一圖層紋理、一視窗管理器(windows manager)、一硬體整合器(hardware composer)以及一Gralloc。影像串流產生器可包含一OpenGL ES遊戲、來自於媒體伺服器的視訊緩衝、一個Canvas二維應用程式，或是任何可將所產生的圖像緩衝消費的其他物件。最常見的影像串流的消費者是SurfaceFlinger，其消費可視圖層，並使用視窗管理器所提供的資訊而將可視圖層整合至一顯示器。其他OpenGL ES App也可消費影像串流，例如，先前所述的相機App可用於消費一相機預覽影像串流。

圖層紋理所包含的邏輯將影像串流產生者與影像串流消費者綁在一起，且其可由三個部分所構成：圖層紋理用戶端(SurfaceTextureClient)、I圖層紋理(ISurfaceTexture)及圖層紋理(SurfaceTexture)(在本實施例中，圖層紋理為C++的實際類別名稱，並非所有組件的名稱)。上述三個部分有助於影像產生者(如圖層紋理用戶端)、合成(binder)(如I圖層紋理)以及影像消費者(如圖層紋理)等圖層紋理構件運行；例如請求自Gralloc(硬體抽象層的一部分)提供記憶體空間、橫跨程式邊界而分享記憶體空間、同步對緩衝區作存取、以及配對合適的消費者與產生者的組合。

圖層紋理可同時在同步與非同步兩模式下操作。在非同步模式中，影像產生者不會被封阻，且影像消費者可拋棄或忽略框架；而在同步模式中，影像產生者可被封阻，以允許影像消費者處理紋理。在一些例子中，影像產生者為透過相機的硬體抽象層所產生的預覽，或者是一種OpenGL ES遊戲。

視窗管理器為一種Android系統服務，用以控制視窗的生命週期、輸入與焦點事件、螢幕導向、轉場、動畫、位置、轉換、Z-階以及視窗的其他許多面向(以一種容器的角度檢視)。一個視窗總是由一個圖層所襯托，視窗管理器會發送所有的視窗中繼資料(metadata)至SurfaceFlinger，SurfaceFlinger因而可採用那些資料以推斷如何整合圖層於顯示器上。

硬體合成器用於對顯示子系統作硬體提取(hardware abstraction)(其也是硬體抽象層的一部分)。SurfaceFlinger可提取如同重迭與二維阻擊器(blitter)，並委派部分整合作業至硬體合成器，以卸載來自於OpenGL與圖形處理單元的作業。這可較使用SurfaceFlinger執行所有任務來得整合迅速。此外，Gralloc會為圖像緩衝器分配記憶體，其分為兩部分：其一提供pmem介面負責連續的記憶體；其二處理框架緩衝區的重整，此框架緩衝區為使用者介面實際上存放框架緩衝資料的位置。SurfaceFlinger執行創建一新顯示硬體的工作，用以建立一本地視窗框架緩衝，而決定資料輸出裝置介面；初始化OpenGL如同合成框架緩衝資料一般；以及經由合併所有圖層而創造主要圖層。

虛擬機器可執行於一種能託管移動App的移動作業系統上。一般而言，運行於移動作業系統的虛擬機器可具有相同或近似於圖1A或圖1B所示的作業系統架構，除非圖1A或圖1B的智慧型裝置被在個人電腦或伺服器所運行的虛擬機器所取代。因此，與硬體資料相關的函式庫或API並未耦接至移動作業系統所支援的真實硬體(例如一圖形處理單元、一相機、感測器或晶片等)。雖然運行於移動作業系統上的虛擬機器可支援多種硬體資源(例如可具有API或對應於硬體的驅動程式)，但因為不是運行在真實、具有物理實體的硬體裝置上，所以它不會收集/接收硬體資料，諸如座標、傾斜角、轉動、震動度、近距、平整度等。在另一個例子中，雖然虛擬機器所運行於的個人電腦/伺服器可具有硬體，例如一圖形處理單元，但移動作業系統中的圖像API或驅動程式可能仍然不會相容於虛擬機器以外的個人電腦/伺服器的硬體。例如用於智慧型手機與伺服器的圖形處理單元可能在規格、驅動程式、所支援的函式庫及/或介面上有差異。虛擬機器所運行於的個人電腦或伺服器的硬體資源，也可能會不同於移動作業系統所被設計運行於的移動裝置，所指的硬體可包含一藍牙、一Wi-Fi、一圖形處理單元、一近場傳輸、一相機、一全球衛星定位系統、一陀螺儀、一電子羅盤、一加速器及其他感測器。

對硬體作限制或是試圖避免缺少實際硬體的情況，可能會對在虛擬機器上運行App產生負面的影響(如圖3A所示的一第二應用程式(下稱為第二App 2))；圖3A至圖4C指出允許移動App與用戶端裝置的作通訊的方法與系統。

圖2A與圖2B揭示基於本發明，使用者介面118、218在一第一應用程式1(下稱為第一App)與一虛擬機器212之間所產生。如圖2A所示，其使用一智慧型裝置(如第一計算裝置100)的一相機(如圖3A、圖3B或圖3C所示的硬體裝置12)擷取一圖片。在本實施例中，第一App 1可被執行於第一計算裝置100，而第二App 2則可執行於運行在第二計算裝置200的虛擬機器212。一使用者可能使用第一App 1接收第二App 2的螢幕畫面(或使用者介面218)，並顯示為第一App 1的螢幕畫面(或使用者介面118)。透過第二App 2的螢幕畫面/使用者介面218而呈現於第一App 1的螢幕畫面/使用者介面118，一使用者可進一步藉由發送使用者觸碰使用者介面118上的一點的座標至一常駐程式(daemon)26而操作第二App 2。該常駐程式26為運行虛擬機器212或是耦接於虛擬機器212的一軟體或一軟體伺服器(請參閱圖2C、圖2D、圖3A、圖3B、圖4A或圖4B)。若常駐程式26並未運行於虛擬機器212而是耦接虛擬機器212，常駐程式26可被執行於第二計算裝置200或是任何在網路上與虛擬機器212耦接的計算裝置。另一實施例中，當使用者觸碰使用者介面118上的一點時，遠端桌面通訊協定也可被應用於產生一觸控事件至第二App 2。

另一實施例中，相機App(第二App 2)可顯示一圖片擷取鍵216於其螢幕畫面/使用者介面218。若使用者經第一App 1遠端操作第二App 2，在第一計算裝置100的第一App 1需要得知使用者介面218的按鍵位置或形狀，以正確顯示於使用者介面118。當相對應的快門鍵116的位置/區域被使用者觸碰/按壓時，第一App 1必須耦接第一計算裝置100的硬體裝置12(如本實施例的相機模組)，以完成圖片擷取程式。確切而言，其可產生一硬體設定，用以選擇一相機API存取第一計算裝置100的相機模組。該硬體設定可包含一參數，例如按鍵216的座標(例如畫素的238、458，皆標示符號於畫素)，以用於在使用者介面118中形成按鍵116。且該硬體設定可被傳送至第一App 1。

接收硬體設定(包含該參數)之後，第一App 1可在螢幕畫面(使用者介面118)上的點(238,458)產生按鍵116並設定為該按鍵允許相機API存取相機模組，以在按鍵116被觸控或按壓時擷取一圖片。

在完成設定硬體設定後(例如依據所接收的硬體設定而設定第一App 1之後)，當一使用者按壓使用者介面118上的按鍵116時，第一App 1會啟動第一計算裝置100的相機模組，以擷取一圖片。接著，該圖片(為一檔案、二進位碼、或其他資料格式)會被傳送至常駐程式26。常駐程式26可用於接收該圖片並將的儲存於記憶體20。其次，第二App 2可自記憶體20取回該圖片並顯示於其螢幕畫面。從第二App 2的視角而言，它接收了一觸控命令並啟動一相機模組；然而，實際上與第二App 2互動的元件可能一設定於存取硬體資料至記憶體20的虛擬相機驅動程式(圖片從第一App 1接收)，或者是一設定於虛擬機器212的硬體設定模組214，以擷取第二App 2的相關於相機API的命令或呼叫。本發明的技術領域的通常知識者應能理解，為了顯示使用者介面118(含按鍵116)，並不一定需要將第二App 2的螢幕畫面(使用者介面218)顯示在虛擬機器212上。在本發明的說明書中，含有按鍵216的第二App 2的螢幕畫面(使用者介面218)可被用於較佳地描述按鍵116與第二App 2之間的關係。而虛擬機器212可產生按鍵116的硬體設定及/或座標，而不需實際地顯示使用者介面218於虛擬機器212或第二計算裝置200的任何顯示裝置上。

圖2B揭示一實施例，其為透過使用一圖形處理單元(其可參照如圖4A與圖4B所示的硬體裝置12或GPU12’)，而在第一計算裝置100上的使用者介面218彩現一圖像226，並且揭示一個相對應的圖像126於使用者介面118以供使用者在遠端操作第二App 2。在本實施例中，第二計算裝置200或虛擬機器212可能沒有圖形處理單元，或是具有圖形處理單元(如圖2C與圖2D所示的一圖形處理單元22)，但來自於虛擬機器212或執行第二App 2的移動作業系統的彩現命令可能不相容於該圖形處理單元。例如：若第二App 2為一Android應用程式，且虛擬機器212被實施作為一種Android虛擬機器，第二App 2會透過函式庫206可產生OpenGL ES命令(例如彩現命令)至圖形處理單元。舉例來說，一EGL/GL介面206g(本發明的實施例中，EGL/GL介面206g可為硬體抽象層208的一部份)或一GLES函式庫(未示於圖中)。然而，由於第二計算裝置200(或伺服器)的圖形處理單元只能接受OpenGL命令而不是OpenGL ES命令，所以OpenGL ES不能直接地指示本地端圖形處理單元彩現圖像。

請參閱圖2C或圖2D，一轉譯器28(可能實施在虛擬機器212或第二計算裝置200上，但位於虛擬機器212外部)可被用於轉譯來自於函式庫206的OpenGL ES命令(該命令可以是自EGL/GL介面206g或libGLES_FIISER.so 206i而被接收/擷取/取回)，而使的變成為OpenGL命令，以供本地端圖形處理單元22依據OpenGL ES命令彩現三維圖像。在一實施例中，圖形處理單元22所彩現的三維圖像可被保存在記憶體20中(部分記憶體20在本實施例中可為框架緩衝區)，且框架緩衝區中的三維圖像可能接續地被常駐程式26所存取，並傳送至第一App 1，且以應用程式串流的形式而顯示在使用者介面118上，或者是顯示於第一App 1的螢幕畫面，如圖2C所示。另一實施例中，彩現的三維圖像可與二維圖像保存於相同位置，例如：在一模組的核心210當中，稱為「/dev/graphics/fb0 210b」。於本實施例中，如圖2D所示，常駐程式26可存取相同位置，以同時串流二維圖像與三維圖像至用戶端。然而，圖2C與圖2D所揭示的實施例在傳送該應用程式串流(包含二維及/或三維圖像)至用戶端時，可能需要更多頻寬。

複參閱圖2B，當彩現第二App 2的一圖像時，一彩現命令可被傳送至第一計算裝置100，並由第一App 1透過網際網路接收。接著，第一App 1會發送彩現命令至本地端(第一計算裝置100)的圖形處裡單元12’(或可轉換彩現命令為相容於本地端圖形處裡單元12’的一格式)，以在一框架緩衝區10’(其可至少為記憶體10的一部份)上彩現對應於該彩現命令的圖像。詳細實施例會在後續實施例中，如圖4A、圖4B、圖4C或圖4D所示，本實施例中，圖像可被顯示在第一計算裝置100。

在一實施例中，彩現命令會與一參數作搭配，例如是待彩現的圖像的記憶體(框架緩衝區)位址/區域、一RGB值、色碼或物件的深度，或者是彩現該圖像的區域/位置/長度/寬度。在另一實施例中，用於彩現圖像的紋理亦可被傳送第一App 1。在Android作業系統中所被命令彩現的圖像/框架，可參考如圖2B-1所示的部分範本，其中的「glBindTexture」可為一彩現命令(在本實施例中，其為一個OpenGL ES命令)，且於第21行的「0x00000de1」與「6」可以為參數。此外，當第二參數「6」可用於指出彩現的一種紋理時，第一參數「0x00000de1」則可用於指出一「目標」。熟悉此技術領域者可知，當彩現一單一圖像、一物件或一框架時，有時需要處理複數個彩現命令(如圖2B-1所示，其可僅執行彩現一圖像/物件/框架)，因此本發明不局限于利用一彩現命令彩現一圖像。

上述與圖2B(及/或圖4A、圖4B或圖4C)相關的實施例中，由於只有彩現命令及/或參數/紋理被傳送至用戶端，所以當彩現第二App 2的整個使用者介面/螢幕畫面于用戶端時，所需要的頻寬較少於圖2C或圖2D所述的實施例。

在一實施例中，彩現命令可能被內含於硬體設定中(其可藉由圖3A或圖3B所示的硬體設定模組214所產生)，或是本身即作為被傳送至第一App 1的硬體設定。於此，當硬體設定(或彩現命令)被接收到時，第一App 1可調度一硬體相關模組(如圖4C所示的彩現模組17’)，以依據該硬體設定(或彩現命令)執行一彩現任務。在本實施例中，為了顯示第二App 2的一螢幕畫面於使用者介面118/第一App 1的螢幕畫面，用於處理複數個彩現命令的硬體相關模組(例如彩現模組17’)需要依據該些彩現命令彩現圖像。

在另一實施例中，當彩現命令產生於一EGL/GL介面206g(或libGLES_FIISER.so 206i)時，硬體設定模組214可被用於產生一硬體設定，並發送該硬體設定與該彩現命令(必要時更包含參數/紋理)至常駐程式26，以傳送至第一App 1。在本實施例中，於接收該硬體設定(及/或參數/紋理)之後，第一App 1會調度一硬體相關模組(如彩現模組17’)耦接至第一計算裝置100的圖形處理單元12’，以處理彩現命令(及/或參數/紋理)。

第一App 1可發送彩現命令(及/或參數/紋理)至其本地端圖形處理單元12’，以彩現圖像126(其相對應于應呈現在第二App 2的使用者介面218的圖像116)。本發明藉由圖形處理單元12’顯示圖像126，不需要彩現於一框架緩衝，或者是在虛擬機器212顯示使用者介面218及圖像226，或者是顯示於第二計算裝置200。

當一使用者與第一計算裝置100的螢幕上的使用者介面118互動(例如觸控智慧型手機的螢幕)時，使用者在螢幕/使用者介面118所觸控的座標可被第一App 1傳送至常駐程式26。在一實施例中，常駐程式26可產生一對應輸入事件至虛擬機器212。在另一實施例中，常駐程式26可發送其接收的座標至虛擬機器212，且一虛擬輸入輸出模組/介面(如圖3A、圖 3B、圖4A或圖4B所示的vr_io_int 210c)可產生一對應輸入事件至第二App 2。在一實施例中，vr_io_int 210c可用於傳送/接收/緩衝一般輸入/輸出至/自第二App 2。此外，一般輸入/輸出可包含一影像、一聲音或其他硬體資料。在另一實施例中，vr_io_int 210c可為一虛擬驅動程式(pseudo driver)。

接著，第二App 2可接收一輸入事件並因此回應該輸入事件(例如基於座標而接收到快門按鍵216被按壓的通知，並使用虛擬機器212的相機API而拍攝圖片)。可因此達成透過第一計算裝置100的第一App 1而遠端操作虛擬機器212/伺服器上的第二App 2。

圖3A揭示了本發明一較佳實施例中，第一App 1與虛擬機器212通訊的系統。如圖3A所示，虛線表示API呼叫/功能呼叫/系統呼叫、命令/指令，及/或參數/數值(例如在JSON或XML架構中)；實線則表示硬體資料的傳輸，例如圖片或其他種硬體資料(可以是一檔案、二進位碼，以及/或來自硬體裝置12或第一App 1的JSON/XML架構中的數值/資料)。在本實施例中，為了在用戶端配置按鍵116而產生硬體資料及/或參數/紋理，虛擬機器212或硬體設定模組214首先需要知道按鍵216在第二App 2的螢幕畫面/使用者介面218(所以導致第一App 1設定按鍵116於第一App 1的螢幕畫面/使用者介面118)顯示時，按鍵216所在位置的相關座標範圍。

在一實施例中，前述的位置(以座標表示)可先經分析第二App 2而得知。例如：假設第二App 2為一Android App，當第二App 2被一分析器(未示於圖中)所分析時，第二App 2所使用的佈局或API相關的編碼可自第二App 2的一應用程式封裝檔案(apk)擷取/讀取。該分析器可以是用於將第二App 2的應用程式封裝檔案作拆解/回復/解碼/解壓縮的程式。應用程式封裝檔案的分析器的範本可參考Android-Apktool(參閱https：//code.google.com/p/android-apktool/)。舉例而言，一個AndroidManifest.xml檔案可表示所需要執行第二App 2所需要的活動、意圖篩檢程式(intent filters)、硬體裝置或API的數量。或者，按鍵216的位置可由第二App 2的應用程式封裝檔案的編碼得知。與第二App 2相關的硬體設定可因此先行產生(例如在進行分析之後，以及使用者于用戶端而遠端起動第二App 2之前時間點)。一旦第二App 2被啟動，硬體設定(必要時一併與參數/座標)可被傳送至第一App 1。

於接收硬體設定之後設定視野/觸控區域並耦接對應硬體裝置

在另一實施例中，當一使用者透過第一App 1於使用者介面118/螢幕畫面所呈現的應用程式串流而操作第二App時，硬體設定可動態地產生。最初，使用者可透過第一計算裝置100的第一App 1啟動一程式，以在虛擬機器212操作第二App 2。使用者可觸控第一計算裝置100的螢幕，而這會產生一輸入事件(例如一觸控事件)，例如：「TOUCH(238,458)」，表示在第一計算裝置100所顯示的一螢幕畫面畫素中，使用者所觸控的一點(或一座標)的地址(238,458)。舉例而言，在解析度480x800的一佈局/螢幕畫面中，該點/座標(238,458)意思是位於第238列第458欄的畫素，用以代表一個相對應的參考點，例如是第一App 1活動時所顯示的一左上對齊畫素的視窗中的一點。在一實施例中，該觸控事件被傳送至第二計算裝置200(經由或藉由常駐程式26的協助)，以作為第二App 2的一輸入。而在另一實施例中，第一App 1可僅傳送該座標至常駐程式26。常駐程式26可隨後發送座標至vr_io_int 210c，且vr_io_int 210c可產生一相關於第二App 2的使用者介面218的座標(238,458)的輸入事件(例如一觸控事件)，並發送至第二App 2。

於另一實施例中，在接收該觸控事件之後，第二App 2可視的為一個在使用者介面218上的該座標(如點(238,458))的活動的輸入事件。熟悉本發明技術領域者可知，因虛擬機器212與第一計算裝置100的螢幕解析度與尺寸可能不盡相同，所以在虛擬機器212與第一計算裝置100對於輸入事件的相關座標並不必然相同。然而，兩者的觸控事件於螢幕上的相對位置應相同。舉例而言，第一計算裝置100可以是一平板電腦，但虛擬機器212則是模擬為具有不同螢幕解析度的智慧型手機。於此，平板電腦的解析度可為「2048 x 1536畫素」，而虛擬機器212或第二App 2的使用者介面218則僅有「480 x 800畫素」。範例中的使用者介面之間若具有不同解析度，本發明僅需對任一作轉換即可。

接著，第二App 2可如同使用者直接觸相對應於使用者介面218上的(238,458)的一點，而回應該觸控事件。在一實施例中，該點(238,458)可位於使用者介面218上的快門按鍵216的一範圍內，且第二App 2可在接收該觸控事件後使用一第二相機API(未示於圖中)。由於虛擬機器212並沒有一相機模組(或是相關硬體裝置)，硬體設定模組214可用於在呼叫被發送至虛擬機器212的一相機驅動程式(例如本實施例中的一驅動程式211或一虛擬相機驅動程式)的時候或是之前，將該呼叫攔截。硬體設定模組214可產生一硬體設定(例如一數值或一數值集合)，用以調度硬體相關模組 17(如第3G圖所示)，以使用位於第一計算裝置100的一第一相機API(未示於圖中)。該硬體設定可藉由常駐程式26而透過網際網路(例如透過HTTP協議)傳送至第一App 1。

在一實施例中，傳送一對座標與硬體設定可用於在第一App 1的螢幕畫面/使用者介面118配置矩形區域(例如快門按鍵116)，例如透過該對座標，可用於配置一區域的左上以及右下的點位置。第一App1可依據所接收的硬體設定，而將該區域耦接于相對應的API(或硬體裝置)，或是耦接於第一計算裝置100的一相機(例如硬體裝置12)。在另一實施例中，由於第一App 1可用於產生具有預設的尺寸/區域/形狀(一旦接收硬體設定與一座標時，就產生預設的尺寸/區域/形狀)的按鍵116，因此並不一定需要將該對座標回傳至第一App1，且其可僅在用戶觸控的座標位置配置預設尺寸/形狀的區域。

請參閱圖3A，第一App 1經該第一相機API(例如啟動一第一相機驅動程式，也就是第一計算裝置100的一驅動程式111)而使用一相機(硬體裝置12)取得一相片或一二進位影像(即硬體資料，例如二進位碼、檔案值或資料)。該圖片可被發送至記憶體10或其他儲存裝置(未示於圖中)，且第一App 1可存取記憶體10或儲存裝置而取得該圖片。接著，第一App 1可傳送硬體資料(即相片/影像)至常駐程式26，且硬體資料可被保存在記憶體20。此外，第一App 1亦會將硬體裝置12已成功取得圖片的結果通知虛擬機器212(通過常駐程式26)。接收通知之後，第二App 2可存取記憶體20，也就是第二App 2會使用圖片(也就是說，將圖片顯示於使用者介面218上，或是將圖片包含在第二App2的螢幕畫面)。在本實施例中，此程式會視為是第二App 2使用第二相機API存取該圖片。

熟知本發明技術領域者可知，雖然前述實施例所揭示的常駐程式26位於第二計算裝置200，常駐程式26亦可實施於耦接在第二計算裝置200的計算裝置/伺服器。且熟知本發明技術領域者亦可知，常駐程式26亦可實施于本發明的虛擬機器212中(例如近似於圖4B所示的函式庫206)。

請參閱圖3B，從第一App 1取得並傳送硬體資料至虛擬機器212或第二App 2的系統與方法會近似圖3A所揭示的實施例，除了其中的常駐程式可用於直接地傳送硬體資料(例如圖片)至虛擬機器212(硬體資料不會先保存在記憶體20中)，且虛擬機器212可利用如驅動程式211或硬體抽象層208而用於接收硬體資料。在本實施例中，因為硬體資料是以類似的方式作接收(該硬體資料來自於硬體抽象層208或驅動程式211)，因此，當從用戶端接收圖片(硬體資料)時，第二App 2可能不會辨別其執行於具有一相機模組(硬體裝置)的真實智慧型裝置以及虛擬機器212之間的差異。在一實施例中，驅動程式211(例如一種用於耦接相機API的相機驅動程式)可用於直接從網際網路(也就是由常駐程式26的協助)而「取得(或接收)」該硬體資料，而不是從任何硬體裝置接收資料；並且將的傳送至第二App 2或儲存該硬體資料至記憶體20中，以供第二App 2存取。

在另一實施例中，硬體抽象層208可會直接地從網際網路(也就是藉由常駐程式26的協助)接收硬體資料(圖片)，並傳送至第二App2或儲存於記憶體20，以供第二App 2存取。在本實施例中，虛擬機器212可不包含驅動程式211(因為硬體資料是直接地被傳送至硬體抽象層208並藉由硬體抽象層208傳送至第二App 2，所以虛擬驅動程式211為選擇性的)，或驅動程式211可以僅是一個虛擬驅動程式而無如同驅動程式111的功能。

一併與參數接收的硬體設定

在一實施例中，當所產生的視圖(view)尺寸為固定時，可透過參數中的座標而指定一視圖的中心(如按鍵116的中心)。在另一實施例中，一對座標(如(230,450)與(255,470))也可用以指定為分別是視野的左上角至右下角的位置，並依據該座標而在第一App 1的使用者介面118產生此視圖。

在一實施例中，參數可包含一標籤。本實施例中，本發明的方法可進一步包含接收相對應於一視圖處理事件的該標籤(如<button>)的步驟；其中，視圖所處理的事件是相同或近似於第二App 2的視圖(例如按鍵216)，且該視圖會被配置為具有相對應於該標籤的功能。

在一實施例中，對應至按鍵的使用者介面/佈局的一視圖可由Arowser^TM於本地端產生，因此視圖的解析度可被固定。然而，使用者介面118的含狀態傳輸(rest)或第一App 1的螢幕畫面(或顯示於第一計算裝置100的螢幕上的物件)可包含來自於第二計算裝置200(或虛擬機器212)的應用程式串流。因此，解析度可被調整或自我調整於網路狀態。例如，網路速度快時，解析度變1080P，而網路速度慢時，解析度轉變為360P。

Arowser ^TM ：接收硬體設定後，調度相對應的硬體裝置

傳統上，無論是iOS、Android或Windows，一使用者介面或一App(特別是原生App)的一功能/移動/視圖的佈局中的元件及其對應位置會被App開發者固定。舉例而言：一開發者可程式設計代表一App的使用者介面上的一按鍵的視圖，並賦予一功能至該按鍵，讓使用者可以透過該按鍵而發送資料或選擇/確認特定狀態。在Android系統中，有一種公開的類別為「視圖」，供使用者介面元件用以表示基本的構成方塊(通常一個視圖會佔用螢幕畫面的一個矩形區域，並負責繪圖與事件的處理)。然而，由於使用者可使用Arowser^TM操作多種位於遠端虛擬機器(如虛擬機器212)的App，導致「視圖」可能不適用於Arowser^TM。如果Arowser^TM僅可提供一個固定的使用者介面，用以顯示App串流(例如包含在遠端的虛擬機器執行的一些應用程式作至少一快照(snapshots)，或部分/全縮時(full time-lapsed)視覺輸出，可參考美國臨時申請案第61951548號所揭示)，將無法透過相對應的API而耦接不同硬體的不同App，而無法作為一種一應俱全的應用程式。舉例而言：第一App 1為Arowser^TM或是包含有Arowser^TM的應用程式，而當一使用者透過Arowser^TM操作執行於虛擬機器212上的一導航App，由於該導航App執行於虛擬機器(通常運行於一伺服器或一個人電腦)而並未直接地耦接於一真實的全球衛星定位系統/輔助全球衛星定位系統模組(也就是說，虛擬機器212可能不包含/連接于任何全球衛星定位系統/輔助全球衛星定位系統模組)，若Arowser^TM沒有被用於表現定位和導航的功能，用戶端所接收的定位訊號(GPS signal)可能就不能被傳送至導航應用程式(例如Android應用程式的開發者為了載入在android.location封包中一個被稱為「GpsSatellite」的類別，以在包裝應用程式封包檔案(例如Android的一個apk檔案)之前取得座標，因此需要額外插入一行編碼，藉此設計一個地圖使用者介面及/或一定位按鍵耦接該應用程式設計發展介面)。

由於使用者行為不同，且App之間也是具有不同的特色並需要使用到不同硬體，因此開發一應俱全的App相當困難。本發明可將這些挑戰透過載入複數個預設的類別而將的作分類；例如：Arowser^TM(第一App 1)可在接收任何硬體設定之前耦接於複數驅動程式，並隨後依據硬體設定而自所選擇的驅動程式當中，將相關的硬體資料傳輸至第二運算裝置200。在另一實施例中，當Arowser^TM接收到硬體設定時，Arowser^TM可動態地設定本身，以載入多種類別或是耦接同一用戶端的多種硬體裝置。舉例而言：所述的設定可包含有一程式依據該硬體作實行，以載入對應類別的(或複數類別)。如圖3C所示，其表示圖3A或圖3B的第一應用程式的詳細示意。請參閱圖3C，第一App 1可包含一接收器13、一調度器15與複數硬體相關模組17。接收器13可用于接收來自於虛擬機器212並關聯於第二App 2的硬體設定。該些硬體相關模組17可用於接收來自用戶端(也就是本實施例的第一計算裝置100)的至少一驅動程式(如驅動程式111)的硬體資料。在一實施例中，該些硬體相關模組17可被用以自硬體裝置12接收硬體資料(或以下圖4A與圖4B所示的實施例所述的硬體裝置12’)。硬體裝置12/12’可包含一藍牙單元、一Wi-Fi單元、一近場傳輸單元、一相機、一圖形處理單元、一全球衛星定位系統、一陀螺儀、一加速器、一熱度計、一磁力儀、一電子羅盤(e-compass)、一氣壓錶(barometer)、一距離感測器(proximity sensor)、一濕度計、一聲音/音效/麥克風與一影像感測器。在一實施例中，硬體資料可包含但不限定於加速度(m/s²)、環境溫度(℃)、重力加速度(m/s²)、轉速(rad/s)、環境亮度(lux)、環境大氣壓力(hPa或mbar)、物件相對於裝置畫面的距離(cm)、相對環境濕度(%)、定位(GPS/AGPS模組)、近場傳輸、聲音/音效/麥克風、影像感測器及/或影像/圖像的相關的數值/資料/檔案。

在一實施例中，任一該些硬體相關模組17可用於耦接上述的硬體裝置其中的一者，並接收相對應的硬體資料。此外，調度器15可用于調度該些硬體相關模組17其中的一者，以自與該硬體設定相對應的一驅動程式(也就是驅動程式111)接收硬體資料。

在一實施例中，第一App 1可更包含一傳輸器19，該傳輸器19可用於自驅動程式(驅動程式111)傳輸硬體資料至虛擬機器212。

在另一實施例中，第一App 1可用於在第一計算裝置100的螢幕上產生使用者介面118，且一互動區域可被配置於第一App 1的螢幕畫面上。在本實施例中，當互動區域活動(例如使用者觸碰或敲擊，或是透過滑鼠指標點擊)時，傳輸器19可用於傳輸其所接收的硬體資料至常駐程式26(或虛擬機器212)。

在另一實施例中，一緩衝模組(未示於圖中)耦接傳輸器19，其可在沒有網路服務時，用於緩衝硬體資料於用戶端(第一計算裝置100)的儲存單元(未示於圖中，例如一SD記憶卡)或記憶體(例如記憶體10或其他記憶體)。在本實施例中，傳輸器19可在網路恢復後傳送硬體資料至常駐程式26(或虛擬機器212)。

本發明中，硬體設定為提供App或API指示，為了獲取硬體資料而指示App或API存取哪個硬體裝置。在一實施例中，一個硬體設定可為一數值或一數值集合，用以在透過第一App 1操作虛擬機器212上的第二App 2時，分配所需要的硬體裝置。若第一計算裝置100有八個感測器/硬體裝置，硬體設定則可包含八位(每一者具有「0」或「1」的數值)，以表示第二App 2的硬體/硬體資料的需求。一個硬體設定若為(0,1,1,0,0,0,0,0)，其意思可為需要第二與第三硬體的硬體資料，並因此該些資料應該被取得並從第一計算裝置100導入虛擬機器212。在另一實施例中，由於硬體相關模組17含有一方法/類別/API，或是可接收一硬體資料，因此第一App 1可在接收一硬體設定之後，使用一對應的方法/類別/API應用於該硬體資料。又於一實施例中，一硬體設定可包含有一JSON檔案，該JSON檔案具有一名稱及/或方法/類別/API的參數，以指定在透過遠端使用第一App 1操作第二App 2時，第一App 1接收相對應的硬體資料。

Arowser ^TM ：于遠程透過Arowser ^TM 產生輸入事件

Arowser^TM(如第一App 1)可顯示含有按鍵116的第二App 2的應用程式串流。在本實施例中，當使用者想要透過Arowser^TM(或是當應用程式串流顯示於使用者介面118或第一計算裝置100的螢幕上時，透過第二App 2的使用者介面顯示)拍攝圖片時，他/她可觸碰按鍵116，且觸控事件會轉傳送至常駐程式26或虛擬機器212，並被輸入至第二App 2。接著，第二App 2可依據觸控事件啟動相對應的活動，並且可使用相關的API(也就是本實施例的虛擬機器212的相機API)達成動作。在本實施例中，虛擬機器212可得知第二App 2想要使用相機拍攝圖片；同時，第一App 1會啟動拍攝的活動，且第一計算裝置100的硬體裝置12(相機模組)可拍攝一圖片並存入第一計算裝置100的記憶體10或其他儲存裝置(未示於圖中)中。第一App 1會傳送該圖片至硬體抽象層208或記憶體20(例如透過常駐程式26)，且相片可利用第二App 2所啟動的活動而呈現。在本實施例中，觸控事件可直接被輸入至第二App 2以處理硬體相關活動，而不是透過使用者於用戶端所觸控的座標。

於用戶端彩現圖像

請參閱圖4A或圖4B，其所揭示的系統為供第一App 1與伺服器或虛擬機器212通訊而得以使用用戶端的硬體設備(也就是硬體裝置12或圖形處理單元12’)彩現伺服器或虛擬機器212上的第二App 2的圖像。請參閱圖4A(並請一併參閱圖1B)，如原生Android作業系統運行於第一計算裝置100時，一彩現驅動程式及/或介面可表示為：也就是一驅動程式111’及/或「libGLES_GPUNAME.so」(「.so」的命名可依不同的智慧型裝置而不同)106i，其驅動圖形處理單元12’依據彩現命令(如OpenGL ES命令)而彩現圖像，以供在Android作業系統運行上執行的一App使用(也就是利用本地端圖形處理單元進行彩現)。然而，由於第二計算裝置200可能沒有圖形處理單元能用以理解第二計算裝置200(或虛擬機器212)所產生的彩現命令(如OpenGL ES命令)，因此一個libGLES_FIISER.so 206i即可用於取代彩現驅動程式的角色，且由於本地端圖形處理單元不存在或不相容於彩現，因此libGLES_FIISER.so 206i可直接導向常駐程式26傳送彩現命令至第一App 1(透過網際網路)，而不是傳送彩現命令至本地端圖形處理單元。

請參閱圖4A，一彩現命令(如一OpenGL ES命令)可在EGL/GL介面206g或libGLES_FIISER.so 206i被擷取/截取/讀取/接收。在一實施例中，對應於該彩現命令的一參數及/或紋理可為在EGL/GL介面206g或libGLES_FIISER.so 206i被擷取/截取/讀取/接收。熟知本發明技術領域者可知，彩現命令或參數/紋理可自第二App 2、其他部分的函式庫206(例如當第二App 2使用如OpenGL API以繪畫或控制圖像中的物件)或其他部份的核心210而被擷取/截取/讀取/接收。本發明的申請專利範圍所主張的架構不限於彩現命令及/或參數/紋理被擷取/截取/讀取/接收的位置。

彩現命令及/或參數/紋理可被發送至常駐程式26，且常駐程式26可用以傳送此一命令至第一App 1。請參考圖4B，第一App 1與伺服器(第二計算裝置200或虛擬機器212)的通訊系統除了常駐程式26可設置於虛擬機器212，其餘近似於上述圖4A的實施例。在一實施例中，常駐程式26可被配置於函式庫206。在另一實施例中，常駐程式26可被配置於核心210。熟知本發明技術領域者可知，常駐程式26可被配置於第二計算裝置200中，或是其他耦接至虛擬機器212的計算裝置(如伺服器或雲端)，以接收彩現命令及/或使vr_io_int 210c與第一App 1進行通訊。

接收彩現命令及/或參數/紋理之後，第一App 1可發送此一命令至EGL/GL介面106g(及/或libGLES_GPUNAME.so 106i)，或是發送至驅動程式111’，以利用圖形處理單元12’彩現圖像。熟知本發明技術領域者可知，Android系統的外的App或移動作業系統可能沒有如同EGL/GL介面106g的介面，但有驅動用戶端的圖形處理單元的一函式庫或一驅動程式可實現本發明，因此本發明不局限於僅透過EGL/GL介面106g彩現圖像。

請參閱圖4C，其為第一App 1與第二計算裝置200或虛擬機器212基於本發明一實施例的通訊架構。請參閱圖4C，其近似於圖3C，第一App 1可包含接收器13、調度器15、傳輸器19以及複數個硬體相關模組17，其中該複數硬體相關模組17的其中一者為一彩現模組17’。接收器13可用於透過網際網路接收彩現命令(如OpenGL ES命令)及/或參數/紋理。同理，調度器15用於調度硬體相關模組17的其中一者(如本實施例的彩現模組17’)，以依據所接收的彩現命令而彩現圖像。彩現模組17’可用於繪製(map)來自於常駐程式26至一API呼叫的彩現命令，並且產生一個繪製的API呼叫以使用彩現API(如OpenGL ES 1.0/1.1 API封包、OpenGL ES 2.0 API封包與OpenGL ES 3.0/3.1 API封包)作圖像彩現。換言之，彩現模組17’可被用於結合使用彩現API及複數個API呼叫，且任一API呼叫可與特定的彩現命令(接收自常駐程式26)相對應。在本實施例中，一個與來自常駐程式26的彩現命令為相同或近似的新的彩現命令(必要時搭配參數及/或紋理)可在彩現模組17’基於其所接收的彩現命令而選擇彩現呼叫/API之後於用戶端被產生。產生於用戶端的彩現命令可傳送至驅動程式111’(若第一App 1為Android App或移動作業系統為Android，則可透過例如EGL/GL介面106g及/或libGLES_GPUNAME.so 106i等)以驅動該硬體裝置，例如本地端的圖形處理單元12’以彩現圖像。在本實施例中，一旦接收到來自於常駐程式26的一彩現命令，彩現模組17’可據此選擇用戶端的一彩現API，並使用該彩現API而透過第一計算裝置100的圖形處理單元12’彩現圖像。

圖4D揭示了在本發明的一實施例中，第一App 1’通訊連接於第二計算裝置200(伺服器)或虛擬機器212。請參閱圖4D，第一App 1’可包含接收器13’用於自常駐程式26接收彩現命令。在一實施例中，第一App 1’或接收器13’可包含一原生編碼函式庫(或複數個原生編碼函式庫)，以調度EGL/GL介面106g或libGLES_GPUNAME.so 106i的一彩現方法/應用程式設計發展介面而彩現圖像。在本實施例中，第一App 1’(或接收器13’)會在接收來自於常駐程式26的彩現命令之後，傳送彩現命令至驅動程式111’(如透過EGL/GL介面106g或libGLES_GPUNAME.so 106i)，且該圖像可藉由圖形處理單元12’而依據此彩現命令進行彩現。第一App 1’(接收器13’或原生編碼函式庫)可包含有一調度器(未示於圖4D)，用以依據彩現命令而調度對應的部分EGL/GL介面106g，相關于調度器的原始碼範例如下：……(於此及以下的「……」指部分的原始碼可被忽視)bool init_gl2_dispatch() { const char*libName= getenv(〞ANDROID_GLESv2_LIB〞)； if(！libName)libName=DEFAULT_GLES_V2_LIB； // //Load the GLES library s_gles2_lib= osUtils：：dynLibrary：：open(libName)； if(！s_gles2_lib)return false； // //init the GLES dispatch table s_gl2.initDispatchByName(gl2_dispatch_get_proc_func,NULL)； s_gl2_enabled=true； return true； } void*gl2_dispatch_get_proc_func(const char*name, void*userData) { if(！s_gles2_lib){ return NULL； } return(void*)s_gles2_lib->findSymbol(name)； } ……

在一實施例中，一個為調度之用的原始碼範本對應的部分的EGL/GL介面106g，以依據一彩現命令彩現一圖像(或部分圖像)，例如：“glBindTexture,”可為如下：…… size_t gl2_decoder_context_t：：decode(void*buf, size_t len,IOStream*stream) { size_t pos=0； if(len<8)return pos； unsigned char*ptr=(unsigned char*)buf； bool unknownOpcode=false； …… break； case OP_glBindTexture： { this->glBindTexture(＊(GLenum＊)(ptr+8),＊(GLuint＊)(ptr+8+4))；pos+=＊(int＊)(ptr+4)； ptr+=＊(int＊)(ptr+4)； } ……

在這實施例中，彩現命令(如「glBindTexture」)、與目標相關的參數(也就是「＊(GLenum＊)(ptr+8))，其可被定位於目標可以在框架緩衝區或記憶體10中被存取的位置)或與紋理相關(也就是「＊(GLunit＊)(ptr+8+4),」，其也可被定位於目標可以在框架緩衝區或記憶體10中被存取的位置)可被調度並接著被傳送至EGL/GL介面106g，用於彩現圖像。

在一實施例中，原生編碼函式庫可藉由使用Android原生開發套件而推行/執行於第一App 1’的應用程式封包檔案(.apk)。在另一實施例中，原生編碼函式庫可推行/執行于另一應用程式封包檔案(以下稱原生編碼函式庫apk)，且一含有原生編碼函式庫的應用程式(下稱原生編碼函式庫app)可在應用程式封包檔案安裝於第一計算裝置100後形成於第一計算裝置100上。在本實施例中，如果兩個應用程式封包皆安裝於第一計算裝置100，第一App 1會接收彩現命令並傳送至原生編碼函式庫app(例如透過第一App 1與原生編碼函式庫app之間的一跨程式通訊或其他通訊)。接著，原生編碼函式庫app會傳送彩現命令至EGL/GL介面106g，以利用圖形處理單元12’進行彩現，因此，熟知本發明技術領域者可知，原生編碼函式庫並不局限於推行/執行於第一App 1’的應用程式封包檔案。

同理，一旦接收觸控螢幕事件，第一App 1(或1’)可傳送觸控螢幕事件的座標(或直接傳送觸控螢幕事件)至常駐程式26，且第二App 2可透過一虛擬輸入輸出模組/介面(如vr_io_int 210c)而依據觸控螢幕事件作回應。

在一實施例中，第一App 1(或1’)可進一步包含有一顯示圖像於第一App 1(或1’)的螢幕畫面的活動。

在一實施例中，彩現的圖像的畫素可儲存於框架緩衝10’(或記憶體10)。

在一實施例中，當第二App 2使用於伺服器或虛擬機器212上的彩現API用於彩現圖像時，可讀取/擷取至少一彩現命令、參數及/或紋理。

此外，傳送器19可用于傳送來自於常駐程式26的一輸入事件(如觸控螢幕事件)的一座標，其為第一App 1所接收。

此外，熟知本發明技術領域者可知，第二計算裝置200或伺服器可執行為一可運行移動作業系統(例如Android作業系統)的計算裝置。在本實施例中，上述的移動作業系統的驅動程式或函式庫可運行於第二計算裝置200中，所以虛擬機器212可能非為必要。

第5A圖所示的流程圖系揭示本發明的第一App 1通訊連接於伺服器(例如第二計算裝置200及或常駐程式26)或虛擬機器212。在本實施例中，該方法相關於設定一互動區域116於顯示在第一計算裝置100(用戶端)上的一螢幕畫面上，其中由執行於第二計算裝置200的第二App 2產生該螢幕畫面，而從第二計算裝置200串流至第一計算裝置100並顯示。請參閱第5A圖，於步驟602中，第一App 1的接收器13接收來自於第二計算裝置 200(或虛擬機器212)的一座標與一硬體設定。於步驟604中，第一App 1配置第一計算裝置螢幕畫面上對應所接收的座標的一點，以形成一互動區域116。于步驟606中，調度器15可調度一個功能/方法，包含但不限制于一個相對應於接收硬體設定的互動區域116的硬體相關模組17。當互動區域116活動時，被調度的硬體相關模組17可執行一功能。

在一實施例中，相關於第一App 1的硬體設定用以拍攝圖片，因此，互動區域116可被設定為一快門按鍵，且當該互動區域116活動(按壓快門按鍵)時產生圖片(硬體資料)，以及將的傳送至第二計算裝置200/伺服器(或虛擬機器212或第二App 2)。

在另一實施例中，該功能或方法可包含接收硬體資料自一藍牙、一Wi-Fi、一近場傳輸、一相機、一全球衛星定位系統、一陀螺儀、一電子羅盤及一加速器的。此外，步驟608可更包含有在互動區域116活動時傳送相關於功能的硬體資料至虛擬機器212。

在一實施例中，虛擬機器212可傳送不同硬體設定至用戶端。

在一實施例中，該用戶端(如第一計算裝置100)可包含有複數功能，且至少有一功能可依據所接收的硬體設定而調度至互動區域116。

在一實施例中，來自於伺服器的至少一個座標以及硬體設定透過網際網路傳送。

在一實施例中，本發明的方法可更包含接收一數值，以設定互動區域116的一長度或一寬度，並依據該數值設定互動區域116具有該長度或該寬度。

在一實施例中，本發明的方法可更包含在第一App 1的螢幕畫面形成互動區域116時或之前接收一廣告的步驟。由於發送觸控事件、接收座標與硬體設定，並完成該互動區域的設定會花費時間，這段時間可用於顯示廣告。

第5B圖揭示了本發明一實施例中，第一App 1與伺服器或虛擬機器212通訊連接的方法。在本實施例中，此方法是關於從第一計算裝置100(用戶端)的驅動程式111傳送硬體資料至伺服器或虛擬機器212。請參閱第5B圖，在步驟610中，第一App 1可耦接於執行第二App 2的伺服器或虛擬機器212。於步驟612中，接收器13可自伺服器或虛擬機器212接收相關於第二App 2的硬體設定。依據此硬體設定，一調度器15可調度第一App 1的一功能，例如複數硬體功能模組17的其中一者，以在步驟614中接收驅動程式111的硬體資料。在本實施例中，第一App 1的功能可為耦接驅動程式111以自該接收驅動程式111的硬體資料。此外，傳輸器19可在步驟616中傳送所接收的硬體資料至伺服器或虛擬機器212。

在一實施例中，第一App 1含有複數功能(相關於硬體相關模組17)，每一者都可用於接收用戶端的複數個硬體資料。此外，每一功能可耦接用戶端的複數驅動程式，以接收硬體資料。本實施例中，該些驅動程式可包含第一計算裝置100(用戶端)的一藍牙、一Wi-Fi、一近場傳輸、一相機、一全球衛星定位系統、一陀螺儀、一電子羅盤及一加速器，而所述的功能可為經藍牙、Wi-Fi、一近場傳輸、一相機、全球衛星定位系統、一陀螺儀、一電子羅盤及加速器而接收硬體資料。

本實施例中，調度器15可依據所接收的硬體設定，而從第一App 1的複數功能中選擇其一。

在一實施例中，本發明的方法可更包含配置一互動區域116於第一App 1(顯示於用戶端)的螢幕畫面上的步驟，並在互動區域116活動時，傳送所接收的硬體資料至伺服器或虛擬機器212。

在一實施例中，本發明的方法更包含在網路中斷時緩衝硬體資料(圖未示使用緩衝模組)的步驟，以及在網路回復時傳送硬體資料至伺服器或虛擬機器212(如利用傳送器19)的步驟。

第5C圖揭示了本發明另一實施例中，第一App 1與伺服器或虛擬機器212通訊連接的方法。在本實施例中，該方法關聯于利用用戶端的第一App 1’彩現第二App 2的一圖像，該第二App 2執行於伺服器或虛擬機器212。如第5C圖所示，於步驟628中，接收器13’接收至少一彩現命令(如一OpenGL ES命令)、一對應參數(如RGB數值/色碼、深度等)及/或一該伺服器(如第二計算裝置200、虛擬機器212或常駐程式26)的紋理；於步驟630中，接收器13’可傳送彩現命令、參數及/或紋理至用戶端的驅動程式111’，以利用圖形處理單元12’彩現圖像。

在一實施例中，彩現命令、參數及/或紋理截取自虛擬機器212並透過網際網路傳送至第一App 1’。另一實施例中，可在傳送彩現命令至函式庫206i或虛擬驅動程式(並未圖示但耦接函式庫206i)之前封阻彩現命令及/或參數。又一實施例中，可在虛擬機器212外封阻彩現命令及/或參數，但這仍是在伺服器內進行封阻。例如，若伺服器包含一圖形處理單元，則可在發送彩現命令及/或參數至圖形處理單元之前截取彩現命令及/或參數。

在一實施例中，第一App 1’可更包含有彩現模組17’。彩現模組17’可為一功能或一彩現方法。彩現模組17’亦可為一個由C或C++所編寫的原生編碼函式庫，並可編譯成.so檔案而封裝至第一App 1’的應用程式封包檔案中，以依據接收器13’所接收到的彩現命令而調度部分彩現介面(如EGL/GL介面106g)驅動圖形處理單元12’作圖像彩現。本實施例中，彩現模組17’亦可為複數個硬體相關模組17的其中一者。另一實施例中，第一App 1’可進一步包含有複數個硬體相關模組17與調度器15，以在接收到彩現命令時，調度器15用於從複數個硬體相關模組17中調度出彩現模組17’。

在一實施例中，彩現模組17’可使用用戶端的一彩現API(如OpenGL ES API)，以依據彩現命令彩現圖像。

彩現命令及/或參數/紋理可被傳送至驅動程式111’，且驅動程式111’可驅動圖形處理單元12’以依據此一命令彩現圖像。在一實施例中，該圖像先儲存於框架緩衝區10’，然後顯示於一顯示裝置(圖未與第一計算裝置100表示，但可為一積體電路或一般電路，以控制第一計算裝置100的螢幕)。在本實施例中，該方法可更包含有顯示用戶端的一螢幕畫面的步驟，其中該螢幕畫面含有彩現的圖像。

於另一實施例，一種相關於彩現命令或參數的紋理可從伺服器發送，且接收器13’可接收來自於該伺服器的此紋理。本實施例中，調度彩現方法可使用用戶端的一彩現API，以依據彩現命令搭配至少一對應參數與紋理而彩現圖像。

在一實施例中，可在第二App 2嘗試使用虛擬機器212的一彩現API(例如透過EGL/GL介面206g)以彩現圖像時，取回至少一彩現命令與對應參數。另一實施例中，除了彩現命令以及相對應的參數以外，紋理也可在第二App 2使用彩現API時被取回。

在一實施例中，虛擬機器212可耦接至常駐程式26。本實施例中，一旦一使用者觸碰使用者介面118或第一App 1的螢幕畫面(其可能包含彩現圖像)的一點時，對應觸碰點的一座標會被傳送至常駐程式26。接著，關聯於座標的一輸入事件可被產生並被輸入至第二App 2。

Arowser ^TM ：在配置本身時顯示廣告

Arowser^TM(如第一App 1)可在接收硬體設定及/或參數/座標時對其本身進行配置。然而這過程會花費時間。舉例而言，一使用者觸碰第一計算裝置100的螢幕而經第一App 1(Arowser^TM)的使用者介面118產生一觸控事件時，發送使用者觸碰點的座標至伺服器，而依據該座標產生一觸控事件並輸入至第二App 2(其可由常駐程式26所完成)，接著在第二App 2使用API及/或座標而配置一觸控區域後產生一硬體設定，其次發送該硬體設定(及/或該座標)回到第一App 1，然後由第一App 1配置其本身。在執行上述步驟時所需的時間當中，Arowser^TM可在使用者等待的過程顯示一廣告(例如In-App Ad)於使用者介面118。

本發明的另一實施例中，可在Arowser^TM活動時完成產生硬體設定及/或設定Arowser^TM，例如在顯示啟動畫面/頁面的期間顯示廣告給使用者。

在一實施例中，接收第一App 1(Arowser^TM)的廣告的方法可包含步驟：傳送被觸碰的第一App 1的使用者介面118的一第一座標至虛擬機器212；自虛擬機器212或常駐程式26接收一硬體設定(及/或一第二座標)；以及在第一App 1耦接一對應硬體裝置12(或依據第二座標形成一觸控區域，其中該觸控區域可啟動一活動，例如拍照)時或之前，接收廣告。

惟以上所述者，僅為本發明的較佳實施例而已，並非用來限定本發明實施的範圍，舉凡依本發明申請專利範圍所述的形狀、構造、特徵及精神所為的均等變化與修飾，均應包括于本發明的申請專利範圍內。

此外，描述本發明的實施例的過程中，本說明書呈現本發明方法和/或過程步驟的特定順序。然而，該方法或過程並不依賴本文所闡述步驟的特定順序，該方法或過程不應限於描述步驟的特定順序。本技術領域具有通常知識者應理解，步驟可能以其它順序呈現。因此，本說明書所指出的步驟特定順序不應視為對專利範圍的限制；再者，本發明於申請專利範圍所指的方法與步驟不應被其書寫順序作為實現本發明的限制，且本技術領域具有通常知識者應可理解順序的均等變化與修飾，均應包括于本發明的申請專利範圍內。