应用和人不一样，它没有眼睛，没有手脚，没法先用眼睛定位想要调起的应用，再点击调起。  

现在完全自我封闭的应用很少了，大部分应用或多或少和其它应用有一些互动，这就是我们平常说的互相调用。调用的操作我们平时用的很多，比如一个应用需要登录，上面有个按钮提示可以用QQ账号快速登录，如果你安装了QQ，那么这个应用会调用QQ的快速登录界面，确认后，QQ会回调到原来的应用，同时将登录的状态返回给了原应用，又或者你拍了一张逗比的照片想发出去让大家乐乐，于是你点击了照片应用中的分享，选择了朋友圈，于是微信的朋友圈被调起，并将这张图片发了出去，并询问你是返回原应用还是留在微信，如果你选择了返回原应用，那么原来的应用又会被调起。  

过程看起来都很自然，即使是平台不同，整体流程也趋向一致，相互调用的原理是什么呢？  

应用和人不一样，它没有眼睛，没有手脚，没法先用眼睛定位想要调起的应用，再点击调起。宿主系统就像一个有格子收纳盒，每个格子里放一个应用，这些应用被宿主程序相互隔离开，是不知道彼此的存在的，如果需要互相传递信息也是需要通过宿主系统代劳的。在这种规则下，分享一张图片就会变成生活中类似下面的场景：  

张三说：“李四，把这张照片给王五，让他发到圈子里”  

李四找到王五，把照片给王五，同时说：“张三让你把这张图片发圈子里”  

王五发了照片后，对李四说：“你回去告诉张三，照片已经发了”  

李四又找到张三，说“照片已经发了”  

这个过程很简单，但是如果我们仔细想想，还是有些问题，首先张三怎么知道有王五这个人，又怎么知道他会发照片？在这里李四就是系统，先于张三和王五存在，新人王五入驻时，如果希望别人通过李四找到自己，就要把自己的名字告诉李四，一并告诉的还有自己的能力，比如发照片。这个过程相当于应用在系统中注册自己，通常应用公布自己的能力的方式是注册Scheme，我们最常见的Scheme就是http:了，声明了这个Scheme的应用声称自己支持http协议，能够打开网页了（不过实际能不能打开，鬼知道），还有一些常见的Scheme比如file:，tel:等，当然，应用不仅可以声明这些标准的Scheme，也能声明自己独有的Scheme，比如微信的就是weixin:，QQ的是mqq:，那如果多个应用都声明相同的Scheme呢？比如王五说自己会发照片，赵六也说自己会发照片，这时系统会有一定的策略来保证公平性，比如Android上，系统就会弹出支持的应用列表，让用户选择，IOS则替用户选择最近打开过的支持应用。  

一般情况下，出现重复的Scheme都是http:，file:，这种标准型的，因为很多三方的浏览器或是文件管理系统本来就是干这个的，互相竞争Scheme也是合理的，但是有些应用则心怀不轨，故意声明别的应用的特有Scheme，如果防范不到位，就很容易被系统的选择策略（或者出现了选择性弹框，或者自动打开）分走部分流量，或者出现一些恶意调用。  

理解了调用的方法，那么后面数据传递就很简单了，只需要在Scheme后面携带上需要传递的信息就可以了，比如：wangwu://action=sendphoto,photopath=xxxx，后面的数据最终会带到声明wangwu这个Scheme的应用中，但是王五收到了信息并不知道是谁发的，该回信息给谁，那么怎么回调呢，也很简单，发起调用的张三在Scheme后面的参数加一个backScheme=zhangsan:，这样王五就知道了如果需要回信息，则构造一个zhangsan://xxxxxx，这种自定协议可以叫做伪协议，这些字段也不是规定死的，只要交互双方自己能识别处理就行。脑洞一下，如果backScheme里面填的不是调用方Scheme，而是另一个应用的Scheme，又能做些什么呢？  

当然，不同平台也有自己一些独特的应用交互方式，只不过用Scheme这种更标准的方式可以减少一些跨平台开发适配的成本，同时也有利于网页和Native之间的相互调用。