android中圖片加載到內存中所佔空間大小計算：分辨率 height*width*一個像素所佔空間大小
解析：decode時指定解碼方式爲ARGB_8888 代表用8位表示透明度（A），8位表示紅色（R），8位表示綠色（G），8位表示藍色（B），也就是說每個像素佔用4*8=32位空間（等於4byte），相對應 RGB_565,一共用16位（2byte）表示一個像素
舉個例子，上述屬性圖片，加載到程序中 分別佔用720*1230*4=3542400byte= 3.38MB（ARGB_8888）；720*1230*2=1771200byte=1.67MB(RGB_565)
光說不行，咱得上代碼上圖，沒圖說個**對不對
代碼很簡單，bitmap自帶getByteCount()方法。
然後兩者的清晰度區別，從上面兩張圖中還是能看出來有些差別，16位解碼出的圖片略微有點失真。
=================================華麗的分割線=================================
接下來說下bitmap的compress方法。
compress將bitmap壓縮輸出到流當中，參數一指定輸出的文件類型，參數二0-100指定質量，也決定了壓縮後的流大小。
參數一指定png 參數二就都爲100了，不會再打折壓縮了，所以要壓縮質量，要指定爲jpeg，（第三種webp格式沒有接觸過）
不知道是不是錯覺，指定jpeg情況下，哪怕質量指定100，出來的圖片還是感覺跟原圖有差距，略微有些失真，所以，需要保持原圖效果，還是指定爲png格式吧。
compress方法查看源碼，直接調用的是c層代碼，跟進c層代碼 發現是skia庫起的作用，skia中繼續調用了libjpeg或者libpng庫來處理壓縮圖片。
繼續上圖舉例子：
jpeg 100%情況下 壓縮後流大小爲299490byte（300k）左右
jpeg 80%情況下 壓縮後流大小爲56043byte（56k）左右
jpeg 50%情況下 壓縮後流大小爲35443byte（35k）左右
jpeg 20%情況下 壓縮後流大小爲24802byte（25k）左右
可以看到，壓縮後圖片大小的減少還是非常明顯的，不過一般情況下 壓縮率在80%以上就OK，繼續往下，文件減少的幅度大幅下降，失真度卻大幅上升。
如果還對圖片佔用大小不滿意，那要從圖片分辨率方面入手（文章第一部分），而不是繼續降低壓縮比率。