圖片優化
優化圖片Bitmap資源的使用 & 內存管理
圖片的內存占據了App的大部分
1.使用完畢后釋放圖片資源 Bitmap.recycle/軟引用
使用完畢后 釋放圖片資源
優化原因
使用完畢后若不釋放圖片資源，容易造成內存泄露，從而導致內存溢出
優化方案
a. 在 Android2.3.3（API 10）前，調用 Bitmap.recycle()方法
b. 在 Android2.3.3（API 10）后，采用軟引用（SoftReference）
2.根據分辨率適配縮放圖片
優化原因
若 Bitmap 與 當前設備的分辨率不匹配，則會拉伸Bitmap，而Bitmap分辨率增加后，所占用的內存也會相應增加
因為Bitmap 的內存占用 根據 x、y的大小來增加的
優化方案
(1)設置多套圖片資源
(2)BitmapFactory.decodeResource() 對Bitmap根據當前的設備的像素密度進行縮放適配
(3)BitmapFactory.inSampleSize 能夠等比的縮放顯示圖片，同時還避免了需要先把原圖加載進內存的缺點
3.按需選擇合適的解碼方式
BitmapFactory.inPreferredConfig，默認使用解碼方式：ARGB_8888
inJustDecodeBounds 使用這個屬性去嘗試解碼圖片，可以事先獲取到圖片的大小而不至于占用什么內存
4.設置圖片緩存
三級緩存+軟引用
優先內存，其次本地緩存，然后網絡加載
http://www.lxweimin.com/p/49e4f44d7a83
1.Bitmap 使用注意點
當我們需要獲取圖片的寬高等屬性時且不對數據進行操作，那么我們不應該把圖片的數據加載到內存中，這時我們可以設置inJustDecodeBounds屬性為true.
BitmapFactory.Options opt=new BitmapFactory.Options();
opt.inJustDecodeBounds=true;(inJustDecodeBounds就是我們不用講圖片加載到內存中。我們只想得到關于圖片的信息)
BitmapFactory.decodeFile(filePath, opt);
final int height = options.outHeight;
final int width = options.outWidth;
2.減小Bitmap對象的內存占用
Bitmap是一個極容易消耗內存的大胖子，減小創建出來的Bitmap的內存占用是很重要的，通常來說有下面2個措施：
1.inSampleSize：縮放比例，在把圖片載入內存之前，我們需要先計算出一個合適的縮放比例，避免不必要的大圖載入。
2.decode format：解碼格式，選擇ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差異。
3.Bitmap對象的復用
我們知道大多數對象的復用，最終實施的方案都是利用對象池技術，要么是在編寫代碼的時候顯式的在程序里面去創建對象池，然后處理好復用的實現邏輯，
要么就是利用系統框架既有的某些復用特性達到減少對象的重復創建，從而減少內存的分配與回收。
在Bitmap中，利用inBitmap的高級特性提高Android系統在Bitmap分配與釋放執行效率上的提升(3.0以及4.4以后存在一些使用限制上的差異)。
使用inBitmap屬性可以告知Bitmap解碼器去嘗試使用已經存在的內存區域，新解碼的bitmap會嘗試去使用之前那張bitmap在heap中所占據的pixel data內存區域，
而不是去問內存重新申請一塊區域來存放bitmap。利用這種特性，即使是上千張的圖片，也只會僅僅只需要占用屏幕所能夠顯示的圖片數量的內存大小。
4.Bitmap對象及時回收
雖然在大多數情況下，我們會對Bitmap增加緩存機制，但是在某些時候，部分Bitmap是需要及時回收的。
例如臨時創建的某個相對比較大的bitmap對象，在經過變換得到新的bitmap對象之后，應該盡快回收原始的bitmap，這樣能夠更快釋放原始bitmap所占用的空間。
bitmap.recycle();
5.LRU管理Bitmap
LRU是Least Recently Used 近期最少使用算法。其實LruCache的作用就是對緩存的元素進行排序，當超過設定的內存值時就會將使用最少，使用最早元素先回收。
使用Lru來管理Bitmap,設置最大內存，可以防止出現內存溢出。
相關源碼可以看LruCache使用以及源碼詳細解析
6.直接使用更小的圖片
(1).我們可以在獲取圖片時告知服務器需要的圖片的寬高, 以便服務器給出合適的圖片, 避免浪費.
以七牛為例, 可以在請求圖片的url中添加諸如質量, 格式, width, height等path來獲取合適的圖片資源.七牛
7.如何加載大圖，可壓縮
圖片在磁盤上的實際大小約為3.5 MB，但在內存中的大小為12262248字節，相當于12.3 MB。
存儲在磁盤上的圖片是被壓縮過的（以JPG，PNG或類似的格式存儲）。 一旦將圖片加載到內存中，它就不再被壓縮，并占用盡可能多的圖片的所有像素所需的內存空間。
具體方法：得到圖片的分辨率，得到手機的分辨率，縮放
先設置inJustDecodeBounds = true ，獲取圖片的真實寬高，計算壓縮比例，
再根據壓縮比例顯示圖片，設置到mImageView。
//創建bitmap工廠的配置參數
BitmapFactory.Options options=new BitmapFactory.Options();
//返回null，不去真正解析位圖，只是得到寬高等信息
options.inJustDecodeBounds=true;
BitmapFactory.decodeFile("/storage/sdcard/test.JPG",options);
int imgWidth=options.outWidth;
int imgHeight=options.outHeight;
System.out.print("圖片寬"+imgWidth+"圖片高"+imgHeight);
// 計算縮放比
int scale=1;
int scalex=imgWidth/screenWidth;
int scaley=imgHeight/screenHeight;
scale=scalex>scaley?scalex:scaley;
//按照縮放比顯示圖片
options.inSampleSize=scale;
//開始真正解析位圖
options.inJustDecodeBounds=false;
Bitmap bitmap=BitmapFactory.decodeFile("/storage/sdcard/test.JPG",options);
mImageView.setImageBitmap(bitmap);
8.加載大圖，不允許壓縮。
首先不壓縮，按照原圖尺寸加載，那么屏幕肯定是不夠大的，并且考慮到內存的情況，不可能一次性整圖加載到內存中，所以肯定是局部加載，就需要用BitmapRegionDecoder
其次，既然屏幕顯示不完，那么最起碼要添加一個上下左右拖動的手勢，讓用戶可以拖動查看
InputStream inputStream = getAssets().open("tangyan.jpg");
//獲得圖片的寬、高
BitmapFactory.Options tmpOptions = new BitmapFactory.Options();
tmpOptions.inJustDecodeBounds = true;
BitmapFactory.decodeStream(inputStream, null, tmpOptions);
int width = tmpOptions.outWidth;
int height = tmpOptions.outHeight;
//設置顯示圖片的中心區域
BitmapRegionDecoder bitmapRegionDecoder = BitmapRegionDecoder.newInstance(inputStream, false);
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Bitmap.Config.RGB_565;
Bitmap bitmap = bitmapRegionDecoder.decodeRegion(new Rect(width / 2 - 100, height / 2 - 100, width / 2 + 100, height / 2 + 100), options);
mImageView.setImageBitmap(bitmap);
9.圖片數量非常多，則會使用LruCache等緩存機制，將所有圖片占據的內容維持在一個范圍內。
https://juejin.cn/user/3298190612500696/posts 安卓文章集合
https://juejin.cn/post/6970683481127043085
Glide做了哪些優化?
1.Glide圖片加載的總體流程介紹
2.Glide緩存機制做了哪些優化？
3.Glide做了哪些內存優化？
4.Glide如何管理生命周期?
5.Glide怎么做大圖加載?
(1)Glide 跟Fresco對比：
Glide：
多種圖片格式的緩存，適用于更多的內容表現形式（如Gif、WebP、縮略圖、Video）
生命周期集成（根據Activity或者Fragment的生命周期管理圖片加載請求）
高效處理Bitmap（bitmap的復用和主動回收，減少系統回收壓力）
高效的緩存策略，靈活（Picasso只會緩存原始尺寸的圖片，Glide緩存的是多種規格），加載速度快且內存開銷小（默認Bitmap格式的不同，使得內存開銷是Picasso的一半）
Fresco：
最大的優勢在于5.0以下(最低2.3)的bitmap加載。在5.0以下系統，Fresco將圖片放到一個特別的內存區域(Ashmem區)
大大減少OOM（在更底層的Native層對OOM進行處理，圖片將不再占用App的內存）
適用于需要高性能加載大量圖片的場景
對于一般App來說，Glide完全夠用，而對于圖片需求比較大的App，為了防止加載大量圖片導致OOM，Fresco 會更合適一些。
并不是說用Glide會導致OOM，Glide默認用的內存緩存是LruCache，內存不會一直往上漲。
(2)圖片加載框架的需求：
異步加載：線程池
切換線程：Handler，沒有爭議吧
緩存：LruCache、DiskLruCache
防止OOM：軟引用、LruCache、圖片壓縮、Bitmap像素存儲位置
內存泄露：注意ImageView的正確引用，生命周期管理
列表滑動加載的問題：加載錯亂、隊滿任務過多問題
