緣起

隨著 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 模式實例化：

// 設置schemeNameval 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 跳轉的設計與實現內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！