誕生
這是一篇來自小白的android研發筆記，近期小白接到了一項來自領導的指示：分析小白負責的app內存使用情況，及給出內存優化的方案，對app進行內存優化。對於小白來說，這是一項艱鉅的任務，但是爲了飯碗，小白到處搜索求學，買課程。終於對android內存分析有了一定的瞭解（內存分析及優化，這裏就不說了，因爲到目前爲止，小白也還未入門），到今天爲止，小白掌握了一項新技能，所以小白寫下了這篇博客，以便紀錄小白的學習心得。 錯誤之處，望大佬前輩們不吝賜教，小白感恩戴德！
冒險
話說android的內存分析猶如一片大海，小白決定抓住圖片這塊木頭開啓冒險之旅。
小白髮現小白的app，包含五彩繽紛的圖片，從各種學習資料上瞭解到，圖片佔用內存的方式有兩種：
第一種：對Bitmap這個類來說，它有一個方法getByteCount(),這個方法直接返回了這個Bitmap自身所佔的內存。但是這種情況是需要在運行時動態算出來的。
第二種：寬高一像素佔用的內存。一般情況下，該方式計算出來的就是bitmap所佔用的內存，但是有例外。比如說，放在資源目錄裏，res目錄裏面，此時需要*壓縮比例。
原來如此，圖片加載到內存所佔用的內存，跟這張圖片的寬高密不可分，so，加載圖片時，最好圖片的尺寸跟控件寬高保持一致，也許這裏會有內存優化的空間。
小白又翻閱了各種資料，監聽圖片寬高的方式有很多很多，有優雅的，有不優雅的，最後小白採用了優雅的方案（廢話），用hook的方式監聽圖片加載前，圖片的大小及控件大小是否一致。採用的是 開源Hook框架-epic，擺在眼前的第一個難點：epic僅在debug包下生效。
小白叕翻閱了資料，向大佬請教，終於習得了不二法門：
類似LeakCanary的引入，build.gradle 中加入引用：
dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
}
萬一我需要修改裏面的部分源碼怎麼破呢？
小白在翻閱資料中。。。。。。。。。。。。。。
啊！啊！啊！！！
幸運的小白又找到的相應的資料，不信往下看：
- 創建一個獨立的模塊，我們就取名爲：app-test吧，把相關的源碼ctr＋c，ctr＋v，修改你想修改的地方，不想修改就不改嘍／攤手；
- 在主模塊app的build.gradle中引入app-test：debugImplementation project(’:app-test’)
- 如果需要在application中進行初始化，在主模塊app的src下方創建兩個目錄：debug和release，將初始化的代碼放進去就over啦（當然啦，在release下方的方法中，並木有調用真正初始化的代碼）
譬如：debug目錄下的代碼如下：
package com.xiaobai.test;
import android.content.Context;
public class TestInitManager {
public static boolean init(Context context) {
BlockCanary.install(context,new AppBlockCanaryContext()).start();//悄悄告訴你，AppBlockCanaryContext也放在debug目錄下
return true;
}
}
release目錄下的代碼如下：
package com.xiaobai.test;
import android.content.Context;
public class TestInitManager {
public static boolean init(Context context) {
return false;
}
}
此節完，感謝閱讀，歡迎指導，圖片內存分析待小白研究完再告訴你們。