《Android應用開發攻略》——3.9 使用本地運作時應用程式日志分析現場錯誤情況

atul nene

3.9.1 問題

當使用者報告了你認為不應該發生的情況時，往往應用程式的釋出版本已經投放市場，你無法了解使用者的環境中到底發生了什麼，而缺陷報告提供的是一個“無法複制”的情景。

3.9.2 解決方案

為你的應用程式設計一個内建的機制，在這種情況下能夠提供更多的細節。你知道重要的事件或者狀态變化以及應用程式的資源需求，如果在應用程式的運作時日志中記錄這些情況，日志就可以成為調查所報告的錯誤核心情況的又一個必需的資源。這種簡單的預防手段和機制有助于減少因為不可預見的情況造成使用者的抱怨，并且改進整體使用者體驗。

解決方案之一是使用标準的java.util.logging包。本攻略提供了一個runtimelog示例，使用java.util.logging寫入裝置上的一個日志檔案，并且讓開發人員能夠全面控制記錄的詳細程度。

3.9.3 讨論

你已經設計、開發并且測試了應用程式，并将其釋出到android market，是以你認為可以給自己放個假了。别着急！除了最簡單的應用程式以外，開發人員無法在開發應用程式期間顧及所有可能的情境，開發時間也沒有如此寬松，使用者一定會報告某些預料之外的應用行為。這些行為不一定是缺陷；可能隻是在測試中沒有碰到的運作時情境。在應用程式中設計一個運作時應用程式日志機制，就能應對意外情況。

将應用程式中最重要的事件記錄到日志中，例如，狀态變化、資源逾時（網絡通路，線程等待）或者最高重試次數。甚至，可以防禦性地記錄異常情況下的代碼路徑執行，或者發送給使用者的最重要通知。

警告： 隻建立能夠洞察應用程式工作情況的語句。否則，日志的尺寸本身就成為問題，雖然開發完畢的應用程式在運作時會忽略log.d()調用，但是太多的日志語句仍然會使應用程式的速度降低。

注意： 你可能疑惑為什麼不使用logcat或者bugsense/acra來應對這一任務。這些解決方案無法滿足需求的原因如下：

因為使用者不太可能為其裝置附加一個調試程式。代碼中過多的log.d和log.i語句對應用程式性能有負面的影響。實際上，你在釋出的應用程式中不應該編譯log.*語句。

acra/bugsense在裝置連接配接到網際網路時工作得很好，但是情況并非總是如此，除了acra之外，應用程式的一些類完全不需要網際網路。而且，acra棧跟蹤隻提供抛出異常時的詳情，而本攻略提供了應用程式運作中較長期的視圖。

例3-5展示了runtimelog類。

例3-5：runtimelog類

當然，有幾個替代方案可供使用：

你可以使用相同的機制在開發應用程式時發現複雜的運作時問題。為此，将mode變量設定為mode_debug。

對于具備許多子產品的複雜應用，在日志調用中添加子產品名為附加參數可能有用。

你還可以從logrecord中提取classname和methodname添加到日志語句中；但是不建議在運作時日志中這麼做。

例3-6說明，這種機制的基本用法和正常的log.d調用同樣簡單。

例3-6：使用runtimelog類

如果有必要，你可以要求使用者從其sd卡中讀取日志檔案，并發送給你的支援團隊。更好的辦法是，編寫代碼，在按下某個按鈕時完成這一任務！

下面是一些附加的注意事項：

這種機制不一定要處于“始終開啟”的狀态。你可以根據使用者設定的配置選項記錄日志，僅在最終使用者試圖重制某種情景的時候啟用它。

如果日志始終開啟，用目前日期（在應用程式啟動時确定）命名日志檔案，删除某個日期之前确實不再使用的舊日志，這能夠有效地控制日志檔案的大小。

3.9.4 參閱

acra網站；攻略3.7；攻略3.8