UIWebView代码注入时机与姿势

一个奇怪的业务场景,引发的胡乱思考

问题其实不难解决,只是顺着这个问题,发散出了一些有意思的东西

本文旨在讨论UIWebView,WKWebView有自己的机制,不用这么费劲

我们的业务最大的最重要的流量还是在PC与WAP,也就是说主要业务还是以Web的形式进行开发的,WAP上很多活动/页面/功能,他们不是由APP的H5团队主导开发的,也不在APP整体的规划功能内,但经常会以所谓低成本的形式接入APP尝试,快速的也在APP里进行传播。(后续验证可行和有效后,也会纳入APP的功能规划里,以最流畅的体验进行呈现)

但这样会有一些问题,纯为WAP开发的页面,直接扔到APP的WebView里表现并不好

WAP的团队开发出来的界面一般长这样
15049394419512

如果这样的页面不做任何处理直接在APP中低成本接入会变成这样

15049394419512

问题就在于APP是有自己的NavigationBar的,而WAP的页面一般都为浏览器而生,浏览器没有自己的导航条于是WAP的团队很自然都会在WAP页面里开发出一个导航条,如果这个页面不做任何针对APP的处理,直接放入APP的WebView中,就会出现这样丑陋的双导航条,一个是native App自己的,一个是WAP网页自己画的

这是一个非常常见的场景

想要实现也非常简单

WAP识别APP的UA,进行定制化的开发就好了

为什么说他奇怪?

团队不同,业务场景不同,也面临不一样的问题,对于我们来说,这个问题不在于如何实现,而在于如何做到让WAP开发最省事。因为背景交代过了,WAP的前端团队和APP完全不是一拨人,如果能有什么办法让WAP前端团队在开发工作中尽量的无感知,尽量的少操作,不需要WAP团队在开发的时候人工的判断UA,选择性渲染,于是蛋疼的问题来了

  • 直接让WAP开发人员定制开发
    • 后端渲染的时候判断UA
    • 前端模板隐藏UI

现有老的开发模式就是这样,每次都是人工适配,纯体力活,有时候项目紧急WAP团队就会忘了,上线的时候一发现,咦?在App里好丑啊,虽然改动很小,但一块后端判定UA,一块前端模板选择渲染,代码分散在几处,改起来很麻烦

单纯是Bar的话不是问题,写进WAP基类就行,问题是类似的场景看业务功能,有时候不止是Bar,会有定制化的东西,在APP里表现,不能和WAP一样

  • WAP的编译框架支持
    • 这确实是可行的,并且是很好的解决方案之一
    • 厂里的前端使用的是FIS的编译打包框架,支持一定的插件扩展,可以在前端代码编译环节,就自动加入UA判断,对特定的UI,进行有规律的渲染控制

这个太底层了,对每天几千万UV的WAP来说,进行这么大的改动,风险高,收益低(毕竟这个界面适配APP只是搂草打兔子捎带手)有点难推动,后续确实可以尝试一下

  • WAP的JS插件支持
    • 基础模板引入JS脚本
    • 用JS脚本在client里判断UA
    • 提取特定Dom
    • 隐藏Dom

最大的问题在于,JS在client里执行的时机,JS执行的时候,这个Dom已经被渲染出来了,当你判断UA,要移除的时候,画面那个bar会闪一下,整体效果是,整个页面带着bar加载出来了,但是会突然闪一下bar消失

  • App在WebView里注入CSS
    • 让WAP只需要对需要隐藏的Dom做个标记比如XXWAPBAR(WAP只用写几个字母)
    • 在WAP浏览器里,无感知,完全不需要定制化开发
    • 在App WebView加载网页的时候,注入额外的CSS,将含有XXWAPBAR标记的Dom隐藏

看起来靠谱,看起来是一种WAP开发人员几乎不用管不用操心,也不会影响WAP,只在APP里有独有效果的设计,试试看

WebView注入

对于Hybrid App来说,向WebView里面注入JS(CSS也是通过JS代码的方式注入),是太常见的一件事情了,注入就是最常见的native to js的通信方式

  • iOS
1
[self.webView stringByEvaluatingJavaScriptFromString:injectjs];
  • 安卓
1
webView.loadUrl("javascript:" + injectjs);

我们注入这么一行demo JS代码试试看

1
2
3
4
var style = document.createElement('style');
//XXWAPBAR 是我们的WAP顶部Bar的class标记
style.innerHTML = '.XXWAPBAR { display: none;}';
document.head.appendChild(style)

习惯性的在iOS的webViewDidFinishLoad,安卓的OnPageFinished的时机去注入这个JS,Run一下看看效果,纳尼?还是闪烁!看来是注入晚了,网页已经渲染完了,这时候注入css,会像前面提到的client端隐藏dom一样,画面会闪烁一下,那我们早一点,webViewDidStartLoadonPageStarted的时机注入?Run一下看看效果,纳尼?彻底没反应?

WebView的JSContext

JSContext是Webkit里面JavaScriptCore框架里面的js上下文,其实就相当于一个WebView里面的js运行时,也可以理解为JS运行环境,先拿iOS做个试验

iOS的同学想必都知道可以用KVC的方式取出UIWebView的JSContext,那么做一个试验,分别在StartLoadFinishLoad的delegate里打印一下JSContext

1
2
3
4
5
6
7
8
9
10
- (void)webViewDidStartLoad:(JSBridgeWebView *)webView {
JSContext* context =[self.webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];
NSLog(@"%@",context);
}
- (void)webViewDidFinishLoad:(JSBridgeWebView *)webView
{
JSContext* context =[self.webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];
NSLog(@"%@",context);
}

运行过后你就会发现,同一个webview的JSContext,在时机不同,他根本就不是一个JS上下文对象,地址都不一样。相同的JS,运行在不同的JS环境里,自然效果是完全不一样的。

每次WebView加载一个新Url的时候,都会丢掉旧的JS上下文,重新启用一个新的JS环境新的JS上下文,因此你在webViewDidStartLoad的时候即便使用stringByEvaluatingJavaScriptFromString去注入js,也是把js代码在旧的上下文中执行,当新的js上下文完全不受任何影响,没任何效果。

在资源加载的时候注入js

安卓的道理也是一样的,因此我们选择OnPageFinished已经晚了,此时页面已经渲染完了,再注入画面会闪,选择OnPageStarted其实是早了,注入到错误的js上下文里,等页面开始加载,就启用了新的js上下文,因此白注入了。

我们得换一个事件,选一个恰到好处的事件回调,安卓的WebViewClient的onLoadResource事件,这个可以满足我们的需求,这个时间点新的js上下文已经生效,整个网页处于加载资源的阶段,还没开始进行排版与渲染,此时加入刚好满足需求

运行一下,效果非常好,画面打开的时候,页面中就已经看不到那个Bar了

蛋疼的问题来了:

iOS的UIWebView没有这个事件,UIWebView只有可怜的这4个事件

1
2
3
4
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType;
- (void)webViewDidStartLoad:(UIWebView *)webView;
- (void)webViewDidFinishLoad:(UIWebView *)webView;
- (void)webView:(UIWebView *)webView didFailLoadWithError:(NSError *)error;

UIWebView的其他出路之一,NSURLProtocol

iOS平台提供的NSURLProtocol是一个可以Hook所有网络请求的工具,无论是由WebView发起的,还是直接由App发起的。

NSURLProtocolHybrid App相结合可以碰撞出非常多的火花比如

  • 利用NSURLProtocol实现Web图片Native缓存
    • UIWebView的缓存有统一上线,并且不好细粒度控制
    • Hook图片请求,不走UIWebView的网络请求,直接通过SDWebImage,进行fetch&cache图片
  • 利用NSURLProtocol实现Hybrid Web页面静态资源本地包
    • css/js/image等静态资源打包随app下发
    • WebView发起请求的时候Hook,从app本地包中返回静态资源
    • 加快网页加载速度
    • 静态资源本地包通过app的方式进行批量更新
  • 利用NSURLProtocol实现Web图片native滤镜处理能力
    • UIWebView发起图片资源加载
    • Hook后由App下载图片
    • App下载图片后进行native滤镜处理
    • App将滤镜过后的图片返回Web

怎么使用NSURLProtocol我就不多说了,随便搜搜你能搜出一大筐。

我们这个场景也可以利用这样方式来实现,简单的说,App就是通过Hook的方式,直接修改了WAP页面的源代码。但有2个选择,可以选择修改css代码,也可以选择直接修改html页面

  • HookCss

每个页面都要加载很多CSS,一般我们的WAP项目里都有一些基础模板通用css,假设是common.css

1.NSURLProtocol选择性hook我们自己域名下的common.css文件
2.通过iOS的字符串处理,给这个文件尾部增加css信息
3.和JS注入的代码里的css一样.XXWAPBAR { display: none;}

1
NSString *newcontent = [NSString stringWithFormat:@"%@\n\n.XXWAPBAR { display: none;}\n",content];

这样Run一下,效果非常好,画面打开的时候,页面中就已经看不到那个Bar了

  • HookHtml

如果不修改CSS,修改HTML也行,但这样就不限定文件了,任意自己域名下的HTML

1.NSURLProtocol选择性hook我们自己域名下的任意HTML文件
2.通过iOS的字符串处理,给这个head标签增加信息
3.给head标签增加script子标签
4.其实直接给head标签直接增加style子标签也可以

1
2
3
4
5
NSString *newcontent = [content stringByReplacingOccurrencesOfString:@"<head>" withString:@"<head>\n<script type=\"text/javascript\">\n
var style = document.createElement('style');
style.innerHTML = '.wkWapX { display: none;}';
document.head.appendChild(style);
\n</script>\n"];

这样Run一下,效果一样,画面打开的时候,页面中就已经看不到那个Bar了

UIWebview的其他出路之二,WebFrameLoadDelegate

这是一个黑科技

这个科技和KVC取JSContext一样,都属于UnDocumented API

WebView与JSContext在UIWebView上的困境

自从iOS 7推出JavaScriptCore,苹果本意是开放这个框架,让开发者根据自己的需求,自己独立运行和开发脚本引擎,但很多人都想在UIWebView上使用JavaScriptCore里非常方便的API快速的进行js与oc的互通,使用里面的JSContext,抛弃以往iframe走shouldStartLoadWithRequest的delegate方式。

UIWebView是基于Webkit的,内部天然存在着一个javascriptcore,以前只是iOS没对外开放,iOS7才对外开放

但很可惜,对于UIWebView看起来苹果真是对它没多少爱了,并没有把JSContext暴露出来,拿到不到webview的JSContext,整个JSC的API也玩不起来,于是聪明的开发者利用KVC的方式还是把它拿了出来

documentView.webView.mainFrame.javaScriptContext

说到底这还是一个Undocumented Api,没有记录在合法苹果开发者文档与头文件的一个Api,存在一定的风险,但即便如此,使用这个方式依然存在一个问题,也就是我上文强调过的WebView与JSContext的问题

每次WebView加载一个新Url的时候,都会丢掉旧的JS上下文,重新启用一个新的JS环境新的JS上下文,因此你在webViewDidStartLoad的时候即便使用stringByEvaluatingJavaScriptFromString去注入js,也是把js代码在旧的上下文中执行,新的js上下文完全不受任何影响,没任何效果。

大家在搜索javaScriptCore使用指南的时候,总能看到类似这样的代码,在OC中给JSContext直接注入对象or函数

1
2
3
4
5
6
7
// Use JSExport Protocol 将oc对象注入给js
context[@"ViewController"] = self
// 将oc的block,注入给JS当做函数
context[@"hello"] = ^(void) {
NSLog(@"hello world");
};

如果我们基于这种模式来构建Hybrid Bridge,那么将带来很大的便利,最直观的优势就是,这种bridge是同步直接return返回的

而以前iframe通过shouldStartLoadWithRequest的delegate方式想要返回,必须得异步,并且用js语句注入来执行回调,才能返回数据给js。

这种基于JSContext的同步Hybrid Bridge构建的时机如果是webViewDidFinishLoad就会存在一些问题,在loadfinish的时候,代表网页中的js代码已经执行完了,如果此时才将bridge构建完毕,那么loadfinish之前执行的js代码是不能够使用jsbridge

如果我们能捕获到新JSContext刚创建的时机,那么我们就能搞事情

  • 比如创建这种同步jsBridge,是的任意js执行的时候都能有效jsBridge!
  • 比如解决我们今天聊得场景问题,在新JS环境刚创建,网页还没开始排版和渲染的时候,注入CSS!

WebFrameLoadDelegate寻求突破

搜索和寻找中发现了这样一个东西

TS_JavaScriptContext

简单的说,这个开源库也找到了一种UnDocumented API来准确捕捉到了新JSContext刚创建的时机,通过WebFrameLoadDelegate

WebFrameLoadDelegate这个词随便在网上一搜,你就能搜到API和OC/Swift代码,但很可惜,这个代码仅限macOS

Apple关于WebFrameLoadDelegate的官方文档URL

15049523772825

从这个官方文档中你可以发现比UIWebViewDelegate多很多的各种Webkit内核的事件

15049524279135

看到其中最重要的一个delegate没?

webView:didCreateJavaScriptContext:forFrame:

没错就是他,意思是说,其实Webkit内核早就把这类事件都抛出来了,并且在macOS的SDK中把这些事件都暴露给了开发者,但是在iOS的SDK中,UIWebView的头文件设计却把这些事件都吞掉了,没暴露出来,不让开发者使用

按着苹果的尿性,源码里一般都会这么写

1
2
3
if (_xxDelegate && [_xxDelegate respondsToSelector:@selector(webView:didCreateJavaScriptContext:forFrame:)]) {
[_xxDelegate webView:webView didCreateJavaScriptContext:ctx forFrame:frame];
}

如果苹果把这个delegate给藏了起来,没有写进UIWebViewDelegate的Protocol里,但我们自己把这个函数实现了,按着苹果的尿性,就应当可以触发

于是TS_JavaScriptContext这个项目就按着这个思路去尝试并且真的成功了,他给NSObject添加了一个category,使得NSObject拥有了webView:didCreateJavaScriptContext:forFrame:的implement,因此respondsToSelector的判定就会生效,从而我们就拿到了JS环境的创建事件

15049532969678

既然已经拿到了正确的时机,后面注入JS就好了,效果杠杠的,

一些探讨和猜测

到了这一步,单纯的找到时机,已经能解决我的问题了,不过WebFrameLoadDelegate里面的其他事件让我产生了很大的好奇心

Apple关于WebFrameLoadDelegate的官方文档URL

从这里可以看到很多很多的事件,都是UIWebView里没有的,可以说macOS下的WebKit框架对外暴露的Api,更加能窥视Webkit原本的运作机制以及事件周期

想要窥视更多Webkit也可以看这个

ios UIWebview runtime header 用于私有api调用查看

其实Webkit整个都是开源的,网上也有很多教你自己下Webkit源码,编译Webkit的,看些个是最直接的,但毕竟太庞大了,头疼看不进去,哈哈哈哈哈

我在之前的文章动态界面:DSL&布局引擎中画过这样一个图

而今天发现,在这图里面还需要补充很多环节,也就是html/css/js在被加载之前都发生了啥

浅谈WebKit之WebCore篇

可以看看这篇文章来学习一下,然后梳理一个大概的理解

  • 当webview跳转了一个url
  • 会先交给Frameloader
  • 然后就会new Document啊
  • Load Resource啊(html/css/js)
  • 就会commit Document
  • 然后parse HTML
  • 生成Dom树啦
  • 再排版 layout
  • 最后渲染 render

看了苹果的WebFrameLoadDelegate文档和那篇私有api调用查看,你会发现有很多forFrame的Api&Delegate,可见FrameLoader还是很重要的一个环节

而且,通过TS_JavaScriptContext这个项目,我还发现一个有趣的现象,就是如果页面中不包含任何的JS(无论是HTML中的JS代码,还是额外JS文件)那么就完全不会有webView:didCreateJavaScriptContext:forFrame:的事件被抛出来,可以想象既然没有JS代码,要毛的JS引擎。

后记

其实一开始我们聊的要注入CSS隐藏WAPUI的业务场景,已经不重要了。这么整体review一下你会发现,客户端解决方案里只有安卓比较舒服,iOS UIWebView都不太尽如人意。而且换了WKWebView可能这些问题都不存在(恩,项目还没用,没深挖)

  • 前端解决
    • 定制开发(机械工作,繁琐,没意义)
    • 前端编译框架(成本大,风险高,跨团队)
  • 客户端解决
    • 安卓onLoadResource时机注入(比较完美)
    • iOS NSURLProtocol改HTML源码(感觉并不很好)
    • iOS 非公开Api调用(可能有审核风险)

一个奇怪的业务场景,引发的胡乱思考

但是这个奇怪的场景,和胡乱发散的思考,确实让我多的了解了很多关于WebView内核的机制,这内核机制太庞大了,现在还是靠发散思考和搜索查找进行学习,有时间和精力真的想好好看看,亲自编译一下Webkit的源码,光是纯纯的源码文本就20M呢,要想看进去还真是一个十足的挑战