Android 项目总结 ViewPager Indicator fragment内存优化过程

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/jiankeufo/article/details/53993004

因前段时间做了个对内存和CPU要求特别严格的一个项目,场景是:

ViewPager+Fragment+Indicator的一个节目库,因为期间遇到了很多坑,所以在此做一个总结,以便下次再遇到这样的坑可以一下子跳过去。

好了,废话不多说。

一开始看到项目需求的时候,是左右滑动的界面,因为之前做过类似需求,所以很想当然的采用了之前的那套代码方法。


问题一

ViewPager+Fragment+Indicator.

这时候有人就问了。解决这种场景的不都是采用这样的方式吗,我的答案是:也对也不对,看对方在这个项目对内存要求是否严格。

PagerAdapter       VS             FragmentStatePagerAdapter

通过在左右滑动这种滑动卡牌数量少数的时候可以采用PagerAdapter   这种机制

但是如果是卡片特别的多的情况下,再采用这样的PagerAdapter会导致内存一直飙升。此时对于那些要求内存特别严格的厂家就不能接受了,要求降低内存。

 最后采用的是FragmentStatePagerAdapter。

那么这两个有什么区别呢?

FragmentPagerAdapter 继承自 PagerAdapter。相比通用的 PagerAdapter,该类更专注于每一页均为 Fragment 的情况。如文档所述,该类内的每一个生成的 Fragment 都将保存在内存之中,因此适用于那些相对静态的页,数量也比较少的那种;如果需要处理有很多页,并且数据动态性较大、占用内存较多的情况,应该使用FragmentStatePagerAdapter


问题二

由于滑动的特别快,所以对此做了一个懒加载。

场景:一共有15个条目,当前是第一个条目,我点击第15个条目的时候,界面飞速滑动。导致界面卡顿。

解决方案:

为每个Fragment添加一个属性 isPageShow 默认为false。在他的onViewCreated中做判断,如果为true的时候,才进行网络加载。另外又添加了个新方法。reLoadData()。再次回到界面的时候回调,同样,如果为true的时候,才进行网络加载。

剩下的就是调用的时机了。


在indicator的pageSelect方法中,首先将所有的fragment实例中的isPageShow置成flase,然后根据当前的index得到当前的fragment,把它置成true,然后调用reLoadData方法。


注意:因为要讲fragment实例保存起来,再使用FragmentStatePagerAdapter的时候用的是SpaseArray<Fragment>,





阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页