RERAN:安卓系統的定時和點選的錄製和回放——（2）

2. Android 輸入

  本節中，我們將介紹Android應用不同型別的輸入，以及它們是如何以事件的形式展示給使用者看。

A. 使用者觸控式螢幕操作

  智慧手機應用程式的區別有部分是使用者通過觸控式螢幕進行的操作引起的不同表現。我們簡要描述幾個常見的：

  按下-釋放（點選）：主要的輸入是簡單的按壓，也就是使用者輕敲螢幕並快速的放開，例如：點選一個按鈕或點選螢幕上的鍵盤進行輸入文字
  按下-保持（按住）：按住是由使用者點選螢幕上的一個區域，然後在同一個位置保持一定的時間。這個動作可以用來訪問二級選單或隱藏的選項。
  滑動：滑動的操作是使用者按下螢幕，然後保持住，一直從位置（x1,y1）移動到一個新的位置（x2,y2），最後放開。很多應用都有用到滑動這個操作。例如在Web瀏覽器頁面滾動文字，或者在憤怒的小鳥遊戲中，打小鳥。
  雙指縮放：多點觸控手勢包括通過多個接觸點，按壓觸控式螢幕，如使用2個或2個以上手指。最常見的多點觸控用法是放大和縮小。一般一些應用程式如果支援這種手勢的話，他們通常會用於改變當前檢視內容的放大級別。例如在谷歌地圖中，用於使用放大或縮小來改變檢視地圖詳情的級別。
  上面列出的四個使用者操作,有三個被認為是手勢:按住、滑動、雙指縮放。簡單的來說，手勢需要一大群潛在的觸屏事件來實現他們的感知功能。如第七節中描述，使用者點選的操作需要事件的叢集則比較少，目前已經可以使用一些方法進行成功的回放。如圖1所示，應用程式執行中，頻繁的使用觸控式螢幕手勢；這些結果是基於同一個使用者玩一款應用軟體5分鐘來統計的。從中可以觀察到：這個會話期間，大多數的應用（86個應用中有60個）已經涉及了20到100個手勢。只有2個應用是不包含任何的手勢（免費的Uno小遊戲和手電筒）。
  除了觸控式螢幕，使用者可以通過手機上的物理按鍵提供輸入。我們的測試裝置沒有物理鍵盤，但它們有幾個不同用途的按鈕，如鎖屏，關機、調節音量大小等。

B.物理感測器

  Android裝置通常有若干個感測器，用於產生非同步輸入。感測器資料產生是硬體檢測到手機物理屬性的變化。我們將描述Android應用程式中最常見的感測器及其用途。需要注意的是，GPS定位是一個服務，而不是直接從裝置的感測器讀取的，所以目前我們無法回放它的事件。
  加速度感測器允許應用程式來檢測手機是否已經改變了它的速度,還可以用來檢測手機是否傾斜和旋轉。這是用來改變螢幕從縱向佈局為橫向佈局的機制，同時一些遊戲使用這個加速度感測器作為使用者輸入的主要手段。如通過左右滾動球過迷宮或者搖晃魔法八球（ magic eight ball：一種遊戲）。
  近距離感測器或光感測器允許應用程式檢測使用者與電話間的距離。這個感測器主要用於通話過程中，當螢幕變暗，使用者靠近電話時，不小心按到其他的按鈕。
  指南針指示手機相對於磁北的方向。指南針通常用於地圖或導航應用程式，提供方向的角度。

C. Android事件

  Android 軟體棧是由一個定製的Linux核心、庫、Dalvik虛擬機器（VM）和執行在虛擬機器上的程式組成。當使用者使用一個Android應用進行互動時，Android裝置的感測器產生併傳送事件到核心，並將資訊存在dev/input/event* 目錄中的裝置檔案中。這些記錄的事件有一個標準，5個基層格式（時間戳：裝置：型別程式碼值），其中時間戳表示最後一次系統重新啟動後到現在經過的時間，裝置是事件的命名（如event 4），剩下的欄位取決於特定的事件型別。
  在上述格式中，觸控式螢幕手勢被編碼作為觸控式螢幕事件流，但並沒有標記其要執行哪些動作。例如,一個這樣的事件可能看起來如下：

  這裡的時間戳顯示事件產生是40秒，系統重啟到事件生成的時間為719451微秒; 輸入的裝置相對於觸控式螢幕（我們的裝置）是event4。接下來的三列提供了位置資訊:0035是事件對應的x位置和0000011f（十六進位制）對應於螢幕的座標287（十進位制）。然而，對高階別的手勢而言，不僅僅只有這樣一個單一的資訊量。例如，單次點選通常需要大約18個觸控式螢幕事件，而滑動的操作大約需要50個觸控式螢幕事件。

圖2 滑動操作的一系列事件：Xi，Yi是初始座標；Xm，Ym是移動的座標（仍然按住移動）；Xf，Yf是最後的座標

  圖2中顯示了滑動這個典型手勢所包含的一個子集事件。該圖的左側顯示了54個事件的原始資料流，而右側顯示高等級的語義事件叢集：點選、移動、釋放。前面介紹的示例事件，實際上資料流中的事件3。注意上面的時間資訊，為了能成功的回放滑動操作，這54個事件必須精確的回放在179毫秒內（時間戳範圍是在40-719421到40-898681）。

  舉個例子，多個感測器的真實應用程式上的事件流。在圖三中，展示的是GasBuddy應用程式的事件流（這個程式是在地圖上顯示天然氣的價格），顯示的資料是app操作後正常執行的前80s。

圖3 Gas Buddy中事件的時序圖

  x軸顯示的時間，以秒為單位,y軸顯示事件的數量。該圖表顯示事件的顆粒度是5s：頂部紅色曲線，標註了觸控式螢幕事件，而底部的淡藍色曲線則標註了指南針的事件。上面的文字則是描述不同的執行階段。首先，使用者使用觸控板輸入地理位置：洛杉磯（0～10s）；可以觀察到，在這個階段並不使用指南針。接下來，應用程式會載入洛杉磯附近的加油站地圖，要使用指南針來定向地圖，可以觀察到，使用者在等待時，沒有觸控式螢幕事件（11～25s）。在第三階段，地圖載入完成，使用者可以使用縮小和放大地圖進行導航，此時產生了大量的觸控式螢幕事件（26～45s），指南針仍然用來保證正確地址的定位。第四階段，使用者瀏覽個別加油站的天然氣價格（46～60s），這個只需要進行滾動，不需要指南針。最後（61+s），使用者再次使用縮小放大地圖進行導航，產生觸控式螢幕和指南針事件。
  時間序列揭示了成功進行回放的幾個關鍵要求：事件來自於所有的感測器，不僅僅是觸控式螢幕，這些事件都必須被採集和傳送，因為它們影響應用程式的行為，同時在在高吞吐量時，這些事件也必須被採集和傳送。

表1. 每個輸入裝置執行5分鐘後產生的輸入事件數

  我們提供了一個典型事件流總量的定量評估表1。表1展示的是來自三個不同的事件輸入裝置，所列出的應用程式在執行5分鐘內產生的事件總數。其中觸控事件占主導地位，但也有相當數量的時間是來自感測器。在測試執行期間，上述的應用程式所在的手機都放置在桌子上用於保持平衡，這樣的話就只會有少量的加速計的事件產生。