前端手艺演进（二）：前端与协定

2019年8月20日 165次阅读 来源: 姜小抖

这个来自之前做的培训，删减了一些营业相干的，参考了许多材料（
参考材料列表），感谢先辈们，么么哒 😘

如今前后端的通讯平常都是经过过程协定来完成的，这里引见和前端开辟相干的各种协定。

HTTP

HTTP 协定是Hyper Text Transfer Protocol（超文本传输协定）的缩写，是万维网的数据通讯的基础。设想HTTP最初的目的是为了供应一种宣布和吸收HTML页面的要领，如今基础上什么范例的文件都可以传输了，比方图片、CSS、JS、数据报文等。

HTTP平常基于TCP/IP通讯协定来通报数据，它有以下特性：

  1. 简朴疾速：客户向效劳器请求效劳时，只需传送请求要领和途径。请求要领经常运用的有GET、HEAD、POST。每种要领划定了客户与效劳器联络的范例差别。由于HTTP协定简朴，使得HTTP效劳器的顺序范围小，因而通讯速率很快。
  2. 天真：HTTP许可传输恣意范例的数据对象。正在传输的范例由Content-Type加以标记。
  3. 无衔接：无衔接的寄义是限定每次衔接只处置惩罚一个请求。效劳器处置惩罚完客户的请求，并收到客户的应对后，即断开衔接。采纳这类体式格局可以节约传输时候。
  4. 无状况：HTTP协定是无状况协定。无状况是指协定关于事务处置惩罚没有影象才。缺乏状况意味着假如后续处置惩罚需要前面的信息，则它必需重传，如许可以致使每次衔接传送的数据量增大。另一方面，在效劳器不需要先前信息时它的应对就较快。
  5. 支撑B/S及C/S情势。

HTTP运用一致资本标识符（Uniform Resource Identifiers, URI）来传输数据和竖立衔接。URL是一种特别范例的URI，包括了用于查找某个资本的充足的信息。一个完整的URL平常包括以下几部份：

协定   域名   端口   虚拟目录   文件名   参数 锚

比方：http://test.google.com:80/test/test.html?query=admin#home

请求音讯Request

一般一个HTTP请求音讯包括以下内容：请求行、请求头、空行、音讯主体。

《前端手艺演进（二）：前端与协定》

比方：

 GET /books/?sex=man&name=Professional HTTP/1.1
 Host: www.example.com
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
 Gecko/20050225 Firefox/1.0.1
 Connection: Keep-Alive
  • 请求行：GET /books/?sex=man&name=Professional HTTP/1.1 用来申明请求范例，要接见的资本以及所运用的HTTP版本。比较罕见的请求范例有GET，POST，PUT，DELETE，OPTIONS等。
  • 请求头：从第二行起为请求头部，用来申明效劳器要运用的附加信息。
  • 空行：请求头部背面的空行是必需的，纵然请求数据为空，也必需有空行。
  • 请求数据：也叫请求主体，可以增添恣意的其他数据，这个例子的请求数据为空。

带有请求数据的POST请求：

 POST / HTTP/1.1
 Host: www.example.com
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
 Gecko/20050225 Firefox/1.0.1
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 40
 Connection: Keep-Alive

 sex=man&name=Professional

相应音讯Response

平常情况下，效劳器吸收并处置惩罚客户端发过来的请求后会返回一个HTTP的相应音讯。一般一个HTTP请求音讯包括以下内容：状况行、音讯报头、空行、相应正文。

比方：

HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8

<html>
      <head></head>
      <body>
            <!--body goes here-->
      </body>
</html>
  • 状况行：由HTTP协定版本号， 状况码， 状况音讯 三部份构成。
  • 音讯报头：用来申明客户端要运用的一些附加信息。
  • 空行：音讯报头背面的空行是必需的。
  • 相应正文，效劳器返回给客户端的文本信息。

状况码

状况码由三位数字构成，第一个数字定义了相应的种别，共分五种种别：

  • 1xx：指导信息–示意请求已吸收，继承处置惩罚。
  • 2xx：胜利–示意请求已被胜利吸收、明白、接收。
  • 3xx：重定向–要完成请求必需举行更进一步的操纵。
  • 4xx：客户端毛病–请求有语法毛病或请求没法完成。
  • 5xx：效劳器端毛病–效劳器未能完成正当的请求。

罕见的状况码有以下几种：

  • 200 OK 客户端请求胜利。
  • 301 Moved Permanently 请求永远重定向。
  • 302 Moved Temporarily 请求暂时重定向。
  • 304 Not Modified 文件未修正，可以直接运用缓存的文件。
  • 400 Bad Request 由于客户端请求有语法毛病，不能被效劳器所明白。
  • 401 Unauthorized 请求未经受权。
  • 403 Forbidden 效劳器收到请求，然则谢绝供应效劳。效劳器一般会在相应正文中给出不供应效劳的缘由。
  • 404 Not Found 请求的资本不存在，比方，输入了毛病的URL。
  • 500 Internal Server Error 效劳器发作不可预期的毛病，致使没法完成客户端的请求。
  • 503 Service Unavailable 效劳器当前不可以处置惩罚客户端的请求，在一段时候今后，效劳器可以会恢复一般。

HTTP和TCP/IP协定的关联

《前端手艺演进（二）：前端与协定》

HTTP/2

HTTP2即超文本传输协定2.0版本，是HTTP协定的下一个版本。由于范例委员会不盘算再宣布子版本了，所以直接叫HTTP/2，而不叫HTTP/2.0。

HTTP2相关于之前的HTTP协定有以下几个长处：

  • HTTP 2采纳完整二进制的花样来传输数据。同时HTTP 2对音讯头采纳HPACK紧缩传输，最大限制地节约了传输带宽。比拟于HTTP 1.x 每次请求都邑照顾大批冗余头信息(比方浏览器Cookie信息等)，HTTP2具有很大的上风。
  • HTTP 2运用TCP多路复用的体式格局来下降收集请求衔接竖立和封闭的开支，多个请求可以经过过程一个TCP衔接来并发完成。
  • HTTP2支撑传输流的优先级和流量掌握机制。HTTP2中每一个文件传输流都有自身的传输优先级，并可以经过过程效劳器来动态转变，效劳器会保证优先级高的文件流先传输。比方在将来的浏览器端衬着中，效劳器端就可以优先传输CSS文件保证页面的衬着，然后在CSS文件悉数传输完成后加载JavaScript剧本文件。
  • 支撑效劳器端推送。效劳端可以在特定条件下把资本主动推送给客户端。

HTTP 1.1会让资本列队加载，以下图所示：

《前端手艺演进（二）：前端与协定》

但当我们开启了HTTP/2今后，有了TCP多路复用，个数几乎没有限定了，以下图所示：

《前端手艺演进（二）：前端与协定》

HTTP/2 将 HTTP 协定通讯分解为二进制编码帧的交流，这些帧对应着特定数据流中的音讯。统统这些都在一个 TCP 衔接内复用。这是 HTTP/2 协定统统其他功用和机能优化的基础。

《前端手艺演进（二）：前端与协定》

如今支撑HTTP2协定传输的浏览器依旧很少，跟着手艺的生长和浏览器的更新迭代，HTTP2的时期终会到来，但我们依旧不能在短时候内希图经过过程它来帮我们举行页面优化。

HTTPS

HTTPS（超文本传输平安协定 Hypertext Transfer Protocol Secure）经过HTTP举行通讯，但运用SSL/TLS来加密数据包。HTTPS的主要头脑是在不平安的收集上建立一平安信道。一般，HTTP 直接和 TCP 通讯。当运用 SSL 时，则演变成先和 SSL 通讯，再由 SSL 和 TCP 通讯了。简言之，所谓 HTTPS，实在就是身披 SSL 协定这层外壳的 HTTP。HTTP的URL由“http://”肇端且默许运用端口80，HTTPS的URL由“https://”肇端且默许运用端口443。

SSL 是独立于 HTTP 的协定，所以不光是 HTTP 协定，其他运行在运用层的 SMTP 和 Telnet 等协定都可合营 SSL（Secure Socket Layer） 协定运用。

《前端手艺演进（二）：前端与协定》

HTTP是不平安的，进击者经过过程监听和中间人进击等手腕，可以猎取网站帐户和敏感信息等。人们对 HTTPS 有一个普遍的毛病认识，以为只需处置惩罚敏感通讯的网站才需要 HTTPS。 每一个未受庇护的 HTTP 请求都可以暴露与用户行动和身份有关的信息。只管接见一次未受庇护的网站可以看上去无害，但一些入侵者会检察汇总的用户浏览运动，以揣摸他们的行动和企图，从而举行去匿名化进击，查出匿名用户的身份。比方，员工可以在浏览未受庇护的医疗文章时不经意地向其店主泄漏敏感的康健信息。

公钥和私钥

加密和解密同用一个密钥的体式格局称为同享密钥加密（Common key crypto system），也被叫做对称密钥加密。

《前端手艺演进（二）：前端与协定》

以同享密钥体式格局加密时必需将密钥也发给对方。可终究怎样才平安地转交？在互联网上转发密钥时，假如通讯被监听那末密钥就可会落入进击者之手，同时也就失去了加密的意义。

SSL 采纳一种叫做公开密钥加密（Public-key cryptography）的加密处置惩罚体式格局。公开密钥加密运用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。望文生义，私有密钥不能让其他任何人晓得，而公开密钥则可以随便宣布，任何人都可以获得。

运用公开密钥加密体式格局，发送密文的一方运用对方的公开密钥举行加密处置惩罚，对方收到被加密的信息后，再运用自身的私有密钥举行解密。运用这类体式格局，不需要发送用来解密的私有密钥，也没必要忧郁密钥被进击者窃听而盗走。

《前端手艺演进（二）：前端与协定》

HTTPS 采纳夹杂加密机制：

《前端手艺演进（二）：前端与协定》

证书颁布机构

公开密钥加密体式格局照样存在一些题目的。那就是没法证明公开密钥自身就是名副实在的公开密钥。

证书颁布机构 (CA) 是一个构造，对公钥和与大众 DNS 称号之间的映照举行证明。比方，客户端怎样晓得特定公钥是不是为 www.foobar.com 的实在公钥？按理说，没法晓得。CA 证明特定密钥是特定网站的实在密钥，它运用自身的私钥来加密署名该网站的公钥。此署名在计算上是没法捏造的。浏览器（和其他客户端）保护信托锚存储库，它包括着名 CA 具有的公钥，而且它们运用这些公钥来加密考证 CA 的署名。

SSL握手流程

《前端手艺演进（二）：前端与协定》

末了运用同享密钥来举行今后的通讯，细致流程：

《前端手艺演进（二）：前端与协定》

Websocket

在现实的前端运用项目中，除了运用应对情势的HTTP协定举行一般收集资本文件的请求加载外，偶然也需要竖立客户端与效劳端之间的及时衔接举行通讯，比方网页及时谈天的运用场景，这就必需触及浏览器端的及时通讯协定了。关于这些对及时性请求较高的运用场景，一般的HTTP协定就并不实用。虽然前端可以经过过程Ajax定时向效劳端轮询的体式格局来延续猎取效劳端的音讯，然则这类体式格局效力相对较低。

WebSocket是浏览器端和效劳器端竖立及时衔接的一种通讯协定，可以在效劳器和浏览器端竖立相似Socket体式格局的音讯通讯。相关于HTTP1.1协定，WebSocket协定的上风是轻易效劳器和浏览器之间的双向数据及时通讯。

7层收集模子

这里只是相似Socket体式格局，WebSocket 是竖立在 TCP/IP 协定之上，属于运用层的协定，而 Socket 是在运用层和传输层中的一个笼统层，它是将 TCP/IP 层的庞杂操纵笼统成几个简朴的接口来供应给运用层挪用。简朴回忆一下7层收集模子：

《前端手艺演进（二）：前端与协定》

简朴来讲，我们在传输数据时，可以只运用(传输层)TCP/IP协定，然则那样的话，假如没有运用层，便没法辨认数据内容。假如想要使传输的数据有意义，则必需运用到运用层协定。运用层协定有许多，比方HTTP、FTP、TELNET等，也可以自身定义运用层协定。WEB运用HTTP协定作运用层协定，以封装HTTP文本信息，然后运用TCP/IP做传输层协定将它发到收集上。

TCP/IP只是一个协定栈，就像操纵体系的运行机制一样，必需要详细完成，同时还要供应对外的操纵接口。这个就像操纵体系会供应范例的编程接口，比方win32编程接口一样，TCP/IP也要供应可供顺序员做收集开辟所用的接口，这就是Socket编程接口。Socket的涌现只是使得顺序员更轻易地运用TCP/IP协定栈罢了，是对TCP/IP协定的笼统，从而构成了我们晓得的一些最基础的函数接口，比方create、listen、connect、accept、send、read和write等等。

《前端手艺演进（二）：前端与协定》

Websocket运用

WebSocket 的完成分为握手，数据发送/读取，封闭衔接。

《前端手艺演进（二）：前端与协定》

var ws = new WebSocket("wss://echo.websocket.org");

ws.onopen = function(evt) { 
  console.log("Connection open ..."); 
  ws.send("Hello WebSockets!");
};

ws.onmessage = function(evt) {
  console.log( "Received Message: " + evt.data);
  ws.close();
};

ws.onclose = function(evt) {
  console.log("Connection closed.");
};

在线演示：https://html5demos.com/web-socket/

DDP

DDP ( Distributed Data Protocol，分布式数据协定）是一种新型的客户端与效劳器端的及时通讯协定，由于兼容性的缘由，如今运用还不普遍。

DDP运用JSON的数据花样在客户端和浏览器之间举行数据传输通讯，所以关于前端开辟者来讲运用异常轻易。著名的Meteor Web框架的双向及时数据更新机制底层运用的就是DDP，这类协定情势下客户端可向效劳器端提议远程过程挪用，客户端也可以定阅效劳端数据，在效劳端数据变化时，效劳器会向客户端提议关照，触发浏览器相应的操纵。

//建立效劳端
const DDPClient = require('ddp');
const client = new DDPClient({
  host: 'localhost',
  port: 3000
});

//监听音讯
client.on('message', function(data, flags){
  console.log('[DDP音讯]: ', data);
});

//建立衔接
client.connect(function(){
  client.subscribe('post',[],function(){
    console.log('[post定阅音讯]');
  });
});

协定范例：https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md

RESTful

REST (Representational State Transfer，表述性状况转化）并非某一种详细的协定，而是定义了一种收集运用软件之间的架构关联并提出了一套与之对应的收集之间交互挪用的划定规矩。与之相似的比方初期的WebSevice，WebSevice如今基础都不必了。

在REST情势的软件运用效劳中，每一个资本都有一个与之对应的URI地点，资本自身都是要领挪用的目的，要领列表对统统资本都是一样的，而且这些要领都引荐运用HTTP协定的范例要领，比方GET、POST、PUT、DELETE等。假如一个收集运用软件的设想是根据REST定义的，我们就可以以为它运用的交互挪用的要领设想遵照RESTful范例。换种体式格局明白，RESTful 是一种软件架构之间交互挪用数据的协定作风范例，它发起以一种通用的体式格局来定义和治理数据交互挪用接口。

比方：关于书本book的纪录治理接口，有增、删、改、查操纵，因而我们定义接口：

  • path/addBook
  • path/deleteBook
  • path/updateBook
  • path/getBook

看上去彷佛没有什么题目。厥后，另一个项目也有相似的接口定义，却可以叫作：

  • path/appendBook
  • path/delBook
  • path/modifyBook
  • path/getBook

接着有一天，项目负责人可以会说，要晋级接口来满足新的需求，因而我们又增添了：

  • path/addBook2
  • path/deleteBook2
  • path/updateBook2
  • path/getBook2

如许用起来是没有什么题目，然则这些随便的定义会增添数据接口保护难度和项目继承开辟的本钱。

这时候，我们也许会斟酌运用文档或范例，划定肯定要运用add来增添，新的接口版本号放前面 path/v2/addBook，开辟的人必需严厉根据文档范例去写。如许做很好，但依旧不够完美，缘由有以下几点：

  • 由于项目事情经常排期慌张，你可以没时候去写文档，或许背面接办的人不想去看文档。
  • 开辟修正功用后极可以来不及或遗忘去更新文档。
  • 不管文档写很多清楚，我们看起来效力老是很低。

这时候假如有一个作风更好的通用范例来定义数据交互接口，就不必这么麻烦了。所以我们完整可以运用RESTful设想的范例特性来处理上面碰到的题目。关于书本纪录操纵接口的定名可以以下操纵：

HTTP要领URI形貌
POSTpath/v1/book新增书本信息
DELETEpath/v1/book删除书本信息
PUTpath/v1/book更新书本信息
GETpath/v1/book猎取书本信息

运用RESTful范例来从新设想接口后，统统就变得很清楚天然，如许新的工程师接办项目时，只需他充足相识RESTful范例，几乎没偶然候本钱。纵然他不相识RESTful范例，也可以很快地去相识，这就可以防止他去读那份看似完美实在冗杂杂的文档。

这里触及到了几个设想的准绳：

  • “资本”示意一种实体，所以应当是名词，URL不该该有动词，动词应当放在HTTP协定中。
  • 根据范例，不该该在URL中包括版本号，应当放在HTTP请求头信息的Accept字段中，不过如许不够直观，所以平常的体式格局照样把版本号放在URL中，算是一个反情势。

RESTful API 的主要设想准绳就是这些，总结来讲就是连系HTTP的固有体式格局来表征资本的状况变化形貌，而不是经过过程动词加名词的体式格局来设想。

Github RESTful API：https://developer.github.com/v3/

GraphQL

GraphQL 对 API 中的数据供应了一套易于明白的完整形貌，使得客户端可以正确地获得它需要的数据，而且没有任何冗余，也让 API 更容易地跟着时候推移而演进。

GraphQL 处理的最主要的3个题目分别是：

  • 需要举行屡次往复以猎取所需的数据：典范的 REST API 请求多个资本时得载入多个 URL，而 GraphQL 可以经过过程一次请求就猎取你运用所需的统统数据。
  • 客户端依赖于效劳端：消除了效劳器对数据内容举行硬编码的需要。我们可以把客户端与效劳端星散开来，零丁举行保护和革新。前后端完全星散。
  • 蹩脚的前端开辟体验：运用 GraphQL，开辟人员可以声明式地来表达其用户界面的数据需求，不必老是关注数据是怎样猎取的。

RESTful APIs vs GraphQL APIs

一个简朴的示例：我们要做一个星球大战人物信息展现的UI界面：需要显现人物的姓名，诞生年份，星球称号以及统统他们参演的影戏的称号。

这个 UI 的 JSON 数据可以相似于：

{
  "data": {
    "person": {
      "name": "Darth Vader",
      "birthYear": "41.9BBY",
      "planet": {
        "name": "Tatooine"
      },
      "films": [
        { "title": "A New Hope" },
        { "title": "The Empire Strikes Back" },
        { "title": "Return of the Jedi" },
        { "title": "Revenge of the Sith" }
      ]
    }
  }
}

假如运用 React.js ，平常会如许示意视图：

// The Container Component:
<PersonProfile person={data.person} ></PersonProfile>

// The PersonProfile Component:
Name: {person.name}
Birth Year: {person.birthYear}
Planet: {person.planet.name}
Films: {person.films.map(film => film.title)}

假如运用 RESTful API，我们可以如许请求数据：

1、猎取人物信息：

GET - /people/{id}
{
  "name": "Darth Vader",
  "birthYear": "41.9BBY",
  "planetId": 1
  "filmIds": [1, 2, 3, 6],
  ...
}

2、猎取星球信息：

GET - /planets/1

3、猎取统统影戏信息：

GET - /films/1
GET - /films/2
GET - /films/3
GET - /films/6

演示

我们需要发送6个请求才猎取到统统需要的数据，每一个猎取数据的要领都是敕令式的。每一个接口返回的信息另有许多字段不是我们所需要的。为了处理这个题目，我们可以会新增添一个接口，比方：

GET - /people/{id}/films

然则如许就不是地道的RESTful API了，而且后端要分外的建立这个接口，用来满足前端的数据请求，假如增减字段或对象，后端还要增添接口或许从新编码。

假如运用GraphQL，我们可以如许来查询：

GET or POST - /graphql?query={...}

比方参数运用：

{
  person(personID: 4) {
    name,
    birthYear,
    homeworld {
      name
    },
    filmConnection {
      films {
        title
      }
    }
  }
}

演示

一个请求就完成了统统数据的猎取。

GraphQL的天真性也会带来一些题目，比方增添庞杂度，资本耗尽进击，N+1查询等。FB针对N+1给出了 dataloader 的计划。

Github GraphQL API：https://developer.github.com/v4/

在线调试：https://developer.github.com/v4/explorer/

与Native交互

Hybrid App是在Native App运用的基础上连系了Web App运用所构成的情势，平常称之为夹杂App。从手艺开辟上来看，比拟于传统的桌面浏览器端的Web App，它具有以下几方面的特性：

  • 可用的体系收集资本更少。由于挪动装备CPU、内存、网卡、收集衔接多方面的限定，HybridApp的前端页面可用的体系资本远远小于桌面浏览器。就收集衔接来讲，大部份挪动装备的运用者运用的还是3G、4G的收集，带宽和流量均有限定，和桌面浏览器的带宽接入比拟照样有着本质上的区分。
  • 支撑更新的浏览器特性。如今智能装备浏览器品种相对较少，且跟着硬件装备的疾速更新，主流的浏览器以WebKit内核占多数，支撑较新的浏览器特性。不像桌面浏览器那样需要斟酌较低版本Internet Explorer的兼容性题目。
  • 可完成离线运用。Hybrid的一个上风是可以经过过程新的浏览器特性或Native的文件读取机制举行文件级的文件缓存和离线更新。这是桌面浏览器,上较难做到的。这些离线机制经常可以用来填补Hybrid App收集体系资本不足的瑕玷，让浏览器剧本更快从当地缓存中加载。
  • 较多的机型斟酌。由于如今挪动装备平台不一致，而且差别装备机型体系的浏览器完成仍有肯定的区分，因而Hybrid App运用需要斟酌差别装备机型的兼容性题目。
  • 支撑与Native交互。Hybrid App的另一个特性是连系了挪动端Native特性，可以在前端页面中挪用客户端Native的才，比方摄像头、定位、传感器、当地文件接见等。

Web挪用Native

在HTML5中挪用Native顺序平常有几种较通用的要领：

一、经过过程URI请求。

Native运用可在挪动端体系中注册一个Scheme协定的URI，这个URI可在体系的恣意处所受权接见来调起一段原生要领或一个原生的界面。一样，Native 的WebView控件中的JavaScript剧本的请求也可以婚配挪用这一通用的Scheme协定。比方我们经过过程对 window.location.href 赋值或运用iframe的体式格局发送一个URI的请求，这个请求可以被Native运用的体系捕捉并调起Native运用注册婚配的这个Scheme协定内容。

比方微信的scheme为（weixin://）。

《前端手艺演进（二）：前端与协定》

二、经过过程addJavascriptInterface（Android）或JavaScriptCore（iOS）注入要领到页面中挪用。

Android，原生Webview需要先注册可供前端挪用的JS函数：

// Android容器许可JS剧本，必需要
webSettings.setJavaScriptEnabled(true);
// Android容器设置侨连对象
mWebView.addJavascriptInterface(getJSBridge(), "JSBridge");

// Android4.2版本及以上，当地要领要加上注解@JavascriptInterface，否则会找不到要领。
private Object getJSBridge(){  
    Object insertObj = new Object(){  
        @JavascriptInterface
        public String foo(){  
            return "foo";  
        }  

        @JavascriptInterface
        public String foo2(final String param){  
            return "foo2:" + param;  
        }  

    };  
    return insertObj;  
}

然后H5中即可挪用原生中注册的函数：

// 挪用要领一
window.JSBridge.foo(); // 返回:'foo'
// 挪用要领二
window.JSBridge.foo2('test'); // 返回:'foo2:test'

iOS，需要引入JavaScriptCore库：

#import <JavaScriptCore/JavaScriptCore.h>

然后原生需要注册API：

//webview加载终了后设置一些js接口
-(void)webViewDidFinishLoad:(UIWebView *)webView{
    [self hideProgress];
    [self setJSInterface];
}

-(void)setJSInterface{

    JSContext *context =[_wv valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];

    // 注册名为foo的api要领
    context[@"foo"] = ^() {

        //猎取参数
        NSArray *args = [JSContext currentArguments];
        NSString *title = [NSString stringWithFormat:@"%@",[args objectAtIndex:0]];
        //做一些自身的逻辑
        //返回一个值  'foo:'+title
        return [NSString stringWithFormat:@"foo:%@", title];
    };
    
}

今后前端就可以挪用了：

// 挪用要领,用top是确保挪用到最顶级,由于iframe要用top才拿到顶级
window.top.foo('test'); // 返回:'foo:test'

三、改写浏览器原有对象。

经过过程修正本来浏览器的window某些要领，然后阻拦牢固划定规矩的参数，然后分发给Java对应的要领去处置惩罚。这里经常运用的是以下四个要领：

  • alert，可以被webview的onJsAlert监听
  • confirm，可以被webview的onJsConfirm监听
  • onsole.log，可以被webview的onConsoleMessage监听
  • prompt，可以被webview的onJsPrompt监听

Native挪用Web

需要先运用JavaScript 在HTML5页面全局中声明相对应的要领。

然后Native向HTML5提议挪用，Android平台平常经过过程loadUrl，iOS一般经过过程stringByEvaluatingJavaScriptFromString完成。

Android调HTML5：

// 异步实行JS代码,并猎取返回值    
mWebView.evaluateJavascript("javascript: 要领名('参数,需要转为字符串')", new ValueCallback<String>() {
        @Override
        public void onReceiveValue(String value) {
            // 这里的value即为对应JS要领的返回值
        }
});

iOS调HTML5：

// 可以获得JS函数实行的返回值
// 要领必需是Html页面绑定在最顶层的window上对象的
// 如window.top.foo
[webView stringByEvaluatingJavaScriptFromString:@"要领名(参数);"];

JSBridge

《前端手艺演进（二）：前端与协定》

JSBridge是HTML5与Native通讯的桥梁，其作用是完成HTML5与Native间的双向通讯。JSBridge综合了上面的手艺，更多的是一种情势、一种头脑，各家的完成体式格局也略有差别。比方微信JSSDK，就是基于WeixinJSBridge，微信浏览器中的页面，经过过程WeixinJSBridge挪用微信供应的一些原生功用。

    原文作者：姜小抖
    原文地址: https://segmentfault.com/a/1190000017380814
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞