60.性能优化-界面卡顿
Bitmap 占用内存分析和常见优化。
耗时引起的卡顿，主线程耗时较长。
2.Android Device Monitor介绍。
检测方法的执行时间，找执行较长的方法。
卡顿：cpu的饱和度引起卡顿，耗时引起卡顿，内存抖动频繁gc，多线程上下文切换。
选择当前的应用-进程，点击【Start Method Profiling】--【OK】。
然后下滑页面，整个程序开始卡顿，等卡顿执行完，再次点击【Start Method Profiling】，
生成ddms57****.trace文件，查找哪个方法的执行时间过长。
方法的排序执行时间，包含了其子函数的执行时间。
找到耗时的方法：ImageUtil.doblur() // 高斯模糊耗时，耗时7s左右。
优化1：线程切换，将耗时操作交给子线程处理。
优化2：不加载原始图片，将加载的图片缩小，减少内存占用和计算量。
使用 SimpleTarget一定要传宽高。
优化3：使用LruCache缓存，避免每次都从网络请求。 同样的图片处理完缓存起来，刷新不要再去请求和计算。
LruCache 底层使用LinkedHashMap实现，通过前移编码挪到最前面。
不同手机内存不一样，根据手机分辨率来定缓存大小。Glide--MemorySizeCalculator--targetBitmapPoolSize
为啥根据手机分辨率来定缓存大小？
根据isLowMemoryDevice +(手机内存，分辨率)，不同分辨率的手机加载图片的大小不同。
当图片变更频繁，且要高效率。可以考虑放native层。如需要100~200Mb。
//private static final int CACHE_SIZE = 4*1024*1024;
// 缓存大小根据手机配置的不同而不同。
private static final int CACHE_SIZE =
new MemorySizeCalculator.Builder(PaoPApplication.get()).build().getMemoryCacheSize() /4;
private LruCache<String,Bitmap> mBlurBitmapCache = new LruCache<>(CACHE_SIZE){
@Override
protected int getItemSize(Bitmap item){
return item.getByteCount(); // 返回图片占用字节大小，默认返回1.
}
};
Bitmap cacheBitmap = mBlurBitmapCache.get(item.headUrl);
// cacheBitmap非空，直接设置。
if(cacheBitmap != null) {
headIv.setImageBitmap(cacheBitmap);
return;
}
// 根据高斯函数的视线原理：图片显示大小优化。下载的时候指定宽高成控件的大小。
int size = ScreenUtil.getScreenWidth(mContext) / 4;
BaseApplication.get().getMainComponent().imageLoader()
.loadImage(mContext, ImageConfigImpl.builder().url(item.userResp.headPortraitUrl)
.simpleTarget(new SimpleTarget<BitmapDrawable>(size, size) {
@Override
public void onResourceReady(BitmapDrawable resource, Transition transition) {
setRecommendBg(recommendBgIv, resource, item.userResp.headPortraitUrl);
}
}).imageView(userHeadiv).build());
private void setRecommendBg(ImageView bgIv, BitmapDrawable resource,String headUrl) {
if(resource != null) {
Observable.just(resource.getBitmap())
.map(new Function<Bitmap, Bitmap>(){
Bitmap blurBitmap = ImageUtil.doBlur(resource.getBitmap(),100,false);
// 缓存图片。
mBlurBitmapCache.put(headUrl, blurBitmap);
return blurBitmap;
})
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(bitmap-> bgIv.setImageBitmap(bitmap));
}
}
高斯模糊算法分析：根据周边像素值来确定自己的像素值，平均值、最大值、最小值、正态分布值。
- 均值模糊：对当前像素点的周边半径，进行相加然后取平均值，赋值给当前像素点。
- 高斯模糊：会进行权重处理，越靠近当前像素点，权重值越大; 越原来越小。有平滑效果。
每个像素点都需要处理，还有要取计算正态分布的值(卷积和)
如果半径越大，算法复杂度就越大；如果图片宽高像素点越多，算法的复杂度也越大。 - 中值滤波：降噪
- 双边滤波：美容
openCV和音视频的三个阶段：会用API > 底层原理 > 搞清数学的公式，会算法。
优化：使用均值模糊，代替均值模糊。
3.高斯模糊和均值模糊。
3.1均值模糊：w h只能是奇数。值越大越模糊。
size里面参数，是模糊的半径。
Mat src = imread("C:/User/hc/Desktop/android/test.png");
Mat dst;
blur(src, dst, Size(15,15), Point(-1,-1));
imshow("src", src);
Mat gaussian;
GaussianBlur(src,gaussian Size(15,15),0);
imshow("gaussian", gaussian);
3.2高斯模糊---卷积和
高斯保留了一些轮廓，相对更加清晰。可以用均值模糊替代均值模糊。提高效率。
sigmaX， sigmaY 的作用，可以直接传0.
sigmaX 不传代表和sigmaY一样，如果sigmaX<=0,自己会计算= 0.3((ksize-1)0.1-1) +0.8
对图片原始宽高进行优化，占用内存太大，计算量太大。
下载的时候，指定图片宽高。
4.Glide源码，怎么做图片压缩的？
https://juejin.cn/post/6844903463134953479
https://blog.csdn.net/qq_34178710/article/details/130812717
BaseApplication.get().getMainComponent().imageLoader()
.loadImage(mContext, ImageConfigImpl.builder().url(item.userResp.headPortraitUrl)
loadImage--> mStrategy.loadImage() 策略设计模式，便于切换图片方案为其他。
GlideImageLoaderStrategy implements BaseImageLoaderStrategy<ImageConfigImpl> 切换策略。
----loadImage/
SingleRequest/onSizeReady()/ Engine.load()--
DecodeJob:decodeFromRetrievedData()--decodeFromData()--runLoadPath()
path.load()-- loadWithExceptionList()-- path.decode()
decodeResource()--> decodeResourceWithList()--> decoder.decode(data,width,height,options)
// ResourceDecoder的实现类为 StreamBitmapDecoder
-- callback.onResourceDecoded(decoded)
Downsampler 源码解析。计算宽高
5.Lrucache 的使用。
图像图形学。
音视频门槛高，薪资也高一些。
6. 总结：
- 优化1：线程切换，将耗时操作交给子线程处理。
- 优化2：不加载原始图片，将加载的图片缩小，减少内存占用和计算量。
使用 SimpleTarget一定要传宽高。 - 优化3：使用LruCache缓存，避免每次都从网络请求。 同样的图片处理完缓存起来，刷新不要再去请求和计算。
LruCache 底层使用LinkedHashMap实现，通过前移编码挪到最前面。
不同手机内存不一样，根据手机分辨率来定缓存大小。Glide--MemorySizeCalculator--targetBitmapPoolSize
