Android scheme 跳转的设计与实现详解

程序员文章站 2023-11-06 17:49:04

缘起随着 app 的成长，我们难免会遇到以下这些需求： h5 跳原生界面 notification 点击调相关界面根据后台返回数据跳转界面，例如登录成功后跳不同界面或者根据运营需求跳不同界面...

缘起

随着 app 的成长，我们难免会遇到以下这些需求：

h5 跳原生界面
notification 点击调相关界面
根据后台返回数据跳转界面，例如登录成功后跳不同界面或者根据运营需求跳不同界面
实现 applink 的跳转

为了解决这些问题，app 一般都会自定义一个 scheme 跳转协议，多端都实现这个协议，以此来解决各种运营需求。今天就来解析下qmui最新版qmuischemehandler的设计与实现。

一个 scheme 的格式大概是这样子：

schemename://action?param1=value1¶m2=value2

例如：

qmui://home?tab=2

从技术角度来讲，实现 scheme 的跳转并不是件很难的事情，就是下面两个步骤：

解析 scheme
根据解析结果跳转指定界面

但是写代码时如果不加以设计，就容易是堆一堆的 if else。例如：

if(action=="action1"){ 
 doaction1(params)
}else if(action=="action2"){
 doaction2(params)
}else {
 ...
}

每当有新的 scheme 添加时，就去添加一个 if，直到它逐渐变成一段巨长的烂代码，改都改不动。因而我们要勤思考、多重构，尽早通过设计出优良的框架来解放自己的双手。

对于 if else 这类的重构，一个基本的方式就是用查表法，将所有的条件以及其所要执行的行为放在一个 map 里，然后使用时通过去查询这个 map 而获取要执行的行为。而我们可以通过注解配合代码生成的方式构建这个 map，从而减少我们代码的编写量。除此之外，我们还需要考虑各种功能性需求：

可以设置拦截器 interceptor，例如跳某些界面，如果是非登录的状态，可能需要跳转到登录界面
参数可以指定一些基础类型， scheme 所携带的参数的值都是字符串，但我们希望它可以方便的转换成我们需要的基础类型
同一个 action 可以根据参数的不同而有不同的跳转行为，例如都是跳转书籍详情，漫画书籍和普通书籍要跳转的界面可能不一样
如果当前界面已经是目标界面，可以选择刷新当前界面或者启动一个新界面
对于 qmui，是同时支持 activity 和 fragment 的，因而 scheme 也要同时支持这两者
可以自定义新界面的实例化方法

接口设计

任何一个库的开发，为了让业务使用方足够舒心，既要保证库的功能足够强大，也要保证使用的方便性，qmui scheme 对外主要是qmuischemehandler这个入口类，以及activityscheme和fragmentscheme两个注解。

qmuischemehandler

qmuischemehandler通过 builder 模式实例化：

// 设置schemename
val instance = qmuischemehandler.builder("qmui://") 
 // 防止短时间类触发多次相同的scheme跳转
 .blocksameschemetimeout(1000)
 // scheme 参数 decode
 .addinterpolator(new qmuischemeparamvaluedecoder())
 .addinterpolator(...)
 // 默认 fragment 实例化 factory
 .defaultfragmentfactory(...)
 // 默认 activity 实例化 factory
 .defaultintentfactory(...)
 // 默认 scheme 匹配器
 .defaultschemematcher(...)
 .build();

if(!instance.handle("qmui://xxx")){ 
 // scheme 未被 handle，日志记录？
}

大多数场景，qmuischemehandler采用单例模式即可。其可以设置多个拦截器、设置 fragment、activity 的默认实例化工厂、以及默认的匹配器。实例工厂和匹配器都是提供了默认实现的，大多数场景是不需要调用者关心的。而且这里都只是设置全局默认值，到了 scheme 注解那一层，还可以为每个 scheme 指定不同的值，以满足可能的自定义需求。

activityscheme 与 fragmentscheme 注解

这两个注解是非常相似的，但是因为 fragment 有一些更多的配置项，因为独立出来了。

@retention(retentionpolicy.class)
@target(elementtype.type)
public @interface activityscheme { 
 // scheme action 名
 string name();
 // 必须的参数列表，用于支持同一个 action 对应多个 scheme 的场景，每一项可以是"type=4" 来指定值，或者只传"type"来匹配任意值
 string[] required() default {};
 // 如果当前界面就是 scheme 跳转的目标值，可以选择刷新当前界面，当然当前界面必须实现 activityschemerefreshable
 boolean userefreshifcurrentmatched() default false;
 // 自定义当前 scheme 的匹配实现方法， 传值为 qmuischemematcher 的实现
 class<?> custommatcher() default void.class;
 // 自定义当前 activity 实例工厂，传值为 qmuischemeintentfactory
 class<?> customfactory() default void.class;
 // 指定参数的类型，支持 int/bool/long/float/double 这些基础类型，不指定则为 string 类型
 string[] keyswithintvalue() default {};
 string[] keyswithboolvalue() default {};
 string[] keyswithlongvalue() default {};
 string[] keyswithfloatvalue() default {};
 string[] keyswithdoublevalue() default {};
}


@retention(retentionpolicy.class)
@target(elementtype.type)
public @interface fragmentscheme { 
 // 这些参数都同 activityscheme
 string name();
 string[] required() default {};
 class<?> custommatcher() default void.class;
 string[] keyswithintvalue() default {};
 string[] keyswithboolvalue() default {};
 string[] keyswithlongvalue() default {};
 string[] keyswithfloatvalue() default {};
 string[] keyswithdoublevalue() default {};

 //同 activityscheme，但当前ui必须实现 fragmentschemerefreshable
 boolean userefreshifcurrentmatched() default false;

 // 同 activityscheme, 但传值是 qmuischemefragmentfactory 的实现类
 class<?> customfactory() default void.class;
 // 可以承载目标 fragment 的 activity 列表，如果当前 activity 不在列表里，则用 activities 的第一项启动新的 activity
 class<?>[] activities();
 // 是否强制启动新的 activity
 boolean forcenewactivity() default false;
 // 可以通过 scheme 里的参数来控制是否强制启动新的 activity
 string forcenewactivitykey() default ""; 
}

可以看出，我们前面所罗列的各种需求，都在 schemehandler 以及两个 scheme 里体现出来了。

使用

对于业务使用者，我们只需要在activity或者fragment上加上注解。qmuischemehandler默认会将参数解析出来并放到activity的 intent 里或者fragment的 arguments 里，因而我们可以在oncreate里将我们关心的值取出来：

@activityscheme(name="activity1")
class activity1: qmuiactivity{

 override fun oncreate(...){
 ...
 if(isstartedbyscheme()){
  // 通过 intent extra 获取参数的值
  val param1 = getintent().getstringextra(paramname)
 }
 }
}

@fragmentscheme(name="activity1", activities = {qdmainactivity.class})
class fragment1: qmuifragment{ 
 override fun oncreate(...){
 ...
 if(isstartedbyscheme()){
  // 通过 arguments 获取参数的值
  val param1 = getarguments().getstring(paramname)
 }
 }
}

这种传值方法很符合 android 官方设计的做法了，这也要求fragment遵循无参构造器的使用方式。

对于 webview，我们可以通过重写webviewclient#shouldoverrideurlloading来处理 scheme 跳转：

class mywebviewclient: webviewclient{ 
 override fun shouldoverrideurlloading(view: webview, url: string){
  if(schemehandler.handle(url)){
   return true;
  }
  return super.shouldoverrideurlloading(view, url);
 }

 override fun shouldoverrideurlloading(view: webview, request: webresourcerequest){
  if(schemehandler.handle(request.geturl().tostring())){
   return true;
  }
  return super.shouldoverrideurlloading(view, request);
 }
}

实现

qmuischemehandler采用代码生成的方式，在编译期生成一个schememapimpl类，其实现了schememap类

public interface schememap {

 // 通过 action 和参数寻找 schemeitem
 schemeitem findscheme(qmuischemehandler handler, string schemeaction, map<string, string> params);
 // 判断 schemeaction 是否存在
 boolean exists(qmuischemehandler handler, string schemeaction);
}

而每个 scheme 的注解对应一个schemeitem:

activityscheme对应实例化一个activityschemeitem类，并加入到 map 中
fragmentscheme对应实例化一个fragmentschemeitem类，并加入到 map 中

在编译期通过schemeprocessor生成的schememapimpl大概是这样子的：

public class schememapimpl implements schememap { 
 private map<string, list<schemeitem>> mschememap;

 public schememapimpl() {
 mschememap = new hashmap<>();
 list<schemeitem> elements;
 arraymap<string, string> required = null;
 elements = new arraylist<>();
 required =null;
 elements.add(new fragmentschemeitem(qdsliderfragment.class,false,new class[]{qdmainactivity.class},null,false,"",required,null,null,null,null,null,sliderschemematcher.class));
 mschememap.put("slider", elements);

 elements = new arraylist<>();
 required = new arraymap<>();
 required.put("aa", null);
 required.put("bb", "3");
 elements.add(new activityschemeitem(archtestactivity.class,true,null,required,null,new string[]{"aa"},null,null,null,null));
 mschememap.put("arch", elements);

 }

 @override
 public schemeitem findscheme(qmuischemehandler arg0, string arg1, map<string, string> arg2) {
 list<schemeitem> list = mschememap.get(arg1);
 if(list == null || list.isempty()) {
  return null;
 }
 for (int i = 0; i < list.size(); i++) {
  schemeitem item = list.get(i);
  if(item.match(arg0, arg2)) {
  return item;
  }
 }
 return null;
 }

 @override
 public boolean exists(qmuischemehandler arg0, string arg1) {
 return mschememap.containskey(arg1);
 }
}

整体的设计以及实现思路就是这样，剩下的就是各种编码细节了。有兴趣的可以通过qmuischemehandler#handle()进行追踪下，或者看看schemeprocessor是如何做代码生成的。这个功能看上去简单，其实也包括了 builder 模式、责任链模式、工厂方法等设计模式的运用，还有 schemematcher、 schemeitem 等对面向对象的接口、继承、多态等的运用。读一读或许对你有所启迪，或许你也能帮我发现某些潜在的 bug。

总结

到此这篇关于android scheme 跳转的设计与实现的文章就介绍到这了,更多相关android scheme 跳转的设计与实现内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！

Android scheme 跳转的设计与实现详解