NestedScrollView/ScrollView 嵌套 RecyclerView 需谨慎

这种布局，RecyclerView(Vertical)不会复用，内容多几屏，Crash必现。

这是一段心路历程~
线上低端机因为OOM大面积Crash~

新功能初期，将原来的RN修改为Native代码，数据流分类不同，每个分类也没多少数据，和大部分的App首页布局差不多。
开始是使用一个RecyclerView直接实现的，但是效果并不理想，滑动卡顿，定位问题是Banner频繁回收，损耗过重，导致卡顿。

后来为了实现业务，用NestedScrollView嵌套几个不用复用的布局，下面的列表用RecyclerView实现的(数据量不大，就没做分页)。

这个版本上线之后，可想而知，Buggly上报低端机出现个别的Crash，也不是很在意，毕竟低端手机的适配工作并没有被重视起来，虽然公司都是学生群体，但是现在的低端机真的没多少呀。

近期，业务组同学直接加了6个分组，也就是18张书籍封面图，结果可想而知，线上中低端机全线Crash。自己挖的坑必须自己跳呀~~

下面就是定位问题。当时在做的时候用一个RecyclerView就是为了实现复用，防止内存Crash，后面为了实现效果，也没有深究，毕竟我用的RecyclerView(捂脸哭)。

· 第一反应，内容同学又传了大图了（代码不可能有Bug），找了半天，有些小问题，但不是主要问题。
· 第二反应，是否可以继续压缩图片质量~
· 第三反应，log 看 首页渲染逻辑

最终发现，本应该回收复用的RecyclerView只初始化了第一次，后面再也没有重写渲染了。So，才反应过来，我写的什么鬼代码~~

那么问题来了，网上NestedScrollView嵌套RecyclerView的需求以及解决滑动冲突的问题一大堆，那么为什么会存在这种需求呢，有没有考虑后续内容增加呢，即使加了分页，是否解决了复用问题呢？感觉我陷入了死胡同，为什么大家都在用这种设计~~

最后：使用HeadView的方式实现了上面的需求，实现了复用(HeaderView不会重新创建)。