Android滑动浮层(滑动布局中使其中子布局一个浮动)

引言：
    滑动浮层中，一般在一些详情界面，或者是一些大评论界面。一个内容比较多的单元，对其中的一部分内容控件做替换的展示（不排除有另类的产品定义）。。这个可以点击替换的类似导航的布局，一般就是浮层，在多屏滑动的展示中，用户可以随时利用这个浮层做快捷的展示切换。。这里我们称这种方式为浮层导航。

定义：
    这个方式来说，有点类似于html中的a anchor锚点，在界面的右下角放置一个向上的箭头，来指引到哪一个位置。这个是一个底部导航加上一点底部，顶部导航加一个头部。这里只讨论一般情况，就是上下滑动的界面，有顶部的内容，在顶部内容和主体内容中间，有一个子布局，是作为浮动导航的。在向上滑动的时候，顶部内容滑出，继续滑动，浮动导航一直放置在顶部。。向下滑动的时候，待主体内容已经滑到顶部，浮动导航随整体下滑，滑出顶部。

做法和方法：
    首先来说，这是一个响应式的布局，整体布局的改变，时刻根据手指的滑动和显示的情况来互相影响。
    手指向下滑动，整体布局正常全部移动，但是当滑到浮动布局的时候，当浮动布局view，y=0，且y-1的时候，那么浮动布局view保持不动，不再跟随整体，主体的内容或从浮动布局的屁股底下滑没有。反之，手指向上滑动，在这个情景下，当主体已经全部滑出来，浮动布局的y也要找过height了。
    一般浮动布局，有两种做法，做法一是整体布局是传统的布局，无论是什么容器，就是传统的滑动，当滑动到需要浮层效果的时候，再加入一个和浮层布局一样的view,显示在滑动布局的内部的顶部，压在上面。做法二，就是这个包裹的容器原生支持这种效果，包括顶部内容的滑出，和滑动布局的滑动，这种容器，有的时候，会把顶部布局和滑动布局同时放入一个可以上下伸缩的容器中，通过外部的手指滑动传递，来决定顶部布局的消失和滑动布局的滞停。

    做法我们已经知道了，那么在android里面，有什么可以支持这些做法的控件和方法呢。这个还是很多的。就是因为太多了，所以可以应对各种各样的交互需要和技术实现。
    这里我们分四个控件：第一是整体控件，第二是头部控件，第三是浮层控件，第四是主体控件。。这里列一张可能出现情况的表。

整体控件	头部控件	浮层控件	主体控件	备注
CoordinatorLayout 协同布局	AppBarLayout> CollapsingToolbarLayout>flag&Toolbar	view.pin效果(记不清了)	NestedScrollView最好 , LinearLayout	谷歌推荐响应式布局 NestScrolling思想设计
ListView	view or HeadView	FrameLayout内部View	item views	这几个情况一般都是 FrameLayout包裹的 做法一。看recyclerView.
ScrollView	view	FrameLayout内 部的view	views	因为不用考虑复用性。所以 可以直接使用onScrollChange 的高度y，来判断布局变化的 时机。用做法一。
recyclerView	view	FrameLayout内 部的view	item views	因为recyclerView和ListView考虑 复用，无固定view.这里的判断 一般是onScroll中的条目变化， 不像ScrollView的只有坐标，这里 还有visibilityItemIndex的逻辑，所 以，我们应用层，可以直接使用 组合成浮动层效果。
ScrollView中嵌套GridView	同下	同下	同下	因为GridView和ListView一样，可以直接看下面
ScrollView中嵌套ListView	view	FrameLayout内 部的view	view	整体的响应肯定是使用ScrollView的 。这里的关键是处理手指交互的界 面显示。有几种处理办法。 1,把listView上部分和下部分作为 listview的headView和footView,这样 把整个布局替换成了ListView. 2,手动设置ListView的高度,把listview 高度写死,在显示滑动的时候,也可 以有良好的体验。 3*，这里比较阴了,使用LinearLayout 实现AdapterView的布局策略，自定 义这样一个布局作为ScrollView长子的子布局。 4*，还有个阴的，重写ScrollView, 使之在处理ListView的测绘触摸等时 候，进行适配处理。
自定义滑动View	可以和浮层一起用做法 一，也可以分开用做法 二在自定义布局里面做 好分配。		任何系统或者自定义的滑动布局

    在界面上往往最求最快的实现。在这里，使用CoordinatorLayout，和做法一，是比较快速一点的捷径。最终技术的选型实现，还要根据具体的项目发展情况，等等。。

 CoordinatorLayout所做的响应式布局。比较复杂，但是又功能强大，因为是google自己support支持，可以拿来就用非常方便。。就是在理解上需要下点功夫。协同布局，全部使用NestedScroll的接口和思想。因为有NestedScroll的支持，先天性解决了滑动冲突，必须外部使用完事件，内部才会继续使用事件。在默认情况下,也就是默认的appbar_behavior和默认的scrollFlag的支持下，CoordinatorLayout只能有一个AppBarLayout和一个父布局,默认只能浮动和协同头部的布局，理解behavior和scrollflag是了解整个机制的关键。自定义behavior是扩展宏伟功能的入口。 简单地理解，behavior就是滑动事件的转移到需要的布局上面,flag就是在这个转移的过程中以何种方式转递。只有理解，才能更好的灵活应用。 子View一旦获得事件，父控件在这个事件之后就不再使用。这个是Nested接口需要解决的问题。scrollView在滑动向下时,可以通过behavior用来拉伸appBarLayout,或者当scrollView不再使用事件的时候再通过通过NestedScrollView同样把behavior动作传递出去，协同别的布局。