前言
我们大前端团队内部 ?每周一练 的知识复习计划继续加油,本篇文章是 《Hybrid APP 混合应用专题》 主题的第二期和第三期的合集。
这一期共整理了 10 个问题,和相应的参考答案,文字和图片较多,建议大家可以收藏,根据文章目录来阅读。
之前分享的每周内容,我都整理到掘金收藏集 [?《EFT每周一练》] (https://juejin.im/collection/5cd11b0af265da0346227e24) 上啦,欢迎点赞收藏咯??。
文章收录:
本系列所有文章,都将收录在 Github 上,[欢迎点击查阅] (https://github.com/pingan8787/Leo-EveryWeek)。
注:本文整理部分资料来源网络,有些图片/段落找不到原文出处,如有侵权,联系删除。
参考文章:[《UIWebView与WKWebView》] (http://www.cocoachina.com/articles/17337)
UIWebView 是苹果继承于 UIView 封装的一个加载 web 内容的类,它可以加载任何远端的web数据展示在你的页面上,你可以像浏览器一样前进后退刷新等操作。不过苹果在 iOS8 以后推出了 WKWebView 来加载 Web,并应用于 iOS 和 OSX 中,它取代了 UIWebView 和 WebView ,在两个平台上支持同一套 API。
它脱离于 UIWebView 的设计,将原本的设计拆分成14个类,和3个代理协议,虽然是这样但是了解之后其实用法比较简单,依照职责单一的原则,每个协议做的事情根据功能分类。

WKWebView 与 UIWebView 的区别:
WKWebView 的内存远远没有 UIWebView 的开销大,而且没有缓存;
WKWebView 拥有高达 60FPS 滚动刷新率及内置手势;WKWebView 支持了更多的 HTML5 特性;WKWebView 高效的 app 和 web 信息交换通道;WKWebView 允许 JavaScript 的 Nitro 库加载并使用, UIWebView 中限制了;WKWebView 目前缺少关于页码相关的 API;WKWebView 提供加载网页进度的属性;WKWebView 使用 Safari 相同的 JavaScript 引擎;WKWebView 增加加载进度属性: estimatedProgress ;WKWebView 不支持页面缓存,需要自己注入 cookie , 而 UIWebView 是自动注入 cookie ;WKWebView 无法发送 POST 参数问题;WKWebView 可以和js直接互调函数,不像 UIWebView 需要第三方库 WebViewJavascriptBridge 来协助处理和 js 的交互; 注意:
大多数App需要支持 iOS7 以上的版本,而 WKWebView 只在 iOS8 后才能用,所以需要一个兼容性方案,既 iOS7 下用 UIWebView , iOS8 后用 WKWebView 。但是目前 IOS10 以下的系统以及很少了,
小结:
WKWebView 相较于 UIWebView 在整体上有较大的提升,满足 iOS 上面使用同一套控件的功能,同时对整个内存的开销以及滚动刷新率和 JS 交互做了优化的处理。
依据职责单一原则,拆分成了三个协议去实现 WebView 的响应,解耦了 JS 交互和加载进度的响应处理。
WKWebView 没有做缓存处理,所以对网页需要缓存的加载性能要求没那么高的还是可以考虑 UIWebView 。
参考文章:[《WKWebView 那些坑》] (https://kknews.cc/tech/x2rzg3g.html)
WKWebView 实际上是个多进程组件,这也是它加载速度更快,内存暂用更低的原因。
在 UIWebView 上当内存占用太大的时候,App Process 会 crash;而在 WKWebView 上当总体的内存占用比较大的时候,WebContent Process 会 crash,从而出现白屏现象。
解决办法:
当 WKWebView 总体内存占用过大,页面即将白屏的时候,系统会调用上面的回调函数,我们在该函数里执行 [webView reload](这个时候 webView.URL 取值尚不为 nil)解决白屏问题。在一些高内存消耗的页面可能会频繁刷新当前页面,H5侧也要做相应的适配操作。
并不是所有 H5 页面白屏的时候都会调用上面的回调函数,比如,最近遇到在一个高内存消耗的 H5 页面上 present 系统相机,拍照完毕后返回原来页面的时候出现白屏现象(拍照过程消耗了大量内存,导致内存紧张,WebContent Process 被系统挂起),但上面的回调函数并没有被调用。在 WKWebView 白屏的时候,另一种现象是 webView.titile 会被置空, 因此,可以在 viewWillAppear的时候检测 webView.title 是否为空来 reload 页面。
WKWebView Cookie 问题在于 WKWebView 发起的请求不会自动带上存储于 NSHTTPCookieStorage 容器中的 Cookie,而在 UIWebView 会自动带上 Cookie。
原因是:
WKWebView 拥有自己的私有存储,不会将 Cookie 存入到标准的 Cookie 容器 NSHTTPCookieStorage 中。
实践发现 WKWebView 实例其实也会将 Cookie 存储于 NSHTTPCookieStorage 中,但存储时机有延迟,在 iOS8上,当页面跳转的时候,当前页面的 Cookie 会写入 NSHTTPCookieStorage 中,而在 iOS10 上,JS 执行 document.cookie 或服务器 set-cookie 注入的 Cookie 会很快同步到 NSHTTPCookieStorage 中,FireFox 工程师曾建议通过 resetWKProcessPool 来触发 Cookie 同步到 NSHTTPCookieStorage 中,实践发现不起作用,并可能会引发当前页面 session cookie丢失等问题。
解决办法1:
WKWebViewloadRequest 前,在 request header 中设置 Cookie, 解决首个请求 Cookie 带不上的问题;
解决办法2:
通过 document.cookie 设置 Cookie 解决后续页面(同域) Ajax``、iframe 请求的 Cookie 问题;(注意: document.cookie() 无法跨域设置 cookie)。
在 WKWebView 上通过 loadRequest 发起的 post 请求 body 数据会丢失,同样是由于进程间通信性能问题, HTTPBody 字段被丢弃。
WKWebView 在独立于 app 进程之外的进程中执行网络请求,请求数据不经过主进程,因此,在 WKWebView 上直接使用 NSURLProtocol 无法拦截请求。
解决办法:
由于 WKWebView 在独立进程里执行网络请求。一旦注册 http(s)scheme 后,网络请求将从 NetworkProcess 发送到 AppProcess,这样 NSURLProtocol 才能拦截网络请求。在 webkit2 的设计里使用 MessageQueue 进行进程之间的通信,Network Process 会将请求 encode 成一个 Message,然后通过 IPC 发送给 AppProcess。出于性能的原因, encode 的时候 HTTPBody 和 HTTPBodyStream 这两个字段会被丢弃掉了。
在 WKWebView 适配过程中,我们发现部分 H5 页面元素位置向下偏移或被拉伸变形,追踪后发现主要是 H5 页面高度值异常导致。
解决办法:
调整 WKWebView 布局方式,避免调整 webView.scrollView.contentInset 。实际上,即便在UIWebView 上也不建议直接调整 webView.scrollView.contentInset 的值,这确实会带来一些奇怪的问题。如果某些特殊情况下非得调整 contentInset 不可的话,可以通过下面方式让H5页面恢复正常显示。
WKWebView 下通过 -[CALayer renderInContext:]实现截屏的方式失效,需要通过以下方式实现截屏功能:
@implementation UIView (ImageSnapshot)- (UIImage*)imageSnapshot { UIGraphicsBeginImageContextWithOptions(self.bounds.size,YES,self.contentScaleFactor); [self drawViewHierarchyInRect:self.bounds afterScreenUpdates:YES]; UIImage* newImage = UIGraphicsGetImageFromCurrentImageContext(); UIGraphicsEndImageContext(); return newImage;}@end
然而这种方式依然解决不了 webGL 页面的截屏问题,截屏结果不是空白就是纯黑图片。
解决办法:
无奈之下,我们只能约定一个JS接口,让游戏开发商实现该接口,具体是通过 canvas getImageData()方法取得图片数据后返回 base64 格式的数据,客户端在需要截图的时候,调用这个JS接口获取 base64String并转换成 UIImage。
如果 WKWebView 退出的时候,JS刚好执行了 window.alert(), alert 框可能弹不出来, completionHandler 最后没有被执行,导致 crash;
另一种情况是在 WKWebView 一打开,JS就执行 window.alert(),这个时候由于 WKWebView 所在的 UIViewController 出现( push 或 present )的动画尚未结束,alert 框可能弹不出来, completionHandler最后没有被执行,导致 crash。
WKWebView 需要通过 WKWebViewConfiguration.mediaPlaybackRequiresUserAction 设置是否允许自动播放,但一定要在 WKWebView 初始化之前设置,在 WKWebView 初始化之后设置无效。
WKWebView 上调用 -[WKWebViewgoBack], 回退到上一个页面后不会触发 window.onload() 函数、不会执行JS。
WKWebView 需要通过 scrollViewdelegate 调整滚动速率:
- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView { scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;}
参考网站:[《Crosswalk Github》] (https://Crosswalk-project.org/) 参考文章:[《Crosswalk入门》] (https://www.mobibrw.com/2015/1934)
Crosswalk 是一款开源的 web 引擎。目前 Crosswalk 正式支持的移动操作系统包括 Android 和 Tizen ,在 Android 4.0 及以上的系统中使用 Crosswalk 的 Web 应用程序在 HTML5 方面可以有一致的体验,同时和系统的整合交互方面(比如启动画面、权限管理、应用切换、社交分享等等)可以做到类似原生应用。
现在 Crosswalk 已经成为众多知名 HTML5 平台和应用的推荐引擎,包括 Google Mobile Chrome App 、 Intel XDK 、 Famo.us 和 Construct2 等等,未来的 Cordova 4.0 也计划集成 Crosswalk 。
首先需要了解,对于一个普通用户来讲,打开一个 WebView 通常会经历哪几个阶段,一般有这些:

当 App 首次打开时,默认是并不初始化浏览器内核的;只有当创建 WebView 实例的时候,才会创建 WebView 的基础框架。
所以与浏览器不同,App 中打开 WebView 的第一步并不是建立连接,而是启动浏览器内核。
于是我们找到了“为什么WebView总是很慢”的原因之一:
WebView 完成后,才开始加载。而这段时间,由于WebView还不存在,所有后续的过程是完全阻塞的。因此由于这段过程发生在 native 的代码中,单纯靠前端代码是无法优化的;大部分的方案都是前端和客户端协作完成,以下是几个业界采用过的方案:
在客户端刚启动时,就初始化一个全局的 WebView 待用,并隐藏,当用户访问了 WebView 时,直接使用这个 WebView 加载对应网页,并展示。
这种方法可以比较有效的减少 WebView 在App中的首次打开时间。当用户访问页面时,不需要初始化 WebView 的时间。
当然这也带来了一些问题,包括:
参考文章:[《WebView常用优化方案》] (https://www.jianshu.com/p/f64e1b1c90d9)
WebView 动态加载。就是不在 xml 中写 WebView ,写一个 layout ,然后把 WebView add 进去。
WebView mWebView = new WebView(getApplicationgContext());LinearLayout mll = findViewById(R.id.xxx);mll.addView(mWebView);
protected void onDestroy() { super.onDestroy(); mWebView.removeAllViews(); mWebView.destroy()}
这里用的 getApplicationContext() 也是防止内存溢出,这种方法有一个问题。如果你需要在 WebView 中打开链接或者你打开的页面带有 flash,获得你的 WebView 想弹出一个 dialog ,都会导致从 ApplicationContext 到 ActivityContext 的强制类型转换错误,从而导致你应用崩溃。
这是因为在加载 flash 的时候,系统会首先把你的 WebView 作为父控件,然后在该控件上绘制 flash ,他想找一个 Activity 的 Context 来绘制他,但是你传入的是 ApplicationContext 。然后就崩溃了。
参考文章:[《WebView常用优化方案》] (https://www.jianshu.com/p/f64e1b1c90d9)
这个方法被运用于类似 qq ,微信这样的超级 app 中,这也是解决任何 WebView 内存问题屡试不爽的方法 对于封装的 webactivity ,在 manifest.xml 中设置。
<activity android:name=".webview.WebViewActivity" android:launchMode="singleTop" android:process=":remote" android:screenOrientation="unspecified" />
然后在关闭 webactivity 时销毁进程:
@Overrideprotected void onDestroy() {super.onDestroy(); System.exit(0);}
关闭浏览器后便销毁整个进程,这样一般 95% 的情况下不会造成内存泄漏之类的问题,但这就涉及到 android 进程间通讯,比较不方便处理,优劣参半,也是可选的一个方案。
参考文章:[《WebView常用优化方案》] (https://www.jianshu.com/p/f64e1b1c90d9)
public void destroy() { if (mWebView != null) { // 如果先调用destroy()方法,则会命中if (isDestroyed()) return;这一行代码,需要先onDetachedFromWindow(),再 // destory() ViewParent parent = mWebView.getParent(); if (parent != null) { ((ViewGroup) parent).removeView(mWebView); }
mWebView.stopLoading(); // 退出时调用此方法,移除绑定的服务,否则某些特定系统会报错 mWebView.getSettings().setJavaScriptEnabled(false); mWebView.clearHistory(); mWebView.clearView(); mWebView.removeAllViews();
try { mWebView.destroy(); } catch (Throwable ex) {
} }}
参考文章:[《Android调试webview》] (https://www.jianshu.com/p/3591eebbe797)
1.1 条件:
1.2 Android 代码中配置 WebView 为可调试:
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { WebView.setWebContentsDebuggingEnabled(true);}
注意 web 调测不受 app manifest 文件中 debuggable 标记状态的影响,如果希望仅 debuggable为 true 时才能使用 web 调测,那么运行时检测此标记,如下:
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { if ( 0 != ( getApplcationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE ) ) { WebView.setWebContentsDebuggingEnabled(true); }}
1.3 手机开启 USB 调试选项,并用 USB 连接电脑:
开启 Android 手机的开发者选项,一般在 系统设置 - Android版本 进行多次点击会触发开启开发者选项,然后进入开发者选项页面,开启USB调试。
为了避免每次调试时看到此警告,勾选“总是允许从这台计算机”,并单击“确定”。
1.4 在 Chrome 中启用设置“USB web debugging”(不会影响WebView):
在 Chrome 上访问 chrome://inspect/#devices 或 about:inspect 访问已启用调试的 WebView 列表,需要访问外国网站。
然后在 WebView 列表中选择你要调试的页面,点击“ Inspect ”选项,跟调试 PC 网页一样,使用 Chrome 控制台进行调试。


1.5 小技巧:
(1)访问 chrome://inspect/#devices 如果 chrome 没有检测到 RemoteTarget 中的页面,可能需要安装一下 Chrome 的 ADB 插件,也可以在 Chrome 访问外国网站访问 https://chrome-devtools-frontend.appspot.com;
(2)对于腾讯系的 APP,默认采用 X5内核 ,我们可以在 APP 内部打开 https://debugx5.qq.com/ 来使用它的Vconsole调试工具进行调试。
参考文章:[《Android下的webview调试》] (https://segmentfault.com/a/1190000009240637)
2.1 Windows 下载 DebugGap 并配置:
在电脑上面下载 Windows 版本的 DebugGap 软件包(下载链接:DebugGap),下载完成后解压下来。
安装完成后,运行 DebugGap ,开始配置:
DebugGap 可以自动获取IP,并设置默认的端口,如果没有,你可以手动设置;
2.2 在客户端上配置:
在调试项目中要进行测试的 HTML 界面中引入 debuggap.js。
<script src="debuggap.js" type="text/javascript"></script>
当调试项目的加载时,您的应用程序将会有一个蓝色的地方,点击会出现一个四叶三叶草的东西,点击“配置”,显示配置页面。输入与远程 DebugGap 上的主机和端口相同的主机和端口,例如 192.168.1.4:11111,然后点击“连接”按钮。

1.4电脑端远程 DebugGap 将检测即将到来的客户端,开发人员可以单击每个客户端进行调试。

参考文章:[《iOS之Safari调试webView/H5页面》] (https://www.cnblogs.com/dianming/p/6902442.html)
一般我们通过 Mac 的 Safari浏览器 来调试,但是要注意两点:
下面开始说说在 Mac 上如何调试:
先将 iPhone 连接到 Mac,在 Mac 的 Safari 偏好设置中,开启开发菜单。具体步骤为:Safari -> 偏好设置… -> 高级 -> 勾选在菜单栏显示“开发”菜单。

具体步骤为:设置 -> Safari -> 高级 -> Web 检查器。

参考文章:[《前端 WEBVIEW 指南之 IOS 调试篇》] (https://imnerd.org/ios-webview-debug.html)
在 Safari-> 开发中,看到自己的设备以及 WebView 中网页,点击后即可开启对应页面的 Inspector,可以用来进行断点调试。


这两者都是强大的抓包工具,原理是以web代理服务器的形式进行工作的,使用的代理地址是: 127.0.0.1,端口默认为 8888,我们也可以通过设置进行修改。
代理就是在客户端和服务器之间设置一道关卡,客户端先将请求数据发送出去后,代理服务器会将数据包进行拦截,代理服务器再冒充客户端发送数据到服务器;同理,服务器将响应数据返回,代理服务器也会将数据拦截,再返回给客户端。
Fiddler 或 Charles 的主要作用有:
补充链接:[《Fiddler工具使用介绍一》] (https://www.cnblogs.com/miantest/p/7289694.html)
参考文章:[《前端常见调试技巧篇总结(持续更新...)》] (https://www.cnblogs.com/chenbeibei520/p/9959555.html)
1.1 Source 面板断点调试 JS 从左到右,各个图标表示的功能分别为:
Pause/Resumescript execution:暂停/恢复脚本执行(程序执行到下一断点停止)。Stepovernextfunctioncall:执行到下一步的函数调用(跳到下一行)。Stepintonextfunctioncall:进入当前函数。Stepoutof currentfunction:跳出当前执行函数。Deactive/Activeall breakpoints:关闭/开启所有断点(不会取消)。Pauseon exceptions:异常情况自动断点设置。1.2 Element 面板调试 DOM:
右击元素,选择 breakon 选项:

Subtreemodifications 选项,是指当节点内部子节点变化时断点;Attributesmodifications 选项,是指当节点属性发生变化时断点;node removal 选项,是指当节点被移除时断点; 参考文章:[《Console调试常用用法》] (https://blog.csdn.net/a0405221/article/details/85248433)
2.1 显示信息的命令:
console.log("normal"); // 用于输出普通信息console.info("information"); // 用于输出提示性信息console.error("error"); // 用于输出错误信息console.warn("warn"); // 用于输出警示信息console.clear(); // 清空控制台信息
2.2 计时功能:
console.time() 和 console.timeEnd() :
console.time("控制台计时器");for(var i = 0; i < 10000; i++){ for(var j = 0; j < 10000; j++){}}console.timeEnd("控制台计时器")
2.3 信息分组:
console.group() 和 console.groupEnd():
console.group("第一组信息"); console.log("第一组第一条:我的博客"); console.log("第一组第二条:CSDN");console.groupEnd();
console.group("第二组信息"); console.log("第二组第一条:程序爱好者QQ群"); console.log("第二组第二条:欢迎你加入");console.groupEnd();
2.4 将对象以树状结构展现:
console.dir() 可以显示一个对象所有的属性和方法:
var info = { name : "Alan", age : "27", grilFriend : "nothing", getName : function(){ return this.name; }}console.dir(info);
2.5 显示某个节点的内容:
console.dirxml() 用来显示网页的某个节点( node) 所包含的 html/xml 代码:
var node = document.getElementById("info");node.innerHTML += "<p>追加的元素显示吗</p>";console.dirxml(node);
2.5 统计代码被执行的次数:
使用 console.count():
function myFunction(){ console.count("myFunction 被执行的次数");}myFunction(); //myFunction 被执行的次数: 1myFunction(); //myFunction 被执行的次数: 2myFunction(); //myFunction 被执行的次数: 3
2.6 输出表格:
console.table(mytable);
虽然把各种各样的手机都摆在桌子上看起来很酷,但却很不现实。但是,浏览器内却提供了你所需要的一切。进入检查面板点击“切换设备模式”按钮。这样,就可以在窗口内调整视窗的大小。
具体的说就是通过在代码中添加" debugger;"语句,当代码执行到该语句的时候就会自动断点。

对于初入混合应用开发的小伙伴,还有经常需要调试混合应用的小伙伴,相信会有帮助?
大家加油~
本文首发在 pingan8787个人博客,如需转载请保留个人介绍。你点的每个赞,我都认真当成了喜欢