App与Js交互（三）Android、iOS通用解决方案推荐

示例代码

Demo： https://github.com/gwpp/jsinterface

正文

在前两篇文章中我们分别详细的列举了Android、iOS两端与JS的交互方式，iOS有5种，Android有3种，如果还有其他，还请读者继续补充一起学习。这么多的交互方式我们应该怎么去选择呢？看过前两篇文章的同学应该能看一些点：

方法很多，但是难度系数是不同的，有些东西如果要在团队中用起来是需要时间成本、学习成本的。
有些引进了三方库，有些是原生支持的。
有些是Android、iOS两端通用的解决方案，有些是各平台特有的。

技术选型的几项原则

我们做技术选型的时候一般会有几个原则：

易用性。团队的能力要hold住，如果整个团队没有一个人会，那还是要慎重考虑一下学习成本的。
平台通用性。在端与端的交互中我们非常重视这一点，我们希望有一种解决方案可以完美的兼容所有平台，而不是两两之间相互约定一种方式。
社区支持。自己一个人或者一个小团队闷头干是很难的，除了问题都没地方询问、讨论，想想都很蛋疼。
侵入性。如果一种方案可以简单集成，相关代码聚集在一两个文件中；另一种方案会写的到处都是，你会选择哪一个？
可维护性。我们需要的是引进这个方案之后只需要封装一下或者沉淀一份内部的技术文档，就可以让任意同学去进行修改。而不是只有特定的一个人或几个人知道。
其他....

一点推荐

罗里吧嗦说了很多有的没的，那我们究竟应该怎样选择呢？推荐如下：

拦截跳转（入门级）
- 适用场景：嵌入页面不多、团队技术能力不强
- iOS：UIWebView/WKWebView 都可以，使用拦截跳转的形式，具体操作见《App与Js交互（一）iOS》的方案一、方案二。
- Android：拦截跳转的形式，具体操作见《App与Js交互（二）Android》的方案一。
- 推荐原因：
  1. 跨平台。JS端不需要关心是Android端还是iOS端，约定好跳转链接后就可以两端统一。
  2. 简单易用。JS端只需要window.location=xxxx就好了，Android、iOS也仅仅只是拦截跳转，网上教程很多，不太容易出错。
- 缺点：
  1. 大量的硬编码代码，约定好的链接都是写死的。
  2. 因为不支持return和callback，所以通信只能是单向的，只能做send操作，做不了get操作。
暴露Native对象供JS调用 （进阶级）
- 适用场景：嵌入页面很多、团队技术能力较强
- iOS：仅支持 UIWebView，暴露出去一个Objective-C对象供JS调用，具体操作见《App与Js交互（一）iOS》的方案三。
- Android：暴露出去一个Java对象供JS调用，具体操作见《App与Js交互（二）Android》的方案二。
- 推荐原因：
  1. 跨平台。JS端不需要关心是Android端还是iOS端，约定好跳转链接后就可以两端统一。
  2. 移动端不需要再拦截跳转链接，硬编码减少。
  3. 支持双向return。即JS调Native方法可以拿到return，Native调用JS也可以拿到return。
  4. JS端很容易就可以把交互相关的代码封装成一个lib，可以所有页面任意调用。
- 缺点：
  1. iOS端只支持UIWebView，而UIWebView的内存优化、加载速度等都没有WKWebView做得好，为了用这种交互方式而舍弃WKWebView，这不是一个很好的选择。
  2. Android API 16 之前有安全性问题，详情见 https://jaq.alibaba.com/blog.htm?id=48
  3. 只支持return，不支持callback。所以在异步调用的时候拿不到返回值，比如我要JS调起APP的登录，登录完成后把用户信息返回给JS，这是一个很常规的需求，但这种交互方式却是做不到的。
  4. JS端调用很方便，但是APP端的初始化会比较麻烦，特别是iOS。
JSBridge （成熟级）
- 适用场景：嵌入页面很多，团队技术能力强，APP、JS团队愿意一起折腾
- iOS：UIWebView/WKWebView都可以，使用桥接的方式，具体操作见《App与Js交互（一）iOS》的方案四、方案五。
- Android：使用桥接方式，具体操作见《App与Js交互（二）Android》的方案三。
- 推荐原因：
  1. 跨平台。JS端不需要关心是Android端还是iOS端，约定好跳转链接后就可以两端统一。
  2. 移动端不需要再拦截跳转链接，硬编码减少。
  3. 支持双向callback，可以异步回调。
  4. JS端可以封装成lib，可以任意页面发起调用。
  5. 安全性高。
- 缺点：
  1. 只支持callback，不支持return，使用起来会相对麻烦一些。
  2. JS、Android、iOS三端的初始化代码都很多、很复杂。出现错误排查起来比较麻烦，团队内部最好有一个三端通吃的大佬，否则有时候出了BUG真的会疯掉。

写在最后

可以看见我推荐的三种解决方案都是跨平台的，因为这一点真的很重要，否则页面多起来JS同学会疯掉的。

这三种方案我们团队都用过，【1】是很早就被废弃的，代码太冗余，前端小手一抖APP的拦截就挂了。【2】、【3】我们犹豫了很久，因为都可以达到我们的需求，【2】简单些，网上资料多，但是iOS不能用WKWebView，不支持异步回调。【3】复杂了一点，刚开始用的时候经常出问题，因为JS那边初始化经常出问题，后来才知道是因为代码执行顺序的问题，init还没走完就调了APP的方法，这种情况在web前端有新人入职的时候出现的最多。

最终我们选择的是【3】，尽管它不支持return，但是callback起码可以完成所有需求，只是有时候没有return用的爽而已。至于初始化代码复杂的问题，坑踩过一遍也就过去了，之后都是顺风顺水的。

APP与JS的交互确实是很多坑，越深入越觉得坑，以后有新发现了再和大家一起分享，本系列也就到此为止了，谢谢所有耐着性子看完的同学，哈哈~~

App与Js交互（三）Android、iOS通用解决方案推荐

目录

示例代码

正文

技术选型的几项原则

一点推荐

写在最后