本文微信公衆號「AndroidTraveler」首發。
背景
最近部門有新入職員工，作爲規劃技術路線的導師，這邊給新員工安排了學習路線。
除了基本的學習路線之外，每次溝通，我都留了一個小問題，讓小夥伴去思考。
這些問題有些是剛接觸 Android 開發的小夥伴所不熟悉的，有些則是部分初級工程師都沒有注意到的。
因此這邊紀錄一下，希望幫助剛畢業進入職場的 Android 小夥伴，或是對這些還不是很熟悉的 Android 開發工程師們。
如有補充或者交流，歡迎留言。
第一點：ANR 的其中一個條件並不是在 Activity 主線程做耗時任務
Q： 你是否瞭解過 ANR？
A： 知道，但不是很瞭解。
Q： 什麼情況下會出現 ANR？
假設這裏回答的不是“在主線程執行耗時任務”的話，可以不繼續追問，直接讓小夥伴去了解 ANR，後期再討論。
如果回答了是“在主線程執行耗時任務”的話，那麼繼續：
Q： 多久算耗時？
A： 不要超過 5s。
Q： 那麼假設我在 Activity sleep 20s，是不是就一定會 ANR？
上代碼例子：
MainActivity.java 文件：
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
findViewById(R.id.button).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
Log.e("zengyu","before sleep");
try {
Thread.sleep(20000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Log.e("zengyu","after sleep");
}
});
}
}activity_main.xml 文件：
<?xml version="1.0" encoding="utf-8"?>
<android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">
<Button
android:id="@+id/button"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_marginTop="8dp"
android:text="Button"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent" />
</android.support.constraint.ConstraintLayout>代碼功能很簡單，就是一個按鈕，點擊之後會 sleep 20 秒。在 sleep 前和 sleep 後都會打印日誌。
如果你只是點擊按鈕，然後什麼都不動，是不會有 ANR 的。
但是你點擊了按鈕之後，你繼續多次點擊按鈕，那麼就會有 ANR 了。
以下四個條件都可以造成ANR發生：
InputDispatching Timeout： 5秒內無法響應屏幕觸摸事件或鍵盤輸入事件
BroadcastQueue Timeout ： 在執行前臺廣播（BroadcastReceiver）的onReceive()函數時10秒沒有處理完成，後臺爲60秒。
Service Timeout ： 前臺服務20秒內，後臺服務在200秒內沒有執行完畢。
ContentProvider Timeout ： ContentProvider的publish在10s內沒進行完。
所以可能很多小夥伴會把上面四個條件的第一個和 Activity 直接掛鉤，以爲是在主線程耗時超過 5s 就會 ANR。實際上是 InputDispatching。
第二點：子線程使用
Q： 既然主線程不能做耗時任務，那麼有耗時任務怎麼辦？
A： 通過 new Thread 啓動一個子線程，在子線程處理。
Q： 考慮一個場景，比如類似微信這類 IM 軟件收到消息。需要寫數據庫，這個時候需要啓動線程。當收到消息 N 多的時候，如果都用 new Thread 啓動線程的話，是否會有問題。場景模擬可以通過循環創建子線程模擬。
上代碼例子：
MainActivity.java 文件：
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
for (int i = 0; i < 10000; i++) {
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
}
}這個部分手機廠商比如（華爲）有對線程數目做限制的話，一運行就會 crash，Logcat 會看到下面信息：
pthread_create (1040KB stack) failed: Out of memory我這邊一開始在三星 S7 上面運行，並沒有出現。後面換成華爲 5x 手機就出現了。
Android 開發的小夥伴都知道兼容是硬傷，所以我們不能抱有僥倖心理。
針對這種情況，我們不能一遇到耗時任務，就很瀟灑的一個 new Thread 全部搞定。
如果你當前界面只有一個耗時任務，而且只需要調用一次，那麼你進入該界面用 new Thread 來處理沒有問題。
但是假設像上面我們描述的場景那樣，需要調用多次的時候。你就不能簡單粗暴的使用 new Thread 了。
推薦方式是使用線程池。
一個原因是避免一些廠商的線程數目限制。
另一個原因是減少線程的頻繁創建和銷燬。
第三點：內部類都可能存在的問題
Q： 上面我們說到了，如果界面調用一次，而且需要啓動線程的時候。可以使用 new Thread 創建，那麼直接使用 new Thread 可能還有什麼問題嗎？
這裏想考察的點可能比較晦澀一點。
由於內部類會持有外部類的引用。假設在 Activity 裏面通過匿名內部類的方式來啓動線程做耗時任務。當用戶退出界面時，由於內部類還持有 Activity 的引用，因此 Activity 沒法得到釋放。
就會存在內存泄漏問題。
解決方法也比較統一，那就是將內部類改爲靜態內部類。
所以修改後的代碼對比如下：
修改前：
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new Thread(new Runnable() {
@Override
public void run() {
//TODO
}
}).start();
}
}修改後：
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new StaticThread().start();
}
private static class StaticThread extends Thread {
@Override
public void run() {
super.run();
//TODO
}
}
}第四點：弱引用場景應用
Q： 用過 Handler 嗎？
A： 用過。
Q： 寫一下簡單的 demo 我看下。
這個是緊接第三點。如果不涉及界面交互，只需要使用到靜態內部類就可以解決。但是當 Handler 裏面需要做界面更新處理時，那麼需要使用弱引用。因爲靜態內部類的處理方式本來就是爲了避免 Activity 無法得到釋放。你如果把 Activity 直接傳進來，那麼 Activity 的引用被靜態內部類持用了，所以這個時候就需要使用到弱引用了。
直接上代碼：
public class MainActivity extends AppCompatActivity {
private static class StaticHandler extends Handler {
private WeakReference<MainActivity> activityWeakReference;
public StaticHandler(MainActivity mainActivity) {
this.activityWeakReference = new WeakReference<>(mainActivity);
}
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
//TODO
//use activityWeakReference.get() to get view
}
}
private StaticHandler mStaticHandler = new StaticHandler(this);
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mStaticHandler.sendEmptyMessage(0);
}
}第五點：持久化 SharedPreferences 的使用
一般很多網上教程和例子在 SharedPreferences 的數據寫入時，一般都會使用 Editor 的 commit 方法。
由於 commit 方法是同步寫入的。並且寫文件屬於 I/O 操作，如果你有大量的數據需要寫入，並且你是在主線程處理的，可能會導致流暢性受影響。極端情況下可能會出現 ANR。
我們點進去源碼看下：
If you don't care about the return value and you're using this from your application's main thread, consider using {@link #apply} instead.其實源碼也說的很清楚了。如果你不關心返回值並且你是在應用的主線程使用的話，考慮使用 apply 替換 commit。
由於我們一般不會處理返回值，因此建議使用 apply 替換 commit。
apply 會把變化馬上寫進內存，然後通過異步方式去寫入。
Unlike {@link #commit}, which writes its preferences out to persistent storage synchronously, {@link #apply} commits its changes to the in-memory {@link SharedPreferences} immediately but starts an asynchronous commit to disk and you won't be notified of any failures.當然源碼還有一個註釋如下：
If another editor on this {@link SharedPreferences} does a regular {@link #commit} while a {@link #apply} is still outstanding, the {@link #commit} will block until all async commits are completed as well as the commit itself.大概意思就是 apply 如果在處理中還未完成的情況下，commit 會阻塞直到所有異步操作完成纔會去 commit。
因此如果要替換，建議將 commit 都替換爲 apply。
第六點：數據庫相關處理
這裏主要是考慮類似微信 IM 登錄後拉取大量離線消息寫入數據庫的問題。
通過對比開啓事務和不開啓事務的耗時來進行說明。
比如不開啓事務插入 10000 條紀錄和開啓事務插入 10000 條紀錄耗時對比。
對於大量的數據庫操作，建議開啓事務的方式，速度的提升是很明顯的。
參考鏈接：
Android ANR：原理分析及解決辦法
