StrictMode有多種不一樣的策略,每一種策略又有不一樣的規則,當開發者違背某個規則時,每一個策略都有不一樣的方法去顯示提醒用戶。在本文中,將舉例子說明如何使用在Android 中使用 StrictMode。java
因爲在主線程中讀寫磁盤和進行網絡訪問都不是好的作法,Google已經在磁盤和網絡代碼中添加了嚴苛模式(StrictMode)鉤子(hook)。若是你對某個線程打開嚴苛模式(StrictMode),當那個線程進行磁盤和網絡訪問,你將得到警告。你能夠選擇警告方式。一些違例包含用戶慢速調用(custom slow calls 這麼翻譯行嗎?),磁盤讀寫,網絡訪問。你能選擇將警告寫入LogCat,顯示一個對話框,閃下屏幕,寫入DropBox日誌文件,或讓應用崩潰。最一般的作法是寫入LogCat或讓應用崩潰。android
目前,有兩大類的策略可供使用,一類是關於線程監控方面的:sql
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() .penaltyLog() .build());
另一類是關於VM虛擬機等方面的策略。
網絡
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder() .detectLeakedSqlLiteObjects() .penaltyLog() .penaltyDeath() .build());
經常使用的監控方面的策略有以下這些:
app
1)Disk Reads 磁盤讀ide
2)Disk Writes 磁盤寫函數
3)Network access 網絡訪問oop
4)Custom Slow Code 自定義的運行速度慢的代碼分析性能
前面三種的意思讀者應該很清楚,就是正如它們的名字所示,分別對磁盤的讀和寫,網絡訪問進行監控。而第四種的自定義慢代碼分析,是僅當訪問調用類的時後才觸發的,能夠經過這種方法去監視運行緩慢的代碼。當在主線程中調用時,這些驗證規則就會起做用去檢查你的代碼。好比,當你的應用在下載或者解析大量的數據時,你能夠觸發自定義運行速度慢代碼的查詢分析,做用很大。StrictMode能夠用於捕捉髮生在應用程序主線程中耗時的磁盤、網絡訪問或函數調用,能夠幫助開發者使其改進程序,使主線程處理UI和動畫在磁盤讀寫和網絡操做時變得更平滑,避免主線程被阻塞的發生。測試
而VM方面的策略重點關注以下幾類:
1)內存泄露的Activity對象
2)內存泄露的SQLite對象
3)內存泄露的釋放的對象
其中,內存泄露的Activity對象和內存泄露的SQLite對象都比較好理解,而所謂對關閉對象的檢查,主要是去監那些本該釋放的對象,好比應該調用close()方法的對象。
你不須要頻繁打開嚴苛模式(StrictMode),你能夠在主活動的onCreate()函數中打開它,你也能夠在Application派生類的OnCreate()函數中設置嚴苛模式(StrictMode)。線程中運行的任何代碼均可以設置嚴苛模式(StrictMode),但你的確只須要設置一次,一次就夠了。
當開發者違反某類規則時,每種策略都會有不一樣的方法令開發者知道當時的狀況。相關的違反狀況能夠記錄在LogCat中或者存儲在DropBox中(android.os.DropBox)服務中。而經常使用監控類的策略還會在當違規狀況發生時顯示相關的對話框和當時的上下文環境,全部的這些都爲了能讓開發者儘快地瞭解程序的瑕疵,以提交程序的質量。下面分步講解如何使用stritctmode。
第一步 啓用strictmode
爲了能在應用中啓用和配置StrictMode,開發者最好儘量在應用程序的生命週期的早段使用,方法是調用StrictMode的方法setThreadPolicy。當使用經常使用監控類的時候,一個最好的調用時機,是在應用中入口和activities被調用前進行。好比在一個應用程序中,能夠把代碼放在啓動Activity類的onCreate()方法中,下面是一個代碼示例,啓用了當前狀況下的全部策略及規則,當程序中出現違背經常使用的規則時,將會顯示相關的提示信息窗口:
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectAll() .penaltyLog() .penaltyDialog() ////打印logcat,固然也能夠定位到dropbox,經過文件保存相應的log .build()); StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll() .penaltyLog() .build());
固然,以上代碼只應在未發佈上線的測試版本的應用中運行以方便監視相關的運行狀況,當在生產版本上時不該該啓用strictmode。所以,最佳的代碼實踐應該爲以下的樣子:
public void onCreate() { if (DEVELOPER_MODE) { StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() .penaltyLog() .build()); } super.onCreate(); }
使用Eclipse調試環境,ADT自動爲你設置debuggable屬性,使項目更易於管理。當你在模擬器上或直接在設備上部署應用,debuggable屬性爲TRUE,當你導出應用創建一個產品版本,ADT將該屬性置爲FALSE。注意,若是你另行設置了這個屬性值,ADT不會改變它。
嚴苛模式(StrictMode)很不錯,不過在Android 2.3以前的版本上該模式不工做。爲了不這個問題,你要在StrictMode對象還不存在的時候就驗證版本是否在Android2.3及以上。你能利用反射技術(reflection),當嚴苛模式(StrictMode)函數有效時間接調用它,反之不去調用。方法很簡單,你能按列表2-12中的代碼處理
列表2-12 利用反射技術(reflection)調用嚴苛模式(StrictMode)
try { Class sMode = Class.forName("android.os.StrictMode"); Method enableDefaults = sMode.getMethod("enableDefaults"); enableDefaults.invoke(null); } catch(Exception e) { // StrictMode not supported on this device, punt Log.v("StrictMode", "... not supported. Skipping..."); }
當嚴苛模式(StrictMode)不存在,將捕捉到ClassNotFoundException異常。enableDefault()是嚴苛模式(StrictMode)類的另外一個函數,它檢測全部違例並寫入LogCat。由於這裏調用的是靜態形式的enableDefault(),因此用null做爲參數傳入。
某些時候你不但願報告全部違例。那在主線程以外的其餘線程中設置嚴苛模式(StrictMode)很不錯。譬如,你須要在正在監視的線程中進行磁盤讀取。此時,你要麼不去調用detectDiskReads(),要麼在調用detectAll()以後跟一個permitDiskReads()。相似容許函數也適用於其餘操做。但要是你要在Anroid2.3以前版本上作這些事,有辦法嗎?固然有。
當應用中嚴苛模式(StrictMode)無效,若是你試圖訪問它,將拋出一個VerifyError異常。若是你將嚴苛模式(StrictMode)封裝在一個類裏,並捕捉這個錯誤,當嚴苛模式(StrictMode)無效時,你能忽略它。
下面是一個簡單的嚴苛模式(StrictMode)封裝類StrictModeWrapper
public class StrictModeWrapper { public static void init(Context context) { // check if android:debuggable is set to true int appFlags = context.getApplicationInfo().flags; if ((appFlags & ApplicationInfo.FLAG_DEBUGGABLE) != 0) { StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() .penaltyLog() .build()); StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder() .detectLeakedSqlLiteObjects() .penaltyLog() .penaltyDeath() .build()); } } }
下面是如何在你的應用中使用這個封裝類:
try { StrictModeWrapper.init(this); } catch(Throwable throwable) { Log.v("StrictMode", "... is not available. Punting..."); }
第二步 運行strictmode
當應用啓用了strictmode模式時,其實跟普通的應用沒什麼兩樣,在測試和運行時,跟平時運行普通應用程序同樣就能夠了。當啓用了Strictmode模式時,會監視全部的程序運行狀況,當發現出現重大問題或違背策略規則時,會提示用戶。下面是當運行啓用了strictmode模式的應用時,當發現違背規則時,顯示給用戶的信息,細心觀察下跟普通的出錯信息有什麼不一樣吧。
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)
而且會出現以下的提示窗口,提示用戶:
忽略某些規則
應該說大部分由StrictMode產生的規則警示都應去遵照,但有時也不是全部產生的信息都代表你的程序有錯誤。好比,在應用程序的主線程中去快速讀寫磁盤其實不會對應用的性能產生太大的影響,又或者你在調試程序階段有一些調試的代碼違反了設定的規則,這些均可以忽略掉這些規則。
忽略規則有兩種方法,一種是單純在代碼中把Strictmode的代碼註釋掉,另一種比較好的方法是,在須要忽略的時候和地方,增長相應的代碼去讓系統中止使用這些規則去檢查,等開發者認爲有必要檢查時,再從新應用這些規則,好比:
StrictMode.ThreadPolicy old = StrictMode.getThreadPolicy(); StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder(old) .permitDiskWrites() .build()); doCorrectStuffThatWritesToDisk(); StrictMode.setThreadPolicy(old);
這裏首先用old來保存了當前的策略規則,而後doCorrectStuffThatWritesToDisk();
這裏,執行了一些向磁盤快速讀寫的操做,最後又從新啓用了這些規則。
小結
StrictMode是一個十分有用的類,它能夠很方便地應用於檢查Android應用程序的性能和存在的問題。當開啓這個模式後,開發者能很好地檢查應用中存在的潛在問題,更多的請參考Android文檔中的相關API說明。