1.背景
做为IM的核心部分,会话页的展示和流畅度十分影响用户体验,本次优化的内容正是会话里面的Gif图片的展示,Android原生是没有View直接支持Gif图片播放的,Startalk使用Glide+FrameSequenceDrawable实现对Gif的支持,但是在使用过程中发现了一些问题,例如在一个会话里面Gif图过多过大,IM在运行一段时间后内存吃紧,造成页面开始卡顿,甚至OOM等问题,为了解决这个问题我们通过Android Studio 3.0开始内置的Android Profiler工具来检测Memory的变化,从而发现问题所在并实施优化。
2.Android Profiler介绍
首先看一下Android Profiler共享时间线视图
Android Profiler现在显示一个共享时间线视图,其中包括一个带有CPU、MEMORY和NETWORK使用情况实时图表的时间线。该窗口还包括时间线缩放控件 3,用于跳转到实时更新的按钮 4 以及显示活动状态,用户输入事件和屏幕旋转事件 5 的事件时间线,1 是连接的设备,2 当前所选进程。
3.问题分析
了解了Android Profiler后,我们通过MEMORY时间线看一下在我们进入会话页后&当会话页有较多较大的GIF时我们的IM APP内存占用对比情况,首先看我们刚进入没有GIF的会话页内存占用如下
说明:
•Total:当前所选进程占用的总内存大小
•Java:从Java或Kotlin代码分配的对象的内存
•Native:从C或C ++代码分配的对象的内存
•Graphics:用于图形缓冲区队列的内存
•Stack:应用程序中堆栈和Java堆栈使用的内存,这通常与您的应用运行的线程数有关
•Code:应用程序使用代码和资源的内存,例如dex字节码,优化或编译的dex代码,.so库和字体
•Others:应用程序使用的内存,系统不知道如何分类
接着我们看一下在我进入一个Gif比较多(个别Gif图很大20M左右)会话后,滑动会话页后内存占用如下图:
从MEMORY时间线可以看到Native增加了将近70M,并且在显示之前已经展示过的Gif时Native内存同样还是在增长,结束会话页后内存一直保持在一定值没有下降。通过上面的分析得出的结论是在加载Gif的时候程序不断的在申请内存,前面背景中提到我们的Gif时Glide+FrameSequenceDrawable加载的,所以C&C++申请内存的操作于应该时在FrameSequence中,看一下FrameSequenceDrawable源码,发现这三个native 申请内存方法。
再看一下我们程序里面是如何使用的
Glide.with(context)
.load(url)
.asGif()
.toBytes()
.diskCacheStrategy(DiskCacheStrategy.ALL)
.dontAnimate()
.into(new ViewTarget<LoadingImgView, byte[]>(mLoadingImgView) {
@Override
public void onResourceReady(byte[] resource, GlideAnimation<? super byte[]> glideAnimation) {
FrameSequence fs = FrameSequence.decodeByteArray(resource);
FrameSequenceDrawable drawable = new FrameSequenceDrawable(fs);
view.setImageDrawable(drawable);
}
});
这段代码是在会话列表的adapter中执行的,FrameSequence.decodeByteArray(resource)每次这个view展示的时候都会被调用到,也就意味着每次都会申请创建 byte[] resource长度大小的内存,这也是重复显示同一个Gif时内存不断增加的原因。
接下来我们对这段代码进行优化,使用Cache策略(LruCache)确保同一个url对应一个FrameSequenceDrawable。
Glide.with(context)
.load(url)
.asGif()
.toBytes()
.diskCacheStrategy(DiskCacheStrategy.ALL)//缓存全尺寸
.dontAnimate()
.into(new ViewTarget<LoadingImgView, byte[]>(mLoadingImgView) {
@Override
public void onResourceReady(byte[] resource, GlideAnimation<? super byte[]> glideAnimation) {
WeakReference<Parcelable> cached = new WeakReference<>(MemoryCache.getMemoryCache(url));
if(cached.get() == null){
FrameSequence fs = FrameSequence.decodeByteArray(resource);
FrameSequenceDrawable drawable = new FrameSequenceDrawable(fs);
drawable.setByteCount(resource.length);
view.setImageDrawable(drawable);
MemoryCache.addObjToMemoryCache(url,drawable);
}else {
if(cached.get() instanceof FrameSequenceDrawable){
FrameSequenceDrawable fsd = (FrameSequenceDrawable)cached.get();
view.setImageDrawable(fsd);
}
}
}
});
其中MemoryCache为LruCache封装的工具类,同时使用了WeakReference来保证FrameSequenceDrawable更容易被回收,回收的好处是native申请的内存可以被销毁释放
protected void finalize() throws Throwable {
try {
if (mNativeFrameSequence != 0) nativeDestroyFrameSequence(mNativeFrameSequence);
} finally {
super.finalize();
}
}
我们在Application的onTrimMemory(level)方法来清空MemoryCache里面的缓存,触发GC(备注:onTrimMemory(level)方法会在程序内存吃紧的时候回调到又不通的level级别),我们这里设置 level >= TRIM_MEMORY_RUNNING_MODERATE,这样在我们Home出程序的时候会被执行。
public void onTrimMemory(int level) {
super.onTrimMemory(level);
if (level >= TRIM_MEMORY_RUNNING_MODERATE) {
QIMSdk.getInstance().clearMemoryCache();
}
}
然后我们重新通过Android Profiler查看上面同样的操作内存情况
在我退出会话页若干秒或者Home出去后,Native内存瞬间降下来了,大概回到进会话前大小。
通过Android Profiler对内存的分析我们优化了Gif的内存消耗问题,其实通过这个工具我们还能分析出程序的不足地方,本次针对的主要是Native的内存部分,而我们内存的另一大开销Java堆内存也是我们优化的重点。
问题:在分析FrameSequenceDrawable源码的时候我们发现Android7.0及以上当view隐藏的时候回调不到 setVisible方法,只做了临时处理,有知道的小伙伴可以评论回复我。
public boolean setVisible(boolean visible, boolean restart) {
boolean changed = super.setVisible(visible, restart);
//TODO 7.0及以上特殊处理 暂时没找到其他好办法
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M){
if(visible && !isRunning() && !restart){
restart = true;
}
}
if (!visible) {
super.setVisible(visible, restart);
stop();
} else if (restart || changed) {
stop();
start();
}
return changed;
}