Android WebView 302斗争之旅
一.背景
越来越多的业务接入，项目内多多少少会出现几个H5页面，只是单纯的提供WebView容器接入H5页面根本满足不了需求，他们需要登录态，需要制定协议控制Native的导航栏，或者需要JsBridge做一些更复杂的操作，这篇主要讲登录态出现的问题。
二.涉及的知识
Android WebView加载url的时候，我们是这样做监听的：
- 页面加载前会回调onPageStarted
- 页面加载完成会回调onPageFinished
- 当页面加载前且在onPageStarted后会回调shouldOverrideUrlLoading让我们决定是否自己处理这个url
public class PerformanceWebClient extends WebViewClient {
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
return super.shouldOverrideUrlLoading(view, url);
}
@Override
public void onPageStarted(WebView view, String url, Bitmap favicon) {
super.onPageStarted(view, url, favicon);
}
@Override
public void onPageFinished(WebView view, String url) {
super.onPageFinished(view, url);
}
}
三.自定义返回栈
14年最初接触的项目，WebView页面是需要登录态的，处理方式就是shouldOverrideUrlLoading方法中，直接将url后面拼入参数，return true告知WebView组件url我们已经处理，你不用管了。
public class PerformanceWebClient extends WebViewClient {
@Override
public void onPageStarted(WebView view, String url, Bitmap favicon) {
super.onPageStarted(view, url, favicon);
}
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
if (url.startsWith("http") || url.startsWith("https")) {
view.loadUrl(appendParamsToUrl(url));
return true;
} else if (isScheme(url)) {
return true;
}
return false;
}
@Override
public void onPageFinished(WebView view, String url) {
super.onPageFinished(view, url);
}
}
简单的代码结构大致是这样，但是迅速暴露出一个问题：302页面返回栈。
我们主动load的页面会加入到返回栈内，而当我们webview.goBack()的时候，加载的时候还是一个302，导致无法正常关闭页面。
这时想到一个方法，自己定义返回栈。
问题是，一个url入栈的标准是什么？
举一个栗子：
A==302==>B==302==>C
加载A的url查看回调顺序是：
onPageStartedA==>onPageStartedB==>onPageStartedC==>onPageFinishedC
从这个角度来看，貌似onPageFinished中将url作为已加载的url挺靠谱的，但是现在存在一个问题，我每次回退栈都要以重新load的形式刷新页面，性能和流量都有耗费。
还存在一个问题，在实际情况中遇到，某一个业务url加载形式例如：
A==302==>B==302==>C==302==>D
加载A的url查看回调顺序是这样的：
onPageStartedA==>onPageStartedB==>onPageStartedC==>onPageFinishedC==>onPageStartedD==>onPageFinishedD
C页面是302到D的，但是也走了onPageStarted方法，猜测是做了某些操作再主动重定向的，这种url我们也不希望加入返回栈内，但是我们不能准确的检测到。
四.尝试优化
在后来接手的另一个项目中，也存在了302返回栈的问题，既要保留登陆态，又需要302不加入返回栈。
这时看到一个这样的处理方式：
class MerchantOnTouchListener implements View.OnTouchListener {
@Override
public boolean onTouch(View view, MotionEvent motionEvent) {
try {
WebView.HitTestResult hr = ((WebView) view).getHitTestResult();
if (hr != null && mLastUrl != null) {
switch (hr.getType()) {
case WebView.HitTestResult.SRC_ANCHOR_TYPE:
case WebView.HitTestResult.SRC_IMAGE_ANCHOR_TYPE:
break;
case WebView.HitTestResult.UNKNOWN_TYPE:
return true;
break;
default:
return false;
}
if (previous.isEmpty() || !previous.get(previous.size() - 1).equals(mLastUrl)) {
previous.add(mLastUrl);
}
}
} catch (Exception ignored) {
}
return false;
}
}
当我们触摸屏幕时（通常就是开始点击链接）使用HitTestResult去看状态，如果得到的type是链接跳转类型，那么将最后加载的url加入返回栈。
实际效果是：302被避免了，但是页面内如果触摸的地方url有变化（比如params变了）也会加入返回栈，回退次数还是增加了，而且解决不了重新加载的问题。
就在这时得知了最开始接触的项目更换了登陆方式，App的登陆就是H5页面，登陆成功后拿到Cookie，Cookie既可以给Native访问Api使用，也可以在H5页面做登录态使用，页面栈全部交给WebView容器处理。
以为这就结束了么？
但是又出现了一个问题：运营商劫持
国内的网络环境大家比较了解，Headers的丢失率比较高，丢失了Cookie就等于丢失了登陆状态，这是其中一点；其次是如果业务发展已经很庞大，很难从Native Token 走SSO的方式转化为Cookie方式。
五.总结
目前经历了几个项目，一直没有很优雅的解决302的问题，目前的做法也有一些瑕疵，希望在以后的工作中能找到更好的方法。
