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);
}
#以上#