原生app与h5交互（移动端 原生 还是 h5）

h5页面和app页面怎么通讯

通讯 *** 如下：

URL Scheme 是最常见的 *** 了，它的核心概念是拦截URL。

APP实现了一个webview，H5在其内打开。

它可以拦截到H5发生的跳转信息，如URL。如果以URL作为通信依据，就可以随意约定个URL，如：建立通信： 获取token：

H5就可以通过跳转到该地址被APP拦截，APP识别到了约定的URL触发对应 *** 。

2. 拦截打印日志

APP的webview有对应的监听，可以拦截到 *** 的 alert 等。就可通过输出 alert("标识", " *** 名", "参数") 等 *** 进行通信。IOS 由于安全限制，UIWebView 性能原因已弃用不考虑，WKWebView 对 alert 等 *** 做了拦截，需要做 *** 处理一下即可。Android 通过 WebView.addJavascriptInterface *** 实现。但因 Android 4.2 以前的系统中没有正确限制使用WebView.addJavascriptInterface，导致攻击者可以伪造 *** 桥接调用原生 *** ，存在安全漏洞，因此较少见。Google在Android 4.2 版本中修复了他，通过在Java *** 内的最上面声明一句@JavascriptInterface，从而避免漏洞攻击。若想 4.2 版本前使用就要另寻出路，window.prompt 一问一答的机制恰好可以满足，Android onJsPrompt *** 中去解析传递过来的文本，将处理结果返回给 *** 。

3. window注入

window注入就比较好理解了，就是双方在 *** 的window下写入通信变量。其实上面两种 *** 也多少会涉及window注入。它是一个对象，常用的有这几个 *** （想用什么自己写入）。

H5页面交互设计与原生APP的区别和解决方案

1.更小的页面空间（由于浏览器的导航本身占用一部分屏幕空间），更大的信息记忆负担。

2.交互动态效果收到限制，影响一些页面场景、逻辑的理解。

3.页面跳转更加费力，不稳定感更强。而且页面之间的跳转也不是很流畅，很多时候出现卡顿或卡死现象。

4.导航不明显，原有底部导航消失，有效的导航遇到挑战等。

针对以上困境，解决 *** 总结如下：

1.H5版上只做查询、浏览、显示结果等操作。

2.精简功能，只将核心的任务实现，非核心的枝节可考虑删减。

3.减少页面层级的数量和输入操作。

4.做好新的WebAPP（h5）交互导航.

5.补充从WebAPP（h5） 对 下载原生APP 的引导。

H5必知必会之与App交互

奇技指南

2018年11月26日发表的“360 AI音箱H5开发实践”一文中，曾简单提到“与Native交互”。本文将就此主题深入探讨H5与App交互的几种常见模式。

本文内容如下：

H5，在中国被专门用来指代开发内嵌于手机应用中的网页的技术，外国好像并没有这个说法。从技术上讲，H5是HTML5即Hyper Text Markup Language（超文本标记语言）第5版的简称。而HTML只是开发网页要用到的多种技术之一。除了HTML，还要用CSS设计界面，用JavaScript实现交互，甚至要用Node.js实现服务端逻辑。为什么H5会被用来笼统地指代这些技术呢？我猜一是因为它简单，二是移动端网页开发技术又恰好需要这么一个概念。

移动端网页运行在手机应用内嵌的浏览器引擎中，这个没有UI的内核容器统称WebView，即iPhone的UIWebView（iOS 2.0–12.0）、WKWebView（iOS 8.0+，macOS 10.10+）和Android的WebView。总之，WebView就是在手机应用中运行和展示网页的界面和接口（神奇的是，英文Interface，既可以翻译成“界面”也可以翻译成“接口”）。

H5与原生应用的交互都是通过原生应用中的WebView实现的。通过这个环境，H5可以调用原生应用注入其中的原生对象的 *** ，原生应用也可以调用H5暴露在这个环境中的JavaScript对象的 *** ，从而实现指令与数据的传输。

比如，在Android应用中，WebView类有一个公有 *** addJavascriptInterface，签名为：

调用这个 *** 可以向WebView中以指定的名称name注入指定的Java对象object。这样，WebView中的JavaScript就可以通过name调用object的 *** 。比如：

在iOS或macOS中，需要通过创建WKWebView类的实例在应用中嵌入网页，交互过程类似。

所谓基础接口，就是首先要规定原生应用和 *** 分别在WebView里注入/暴露一个什么对象：

并约定在这两个对象上分别可以调用什么 *** ：

顾名思义，NativeBridge.callNative是由 *** 调用向Native传递指令或数据的 *** ，而 *** Bridge.call *** 则是由Native调用向 *** 传递指令或数据的 *** 。 *** 签名中的参数含义如下：

基础接口只有两个对象和两个 *** ， *** 与App间的互操作则通过action和params来扩展和定义。

对于 *** 而言，虽然这里只定义了一个对象一个 *** ，但实践中，可以把action对应 *** 的实现附加到 *** Bridge上，只要把call *** 实现为一个分发 *** 即可，比如：

这样，所有对call *** 的调用，都会转化成对 *** Bridge上相应action *** 的调用，优点是只需一行代码。

另一种实现方式是通过switch...case语句实现调用分发，比如:

这样实现的优点是所有 *** 一目了然，当然同样也是把所有相关接口都附加到同一个 *** Bridge对象上。

以上两种实现模式各有利弊。

由 *** 发起的单向调用App的操作，主要涉及加载URL和切换到原生界面，可对应如下action：

loadUrl调用的参考协议如下：

这里NativeBridge是App的原生对象，其callNative *** 被调用时，会收到一个对象（字典/映射）参数。根据这个参数的action属性的值，App可知需要执行的操作是加载URL。于是再取得params属性中的url，发送请求即可。

loadContent调用的参考协议如下：

同上，这里通过params向App传递了必要参数，App负责切换到相应的原生界面。

由App发起的单向调用 *** 的操作，主要涉及用户点击后退按钮（），可对应如下action：

can_back调用的参考协议如下：

此调用返回的值示例如下：

顾名思义，can_back用于App询问 *** ：在返回上一级界面前，是否弹窗提示用户？

返回值中的can如果是true，则直接返回，不提示；如果是false，则弹出一个确认框，请用户确认。另一个值target是与App约定的返回目标，比如prev表示返回上一级，top表示返回顶级，等等。

双向调用是 *** 先调用App，然后App在完成操作后再调用 *** ，双向通常都需要传递数据。双向调用主要涉及 *** 调用App原生组件和用户点击右上角按钮，可对应如下action：

loadComponent的参考协议如下：

在这个例子中，涉及 *** 调用App显示其实现的城市选择组件：type: 'location'，用户选择完城市之后，App再调用set_location，将用户选择的城市名称传给 *** ：

*** 根据拿到的值更新界面，完成一次双向调用。另一个例子是 *** 调用原生的日期选择组件，与此类似。

为什么叫displayNextButton？因为根据具体业务场景，可能存在如下三种情况：

displayNextButton协议的参考实现如下：

以上代码示例表明， *** 调用App，告诉App显示“下一步”按钮，但是要禁用变灰，因为enable: false。如果传递的是enable: true，那么用户就可以点击“下一步”按钮了。点击之后，App再调用 *** 的save_form。最后，如果不想显示按钮，可以传递name: ''。

下面重点说一下用户点击“下一步”按钮，App调用save_form的场景。此时也分两种情况：

如果是 *** 通过App保存数据——可能因为App端实现了数据写入必需的加密机制——那么， *** 可以在App调用save_form时将约定好的数据返回给App，由App去保存数据。

如果是 *** 直接保存数据，比如通过Ajax，那么在保存完数据之后，则还需要调用前面所说的App暴露的loadUrl或loadComponent *** ，以告知App切换界面。当然这种情况下会出现第三次调用，但仍然属于双向调用。

本文介绍了 *** 与App交互的几种模式，而且只讨论了 *** 端的实现。在开发实践中，团队各端总会面临哪一端主导的问题。本文展示的参考实现就是H5端主导的一种实现形式。H5主导的特点是把主要业务逻辑都封装到WebView中，App主要协同配合，而优点是业务逻辑的变更不会蔓延到App。毕竟相对于H5，App的安装部署模式会造成多版本共存问题，需要尽可能控制新版本。假如由App端主导，将逻辑封装在App端，势必造成版本不受控，给整个项目或产品埋下隐患。

当然，事无绝对。具体情况还要具体分析。而且，哪方主导有时候也取决多方面因素。实践中还是要因人、因时、因势制宜。

h5做app和原生app有什么区别？

一、功能更强大

从以上定义中可以看出，原生APP是系统性的应用程序，可以地用手机终端的硬件设备，比如语音、短信、GPS、蓝牙、重力感应和摄像头等，但是webAPP是不可以做到这些的。所以如果你想做一个可扩展性强，而且后期功能不断完善的APP，一定要考虑原生的。                      二、 加载速度更快

刚我们有提到原生APP是由 “云服务器数据+APP应用客户端” ”两部分构成，APP应有所有的UI元素、数据内容、逻辑框架都是安装在手机里的。所以用户在使用APP的时候，不需要重新加载数据，因为这些内容都安装在手机中了，虽然之一次安装的时候有点复杂，但是在实际使用会方便很多。

济南APP开发定制

但是web APP打开每一个页面，都需要重新加载，虽然现在 *** 情况很好了，但是在实际中可能会有各种问题，比如流量用完了、所在区域 *** 不好或出了问题，就很大可能出现加载慢或者加载不出来的问题，加载多了很容易出现卡死错乱的情况，用户的体验就会很差。因此考虑到用户体验和加载速度方面，原生APP的性能要远远优于web。

第三：稳定性更好

目前市场的web版的APP多为模板，这种模板价格便宜，但是功能无法拓展，而且随着市场上浏览器、技术的进步，会逐步出现各种问题，稳定性根本无法保证。相比而言原生的APP技术更加成熟，而且功能可以拓展性更强。做个简单的比喻，我们有一套房子，这个房子可以考虑自己建设，这个过程中我可以决定建几层、建成什么样的户型等等，但如果其买别人做好的，那就只能从已经有的中选择。如果遇到 *** 不好的情况可能就像等期房一样，只大体知道是啥样的，但具体的得等 *** 好了才能看到。