Android學習筆記匯總

Activity相關

測試下來發(fā)現(xiàn)：onSaveInstanceState()在onStop之后調用，onRestoreInstanceState在onStart()之后調用。可以在ActivityThread類的callActivityOnStop()方法和handleStartActivity()方法中看出來。

Fragment相關

Fragment生命周期和Activity生命周期

activity_fragment_lifecycle.jpg
activity_lifecycle.jpg

fragment_lifecycle.jpg

Service相關

Android一般的進程優(yōu)先級劃分：

1.前臺進程 (Foreground process)
2.可見進程 (Visible process)
3.服務進程 (Service process)
4.后臺進程 (Background process)
5.空進程 (Empty process)

安卓系統(tǒng)，根據(jù)oom_adj, 占用內存大小，進程活躍程度，來綜合決定回收哪個進程。oom_adj 存儲在proc/PID/oom_adj文件中，其中PID是進程的id，直接 adb shell進入手機根目錄查看這個文件即可。

比如我現(xiàn)在進程是在最前面和我交互的，是前臺進程，進程id是18303，這樣查看。

1|HWNOH:/ $ cat /proc/18303/oom_adj
0
HWNOH:/ $

然后我退到后臺，再次查看。

1|HWNOH:/ $ cat /proc/18303/oom_adj
11
HWNOH:/ $

Android布局優(yōu)化之ViewStub、include、merge

BroadcastReceiver 相關

AsyncTask相關

Android 事件分發(fā)機制

Android View 繪制流程

Android Window、Activity、DecorView以及ViewRoot

Android的核心Binder多進程AIDL

AMS,WMS,PMS

git clone https://android.googlesource.com/platform/frameworks/base

替換成

git clone https://aosp.tuna.tsinghua.edu.cn/platform/frameworks/base

Android ANR

Android 內存相關

Android 屏幕適配

Android 緩存機制

Android 性能優(yōu)化

Android MVC、MVP、MVVM

Android Gradle 知識

RxJava

OkHttp

OkHttp是一個高效HTTP客戶端，原因如下：

  • HTTP/2支持請求同一個host的多個請求共享一個socket連接。
  • 連接池降低請求延遲（HTTP/2不可用的情況）。
  • 透明的GZIP壓縮下載體積。
  • 響應緩存，避免完全重復的request發(fā)起網(wǎng)絡請求，可以直接從緩存里面獲取響應。

當OkHttp遇到網(wǎng)絡問題的時候，它會靜默的從常見的連接問題中恢復。如果你的服務有多個IP地址，當?shù)谝淮芜B接失敗的時候，OkHttp會嘗試其他的地址。對于IPv4+IPv6以及服務放在多個數(shù)據(jù)中心的情況，這是很重要的。OkHttp支持先進的TLS（傳輸層安全協(xié)議）特性。

使用OkHttp很簡單。它的request/response API都是使用構建模式創(chuàng)建，并且是不可變的。OkHttp支持同步和異步請求。

HTTP1.0、HTTP1.1 和 HTTP2.0 的區(qū)別

三次握手四次揮手

  1. 主動結束端發(fā)送消息給被動結束端，說明主動結束端已經(jīng)沒有數(shù)據(jù)發(fā)送了。
  2. 被動結束端收到消息后，被動結束端的數(shù)據(jù)可能還沒有發(fā)送完畢，所以他先發(fā)送一個消息告訴主動結束端："我知道了"。
  3. 被動結束端數(shù)據(jù)發(fā)送完畢后，通知主動結束端：“我數(shù)據(jù)發(fā)送完了，可以關閉連接了?！?。
  4. 主動結束端發(fā)送一個消息給被動結束端，如果在兩倍超時間內沒有收到響應，就斷開連接。

Retrofit

Android 熱更新與插件化

Android組件化

卡頓相關

卡頓原因是什么，如何檢測卡頓，怎么判斷是頁面響應卡頓還是邏輯處理造成的卡頓？

卡頓原理是什么：60幀每秒是目前最合適的圖像顯示速度，也是絕大部分Android設備設置的調試頻率，如果在16ms內順利完成界面刷新操作可以展示出流暢的畫面，而由于任何原因導致接收到VSYNC信號的時候無法完成本次刷新操作，就會產(chǎn)生掉幀的現(xiàn)象，刷新幀率自然也就跟著下降(假定刷新幀率由正常的60fps降到30fps，用戶就會明顯感知到卡頓)

造成卡頓的常見原因：

  1. 過度繪制
  • 去除不必要的背景
  • 布局文件扁平化
  • merge、ViewStub標簽的使用
  1. UI線程中有耗時操作，I/O讀寫、數(shù)據(jù)庫訪問等；
  • 減少ui線程中的耗時操作
  1. 頻繁的GC
  • 避免內存抖動，瞬間創(chuàng)建大量的臨時對象。不要在for循環(huán)中去new對象或在onDraw方法中創(chuàng)建對象等。
  • 避免內存泄漏。

如何檢測卡頓？

  • StickMode
  • TraceView（已被棄用，考慮使用 Android Studio自帶的CPU Profiler）
  • AndroidPerformanceMonitor
  • ANR-WatchDog
  • Choreographer

推薦使用 AndroidPerformanceMonitor和Android Studio自帶的CPU Profiler

怎么判斷是頁面響應卡頓還是邏輯處理造成的卡頓？
關于運算阻塞導致的卡頓的分析可以使用TraceView（已被棄用，考慮使用 Android Studio自帶的CPU Profiler）android studio：profiler調試閃退解決方法

備注：我的理解頁面響應卡頓就是指布局過于復雜、過度繪制造成的卡頓。可以打開發(fā)開者選項里的OverDraw（調試GPU過度繪制）和GPU呈現(xiàn)模式來查看

  1. Android性能優(yōu)化（六）之卡頓那些事
  2. Android APP 卡頓問題分析及解決方案
  3. Android UI性能優(yōu)化 檢測應用中的UI卡頓

Handler 機制原理，IdleHandler 什么時候調用。

LeakCanary 原理，為什么檢測內存泄漏需要兩次？

我的理解為什么要檢測兩次？ 其實就是為了準確性唄。寧可錯殺一百，不愿放過一個。

  1. 如果在activity destroy以后并且在5秒鐘之后系統(tǒng)沒有進行gc，那么activity對象是沒有被回收的，此時我們檢測發(fā)現(xiàn)activity對象沒有被回收，然后我們再手動調用一次gc，gc過后，我們再檢測一次activity對象是否被回收，如果被回收了，那么結束，如果activity對象還是沒有被回收說明很可能出現(xiàn)了內存泄漏無法被回收，所以我們就并dump出當前的內存文件供之后進行分析。

屬性動畫、補間動畫、幀動畫的區(qū)別和使用場景；

APK 瘦身是怎么做？

冷啟動優(yōu)化

Android性能優(yōu)化（一）之啟動加速35%
https://zhuanlan.zhihu.com/p/86283192

RecyclerView相關

如何判斷一個 APP 在前臺還是后臺？

代碼可以參考
https://github.com/humanheima/ActivityDemo

如何做應用保活？全家桶原理？

Retrofit 在 OkHttp 上做了哪些封裝？

invalidate和requestLayout的區(qū)別

  1. requestLayout和invalidate 區(qū)別

Parcelable & Parcel

Parcel是一個可以通過IBinder來發(fā)送的消息 (data and object references) 容器。Parcel不是一個通用的序列化機制。Parcelable & Parcel和被設計成一個高性能的IPC傳輸。因此，Parcel數(shù)據(jù)不適合持久存儲（存儲在文件中）。

Parcelable的原理
如何將 Parcelable 保存到本地文件里

ButterKnife

加載超級大的圖片

SurfaceView 和 TextureView 的區(qū)別。

Android 打包流程

Android中的Dalvik和ART區(qū)別分析

進程管理

V1 V2 V3 簽名

Walle渠道包生成工具基于V2簽名：

對新的應用簽名方案生成的APK包中的ID-value進行擴展，提供自定義ID－value（渠道信息），并保存在APK中
而APK在安裝過程中進行的簽名校驗，是忽略我們添加的這個ID-value的，這樣就能正常安裝了
在App運行階段，可以通過ZIP的EOCD（End of central directory）、Central directory等結構中的信息（會涉及ZIP格式的相關知識，這里不做展開描述）找到我們自己添加的ID-value，從而實現(xiàn)獲取渠道信息的功能
新一代渠道包生成工具完全是基于ZIP文件格式和APK Signing Block存儲格式而構建，基于文件的二進制流進行處理，有著良好的處理速度和兼容性，能夠滿足不同的語言編寫的要求，目前筆者采用的是Java＋Groovy開發(fā)， 該工具主要有四部分組成： 1. 用于寫入ID-value信息的Java類庫 2. Gradle構建插件用來和Android的打包流程進行結合 3. 用于讀取ID-value信息的Java類庫 4. 用于供com.android.application使用的讀取渠道信息的AAR

這樣，每打一個渠道包只需復制一個APK，然后在APK中添加一個ID-value即可，這種打包方式速度非常快，對一個30M大小的APK包只需要100多毫秒（包含文件復制時間）就能生成一個渠道包，而在運行時獲取渠道信息只需要大約幾毫秒的時間。

下面的代碼獲取渠道信息：

WalleChannelReader的 getChannel 方法。

@Nullable
public static String getChannel(@NonNull final Context context) {
    return getChannel(context, null);
}

@Nullable
public static String getChannel(@NonNull final Context context, @NonNull final String defaultChannel) {
    final ChannelInfo channelInfo = getChannelInfo(context);
    if (channelInfo == null) {
        return defaultChannel;
    }
    return channelInfo.getChannel();
}

硬件加速相關

在Target API level >=14 硬件加速默認開啟。在 Android 里，硬件加速專指把View中繪制的計算工作交給 GPU來處理。啟用硬件加速需要更多資源，因此應用會占用更多內存。簡單來說，開啟硬件加速主要在繪制和執(zhí)行動畫的過程中可以提升性能。

WindowManagerService

WindowManagerService的作用：

  1. 窗口管理（WindowManager）
  2. 輸入系統(tǒng)的中轉站（InputManagerService）
  3. 窗口動畫（WindowAnimator）
  4. Surface管理（SurfaceFlinger）
最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容