前言

关于Rubik

关于组件化

• 隔离：让业务组件之间保持相对的独立性
• 复用：复用业务组件形成可运行软件

怎样才算彻底的组件隔离？

• 明确开发人员的职责：由于对一个模块的修改不会直接影响另一个模块，所以负责开发不同模块的开发人员，只需要对约定好的接口负责，不需要关心其他组件的具体实现。
• 降低测试成本：同样的，对于测试人员而言，如果能够保证对一个组件的修改，只影响组件本身和组件的接口，那么对于没有被修改过的组件，就没有回归测试的必要了。
• 提升编译速度：在实际开发中，可以让大部分组件提前编译成二进制，只让少数经常变更的组件保持源码状态。
• 故障隔离：当一个组件出现故障，能够做到不影响其他组件的正常运行。

组件级别的复用应该做到什么程度？

Rubik在组件化中的作用？

Rubik Router：基于Kotlin DSL的“函数”路由

• 灵活性：在实际开发中，组件的边界通常不是简单的页面跳转，有可能是Api的调用或数据、实例的获取，相比于传统的页面路由，“函数”路由可以更加轻量级的满足这些需求。
• 可扩展性：“函数”路由有更低的层次，使用者可以在函数的基础上延伸更多的用法。
• 一致性：对于路由调用者而言，路由的终点无论是函数、页面还是数据，Rubik Router都提供一致的调用方式。

 @RRoute(path = "user") fun getUser(id : Int, name : String) : User? { … }

 navigate { uri = "app://com.account/user" query { "id" with 400 "name" with "zhangsan01" } result<User?> { user -> // 通过泛型指定接收数据类型 … } } 

Rubik Plugins：基于Gradle Plugin的组件管理和依赖管理工具

• rubik：
  • 提供全局定义组件的能力，并根据全局定义自动启用rubik-context、rubik-root等插件

    rubik插件工程结构

    ​

     rubik { component { uri "app://com.cloud-file" // uri 是组件的唯一 id，和路由根路径 dependencies { // 组件所依赖的其他组件uri uri ("app://com.local-file" ) uri ("app://com.upload" ) } source { // 定义的多种来源 project (":lib-cloud-file") maven { // 其他组件依赖自己的默认版本 version "0.2.0" variant "english-debug" } } } component { … } // 继续定义下一个组件 } 

    ​组件的定义方式

     

     

• rubik-root：
  • 给App工程提供筛选组件能力，根据flavor、版本号筛选要打包进apk的业务组件
  • 提供组件的源码工程和aar切换的能力

 rubik { packing { uri ("app://com.cloud-*") { // 筛选范围，uri表示用uri筛选，支持*匹配任意字符 projcetMode () // 筛选方式， projcetMode通过工程筛选一些组件 } uri ("app://com.preview-file") { mavenMode { // 筛选方式， mavenMode通过maven依赖aar筛选一些组件 version "0.2.0" variant "netdisk-english-debug" } } …… } } 

• rubik-context：
  • 提供把业务代码按flavor、版本号编译成aar 并发布到maven的能力
  • 提供辅助函数路由，把中间代码打包成context.jar ，并按版本号发布到maven的能力，并根据全局定义，为组件自动添加其他组件的中间代码依赖

• rubik-test:
  • 给工程提供单元测试环境

最后