前言

最近在搞URL Scheme数据还原相关代码的重构工作，借此梳理一下整体的流程。并且在重构过程中呢，还遇到了一个天坑，拿出来与大家分享一下。如果大家有更好的方案，欢迎评论或私信我让我学习一下~

前置知识点

首先我们对齐一下所需要的前置知识点，避免后面造成理解上的冲突。

URL Scheme

URL Scheme指的是遵守以下格式的URL：

{scheme://action?param1=value1&param2=value2...}

APP识别到URL Scheme数据后，会根据action去执行相应的逻辑。

scheme通常由业务定义好，一般以app层级划分或业务域层级划分，比如"taobao://"、"douyin://"，或者"tbSearch://"、"douyinSearch://"。action指的是行为，比如"user/detail"是打开个人详情页面，"item/detail"是打开商品详情页面等。再由后面的参数决定具体的页面数据。举个例子：

{wodeApp://user/detail?userId=123}

wodeApp识别到这个Url Scheme以wodeApp开头，就知道是它需要的数据，进而解析数据，打开userId为123的用户页面。

URL Scheme来源

Scheme数据的来源可以有很多，最常见的就是剪贴板、H5页面唤端、消息通知唤端、短信通知唤端等。因为后面的内容会涉及到数据来源，场景又比较复杂可能会比较混乱，所以这里我们先理清一下。

我们把所有的唤端（包括H5页面唤端、消息通知唤端、短信通知唤端）统一一下，都称为Intent唤端，因为他们最终给到App的数据都是放在Intent中的，所以后面讲到唤端就不再一一区分了。

那么我们现在能拿到URL Scheme的场景就分为四种：

冷启动时从剪贴板获取
热启动时从剪贴板获取
冷启动时从唤端Intent中获取
热启动时从唤端Intent中获取

为什么要分冷热启动呢？因为冷热启动，URL Scheme获取的方式是不一样的，具体后面会说到。

数据还原

数据还原，在产品上是非常重要的。最基本的一种数据还原，就是跳转目标页面。比如用户被消息推送了某个商品，点击进来后根据解析得到的Scheme数据我们需要跳转到指定的商品详情页面。另外，我们可能还需要根据解析的Scheme数据向服务端发起某个请求，比如从平价商品页面唤端来的用户我们需要打上用户标签。

所有的根据action指定的业务逻辑，我们都称之为数据还原。

产品的迭代历程

上面也讲到了，我是因为重构才有机会写这篇文章的。那为什么要重构呢？自然是代码hold不住产品的迭代速度了，这就要从产品的需求讲起。（当然，需求的迭代只是重构的原因之一，更主要的原因是之前的代码没封装，写的很乱，职责不清晰，所以才把重构提上日程的..）

有一天，PD找上门来
PD:咱们做个简单的唤端哈，从消息通知进来，或者从H5页面唤端进来，我们能打开相应的页面就行。另外，如果剪贴板里有这样的数据，也要能达到一样的效果。

程序员A：没问题，这项技术已经很成熟了，马上给你搞出来

最终这个需求的实现，也基本上不存在什么问题。唤端的Intent数据从闪屏页拿到后，传递到首页，首页再根据数据执行相应的Action。另外在首页onResume生命周期中获取剪贴板数据，如果符合Scheme数据协议，也去做相应的Action。

过了一个月，PD又找上门来
PD：咱们唤端需要再做一个通用能力哈。如果唤端数据带了某个api的某个参数，需要在下次请求这个api的时候把这个参数给带上，从而满足服务端数据的定制化能力。当然了，还是跟上次一样，如果剪贴板里有这样的数据，也要能达到一样的效果。

程序员A:为啥要这样搞啊？有啥用？

PD：你想啊，比如首页的推荐流理论上对每个人都是不一样的。那如何实现更精准地推送呢？唤端就是一个手段。每个唤端页面唤端的时候，都带上用户相关的数据，然后把这份数据作为接口参数传给服务端，不就可以实现定向推送了嘛。

程序员A:你很有想法，但是我得想一想...

糟了，之前的剪贴板相关的代码要重写了。为什么呢？因为之前是在首页onResume生命周期中获取剪贴板数据，如果剪贴板数据符合Scheme数据协议，就去做相应的Action。但这个新的需求，又必须保证得在首页请求发出去之前，就要拿到剪贴板数据并预埋好接口参数，否则就不会起作用了。比如用户冷启App时，如果不在闪屏页预先拿到剪贴板数据并预埋上首页的接口参数的话，到首页做这个逻辑就没法保证是在首页接口请求前完成参数的预埋了。

那这个逻辑是要放在闪屏页么？也不对，因为在热启App时，是不会经过闪屏页的，但热启时也要有这样的能力，这就要我们必须把解析剪贴板的这段逻辑放在BaseActivity中去。

下面就来分享一下URL Scheme数据还原改善后的流程。

数据还原流程

剪贴板

冷启：闪屏页onWindowFocusChanged获取剪贴板数据->解析scheme数据（执行预埋接口参数等Action）->跳转首页->首页跳转至目标页面->清空剪贴板

热启：BaseActivity#onWindowFocusChanged获取剪贴板数据->解析（执行预埋接口参数等Action）->跳转目标页面->清空剪贴板

因为某些原因，我们的项目中闪屏页没有继承BaseActivity，所以这里分开了两个部分。如果大家都是统一继承BaseActivity的，那么这部分解析scheme的逻辑是可以合二为一的。

唤端

冷启：闪屏页onCreate获取唤端Intent->解析scheme数据（执行预埋接口参数等Action）->跳转首页->首页跳转至目标页面->清空剪贴板

热启：闪屏页onCreate获取唤端Intent->解析scheme数据（执行预埋接口参数等Action）->跳转目标页面->清空剪贴板

总结

唤端的逻辑全部在闪屏页的onCreate生命周期做。只有在冷启唤端时需要先跳转至首页，首页再跳转至模板页面。
剪贴板的逻辑，冷启时在闪屏页做剪贴板的获取与解析，热启时在页面基类做剪贴板的获取与解析，解析完数据后统一在页面基类进行目标页面的跳转。之所以放在页面基类而不是首页，是因为热启回APP后可能处于任意一个页面，所以这段逻辑只能放到基类里面去处理。

另外需要注意的一点是，闪屏页的LaunchMode需要设置为singleTask，否则唤端启动时新创建的闪屏页会到浏览器的栈去，不符合业务需求。

踩坑分享

在这个过程中，我也踩了一个大坑..没想到Android对剪贴板的获取有这样的限制。细心的同学可能已经发现了，在重构前我们是在首页的onResume生命周期去获取剪贴板的，去网上一搜获取剪贴板数据，大部分的回答都是这样：

override fun onResume() {
    window.decorView.post{
        val content = ClipboardService.getInstance().clipboardContent
    }
}

那为什么在方案设计中，却是在onWindowFocusChanged回调中才去获取剪贴板数据呢？因为上面的代码，在部分场景（尤其是闪屏页），是没法保证能拿到剪贴板数据的。

原因

Android获取剪贴板存在限制，必须在当前Activity获得焦点的情况下才能成功获取到。

闪屏页的生命周期：onCreate->onResume->跳转页面->onPause

闪屏页获取焦点时的回调：onWindowFocusChanged(boolean hasFocus)；当回调中hasFocus收到true时，表面当前Activity窗口获取到了焦点。

经试验，当闪屏页跳转页面过快，部分机型（如Redmi k40 pro）onWindowFocusChanged会回调false，收不到true，即一直没有获得过焦点，那么这种情况下就无法获取剪贴板数据（拿到是空字符串）。所以获取剪贴板数据的时机，不能太早，也不能太晚。不能在onCreate中去获取剪贴板数据，也不能等到发生跳转了再去拿。

其次，因为onWindowFocusChanged回调时机必在onResume之后，所以即使我们在onResume中post去拿剪贴板，我们也没法保证post的Runnable执行的时机是正正好的。有可能Runnable执行时，闪屏页已经发生跳转了。也有可能Runnable执行时，闪屏页还未获取到焦点。

所以呢，我们应该把获取剪贴板数据的时机放到onWindowFocusChanged中去，而闪屏页冷启跳转首页的逻辑，也要放到onWindowFocusChanged之后，保证闪屏页已经获取到焦点了，且成功获取到剪贴板数据了。

总结

通过这篇文章，我们知道了URL Scheme数据还原的整体流程。如果大家实际业务中没有类似“根据唤端数据，预埋首页接口参数”这样的需求，其实可以比较简单地就实现了。另外，分享了一下Android上获取剪贴板数据所存在的限制，以及在实际业务中遇到的坑该怎么解决。

文章不足之处，还望大家多多海涵，多多指点，先行谢过！

参考文章

juejin.cn/post/684490… # Android 外部唤起应用跳转指定页面

juejin.cn/post/702840… # 闲鱼唤端的背后

Android URL Scheme数据还原流程与踩坑分享

前言