app内嵌h5页面怎么交互(app调用h5方法)

奇怪的技能指南
本文来自周刊，作者李，高级技术书籍译者，翻译出版过40余部技术和交互设计专著，现任360公司高级前端开发工程师，360前端技术委员会委员，W3C AC代表。
在2018年11月26日发表的《360 AI音箱H5的开发实践》一文中简单提到了“与原生的交互”。本文将讨论H5和App在这个话题上的几种常见交互模式。
首先，本文涉及的H5-App交互协议和模式没有什么特别之处。相反，它们只是在业内已有经验和实际项目的基础上进行总结和提炼。因此，本文所涉及的技术和代码可以视为行业经验的产物，并不属于机密，也不属于权威实践。仅供业内同仁参考。
这篇文章的内容如下：
基本界面概述单向调用双向调用实现方式概述H5，这个在国内专门用来指代开发嵌入手机应用的网页的技术，在国外好像没有这个说法。从技术上讲，H5是超文本标记语言第五版HTML5的缩写。HTML只是用来开发网页的众多技术之一。除了HTML，还要用CSS设计界面，用JavaScript实现交互，甚至用Node.js实现服务器端逻辑。为什么H5通常指这些技术？我估计是因为简单，其次移动web开发技术正好需要这样一个概念。
移动网页在嵌入在移动电话应用中的浏览器引擎中运行。这种没有UI的内核容器统称为WebView，即iPhone(iOS 2.012.0)的UI WebView，Android的WKWebView(iOS 8.0，macOS 10.10)和WebView。总之，WebView就是移动应用中运行和显示网页的界面和接口(神奇的是，英文Interface既可以翻译成“界面”，也可以翻译成“界面”)。
与H5本地应用的交互是通过本地应用中的WebView实现的。通过这个环境，H5可以调用原生应用注入的原生对象的方法，原生应用也可以调用H5在这个环境下暴露的JavaScript对象的方法，从而实现指令和数据的传递。
例如，在Android应用程序中，WebView类有一个带有签名的公共方法addJavascriptInterface:
public addjavascriptinterface(object object，string name)调用此方法将指定名称的指定Java object对象注入WebView。这样WebView中的JavaScript就可以通过名字调用object的方法了。例如：
class JsObject { @ Java script interface public String toString(){ return \ ‘ injected object \ ‘；} } webview.getSettings()。setjavascript enabled(true)；webview . add javascriptinterface(new JsObject()，\ ‘ injected object \ ‘)；webView.loadData(\’\ ‘，\’text/html\ ‘，null)；webview . loadurl(\ ‘ JavaScript : alert(injected object . tostring())\ ‘)；在iOS或macOS中，需要通过创建WKWebView类的实例在应用中嵌入一个网页，交互过程类似。
基本接口所谓基本接口，就是先指定原生应用和JS分别在WebView中注入/暴露什么对象：
NativeBridge:本机应用注入WebView的对象JS。Bridge: JS向WebView中的对象公开，并指定可以对这两个对象调用什么方法：
NativeBridge.callNative (action，params，who care) JSBridge.callJS (action，params，whoami)顾名思义，原生桥。Call Native是调用JS向Native传递指令或数据的方法，而JS桥接。Call JS是调用native向JS传递指令或数据的方法。签名中的参数具有以下含义：
Action: string，params:JSON对象，要传递给Native/JS的数据，whoCare: numerical value，表示JS希望哪端响应whoAmI: numerical value，表示哪端调用JS基本接口只有两个对象和两个方法。JS和App之间的互操作性是由action和params扩展和定义的。
对于JS的实现方式，虽然这里只定义了一个对象和一个方法，但是在实际操作中，可以将对应的action方法的实现附加到JSBridge上，只要将callJS实现为一个分发方法，比如：
窗户。JSBridge={ } window . js bridge . callJS=function({ action，params，whoami }){ return window . js bridge[action](params，whoami)}这样，所有对call js的调用都会转换成对js bridge上相应action方法的调用。优点是只需要一行代码。
另一种方法是通过交换机实现呼叫分配.case语句，比如：
function callJS (action，params，whoAmI){ params=JSON . parse(JSON . stringify(params))switch(action){ case ‘ show skill ‘ : const category=params . category jsbridge . show skill(category)break case ‘ showSkill detail ‘ 3360 const id=params . id jsbridge . showSkill detail(id)break case ‘ other action ‘ 3360//部分代码break default 3360 } }//JS暴露于通用接口const这种实现的好处是所有方法一目了然，当然，所有相关接口都附加到同一个JSBridge对象上。
以上两种实现方式各有利弊。
单向调用JS发起的单向调用App的操作主要涉及加载URL和切换到原生界面，可以对应以下动作：
URL:加载另一个URLloadContent:跳转到本机接口。loadUrl调用的参考协议如下：
NativeBridge . callNative({ action 3360 ‘ load URL ‘，params: { URL }，who care 3360 0})这里native bridge是App的原生对象，调用其call native方法时，会收到一个object (dictionary/map)参数。根据这个参数的action属性值，App就知道要执行的操作是加载URL。然后获取params属性中的url并发送请求。
加载调用的参考协议如下：
原生桥。调用本机({Action : \’ Load Content \ ‘，params 3360 {Type 3360 \’ Album \ ‘，Content : { Album _ ID 3360 \ ‘ 1 \ ‘ }，世卫组织关怀3360 0 0})同上，这里通过params
App发起的单向调用JS主要是用户点击返回按钮()，可以对应以下动作：
Can_back:返回前询问JS用户是否需要确认can_back调用的参考协议如下：
bridge . call js({ action 3360 \ ‘ can _ back \ ‘，params: { }，whoami3360 1/2})此调用返回值的示例如下：
{can3360 true，target: \’ prev \’}顾名思义，can_back是App用来问JS:在返回上一级界面之前，是否弹出提示用户？
如果返回值中can为真，则直接返回，不做提示；如果是假的，会弹出一个确认框，要求用户确认。另一个值target是和App约定的回报目标。例如，prev表示返回到下一个更高的级别，top表示返回到顶级，以此类推。
调用双向双向调用是指JS先调用App，操作完成后App再调用JS。双向通常需要数据传输。双向调用主要涉及JS调用App的原生组件和用户点击右上角的按钮，可以对应以下动作：
Load:调用原生组件displayNextButton:显示“下一步”、“保存”或“完成”按钮的loadComponent的引用协议如下：
native bridge . call native({ action : ‘ load component ‘，params: { type: ‘location ‘，value，callback name : ‘ set _ location ‘ }，Care: 0})本例中，JS调用App显示其实现的城市选择组件：type: ‘location ‘。用户选择城市后，App再次调用set_location，将用户选择的城市名称传递给JS:
bridge . call JS({ action 3360 ‘ set _ location ‘，params: { value3360 ‘北京市朝阳区’，}，whoami 3360 1/2}) JS根据获取的值更新接口，完成一次双向调用。再比如JS调用原生日期选择组件，与此类似。
为什么叫displayNextButton？因为根据具体的业务场景，可能会有以下三种情况：
目前WebView不需要在右上角显示按钮，比如详情页；目前WebView需要显示“下一步”或者“保存”按钮，但是禁用了变灰；目前，WebView需要显示“下一步”或“保存”按钮，允许用户点击。displayNextButton协议的参考实现如下：
native bridge . call native({ action 3360 \ ‘ display nextbutton \ ‘，params: {name3360 \’ next \ ‘，enable3360 false，callback name3360 \’ save _ form \’}，care : 0 0 })上面的代码示例显示JS调用App，告诉App显示“下一步”按钮，但是因为enable 3360 false，所以需要禁用变灰。如果enable:为真，则用户可以单击“下一步”按钮。点击后，App再次调用JS的save_form。最后，如果不想显示按钮，可以传递name: ‘ ‘。
让我们重点看一下用户点击“下一步”按钮，App调用save_form的场景。这时候也有两种情况：
JS直接保存数据JS通过App保存数据。如果JS通过App ——保存数据，可能是因为App实现了必要的加密机制3354进行数据写入。然后JS可以在App调用save_form的时候把约定的数据返回给App，App会保存数据。
如果JS直接保存数据，比如通过Ajax，那么在保存数据之后，你需要调用上面提到的App暴露的loadUrl或者loadComponent方法来通知App切换接口。当然，这种情况下会有第三次通话，但仍然是双向通话。
哪一方主导本文介绍了JS与App交互的几种模式，只讨论JS的实现。在开发实践中，团队的每一端总是面临着哪一端占优的问题。本文展示的参考实现是一种由H5主导的实现形式。H5的主要特点是所有主要的业务逻辑都封装在WebView中，应用程序主要相互协作。好处是业务逻辑的变化不会波及到应用程序。毕竟相比H5，App的安装部署方式会造成多版本共存，所以要尽可能控制新版本。如果以App端为主，逻辑封装在App端，必然会造成版本失控，为整个项目或产品埋下隐患。
当然，没有什么是绝对的。具体情况要具体分析。而且，哪一方占优，有时候取决于很多因素。在实际操作中，还是要因人、因时、因境。