手机app开发可选技术——webview

选型标准

·写代码的难易度
·编译的难易度
·上架和推广的难易度
·小程序和原生应用的不同等方面

技术方案

WebView

入门知识

我们通常是使用浏览器浏览网页，你很清楚的知道你正在使用浏览器，要么是PC客户端，要么是手机上的app。但是webview是一个嵌入式的浏览器，是嵌入在原生应用中的，你可能都意识不到你在使用浏览器。
传统浏览器分为两个部分，UI（地址栏、导航栏）和浏览器搜索引擎。webview就是原生应用中的浏览器引擎。
webview只是一个可视化的组件，是作为原生app的视觉部分。
用webview展示的内容是不需要存储在本地的，可以直接从服务器获取。
这种灵活性打开了浏览器端的web应用和希望展示在原生应用中的web应用代码直接可以重用的世界。
运行在webview中的JS代码有能力调用原生系统的API，没有传统浏览器沙箱的限制。
沙箱的存在是因为，你永远不能完全信任加载的web内容，所以不能允许它调用原生的系统API。而在webview中开发人员通常可以完全控制加载的内容，恶意代码进入并在设备上造成混乱的可能性很低。
在webview中，js代码可以跟原生应用代码相互通信，也可以调用原生API集成酷炫的系统级功能，如传感器、存储、日历、联系人等。
用法
作为app内置浏览器，显示链接的内容
用来显示广告
完全承载app内的所有交互。从技术角度看这些仍是原生应用，但它做的唯一原生操作就是托管webview，这种应用被称为混合应用。从部署和更新的角度来看，混合应用非常方便。
作为原生应用的扩展。许多原生应用会提供加载项和扩展程序来扩展其功能，由于web技术的简单性和强大，这些加载项和扩展通常以HTML、CSS、JS而不是C++,C#或其他来构建。
webview的精髓
webview其实只是一个在应用中设置好位置和大小的浏览器，而且不会放置任何花哨的UP。
在大多数情况下，除非你调用了原生API，否则不必在webview中专门测试web应用。

进阶知识
webview是我们前端开发从PC端演进到移动端的一个重要载体，现在大家每天使用的App，webview都发挥着它的重要性。

适用场景
提到应用场景，大家最直观的能想到一些APP内嵌的页面，为我们提供各种各样的交互。
其实webview的应用场景远远不止这些，其实在一些pc的软件里，和我们交互的也是我们的html页面，只是穿着webview的衣服。
另外，还有一些网络机顶盒里的交互，也是webview在和我们打交道，比如一些早期的IPTV里的EPG都是运行在webview里的，他们基于webkit内核，尽管我们使用的交互方式是遥控器。
与app native的交互
其实目前使用频率最多的，还是客户端内嵌的webview，小到我们地铁里用手机看的一篇公众号文章，大到我们使用app中的一些重要交互流程，其实都是webview打开m页去承接的。那么，到底m页怎么和native去交互呢？
目前javascript和客户端（native）交互的常见方式有两种，一种是通过JSBridge的方式，另一种是通过schema的方式。
1.JSBridge
当我们在native内打开m页，native会在全局的windows下，为我们注入一个bridge。这个bridge里面，会包含我们与native交互的各种方法，比如判断第三方app是否安装，获取网络信息等功能。
（ios和android端不同）
2.schema url
如果说bridge的方式是只能在native内部交互，那么schema url不仅可以在native内交互，也是可以跨app来交互的。schema也是目前我们转转使用的主要方式，它类似于一个伪协议的链接（也可以叫做统跳协议）
在webview里，当m页发起schema请求时，native端会去进行捕获。
（ios和Android不同）
通过schema的方式可以进行跨端交互。
在native中，会通过schema找到相匹配的app。其中ios不可以重复，安卓可以重复，遇到重复情况时，会弹窗让用户选择其中之一。