关于android右滑返回的几种解决办法
最近简单看了一下ios开发，界面开发方法感觉不如android来的痛快。可能接触的比较少，大概在做界面开发的时候各种要切图，还是android来的实在。而且关于屏幕适配在android上没法解决，在ios上也是一大痛点啊，这些在web上解决起来游刃有余，这也是web以后一统天下的一大原因吧。
看了几天ios开发之后，感觉android上的东西基本都是按照ios的标准来的。个人感觉谷歌的Material design非常棒，不知道在国内为啥流行不起来。但是ios设计有官方支持，开发起来更酸爽，android按照苹果的规范来开发就显得不这么自然，当然，ios用户体验确实无懈可击，大部分都是手势操作，例如滑动删除，滑动返回等等。今天就来分析一下滑动返回在android上实现的方法思路。
滑动返回的核心就是View的滑动
滑动返回的核心不过就是根据手势来进行滑动，听起来确实像一句废话。关于View滑动大概就是三种方法，而滑动返回就是根据这三种方法进行拓展的。
- 通过View自带的scrollTo和scrollBy
- 通过动画，包括属性动画和视图动画
- 通过动态的布局
- 还有一种在v4包里面的ViewDragHelper，关于用法不是本文的重点，但是绝对是开发的神器类，市面上的手势操作应用，基本都能用它来实现
滑动返回的几种解决方案
以上View滑动方法结合滑动返回需求的实际使用场景
第一种通过scrollTo和scrollBy实现滑动
结合固定的弹性滑动方法。scrollTo/scrollBy只能滑动View内的内容，所以适合二级页面少的情况，我们可以在同一个Activity中添加两个视图，通过scrollTo/scrollBy进行动态的添加删除View。
最好的应用场景就是最多二级页面，而且页面结构不复杂的情况。这样我们就不用多创建额外的Activity，在进行页面切换的时候异常的流畅。缺点也是显而易见的，就是要在逻辑性以及界面结构及其简单的情况下使用，最重要的是页面的跳转不能过多。因为太多原因的限制，所以这种方法适用的场景很少，但也有些情况使用它却会让页面流畅度增加N+1倍。
例如像nice应用中拍照和摄影就放在了同一个Activity中，然后结合ViewPage+Fragment使用。很明显的问题就是在切换的时候会明显的卡顿一段时间，我用价位在2500左右的手机进行测试的时候都能感到非常明显的卡顿。造成卡顿的原因是什么呢？因为在调用系统摄像头，在两个Fragment中分别调用了打开和关闭方法，这样就会有卡顿的情况。在这种场景下就可以使用scrollTo/scrollBy，在同一个页面中添加两个视图，但是两个视图共用同一个Camera，这样在切换的时候速度就会很快了。
第二种我们可以使用动画或者动态布局或者ViewDragHelper，当滑动到一定距离的时候进行弹性滑动，然后结束掉此Activity，就实现了
主要是首先要实现View跟随着手势滑动。主要的问题是需要设置一个透明背景。关于git上很多第三方都是基于此方法，而核心问题需要设置窗口半透明windowIsTranslucent为true，设置之后当滑动返回的时候，就能看到上一个窗口的view了。当然设置了这个属性之后会出现各种各样的问题，需要根据具体需求来修改。
第三种方法也是首先实现滑动，在滑动的时候把上一个Activity的页面加到滑动的左边，也就是说我们在滑动时候看到的上一个视图是个假视图，并不是上一个Activity，只是Activity绘制的一个图。
这种方法对程序的影响最小，但是也存在问题。首先我们需要在视图结束的时候执行finish方法真正结束掉这个Activity，在一些定制的系统上，每次finishActivity都会闪屏一下，这样我们可以清楚的看到这种不好的体验。还有就是因为我们看到的上一个Activity是个假的视图，所以当滑动完成之后立即点击会没有反应。
以上就是解决右滑返回的三种方案，关于代码，请移步github选择合适的解决方法