口碑 App 各 Bundle 之间的依赖分析指南

举报
橘座 发表于 2019/10/14 18:47:26 2019/10/14
【摘要】 背景口碑的 O2O 业务 Bundle,目前需要在支付宝和口碑独客这两个 App 中的运行。目前口碑 App 也是使用 mPaaS 框架,一些基础服务比如 ConfigService,H5 容器,RPC 网络库,AntUI 库,Sync,扫码,Push 等,和支付宝保持一致,并对于不兼容的地方进行拉分支单独改造,对于支持多 App 的 Bundle,直接使用支付宝的基线。那么,每次业务在支付...

背景

口碑的 O2O 业务 Bundle,目前需要在支付宝和口碑独客这两个 App 中的运行。目前口碑 App 也是使用 mPaaS 框架,一些基础服务比如 ConfigService,H5 容器,RPC 网络库,AntUI 库,Sync,扫码,Push 等,和支付宝保持一致,并对于不兼容的地方进行拉分支单独改造,对于支持多 App 的 Bundle,直接使用支付宝的基线。

那么,每次业务在支付宝上发版之后,同步到口碑 App 时,都需要将口碑 App 的基线进行升级。所谓基线升级,就是将支付宝中对应的 Bundle 版本号同步到独客,将有定制分支的 Bundle 进行代码 merge。支付宝 App 有几百个 Bundle,而口碑 App 的 Bundle 规模也已达到相似规模。

这几百个 Bundle 中,其中几十个 Bundle 是口碑 App 有分支定制以及特有的,剩下的 Bundle 直接从支付宝已有体系内进行索引。

为了减小包大小,我们需要确定这些 Bundle 之间的依赖关系,更确切一点,我们想知道这些 Bundle 的依赖程度:如果删除某个 Bundle,将会对剩余的哪些 Bundle 有影响?有哪些 Bundle 可以直接删除?解决这些问题,我们需要分析这几百多个 Bundle 的依赖关系。

1. Bundle 依赖分析方法

几百个 Bundle,靠人工一个个看,是梳理不过来的。而且,每个版本都有代码更新,依赖关系都有可能变化。因此,需要我们开发对应的工具进行分析。

方案 1:分析 build.gradle

我们知道,在 Android 开发中,如果我们需要依赖某个 Jar 包,我们会在 module 的 build.gradle 中添加,比如:

 dependencies {        provided 'com.alipay.android.phone.thirdparty:fastjson-api:1.1.45@jar'

        provided 
'com.alipay.android.phone.thirdparty:wire-api:1.5.3@jar'

        ...

 }

对于某个 Bundle,我们可以通过分析 Bundle 中的 module,然后解析 build.gradle 文件,获取 Bundle 之间的依赖。


1667cd6ebd25a46d?w=828&h=375&f=png&s=73324

【结论】

这种方案出现的问题:

  • dependencies 的依赖可能有冗余,会有多余的 dependencies 出现,会影响结果的准确性;

  • 这种方案我们只能在知道 Bundle 之间的依赖关系,并不知道依赖了其中的多少个类?有哪些地方依赖?

方案 2:分析每个 Bundle 的每个 Java 文件的 import 区域

为了解决方案 1 中的问题,我们使用方案 2 进行依赖分析,就是分析每个 Bundle 的每个 Java 文件的 import 区域,然后建立它们之间的映射关系。


1667cd6c106d1ade?w=807&h=101&f=png&s=10704

以 o2ocommon 这个 Bundle 为例,bundle、module、class 和 import 的区域关系如下:


1667cd9249f83c1a?w=1920&h=1080&f=jpeg&s=739883

然后,我们将 Bundle 之间的依赖,转换为分析 Java 文件之间的依赖;并且能够计算出 Bundle 之间有多少个类依赖,以及依赖了多少次。

【结论】

方案 2 通过

2. 方案实施:JDA 依赖分析工具开发

2.1 拉取每个 Bundle 对应的源码

通过脚本,将 Bundle 对应的 gitlab 代码库拉取到的本地,切换到需要的分支。

2.2 根据 setting.gradle 创建 Bundle

遍历 Bundle 目录,如果查找到 setting.gradle 文件,就创建一下 Bundle 对象:

public class Bundle implements Serializable, Comparable<bundle> {    private String localPath;    private String name;//文件夹名称
    private List<gradlemodule> moduleList;//包含的module
    private String packageId;    private String groupId;//groupId
    private String artifactId;//artifactId

    private Map<bundle> dependencyMap;//依赖关系表
    ...
}

2.3 根据 build.gradle 创建 module

创建好 bundle 之后,遍历 bundle 的子目录,查找 build.gradle 文件,然后创建 module 对象:

public class GradleModule implements Serializable{    private String localPath;    private String name;//module的名称
    private Bundle bundle;//隶属那个Bundle
    private List<javafile> javaFileList;//module包含的import
    ...
}

2.4 查找 Java 文件所在的 src 目录,创建 JavaFile

查找 build.gradle 中的 src 属性,找到 Java 代码的存放位置,获取 *.java 文件的列表,创建 JavaFile 对象:

public class JavaFile implements Serializable {    private String className;//类全称
    private List<importmodel> imports;//该类的imports文件
    private GradleModule parentModule;//所在的Bundle
    ...
}

2.5 解析 Java 文件

这一步是整个方案的核心,需要解析 Java 的语法,将 Java 文件的 import 区域过滤出来。

2.6 整理 import 区域,删除多余的 import

将 import 的类文件,在 Java 文件中进行搜索,如果未引用到,则删除该 import,如果存在,则保留。然后创建 import 对象:

public class ImportModel implements Serializable {    private String className;//该import的包名+类名
    private Bundle dependBundle;//该类所在的Bundle
    ...
}

2.7 建立映射关系表 Map

经过上述递归算法,我们建立了 Bundle、Module、JavaFile、ImportModel 之间的树结构。并且保存了所有 Java 文件与其所属 Bundle 之间的映射关系。

    private Map<string> mJavaFileBundleMap = new LinkedHashMap<>();//Java文件与所属Bundle之间的映射关系
    private List<javafile> mAllJavaFile = new ArrayList<>();//所有Java文件的List
    private List<bundle> mBundleList = new ArrayList<>();//所有Bundle的List

3.8 依赖分析

   /**
     * 依赖分析
     * mochuan.zhb@alibaba-inc.com
     */
    private void dependenciesAnalysis() {        for (JavaFile javaFile : mAllJavaFile) {//遍历所有的Java文件
            //获取Java文件的Import区域列表
            List<importmodel> importModelList = javaFile.getImports();            //获取当前Java文件所在的Bundle
            Bundle currentBundle = javaFile.getParentModule().getBundle();            //获取当前Bundle与其他Bundle依赖映射表
            Map<bundle> dependencyMap = currentBundle.getDependencyMap();            if (dependencyMap == null) {
                dependencyMap = new HashMap<>();
                currentBundle.setDependencyMap(dependencyMap);
            }            if (importModelList == null || importModelList.size() == 0) {                continue;
            }            //遍历Import列表
            for (ImportModel importModel : importModelList) {
                String importClassName = importModel.getClassName();                if (isClassInWhiteList(importClassName)) {                    continue;
                }                //查找import中类,所在的Bundle
                Bundle bundle = mJavaFileBundleMap.get(importClassName);                if (bundle == null) {                    //没有查到该类所在的Bundle
                    JDALog.info(String.format("%s depend bundle not found.", importModel.getClassName()));
                } else if (bundle == javaFile.getParentModule().getBundle()) {                    //内部依赖;该import类和当前类在同一个Bundle中
                    JDALog.info("internal depend.");
                } else {                    //currentBundle依赖bundle
                    Dependency dependency = dependencyMap.get(bundle);                    if (dependency == null) {
                        dependency = new Dependency();
                        dependencyMap.put(bundle, dependency);
                    }                    //将依赖次数+1
                    dependency.setDependCount(dependency.getDependCount() + 1);                    //能找到对应的Bundle依赖
                    JDALog.info(String.format("%s depend %s", javaFile.getParentModule().getBundle().getName(), bundle.getName()));
                }
            }
        }
    }

3. 依赖结果分析

我们把有相互依赖的 Bundle 进行连线,得到如下图:


1667cda2d1d38636?w=1169&h=872&f=png&s=910614

化成圆形的图为:


1667cda55136074e?w=964&h=821&f=png&s=930797

为了更加准确地衡量 Bundle 之间的依赖程度,后续我们可以将依赖关系转换成 markdown 表格形式:更具体地展示 Bundle 之间依赖、以及被依赖的情况,以及被依赖多少次也能够清晰展现。除此之外,我们甚至可以知道具体是依赖哪个类。

4. 总结

1. 上述分析方法有效:

有了上述分析结果,为我们后续减小包大小、增删 Bundle、Bundle 升级提供了强有力的指导,为后续解除 Bundle 之间的依赖提供了详细的数据参考;

2. 从依赖表中,我们也可以看到哪些 Bundle 是叶子节点,可以根据是否叶子节点确定 packageId 的分配。

3. 对于通过反射的方式进行依赖的情况,目前还比较难统计到:

比如 Class.forName("com.koubei.android.xxx") 之类的,后续可以考虑其他方案进行完善。

本文转载自异步社区

原文链接:https://www.epubit.com/articleDetails?id=N83cbe0af-bb91-4a2a-8f4c-ffad741ae8e5


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。