Android组件化架构 —— 基础(四) URL Scheme

xwzz.jpg

前篇回顾

  • Android组件化 —— 基础(一) - 组件化与集成化
  • Android组件化 —— 基础(二) - 组件间通讯
  • Android组件化 —— 基础(三) - ARouter

前篇,我们了解了ARouter路由的基本功能及其内部原理。至此,我们已完成Android APP组件化架构的搭建,并解决了组件间的通讯问题。
但,正如上述描述,我们仅是解决了Android APP内部组件通讯。实际开发中,通讯不仅涉及Android APP内部,往往还涉及到一些外部使用场景,如:

  • 1、接口路由下发,动态页面跳转或功能调起
  • 2、外部APP唤起咱们APP的页面或功能
  • 3、Web H5 js调用APP的页面或功能

这些场景并不属Android APP独有,iOS、H5、后台接口都涉及在内,需各端相互配合才能完成上述场景的相关功能,那么各端之间统一的通讯规则就显得尤为重要,URL Scheme或许是不二之选。

URL Scheme

一个正常的Url链接是这样的:

https://www.baidu.com?key=hello

它是由scheme协议头、host域名、path路径、query参数4个部分组成

[scheme:][host][path][?query] 

无论是Android,还是iOS都支持开发人员为自身APP注册自定义的URL Scheme,便于其它APP与之通讯。

如何设计一个满足我们业务场景需求的URL是我们首先要解决的问题,通过上面3个场景需求的分析,设计的URL无非就是将 “页面跳转”“功能调用” 这两个需求高效或者说显著的表示出来。

ARouter的URL Scheme

前篇,ARouter中有提到其是支持标准URL Scheme跳转的,我们先尝试直接使用ARouter看是否能满足我们的需求,以第2个场景为例,由外部APP唤起user模块的UserMainActivity和isLogin()功能。

  • ARouter - 标准的页面跳转URL定义
页面路由:example://www.demo.com/user/UserMainActivity

上面是我定义的跳转UserMainActivity路由,只需在AndroidManifest.xml中注册这个Scheme,再由ARouter完成跳转。

        
          
            ...

            
                

                

                
                
            

        
// Activity
class AppMainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        handUri();
    }

    private fun handUri() {
        val uri: Uri? = intent.data
        if (uri != null) {
            // 交给ARouter处理
            ARouter.getInstance().build(uri).navigation()
        }
    }
}

外部,我使用浏览器来唤起我们的APP

跳转APP

测试下:


ARouter标准Url跳转页面
  • ARouter - 标准的功能调用URL定义
功能路由:example://www.demo.com/user/isLogin

可当我按照标准的URL规范去定义功能调用url时,ARouter并不会明白这个url所表达的意义。通过查看源码我们会发现ARouter会将url中path部分作为它自身的路由部分来处理后续逻辑。

final class _ARouter {

    ...

    protected Postcard build(Uri uri) {
        if (null == uri || TextUtils.isEmpty(uri.toString())) {
            throw new HandlerException(Consts.TAG + "Parameter invalid!");
        } else {
            PathReplaceService pService = ARouter.getInstance().navigation(PathReplaceService.class);
            if (null != pService) {
                uri = pService.forUri(uri);
            }
            //url的path会作为ARouter的path进行处理
            return new Postcard(uri.getPath(), extractGroup(uri.getPath()), uri, null);
        }
    }

}

显然,功能路由的/user/isLogin是无法匹配到路由的,还记得ARouter跨模块功能调用提供的路由是谁的吗?没错Servcie!一个Service下可能存在多个功能,而isLogin()只是其中一个。我们通过路由也仅仅能拿到Service对象,如果想要通过url调到具体的service内部功能,还要编写大量的代码来进行匹配,并且这样的代码维护性是很差的。

因此,我个人不建议直接将URL Scheme交给ARouter来处理,ARouter只需做好本职APP内部通讯即可,对于Url的处理可以由上层造轮子交给它解析后,再由ARouter来完成跳转或者功能调用。

自定义URL Scheme

既然,Url需交给上层轮子来处理,那么对于Url的定义也就无需参考ARouter规范约束,实际开发中Url的定义往往也不会理想化的完全按照ARouter要求来设计,毕竟适合多端协作的Url才是好的Url,下面以我定义的Url格式为例,开始制造这个轮子。

example://www.demo.com/openApp?action={
     "action_type":"jump" ,                     // 动作类型  跳转(jump) 或 功能(call)
     "page_type":"native" ,                     // 跳转的页面类型  native  web  rn  flutter
     "path":"/user/UserMainActivity" ,          // 实际路由地址
     "params":"{ \"key\" : \"value\" }"          // 携带参数 
}

可以看到[scheme:][host][path]这三部分是固定不变的,涉及业务逻辑都由参数action字段来决定,action主要由四部分组成:

  • action_type : 标识路由动作,jump(页面跳转) ,call(功能调起)
  • page_type : 当路由动作为jump时,标识页面跳转目标类型,native (App原生页面),web(H5页面),rn(RN页面),flutter(Flutter页面)
  • path : 实际的路由地址
  • params : 目标页面或功能所需参数

这四部分基本可以满足页面跳转和功能调起需求了,action对应的Bean对象如下:

data class RouterAction(
    var action_type: String? = "",    // 行为类型:  jump (跳转页面) 、 call (调用功能)
    var page_type: String? = "",      // 页面类型:  native (原生页面) 、 web (H5) 、rn(RN)、 flutter(Flutter)
    var path: String? = "",           // 路由地址:  /search/SearchActivity
    var params: JsonObject? = null    // 路由目标需要的参数: "{ key : value }"
)

自定义页面跳转 Url

OK,有了路由规则,来看看页面跳转现在的路由是什么样?

页面路由:
example://www.demo.com/openApp?action={"action_type":"jump" ,"page_type":"native","path":"/user/UserMainActivity" , "params":"{}" }

有了路由,开始完成文章开篇时提到的三个场景吧!

场景1:接口路由下发,动态页面跳转

这是一个很常见的场景,例如:
订单详情页底部按钮,在不同的订单状态下会显示不同的业务逻辑按钮(申请退款、取消订单、评价、联系客服等),以往这些按钮的显示规则都由移动开发人员写死在客户端代码里,一旦订单业务进行调整,原显示规则发生改变,就需修改客户端代码,诺流程影响过大,甚至需开启强更发版。
现在有了路由,这些显示规则都可搬移至服务端,由后台开发人员动态返回。

下面我将模拟接口返回路由场景,涉及JSON数据如下:

{
    "btnBgColor":"#FF0000",
    "btnColor":"#FFFFFF",
    "btnTxt":"跳转User页面",
    "openUrl":"example://www.demo.com/openApp?action\u003d{\"action_type\":\"jump\" ,\"page_type\":\"native\",\"path\":\"/user/UserMainActivity\" , \"params\":{} }"
}

模拟请求代码:

    private fun getBtnForNet() {
        Thread {
            Thread.sleep(1500)
            val json = "{\"btnBgColor\":\"#FF0000\",\"btnColor\":\"#FFFFFF\",\"btnTxt\":\"跳转User页面\",\"openUrl\":\"example://www.demo.com/openApp?action\\u003d{\\\"action_type\\\":\\\"jump\\\" ,\\\"page_type\\\":\\\"native\\\",\\\"path\\\":\\\"/user/UserMainActivity\\\" , \\\"params\\\":{} }\"}"
            runOnUiThread {
                showButton(JsonParser.fromJsonObj(json, ButtonBean::class.java))
            }
        }.start()
    }

    private fun showButton(btnBean: ButtonBean) {
        val button = Button(this)
        btnBean.btnColor?.run {
            button.setTextColor(Color.parseColor(this))
        }
        btnBean.btnBgColor?.run {
            button.setBackgroundColor(Color.parseColor(this))
        }
        button.text = btnBean.btnTxt
       
        button.setOnClickListener {
            RouterManager.jumpUrl(this, btnBean.openUrl)
        }

        findViewById(R.id.layoutParent).addView(button)
    }

可以看到,我将路由处理交给了RouterManager的jumpUrl()函数,实际上RouterManager只是我对ARouter API的封装管理类,最终我将URL Scheme的处理交给了前文提到要造的轮子:SchemeHelper

/**
 * 路由管理类
 * */
object RouterManager {

    private val mSchemeHelper by lazy { SchemeHelper() }
  
    /**
     * 跳转 Activity
     * */
    fun goActivity(context: Context?, path: String, bundle: Bundle? = null) {
        ARouter.getInstance().build(path)
            .with(bundle)
            .navigation(context)
    }

    ...

    /**
     * Scheme 路由跳转
     * */
    fun jumpUrl(
        context: Context,
        jumpUrl: String?,
        callBefore: ((context: Context, action: RouterAction) -> Unit)? = null,
        callAfter: ((context: Context, json: String?) -> Unit)? = null
    ) {
        mSchemeHelper.jumpUrl(context, jumpUrl, callBefore, callAfter)
    }

    ...

}

而SchemeHepler中要做的事想当然是对Url进行解析,拿出参数action中那四部分数据,根据这四部分数据完成具体的页面跳转。

class SchemeHelper {

    /**
     * Scheme 路由跳转
     * */
    fun jumpUrl(
        context: Context,
        jumpUrl: String?,
        callBefore: ((context: Context, action: RouterAction) -> Unit)? = null,
        callAfter: ((context: Context, json: String?) -> Unit)? = null
    ) {
        try {
            XLog.i("jumpUrl:: $jumpUrl")
            //校验协议
            if (TextUtils.isEmpty(jumpUrl)) return
            val schemeUrl = CommRouter.Scheme.run { "$SCHEME$HOST$PATH" }
            if (jumpUrl!!.startsWith(schemeUrl)) {
                // 解析Action
                var actionJson = UrlUtils.getUrlParam(jumpUrl, CommRouter.Scheme.ACTION)
                actionJson = URLDecoder.decode(actionJson)
                val routerAction = JsonParser.fromJsonObj(actionJson, RouterAction::class.java)
                // 分发路由
                dispatchAction(context, routerAction, callBefore, callAfter)
            }
        } catch (e: Exception) {
            XLog.e(e)
        }
    }

    /**
     * 根据action_type分发路由
     * */
    private fun dispatchAction(
        context: Context,
        routerAction: RouterAction,
        callBefore: ((context: Context, action: RouterAction) -> Unit)? = null,
        callAfter: ((context: Context, json: String?) -> Unit)? = null
    ) {
        if (TextUtils.isEmpty(routerAction.action_type)) return

        when (routerAction.action_type) {
            CommRouter.Scheme.ACTION_TYPE_JUMP -> {
                // 跳转页面
                jumpAction(context, routerAction, callBefore, callAfter)
            }
            CommRouter.Scheme.ACTION_TYPE_CALL -> {
                // 调用功能
                callAction(context, routerAction, callBefore, callAfter)
            }
            else -> {
                XLog.e("未知行为类型(action_type)::${routerAction.action_type}")
            }
        }
    }

    ...
}

通过路由分发,我们已将Url解析为路由跳转(jumpAction)和功能调用(callAction)两部分,现在接口下发的是“/user/UserMainActivity”页面跳转路由,这个路由不就是配置在UserMainActivity上的ARouter路由吗,剩下的就交给ARouter吧!

    /**
     * 跳转页面
     * */
    private fun jumpAction(
        context: Context,
        routerAction: RouterAction,
        callBefore: ((context: Context, action: RouterAction) -> Unit)? = null,
        callAfter: ((context: Context, json: String) -> Unit)? = null
    ) {
        if (TextUtils.isEmpty(routerAction.page_type) || TextUtils.isEmpty(routerAction.path)) return

        callBefore?.invoke(context, routerAction)

        when (routerAction.page_type) {
            CommRouter.Scheme.PAGE_TYPE_NATIVE,
            CommRouter.Scheme.PAGE_TYPE_WEB -> {
                // 原生页面 & H5 处理方式一样 ,都交给ARouter处理
                RouterManager.goActivity(
                    context,
                    routerAction.path!!,
                    bundle
                )
            }
            CommRouter.Scheme.PAGE_TYPE_RN -> {
                // RN

            }
            else -> {
                XLog.e("未知页面类型(page_type)::${routerAction.page_type}")
            }
        }
        callAfter?.invoke(context, "")
    }

来,运行下看看效果:


接口下发页面路由演示

自定义功能调起 Url

页面跳转完成,接下来看看功能调起的路由又该如何实现。

功能路由:
example://www.demo.com/openApp?action={"action_type":"call" ,"page_type":"","path":"/user/isLogin" , "params":"{}" }
场景1:接口路由下发,动态功能调起

思考下:开篇时,我们提到ARouter是无法直接通过路由去调起一个功能,还需要借助Service来做中转,“/user/isLogin”又属于哪个Service呢,对于User模块的开发者知道这个功能属于他的模块,但对于其他开发人员就不一定了。如果每个业务模块对外提供一个功能,都在SchemeHelper这个轮子里进行编写代码调起自身模块的Service功能,显然是不合适的!怎么办?

还记的 “Android组件化 —— 基础(二) - 组件间通讯” 篇章中我们是如何手动实现路由框架的吗?这里是类似的,对于功能调起的路由需要开发人员手动注册到SchemeHelper中,至于使用哪个Service,调起哪个功能,都不应该由轮子来操心,回调给注册的开发人员去实现即可。

下面是我定义的回调函数接口:

interface IRouterCall {

    /**
     * @param context 上下文
     * @param path 功能路由
     * @param bundle 携带来的参数
     * @return 该功能可以返回数据,JSON格式字符串
     * */
    fun handleCall(context: Context, path:String , bundle: Bundle): String?
}

业务开发人员将对外提供的功能函数编写完毕后,再实现一个对应的IRouterCall子类,并将该子类对象与其对应的路由注册到SchemeHelper中。

/**
 * User模块对外提供的ARouter Service
 * */
@Route(path = "/user/UserService")
class IUserServiceImpl2 : IUserService2 {

    override fun init(context: Context?) {
    }

    /**
     * 用户是否登录
     * */
    override fun isLogin(): Boolean {
        // 是否登录业务逻辑
        return true
    }
}

/**
 * /user/isLogin功能路由的处理类
 */
class IsLoginCall : IRouterCall {

    override fun handleCall(context: Context, path: String, bundle: Bundle): String? {
        val ret = RouterManager.getService(IUserService2::class.java)?.isLogin() ?: false
        Toast.makeText(context, "用户登录状态:$ret", Toast.LENGTH_SHORT).show()
        return null
    }
}

/**
 * User模块初始化入口
 * */
object UserInit {

    fun init(context: Context) {
        initRouter()
    }

    private fun initRouter() {        
        // 注册功能路由 /user/isLogin
        RouterManager.addRouterCall("/user/isLogin" , IsLoginCall())
    }

}

与手动实现路由框架时相同,我会将路由路径以及Call对象存储到Map容器中,在路由页面跳转部分,已经将路由处理分发为jumpAction() 和 callAction()函数,这里在callAction()函数里进行匹配路由,再回调给开发人员即可。

object RouterManager {

    private val mSchemeHelper by lazy { SchemeHelper() }
  
    ...

    /**
     * 注册自己业务的路由处理器
     * */
    fun addRouterCall(
        path: String,
        call: IRouterCall
    ) {
        mSchemeHelper.registerCall(path, call)
    }

    ...
}

class SchemeHelper {

    // actionType : call 路由容器
    private val mCallGroup = HashMap()

    /**
     * 注册Call功能
     * */
    fun registerCall(path: String, call: IRouterCall) {
        mCallGroup[path] = call
    }


    /**
     * 调起功能
     * */
    private fun callAction(
        context: Context,
        routerAction: RouterAction,
        callBefore: ((context: Context, action: RouterAction) -> Unit)? = null,
        callAfter: ((context: Context, json: String?) -> Unit)? = null
    ) {
        if (TextUtils.isEmpty(routerAction.path)) return

        // 正常触发 call
        callBefore?.invoke(context, routerAction)
        var resultJson: String? = null
        val call = mCallGroup[routerAction.path]
        if (call != null) {
            // 自定义的Call功能实现
            resultJson = call.handleCall(context, routerAction.path!! , bundle)
        } else {
            when (routerAction.page_type) {
               // TODO 公共的Call功能实现
               handleCommCall(context, routerAction.path!! , bundle)
            }
        }
        callAfter?.invoke(context, resultJson)
    }

}

测试下,试试App模块是否能调起User模块的isLogin功能:

    private fun getBtnForNet() {
        Thread {
            Thread.sleep(1500)
            val json = "{\"btnBgColor\":\"#FF0000\",\"btnColor\":\"#FFFFFF\",\"btnTxt\":\"调起isLogin\",\"openUrl\":\"example://www.demo.com/openApp?action\\u003d{\\\"action_type\\\":\\\"call\\\" ,\\\"page_type\\\":\\\"\\\",\\\"path\\\":\\\"/user/isLogin\\\" , \\\"params\\\":{} }\"}"
            runOnUiThread {
                showButton(JsonParser.fromJsonObj(json, ButtonBean::class.java))
            }
        }.start()
    }
接口下发功能路由演示

至此,SchemeHelper轮子基本成型,我们已经顺利打通动态的页面跳转和功能调用场景,而至于场景2、场景3的实现,将通讯数据换成Scheme Url,拿到Url后扔给轮子处理即可,我把核心代码贴在下方,就不分别演示了。

场景2:外部APP唤起咱们APP的页面或功能
  • 清单文件配置Scheme:
    

        
            ...

            
                

                

                
                
            
            
            ...
        

    
  • Activity中获取Url,并交给轮子处理
@Route(path = "/app/AppMainActivity")
class AppMainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        handUri();
    }

    private fun handUri() {
        RouterManager.jumpUrl(this, intent?.dataString) 
    }

}
场景3:Web H5 Js调用APP原生页面或功能
  • webView暴露JS接口
mWebView.addJavascriptInterface(JsApi(mContext), “androidJs”)


/**
 * 供H5调用的Js接口
 * */
class JsApi(private val mContext: Context) {

    /**
     * 通过路由调起APP的页面或功能
     * */
    fun openApp(openUrl: String) {
        RouterManager.jumpUrl(mContext , openUrl)
    }

}
  • H5 Js调用
window.androidJs.openApp("example://www.demo.com/openApp?action={\"action_type\":\"call\" ,\"page_type\":\"\",\"path\":\"/user/isLogin\" , \"params\":\"{}\" }")

小结

本篇,我们学习了URL Scheme在组件化场景中的使用,它为多场景开发中通讯提供了统一标准,使业务实现更加灵活,一个设计完善的Url路由可使开发人员一眼就知其作用,从而降低代码维护成本;试想下在场景1和场景3中,如果不使用Url路由来做通讯,客户端开发人员就不得编写大量的代码来完善这些功能,而这些功能涉及到流程变动时往往伴随着发版,使用路由做通讯可使发版频次降低。

虽然我们完成了Url路由的通讯功能,但在处理Call路由时,还是采取了手动注册的方式。通过前两篇学习,我们知道手动注册会在APP启动时通过startup来完成,这个路由可能并未被使用就已被载入内存中,导致额外内存开销。在学习ARouter过程中,发现其是通过APT(注解处理器)方案来完成注册相关工作。

下篇,不妨参考ARouter的APT实现,编写一个完成Call路由注册的注解处理器。那么,我们下篇再见~

你可能感兴趣的:(Android组件化架构 —— 基础(四) URL Scheme)