之所以想到写本文，是因为看到鸿洋微博的RecyclerView实现抖音效果的文章。里面讲了ViewPager实现会OOM，RecyclerView不会。
第一个get的点，RecyclerView打造成ViewPager，这个就不用多说了，SnapHelper封装了这一切
第二个get的点，为什么RecyclerView不会OOM呢？
这需要掌握RecyclerView一些浅显的原理。RecyclerView除了界面上显示的item，还有上下各2个供4个的预加载item。所以他内存中有 当前界面可见item数量+4 个数的item。他会在滑动的时候，不断bind新的数据。
ViewPager则是需要给他View的集合，你如果有10000个item，那内存中就必须有10000个item。
曾经我懵懂的时候问过Android老师，怎么才能只使用3个item去实现ViewPager？
这个问题挺白痴的，因为很简单就能实现。但是没想到老师说的答案令我震惊了，你没必要这么搞，他会自动替你管理，你移动到哪里就会有对应的item的销毁和创建。我说，假如我要写一个电子书，他有10000页，我肯定不能让他有10000页在内存中的对吗。他说，现在手机硬件都很好了，你做的这点优化微不足道。。。
这里就不写后续剧情了。我们固然可以用少量的item去实现ViewPager，手动做和RecyclerView类似的bind、unbind类似的操作。可是，RecyclerView这里已经实现好了强大的内存管理机制，我们无需写一份蹩脚的替代品了。
所以这里是建议，能用RecyclerView就用它，它真的是一个设计优良的框架。
最后结合Bitmap深化一下RecyclerView的内存管理机制
比如实现一个相册。4*7张图片。你可以想象下内存中有多少张图片？（4+4）*7吗？其实不太对。因为你在向下滑动的时候，旧的Bitmap可能没有被及时回收，因为GC是低优先级的，在内存容量尚多的情况，不会轻易触发。所以Bitmap会在一块新开辟的内存中进行创建。所以我们通常会用到inBitmap这个属性，使得我们可以复用之前的已经没有被任何引用所指向的bitmap的内存空间了（当你向下滑的时候，会有一行行的Bitmap不会再被引用所指向）。因此，如果采用这个标记位，那么我们的内存占用就一定是8*7=56张。