Skip to content

Latest commit

 

History

History
125 lines (101 loc) · 7.51 KB

2.0升级指南.MD

File metadata and controls

125 lines (101 loc) · 7.51 KB
Raw

CC 1.x.x 升级到CC 2.x.x升级指南

1. 修改根目录build.gradle

从2.0.0开始，CC的自动注册插件从通用的AutoRegister改为定制化的CCRegister 在根目录需要将插件地址换一下：

buildscript {
    dependencies {
        classpath 'com.billy.android:autoregister:x.x.x' //使用最新版
    }
}

改为

buildscript {
    dependencies {
        classpath 'com.billy.android:cc-register:x.x.x' //使用最新版
    }
}

2. 修改cc-settings.gradle

由于2.0.0开始使用定制化的插件，插件名称发生了变化，并且将许多原来在cc-settings.gradle中的配置已放在插件中完成，减少配置文件的复杂度

为了兼容以前直接apply github上cc-settings.gradle文件的用户，2.0版该gradle文件命名为cc-settings-2.gradle

从2.0.0版本开始，不再推荐直接依赖github上的cc-settings-2.gradle文件，推荐下载到工程根目录下使用，主要原因有：

  • github上的文件偶尔会在编译时出现下载失败的情况
  • cc-settings-2.gradle内容只包含了使用插件和添加对CC库的依赖，其它内容都已移至cc-register插件中维护
  • 此文件是为了给用户避免在每个组件中添加重复的代码使用，可在文件中添加自己的配置逻辑，建议在本地维护
2.1 之前依赖的是github上的cc-settings.gradle文件

之前是通过apply from: 'https://raw.githubusercontent.com/luckybilly/CC/master/cc-settings.gradle'方式接入，按如下方式修改：

  • 未新增/修改任何配置：
    • 下载cc-settings-2.gradle文件到工程根目录，并使用该文件:apply from: rootProject.file('cc-settings-2.gradle')
  • 有类似于cc-settings-demo.gradle的扩展配置文件：
    • 下载cc-settings-2.gradle文件到工程根目录，并使用该文件:apply from: rootProject.file('cc-settings-2.gradle')
    • 将之前在文件中添加的project.ext.registerInfoList.add改为：ccregister.registerInfo.add放到cc-settings-2.gradle文件中
2.2 之前依赖的是本地cc-settings.gradle文件（从github上下载的文件放在工程根目录）

之前是通过apply from: rootProject.file('cc-settings.gradle')方式接入，按如下方式修改：

  • 未新增/修改任何配置：
    • 重新下载cc-settings-2.gradle文件并替换原来的cc-settings.gradle文件（或者复制文件中的内容覆盖原来的内容）
  • 有类似于cc-settings-demo.gradle的扩展配置文件：
    • 重新下载cc-settings-2.gradle文件并替换原来的cc-settings.gradle文件（或者复制文件中的内容覆盖原来的内容）
    • 将文件中的project.ext.registerInfoList.add改为：ccregister.registerInfo.add

3. 调试组件（组件独立以application方式编译运行）

2.0以前，组件切换app/lib运行方式的步骤为：

  • 在local.properties中修改配置： module_name=true
  • sync 或 clean 工程比较大的情况下，sync/clean耗时比较长，影响开发效率 借鉴DDComponentForAndroid的思路： 让所有组件可直接在Android Studio中点击绿色Run按钮独立运行，无需sync和clean

在CC 2.0.0及以上版本中：

  • 不在兼容在module/build.gradle中添加ext.runAsApp=true来实现组件独立运行
    • 但仍然可以通过if (project.ext.runAsApp) { ... }来判断当前module当前是否以app方式编译运行
  • 所有组件可直接在Android Studio中点击绿色Run按钮直接运行
    • 需要注意的是，编译主app时，需要在local.properties添加配置：module_name=true 将单独运行的组件从主app打包依赖项中排除
  • 主app module一直以application方式编译，可以用如下方式来标记：
    • 在module/build.gradle中添加ext.mainApp=true
  • 依赖CC的公共库module（如demo_base/demo_interceptors）一直以library方式编译，可选如下方式中的一种来实现：
    • 直接将CC添加到dependencies列表api 'com.billy.android:cc:x.x.x'，而不是apply cc-settings-2.gradle文件
    • 或者在apply cc-settings-2.gradle之前添加ext.alwaysLib=true
  • 默认情况下通过assemble命令打包是打apk包，若要打aar包，可用如下方式来实现：
    • 在local.properties中添加assemble_aar_for_cc_component=true

4. 启用App内部多进程组件调用功能（如果有需求的话）

注：默认情况下未开启App内部多进程的支持

4.1 启用多进程支持

可下载cc-settings-2.gradle文件到本地根目录，并在文件最后添加：

ccregister.multiProcessEnabled = true

并在组件类（IComponent实现类）上添加一个注解，标明其所在进程（在主进程运行组件无需添加注解）

注意：这样做并不是创建新的进程，而是指定此组件在哪个进程运行（如果AndroidManifest.xml中没有对应的进程，此组件无效）

public class DemoComponent implements IComponent{} //DemoComponent组件在主进程运行
@SubProcess(":yourProcessName") //指定DemoComponentA组件所在的进程名称为 'packageName:yourProcessName'
public class DemoComponentA implements IComponent{}
@SubProcess("a.b.c") //指定DemoComponentB组件所在的进程名称为 'a.b.c'
public class DemoComponentB implements IComponent{}
@AllProcess         //指定DemoComponentC组件在主进程和所有子进程内都存在，每个进程调用进程内部的DemoComponentC组件
public class DemoComponentC implements IComponent{}
4.2 排除App中没有组件的进程名称

为了支持多进程通信，CCRegister插件会在编译时扫描合并后的AndroidManifest.xml文件中所有四大组件 收集所有子进程名称，为每个子进程生成一个RemoteProvider的子类并注册到AndroidManifest.xml文件中

这样做是因为：
如果放在Transform.transform方法中修改，在扫描完class代码之后再修改AndroidManifest.xml，无效
欢迎提PR优化

这将导致一些不含有子进程组件的进程也会生成一个没有任何作用的RemoteProvider的子类，这会额外带来一点点内存消耗。 虽然这种内存消耗是可以基本忽略的，但是还是可以通过如下方式添加配置来避免：

ccregister.excludeProcessNames = [':processNameA', ':processNameB']
4.3 动态组件不支持@SubProcess及@AllProcess注解

动态组件在其被注册的进程中运行，如：在主进程中调用CC.registerComponent(dynamicComponent);,dynamicComponent将在主进程中运行

5 关于性能

5.1 关于CC调用日志

开启verbose日志(CC.enableVerboseLog(true);)后 由于会频繁调用cc.toString()、ccResult.toString()、remoteCC.toString()、remoteCCResult.toString() 会带来一定的性能损耗 故在打正式上线包时，一定要将其关闭CC.enableVerboseLog(false);（默认是关闭状态）

5.2 关于跨App调用

如果要调用的app不是存活状态，或者刚刚重新安装该app或杀掉重启app（这种情况常见于单组件调试时修改代码重新打包运行） 跨进程调用之前，会先唤醒该app，并通过RemoteProvider获取调用该进程组件的句柄：RemoteCCService 由于（app唤醒 -> ContentProvider初始化完成 -> 获取句柄）这个过程需要一定的时间：根据app初始化耗时不同而有差异 所以：跨app调用时，初次调用会消耗大约100ms左右的时间，但这只在开发期间有影响，不会影响正式产品