工程链接

1.背景介绍

工程配置 android gradle3.0.1，Gradle4.4。因为Android Studio的版本不同，可能upgrade gradle plugin的时候，会触发起码module的build.gradle的运行，而此时module的build.gradle又要使用自己写的这个plugin的东西去解析自己的声明，所有这就是一个鸡和蛋的问题。所以建议将module_build单独拉project，编辑上传本地maven库，然后实例工程使用上传的gradle插件记好了;

最新的修改：所有的module都变为地位平等，app的module也需要配置是否可以作为其他module的依赖module。gradle编译的时候，一般命令为：gradle build(表示运行以根目录下config.gradle中配置的main_module为主module的编译工作)，单独编译指定module，可以使用命令：gradle :module_name:task_name。

项目功能已趋近稳定，具体每个功能都已经有完备的流程；

就目前我看到的产品业务发展规划，是在不断完善项目，修复bug的前提下，主要工作就是对接第三方的设备。

而在这个过程中，比较突出问题：针对越来越多不同设备，不同需求的接入，修剪适配项目代码，但是前期代码糙快猛，模块功能之间耦合比较严重，对项目代码的修剪工作造成了不小的麻烦，多半情况下的妥协处理就是把不需要的功能入口屏蔽掉，但是相关代码还存在。所以即使某个第三方设备仅仅需要一小部分的功能，其安装包也是和全功能的版本大小一样的，这种在我们推送有流量限制的前提下，是很不节俭的。

另一个也是代码耦合造成的问题：因为所有功能都耦合在一个module中，在一个版本的迭代中，就有可能因为相互依赖的问题，本该并行开发的工作，变成了线性，严重影响效率。对于测试人员，也要因为任何的改动，做全功能的回归测试。

基于以上，项目的组件化重构就提上了日程。

2.组件化原理

• 组件化的定义：

  Component-based software engineering (CBSE), also known as component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems. This practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for organizations that sponsor such software.

概括一下，就是基于可重用的目的，将一个大型的软件系统按照分离关注点的形式，拆分成多个独立的组件，以此减少耦合。针对我们的项目，大体的体现如下：(未体现base-lib等底层公共module)

组件化思想应用到我们的项目上，就是将收银，Erp，团购验券，预授权等业务模块进行解耦，独立成单独的组件，降低业务复杂度，每个组件都可以有自己独立的版本。根据不同的设备和商务需求，动态的去组合不同组件。这样做的好处，

1. 代码耦合降低，一个模块的改动不涉及或者很少涉及其他模块，提升代码质量，减少出bug的概率；

2. 代码修改范围变小，测试的工作量也相应的减少，将具体的业务分拆组件化之后，可以将没有变动的模块剔除回归测试的checklist，减少测试工作量；

3. 每一个独立的组件，都可以独立运行，方便开展独立测试；

4. 根据不同设备的需求，定制app，不需要的组件不会打包到app中，减少apk的大小；
   
   
   
   

3.方案选择

明确了目标，那么就要提出对应的实现方案，网络上有一热心网友对比了几个比价成熟的组件化方案：组件化方案对比

根据热度和传播程度，重点关注了一下得到 DDComponentForAndroid 和 阿里Arouter

DDComponentForAndroid 在路由上面的设计和其他几家通过注解，动态代码生成的实现方式都是大同小异的，但是他在使用Gradle Plugin实现Module之间的完全隔离上，想法比较新颖。只需要声明使用一个plugin，完全不用再多处手动配置手动配置的实例；

ARouter 严格意义上说，不能算是一个组件化框架，是一个用来解耦的路由框架，通过路由完成功能模块间之间的跳转，杜绝了模块间之间的直接依赖，也是组件化重要的思想和工具。

经过方案的对比，所以最终决定我们项目中的组件化使用：

ARouter (路由功能) + Gradle Plugin(Module隔离，Module初始化代码动态注入)

4.方案实施

1， ARouter的使用

由于ARouter推出时间比较长，功能多样，性能稳定，关于如何使用，网络上比比皆是，没必要过多介绍了，这里重点关注一下其优缺点和典型的应用场景：

• 功能介绍

  1. 支持直接解析URL进行跳转、参数按类型解析到Bundle，支持Java基本类型(*)

  2. 支持应用内的标准页面跳转，API接近Android原生接口

  3. 支持多模块工程中使用，允许分别打包，包结构符合Android包规范即可(*)

  4. 支持跳转过程中插入自定义拦截逻辑，自定义拦截顺序(*)

  5. 支持服务托管，通过ByName,ByType两种方式获取服务实例，方便面向接口开发与跨模块调用解耦(*)

  6. 映射关系按组分类、多级管理，按需初始化，减少内存占用提高查询效率(*)

  7. 支持用户指定全局降级策略

  8. 支持获取单次跳转结果

  9. 丰富的API和可定制性

  10. 被ARouter管理的页面、拦截器、服务均无需主动注册到ARouter，被动发现

  11. 支持Android N推出的Jack编译链

• 2 不支持的功能

  1. 自定义URL解析规则(考虑支持)

  2. 不能动态加载代码模块和添加路由规则(考虑支持)

  3. 多路径支持(不想支持，貌似是导致各种混乱的起因)

  4. 生成映射关系文档(考虑支持)

• 3 典型应用场景

  1. 从外部URL映射到内部页面，以及参数传递与解析

  2. 跨模块页面跳转，模块间解耦

  3. 拦截跳转过程，处理登陆、埋点等逻辑

  4. 跨模块API调用，模块间解耦(注册ARouter服务的形式，通过接口互相调用)

2，关键点：组件化Gradle插件

上文提到一种手动配置组件合并打包和组件独立打包的开发模式，其配置需要过多人为的参与。在配置完后，当前的配置只能符合一种组件组合方式的运行，如图所示：

当前可以运行app这个module，可能app module依赖于base，payplatform这两个module；

但是如果我现在想运行payplatform这个module，那么就需要手动的去改每一个module的gradle配置，然后clean project。操作完全部修改步骤之后，才能run payplatform，着实繁琐。

那么我们的目标是如下图这样的：

每个module都是不需要手动去修改配置的，选中任意一个module，根据预先配置好的module依赖关系，会自动将配置的组件打包进apk，然后运行在机器上。

每个module都可以直接run的秘密：

每一个module都会有一个build.gradle文件，其管理当前module的配置，在每一个build.gradle的开头，都有一句声明：

1

apply plugin：com.android.application / com.android.library

只要是使用application plugin的module，AS就认为这是一个可运行的module，声明为library plugin的module，AS认为它是一个库，不具备单独运行的能力，因此也就会在Run Configurations中对应的module上打上一个叉号❌。

那么我们是不是可以直接将所有module都声明使用application，就可以达到所有module全部可运行的目的呢？图样图森破。

不能这么操作的原因有二：

1. 当一个module作为application开始build时，他要求他所依赖的其他所有module，都必须使用library plugin。不然build是无法完成的。

2. 在build过程中，其中有一步就是merge AndroidManifest.xml，其会将所有module的manifest做一个合并，其他module作为app运行，一定会声明作为LAUNCHER的Activity，也多半会声明自定义的Application，那么在合并时就会报错，build system不知道要保留哪一个module的Application。即使build完成之后的安装，也会因为manifest中存在声明的每个module的LAUNCHER，而会在桌面上出现多个启动图标。

那么我们自定义的gradle plugin，就需要在点击run时，根据所点击的module，动态的取修改所有的module的build.gradle；大体流程如下：

步骤解析

当run某一个具体module的时候：

step1：

在每个module下，都有一个gradle.properties的配置文件其中声明了当前module作为独立app运行时，需要依赖的module信息：

1
2
3

isRunIndependence = true
release_dependency_module = modulea,moduleb
debug_dependency_modlue = modulea,moduleb

当在命令行下执行：

1

./gradlew :app:assembleDebug

表明当前是将app 这个module作为主module，那么其就会读取app module目录下的gradle.properties，获得app 所依赖的module信息。

step2-1，step2-2：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

//节选自gradle plugin
   void useDebugSourceSets(Project project) {
        project.android.sourceSets {
            main {
                manifest.srcFile 'src/main/debug/AndroidManifest.xml'
                java.srcDirs = ['src/main/debug/java', 'src/main/java']
                res.srcDirs = ['src/main/debug/res', 'src/main/res']
                assets.srcDirs 'src/main/assets'
                jniLibs.srcDirs 'src/main/jniLibs'
            }
        }
    }
    void useReleaseSourceSets(Project project) {
        project.android.sourceSets {
            main {
                manifest.srcFile 'src/main/AndroidManifest.xml'
                java.srcDirs 'src/main/java'
                res.srcDirs 'src/main/res'
                assets.srcDirs 'src/main/assets'
                jniLibs.srcDirs 'src/main/jniLibs'
            }
        }
    }

对应的，需要在module中建立相应的目录：

step3：
一般我们会将一些全局的初始化动作，变量在自定义的Application中进行声明。在Module作为独立App 进行build的时候，这样做是没有问题的，但是当Module作为组件被包含在主Module的代码中时，如上面提到的，为了避免merge Manifest失败，就不能再在Module自身的Manifest中声明自定义的Application了，且即使Module继续使用自定义Application，那么此时Module的Application也是一个普通的类，没有生命周期，不会被系统调用。那么Module又必须要进行一些初始化，怎么做呢？此时就要使用到android gradle1.5之后提供的Transform接口了：transform-api简介，配合transform-api就需要javaassist基本操作demo，一个能够将动态生成的代码插入到class文件的开源库，最终编译成dex，打包到apk中。

首先在每个module的build.gradle中声明，module作为app，作为组件时初始化使用的类名：

1
2
3
4

appindicator{
    myRealApp = 'com.liukuai.modulea.ModuleAApplication' //独立运行时使用
    myShadowApp = 'com.liukuai.modulea.app.ModuleApp' //module运行时类似Application功能的类
}

然后插入到transforms过程中的自定义Transform做如下操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

/**
* 节选自AppTransform
* @mainClass: 主Module appindicator中声明的myRealApp
* @moduleClazz: 所有组件Module appindicator中声明的myShadowApp的集合
**/ 
private void injectModuleAppCode(CtClass mainClass, List<CtClass> moduleClazz, String path){
        println "begin inject Module App code :${mainClass.getName()}"
        mainClass.defrost()
        try{
            CtMethod mainCreateMethod = mainClass.getDeclaredMethod("onCreate")
            StringBuilder builder = new StringBuilder()
            println "begin inject Module App code 1"
            //因为android.jar不在classPool的classpath搜索路径内，要使用this，就需要将android的内容添加到搜索路径中
            def androidPath = getSDkJarPath()
            println "androidPath:${androidPath}"
            classPool.insertClassPath(androidPath)
            for(CtClass moduleClass : moduleClazz){
                builder.append("new " + moduleClass.getName() + "().onCreate(this);")
            }
            mainCreateMethod.insertAfter(builder.toString())
        }catch(Exception e){
            println '$$$$$$$$$$$$$$$$$$$$$$$$$$$$$'+"happen Exception: ${e.getMessage()}"
        }
        mainClass.writeFile(path)
        mainClass.detach()
        println "end inject Module App code"
    }

编译完成之后，通过反编译看一下是否奏效了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

package com.liukuai.modulazition;
import com.alibaba.android.arouter.launcher.ARouter;
import com.liukuai.base_lib.BaseApplication;
import com.liukuai.modulea.app.ModuleApp;
public class MyApplication extends BaseApplication {
    public void onCreate() {
        super.onCreate();
        ARouter.openLog();
        ARouter.openDebug();
        ARouter.init(this);
        new ModuleApp().onCreate(this);
        new com.liukuai.moduleb.app.ModuleApp().onCreate(this);
    }
}

bingo，此时，在启动apk时，也会自动的启动Module的初始化工作。

5.总结

在每一个Module(不管是主工程，还是其他功能Module)，都声明使用该gradle插件，然后在对应Module的build.gradle中，声明该模块单独运行和作为module运行时，初始化需要调用的类(都是继承自AppSimilar接口)。

在对应Module的proper.properties文件中声明，当前这个模块如果单独运行所需要依赖的其他module信息。

像base_lib这种，不是独立功能模块，直接使用android library插件，不能声明使用组件化的gradle插件。

然后选择module，直接run就可以了(如果碰到编译错误，什么R8之类的，clean一下再run)。

附1：关于Android Gradle dependencies中集中依赖方式的区别：

可以看到，在android Gradle 3.0以后推出的runtimeOnly是最接近于我们对于组件化的需求的。但是其还是有些许不足，runtimeOnly虽然能隔离module间的java依赖，但是没有隔离资源，也就是moduleA可以直接调用到moduleB的layout，string，drawable等，无法实现我们期望的module间完全隔离。

附2：Android App Bundle 官方的动态插件方案

The new app publishing format, the Android App Bundle, is an improved way to package your app. The Android App Bundle lets you more easily deliver a great experience in a smaller app size, allowing for the huge variety of Android devices available today. You don’t need to refactor your code to start benefiting from a smaller app.

感觉国内的一杆插件化，要毙掉了 ：P

• App Bundle 官方指南
• 中文demo
  
  

参考文章

• https://cloud.tencent.com/developer/article/1005631

• https://www.jianshu.com/p/1b1d77f58e84

• 精通Groovy

• gradle插件的简单开发

• 官方指南

• Android Gradle Plugin 源码

什么是LRU：

Least Recently Used(最近最少使用)，其思想如名称，定义一个固定size的缓存池，如果缓存内容没有超过缓存池，则所有的数据都是可以直接放入到池中的，但是如果需要缓存的对象，已经超过了缓存池的限制，则LRU会将最近最少被使用到的缓存池中的对象，驱逐出池，用于腾出空位置将新对象放入其中。

在Android UI开发中，经常会需要去展示各种各样的图片，如果只是一个新闻，一件商品的图片展示，可能产品或者美工没有什么太多的要求，默认的矩形展示就可以了。但是如果涉及到用户头像这种的，可能需要已不同于普通矩形的样式展示出来，比如说，圆角矩形，圆形等，感觉就是为了突出效果的目的呢，whatever，反正产品就要这种展示，我们苦逼的就需要去实现。

Android中的动画使用注意事项

基本上现如今市面上所有的app，都会使用到动画效果，动画可以很好的提升用户的交互体验。

Android中的动画大概可以分成两个发展阶段：在Android3.0之前，Framework层提供了android.view.animation，可以实现View，ViewGroup的各种动画效果，比如AlphaAnimation，RotateAnimation，ScaleAnimation，TranslateAnimation，就可以分别实现透明度，旋转，缩放，位移等动画效果。当然，也可以通过AnimationSet将多个动画联合使用，以达到更复杂的效果。

TODO 如果发生异常，OnError，Action1运行的线程所在？？？？

TODO map 和 flatMap 的原理

TODO 与Retrofit的结合使用

TODO RxBinding，RxLifeCycle的应用

什么是响应式(Reactive):

应用开发中的例子：
搜索输入框，根据用户实时输入的数据，输入框下方会根据当前输入内容，实时刷新推荐信息，这种就叫做Reactive的能力。
类似这种能自动对外部环境的变化做出响应的系统，我们就称之为响应式系统(Reactive System)，其中的外部环境，可以是输入信号的变化，事件的发生等等。通常这个响应式系统不但能响应外部环境的变化，还会根据自身内部状态通过某种方式反馈给外部观察者(推荐内容变化)。

  关于Android App的优化，百度，Google已经收录了不计其数的文章。常规套路我相信大家基本上应该都可以如数家珍了吧。尤其是国内的技术环境，大众化的，易于理解和实践的优化方式和方法，被粘贴过来，复制过去。无非也就是使用系统提供的工具，例如Traceview, Hierarchyviewer，DDMS，MAT等等，去分析方法的调用，View的层级，内存的占用和一些其他的影响App性能表现的Key。随便查阅四五篇，也就了然于胸了。相比而言，Google搜到的外文技术文章，还有一些App优化的独到见解和处理方式方法，这个会在下文中有所提及。