60.性能优化-界面卡顿

Bitmap 占用内存分析和常见优化。

耗时引起的卡顿，主线程耗时较长。

2.Android Device Monitor介绍。

监测方法的执行时间，找执行较长时间的方法。代码回滚，一个个方法注释(x)。
卡顿：cpu的饱和度引起卡顿，耗时引起卡顿，内存抖动频繁gc，多线程上下文切换。

选择当前的应用-进程，点击【Start Method Profiling】--【OK】。
然后下滑页面，整个程序开始卡顿，等卡顿执行完，再次点击【Start Method Profiling】，
会生成ddms57****.trace文件，查找哪个方法的执行时间过长。
检测代码的执行时间。

方法的排序执行时间，包含了其子函数的执行时间。
找到耗时的方法：ImageUtil.doblur() // 高斯模糊耗时，耗时7s左右。
优化1：线程切换，将耗时操作交给子线程去处理。RxJava
优化2：不加载原始图片，将加载的图片缩小，减少内存占用和计算量。
使用 SimpleTarget一定要传宽高。
优化3：使用LruCache缓存，避免每次都从网络请求。 同样的图片处理完缓存起来，刷新不要再去请求和计算。
LruCache 底层使用LinkedHashMap实现，通过前移编码挪到最前面。天生有做缓存的优势。
不同手机内存不一样，根据手机分辨率来定缓存大小。Glide--
GlideBuilder--build()-- new LruResourceCache(memorySizeCalculator.getMemorySize());
-- MemorySizeCalculator--targetBitmapPoolSize
memoryCacheSize.
内存缓存 = 一屏幕图片2 = (widthPheightP4)2

为啥根据手机分辨率来定缓存大小？
根据isLowMemoryDevice +(手机内存，分辨率)，不同分辨率的手机加载图片的大小不同。
当图片变更频繁，且要高效率。可以考虑缓存放native层。如需要100~200Mb。
放在java层，容易OOM。

//private static final int CACHE_SIZE = 4*1024*1024; // 4MB
// 缓存大小根据手机配置的不同而不同。3-4m,大概10张图片
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.否则容易oom。默认这里返回的1.
    }
};
Bitmap cacheBitmap = mBlurBitmapCache.get(item.headUrl); // 拿缓存
// cacheBitmap非空，直接设置。不要下载
if(cacheBitmap != null) {
    headIv.setImageBitmap(cacheBitmap);
    return;
}
// ... BaseApplication.get().getMainComponent().imageLoader()
    .loadImage()

// 根据高斯函数的实现原理：图片显示大小优化。下载的时候指定宽高成控件的大小。屏幕的四分之一。SimpleTarget 带上宽高访问。
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);
            // 缓存图片。到cache
            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("blur", dst); // 类似水搅混了。

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
sigmaX的值1，曲线非常陡峭。自己点占据的比例更大。模糊效果不明显。
sigmaX的值10，曲线的坡就比较平滑。类似均值的效果。

对图片原始宽高进行优化，占用内存太大，计算量太大。
下载的时候，指定图片宽高。

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)

ImageLoader.java
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 源码解析。计算宽高, 压缩。
decode() --decodeFromWrappedStreams()-- calculateScaling()

// 判断有没有传宽高的值。
int targetWidth = requestWidth==Target.SIZE_ORIGINAL? sourceWidth :requestedWidth;
int targetHeight = requestHeight==Target.SIZE_ORIGINAL? sourceHeight :requestedHeight;

Bitmap三级缓存：内存（Lrucache，pool）、磁盘、网络缓存。
Glide四级缓存：当前活动的bitmap，内存、磁盘、网络缓存。

5.Lrucache 的使用。

1.3-5年源码熟悉 ，binder底层源码。5-10年一个新的台阶。
2.开发过程中遇到ndk，可以解决很多问题。
3.做音视频开发。
图像图形学。
音视频门槛高，薪资也高一些。

6. 总结：

• 优化1：线程切换，将耗时操作交给子线程处理。
• 优化2：不加载原始图片，将加载的图片缩小，减少内存占用和计算量。
  使用 SimpleTarget一定要传宽高。
• 优化3：使用LruCache缓存，避免每次都从网络请求。 同样的图片处理完缓存起来，刷新不要再去请求和计算。
  LruCache 底层使用LinkedHashMap实现，通过前移编码挪到最前面。
  不同手机内存不一样，根据手机分辨率来定缓存大小。Glide--MemorySizeCalculator--targetBitmapPoolSize