内置浏览器返回键重定向问题解析

1、目前android端物理硬件返回键与左上角返回键处理基本一致，都是调用webview中的goback方法。

      好处：可以满足大部分的网页后退与关闭。

      不足之处：个别网页会因为重定向问题无法返回之前的页面

                        解决方案：不是必需重定向的页面，去掉重定向。如果是必需要重定向的页面，客户端需要自己维护一个历史栈，同时需要前端通过JS告诉客户端哪个是重定向的页面。这样客户端后退时自行过滤掉重定向的页面。当然以上的方案只能解决咱们自己写的页面，其他第三方的页面无法处理的。而另外一种比较通用的、实现成本小的办法就是“增加关闭按钮”。咱们目前采用的就是这种方案。像微信，微博也只能是用这种。

       此方案另外一个问题:H5页面弹出的浮层无法不掉。（这个问题下面有解决方案）

 2、IOS的处理机制是这样的：左上角的返回键调用的是H5的goback方法，根据goback方法的返回值true/false进行判断。是关闭啊还是什么也不操作，由H5来返回上一级页面。

       

      我说一下我对这种方案的想法：从整体上的设计，我觉得不妥。你想：我调用我自己的返回值，我知道要操作什么，我也有能力操作，我还得请求一下H5，然后由H5去返回。然后我还得知道返回值，来决定我的下一步操作，很奇怪。如果说特定的页面，为了实现功能，几个页面的话，我可以特殊这么处理倒可以。但是整体设计都用这种的话，我觉得不太妥当 。

      

      优点：实现了所有的功能要求。H5中部分页面弹出的浮层自己也能关掉了

      缺点：一旦哪个页面加载到了其他第三方的H5页面，那么可能无法关闭或无法返回（根据编码写法不同）

3、如果android端同步使用IOS的处理方案。

      1、首先系统版本4.4以下的机器 ，可以调到H5的goback方法，但是收不到返回值。所以无法处理下一步的操作。通常都是到一级界面，无法返回了。此时还是得使用“关闭按钮”。

      2、如果采用这种方案，那么一旦哪个页面加载到了其他第三方的H5页面，那么可能无法关闭或无法返回

综上所述，我认为IOS可以保持不动。android端的处理方案为:

         android的物理返回键不动，仍然是调用webview自己的返回键。左上角的返回键方案：

          第一步：事先约定好客户端点击返回的时候，需不需要通知H5。如果有些页面需要通知H5，则可在URL中配置相关的参数isGobackNotified=true;          

          第二步：客户端点击返回键，判断当前URL是否需要通知H5，如果需要的话，则通知一声。然后H5根据通知来决定自己的操作，比如：关闭浮层等。

          第三步：后退和关闭操作由客户端处理。

      

      此方案优点：解决了H5的弹出浮层的BUG,同时也可以进行后退和关闭。

      此方案缺点：听H5童鞋说，实现起来不容易。

     方案二：如果说非要使用调用H5 goback的方案的话

       那么 android可以这样解决这个问题：

       4.4以上的版本可以正常解决。

       4.4以下的版本，返回到一级界面的时候，则可通过“关闭按钮”或物理返回键返回

      

      但这种方案，无论android与ios都存在的问题是：如果打开的是第三方的H5的话，无法返回或无法后退

       方案三：    android端不区分版本处理，客户端调用H5的goback方法，然后H5端通过JS回调客户端的特定方法。然后客户端进行下一步的操作。