<span id="ubbei"><video id="ubbei"></video></span>
<span id="ubbei"></span>
<span id="ubbei"><video id="ubbei"></video></span>
<strike id="ubbei"><video id="ubbei"></video></strike><th id="ubbei"></th>
<span id="ubbei"><video id="ubbei"></video></span><span id="ubbei"></span><span id="ubbei"><video id="ubbei"></video></span>
<th id="ubbei"><video id="ubbei"><span id="ubbei"></span></video></th>
<span id="ubbei"></span>
<th id="ubbei"><video id="ubbei"><span id="ubbei"></span></video></th><strike id="ubbei"><dl id="ubbei"><ruby id="ubbei"></ruby></dl></strike>
<span id="ubbei"></span>
<th id="ubbei"></th>
<span id="ubbei"></span>
<th id="ubbei"></th>
<span id="ubbei"></span>
<span id="ubbei"></span>
<span id="ubbei"></span>
<span id="ubbei"><video id="ubbei"><strike id="ubbei"></strike></video></span>
<strike id="ubbei"><video id="ubbei"></video></strike>

  • <output id="ubbei"></output>
          1. <li id="ubbei"><s id="ubbei"><strong id="ubbei"></strong></s></li>
          2. Android中一個簡單有用的發現性能問題的方法

            在Android中,性能優化是我們持之不懈的工作。這其中,在主線程執行耗時的任務,可能會導致界面卡頓,甚至是ANR(程序未響應)。當然Android提供了很多優秀的工具,比如StrictMode,Method Tracing等,便于我們檢測問題。

            這里,本文將介紹一個更加簡單有效的方法。相比StrictMode來說更加便于發現問題,相比Method Tracing來說更加容易操作。

            首先,我們有這樣一個程序代碼

            @Override
            protected void onCreate(Bundle savedInstanceState) {
                super.onCreate(savedInstanceState);
                setContentView(R.layout.activity_main);
                writeContentToFile();
            }
            
            private void writeContentToFile() {
                File log = new File(Environment.getExternalStorageDirectory(), "Log.txt");
                Writer outWriter = null;
                try {
                    outWriter = new BufferedWriter(new FileWriter(log.getAbsolutePath(), false));
                    outWriter.write(new Date().toString());
                    outWriter.write(" : \n");
                    outWriter.flush();
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    if (outWriter != null) {
                        try {
                            outWriter.close();
                        } catch (IOException e) {
                            e.printStackTrace();
                        }
                    }
                }
            }
            

            上面的代碼需要優化,因為

            • writeContentToFile 是一個本地文件寫操作,比較耗時
            • 而writeContentToFile 這個方法卻放在了主線程中,必然會阻塞主線程其他的工作順利執行。

            上面介紹StrictMode和Method Traing都可以檢測這個問題,這里我們我們用一個更簡單的方法

            public void checkWorkerThread() {
                boolean isMainThread = Looper.myLooper() == Looper.getMainLooper();
                if (isMainThread) {
                    if (BuildConfig.DEBUG) {
                        throw new RuntimeException("Do not do time-consuming work in the Main thread");
                    }
                }
            }
            

            這段方法有幾點注意的。

            • 主線程判斷,使用 Looper.myLooper() == Looper.getMainLooper() 可以準確判斷當前線程是否為主線程。
            • BuildConfig.DEBUG 條件控制,只有在debug環境下拋出異常,給予開發者明顯的提示。當然也可以使用自定義的是否拋出異常的邏輯
            • 如果當前線程不是主線程,那么就被認為是工作者線程。

            比如上面的方法加入checkWorkerThread檢查

            private void writeContentToFile() {
                checkWorkerThread();
                //代碼省略,具體實現參考上面
            }
            

            再次執行程序,會曝出異常。

            java.lang.RuntimeException: Unable to start activity ComponentInfo{com.droidyue.checkthreadsample/com.droidyue.checkthreadsample.MainActivity}: java.lang.RuntimeException: Do not do time-consuming work in the Main thread
                      at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2664)
                      at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2733)
                      at android.app.ActivityThread.access$900(ActivityThread.java:187)
                      at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1584)
                      at android.os.Handler.dispatchMessage(Handler.java:111)
                      at android.os.Looper.loop(Looper.java:194)
                      at android.app.ActivityThread.main(ActivityThread.java:5869)
                      at java.lang.reflect.Method.invoke(Native Method)
                      at java.lang.reflect.Method.invoke(Method.java:372)
                      at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1019)
                      at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:814)
             Caused by: java.lang.RuntimeException: Do not do time-consuming work in the Main thread
                      at com.droidyue.checkthreadsample.MainActivity.checkWorkerThread(MainActivity.java:34)
                      at com.droidyue.checkthreadsample.MainActivity.writeContentToFile(MainActivity.java:40)
                      at com.droidyue.checkthreadsample.MainActivity.onCreate(MainActivity.java:27)
                      at android.app.Activity.performCreate(Activity.java:6127)
                      at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1123)
                      at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2617)
                      ... 10 more
            

            通過分析crash stacktrace 我們可以很輕松的發現問題的根源并解決。

            哪些方法需要加上檢查

            • 本地IO讀寫
            • 網絡操作
            • Bitmap相關的縮放等
            • 其他耗時的任務

            如何選擇工作者線程

            Android中的工作者線程API有很多,簡單的有Thread,AsyncTask,也有ThreadPool,HandlerThread等。關于如何選擇,可以參考這篇文章。 關于Android中工作者線程的思考

            對比

            • StrictMode 是一把利器,但是檢測的東西很多,打印出來的日志可能也有很多,查找定位問題可能不如文章的方法方便。
            • Method Tracing,需要刻意并時不時進行設置start和stop操作,文章的方法,可以說是一勞永逸。

            檢測會不會有性能問題

            • 理論上是不會的,通常這個檢測的代價要遠遠比耗時任務要小很多。
            • 如果想進一步優化的,可以在編譯期屏蔽這個方法的調用,即assumenosideeffects,具體可以參考 關于Android Log的一些思考 中的編譯期屏蔽 的內容。

            延伸閱讀

            當你剛剛寫完一個方法時,考慮這一下這個方法會不會很耗時,如果耗時,不妨增加一個線程的check。注意,一定要加載debug版,不要影響到線上的用戶。

            我來評幾句
            登錄后評論

            已發表評論數()

            相關站點

            +訂閱
            熱門文章
            陕西高频十一选五