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

因前段时间做了个对内存和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>,