視圖（View）

關於視圖的部分，顧名思義就是使用者可以透過顯示層 User Interface（UI）

介面做溝通，所有使用者請求與結果皆由視圖來呈現與處理，而本研究是基於智 慧型手機進行開發，故視圖的部分便是利用搭配 Android 作業系統的智慧型手機。

使用者開啟本研究的 APP 後，手機便會自動開啟相機並呈現預覽模式（圖 3-2），

接著按下『Start』鍵後手機便開始執行連續拍照並傳送圖片的動作，本研究是利 用執行緒（Thread）的概念去執行工作任務。行程（Process）中一段程式碼（或 者說是指令）的執行軌跡（trace）便稱為執行緒，是電腦中最小的執行單位，且 作業系統會配置每一個執行緒一部份的中央處理器（CPU）暫存器（register）空 間以及執行指令過程中相關資料所需存取的記憶體空間，然而執行緒是在行程上

以時間作為分割來執行多種事件的方式，亦即同一時間只能執行一個執行緒，但 執行緒快速在不同事件中切換執行，由於時間間格很小，會讓我們看似同時進行 多個執行緒（圖 3-3）。

圖 3-2、手機預覽模式

圖 3-3、一個行程含有兩個執行緒的執行示意圖（來源:wikipedia）

依工作任務可分為兩種不同工作內容（事件）的執行緒：

(一) 拍照執行緒：每當手機要開始拍一張照片時即會啟動一個執行緒（Thread）

來處理拍照時必要的工作，其中包括將圖片檔案轉換成 Byte 矩陣以利傳送，

轉換完畢後便將 Byte 矩陣存入佇列（Queue）裡等待執行傳送任務的執行緒 來取出（圖 3-4），若佇列空間已滿便停住（Blocked）存入資料，而當此執行 緒執行完上述的工作後，生命週期（Lifecycle）便來到結束（Dead）的狀態，

此時 Java Virtual Machine（JVM）裡的 Garbage Collection（GC）功能便回收 此執行緒的記憶體，以減輕記憶體的負擔，以上動作會一直重複直到使用者 關閉此 APP 或是按下『Pause』鍵。

(二) 傳送執行緒：生命週期與流程都跟上述的拍照執行緒相同，不同之處只在於 工作內容而已，當負責傳送任務的執行緒發現佇列不為空便開始取出圖檔資 料（圖 3-4）做傳輸，而此傳輸是透過網路並且遵循 HTTP 通訊協定，如此 一來，使用者端便是發出了請求（Request），要求伺服器端（Server）進行處 理。

利用執行緒的概念可以使得系統更有效率，不會因為等待而浪費時間，避免出現 Application Not Responding（ANR）強制關閉此 APP 的情況發生。

圖 3-4、執行緒存取佇列示意圖（來源:Jenkov.com）

然而伺服器端的車牌辨識系統之辨識結果不一定百分之百正確，故本研究加 入使用者再確認的機制，倘若伺服器在處理過程中發現疑似有贓車的存在，伺服 器端會發出請求到使用者端，此請求內容包含了利用 JavaScript Object Notation

（JSON）輕量級交換語言格式所包裝的贓車圖片資訊以及贓車車牌號碼，透過網 路傳送至使用者端。

此時手機便會自動暫停偵測，所有上述的拍照、傳送任務之執行緒都變成停 住的狀態，唯獨主執行緒（Main-Thread）例外，主執行緒是讓一支 APP 程式運 作的執行緒，此時主執行緒會產生一個新的執行緒來呈現 AlertDialog，其目的是 為了避免主執行緒處理繁瑣的工作而導致 ANR 發生，而 AlertDialog 內容就是伺 服器端傳送過來的 JSON 所解析出來的贓車車牌號碼和贓車圖片，提供使用者肉 眼來判斷是否相符（圖 3-5），當 AlertDialog 準備完畢時，便會發送訊息（Message）

通知 Android 的 Handler 工具來呈現 AlertDialog 畫面給使用者，整個 AlertDialog 呈現流程如圖 3-6 所示。

圖 3-5、使用者判斷贓車資訊是否相符

圖 3-6、AlertDialog 呈現示意圖

由圖 3-5 可知，使用者會有兩種選項：

(一) 『Continue』：此種情況即為贓車圖片與贓車號碼不相符，代表圖片在車牌辨 識系統辨識過後的結果與圖片中車牌真正的號碼不同，但又剛好贓車資料庫 恰巧有一筆贓車號碼與誤判的結果相同，甚至是相近，才會導致這種情況發

生。使用者按下『Continue』鍵之後，系統會恢復拍照與傳送工作的執行緒 繼續偵測。

(二) 『Confirm』：經過使用者肉眼判斷確實相符後按下『Confirm』鍵，Android 系統利用 Intent 工具從 AlertDialog 畫面切換至另一個顯示此贓車相關的訊息 畫面，裡面包含了利用衛星定位技術所定位出來的經緯度、Google Map 以及 拍攝時間（圖 3-7），其中 Google Map 的開發是使用 Google Map API 與

MapView 元件所撰寫出來，而 Google Map API 的作用是將 Google Map 服務 器上的地圖圖片以及數據資料包含地標點、劃線等等內嵌到使用者端的應用 程式上，開發者只要向 Google 申請私人開發金鑰便能開始利用 Google 所提 供的服務做開發，Google Map 中圖釘即為贓車所在位置，如圖 3-7 所示。最 後以上資訊再加上贓車圖片和贓車車牌號碼一併傳送到處理中心，提供給員 警調查處理，發送後一樣是恢復拍照與傳送工作的執行緒繼續偵測。

圖 3-7、贓車相關資訊呈現

假設今天並非只有單一使用者在使用本系統查緝贓車，此時伺服器端發現疑 似贓車的存在，則伺服器該如何把贓車訊息推送到正確的使用者端上，要解決這 個問題有多種方法可以使用，例如 eXtensible Messaging and Presence Protocol

（XMPP）、Message Queue Telemetry Transport（MQTT）以及 Google cloud

Messaging（GCM）等等，這些多種的通訊協定都可以幫助我們把資料傳送至正 確對應的使用者，但以 XMPP 來說，它是以 eXtensible Markup Language（XML）

為基礎的通訊協定，目前主要應用在許多聊天系統中，其缺點為協議較複雜、冗 餘且佈署硬體成本較高。至於 MQTT 即為機器之間輕量級消息或數據的傳輸協議，

但是此協議不夠成熟且實現較為複雜，因此本研究是利用 GCM 來達成贓車資訊 傳送至正確對應使用者手機之目的。GCM 好處為簡單、訊息推送速度快以及由

於是 Google 所提供的服務，所以無須實現以及佈署伺服器端，圖 3-8 顯示整個

GCM 推送訊息之過程。

圖 3-8、GCM 的基本流程（來源: HKCERT）

Google 所發佈的 GCM 前身是 Cloud to Device Messaging（C2DM），GCM 的 用處即為開發人員可透過該服務將伺服器中的資料傳送給 Android 應用程式使用，

而且這也是一項免費的服務，開發人員只要取得永久憑證（simple API 金鑰）即 可運用此服務。從圖 3-8 當中可以看出，當使用者開啟本研究 APP 時，系統便會 自動向 GCM 伺服器進行註冊動作，而 GCM 會根據用戶帳號分配一組登記編號

（Registration ID）給該使用者，接著當使用者請求於伺服器時便一併把登記編號 與用戶帳號傳送到伺服器端，在伺服器處理資料的過程中若有符合且完成使用者

的需求下，便把資料數據以及登記編號再傳送至 GCM 伺服器中，最後 GCM 伺 服器再依據登記編號把資料數據發送到該名使用者上了，如此一來便能達到資料 給予正確對應的用戶的目的，解決多使用者（multi-client）之資料推送問題。