前言：
與其每天渾水摸魚、渾渾噩噩，不如多進階學習，提升自己的競爭力，
Android中高級必會知識點：
一、性能優化
1、APP穩定性優化
1.做過哪些穩定性方面的優化？
2.性能穩定性是怎么做的？
3.業務穩定性如何保障？
4.如果出現例外，怎樣快速止損？
2、APP啟動速度優化
1.啟動優化原理是什么？
2.是怎么異步的，異步遇到過什么問題嗎？
3.啟動優化有哪些容易被忽略的地方？
4.版本迭代導致的啟動變慢有好的解決方式嗎？
1、出現 ANR 的情況
滿足下面的一種情況系統就會彈出 ANR 提示
輸入事件(按鍵和觸摸事件) 5s 內沒被處理；
BroadcastReceiver 的事件 ( onRecieve() 方法) 在規定時間內沒處理完 (前臺廣播為 10s，后臺廣播為 60s)；
Service 前臺 20s 后臺 200s 未完成啟動；
ContentProvider 的 publish() 在 10s 內沒進行完，
通常情況下就是主執行緒被阻塞造成的，
2、ANR 的實作原理
以輸入無回應的程序為例（基于 9.0 代碼）：
最終彈出 ANR 對話框的位置是與 AMS 同目錄的類 AppErrors 的 handleShowAnrUi() 方法，這個類用來處理程式中出現的各種錯誤，不只 ANR，強行 Crash 也在這個類中處理，
// base/core/java/com/android/server/am/AppErrors.java
void handleShowAnrUi(Message msg) {
Dialog dialogToShow = null;
synchronized (mService) {
AppNotRespondingDialog.Data data = (AppNotRespondingDialog.Data) msg.obj;
// ...
Intent intent = new Intent("android.intent.action.ANR");
if (!mService.mProcessesReady) {
intent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY
| Intent.FLAG_RECEIVER_FOREGROUND);
}
mService.broadcastIntentLocked(null, null, intent,
null, null, 0, null, null, null, AppOpsManager.OP_NONE,
null, false, false, MY_PID, Process.SYSTEM_UID, 0 /* TODO: Verify */);
boolean showBackground = Settings.Secure.getInt(mContext.getContentResolver(),
Settings.Secure.ANR_SHOW_BACKGROUND, 0) != 0;
if (mService.canShowErrorDialogs() || showBackground) {
dialogToShow = new AppNotRespondingDialog(mService, mContext, data);
proc.anrDialog = dialogToShow;
} else {
MetricsLogger.action(mContext, MetricsProto.MetricsEvent.ACTION_APP_ANR,
AppNotRespondingDialog.CANT_SHOW);
// Just kill the app if there is no dialog to be shown.
mService.killAppAtUsersRequest(proc, null);
}
}
// If we've created a crash dialog, show it without the lock held
if (dialogToShow != null) {
dialogToShow.show();
}
}
不過從發生 ANR 的地方呼叫到這里要經過很多的類和方法，最初拋出 ANR 是在 InputDispatcher.cpp 中，我們可以通過其中定義的常量來尋找最初觸發的位置：
// native/services/inputflinger/InputDispatcher.cpp
constexpr nsecs_t DEFAULT_INPUT_DISPATCHING_TIMEOUT = 5000 * 1000000LL; // 5 sec
從這個類觸發的位置會經過層層傳遞達到 InputManagerService 中
// base/services/core/java/com/android/server/input/InputManagerService.java
private long notifyANR(InputApplicationHandle inputApplicationHandle,
InputWindowHandle inputWindowHandle, String reason) {
return mWindowManagerCallbacks.notifyANR(
inputApplicationHandle, inputWindowHandle, reason);
}
這里的 mWindowManagerCallbacks 就是 InputMonitor ：
// base/services/core/java/com/android/server/wm/InputMonitor.java
public long notifyANR(InputApplicationHandle inputApplicationHandle,
InputWindowHandle inputWindowHandle, String reason) {
// ... 略
if (appWindowToken != null && appWindowToken.appToken != null) {
final AppWindowContainerController controller = appWindowToken.getController();
final boolean abort = controller != null
&& controller.keyDispatchingTimedOut(reason,
(windowState != null) ? windowState.mSession.mPid : -1);
if (!abort) {
return appWindowToken.mInputDispatchingTimeoutNanos;
}
} else if (windowState != null) {
try {
// 使用 AMS 的方法
long timeout = ActivityManager.getService().inputDispatchingTimedOut(
windowState.mSession.mPid, aboveSystem, reason);
if (timeout >= 0) {
return timeout * 1000000L; // nanoseconds
}
} catch (RemoteException ex) {
}
}
return 0; // abort dispatching
}
然后回在上述方法呼叫 AMS 的 inputDispatchingTimedOut() 方法繼續處理，并最終在 inputDispatchingTimedOut() 方法中將事件傳遞給 AppErrors
// base/services/core/java/com/android/server/am/ActivityManagerService.java
public boolean inputDispatchingTimedOut(final ProcessRecord proc,
final ActivityRecord activity, final ActivityRecord parent,
final boolean aboveSystem, String reason) {
// ...
if (proc != null) {
synchronized (this) {
if (proc.debugging) {
return false;
}
if (proc.instr != null) {
Bundle info = new Bundle();
info.putString("shortMsg", "keyDispatchingTimedOut");
info.putString("longMsg", annotation);
finishInstrumentationLocked(proc, Activity.RESULT_CANCELED, info);
return true;
}
}
mHandler.post(new Runnable() {
@Override
public void run() {
// 使用 AppErrors 繼續處理
mAppErrors.appNotResponding(proc, activity, parent, aboveSystem, annotation);
}
});
}
return true;
}
當事件傳遞到了 AppErrors 之后，它會借助 Handler 處理訊息也就呼叫了最初的那個方法并彈出對話框，
參考：《Android ANR原理分析》
3、ANR 的解決辦法
上面分析了 ANR 的成因和原理，下面我們分析下如何解決 ANR.
1. 使用 adb 匯出 ANR 日志并進行分析
發生 ANR的時候系統會記錄 ANR 的資訊并將其存盤到 /data/anr/traces.txt 檔案中（在比較新的系統中會被存盤都 /data/anr/anr_* 檔案中），我們可以使用下面的方式來將其匯出到電腦中以便對 ANR 產生的原因進行分析：
adb root
adb shell ls /data/anr
adb pull /data/anr/<filename>
在筆者分析 ANR 的時候使用上述指令嘗試匯出 ANR 日志的時候都出現了 Permission Denied，此時，你可以將手機 Root 之后匯出，或者嘗試修改檔案的讀寫權限，或者在開發者模式中選擇將日志匯出到 sdcard 之后再從 sdcard 將日志發送到電腦端進行查看
2. 使用 DDMS 的 traceview 進行分析
在 AS 中打開 DDMS，或者到 SDK 安裝目錄的 tools 目錄下面使用 monitor.bat 打開 DDMS，
TraceView 工具的使用可以參考這篇文章：《Android 性能分析之TraceView使用(應用耗時分析)》
這種定位 ANR 的思路是：使用 TraceView 來通過耗時方法呼叫的資訊定位耗時操作的位置，
資料：
- 《ANR 官方檔案》
- 《Android 性能分析之TraceView使用(應用耗時分析)》
3. 使用開源專案 ANR-WatchDog 來檢測 ANR
專案地址是 Github-ANR-WatchDog
該專案的實作原理：創建一個檢測執行緒，該執行緒不斷往 UI 執行緒 post 一個任務，然后睡眠固定時間，等該執行緒又一次起來后檢測之前 post 的任務是否運行了，假設任務未被運行，則生成 ANRError，并終止行程，
4. 常見的 ANR 場景
I/O 阻塞
網路阻塞
多執行緒死鎖
由于回應式編程等導致的方法死回圈
由于某個業務邏輯執行的時間太長
5. 避免 ANR 的方法
UI 執行緒盡量只做跟 UI 相關的作業；
耗時的作業 (比如資料庫操作，I/O，網路操作等)，采用單獨的作業執行緒處理；
用 Handler 來處理 UI 執行緒和作業執行緒的互動；
使用 RxJava 等來處理異步訊息，
最后
其實Android開發的知識點就那么多，面試問來問去還是那么點東西，所以面試沒有其他的訣竅，只看你對這些知識點準備的充分程度，so，出去面試時先看看自己復習到了哪個階段就好，
上面分享的百度、騰訊、網易、位元組跳動、阿里等公司2021年的高頻面試題，博主還把這些技術點整理成了視頻和PDF（實際上比預期多花了不少精力），包含知識脈絡 + 諸多細節，由于篇幅有限，上面只是以圖片的形式給大家展示一部分，
Android學習PDF+學習視頻+面試檔案+知識點筆記
【Android思維腦圖（技能樹）】
知識不體系？這里還有整理出來的Android進階學習的思維腦圖，給大家參考一個方向，
【Android高級架構視頻學習資源】
F+學習視頻+面試檔案+知識點筆記](https://docs.qq.com/doc/DSkNLaERkbnFoS0ZF)
【Android思維腦圖（技能樹）】
知識不體系？這里還有整理出來的Android進階學習的思維腦圖，給大家參考一個方向，
[外鏈圖片轉存中…(img-Tcy2Rd93-1623417596908)]
【Android高級架構視頻學習資源】
**Android部分精講視頻領取學習后更加是如虎添翼！**進軍BATJ大廠等（備戰）！現在都說互聯網寒冬，其實無非就是你上錯了車，且穿的少（技能），要是你上對車，自身技術能力夠強，公司換掉的代價大，怎么可能會被裁掉，都是淘汰末端的業務Curd而已！現如今市場上初級程式員泛濫，這套教程針對Android開發工程師1-6年的人員、正處于瓶頸期，想要年后突破自己漲薪的，進階Android中高級、架構師對你更是如魚得水，趕快領取吧！
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/287184.html
標籤：其他