最新的Android平臺(tái)中(Android 2.3起)，新增加了一個(gè)新的類(lèi)，叫StrictMode(android.os.StrictMode)。這個(gè)類(lèi)可以用來(lái)幫助開(kāi)發(fā)者改進(jìn)他們編寫(xiě)的應(yīng)用，并且提供了各種的策略，這些策略能隨時(shí)檢查和報(bào)告開(kāi)發(fā)者開(kāi)發(fā)應(yīng)用中存在的問(wèn)題，比如可以監(jiān)視那些本不應(yīng)該在主線程中完成的工作或者其他的一些不規(guī)范和不好的代碼。
StrictMode有多種不同的策略，每一種策略又有不同的規(guī)則，當(dāng)開(kāi)發(fā)者違背某個(gè)規(guī)則時(shí)，每個(gè)策略都有不同的方法去顯示提醒用戶(hù)。在本文中，將舉例子說(shuō)明如何使用在Android 中使用 StrictMode。
StrictMode的策略和規(guī)則
目前，有兩大類(lèi)的策略可供使用，一類(lèi)是關(guān)于常用的監(jiān)控方面的，另外一類(lèi)是關(guān)于VM虛擬機(jī)等方面的策略。常用的監(jiān)控方面的策略有如下這些：
Disk Reads 磁盤(pán)讀
Disk Writes 磁盤(pán)寫(xiě)
Network access 網(wǎng)絡(luò)訪問(wèn)
Custom Slow Code 自定義的運(yùn)行速度慢的代碼分析
前面三種的意思讀者應(yīng)該很清楚，就是正如它們的名字所示，分別對(duì)磁盤(pán)的讀和寫(xiě)，網(wǎng)絡(luò)訪問(wèn)進(jìn)行監(jiān)控。而第四種的自定義慢代碼分析，是僅當(dāng)訪問(wèn)調(diào)用類(lèi)的時(shí)后才觸發(fā)的，可以通過(guò)這種方法去監(jiān)視運(yùn)行緩慢的代碼。當(dāng)在主線程中調(diào)用時(shí)，這些驗(yàn)證規(guī)則就會(huì)起作用去檢查你的代碼。比如，當(dāng)你的應(yīng)用在下載或者解析大量的數(shù)據(jù)時(shí)，你可以觸發(fā)自定義運(yùn)行速度慢代碼的查詢(xún)分析，作用很大。StrictMode可以用于捕捉發(fā)生在應(yīng)用程序主線程中耗時(shí)的磁盤(pán)、網(wǎng)絡(luò)訪問(wèn)或函數(shù)調(diào)用，可以幫助開(kāi)發(fā)者使其改進(jìn)程序，使主線程處理UI和動(dòng)畫(huà)在磁盤(pán)讀寫(xiě)和網(wǎng)絡(luò)操作時(shí)變得更平滑，避免主線程被阻塞的發(fā)生。
而VM方面的策略重點(diǎn)關(guān)注如下幾類(lèi)：
內(nèi)存泄露的Activity對(duì)象
內(nèi)存泄露的SQLite對(duì)象
內(nèi)存泄露的釋放的對(duì)象
其中，內(nèi)存泄露的Activity對(duì)象和內(nèi)存泄露的SQLite對(duì)象都比較好理解，而所謂對(duì)關(guān)閉對(duì)象的檢查，主要是去監(jiān)那些本該釋放的對(duì)象，比如應(yīng)該調(diào)用close()方法的對(duì)象。
當(dāng)開(kāi)發(fā)者違反某類(lèi)規(guī)則時(shí)，每種策略都會(huì)有不同的方法令開(kāi)發(fā)者知道當(dāng)時(shí)的情況。相關(guān)的違反情況可以記錄在LogCat中或者存儲(chǔ)在DropBox中(android.os.DropBox)服務(wù)中。而常用監(jiān)控類(lèi)的策略還會(huì)在當(dāng)違規(guī)情況發(fā)生時(shí)顯示相關(guān)的對(duì)話框和當(dāng)時(shí)的上下文環(huán)境，所有的這些都為了能讓開(kāi)發(fā)者盡快地了解程序的瑕疵，以提交程序的質(zhì)量。下面分步講解如何使用stritctmode。
第一步 啟用strictmode
為了能在應(yīng)用中啟用和配置StrictMode,開(kāi)發(fā)者最好盡可能在應(yīng)用程序的生命周期的早段使用，方法是調(diào)用StrictMode的方法setThreadPolicy。當(dāng)使用常用監(jiān)控類(lèi)的時(shí)候，一個(gè)最好的調(diào)用時(shí)機(jī)，是在應(yīng)用中入口和activities被調(diào)用前進(jìn)行。比如在一個(gè)應(yīng)用程序中，可以把代碼放在啟動(dòng)Activity類(lèi)的onCreate()方法中，下面是一個(gè)代碼示例，啟用了當(dāng)前情況下的所有策略及規(guī)則，當(dāng)程序中出現(xiàn)違背常用的規(guī)則時(shí)，將會(huì)顯示相關(guān)的提示信息窗口：
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectAll()
.penaltyLog()
.penaltyDialog() ////打印logcat，當(dāng)然也可以定位到dropbox，通過(guò)文件保存相應(yīng)的log
.build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll()
.penaltyLog()
.build());
當(dāng)然，以上代碼只應(yīng)在未發(fā)布上線的測(cè)試版本的應(yīng)用中運(yùn)行以方便監(jiān)視相關(guān)的運(yùn)行情況，當(dāng)在生產(chǎn)版本上時(shí)不應(yīng)該啟用strictmode。因此，最佳的代碼實(shí)踐應(yīng)該為如下的樣子：
public void onCreate() {
if (DEVELOPER_MODE) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectDiskWrites()
.detectNetwork()
.penaltyLog()
.build());
super.onCreate();
第二步 運(yùn)行strictmode
當(dāng)應(yīng)用啟用了strictmode模式時(shí)，其實(shí)跟普通的應(yīng)用沒(méi)什么兩樣，在測(cè)試和運(yùn)行時(shí)，跟平時(shí)運(yùn)行普通應(yīng)用程序一樣就可以了。當(dāng)啟用了Strictmode模式時(shí)，會(huì)監(jiān)視所有的程序運(yùn)行情況，當(dāng)發(fā)現(xiàn)出現(xiàn)重大問(wèn)題或違背策略規(guī)則時(shí)，會(huì)提示用戶(hù)。下面是當(dāng)運(yùn)行啟用了strictmode模式的應(yīng)用時(shí)，當(dāng)發(fā)現(xiàn)違背規(guī)則時(shí)，顯示給用戶(hù)的信息，細(xì)心觀察下跟普通的出錯(cuò)信息有什么不同吧。
09-04 16:15:34.592: DEBUG/StrictMode(15883): StrictMode policy violation; ~duration=319 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=31 violation=1
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1041)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.database.sqlite.SQLiteStatement.acquireAndLock(SQLiteStatement.java:219)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:83)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.database.sqlite.SQLiteDatabase.updateWithOnConflict(SQLiteDatabase.java:1829)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.database.sqlite.SQLiteDatabase.update(SQLiteDatabase.java:1780)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at com.mamlambo.tutorial.tutlist.data.TutListProvider.update(TutListProvider.java:188)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.content.ContentProvider$Transport.update(ContentProvider.java:233)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.content.ContentResolver.update(ContentResolver.java:847)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at com.mamlambo.tutorial.tutlist.data.TutListProvider.markItemRead(TutListProvider.java:229)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at com.mamlambo.tutorial.tutlist.TutListFragment.onListItemClick(TutListFragment.java:99)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.support.v4.app.ListFragment$2.onItemClick(ListFragment.java:53)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.widget.AdapterView.performItemClick(AdapterView.java:282)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.widget.AbsListView.performItemClick(AbsListView.java:1037)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.widget.AbsListView$PerformClick.run(AbsListView.java:2449)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.widget.AbsListView$1.run(AbsListView.java:3073)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.os.Handler.handleCallback(Handler.java:587)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.os.Handler.dispatchMessage(Handler.java:92)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.os.Looper.loop(Looper.java:132)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at android.app.ActivityThread.main(ActivityThread.java:4123)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at java.lang.reflect.Method.invokeNative(Native Method)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at java.lang.reflect.Method.invoke(Method.java:491)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599)
09-04 16:15:34.592: DEBUG/StrictMode(15883): at dalvik.system.NativeStart.main(Native Method
并且會(huì)出現(xiàn)如下的提示窗口，提示用戶(hù)：轉(zhuǎn)播到騰訊微博
忽略某些規(guī)則
應(yīng)該說(shuō)大部分由StrictMode產(chǎn)生的規(guī)則警示都應(yīng)去遵守，但有時(shí)也不是所有產(chǎn)生的信息都表明你的程序有錯(cuò)誤。比如，在應(yīng)用程序的主線程中去快速讀寫(xiě)磁盤(pán)其實(shí)不會(huì)對(duì)應(yīng)用的性能產(chǎn)生太大的影響，又或者你在調(diào)試程序階段有一些調(diào)試的代碼違反了設(shè)定的規(guī)則，這些都可以忽略掉這些規(guī)則。
忽略規(guī)則有兩種方法，一種是單純?cè)诖a中把Strictmode的代碼注釋掉，另外一種比較好的方法是，在需要忽略的時(shí)候和地方，增加相應(yīng)的代碼去讓系統(tǒng)停止使用這些規(guī)則去檢查，等開(kāi)發(fā)者認(rèn)為有必要檢查時(shí)，再重新應(yīng)用這些規(guī)則，比如：
StrictMode.ThreadPolicy old = StrictMode.getThreadPolicy();
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder(old)
.permitDiskWrites()
.build());
doCorrectStuffThatWritesToDisk();
StrictMode.setThreadPolicy(old);
這里首先用old來(lái)保存了當(dāng)前的策略規(guī)則，然后doCorrectStuffThatWritesToDisk();
這里，執(zhí)行了一些向磁盤(pán)快速讀寫(xiě)的操作，最后又重新啟用了這些規(guī)則。
小結(jié)
StrictMode是一個(gè)十分有用的類(lèi)，它可以很方便地應(yīng)用于檢查Android應(yīng)用程序的性能和存在的問(wèn)題。當(dāng)開(kāi)啟這個(gè)模式后，開(kāi)發(fā)者能很好地檢查應(yīng)用中存在的潛在問(wèn)題，更多的請(qǐng)參考Android文檔中的相關(guān)API說(shuō)明。
