13518219792
本文是组件化项目的时候关于BuildConfig的一些小知识点，因为Module解耦，不同的Module很难区分环境，所以我主要在BaseModule的build文件里面定义一个变量，主要是针对线上和线下环境，当然读者可以自定义更多的变量，希望对你有所帮助。
成都创新互联公司咨询电话：18982081108，为您提供成都网站建设网页设计及定制高端网站建设服务，成都创新互联公司网页制作领域10年，包括宣传片制作等多个行业拥有丰富的网站营销经验，选择成都创新互联公司，为网站锦上添花！
BuildConfig是android在编译过程中自动生成的一个配置文件。
在不同的编译模式下会生成不同的变量，我们可以利用这些变量来方便不同编译环境下的开发，比如日志的打印（开发环境下可以打印Verbose一级，发布环境下可以打印Warn一级）。
没有自己变动过gradle文件的话，自动生成的BuildConfig一般如下文所示。
如图所示
同java常量。
可以的。
在app模块的build.gradle中（不是Project的），有个buildTypes节点，我们修改如下。
其中 isDebug 是我们自己定义的，编译后的 BuildConfig 为
可以看到系统已经为我们生成了.
手机硬件现在都是固定的，不像台式电脑可以组装，如果组件化了你就可以根据自己需求买各种硬件组装到一起，就像某个手机性能好像素也好，可你就打游戏几乎不照相，就得多花钱，要是自己选就要好性能，相机差不多的就行。
完全可以，而且在淘宝、微信等 App 已经实现并应用，主要利用 Java ClassLoader 的原理，对于 Android 来说是 DexClassLoader，如下
DexClassLoader pluginClassLoader = new DexClassLoader(dexPath, optimizedDirectory, libraryPath, parentClassLoader);
可动态加载的内容包括 apk、dex、jar 等
我也利用这个原理及开源项目实现了一个版本，并且整理了 Android 插件化的作用、概念以及不错的资料(包括开源项目)和解决方案。
其中包括 65535 问题，Android 插件化、Android 组件化、Android 动态加载、Android 动态升级；介绍 DexClassLoader 和 PathClassLoader 的区别；如何解决生命周期管理、资源访问问题，如何消除公共依赖
1，app compile project加入module后，module的权限，资源文件，权限，依赖引入，application属性权限，注意冲突，
application属性权限主包没引入的，module不能引入，超权限控制无法编译，
依赖引入，要是module已经引入所需依赖，主包不需引入，避免冲突
多module开发，其中的一个为入口module，其他module为独立的“应用”（library）
1.在原有的项目导入另外个项目的module为主项目的次module，即在A项目中添加一个启动B项目的入口
1）右击B项目的module，选择copy path；
2）右击A项目，New—Module—Import Gradle Project，把上一步拷贝的路径粘贴，一直到完成；
2.build.gradle文件
1）主module配置为 apply plugin: 'com.android.application'，次module为 apply plugin: 'com.android.library'；
2）次module不需要applicationId
3）dependencies依赖需放入到次module
4）都加上 multiDexEnabled true
5）主module导入次module ：compile project(path: ':module2')
6）.build.gradle中设置的compileSdkVersion buildToolsVersion minSdkVersion targetSdkVersion统一
3.AndroidManifest.xml文件
1）主module 在application上加上tools:replace="android:name,allowBackup,icon,theme,label"
同时在顶端加上xmlns:tools=""；主要是避免多module的name,icon,theme等冲突
2）次module把application下的android:name，android:icon，android:label删除，否则安装后，在桌面上会有多个图标；
3）次module去掉activity的主过滤器 intent-filter
4.资源文件的冲突
jar包的冲突，检查是否重复，在module中都存在了；
类名、文件名等，重复可去修改其中一个，避免重复，资源索引出问题。
基本上就是这些，主要是rebuild后看报的什么错，具体的问题具体去分析处理。
开源的Github Android客户端，基于Kotlin，组件化开发
整个App分为基础模块Module_base和业务模块Module_Business
github地址
原理：实现原理上都选择尽量少的hook，通过在manifest上预埋一些组件实现四大组件的插件化。其中Small更形成了一个跨平台、组件化的框架。
VirtulApp：
能够完全模拟app的运行环境，能够实现免安装应用和双开技术。
Atlas：
阿里出品，号称是一个容器化框架，结合了组件化和热更新技术。
Android中有两种类加载器，DexClassLoader和PathClassLoader，它们都继承于BaseDexClassLoader。
两者的区别：DexClassLoader多了一个optimizedDirectory的路径参数，这个目录必须是内部存储路径，用于缓存系统创建的Dex文件。
所以我们可以使用DexClassLoader去加载外部Apk中的类。
ClassLoader调用loadClass方法加载类采用了双亲委托机制来避免重复加载类。
首先，ClassLoader会查看自身已经加载的类中是否已经存在此类，如不存在，然后，则会使用父类来加载此类，如不能成功加载，则会使用自身重载于BaseDexClassLoader的findClass()方法来加载此类。
DexClass的DexPathList在DexClass的构造器中生成，findClass()方法则是从DexPathList下面找出对应的DexFile，循环DexElements，通过dexElement.dexFile取出对应的DexFile，再通过DexFile.loadClassBinaryName()加载对应的类。
作用：使用插件DexClassLoader加载出需要的类。
通过每一个插件的DexClassLoader加载出自身所需要的类，当每一个插件需要加载相同的类库时，可采用该类库的不同版本来使用。
通过把每一个插件的pathList（DexFile）合并到主app的DexClassLoader上，来使各个插件和主app直接能够相互调用类和方法，并且各个插件中相同的功能可以抽取出来作为一个Common插件供其它插件使用。
插件调用主工程
在ClassLoader构造时指定主工程的DexClassLoader为父加载器即可直接调用主工程中的类和方法。
主工程调用插件
如果是多DexClassLoader的情况，则需要通过插件的DexClassLoader加载对应的类并反射调用其方法。此种情况，主工程一般会在一个统一的地方对访问插件中的类和方法做一些访问权限的管理及配置。
如果是单DexClassLoader的情况，则可以直接调用插件中的类和方法。但是当多个插件引用的库的版本不同时，会出现错误，因此，建议采用Gradle版本依赖管理统一处理主工程及各个插件的库依赖。
Android通过Resource来加载资源，只要有插件apk，就可以使用assertManager.addAssertPath（apkPath）的方式来生成assertManager，再使用其new出对应的Resource对象即可。
注意：由于AssertManager并不是Public，所以需要通过反射的方式去调用它。并且由于一些Rom对Resource的处理，所以，需要兼容处理。
有2种处理方式：
产生的原因：由于主工程和各个插件引用的Resource id重复产生的冲突。
解决思路：Android中的资源在系统中是以8位16进制0XPPTTRRRR的方式存在，其中PP即是资源区分的区域（Android系统只用它来区分系统资源和应用资源），只要让每一个插件的PP段取不同的值即可解决资源id冲突的问题。
具体解决方式：
1.修改aapt源码，编译期修改PP段。
2.修改Resource的arsc文件，其中的每一条都包含了资源id和映射路径。
Activity的处理最为复杂，有两种处理方式：
1.ProxyActivity的方式。
2.预埋StubActivity，hook系统启动Activity的过程。
原理：VirtualAPK通过替换了系统的Instrumentation，hook了Activity的启动和创建，省去了手动管理插件Activity生命周期的繁琐，让插件Activity像正常的Activity一样被系统管理，并且插件Activity在开发时和常规一样，即能独立运行又能作为插件被主工程调用。
Android插件化方向主要有2个方向：
Android 插件化
