APP之间相互调用并且传输数据经常会出现在实际需求中，我们应该对这样的基本功能的实现原理有一个简单的认识，这样也方便工作中和程序哥哥们的沟通。
在产品设计中，经常会遇到APP之间相互调用的功能设计，比如：
实现三方登录。用 *** 账号快速登录，如果安装了 *** ，那么应用会调用 *** 的快速登录界面，确认后， *** 会回调到原来的应用，同时将登录的状态信息返回给了原应用。实现分享。选择应用内的可分享内容，点击分享， 选择朋友圈，于是微信的朋友圈被调起，并将这张图片发了出去，并询问你是返回原应用还是留在微信，如果你选择了返回原应用，那么原来的应用又会被调起。实现第三方支付。选择应用内要支付的内容，选择支付方式，一般会提供支付宝或微信，点击后跳转到支付宝或微信的付款页面，完成支付后回到该应用。实现手机网页引导并打开应用功能。在推广的H5页面上，加入打开APP的按钮，点击后直接调起我们的APP，并且可以根据参数信息， 在本地应用中还原用户的浏览场景。这些过程实现的原理就是利用 URL Scheme。
什么是URL Scheme
URL Scheme就是一个可以让app相互之间可以跳转的协议。每个app的URL Scheme都是不一样的，如果存在一样的URL Scheme，那么系统就会响应先安装那个app的URL Scheme，因为后安装的app的URL Scheme被覆盖掉了，是不能被调用的。
应用之间跳转原理
一个应用能打开另一个应用的必然条件是，另一个应用必须配置一个scheme（协议），这样应用程序才能根据协议找到需要打开的应用。
APP应用在系统中通过注册Scheme的方式注册自己，常见的Scheme就是 http:，声明了这个Scheme的应用就是声称自己支持http协议，能够打开网页了。还有一些常见的Scheme比如 file:（传输文本）， tel:（通话）等。
当然，APP应用不仅可以声明这些标准的Scheme，也能声明自己独有的Scheme，比如微信的就是 weixin:， *** 的是 mqq: 。
如果多个应用都声明相同的Scheme呢？比如应用a、b、c都声明自己能发短信，这时系统会有一定的策略来保证公平性，比如在Android系统中，就会弹出支持的应用列表，让用户选择， iOS则替用户选择近打开过的支持应用。
应用之间传递数据
了解了应用之间调用的 *** ，那么后面数据传递就简单了，只需要在Scheme后面携带上需要传递的信息作为参数就可以了。
比如，发起调用的是应用A，被调用的是应用B。yingyongB://action=sendmessage,message=”xxx”，后面的数据会带到应用B中，但是应用B接到了信息不知道该信息是哪个应用发的，回信息给哪个应用。如何进行回调呢？发起调用的应用A在Scheme后面加一个参数backScheme=yingyongA: ，这样应用B就知道了需要返回信息给应用A，应用A和B这种自定义协议也可以叫做伪协议，只要双方应用能识别处理就可以。
同样，我们也可以实现跳转到指定页面的功能。想要跳转到指定界面，必定是上一个app告诉下一个app（被跳转的app）需要跳转到哪个界面，而如何告诉它这里便涉及到两个app的通信。两个app之间的跳转只需要配置一个Scheme，通过协议即可实现。
最后上一段iOS测试代码：
//进入更多界面（上一个APP）
– (IBAction)intoMore:(id)sender {
NSURL *url = [NSURL URLWithString:@”test://more”] //test://more是要跳转的页面名称
if ([[UIApplication sharedApplication] canOpenURL:url]) {
[[UIApplication sharedApplication] openURL:url] //是否安装应用，url是跳转页面的地址
}else{
NSLog(@”没有安装应用”) //没有安装则提示相应信息
}
}
在被调用的APP中，就会监听 *** ，对进入的页面进行判断。
总结
以上就是应用之间进行交互原理的简单总结，不同平台会有自己一些独特的应用交互方式，用Scheme这种方式可以减少一些跨平台开发适配的成本，同时也有利于网页和Native之间的相互调用。
作者：流年，互联网产品设计师，4年互联网产品设计经验。
本文由 @流年 原创发布于人人都是产品经理。未经许可，禁止转载。
app实现交互功能的内涵 app交互问题分析
