writen by Tony@tokyo
[故事概要]
今天调查一个线上Bug。
产品本身是一个Android 应用。 已APK的方式安装和运行在Android设备上。整体的架构是naive 开发搭框架，中间嵌入WebView。这些都没什么好说的。
这个线上Bug的问题是，在某些特定画面迁移过程中，Android设备的后退按钮会失效。 绝大多数的画面都是可以的。
比如以下这种Case的画面迁移：
A一览画面 -> B 登陆画面 -> C 登陆确认画面 -> D 登陆终了画面 -> A 一览画面
对应每个阶段的画面URL是：
/list -> /xxxregiest?id=12 -> /xxxregiest-> /xxxregiest -> /list
现象则是，在整个迁移的链条走完之后，又回到A 一览画面之后， 此时再点击 Android设备的后退按钮，什么反应都没有。。。。
[调查和分析]
首先，想到用Android设备自带的浏览器来做一次操作。
在Android自带的浏览器上，当走完整个迁移链条之后，此时点返回按钮，会出现《post送信重复提交》的信息。。。。
于是我果断想到，这肯定是因为画面迁移之间，有form提交，所以WebView回退的时候，失败了。
于是我换了个平板测试，结果发现，在 B 登陆画面 -> C 登陆确认画面的迁移上，回退按钮是有效的。
但是B 登陆画面 -> C 登陆确认画面的迁移也是依靠form提交完成的阿？
问题究竟在哪里呢？
啊啊啊！！！我看到了，那一霎那。
回退按钮无效的根本原因在于：
xxxregiest这个页面是有状态的。同一份后台代码，同一个url，会对应着完全不同的前台view。
/xxxregiest 不是Rest的，也就是说在load这个url的时候，后台程序会根据post送信来决定forward到哪里去。
B 登陆画面 -> C 登陆确认画面 -> D 登陆终了画面，进行了两次post数据的提交。并且系统用了token来避免重复提交。
也就是说，两次post数据提交的过程是不可逆的。 当到最后，再点击回退按钮的时候，只是单纯的重复提交整个数据链的最后一次post，必然是失败的。
[对应]
最开始我想到的方法是，在form提交的js中，调用后台JsInterface的代码，做webView.clearHistory()。
这样，让不想回退的画面，在前画面提交以前就把webView里面的历史纪录全部清掉。
但是后来发现，clearHistory只能在当前画面初期化完成之后才可以生效。
最后，能够简单有效的就是捕捉当前的keydown事件，在里面根据当前的URL死判画面的迁移。
简而言之，重写整个Web画面的后退流程。
代码的例子：
@Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
if (webViewUrl == null) {
return super.onKeyDown(keyCode, event);
}
try {
switch (keyCode) {
case KeyEvent.KEYCODE_BACK:
//取得当前url
String currentUrl = webView.getUrl();
//根据业务逻辑重排流程
if (currentUrl.indexOf("xxx_regist") != -1) {
return true;
} else if (currentUrl.indexOf("list") != -1) {
webView.clearHistory();
webView.loadUrl(this.getResources().getString(R.string.top_page));
return true;
}
//预留下来的，交给webView自己判断
if (webView.canGoBack()) {
webView.goBack();
return true;
} else {
//如果没有可以back的url，并且是首页，则跳出退出对话框
if (webViewUrl.equals(this.getResources().getString(R.string.top_page))) {
DialogFactory.exitApplicationDialog(this).show();
return false;
}
}
} catch (Exception e) {
}
return super.onKeyDown(keyCode, event);
}
#以上#