言

WKWebView是iOS8 出来的浏览器控件,用来取代UIWebView.对于WKWebView与UIWebView的对比特点,这里就不过多的叙述,都算是老生常谈的问题了,网上的说明也很多.近来在做Web端,需要植入移动端,并且做JS交互工作.以前写过的JavaScript:浅谈iOS与H5的交互-JavaScriptCore框架是用于UIWebView.在WKWebView并不适用了,自己做的过程中遇到一些坑,在这里总结一下,做一下记录.

WKWebView加载本地 html文件

现在的项目要求就是使用存储在本地的html文件 js文件 css文件 img图片等文件.我使用HBuilder创建了一个Demo工程.里面包含了基本的文件以及图片资源.如下所示.然后拖到Xcode工程中.

然后我们把整个Html工程文件夹导入工程中.

WKWebView 在iOS 9 有新的加载本地方法- (nullable WKNavigation *)loadFileURL:(NSURL *)URL allowingReadAccessToURL:(NSURL *)readAccessURL API_AVAILABLE(macosx(10.11), ios(9.0));.但是我看了网上有一些博客说- (nullable WKNavigation *)loadRequest:(NSURLRequest *)request;并不能加载本地html文件.其实两者都能加载.只是需要把路径写对.第一个方法就不过多叙述了.网上有很多的博客.这里我就用第二个方法来看一下如何加载.

NSString *path=[[[NSBundle mainBundle] bundlePath] stringByAppendingPathComponent:@"index.html"];

NSURLRequest *request=[NSURLRequest requestWithURL:[NSURL fileURLWithPath:path]];

[_mainWebView loadRequest: request];

• 1
• 2
• 3

运行效果图如下.

Xcode工程中 html文件 加载js文件 css文件 img文件

上面我们加载了html.可是css样式 .img文件和js文件都没有加载出来.那么我们该如何解决呢?(html原始加载图如下所示.)

对于css文件、img文件 ,js文件我们只需要把html文件中的文件夹路径删除即可.如下所示.

???????? 注意:这里是使用的- (WKNavigation *)loadRequest:(NSURLRequest *)request;方式加载的网页.所有如上设置即可.如果使用的是loadFileURL:(NSURL *)URL allowingReadAccessToURL:(NSURL *)readAccessURL或者loadHTMLString:(NSString *)string baseURL:(NSURL *)baseURL;都需要设置本地资源文件所对应的路径! 我们只需要把资源文件所对应的路径设置给readAccessURL 和 baseURL即可(). 例如下面所示.

//假定都在工程根目录之下.

NSURL *baseURL=[NSURL fileURLWithPath:[[NSBundle mainBundle] bundlePath]];

[_mainWebView loadHTMLString:[self loadHtmlString] baseURL:baseURL];

• 1
• 2
• 3

对于js文件,有时候我们发现我们就算如上删除了js文件夹的路径依然不能使用.这是为什么呢?.这里就要去检测查看工程的设置,是否把js文件当成一个可编译文件使用了.我们需要把它移动到资源文件中.这样就能正常加载了.如下图所示.

WKWebView中警告窗 确认面板 输入框的显示

相比于UIWebView,WKWebView对警告窗 确认面板 输入框并不能直接显示.是通过WKUIDelegate代理方法收到对应的回调方法.如下所示.

//接收到警告面板

- (void)webView:(WKWebView *)webView runJavaScriptAlertPanelWithMessage:(NSString *)message initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(void))completionHandler;

//接收到确认面板

- (void)webView:(WKWebView *)webView runJavaScriptConfirmPanelWithMessage:(NSString *)message initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(BOOL result))completionHandler;

//接收到输入框

- (void)webView:(WKWebView *)webView runJavaScriptTextInputPanelWithPrompt:(NSString *)prompt defaultText:(nullable NSString *)defaultText initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(NSString * _Nullable result))completionHandler;

• 1
• 2
• 3
• 4
• 5
• 6

我们只需要对上面的回调方法进行实现即可实现显示警告窗 确认面板 输入框等需求.

WKWebView中OC方法调用JS方法

在WKWebView OC方法调用JS方法方法比较简单.我们只需要使用如下方法即可.

- (void)evaluateJavaScript:(NSString *)javaScriptString completionHandler:(void (^ _Nullable)(_Nullable id, NSError * _Nullable error))completionHandler;

• 1

看一下我写的例子.在index.js中定义一个方法.方法内容为弹出一个警告框.代码如下所示.

function alertAction(message) {

alert(message);

}

• 1
• 2
• 3

然后在ViewController控制器中定义一个Button.定义它的点击方法.代码如下所示.

- (UIButton *)alertButton{

if (_alertButton==nil) {

_alertButton=[[UIButton alloc] initWithFrame:CGRectMake(KMainWidth*0.2, KMainHeight - 60, KMainWidth * 0.6, 40)];

_alertButton.backgroundColor=[UIColor colorWithRed:250/255.0 green:204/255.0 blue:96/255.0 alpha:1.0];

_alertButton.layer.cornerRadius=6.0f;

_alertButton.layer.masksToBounds=YES;

_alertButton.titleLabel.font=[UIFont systemFontOfSize:16];

[_alertButton setTitle:@"弹出弹窗" forState:UIControlStateNormal];

[_alertButton setTitleColor:[UIColor blackColor] forState:UIControlStateNormal];

[_alertButton addTarget:self action:@selector(alertButtonAction) forControlEvents:UIControlEventTouchUpInside];

}

return _alertButton;

}

- (void)alertButtonAction{

[self.mainWebView evaluateJavaScript:@"alertAction('OC调用JS警告窗方法')" completionHandler:^(id _Nullable item, NSError * _Nullable error) {

NSLog(@"alert");

}];

}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22

因为弹窗不能直接显示.所以我们实现了对应的代理方法.如下所示.

//接收到警告面板

- (void)webView:(WKWebView *)webView runJavaScriptAlertPanelWithMessage:(NSString *)message initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(void))completionHandler{

UIAlertController *alert=[UIAlertController alertControllerWithTitle:@"提示" message:message preferredStyle:UIAlertControllerStyleAlert];

UIAlertAction *action=[UIAlertAction actionWithTitle:@"ok" style:UIAlertActionStyleCancel handler:^(UIAlertAction * _Nonnull action) {

completionHandler();//此处的completionHandler()就是调用JS方法时，`evaluateJavaScript`方法中的completionHandler

}];

[alert addAction:action];

[self presentViewController:alert animated:YES completion:nil];

}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

这时候我们点击按钮就会调用对应的JS方法了.相比于JavaScriptCore框架还是非常简单的.效果图如下所示.

WKWebView中JS方法调用OC方法

上一个模块我们看到了OC方法调用JS方法.那么JS方法调用OC方法呢?我们也只需要几步就可以完成调用.

第一步.我们需要在WKWebView创建的过程中初始化添加ScriptMessageHandler.(命名自定例如:currentCookies.如下所示)

WKWebViewConfiguration *configuration=[[WKWebViewConfiguration alloc] init];

WKUserContentController *userController=[[WKUserContentController alloc] init];

configuration.userContentController=userController;

_mainWebView=[[WKWebView alloc] initWithFrame:CGRectMake(0, 0, KMainWidth, KMainHeight) configuration:configuration];

[userController addScriptMessageHandler:self name:@"currentCookies"];

• 1
• 2
• 3
• 4
• 5

然后实现代理方法.监听JS的回调.为了查看效果,我们仍然使用弹窗的形式展示我们的回调信息.代码如下所示.

//JS调用的OC回调方法

- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message{

if ([message.name isEqualToString:@"currentCookies"]) {

NSString *cookiesStr=message.body;

NSLog(@"当前的cookie为： %@", cookiesStr);

UIAlertController *alert=[UIAlertController alertControllerWithTitle:@"提示" message:@"JS调用的OC回调方法" preferredStyle:UIAlertControllerStyleAlert];

UIAlertAction *action=[UIAlertAction actionWithTitle:@"ok" style:UIAlertActionStyleCancel handler:nil];

[alert addAction:action];

[self presentViewController:alert animated:YES completion:nil];

}

}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

然后在Html文件中添加点击方法.

<div id="button_div" onclick="buttonDivAction()">

点击调用OC方法

</div>

• 1
• 2
• 3

紧接着.在js文件中实现点击事件.这时候要注意的是ScriptMessageHandler的名称要与上面定义的一致.

function buttonDivAction() {

window.webkit.messageHandlers.currentCookies.postMessage({

"body": "buttonActionMessage"

});

}

• 1
• 2
• 3
• 4
• 5

然后我们点击网页中对应的div就会出现对应的弹窗.效果图如下所示.

并且控制台打印信息如下所示.

总结

相比于UIWebView,WKWebView确实更加的方便快捷.本篇博客就到这里了.如果有任何问题,欢迎在评论区回复骚栋.感谢观看,最后还是附上本篇博客的Demo传送门.

eb安全策略

web安全对iOS开发者来说重要吗？重要！APP中通常会使用很多web页面，例如广告、登录流程、闪屏，或者需要使用跨平台功能的时候。你可能在页面中仅仅一部分使用web，也可以整个页面都是webView,甚至做一个web app。因此web安全对于app来说非常重要。

来自web的安全攻击有以下几种：

• 跨域攻击
• 预测执行攻击
• 窗口控制攻击

本文将针对这三种攻击类型，给出安全防御措施。

安全传输

网络传输相信大家都很熟悉了，安全的传输能够保证接收到的数据来自可信任的站点，并且在传输工程中不会被篡改。安全传输是其它安全措施的基础，采取的措施包括：

• HTTPS和WSS（webSocket Secure）
• Http Strict Transport Security（HSTS）遵循HTTPS安全协议的web只能访问同样遵循HTTPS安全协议的内容，不能访问遵循HTTP不安全协议的内容。
• Upgrade-Insecure-Requests 请求头中添加这一项表示web支持更加安全的升级机制，服务器可以重定向到这个站点的安全版本。
• 使用cookie确保安全，cookie只能被安全的传输，例如千万不要把cookie放到粘贴板上
• 在app的info.plist文件中

Allow Arbitrary Loads in Web Content 这个开关一定要置为 NO！

跨域封锁

web的内容可以来自任何站点，例如，webView上的一张图片可以来自任何服务器，也可以从任意服务器上加载一个脚本或iframe。需要注意的是要当心来自其它服务器的资源。跨域的保护已经有20多年的历史，并且形成了基本原则--同源策略：只有和页面来源相同的脚本才会被该页面执行。例如iframe来自不同的域名，同源策略不允许加载这个iframe。仅仅靠同源策略还是不够的，还需要采取其它的防御措施。

1. Subresource Integrity

服务器可能会发生异常导致下发错误的资源使得web发生crash，但是开发者通常是知道所要请求哪个资源的，在脚本里面增加一个检查签名。如果签名匹配则认为是下发了正确的资源，如果不匹配仍然可以正常工作，此时尝试从页面的资源里查找或者从自己的服务器重新加载。这样做虽然降低了性能，但是提升了安全性。

<script src="https://cdn.example/framework.js"
 integrity="sha256-8WqyJLuWKRB...oZkCnxQbWwJVw=">
</script>
window.framwork || // reload from own domain

2. Content Security Policy

HTTP response：
:status:200
Content-Security-Policy:
 default 'self'; // No inline
 script-src cdn.example;
 frame-src social.example;
 frame-ancestors news.example;

HTTP response的Header里面，default设置成自己，默认只能加载同源的资源；script-src和frame-src 分别指定可信任的脚本和iframe的来源；frame-ancestor设置成news.example，指定只有news.example可以iframe我们的web。

另外不使用inline属性的脚本也是一种防御措施，不使用inline脚本，只从文件加载脚本，这么做分离了逻辑和文件，更加安全。

3. HttpOnly cookies

HTTPOnly cookies作为一种安全措施，已经有至少15年的使用历史。在这之前script通过document.cookie这个强大的api能拿到文档的cookie，留下安全隐患。HTTPOnly cookies能够阻止这种情况，只允许HTTP请求访问cookie，禁止使用script访问cookie。它的使用方式很简单，只需要在HTTP response的Header里面加上HttpOnly这一项，如下

HTTP response：
:status:200
Set-Cookie:
 auth=abc...123; HttpOnly;

4. SameSite cookies

在HTTP response的Header里面将SameSite cookies这一项设置为Strict，那么将不允许把cookie从一个域名发送到另一个域名。例如其他人的web里面嵌入了我们的web，如果我们的服务器HTTP response的Header里面SameSite cookies=Strict，那么其他人将无法使用他的cookie来访问我们的服务器。

HTTP response：
:status:200
Set-Cookie:
 auth=abc...123; HttpOnly;
 SameSite=strict

5. Cross-Origin-Resource-Policy

Cross-Origin-Resource-Policy是推出的新功能。之前web可以加载任意web中的资源，例如图片或者script。在HTTP response的Header里面将Cross-Origin-Resource-Policy这一项设置为Same，将不允许别人的web向我们的服务器请求图片或者script，但是我们自己的web可以。

HTTP response：
:status:200
Cross-Origin-Resource-Policy:Same

6. Cross-Origin-Window-Policy

Cross-Origin-Window-Policy也是新推出的功能。之前通过window.open这个强大的api，其他人的web可以在新窗口中打开我们域名下的web，通过一些手段可以修改我们的web，导航到攻击者指定的页面。在HTTP response的Header里面将Cross-Origin-Resource-Policy这一项设置为Deny，将阻止其他人修改我们web中的内容，当然别人仍然还是可以打开我们的web。Cross-Origin-Resource-Policy适用于希望使用post message 进行窗口间通信，但是不想让别人控制我们自己web内容的情况。

HTTP response：
:status:200
Cross-Origin-Window-Policy:Deny

常见的web攻击及防御手段

Cross-Origin Attacks

• Cross-Site Scripting
• Compromised CDN
• Cross-Site Request Forgeries

Cross-Site Scripting

例如我们的web里面有一个文本框，用户可以输入文字，如下图。假如攻击者注入了这么一段脚本，如果没有采取防御措施，那么我们web的cookie就会被盗取。

在HTTP response的Header中添加HTTPOnly这一项，就能阻止脚本访问文档的cookie，从而防御跨域脚本攻击。

另外一种防御手段是Content-Security-Policy，如下

HTTP response：
:status:200
Content-Security-Policy:
 default-src 'self'; // No inline

Content-Security-Policy能保证拒绝加载外部来源的脚本，并且不使用inline属性的脚本，只从文件中加载脚本。

Compromised CDN

例如我们的web需要从某个外部资源装载一个framework，攻击者可能拦截这个请求，并把它重定向到自己的攻击脚本上，如下图

使用Content-Security-Policy中script-src这个属性可以指定信任的脚本来源，并且在引用资源的时候指定来源和校验签名，如下

在HTTP response中：

HTTP response：
:status:200
Content-Security-Policy:
 default-src 'self'; 
 script-src cdn.example;

在HTML中：

<script src="https://cdn.example/framework.js"
 integrity="sha256-8WqyJLuWKRB...oZkCnxQbWwJVw=">
</script>
window.framwork || // reload from own domain

3. Cross-Site Request Forgeries

攻击者可能在自己的web中嵌入我们的web，然后向我们的服务器发起一个伪造的网络请求（使用的是攻击者网站的cookie），如下图

如果采取了防御措施，将HTTP response的Header里面的SameSite设置为strict，那么就会禁止攻击者网站的cookie发动到我们的服务器上面，如下

HTTP response：
:status:200
Set-Cookie:
 auth=abc...123; SameSite=strict

2. Speculative execution attacks (Spectre)

防御措施有：

• WKWebView
• Content Security Policy
• HttpOnly cookies
• SameSite cookies
• Cross-Origin-Resource-Policy

Speculative execution 的定义：预测执行类似于批量执行条件判断语句，例如计算机大量执行"x是否会造成数组array越界"这条指令，就能推测出这个数组的长度，进一步推测出这个数组在内存缓冲区中的地址边界。利用缓冲区溢出这种攻击手段，可以向web中注入攻击脚本。当x超过数组边界的时候，本来应该执行越界的error回调，但是确取出了攻击脚本并执行，造成数据泄露。显然只靠同源策略是无法防御这种攻击的，因为攻击脚本和文档处在同一个域名下，并且在同一个线程中。

防御预测执行攻击的方法是确保web内容和其他iframe（例如攻击脚本）处在不同的线程中。

WKWebView

以Safari app为例，WKWebView会单独分离出一个NetWork线程用于处理添加cookie等逻辑，而且每个网页处在不同的线程当中，所以evil网页是无法通过预测执行攻击手段攻击我们的页面。而且因为NetWork线程也是独立的，所以evil网页也无法通过预测执行攻击手段拿到重要数据，例如cookie。

如果使用UIWebView，所有的web包括NetWork线程都在app的同一个线程中，所以是无法防御预测执行攻击手段的。

Content security policy

Content security policy的封锁功能是处于Network线程中，和web线程是分离的，因此可以防御预测执行攻击手段。

例如web要加载一个广告iframe，但是这个广告iframe被重定向到了一个攻击脚本，如果使用了Content security policy，如下，因为攻击脚本不在信任的frame-src里面，所以会禁止加载。还有一种情况，攻击者的web引入了我们的web，因为设置了frame-ancestors为none，所以会禁止攻击者网站引入我们的web，从而防御攻击。

HTTP response：
:status:200
Content-Security-Policy:
 default-src 'self'; 
 frame-src ad.example
 social.example
 frame-ancestors 'none'

HttpOnly cookies 和 SameSite cookies

HttpOnly cookies 和 SameSite cookies的封锁功能也是处于Network线程中，和web线程是分离的，因此可以防御预测执行攻击手段。HttpOnly cookies能够禁止攻击者通过脚本拿到cookie。SameSite cookies设为strict能够禁止cookie从一个域发送到另一个域。

Cross-Origin-Resource-Policy

Cross-Origin-Resource-Policy的封锁功能也是处于Network线程中，和web线程是分离的，因此可以防御预测执行攻击手段。Cross-Origin-Resource-Policy设置成Same能禁止攻击者的web加载我们网站的资源。

Window Control Attacks

Cross-Origin-Window-Policy

攻击者的页面可以通过window.open这个api在新的窗口打开我们的web，攻击者趁我们不注意的时候，把我们的页面导航到钓鱼页面，然后诱导用户填写用户名和密码，这样就窃取到了用户信息。把HTTP response Header里面的Cross-Origin-Window-Policy设置为Deny，能够禁止攻击者修改我们的web，这样攻击者就无法导航到钓鱼页面。

总结

每种安全措施防御的攻击类型

建议

• 使用安全的网络传输（例如https，wss）
• 设置Cookies为HttpOnly和其它安全选项
• 把UIWebView升级到WKWebView
• 测试防御措施是否生效，web是否仍然能正常工作。安全措施都具有一定的限制功能，因此测试web是否能正常工作非常重要。例如Content-Securityp-Policy的script-src白名单里少些了一个允许的域名，那么这个域名下的web就无法正常使用了。

App开发中，内嵌WebView始终占有着一席之地。它能以较低的成本实现Android、iOS和Web的复用，也可以冠冕堂皇的突破苹果对热更新的封锁。

然而便利性的同时，WebView的性能体验却备受质疑，导致很多客户端中需要动态更新等页面时不得不采用其他方案。

以发展的眼光来看，功能的动态加载以及三端的融合将会是大趋势。那么如何克服WebView固有的问题呢？我们将从性能、内存消耗、体验、安全几个维度，来系统的分析客户端默认WebView的问题，以及对应的优化方案。

性能

对于WebView的性能，给人最直观的莫过于：打开速度比native慢。

是的，当我们打开一个WebView页面，页面往往会慢吞吞的loading很久，若干秒后才出现你所需要看到的页面。

这是为什么呢？

对于一个普通用户来讲，打开一个WebView通常会经历以下几个阶段：

1. 交互无反馈

2. 到达新的页面，页面白屏

3. 页面基本框架出现，但是没有数据；页面处于loading状态

4. 出现所需的数据

如果从程序上观察，WebView启动过程大概分为以下几个阶段：

如何缩短这些过程的时间，就成了优化WebView性能的关键。

接下来我们逐一分析各个阶段的耗时情况，以及需要注意的优化点。

WebView初始化

当App首次打开时，默认是并不初始化浏览器内核的；只有当创建WebView实例的时候，才会创建WebView的基础框架。

所以与浏览器不同，App中打开WebView的第一步并不是建立连接，而是启动浏览器内核。

我们来分析一下这段耗时到底需要多久。

分析

针对WebView的初始化时间，我们可以定义两个指标：

• 首次初始化时间：客户端冷启动后，第一次打开WebView，从开始创建WebView到开始建立网络连接之间的时间。

• 二次初始化时间：在打开过WebView后，退出WebView，再重新打开WebView，从开始创建WebView到开始建立网络连接之间的时间。

测试数据：

测试系统1： iOS模拟器，Titans 10.0.7

测试系统2： OPPO R829T Android 4.2.2

测试方式：测试10次取平均值

测试App：美团外卖

单位：ms

*Android外卖客户端启动后会在后台开启WebView进程，故并不是完全新建WebView时间。

这意味着什么呢？

作为前端工程师，统计了无数次的页面打开时间，都是以网络连接开始作为起点的。

很遗憾的通知您：WebView中用户体验到的打开时间需要再增加70~700ms。

于是我们找到了“为什么WebView总是很慢”的原因之一：

• 在浏览器中，我们输入地址时（甚至在之前），浏览器就可以开始加载页面。

• 而在客户端中，客户端需要先花费时间初始化WebView完成后，才开始加载。

而这段时间，由于WebView还不存在，所有后续的过程是完全阻塞的。可以这样形容WebView初始化过程：

那么有哪些解决办法呢？

怎么优化

由于这段过程发生在native的代码中，单纯靠前端代码是无法优化的；大部分的方案都是前端和客户端协作完成，以下是几个业界采用过的方案。

全局WebView

方法：

• 在客户端刚启动时，就初始化一个全局的WebView待用，并隐藏；

• 当用户访问了WebView时，直接使用这个WebView加载对应网页，并展示。

这种方法可以比较有效的减少WebView在App中的首次打开时间。当用户访问页面时，不需要初始化WebView的时间。

当然这也带来了一些问题，包括：

• 额外的内存消耗。

• 页面间跳转需要清空上一个页面的痕迹，更容易内存泄露。

【参考东软专利 - 加载网页的方法及装置 CN106250434A】

客户端代理数据请求

方法：

• 在客户端初始化WebView的同时，直接由native开始网络请求数据；

• 当页面初始化完成后，向native获取其代理请求的数据。

此方法虽然不能减小WebView初始化时间，但数据请求和WebView初始化可以并行进行，总体的页面加载时间就缩短了；缩短总体的页面加载时间：

【参考腾讯分享：70%以上业务由H5开发，手机QQ Hybrid 的架构如何优化演进？】

还有其他各种优化的方式，不再一一列举，总结起来都是围绕两点：

1. 在使用前预先初始化好WebView，从而减小耗时。

2. 在初始化的同时，通过Native来完成一些网络请求等过程，使得WebView初始化不是完全的阻塞后续过程。

建立连接/服务器处理

在页面请求的数据返回之前，主要有以下过程耗费时间。

• DNS

• connection

• 服务器处理

分析

以下为美团中活动页面的链接时间统计：

统计： 美团的活动页面

内容值： n%分位值（ms）

优化

这些时间都是发生在网页加载之前，但这并不意味着无法优化，有以下几种方法。

DNS采用和客户端API相同的域名

DNS会在系统级别进行缓存，对于WebView的地址，如果使用的域名与native的API相同，则可以直接使用缓存的DNS而不用再发起请求图片。

以美团为例，美团的客户端请求域名主要位于api.meituan.com，然而内嵌的WebView主要位于 i.meituan.com。

当我们初次打开App时：

• 客户端首次打开都会请求api.meituan.com，其DNS将会被系统缓存。

• 然而当打开WebView的时候，由于请求了不同的域名，需要重新获取i.meituan.com的IP。

根据上面的统计，至少10%的用户打开WebView时耗费了60ms在DNS上面，如果WebView的域名与App的API域名统一，则可以让WebView的DNS时间全部达到1.3ms的量级。

静态资源同理，最好与客户端的资源域名保持一致。

同步渲染采用chunk编码

同步渲染时如果后端请求时间过长，可以考虑采用chunk编码，将数据放在最后，并优先将静态内容flush。对于传统的后端渲染页面，往往都是使用的【浏览器】--> 【Web API】 --> 【业务 API】的加载模式，其中后端时间就指的是Web API的处理时间了。在这里Web API一般有两个作用：

1. 确定静态资源的版本。

2. 根据用户的请求，去业务API获取数据。

而一般确定静态资源的版本往往是直接读取代码版本，基本无耗时；而主要的后端时间都花费在了业务API请求上面。

那么怎么优化利用这段时间呢？

在HTTP协议中，我们可以在header中设置 transfer-encoding:chunked 使得页面可以分块输出。如果合理设计页面，让head部分都是确定的静态资源版本相关内容，而body部分是业务数据相关内容，那么我们可以在用户请求的时候，首先将Web API可以确定的部分先输出给浏览器，然后等API完全获取后，再将API数据传输给浏览器。

下图可以直观的看出分chunk输出和一起输出的区别：

• 如果采用普通方式输出页面，则页面会在服务器请求完所有API并处理完成后开始传输。浏览器要在后端所有API都加载完成后才能开始解析。

• 如果采用chunk-encoding: chunked，并优先将页面的静态部分输出；然后处理API请求，并最终返回页面，可以让后端的API请求和前端的资源加载同时进行。

• 两者的总共后端时间并没有区别，但是可以提升首字节速度，从而让前端加载资源和后端加载API不互相阻塞。

页面框架渲染

页面在解析到足够多的节点，且所有CSS都加载完成后进行首屏渲染。在此之前，页面保持白屏；在页面完全下载并解析完成之前，页面处于不完整展示状态。

分析

我们以一个美团的活动页面作为样例：

测试页面：http://i.meituan.com/firework/meituanxianshifengqiang

在Mac上面，模拟4G情况

页面样式：

测试得到的时间耗费如下：

表1

同时，对HTML的加载时间进行分析，可以得到如下时间点。

表2

这意味着什么呢？

对于表1

可以看到，随着在网络优良的情况下，Dom的解析所占耗时比例还是不算低的，对于低端机器更甚。Layout时间也是首屏前耗时的大头，据猜测这与页面使用了rem作为单位有关（待进一步分析）。

对于表2，我们可以发现一个问题

一般来说HTML在开始接收到返回数据的时候就开始解析HTML并构建DOM树。如果没有JS（JavaScript）阻塞的话一般会相继完成。然而，在这里时间相差了90ms……也就是说，解析被阻塞了。

进一步分析可以发现，页面的header部分有这样的代码：

.....

通常情况下，上面代码的link部分和script部分如果单独出现，都不会阻塞页面的解析：

• CSS不会阻止页面继续向下继续。

• 内联的JS很快执行完成，然后继续解析文档。

然而，当这两部分同时出现的时候，问题就来了。

• CSS加载阻塞了下面的一段内联JS的执行，而被阻塞的内联JS则阻塞了HTML的解析。

通常情况下，CSS不会阻塞HTML的解析，但如果CSS后面有JS，则会阻塞JS的执行直到CSS加载完成（即便JS是内联的脚本），从而间接阻塞HTML的解析。

优化

在页面框架加载这一部分，能够优化的点参照雅虎14条就够了；但注意不要犯错，一个小小的内联JS放错位置也会让性能下降很多。

1. CSS的加载会在HTML解析到CSS的标签时开始，所以CSS的标签要尽量靠前。

2. 但是，CSS链接下面不能有任何的JS标签（包括很简单的内联JS），否则会阻塞HTML的解析。

3. 如果必须要在头部增加内联脚本，一定要放在CSS标签之前。

JS加载

对于大型的网站来说，在此我们先提出几个问题：

• 将全部JS代码打成一个包，造成首次执行代码过大怎么办？

• 将JS以细粒度打包，造成请求过多怎么办？

• 将JS按 "基础库" + "页面代码" 分别打包，要怎么界定什么是基础代码，什么是页面代码；不同页面用的基础代码不一致怎么办？

• 单一文件的少量代码改的是否会导致缓存失效？

• 代码模块间有动态依赖，怎样合并请求。

关于这些问题的解决方案数量可能会比问题还多，而它们也各有优劣。

具体分析太过复杂，鉴于篇幅原因在这里不做具体分析了。您可以期待我们的后续计划：BPM（浏览器包管理）。

JS解析、编译、执行

在PC互联网时代，人们似乎都快忘记了JS的解析和执行还需要消耗时间。确实，在几年前网速还在用kb衡量的时代里，JS的解析时间在整个页面的打开时间里只能算是九牛一毛。

然而，随着网速越来越快，而CPU的速度反而没有提升（从PC到手机），JS的时间开销就成为问题了。那么JS的编译和解析，在当今的页面上要消耗多少时间呢？

分析

我们用以下方式来检验JS代码的解析/编译和执行时间：

<script>

将测试代码放入 【test code】 位置，然后在手机中执行；

• 在t1~t2期间，JS代码仅仅声明了一个函数，主要时间会集中在解析和编译过程；

• 在t2~t3时间段内，执行test时时间主要为代码的执行时间

在首次启动客户端后，打开WebView的测试页面，我们可以得到如下的结果：

测试系统： iPhone6 iOS 10.2.1

测试系统： OPPO R829T Android 4.2.2

内容值： 编译时间（ms）/执行时间（ms）

当保持客户端进行不关闭情况下，关闭WebView并重新访问测试页面，再次测试得到如下结果：

执行时间指的是框架代码加载的页面的初始化时间，没有任何业务的调用。

这意味着什么

经过测试可以得出以下结论：

• 偏重的框架，例如React，仅仅初始化的时间就会达到50ms ~ 350ms，这在对性能敏感的业务中时比较不利的。

• 在App的启动周期内，统一域名下的代码会被缓存编辑和初始化结果，重复调用性能较好。

所以，在移动浏览器上，JS的解析和执行时间并不是不可忽略的。

在低端安卓机上，（框架的初始化+异步数据请求+业务代码执行）会远高于几KB网络请求时间；高性能的Web网站需要仔细斟酌前端渲染带来的性能问题。

优化

• 高性能要求页面还是需要后端渲染。

• React还是太重了，面向用户写系统需要谨慎考虑。

• JS代码的编译和执行会有缓存，同App中网页尽量统一框架。

WebView性能优化总结

一个加载网页的过程中，native、网络、后端处理、CPU都会参与，各自都有必要的工作和依赖关系；让他们相互并行处理而不是相互阻塞才可以让网页加载更快：

• WebView初始化慢，可以在初始化同时先请求数据，让后端和网络不要闲着。

• 后端处理慢，可以让服务器分trunk输出，在后端计算的同时前端也加载网络静态资源。

• 脚本执行慢，就让脚本在最后运行，不阻塞页面解析。

• 同时，合理的预加载、预缓存可以让加载速度的瓶颈更小。

• WebView初始化慢，就随时初始化好一个WebView待用。

• DNS和链接慢，想办法复用客户端使用的域名和链接。

• 脚本执行慢，可以把框架代码拆分出来，在请求页面之前就执行好。

WebView内存消耗

分析

为了测试WebView会消耗多少内存，我们设计了如下的测试方案：

1. 客户端启动后，记录消耗的内存。

2. 打开空页面，记录内存的上涨。

3. 退出。

4. 打开空页面，记录内存上涨。

5. 退出。

6. 打开加载了代码的页面，记录内存的额外增加。

得到如下测试结果：

测试系统： iOS模拟器，Titans 10.0.7

测试系统： OPPO R829T Android 4.2.2

测试方式：测试10次取平均值

WKWebView的内存消耗相比其他低了一个数量级，在此方面相当占优。

UIWebView和Android的WebView在首次初始化时都要消耗大量内存，之后每次新建WebView会额外增加一些。

UIWebView的内存占用不会在关闭WebView时主动回收，每次新开WebView都会消耗额外内存。

相比于性能，对于内存的优化可以做的还是比较有限的。

• WKWebView的内存占用优势比较大（代价是初始化比较慢）。

• 页面内代码消耗的内存相比与WebView系统的内存消耗相比可以说是很低。

WebView体验

除了打开的速度，WebView通常体验也没有native的实现更好，我们可以找到以下几个例子：

长按选择

在WebView中，长按文字会使得WebView默认开始选择文字；长按链接会弹出提示是否在新页面打开。

解决方法：可以通过给body增加CSS来禁止这些默认规则。

点击延迟

在WebView中，click通常会有大约300ms的延迟（同时包括链接的点击，表单的提交，控件的交互等任何用户点击行为）。

唯一的例外是设置的meta：viewpoint为禁止缩放的Chrome（然而并不是Android默认的浏览器）。

解决方法：使用fastclick一般可以解决这个问题。

页面滑动期间不渲染/执行

在很多需求中会有一些吸顶的元素，例如导航条，购买按钮等；当页面滚动超出元素高度后，元素吸附在屏幕顶部。

这个功能在PC和native中都能够实现，然而在WebView中却成了难题：

在页面滚动期间，Scroll Event不触发

不仅如此，WebView在滚动期间还有各种限定：

• setTimeout和setInterval不触发。

• GIF动画不播放。

• 很多回调会延迟到页面停止滚动之后。

• background-position: fixed不支持。

• 这些限制让WebView在滚动期间很难有较好的体验。

这些限制大部分是不可突破的，但至少对于吸顶功能还是可以做一些支持：

解决方法：

• 在iOS上，使用position: sticky可以做到元素吸顶。

• 在Android上，监听touchmove事件可以在滑动期间做元素的position切换（惯性运动期间就无效了）。

键盘形态有限

WebView对键盘的控制能力很弱，无法直接调起或者隐藏键盘，而且键盘的确认文案是无法自定义的。

我们以百度为例：

当你打开百度搜索时，点击【换行】就完成了输入并开始了搜索。

为什么是【换行】而不是【搜索】呢？

当然不是bug……而是……臣妾做不到啊！

解决方法：

目前只能通过由与App通过桥协议的方式，由App代为唤起键盘（但是实际操作过于复杂）。

crash

通常WebView并不能直接接触到底层的API，因此比较稳定；但仍然有使用不当造成整个App崩溃的情况。

目前发现的案例包括：

• 使用过大的图片（2M）

• 不正常使用WebGL

WebView安全

WebView被运营商劫持、注入问题

由于WebView加载的页面代码是从服务器动态获取的，这些代码将会很容易被中间环节所窃取或者修改，其中最主要的问题出自地方运营商（浙江尤其明显）和一些WiFi。

我们监测到的问题包括：

• 无视通信规则强制缓存页面。

• header被篡改。

• 页面被注入广告。

• 页面被重定向。

• 页面被重定向并重新iframe到新页面，框架嵌入广告。

• HTTPS请求被拦截。

• DNS劫持。

这些问题轻则影响用户体验，重则泄露数据，或影响公司信誉。

针对页面注入的行为，有一些解决方案：

使用CSP（Content Security Policy）

CSP可以有效的拦截页面中的非白名单资源，而且兼容性较好。在美团移动版的使用中，能够阻止大部分的页面内容注入。

但在使用中还是存在以下问题：

• 由于业务的需要，通常inline脚本还是在白名单中，会导致完全依赖内联的页面代码注入可以通过检测。

• 如果注入的内容是纯HTML+CSS的内容，则CSP无能为力。

• 无法解决页面被劫持的问题。

• 会带来额外的一些维护成本。

总体来说CSP是一个行之有效的防注入方案，但是如果对于安全要求更高的网站，这些还不够。

HTTPS

HTTPS可以防止页面被劫持或者注入，然而其副作用也是明显的，网络传输的性能和成功率都会下降，而且HTTPS的页面会要求页面内所有引用的资源也是HTTPS的，对于大型网站其迁移成本并不算低。

HTTPS的一个问题在于：一旦底层想要篡改或者劫持，会导致整个链接失效，页面无法展示。这会带来一个问题：本来页面只是会被注入广告，而且广告会被CSP拦截，而采用了HTTPS后，整个网页由于受到劫持完全无法展示。

对于安全要求不高的静态页面，就需要权衡HTTPS带来的利与弊了。

App使用Socket代理请求

如果HTTP请求容易被拦截，那么让App将其转换为一个Socket请求，并代理WebView的访问也是一个办法。

通常不法运营商或者WiFi都只能拦截HTTP（S）请求，对于自定义的包内容则无法拦截，因此可以基本解决注入和劫持的问题。

Socket代理请求也存在问题。

• 首先，使用客户端代理的页面HTML请求将丧失边下载边解析的能力；根据前面所述，浏览器在HTML收到部分内容后就立刻开始解析，并加载解析出来的外链、图片等，执行内联的脚本……而目前WebView对外并没有暴露这种流式的HTML接口，只能由客户端完全下载好HTML后，注入到WebView中。因此其性能将会受到影响。

• 其次，其技术问题也是较多的，例如对跳转的处理，对缓存的处理，对CDN的处理等等……稍不留神就会埋下若干大坑。

此外还有一些其他的办法，例如页面的MD5检测，页面静态页打包下载等等方式，具体如何选择还要根据具体的场景抉择。

客户端内打开第三方WebView

一般来说，客户端内的WebView都是可以通过客户端的某个schema打开的，而要打开页面的URL很多都并不写在客户端内，而是可以由URL中的参数传递过去的。

那么，一旦此URL可以通过外界输入自定义，那么就有可能在客户端内部打开一个外部的网页。

例：作案过程

• 某个App有个WebView，打开的schema为 appxx://web?url={weburl}。

• App中有个扫码的功能，可以扫描某个二维码并打开对应的schema链接。

• 某个坏人制作了一个二维码并张贴到街上，内容符合 ： appxx://web?url={some_hack_weburl}。

• 用户扫码打开了some_hack_weburl。

• 如果some_hack_weburl是一个高仿的登录页面，那么用户将会很可能将用户名密码提交到其他网站。

解决方法：在内嵌的WebView中应该限制允许打开的WebView的域名，并设置运行访问的白名单。或者当用户打开外部链接前给用户强烈而明显的提示。

发展

在一个客户端内，native目前主要功能是提供高效而基础的功能；内部的WebView则添加一些性能体验要求不高但动态化要求高的能力。

提高客户端的动态能力，或者提高WebView的性能，都是提升App功能覆盖的方式。

而目前的各种框架，ReactNative、Week包括微信小程序，都是这个趋势的尝试。

随着技术的发展，WebView的性能、体验和安全问题也将会逐渐的改善，在App中占有越来越多比重的同时，也将会为App开拓新的能力，为用户带来更优质的体验。