Android技术栈(二)组件化改造，目前最稳定和高效的UI适配方案

最新推荐文章于 2024-08-21 02:12:18 发布

广东程序员鱼

最新推荐文章于 2024-08-21 02:12:18 发布

阅读量916

点赞数 23

分类专栏： Android程序员文章标签： android ui java

本文链接：https://blog.csdn.net/m0_61040489/article/details/136838929

版权

Android程序员专栏收录该内容

10 篇文章 0 订阅

订阅专栏

文章详细介绍了ARouter在Android应用中的使用，包括模块间路由、自定义拦截器、全局策略（降级和重定向）、接口下沉以及ContentProvider的运用。作者还探讨了ARouter的实现原理和局限性，以及如何成为Android架构师所需的知识技能。

摘要由CSDN通过智能技术生成

.build(PR.navi.navi)
.navigation();

而Activity则不需要,它会立即显示

ARouter.getInstance()
.build(PR.navi.navi)
//还可以设置参数,ARouter会帮你存在Bundle中
.withString(“pathId”,UUID.randomUUID().toString())
//Activity 或 Context
.navigation(this);

navi模块是典型的业务逻辑模块,这里你可导入一些只有这个模块才会使用的专属第三方SDK,比如我在navi模块中使用了高德地图的SDK,其他模块只需要我这个模块的地图功能,但它不应该知道我到底使用的是高德还是百度还是腾讯地图,这就提高了封装性,在未来改变此模块的具体实现时,代价也会小得多.

3.自定义全局拦截器、全局降级策略、全局重定向

ARouter实现了module间的路由操作,同时也实现了拦截器的功能,拦截器是一种AOP(面向切面编程),比较经典的使用场景就是处理页面登录与否的问题.拦截器会在跳转之间执行，多个拦截器会按优先级顺序依次执行.通过实现IInterceptor接口并标注@Interceptor注解,这样一来,这个拦截器就被注册到ARouter当中了.

process方法会传入Postcard和InterceptorCallback,Postcard携带此次路由的关键信息,而InterceptorCallback则用于处理此次拦截,调用onContinue则放行,又或者调用onInterrupt抛出自定义异常.

拦截器会在ARouter初始化的时候进行异步(不在主线程)初始化,如果第一次路由发生时,还有拦截器没有初始化完毕,那么ARouter会等待该拦截器初始化完毕才进行路由.

@Interceptor(priority = 8)
public class TestInterceptor implements IInterceptor {
@Override
public void process(Postcard postcard, InterceptorCallback callback) {

callback.onContinue(postcard); // 处理完成，交还控制权
// callback.onInterrupt(new RuntimeException(“我觉得有点异常”));
// 觉得有问题，中断路由流程
// 以上两种至少需要调用其中一种，否则不会继续路由
}

@Override
public void init(Context context) {
// 拦截器的初始化，会在ARouter初始化的时候调用该方法，仅会调用一次
}
}

当页面未找到时,我们可以定义一种降级策略来让程序继续运行,此时我们需要实现DegradeService接口,并用@Route(必须)标注,然后它会在全局范围内生效,你可以在onLost回调中自定义降级逻辑.

@Route(path = “/xxx/xxx”)
public class DegradeServiceImpl implements DegradeService {
@Override
public void onLost(Context context, Postcard postcard) {
// do something.
}

@Override
public void init(Context context) {

}
}

有时候页面我们需要将path其重定向别的path,这时我们可以实现PathReplaceService接口,并用@Route(必须)标注,然后它会在全局范围内生效.所以若没有重定向需求记得返回原path

@Route(path = “/xxx/xxx”)
public class PathReplaceServiceImpl implements PathReplaceService {
String forString(String path) {
return path; // 按照一定的规则处理之后返回处理后的结果
}
Uri forUri(Uri uri) {
return url; // 按照一定的规则处理之后返回处理后的结果
}

@Override
public void init(Context context) {

}
}

以上上三种接口中的init方法,只有拦截器的调用时间是特殊的,其他两种,都是在第一次使用时才会进行初始化.

4.接口下沉->暴露服务

有的时候我们可能需要的不是另外一个模块的页面,而是它提供的服务(MVC中的Model层),这时这时我们需要为自己想要的服务编写一个接口,并让他实现IProvider接口,然后把它放到common模块中, 但是接口的实现依然放在非common的具体的模块中,比如common模块的TTSService和ai模块的TTSServiceImpl.

这种做法被称为接口下沉,其实它并不是严格符合解耦思想的,但是它非常有用,就像你使用了ARouter,但没人规定你就不能用startActivity了一样,框架最终的目的还是为了方便我们编码的,而不是为了给我们添堵,更何况最终结果各模块依然是松散耦合的.

服务的初始化时机也是在第一次使用的时候.我们在common模块中声明TTSService接口:

public interface TTSService extends IProvider
{
void send(String text);

void stop();
}

并在ai模块中实现它并使用@Route注解标注

@Route(path = PR.ai.tts_service)
public class TTSServiceImpl implements TTSService
{
//省略…
}

这样我们就能在其他模块使用该服务了

TTSService ttsService = (TTSService) ARouter.getInstance()
.build(PR.ai.tts_service)
.navigation()

5.ContentProvider->模块内的Application

有些第三方SDK初始化是必须要在Application的onCreate中进行初始化的,但是如果我们编写独立于host的module时,要怎么初始化它们呢?

ARouter并没有提供官方的解决方案,但是经过我的实践,我们可以通过声明ContentProvider并在模块内AndroidManifest中注册它来实现初始化功能.

//java
public class ModuleLoader extends ContentProvider
{
@Override
public boolean onCreate()
{
Context context = getContext();
//TODO
return true;
}

//…

}

//AndroidManifest

ContentProvider#onCreate在Application#attachBaseContext调用之后Application#onCreate调用之前执行,并且可以通过getContext拿到Application的Context.这样就解决了部分第三方SDK初始化的问题.