客户端Scheme唤起方案

一、基础定义设计

定义一些基本的定义和规则。

1. 1 Scheme 唤起定义：

客户端的Scheme唤起是一种通过特定的URI（统一资源标识符）模式来启动应用程序的技术。这种方法允许一个应用（比如网页或另一个移动应用）通过指定一个自定义的URL（比如yourapp://path?query）来直接打开另一个应用，并且可以传递数据或指令。这个URL的结构由两部分组成：scheme和path/query，其中scheme是用于标识应用的唯一标识符，而后面的部分用于指定要执行的特定操作或传递的数据。使用Scheme唤起机制可以提高应用间交互的流畅性和用户体验，常见于支付、分享、登录等场景。

1.2 Scheme 规则设计

Scheme格式：sccba[BID]://***

业务增加来源标志字段：emas_origin

来源类型（业务同步梳理）：

share_xxx
...

二、流程设计

在原有的唤起流程的基础上，做了些许改动。

2.1 原流程

2.2 修改后的流程

修改点：

1、简化唤起流程：尽量做到业务直达，避免业务操作中断，针对唤起操作，不再展示引导页、广告页，直达首页。需业务产品确认。
2、统一唤起流程：唤起后，无论冷启动还是热启动，统一回到首页，重置3、4号容器，统一通知给1号容器转发（特别的，对于 push 消息采用同样方案），便捷 H5 使用。

注意：

业务上务必关注修改点2，评估好影响！

三、安全设计

3.1 避免未知应用唤起（业务&客户端共同建设）

3.1.1 白名单机制

客户端通过管控配置文件，校验唤起来源，对未知来源的唤起进行上送APM上送处理，通过告警跟踪处理。

3.1.2 动态令牌验证

通过与授权服务器请求和验证令牌来验证身份，大致的业务逻辑如下：

3.2 通信内容安全

可信任客户端级别，客户端内解密

此类一般针对通过客户端分享的静态页面，通过静态页面再唤起客户端时不携带敏感信息的场景，业务前端把固定参数，客户端通过对称加密算法进行解密，确保非明文传递。

此方案安全防护能力较低，目前金融小店的唤起采用此方案。

3.3 埋点与监控

对所有唤起操作进行日志记录和监控，可以有效帮助检测和分析潜在的安全威胁。

全链路上送用户行为分析平台，包括客户端、业务H5端，在相关的路径上同步上送外部唤起埋点。

为后续统计客户端唤起成功率、业务唤起成功率打下基础。

关键节点：

客户端收到 Scheme
客户端解析 Scheme 结果（成功/失败）
客户端通知告知业务 Scheme
业务收到 Scheme
业务处理 Scheme 结果（成功/失败）

上送内容：

Scheme 对应的 URI（注：包含来源信息，origin）
相关状态信息（receive state、handle state）

埋点控制：

使用用户行为分析进行埋点，不要使用听云！
针对客户端的埋点系统，做整体评估，增加系统级开关配置

3.4 隐私合规

对于唤起时（尤其是用户已安装未打开的场景），应在隐私政策同意后进行业务逻辑处理，避免由此引发隐私不合规事件。

目前Scheme唤起集成于启动流程中，不存在在隐私政策同意前就处理业务的情况。

但，在后面简化唤起流程的场景中，务必要注意此情况。

四、用户体验设计

4.1 流程简化

简化唤起流程，尽量做到业务直达，避免业务操作中断。

参考 2.2 小节。

4.2 错误处理机制（业务&客户端共同完善）

设计详细的错误处理机制，当调用失败或发生错误时，能给用户清晰的指引和反馈。

1、明确错误信息

客户端、业务H5要把全路径唤起的错误信息进行明确，提供清晰、易于理解的错误信息，避免使用技术性强的术语。

2、提供具体的解决方案

在业务上，要针对场景对未能成功唤起的场景提出切实的解决方案来告知用户。

3、错误日志记录

在后台记录详细的错误日志，便于开发团队追踪、分析和修复问题。

五、测试

1、要关注客户端首次、非首次启动场景
2、对于冷启动、热启动要多次验证，例如热启动中开启 3号、4 号、二楼、登录容器等表现是否正常
3、合规验证，避免触发隐私政策问题
4、要验证是否有操作系统差异（Android/iOS），避免表现不一致
5、埋点验证，埋点信息准确度、各种场景的覆盖度等
6、PUSH 场景、Shortcut（桌面快捷入口）场景，涉及到冷启、热启等
7、其他安全类验证

六、其他

后续关注鸿蒙系统的Scheme唤起流程。