Android适合组件化开发的路由框架:Launch

1.概述

最近越来越不想写代码了,特别是一些重复性的代码,比如由于每次启动一个 Activity,我们都会很习惯的在 Activity 中写下:

public static void launch(Activity activity) {
    Intent intent = new Intent();
    intent.setClass(activity, xxxActivity.class);
    activity.startActivity();
}

已经有两年Android开发经验的我掐指一算,好像有很多方法可以直接帮咱们生成这样类似的代码:

  • 通过 Android Studio 中自定义Activity的Template,这样就可以在生成一个Activity class的时候,会自动帮咱们填充launch方法。大幅提高Android开发效率之Android项目模板化
  • 通过 Android Studio 的快捷键方式 Live Templates,来定制 launch 代码块:你不一定知道的Android Studio中强大的快捷代码块
  • 可爱的编译时注解。

本文的重点放在了编译时注解的框架实现,毕竟是要和时代接轨的啦!

百牛信息技术bainiu.ltd整理发布于博客园

2.需求剖析

我的需求很简单,就完成通过注解来代替Intent代码来启动 Activity,让注解来帮我们生成 launch 方法,而且还要能够在组件化开发中使用。
需求很明确,所以直接开始构思:
所有的 launch 方法其实很类似,不同的就是跳转的终点 xxxActivity ,那么我们就想办法来构造一个对应的关系:通过配置注解 LaunchAnn 来给每个 Activity 分配一个String别名,我通过找到这个别名,我就知道了这个对应的真实 Activity。这样在需要启动xxxActivity的地方,我通过调用别名来启动这个 xxxActivity 就可以了,这样启动就不会依赖 xxxActivity,而仅仅是一个别名字符串而已。

3.开发流程

创建三个 module:

  • iocAnnotation:java lib,里面只放了编译时注解
  • iocCompiler: 只能是 java lib,不能是 Android lib(生成aar的),因为我们使用的 AbstractProcessor 在Android环境下是找不到的。
  • iocApi:Android lib,是给用户直接使用的,里面会用到一点点反射。

开发注解框架可以参考:Android 如何编写基于编译时注解的项目。注意的点:

  • 为啥要三个 module:由于 iocCompiler 只是在编译的时候才使用的,所以在运行的时候是用不到的,这样我们就可以不用打包到正式apk中,所以在gradle文件中引入方式是:annotationProcessor。
  • iocCompiler 对 AbstractProcessor 的注释有两种:1是直接在实现类中通过google提供的注解AutoService完成,2是自己在 resources 下 META-INF/services/javax.anotation.processing.processor中进行声明,如果有多个processor,直接逗号隔开。

定义注解:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.CLASS)
public @interface LaunchAnn {
    String value();
}

注解使用:

@LaunchAnn("RuntimeActivity")
public class RuntimeActivity extends Activity {

}

打开 activity:

public void onClick(View view) {
    Launch.launch("RuntimeActivity", this);
}

iocCompiler 中的 CakeProcessor 中(AbstractProcessor实现类),生成了一个固定的LaunchUtil工具类。通过遍历有哪些类使用了LaunchAnn注解,然后把 LaunchAnn 的 value 值(这里的“RuntimeActivity”)作为 key,类对应的全路径(包名+类名)作为 value 存入到 LaunchUtil 工具类的 map 中,这样我就可以直接通过注解 LaunchAnn 的 value 值可以获取到对应类的全路径。
iocApi 的作用就是提供给用户调用的接口(onClick中的内容调用),LaunchUtil 中包含了注解对应的map信息,所以关键点就是能够解析LaunchUtil中的内容。
由于 iocApi 和 iocCompiler 没有半毛钱联系,所以怎么能够获取到 LaunchUtil 这个类?这点还是让我花费了一些时间的,最后通过在 iocApi 中定义一个 LaunchInjector 接口,实现通过key值获取Class的getPackageName的接口。当然我们的 LaunchUtil 工具也要实现与LaunchInject这个接口,这样通过反射LaunchUtil的,直接形成了一个 LaunchInjector 的对象,通过 getPackageName 方法就可以获取到需要跳转的 Activity 对应的 Class。
我感觉介绍的差不多了,不懂就自己看代码了。

4.适配组件化方案

其实最开始仅仅是想做一个懒人开发者,这样我就不用每次都写 launch 了,但是开发到最后才发现,前面还有好多要去学习的地方。
由于本身自己在学组件化开发,所以想把写的注解运用到组件化当中去。有4个 module:modulebase、moduleA、moduleB、app。命名中可以看出 modulebase 是基础包,moduleA 和 moduleB 都是功能模块包,最后总包 app module。
由于每个模块都是用了Launch,所以我们可以发现在编译注解的时候,每个 lib 下面都会有一个 LaunchUtil,在合并的时候就会冲突(提示类重复),所以我们需要针对不同的模块,定制不同的类名,我这边是根据模块绑定了,例如:LaunchUtil$$moduleA.java。这样多个 LauncUtil 类就可以共存了。
现在由于有多个 LauncUtil,我们怎么把所有的 LaunchUtil 里面的map信息进行汇总,得到一个总的 map 信息呢?这个东西我想了很久很久,过程中经历了两种实现,其中第一种最后证明不行,最后选择了第二种。为啥还要说第一种呢,因为我感觉还是有必要记录一下的:

  • 第一种,为什么不可以对注解生成的 LaunchUtil 再进行加入注解,然后再把所有的 LaunchUtil 在编译时获取其中的map,最后生成一个新的LaunchUtilMerge类呢?我最开始的想法就是这样的,在生成的 LaunchUtil 中也实现了一个注解:MergeLaunch 注解,然后再生成一个 MergeProcessor 来查找 MergeLaunch 对应的 LaunchUtil 类,获取每个类中的 map,得到一个总的 map 放入到 LaunchUtilMerge 中去。
    想象这很美好,但在开发过程中发现,由于编译的流程是:先编译 moduleA、moduleB 变成 aar 包,然后 app 依赖 aar 包后再进行编译,而 aar 中的类都是 .class 形式存在的,那么 moduleA.aar 中的 LaunchUtil 在 app module 看来就是一个 LauncUtil.class,即使你有 MergeLaunch 编译时注解,你也不可能找到 moduleA.arr 中的 LaunchUtil,因为他是一个 .class 文件,编译时注解只对 .java 文件有效。在组件化的时候,编译注解是对 java 类而言的,所以在 jar 包、aar 包中存在编译时注解,也是获取不到的。导致的后果就是,LaunchUtilMerge 最后也只找到了app module 中的 LaunchUtil,这样得到的 map 信息明显是不全的。分析到最后,我也是放弃了,很坚决的放弃!
  • 第二种,在第一种无解的情况下,手贱把 apk 反编译看了看,其实发现打包后每个模块对应的 LaunchUtil 其实都是在 dex 中的,所以有没有一种方法,通过类名来找对应的 LaunchUtil 呢?为了好处理在生成 LaunchUtil 的时候,我都把他们放在了一个文件夹下面:”seu.com.util“,这样我只要找到这个文件夹下面的所有类就可以了,现在的问题就变成了通过指定的包名来找对应的所有类。
    网上搜了搜,还真有在 Android 环境下,通过 DexFile 这个类来查找 dex 中对应的类名对应的全路径:Android中获取指定包名下的所有类,哈哈哈,这样我就找到了所有LaunchUtil对应的全路径名称,最后通过反射找到的所有类,获取每个类中的map,合并成一个汇总的 map,其中包括了所有 LaunchuAnn 注册过的 Activity 对应的类信息,在 iocApi 下的 Launch 类中。这样你就可以通过传入一个字符串的方式来启动 Activit y啦。

    5.总结

    前面的编译注解对老司机来说其实都是比较简单的,开发流程表比较固定。对于适配组件化开发的过程,其实还是一个比较新鲜的事情。因为看到了阿里的ARouter是适合组件化开发的,所以自己也是有点蠢蠢欲动的赶脚。最后有一个可以让人参考的 demo,希望大家多多交流和学习。对于还有更好的方法来获取所有的 LaunchUtil 的,欢迎交流。
    存在的不足:

  • 只是查找了一个dex中的所有类,一些apk有好多 dex 文件,那么要确保所有的 LaunchUtil 都被找到,需要查找所有的 dex,这一块是暂时还没有处理的。后续对 class 拆分成多个dex有了研究之后再回来研究这一块。
  • 项目还是比较适合个人学习提升的:https://github.com/dndxxiangyu/AndroidLearn

作者:五香鱼cc
链接:http://www.jianshu.com/p/af2b83af02e1
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

时间: 2024-08-11 07:40:42

Android适合组件化开发的路由框架:Launch的相关文章

Android 业务组件化开发实践

组件化并不是新话题,其实很早很早以前我们开始为项目解耦的时候就讨论过的.但那时候我们说的是功能组件化.比如很多公司都常见的,网络请求模块.登录注册模块单独拿出来,交给一个团队开发,而在用的时候只需要接入对应模块的功能就可以了. 百牛信息技术bainiu.ltd整理发布于博客园 今天我们来讨论一下业务组件化,拿出手机,打开淘宝或者大众点评来看看,里面的美食电影酒店外卖就是一个一个的业务.如果我们在一个项目里面去写的时候,总会出现或多或少的代码耦合,最典型的有时为了赶上线时间而先复制粘贴一段类似的代

Android组件化开发实践

Android项目中代码量达到一定程度,编译将是一件非常痛苦的事情,短则一两分钟,长则达到五六分钟.Android studio推出instant run由于各种缺陷一般情况下是被关闭的--组件化开发可以有效降低代码模块的耦合度,使代码架构更加清晰,同时模块化的编译可以有效减少编译时间,当然总的编译时间是不会减少的,只是App模块化之后开发某个模块时,只需要编译特定模块,可以快速编译调试. 百牛信息技术bainiu.ltd整理发布于博客园 原理 组件化和插件化有些同学有些迷惑,简单来说组件化是在

Android业务组件化之子模块SubModule的拆分以及它们之间的路由Router实现

前言: 前面分析了APP的现状以及业务组件化的一些探讨(Android业务组件化之现状分析与探讨),以及通信的桥梁Schema的使用(Android业务组件化之URL Schema使用),今天重点来聊下子模块SubModule的拆分以及它们之间的路由Router实现.本篇涉及的相关知识比较多,阅读本篇之间需要大致了解一下Java的注解(Java学习之注解Annotation实现原理).Java的动态代理机制(Java设计模式之代理模式(Proxy))等.业务组件化是一个循序渐进的过程,一开始很难

Android组件化开发的简单应用

组件化开发的主要步骤: 一.新建Modules 1.新建Project,作为应用的主Module. 2.新建Module:"Common",类型选择"Android Library",作为所有其它Module的基础依赖库. 3.新建Module:"Home",类型选择"Android Library",依赖"Common". 4.新建Module:"Project",类型选择"

Android项目模块化/组件化开发(非原创)

文章大纲 一.项目模块化初步介绍二.项目模块化的两种模式与比较三.大型项目模块化的演进四.项目模块化总结五.参考文章 一.项目模块化初步介绍 1. 前言 在Android开发中,随着项目的不断扩展,项目会变得越来越庞大,而随之带来的便是项目维护成本与开发成本的增加!每次调试时,不得不运行整个项目:每当有新成员加入团队时,需要更多的时间去了解庞大的项目...而为了解决这些问题,团队通常会将项目模块化,以此来降低项目的复杂度和耦合度,让团队可以并行开发与测试,让团队成员更加专注于自己所负责的功能模块

前端框架Vue自学之Vue组件化开发(三)

终极目标:掌握和使用Vue(全家桶:Core+Vue-router+Vuex) 本博客目的:记录Vue学习的进度和心得(Vue组件化开发) 内容:通过官网说明,掌握Vue组件化开发. 正文: Vue组件化开发 一.认识组件化 原文地址:https://www.cnblogs.com/xinkuiwu/p/12037281.html

【组件化开发】前端进阶篇之如何编写可维护可升级的代码

前言 我还在携程的做业务的时候,每个看似简单的移动页面背后往往会隐藏5个以上的数据请求,其中最过复杂的当属机票与酒店的订单填写业务代码 这里先看看比较“简单”的机票代码: 然后看看稍微复杂的酒店业务逻辑: 机票一个页面的代码量达到了5000行代码,而酒店的代码竟然超过了8000行,这里还不包括模板(html)文件!!! 然后初略看了机票的代码,就该页面可能发生的接口请求有19个之多!!!而酒店的的交互DOM事件基本多到了令人发指的地步: 当然,机票团队的交互DOM事件已经多到了我笔记本不能截图了

Android业务组件化之现状分析与探讨

前言: 从个人经历来说的话,从事APP开发这么多年来,所接触的APP的体积变得越来越大,业务的也变得越来越复杂,总来来说只有一句话:这是一个APP臃肿的时代!所以为了告别APP臃肿的时代,让我们进入一个U盘时代,每个业务模块都是一个具备独立运行的盘,插在哪里都可以完美运行,这就是推进业务组件的初衷也是一个美好的愿景. 需求背景: 随着公司的快速发展,版本不断的迭代,业务变得也越来越复杂,业务模块的数量有可能还会继续增加,而且每个模块的代码也会越来越多,这样下去势必影响开发效率,增加项目的维护成本

AppBoxFuture(六): 前端组件化开发

??前面几篇都是在介绍结构化与非结构化的数据存储,本篇换换口味介绍一下框架是如何实现前端组件化开发的.首先得感谢Vue.ElementUI等优秀的前端开源项目,这些项目帮助作者快速实现了框架的两个前端工程(IDE及Web应用)的开发. ??当初框架的设计目标是:前端.后端.存储端统统一锅端,为什么这么设计,一方面是想减少开发人员对于开发环境及各类工具的安装配置时间,另一方面是想消除各端之间的集成调试问题,使开发人员更多的关注数据结构.业务逻辑.用户界面的设计与开发.为了达成这一目标,作者在框架的