Android性能優化一內存優化

在Android 使用的是davilk虛擬機它和java虛擬機相似可是它是使用基於寄存器的 java基於棧的
davilk虛擬機的編譯出來的文件也不一樣它是擁有一個dex文件有多個class 而java虛擬機是一個文件對應一個classjava

davilk虛擬機是先編譯成class 文件而後經過 dx 工具在打包成一個dex文件。android

一個android app 就是一個davilk虛擬機它是由zygote進程中davilk虛擬機複製過來的。web

adb shell cat /system/build.prop 查看系統設置最大 java object heap 的大小

在Android啓動中 davilk虛擬機 java object heap size navtive heap size
java object heap 是有限制的能夠經過 root adb shell cat /system/build.prop 來查看 navtive heap size 大機率是沒有限制shell

adb shell cat /proc/pid/oom_adj 查看當前app所處於的進程

android 的前臺進程 0 可見進程後臺進程 11 服務5 服務8 空進程 -11--16markdown

若是兩個進程都是後臺進程 11 那麼誰佔用的內存大就回收誰。因此內存回收很是重要網絡

如何查看 adb shell cat /proc/pid/oom_adjapp

OOM問題：ide

內存泄漏: 當應用週期內再也不使用的對象被GC ROOTS引用致使不能回收會使實際可用的java 堆內存變小就會發生內存泄漏工具

內存泄漏超過單個應用最大的使用內存,超出這個值就會OOM大數據

OOM 有不少中不必定是超過最大使用堆內存

OOM

1. JAVA堆內存溢出
2. 無足夠的連續空間
3. FD數量超過限制
4. 線程數量超過限制 
5. 虛擬內存不足
複製代碼

咱們能夠使用 adb shell dumpsys meminfo --package 包名

若是多個設備 adb -s xxx shell

從下載hprof後要經過Android sdk 中platm-tools hprof-conv.exe 來轉換成MAT所須要的文件

out-coming 是該對象中引用了誰 in-comeing 是誰引用了該對象

資源性的泄漏好比database中
註冊對象未註銷好比廣播 eventBus
類的靜態變量持有大數據對象。
單例模式形成的泄漏好比Context 傳入了Activity
非靜態內部類的靜態實例
Handler的零時性泄漏
容器中的對象沒有clear 而且設置null
webView 須要使用aidl進程通訊

地圖中 BitMapFactory.Option 參數中有個參數 inJustDecodeBounds=true 能夠不加載圖片不分配內存,但會返回圖片的寬度和高度。而後經過samleSize來縮放圖片比例

1個像素有一個參數Config ALPHA(1) 是佔1個字節(byte) RGB_565是佔2個字節(byte)
ARGB_888是佔4個字節 ARGB_F16佔 8個字節(byte) 、

在Android圖片中佔用的內存大小是
那麼大小就是

1920x1080像素佔多少內存 1920x1080x4x((設備密度/圖片所在文件夾的密度)^2)/1024= KB

mdpi hdpi xdpi xxdpi xxxdpi 160 240 320 480 560

可是在文件和網絡上加載的圖片就沒有1920x1080x4/1024=kb

8bit(位)=1Byte(字節)

1024Byte(字節)=1KB

1024KB=1MB

1024MB=1GB

1024GB=1TB

Bitmap的內存模型 Android 3.0-4.4 bitMap對象保存在java Heap 像素數據保存在 native Heap Android 5.0-7.0 bitmap對象保存在java Heap 像素數據保證在 java Heap Android 8.0 bimap對象保存在java Heap 像素數據保存在 native Heap

內存優化總體思想:

設備分級:
BitMap優化統一圖片庫線上線下監控
glide圖片加載庫

LeakCanary 內存檢測工具
兩部分 1.找出泄漏的嫌疑的對象。原理 2.確診:haha開源庫利用這個可達性分析

LeakCanary的原理在ActivityThread中的bindAppcalition方法 ContentProvider.onCreate 會比Appcaliton.onCreate 更早執行

LeakCanary檢測Activity退出的原理
ActivityLifecycleCallbacks 能夠監聽Activity的生命週期  Fragment的生命週期
JAVA四種引用和引用隊列ReferenceQueue的關係
複製代碼

RefereQueue 引用隊列就是存放引用的隊列

做用:看成用於Reference對象所引用的對象被GC回收的時候,該Reference對象將會被加入引用隊列的末尾

當弱引用 WeakReference weakReference=new WeakReference(obj,referenceQueue)

leakcanary watch 一個對象5s 加入觀察列表