1. 崩潰優化

2. 內存優化

內存的主要索引

Native Heap

對象 = null，內存會減少佔用麼？
https://www.zhihu.com/question/21356272

2.x 內存優化工具

Android Studio/Memory-Profiler

1 強制內存回收按鈕
2 Dump the Java heap
3 開始／停止記錄內存分配情況
4 縮小／放大時間線
5 實時播放內存分配情況（這個按鈕點下試試便清楚了）
6 發生一些事件的記錄(如Activity的跳轉，事件的輸入，屏幕的旋轉)
7 內存使用時間線

關於頂部的幾種內存類型介紹：
Java : java代碼分配的內存
Native:c/c++代碼分配的內存(有時候其實並沒有使用到c/c++代碼,但還是會有Native的內存分配，因爲Android Framework會去通過java代碼訪問一些需要使用Native的資源，如圖像資源Bitmap)
Graphics:圖像緩存等，包括GL surfaces, GL textures等.
Stack:棧內存（包括java和c/c++）
Code:代碼的內存分配（例如代碼，資源，libs等等），處理代碼和資源（如 dex 字節碼、經過優化或編譯的 dex 代碼、.so 庫和字體）的內存。
Other:這個是連繫統都不知道是什麼類型的內存，放在這裏.
Allocated: jave分配的對象個數 (在Android7.1和以下的設備，這個計數是在設備連接後開始，所以並不是app啓動時候的計數。Android8.0或更高，在系統裏面內置的Profiler工具，所以無論什麼時候連接，都是app啓動時候的計數)

參考文檔資料:https://www.jianshu.com/p/e75680772375
參考資料：https://developer.android.com/studio/profile/memory-profiler

Android Studio/Memory Monitor 觀察 Dalvik內存

dumpsys meminfo 觀察整體內存

smaps 觀察整體內存的詳細組成

Eclipse Memory Analyzer 詳細分析 Dalvik 內存

2.x 查看內存的相關命令

https://blog.csdn.net/bigconvience/article/details/35553983
procrank
dumpsys meminfo <package_name>

PSS：表示一個進程在RAM中實際使用的空間地址大小，它按比例包含了共享庫佔用的內存。假如有3個進程使用同一個共享庫，那麼每個進程的PSS就包括了1/3大小的共享庫內存。這種方式表示進程的內存使用情況較準確，但當只有一個進程使用共享庫時，其情況和RSS一模一樣。
USS：表示一個進程本身佔用的內存空間大小，不包含其它任何成分，這是表示進程內存大小的最好方式！
可以看到:VSS>=RSS>=PSS>=USS

參考資料

https://developer.android.google.cn/topic/performance/memory

3. 卡頓優化

對用戶來說，內存佔用高，耗費電量，耗費流量可能不容易被發現(放屁)，但是用戶對於卡頓特別敏感；對於開發者來說，卡頓的問題確實非常難以排查定位，產生的原因錯綜複雜，跟 CPU，內存，磁盤I/O 等都有可能有關，與系統環境也有很大關係；

到底如何定位卡頓呢？本地有哪些工具能幫助我們更好的發現和排查問題呢？工具之間的差異又是？

3.1 基礎知識

造成卡頓的原因千百種，不過最終都反應在CPU時間上；CPU時間分爲 用戶時間(執行用戶態應用程序代碼所消耗的時間) 和 系統時間(執行內核態系統調用所耗費的時間，包括I/O，鎖，終端以及其它系統調用的時間)。

1.CPU性能
CPU的性能需要看主頻，核心，緩存等參數，具體表現在計算能力和指令執行能力；
智能電視有以下廠商：
臺灣：晨星 Mstar、聯發科MTK、瑞昱 Realtek
內地：晶晨 Amlogic、海思 Hisilicon、全志 Allwinner、瑞芯微 Rockchip
晨星 Mstar是目前智能電視的芯片主流品牌，對智能電視的畫質有着先進處理基礎。
好像近幾年，Amlogic 又異軍突起了，性能不僅不錯，而且售價更加低廉… …我們公司最近也準備採用 Amlogic方案；

可以通過下面的方法獲得設備的CPU信息：

獲取CPU核心數
/sys/devices/system/cpu/possible
獲取某個CPU的頻率
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq

隨着機器學習與AI的崛起，電視的CPU不僅有強大的GPU，還攜帶了NPU。
所以，在電視開發中，可以根據設備的CPU性能寫代碼以及優化，例如線程池使用線程數根據CPU的核心數，一些高級的AI功能只在主頻比較高或者帶NPU的設備開啓。

2.卡頓問題分析指標
回到CPU時間，也就是用戶時間和系統時間

3.2 Andorid 卡頓排查工具

1.TraceView 尋找卡主主線程的地方

關注兩個點：1.很耗時的函數 Incl Cpu Time(CPU佔用時長) 2. 調用頻繁的函數. Calls + Recur Calls / Total(調用次數)

// 代碼可以插入:
Debug.startMethodTracing("TestApp");
...
Debug.stopMethodTracing();
// 會在sdcard上生成一個”TestApp.trace”的文件.
// android 9.0 在 /sdcard/Android/data/xxx.xxx.xxx/files

使用 monitor ，打開導出的 files 下面的文件

2.Nanoscope

3.systrace

Trace.beginSection
Trace.endSection

4.Simpleperf

3.3 可視化方法

1.Call Chart
2.Flame Chart

3.4 如何監控應用卡頓

3.5 卡頓現場與卡頓分析

3.6 總結

3.7 參考資料

新的流暢體驗，90Hz 漫談

4. UI優化

UI渲染依賴兩個核心硬件：CPU 與 GPU；
Rasterization（柵格化）操作是一個非常耗時的操作,GPU可以加快柵格化操作；

繪製過程主要是由 CPU 來進行 Measure、Layout、Record、Execute的數據計算工作，GPU 負責柵格化、渲染。
所謂的柵格化就是繪製那些Button，Shape，Path，String，Bitmap等組件最基礎的操作；

官方長期重視 Android UI 渲染性能，基本每次I/O大會囉嗦一番；每個開發者都希望自己的應用可以做到 60 fps 如絲般順滑，相比IOS系統，渲染性能一直被吐槽；

Android爲了彌補和IOS的差距，每個版本都做了大量的優化；瞭解 Android 圖形系統整體架構，以及它包含的主要組件；

繪製過程各個圖形組件的作用：

畫筆：Skia(繪製2D圖形，使用CPU繪製) 或 OpenGL(繪製2D/3D圖形，使用GPU繪製)；
畫紙：Surface。所有的元素都在 Surface 這張畫紙上進行繪製和渲染。在 Android 中，Window 是 View 的容器，每個窗口都會關聯一個 Surface。而 WindowManager 則負責管理這些窗口，並且把它們的數據傳遞給 SurfaceFlinger。
畫板：Graphic Buffer。Graphic Buffer 緩衝用於應用程序圖形的繪製，在 Android 4.1 之前使用的是雙緩衝機制；在 Android 4.1 之後，使用的是三緩衝機制
顯示：SurfaceFlinger。它將 WindowManager 提供的所有 Surface，通過硬件合成器 Hardware Composer 合成並輸出到顯示屏。

4.1 硬件加速

Android 3.0 之前，沒有硬件加速時，系統會使用軟件方式來渲染UI

整個流程如上圖所示：

Surface：每個 View 都由某一個窗口管理，而每一個窗口都關聯有一個 Surface。
Canvas。
Canvas：通過 Surface 的 lock 函數獲得一個 Canvas，Canvas 可以簡單理解爲 Skia 底層接口的封裝。
Graphic Buffer：SurfaceFlinger 會幫我們託管一個BufferQueue，我們從 BufferQueue 中拿到 Graphic Buffer，然後通過 Canvas 以及 Skia 將繪製內容柵格化到上面。
SurfaceFlinger：通過 Swap Buffer 把 Front Graphic Buffer 的內容交給 SurfaceFinger，最後硬件合成器 Hardware Composer 合成並輸出到顯示屏。

CPU 對於圖形處理並不是很高效，過程完全沒有利用到GPU的高性能；所以從 Android 3.0開始支持硬件加速，Android 4.0時，默認開啓；

硬件加速與軟件繪製差異非常大，最核心是通過 GPU 完成 Graphic Buffer 的內容繪製；
硬件繪製還引入 DisplayList 的概念，每個View內部都有一個 DisplayList，當某個View 需要重繪時，標記爲 Dirty。
當需要繪製時，硬件繪製僅僅只需要重繪一個 View 的 DisplayList，軟件繪製時需要向上遞歸。
硬件加速大大減少繪圖的操作數量，所以提高了渲染效率。
如下圖所示：

4.2 Projbect Buffer

2012 I/O 大會宣佈 Project Butter(包含兩個部分：1. VSYNC，2. Triple Buffering) 黃油計劃，並在 Android 4.1 正式開啓這個機制。

VSYNC信號
對於 Android 4.0，CPU繁忙，可能會導致UI繪製來不及處理；
爲了解決此問題，Project Buffer 引入 VSYNC(官方文檔)

三緩存機制 Triple Buffering

GPU 渲染模式分析演示

參考資料

深入淺出 Android 屏幕刷新原理
 Android繪製優化（一）繪製性能分析
 Android性能優化第（四）篇—Android渲染機制
 Android的UI底層是用CPU繪圖的還是GPU繪圖的呢？以及surfaceview,window,普通view是如何實現的？
深入Android渲染機制

5. 啓動優化

6.存儲優化

7. 網絡優化

8. 耗電優化

9. I/O 優化

10. 體積優化

apkchecker

`11. 安全`

反破解包括幾個方面：靜態分析，動態調試，防止重編譯
11.1.靜態分析：

代碼混淆技術
NDK保護，Native代碼；
外殼保護(代碼加密技術)，UPX加殼工具，市面上也有相關的加固平臺；

11.2.動態調試：

檢測調試器，android:debuggable=“false”，讓程序不可以調試，代碼判斷如下：

if ((getApplicationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE) != 0) {
	android.os.Process.killProcess(android.os.Process.myPid());
}
// 也可以判斷是否有調試器連接
android.os.Debug.isDebuggerConnected()

檢測模擬器

ro.product.model: sdk，手機的值爲 手機的型號；
ro.build.tags：test-keys，手機的值爲 release-keys；
ro.kernel.qemu：模擬器爲 1，正常手機沒有該屬性；

DroidBox 一款開源的Android程序動態分析工具
在線Android軟件的靜態與動態分析 http://mobilesandbox.org

11.3.動態調試：

檢查簽名
校驗保護：判斷classes.dex文件的Hash值

`性能配置`

CPU 的性能

`APM平臺支持`

俗話說的話，剩下還得靠監控(卡頓，網絡，幀率，)的
市場上有很多商業化的 APM 平臺，比如著名的 NewRelic，還有國內的聽雲
、OneAPM 等等。

參考資料

Android 性能優化必知必會(2020-5-16)

andoird 優化學習筆記

文章目錄

1. 崩潰優化

2. 內存優化

2.x 內存優化工具

2.x 查看內存的相關命令

參考資料

3. 卡頓優化

3.1 基礎知識

3.2 Andorid 卡頓排查工具

3.3 可視化方法

3.4 如何監控應用卡頓

3.5 卡頓現場與卡頓分析

3.6 總結

3.7 參考資料

4. UI優化

4.1 硬件加速

4.2 Projbect Buffer

參考資料

5. 啓動優化

6.存儲優化

7. 網絡優化

8. 耗電優化

9. I/O 優化

10. 體積優化

`11. 安全`

`性能配置`

`APM平臺支持`

參考資料

Android動畫了解—擴展知識

Android動畫了解—視圖動畫

硅谷來信筆記整理

Android動畫了解—RecyclerView Animator

Android動畫了解—屬性動畫(Property Animation)

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結