問題出現(xiàn)場景
引入github著名第三方庫PhotoView
在項目的需求中有點擊查看大圖，查看大圖里的組件用的PhotoView，并且寬高設置為match_parent，出現(xiàn)了比較明顯的卡頓
與ImageView進行對比
- ImageView寬高設置為match_parent
- 設置ScaleType為MATRIX(手勢縮放需要的類型)
對比發(fā)現(xiàn)落剪，在ImageView的setImageDrawable的時候，ImageView里的Drawable的Bounds和PhotoView里的Bounds不一致尿庐，其實追溯到源碼是可以發(fā)現(xiàn)忠怖。Drawable的Bounds在ScaleType為MATRIX時，取的值為Drawable本身的getIntrinsicWidth和getIntrinsicHeight
如下源碼
if (dwidth <= 0 || dheight <= 0 || ScaleType.FIT_XY == mScaleType) {
/* If the drawable has no intrinsic size, or we're told to
scaletofit, then we just fill our entire view.
*/
mDrawable.setBounds(0, 0, vwidth, vheight);
mDrawMatrix = null;
} else {
// We need to do the scaling ourself, so have the drawable
// use its native size.
mDrawable.setBounds(0, 0, dwidth, dheight);
…………
}
總結(jié)以下幾點
- 那么說明加載出來的Drawable本身他的getIntrinsicWidth和getIntrinsicHeight不一致
- 假定Canvas繪制壓力來自于加載出來的圖片的像素大小(畢竟沒看過源碼抄瑟，單單比較得出的結(jié)論)
- 加載出來的圖片資源不一致
那么首先筆者用的是圖片框架是Glide凡泣，在Glide的源碼中有這樣一段代碼
public Target<TranscodeType> into(ImageView view) {
Util.assertMainThread();
Preconditions.checkNotNull(view);
if (!requestOptions.isTransformationSet()
&& requestOptions.isTransformationAllowed()
&& view.getScaleType() != null) {
if (requestOptions.isLocked()) {
requestOptions = requestOptions.clone();
}
switch (view.getScaleType()) {
case CENTER_CROP:
requestOptions.optionalCenterCrop();
break;
case CENTER_INSIDE:
requestOptions.optionalCenterInside();
break;
case FIT_CENTER:
case FIT_START:
case FIT_END:
requestOptions.optionalFitCenter();
break;
case FIT_XY:
requestOptions.optionalCenterInside();
break;
case CENTER:
case MATRIX:
default:
// Do nothing.
}
}
return into(context.buildImageViewTarget(view, transcodeClass));
}
會自動根據(jù)ImageView的scaleType自動進行相應的配置，想深究的可以研究下Glide源碼皮假，這里不做詳細分析,回過頭來再看PhotoView
- PhotoView重寫了getScaleType方法
@Override
public ScaleType getScaleType() {
return attacher.getScaleType();
}
- PhotoViewAttacher里的mScaleType默認為FIT_CENTER
private ScaleType mScaleType = ScaleType.FIT_CENTER;
……
public ScaleType getScaleType() {
return mScaleType;
}
到此可以說明了PhotoView本身的ScaleType和提供給外界引用的ScaleType并不一致
實踐
自定義一個PhotoNewView鞋拟，完全copyPhoto的代碼，僅在getScaleType中返回super.getScaleType()
測試得出钞翔，這樣修改以后严卖，完美達到預期，gif不再卡頓布轿，同時Drawable承載的信息和ImageView一致
解決方案
方案一
- 點擊看大圖的時候哮笆，如果圖片是GIF類型的，那么不采用PhotoView汰扭，反之稠肘，用PhotoView
方案二
- 如上所說，自定義一個自己需要的PhotoNewView萝毛，為了保險起見项阴，建議多提供一個方法，來選擇性提供返回View本身的ScaleType或者是PhotoViewAttacher里的mScaleType笆包，若熟讀了PhotoView的源碼环揽，也是能做更精細的擴展
