iOS/Android 微信及浏览器中唤起本地APP

正文

请到「今天看啥」查看全文

< intent-filter >
< action android:name = "android.intent.action.MAIN" />
< category android:name = "android.intent.category.LAUNCHER" />
intent-filter >

< intent-filter >
< action android:name = "android.intent.action.VIEW" />
< category android:name = "android.intent.category.DEFAULT" />
< category android:name = "android.intent.category.BROWSABLE" />
< data android:scheme = "mls" />
intent-filter >

理论上，在 Android 上这两种方式应该都是可以顺利实现的。但是 Android 的 chrome 内核从 chrome 25 以后就弃用了 iframe，不再支持通过 js 触发（非人为点击）或者通过设置  iframe src  地址来触发 scheme 跳转。所以，后一种方法在适配上存在比较多的问题。故一般选择前面一种做法，即 href 的点击或者 window.location 跳转。

使用第一种方案，setTimeOut 派上用场。

$('a').click(function() {
    location.href = '自定义 URL scheme';
    t = Date.now();
    setTimeout(function(){
        if (Date.now() - t < 1200) {
            location.href = 'Android 下载地址';
        }
    }, 1000);
    return false;
    }
}

理想过程是这样：浏览器尝试打开 URL scheme，在 1 秒计时后，检查当前时间，如果实际时间已过 1200 毫秒，说明唤起 app 成功（唤起 app 会让浏览器的定时器变慢）；如果没超过 1200 毫秒，很可能是没有安装应用，就跳到下载地址。

但是这么做也是有问题的，因为 Android 系统是多任务系统，setTimeOut基本就没那么精准，不能起到理想效果。换一种方式， setInterval ，如果设置比较小的运行间隔（<30ms），在浏览器或者 webview 中，应用切换到后台，setInterval 会被很明显的延迟执行，比如设置一个运行间隔 20ms，总计运行 100 次的定时器，如果页面一直处于前台，则 100 次跑完，总耗时与 100×20=2000ms 不会有太大差异，但页面在后台运行时，此时间会明显超过 2000ms。可以利用这一点来实现是否成功打开 app 检测及回调。

function openApp(openUrl, appUrl, action, callback

请到「今天看啥」查看全文