不论是在创业团队中快速试错，还是在成熟团队中快速迭代复杂需求，还或者是其他原因，WebView在APP中的大量使用已经成为了一个明显的趋势，这也应该算是大前端融合的一个表象吧。笔者在工作中也遇到过很多App&Js交互的问题，粗浅的研究了一下，这里也分享给大家，如果有错误的地方还请下方留言指出，共同进步。
众所周知，iOS有 UIWebView 、 WKWebView 两个组件可以用来渲染嵌入页面。前者使用甚广，出生的也早，后者是iOS8推出的，优化了加载速度和内存，安全性上也有所提升。具体的两者比较百度、上都很多，这里不做赘述。
前两种方法到此就介绍完了，很简单，但是在项目大了之后拦截跳转的代理方法中会有非常多的判断。冗余、可维护性差，硬编码重。所以我们会有下面的其他方法。
JSContext即JavaScriptContext，这个东西在UIWebView中可以拿到，但是在WKWebView中却是取不到了，所以只能用在UIWebView中。除此以外Android里也有类似的一个东西，所以使用JSContext就有了在JS端多平台统一的可能，这里不多说，在《App与Js交互（三）》中会有详细说明。
JSContext的原理就是iOS暴露出去一个遵守 <JSExport>协议的对象给JS，JS可以直接调用该对象的public方法。
window.webkit.messagehandlers.<name>.postMessage 是apple推荐使用的WKWebView的JS交互方式，使用起来比较简单，不支持callback回调。
参考如下内容：主要有两种方法。一种是使用系统的浏览器组件（IOS中的UIWebView和Android中的WebView），另一方法就是使用整合好的JavaScript引擎。
使用系统的浏览器组件比较容易实现但是更复杂，效率也低。 WebView提供了 addJavascriptInterface 把Java classes注入到JavaScript文本的方法。但是它只支持最原始的几种数据类型，因此也局限了API设计。并且在Android 2.3模拟器上不稳定，在真机上也会遇到 issue #12987的问题。在IOS上更糟 UIWebView没有公共的APIs支持JavaScript到Objective-C的交互(你必须使用似有的APIs才能达到与addJavascriptInterface相同的功能)。
PhoneGap 是基于 UIWebView and WebView的比较出名的项目。开发者被迫使用回调函数从JavaScript APIs得到返回值。这在游戏上效率极低，也更为复杂。
早期的ngCore同样依赖UIWebView来支持iOS。但是这个机制由于其糟糕的表现被取代。
为了获得更好的表现、灵活性、兼容性，嵌入全功能的JavaScript引擎变得更为有效。
