WEEX-EEUI 卡顿优化（图片加载）

最新推荐文章于 2021-05-31 03:32:54 发布

像一只小蜗牛

最新推荐文章于 2021-05-31 03:32:54 发布

阅读量769

点赞数

分类专栏： weex 文章标签： eeui imageAdapter 卡顿分析 androidProfile

本文链接：https://blog.csdn.net/ZPCrobot/article/details/108491919

版权

本文介绍了在Android平台上，使用WEEX-EEUI框架时遇到的图片加载导致的卡顿问题及其解决过程。通过Android Profile工具分析，发现线程数量异常增加，与Picasso和Glide的ImageAdapter有关。最终定位问题在于非法的placeHolder和WEEX的autobitmaprecycle参数。移除无效placeHolder和调整autobitmaprecycle设置解决了卡顿问题，强调了Android Profile工具在性能优化中的重要性。

摘要由CSDN通过智能技术生成

前言

前两天前端的小伙伴告诉我，他写的页面再android手机上特别的卡，崩溃了很多次。这让我紧张了起来，已经用weex-eeui做过一个项目了，之前还没发现这个问题。因为问题不好定位，让我想起了之前一直想用却没有怎么使用过的android profile工具。现在它可以排上用场了。

Android Profile 工具使用

这里先提供几个我觉得写的比较好的文章给大家：
1.Android studio中android profile（性能分析器）的使用
2.Android性能分析工具 — CPU Profile

如果第一个看不太懂，就看第二个。第二篇文章主要讲了CPU分析，因为通过观察发现，内存波动和cpu波动都有些异常，不过cpu的问题更突出一些。
在这里插入图片描述

通过观察cpu的数据发现，每次打开图片比较多的页面和关闭图片比较多的页面的时候都会出现卡顿，而且线程数量从一开始的七十多不断的增加到两千多个线程，这不卡才怪！
顺着这个思路，我使用了Trace文件分析这个功能，找到了这些线程的真正来源是Picasso 的dispatcher方法，这让我很懵逼。之前用picasso的时候几乎没有遇到过这个问题。还好ImageAdapter又支持picasso和glide，于是乎，我就把框架切换到glide上面，结果还是回出现卡顿，线程数量一直飙升的问题。

问题解决历程

这里我给大家看一下ImageAdapter的代码

//placeHolder是默认占位图，问题就出在这里
if (!TextUtils.isEmpty(strategy.placeHolder)) {
   
            Log.d(TAG, "placeHolder: " + strategy.placeHolder);
            String placeHolder = eeuiBase.config.verifyFile(eeuiPage.rewriteUrl(view, handCachePageUrl(view.getContext(), strategy.placeHolder)));
            File file=new File(placeHolder);
            if(file.exists()){
   
                Picasso.Builder builder = new Picasso.Builder(WXEnvironment.getApplication());
                Picasso picasso = builder.build();
                picasso.load(Uri.parse(placeHolder)).into(view);
                view.setTag(strategy.placeHolder.hashCode(), picasso);
                valid=true;
            }else{
   
                Log.d(TAG