第二章 文獻探討
2.5 記錄器設計
在記錄器的設計方面，因記錄的資訊相當多樣化，Android 應用程式設計介面也提 供不同的參數取得方式，良好的設計可以更加彈性的記錄，且不會影響使用者原本使用 習慣。
在 Clayton Shepard 等人[1]對在記錄器設計方面，提出三項特點，分別如下:
1.背景處理程序管理(Daemon Manager):為了確保後端記錄服務執行緒一直執行，不會 因意外關閉或重開機時無法啟動執行緒，執行緒由後端處理執行緒管理員啟動和監 視，執行緒是為了蒐集所有中斷法所蒐集的資訊，而執行緒會透過背景處理程式監 視，如果執行緒意外離開，會透由背景處理程式重新啟動，可達到資料紀錄不中斷 和減少影響使用者前端操作的目的。
2.時間間隔管理(Interval Manager):執行緒執行感測資料蒐集時，蒐集資料的頻率會動 態根據某些環境數值的改變而變更。例如，當感測到手機正在充電，紀錄資料的時 間間隔可以降低到每一分鐘，甚至每一秒，相反的，隨著電力消耗的程度將記錄時 間間隔逐漸放寬，有效的動態感測紀錄。
‧
3.自動更新(Auto Update):檢查伺服端任何的更新服務，自動下載後並將檔案更新。通 常設定於當記錄器重新啟動執行任務，可從伺服器上下載新的軟體包到受測者手 機，啟動內建 installer 程式安裝並完成更新程序。
Rui Guo 等人[2]是對 Android 應用程式介面中，不同類型資訊依 Android 函式庫提 供不同的方法提出適合的蒐集方式，有以下四種方式:
1.像螢幕開啟、關閉或充電不充電等事件的記錄，使屬於觸發式的資訊，採用 Android 組件的廣播接收器，當感測到事件發生時，則記錄該事件相關資訊。
2.網路流量和系統服務方面的資訊，透過定期讀取系統資訊紀錄。
3.通話簡訊等記錄，可以透過 API 提供的 content provider 組件，在該資料來源有開放 權限的情況下，透過 URI 資訊索引取得相關的資料。
4.地理位置資訊(GPS)，則需要透過註冊地理資訊監聽器方式，記錄所在位置經、緯 度的變化。
P.-M. Chen 等人[4]為瞭解現代人在 Android 平台上使用應用程式的時機及常用應 用程式，提出各式應用程式狀態感測，透過 Android 平台提供 android.util.Log 資訊方式，
擷取自行定義及系統使用資訊，為瞭解受測者習慣何時、何地使用應用程式，故將經、
緯度和時間資訊一併記錄於 SQLite 資料庫，以便於研究員於伺服器端，可透過網頁 GUI 介面分析不同時段和地點，使用者所使用的應用程式，產生統計報表。
本系統參考 Clayton Shepard 等人[1]所提出的背景處理程序管理和 Rui Guo 等人[2]
提出資料蒐集方式，依系統特性差異，提出符合本系統架構方式，而自動更新方式與 Clayton Shepard 等人[1]所提出方式有所不同，細節將於第 4 章介紹。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
第三章 系統架構及流程
本論文的系統，以 Android 平台為範圍，提出了一個對於系統架構的概念雛型；它 可以廣泛性的蒐集 Android 手機上感測記錄機制、讓研究人員簡易的定義實驗收集的資 料內容、讓使用者易於參與及提供實驗所需數據，讓分析數據人員對於所收集進行報表 的統計。
3.1 實驗設定檔 ECF
為了讓實驗達到客製化的目的，研究人員能夠方便描述所將要進行的實驗，以及讓 負責收集資料的 App 能夠精確的分析需求進行資料的收集，本實驗提出可設定之中介語 言(ECF)，其建立與實作內容上，考量了下列兩項層面：
1.需求層面:
(1)感測器種類繁多
(2)研究實驗規則多樣化
(3)實驗定義必須有所規範，又得兼顧彈性
2.系統開發層面:
系統在開發方面所需考量資訊為下表 5，所以實驗設定檔在設計上包括感測項目、
‧
(5)限制條件比較運算子:包含(>=,>,=,<,<=運算子)。
(6)限制條件比較值:依 API 提供各屬性的比較值(如 double、float)。
(7)上傳時機:待機螢幕關閉或手機充電。
gps.longitude >=121.610989,
‧
gps.longitude<= 121.617147, gps.latitude >= 25.038755 , gps.latitude <= 25.045365,
uploadpolicy
screenoffupload,
圍(-π~π) SensorManager 2 磁性 x,y,和 z 軸的磁性感應強度 SensorManager 3 亮度 測量光強度(單位:lx) SensorManager
4 壓力 測量環境空氣壓力
(單位:hPa mbar) SensorManager 5 距離 靠近螢幕的距離(單位:cm) SensorManager 6 溫度 攝式溫度(單位:°C) SensorManager 7 加速度 三軸(x,y,和 z)m / s2 加速度 SensorManager 8 全球定位資訊 經緯度、移動速度、精確度、
高度、方向 LocationManager 表 8:行為屬性列表。 broadcast
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
以上資料蒐集，就隱私保護來說，參考上述 Rui Guo 等人[2]提出的第二種方式，舉 例來說，通話資訊僅對撥接通話次數和各時數進行統計，並沒有記錄使用者電話號碼資 訊。
本應用程式所記錄之身分辨識資訊，不採用手機設備 IMEI 序號，因此資訊可以關 聯出設備擁有人資訊，實驗唯一識別碼改透由用戶端向伺服端索取，此實驗唯一識別碼 無法反推使用者資訊，另因記錄之定位資訊無法對應到使用者身分識別碼，所以也可以 避免洩漏受測者所在位置。
此外，本實驗平台也可讓施測者選擇過濾條件，達到 N. Haderer 等人[3]所提出區域 過濾器相同的功能，並可增加更多過濾條件，如受測者所在高度之類條件。
最後，為保護實驗記錄資訊於上傳時被有心人士截取，在用戶端上傳記錄時，對傳 輸封包資訊使用 BASE64 加密方式保護，資料傳送至伺服端後再行解密。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
3.3 系統架構
圖 4:系統架構示意圖。
本系統整體系統架構圖示意圖如上圖 4 所示，可分為用戶端和伺服器端，伺服器端 主要為網頁式方式提供研究員建立實驗和實驗相關設定檔，和將接收來至用戶端的實驗 紀錄檔儲存到資料庫；在用戶端為受測者安裝的應用程式，受測者可選取要參加的實驗 設定檔進行感測，感測後於符合上傳時機時將實驗紀錄檔上傳至伺服器端。為避免同時 間大量用戶上傳資料，導致伺服器負載過重，於中間架設 RabbitMQ 佇列伺服器以有效 達到緩衝效果。
‧
件關聯式資料庫系統 PostgreSQL。表 9:伺服端安裝元件。
OS Freebsd 9 JVM Open JDK 1.7 Application Server Glassfish 3.1.2
Queue Server RabbitMQ 3.0.1 Database PostgreSQL 9.2
在系統 web 介面部署主要是透過 Glassfish，GlassFish 是昇陽電腦公司所研發的開 放原始碼應用伺服器，透過 Java 程式語言編寫以增加跨平台性，它有助於組織透過輕量
(Experimeant Loader)和記錄上傳模組(Log Uploader)和伺服器端溝通，在 ECF 處理區分 為前端 ECF 剖析模組、後端限制條件過濾和不同屬性資料蒐集模組，資料記錄主要儲 存於智慧型手機 SQLite 資料庫，各模組處理細節將於第 4 節介紹。在伺服器端方面，
主要為實驗 ECF 設定檔資料產出和將用戶端上傳記錄，依實驗 ID 寫入 PostgreSQL 資料 庫。用戶端應用程式主要使用系統模組，如下圖 5 所
示:
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 5:用戶端應用程式系統模組。
用戶端使用流程步驟如下:
1.受測者於網路上下載並將應用程式安裝於手機，應用程式已包含 ECF 剖析工具、限 制條件過濾和相對應記錄方法。
2.當使用者開啟應用程式時，會以 RESTful 方式向伺服端判定有無授權 ID，若沒有則 取得新授權 ID 及認證碼，便於使用者上傳記錄辨識，此資料會以 DAO(Data Access Objects)方式，記錄於本機 XML 檔案，若使用者未將此應用程式刪除或執行資料清 除動作，此後作實驗都沿用此 ID 作認證。
3.當使用者要選取實驗時，會先於 SQLite 資料庫建立資料表，並將用戶端授權 ID、
認證碼、手機 OS、版本、型號資訊參數帶入向伺服器端做認證，並也以 RESTful 方式向伺服端取得實驗 ECF 設定檔和實驗列表 ID。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
4.使用者確定實驗後，前端 ECF 剖析工具將使用實驗 ECF 設定檔分割成各類參數，
交由後端服務，以限制條件過濾器和呼叫對應的屬性資料記錄方法，同時並將相關 參數寫入另一個 XML 檔案，此 XML 檔的作用是考量使用者可能更換電池或其他 因素將手機關機，若使用者曾經執行過實驗，會在手機重新開機時，背景喚起此應 用程式後端服務對此 XML 檔案進行辨識，繼續原先選擇的實驗記錄。
5.在資料寫入資料庫之前會先以限制條件過濾器過濾，符合實驗限制的紀錄才可以寫 入 SQLite 資料庫。
6.在偵測到手機充電或待機(螢幕關閉)事件時，自動啟用上傳機制，將所收集而來暫 存於 SQLite 內的資料，包裝成 JSON 物件格式後進行加密，將物件逐一上傳至伺 服器端的 RabbitMQ。RabbitMQ 為專門處理 Message Queue 的伺服器，在此處主要 為擔任緩衝功能的角色。
7.在伺服器端，另外 建立了記錄監聽器程式，該程式會慢慢讀取 RabbitMQ 上的訊息，
並轉而呼叫 web 伺服器上轉存的 RESTful，最後將資料送達 PostgreSQL 資料庫內 儲存。上傳完畢後就將用戶端已上傳的資料列刪除，並繼續記錄後續的資料，以防 止上傳重複的資訊，導致實驗結果不正確。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
第四章 系統模組分析
本章主要是對實驗流程中，各模組運作細部內容進行分析，對於在取得實驗相關參 數方面，透過實驗者 ID 讀取模組和實驗 ECF 設定檔讀取模組使用 RESTful(於 4.1 節介 紹)方式和伺服器端索取資料；在實驗設定檔分析模組方面，如下圖 6 所示：區分為前 端 ECF 剖析模組、後端限制條件過濾和不同屬性資料蒐集模組；在資料庫方面，區分 為記錄寫入和讀取記錄上傳兩個模組。
圖 6:實驗設定檔分析模組。
‧
本系統實驗參數讀取是以 REST 方式，REST(Representational State Transfer)的縮 寫，以 URL (Uniform Resource Locator)網址定位資源所在處，就是透過使用 Http 的格 式對網站進行互動，並且針對的是網站所提供的「資源」而不是「網頁服務」，所以這 是一種 Design Pattern。
資源則藉由 HTTP 協定中所定義的方法操作資源。REST 所稱的資源如表 10 所 示，其實是資料與資料處理方法的包裝，也就是 OOP 中的「個體」、「物件」。同時 在 HTTP 中，也定義了四種基本方法，即 GET, POST, PUT, DELETE。以上四種基本 方法大致上對應了四種資料處理動作，即 Create, Read, Update, Delete。
REST 指的是一组架構約束條件和原則。滿足這些約束條件和原则的應用程序或設 計就稱為 RESTful。
表 10:網頁參數截取基本方法列表。
HTTP 方法 資料操作 描述
POST Create Create a resource without id.
GET Read Get a resource.
PUT Update Update a resource or create a
PUT Update Update a resource or create a