5. 實驗結果與討論
5.2 Log Query Service
Average logs (Per month)
Average Life Cycle (Months)
Text App 476.41 8+
Voice App 1 31.28 1.67
Voice App 2 142.09 2.22
表格 5-1 Usage comparison for the three apps
因為使用者下載應用程式的時間都不相同，很難對每個使用者定義絕對的應 用程式開始使用的時間點。然而，如果我們對個別使用者的使用情況作比較，我 們還是可以觀察出相似的下載和使用之序列如圖 5-1、圖 5-2
‧
2010/11 2010/12 2011/01 2011/02 2011/03 2011/04 2011/05 2011/06 2011/07 2011/08 2011/09 2011/10 2011/11
Usage
User 1 User 2 User 3 User 4
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
48
應用程式很有趣且吸引人，讓他頻繁的使用。然而使用者 3 沒有打字的習慣，使 用的頻率隨著新鮮感的降低而下降了，在夏天中不尋常的高頻率使用免費簡訊應 用程式是因為使用者 3 去旅遊，需要用較有效率且便宜的方式來聯絡家人、朋友。
當被問到有關其他兩個通話程式的使用情況時，使用者 3 表示因為他的聯絡人中 很少人使用這兩個軟體，所以沒有進一步設定，因為通話程式一段時間沒有使用，
使用者 3 覺得記憶體空間不足，就將沒用到的應用程式刪除。
在此案例中，我們觀察到雖然 3 個應用程式都是以免費通訊為目的，使用模 式和應用程式生命週期隨著應用的不同而有極大的差異，免費傳簡訊應用程式似 乎是比較耐用的，其他兩個通話程式，只能引起使用者短期的興趣。
5.3 Log Real-time Monitor
研究者如果要對智慧型手機使用者的使用行為進行分析，如果事先知道操作 行為會產生出 Log Pattern，將會在分析上更清楚，經由 Log Real-time Monitor 的 協助，研究者可以立刻從畫面上取得操作行為所產生的 Log List，對於使用者在 手機上進行了哪些必須的操作而其所產生的 Log List 將會更容易且清楚的定義 出操作行為。
圖 5-4 Real-time Log Monitor
如標示出來的 Log 是跟通話有關的操作行為，經由 Log Monitor 研究者可以 觀察到 com.android.phone .InCallScreen 是使用者在進行語音通話必定會啟動的 Activity，然而對於進行語音通話的方式可能有很多種，如手動輸入號碼或是快
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
49
速撥號等方式，對於經由不同方式達到同一行為的意圖，對於大部分的應用程式 應該會具有類似的情形，例如分享照片等。所以單獨的 Log 很明顯是不夠的，
可能必須結合前後數個 Logs，產生特定的 Pattern，才有足夠的資料做更進一步 的分析。例如使用者是經由聯絡人列表來進行語音通話，則在.InCallScreen 之前 必定先經由 com.android.htccontacts .ContactDetailLayerCarouselActivity ，也就是 說如果要經由語音通話則至少需要經過兩個 Activity 的啟動，結合這兩個 Activity 則可以定義操作行為會產生的 Pattern。
在此處將說明經由 Log Real-time Monitor 產生的 Log List 協助，所找到進行 語音通話所產生的操作行為模式。
Enter phone number using keypad
圖 5-5 Left:手動輸入號碼步驟以及對應產生的 Log 流程圖 Right:手動輸入號碼手機畫面
使用時機:當想要通話的對象不在聯絡人清單或是已經熟記該聯絡對象的號 碼，則使用者會藉由此一方法進行語音通話(如圖 5-5)。
Contact List
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
50
圖 5-6 Left:經由通訊錄進行通話的步驟以其對應產生的 Log 流程圖 Right:手機通訊錄畫面
使用時機:當聯絡對象已於先前存入連絡人清單，但對聯絡人電話不熟，或是 久未聯絡會經由此方式進行語音通話(如圖 5-6)。
Call history
圖 5-7 經由通話記錄進行通話的步驟以其對應產生的 Log 流程圖 Right:手機通話記錄畫面
使用時機：當有來電未接或是最近有通話過的連絡人，要進行通話時使用者 可直接從 call history 撥打電話(如圖 5-7)。
Favorite contact
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
51
圖 5-8 經由我的最愛進行通話的步驟以其對應產生的 Log 流程圖 Right:我的最愛聯絡人畫面
使用時機：當通話對象已經被設為我的最愛，可以經由開啟我的最愛清單，
由於我的最愛是將通訊錄中特定使用者集中，所以數量往往較少(如圖 5-8)。
Widget:
圖 5-9 經由 widget 進行通話的步驟以其對應產生的 Log 流程圖 Right：widget 畫面
使用時機：當有將常撥出的對象設為 widget，有別於 favorite contact，widget 是放在桌面的聯絡人捷徑，撥出電話前所需的選擇時間(select elapsed time)會更 少(如圖 5-9)。
Call from voice:
撥出的對象必須已儲存在 contact list，一般使用者會在無法用手操作手機時 使用(如開車時撥電話)，但是此功能 Android 平台上尚未出現中文語音辨識率足 夠的語音撥號軟體，故無法順利取得 Log.
‧
Enter phone number using keypad
表格 5-2 撥出模式步驟，觸發的 Application、Activity、Log 數量比較
藉由 Log Real-time Monitor 已經使用者操作行為成功定義初五種 Log Pattern，
然而值得注意的，如表格 5-2 所示，透過 Widget 所產生的 Pattern 僅具有單獨 Log，這樣的 Pattern 將可能會難以分析，此外雖然透過我的最愛的方式來進行 撥打電話需要四個步驟，但是實際測試的時候可以發現使用我的最愛聯絡人速度 遠高於 Contact List，這是因為透過我的最愛的聯絡人可以更快速的找到想要通 話的對象，然而在尋找聯絡的人時候並不會產生相對應的 Log，也就是說 Activity 的多寡並無法決定完成一件事情的時間長短。
經由使用者的操作行為結合 Log Real-time Monitor 研究者可以方便且快速找 到相對應的 Log List，進一步去定義操作行為產生的 Log Pattern，免除在大量資 訊中或是事後的 Log List 中找尋相對應的 Log 資料。經由定義這樣的 Pattern 與 Log service 中的資料，可以快速對使用者行為進行一定的分析。雖然 Log Monitor 提供了一個方便的介面供研究者查詢或是瞭解操作行為所產生的 Log 也加速的 定義 Pattern 的速度與效率，然而受限於 Android Market 上 App 的多樣化，除了 原生的 App 外，有更多具備可取代原生程式的 App，抑或是具有多重性質的應 用程式，這些類型的應用程式往往會造成分析 User Log 上很大的困難處，此外