android跨应用调用方法是,Android 跨应用间调用: URL Scheme

在Android开发中，不同Activity之间的跳转和切换是很常见的，这使得APP的内容更加丰富，功能更为多样，但是一个应用所能包括的功能毕竟有限，在很多的场景下需要跨应用调用，比如在应用中跳转到微信支付的页面，或者使用第三方账号登陆时跳转到QQ登陆等等。这样的情况下，要跳转的Activity或者Application是第三方开发的，很可能不知道要具体跳转到哪一个Activity中，或者直接跳转并不安全，诸如这些问题都需要在跨应用间调用时被周全地考虑到。为了更好地解决这一问题，下面就来介绍Android中的URL Scheme协议

URL Scheme简介

Android中的自定义的URL Scheme是一种页面内跳转协议，也可以被称为URLRouter，就是通过类似打开网页的方式去通过路由打开一个Activity，而非直接通过显式Intent方式去进行跳转。这样隐式intent的方法跳转好处如下：

降低耦合性：不需要知道具体要跳转哪个界面，只需要根据需求，按照约定好的URL路由协议发送Intent即可；

更为安全：不显示Intent跳转，只要是符合协议的Intent都会有对应的Activity来匹配，避免了跳转到不该出现的页面；

更为灵活： 有着更为广泛的应用场景，一下场景中都可以使用URL Scheme

服务器下发跳转路径，客户端根据服务器下发跳转路径跳转相应的页面

H5页面点击锚点，根据锚点具体跳转路径APP端跳转具体的页面

APP端收到服务器端下发的PUSH通知栏消息，根据消息的点击跳转路径跳转相关页面

APP根据URL跳转到另外一个APP指定页面

URL Scheme协议格式

上文已经说过，URL Scheme是就通过类似打开网页的方式去通过路由打开一个Activity，其协议格式和我们打开网页输入的网址类似。

一个完整的完整的URL Scheme协议格式由scheme、host、port、path和query组成，其结构如下所示：

://:/?

其中scheme既可以是Android中常见的协议，也可以是我们自定义的协议。Android中常见的协议包括content协议、http协议、file协议等，自定义协议可以使用自定义的字符串，当我们启动第三方的应用时候，多是使用自定义协议。

如下是一个自定义协议的URI：

通过上面的路径 Scheme、Host、port、path、query全部包含:

xl，即为Scheme，代表该Scheme 协议名称

goods，即为Host，代表Scheme作用于哪个地址域

8888，即为port，代表该路径的端口号

goodsDetail，即为path， 代表Scheme指定的页面

goodsId，即为query，代表传递的参数

URL Scheme的使用方法

URL Scheme的使用方法简要言之就是先在manifest中配置能接受Scheme方式启动的activity；当需要调用时，将Scheme协议的URi以Data的形式加入到Intent中，隐式调用该activity。

1). 在AndroidManifest.xml中对标签增加设置Scheme

android:host="auth_activity">

上面的设置中可以看到，MainActivity包含多个设置，第一个是正常的启动，也就是在应用列表中启动；第二个是通过URL Scheme方式启动，其本身也是隐式Intent调用的一种，不同在于添加了属性，定义了其接受URL Scheme协议格式为

这里需要说明下，URL Scheme协议格式中，组成URI的这些属性在标签中都是可选的 ，但存在如下的依赖关系：

如果没有指定scheme，那么host参数会被忽略

如果没有指定host，那么port参数会被忽略

如果scheme和host都没有指定，path参数会被忽略

当我们将intent对象中的Uri参数与intent-filter中的标签指定的URI格式进行对比时，我们只对比intent-filter的标签指定的部分，例如：

如果intent-filter中只指定了scheme，那么所有带有该sheme的URI都能匹配到该intent-filter。

如果intent-filter中只指定了scheme和authority(authority包括host和port两部分)而没有指定path，那么所有具有相同scheme和authority的URI都能匹配到该intent-filter，而不用考虑path为何值。

如果intent-filter中同时指定了scheme、authority和path，那么只有具有相同scheme、authority和path的URI才能匹配到该intent-filter。

需要注意的是，intent-filter的标签在指定path的值时，可以在里面使用通配符*，起到部分匹配的效果。

2). 使用URL启动Activity

Uri data = Uri.parse("urlschemel://auth_activity");

Intent intent = new Intent(Intent.ACTION_VIEW,data);

//保证新启动的APP有单独的堆栈，如果希望新启动的APP和原有APP使用同一个堆栈则去掉该项

intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

try {

startActivityForResult(intent, RESULT_OK);

} catch (Exception e) {

e.printStackTrace();

Toast.makeText(MainActivity.this, "没有匹配的APP，请下载安装",Toast.LENGTH_SHORT).show();

}

当然可以在网页中调用

打开新的应用

或者是在JS中调用

window.location = "urlschemel://auth_activity";

3.)如何判断URL Scheme是否有效

boolean checkUrlScheme(Intent intent){

PackageManager packageManager = getPackageManager();

List activities = packageManager.queryIntentActivities(intent, 0);

return !activities.isEmpty();

}

将子APP在Home Launcher中隐藏

有时候需要把一些辅助性的、较为独立的APP在Home Launcher中隐藏起来，只允许一些特定的APP调用。这个时候，我们可以利用URL Scheme协议来做到这一点，设置AndroidManifest.xml中对标签如下

android:host="auth_activity">

因为Home Launcher列出的应用图标要求必须有Activity同时满足

上面的配置中有多余的category和data限制存在，所以并不匹配，不会在Home Launcher出现，但是可以使用URL Scheme来启动。

Uri data = Uri.parse("urlschemel://auth_activity");

Intent intent = new Intent(Intent.ACTION_MAIN,data);

intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

这样就可以将一组APP设置一个统一的入口，然后根据实际需要在调用不同子APP，即所谓的APP业务组件化，URL Scheme在其中有着重要的作用，更进一步讨论会在以后的文章中呈现，敬请期待。