缘起
随着 App 的成长,我们难免会遇到以下这些需求:
为了解决这些问题,App 一般都会自定义一个 scheme 跳转协议,多端都实现这个协议,以此来解决各种运营需求。今天就来解析下QMUI最新版QMUISchemeHandler的设计与实现。
一个 scheme 的格式大概是这样子:
schemeName://action?param1=value1¶m2=value2
例如:
qmui://home?tab=2
从技术角度来讲,实现 scheme 的跳转并不是件很难的事情,就是下面两个步骤:
但是写代码时如果不加以设计,就容易是堆一堆的 if else。例如:
if(action=="action1"){ doAction1(params) }else if(action=="action2"){ doAction2(params) }else { ... }
每当有新的 scheme 添加时,就去添加一个 if,直到它逐渐变成一段巨长的烂代码,改都改不动。因而我们要勤思考、多重构,尽早通过设计出优良的框架来解放自己的双手。
对于 if else 这类的重构,一个基本的方式就是用查表法,将所有的条件以及其所要执行的行为放在一个 map 里,然后使用时通过去查询这个 map 而获取要执行的行为。而我们可以通过注解配合代码生成的方式构建这个 map,从而减少我们代码的编写量。除此之外,我们还需要考虑各种功能性需求:
接口设计
任何一个库的开发,为了让业务使用方足够舒心,既要保证库的功能足够强大,也要保证使用的方便性,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:
在编译期通过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 跳转的设计与实现内容请搜索呐喊教程以前的文章或继续浏览下面的相关文章希望大家以后多多支持呐喊教程!
声明:本文内容来源于网络,版权归原作者所有,内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:notice#nhooo.com(发邮件时,请将#更换为@)进行举报,并提供相关证据,一经查实,本站将立刻删除涉嫌侵权内容。