-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
组件化插件化理解 #1
Comments
@chuyun923 假如是四个人同时开发一个 APP ,每个人负责一个模块,我们先想一下正常的开发模式,一个人在自己的模块里写了一个 util(只是一个例子,也可能是其他的类),然后提交代码了,另一个人更新下来了代码,接下来写代码刚好用到了这个 util 里的一个方法或者变量,于是直接就拿来用来,久而久之,这两个模块的耦合度会越来越高。未来某一天,那个人把 util 里的那个方法或者变量删了,结果整个团队都编译不过了。 为什么他们能相互引用呢?因为他们都是作为宿主的一个 library 而存在的啊,都是属于宿主的一部分。如果要想他们之间没有耦合,在没有任何黑科技引入的情况下,就只好把每个模块都打成 apk ,两个完全独立的 apk 工程,是无法引用彼此的类的。而且每个模块都是一个可以独立运行的 apk ,这样就可以去单独地去测试维护这个模块。 而最终是要打成一个 apk 的,因此在 release 的时候,其他模块又不能作为 apk 存在,否则正常情况下无法加载到模块里的类。所以 release 的时候,就把这个模块作为一个 library ,而整个工程就是一个普通的 APP 工程。 但是这样就涉及到可能在 debug 和 release 时候频繁地改代码,于是 Gradle 的优势就体现出来了,通过 Gradle 的配置就可以实现无需更改代码,在我写的 demo 里只需要将 gradle.properties 里的 isDebug 值改一下就可以实现无缝切换了。 |
@liangzhitao 你好,您上面的回答是一些相互之间关联性比较弱的模块可以使用。 不知道面对相互之间有强关联性的情况该如何解决,如下: A.用户登录模块 上面三个模块,B,C 必然需要走过 A 的界面(Activity),不然无法获取到用户信息,这个时候,B,C 模块的开发者该如何独立的进行测试,维护? 因为当A,B,C 作为独立 apk 时并不能共享很多数据,这个时候有些信息的传递反而会复杂。 不知道我理解的对不对,求指导 |
@flyer88 这是个很好的问题。 实际上在 MDCC 上 oasisfeng 也有讲到这个问题,他给出的方案是不管是传递数据还是提供服务,都可以使用 BroadcastReceiver 和 ContentProvider ,甚至是共享进程,来进行通信。这是一种非常轻量的解决方案,同样是不牵涉任何黑科技,甚至是稍微复杂一点的技术。 不过我其实想到有另外一种方案,如果有一些后端的经验或者对 Atlas 有一些了解的话,很容易可以想到 OSGi 这种方式。每个模块单独提供出服务,供其他模块去使用。这是一种比较复杂的解决方案,在组件化这样一个轻量的解决方案里显得重一些,需要在编译期和运行期分别做处理,使得编译期和运行期所引用的类要都能够被找到。 需要注意的一点,本着最大化解耦的原则,这两种方式,都要求当前模块的负责人在提供对外服务的时候,要对所有的可能会用到的接口进行收敛,不管是使用 BroadcastReceiver 和 ContentProvider ,还是类 OSGi ,都要尽可能少地暴露接口。 |
修改app 和 componentizationlibrary下的 gradle.properties配置isDebug为true时,run起来的应该是componentizationlibrary中的LibraryActivity作为LAUNCHER启动?然而我修改成true之后,还是启动的app中的MainActivity。 |
嗯,了解了,修改了gradle.properties之后并不会导致gradle重新构建项目,在build里面加个空格,sync一下就好了 |
有个问题请教下,正如你所说利用gradle配置 在release跟debug包中自由切换是编译生成aar还是apk,对单模块调试很方便,反映到demo中 module app下的bulid.gradle文件中有如下配置 |
@fqcheng220 哪个类引用不到?日志贴一下看看。 |
:app:compileDebugJavaWithJavac - is not incremental (e.g. outputs have changed, no previous execution, etc.). |
@fqcheng220 在 extra_config.gradle 的脚本可以导出一个 Library 的 'sharedDependency.jar' provided fileTree(dir: project(':componentizationlibrary').projectDir.absolutePath + '/outputs/jar/', include: 'sharedDependency.jar') 就是为了引用的时候不报你日志里的这个错误。 |
@liangzhitao 现在实际情况是ComponentizationApp-master目录下 gradle assembleDebug 就会报我提的错误呢(gradle.properties配置为true)但是如果我切换到componentizationlibrary目录下gradle assembleDebug可以正常生成componentizationlibrary对应的apk, 我看了下app模块下有outputs/jar/sharedDependency.jar生成,所以大概是什么原因导致这个错误呢 |
@fqcheng220 demo 是没问题的,你再检查检查吧。 |
@baoyachi :) |
hi, |
@csatshell 真要这样用的话,那就没办法了,至少是我没想到有什么办法。也不建议这样用的,最好一个 module 至少保留一个 Activity ,将 Activity 作为 Fragment 的容器,这样也不容易出现 Fragment 嵌套很多层的情况。 |
求知乎讨论的原贴,我想看看 |
这个思路很棒,很好的解决团队协同开发的问题。用比较小的代价,换来项目的解耦、开发效率的提升。 |
我想问一下,启动别的module的activity可以用action等方式, 那么引用别的module的fragment要怎么引用呢 |
按照你这么说, 还是解决不了那个人把 util 里的那个方法或者变量删了,结果整个团队都编译不过了的问题啊 @liangzhitao |
我遇到和@fqcheng220 类似的问题,如果插件化的思路是为了在debug=true的时候能够进行多个module的并行开发,此时主工程通过shareDependency.jar引入的依赖不会像module一样进行资源合并,这样只解决了依赖存在不报错的问题而不能使得主工程正常执行业务逻辑。既然无法正常运行业务,还不如不要允许主工程成为可运行状态,对于开发者来说更加友好。可以使用类似module处理manifest的方法,将debug=true时候的manifest中主activity注释掉。 |
@csatshell |
hi,很高兴看到您在知乎上的留言,有些问题向您请教一下~~
这一块理解在demo中理解的不是很好。不知是否想表达如下意思:
The text was updated successfully, but these errors were encountered: