写的教程很不容易看明白

supersugar commented 6 years ago

不知道是不是就我自己这么觉得...

MugWorld commented 6 years ago

我也觉得

hhyy1986 commented 5 years ago

+1

wangzhiyuan commented 5 years ago

+1

liulinjie1990823 commented 5 years ago

+100

luckybilly commented 5 years ago

@supersugar @MugWorld @hhyy1986 @liulinjie1990823 @wangzhiyuan 新版文档地址：https://luckybilly.github.io/CC-website/

hao321 commented 5 years ago

教程的顺序有点问题，还没写怎么在主app中怎么引入cc的依赖呢，就开始写用cc调用组件了，让人看着有点懵

xiaojinzi123 commented 5 years ago

建议使用基于 URI的库并且贴近Android原生的使用,原因我写了一篇文章阐述为什么我不建议使用CC,如何可以不妨试试 Component

luckybilly commented 5 years ago

@xiaojinzi123 很高兴看到这样一篇讲解CC缺点的文章，这说明CC框架已经有被黑的资格了 :D

确实，每个框架都会有它的缺点，CC也不例外。

从文章内容看来，你可能是对CC的一些细节了解的还不太全面，我逐个作一下说明吧：

注：以下标题对应文章中的标题，文章中的原文用引用的方式表示（展示为整行的灰底文字）

CC配置不简单

它配置的方式,我不说的话新人一脸懵逼吧？

addComponent是CC中独有的用法，不看文档，确实会一脸懵逼。但是，看文档这个要求不过分吧。

另外，文章中的2张截图其实不太准确：

第一张图中的代码是CC框架下在主app module/build.gradle中依赖组件的方式，它的用法在demo/build.gradle和CC文档中都有充分的说明，是CC为了便于组件化框架下的开发及调试做的一个小优化，主要功能有：
- 完全的代码隔离（编码阶段在主app module中无法引用到组件里的代码）
- 开发调试期间，可以在local.properties中修改配置，将组件从主app module打包的apk中排除，而不用修改主app module/build.gradle代码，开发期间的配置修改不影响持续集成编译环境（如：jenkins）的打包产物
- 无需修改任何配置，无需sync，无需clean，所有组件module可以直接在android studio中点击绿色Run按钮以application方式编译运行
- addComponent写在build.gradle的dependencies下，与implementation/api等用法高度相似，十分简洁

第二张图片中的代码，是从cc-settings-demo.gradle中截图的，它是github源码demo中演示的高级功能（自动注册和一个开关），从截图中也可以看到注释有写“搭顺风车”，它并不是使用CC所必须配置的

文章中没有说到的是：

使用CC，所有组件module中的配置是：需要将build.gradle中的apply plugin: 'com.android.library'或apply plugin: 'com.android.application'替换为apply from: rootProject.file('cc-settings-2.gradle')，仅此而已，（创建一个组件module的详细说明可点击这里查看）

对CC库的依赖及apply cc-register插件都在此文件中（可以额外配置使用一些高级功能，不需要的话，完全可以不开启）

相比于文章中贴出的其它组件化框架每个业务模块的build.gradle中的配置：

CC无需在所有模块中添加annotationProcessor的相关依赖及配置
CC无需在所有模块中添加对组件化框架的依赖
CC无需在所有模块中设置此module当前是否以application方式单独编译运行

应该基于Uri

组件化一般都是和 iOS 端同时提供,方便H5和后台针对 Uri 对移动端跳转的控制,而不是像 CC 一样自己玩自己的

相信绝大多数的公司，都是同时有android和iOS的开发需求的，至于H5和原生的跳转需求也基本上都存在，既然有不少人选择了使用CC，难道他们不需要与H5交互，没有推送功能吗？

不知道你是如何得出CC是自己玩自己的这种结论的，可能是对CC这种方案理解不够深入的原因吧。

如果两个端都用URLscheme的方式，当然没有问题，但URLscheme也不是唯一的实现方案吧。

在iOS的组件化方案中，有一种基于target-action的方案，其思想与CC异曲同工，利用iOS中的runtime机制，可以轻易地封装出来。如果不想自己封装，也有现成的开源框架可供使用：CTMediator

方便H5和后台针对 Uri 对移动端跳转的控制

H5调用原生组件，除了URLscheme之外，还有jsBridge方式(不管jsBridge是通过什么方式实现，例如：addJavascriptInterface、JsBridge等)

在jsBridge中使用CC后，可以达到在js中调用原生任意组件的效果

不需要为使用URLscheme而额外创建一个无实际意义的中间Activity，何况这个中间Activity还有被外部恶意调用的风险

重要的是：不仅仅是页面跳转哦（后台推送功能也可以类似地来实现）~

CC 在很多目标界面需要 CC.sendCCResult

CC.sendCCResult(callId, ccResult)确实是实现组件时必须调用的，而且是要确保在所有逻辑分支中都必须会调用到。这确实是CC的一个缺点，在CC的文档中也多处强调过了

文章中所说的在目标界面需要调用，属于实现组件中的一种异步实现，在activity完成操作后组件功能才执行结束的情况，这种情况下的使用可以用来替代startActivityForResult的繁琐写法。但这种实现确实存在一定的框架侵入性，开发者可以封装一个工具类用于解决这种侵入性，做法我在文档：'CC框架实践(3): 让jsBridge更优雅'中的Tips中作了提示。

那么对于系统或者第三方的界面呢？都是通过 setResult 返回信息给你的,你怎么把 CC.sendCCResult 放到不是你写的界面上？

这是组件所提供的具体功能，不属于CC框架的范畴（CC的立足点是解决组件调用而非具体的页面跳转功能），可以用上面所说的封装工具类来实现这种针对三方库或者系统的startActivityForResult的调用

CC所谓的跨进程调用,渐进式组件化

能跨进程进行组件调用，从而支持渐进式组件化改造，是CC的最大特色。

那么其实这时候你随便使用哪个组件化方案,其实拆分的速度都会很快,因为你只要保证切断每一个界面的联系和调用就可以移动相关的类到所属的模块了.可以优先移动那些使用频率高的业务界面,比如登陆相关率先移动到 User 模块下.那么后面开发的业务模块直接包含 User 业务模块模块即可单独运行.其实在我看来根本没有必要所以的跨进程调用

这个观点我不太认同，老项目拆分组件的解耦工作，谁做谁知道。

User模块基本上与所有的模块都有关联，在很多实际项目中User模块的耦合度相当高，如果一上来就要解耦User模块，很多团队就会因为时间关系导致组件化改造工作迟迟不能开展。

CC通过跨进程组件调用的方式，将陡峭的组件化改造实施曲线拍平，实现真正意义上的渐进式组件化（解耦只是过程，而不是前提）

CC 跨进程调用传递的是 json,难道你还会新建一个实体对象去接 json 吗？

请看一下github上的源码，在demo中调用单独运行的组件demo_component_b中的登录功能，并获取返回值的demo代码:演示跨app传递自定义类型及各种集合类型

另外，CC从2.0版开始，支持app内部的多进程组件调用

值得一提的是：不管被调用组件是在当前进程还是在其他进程运行，也不管组件是在当前app还是在其他app运行，组件的实现和调用的代码无需作出任何改变

需要让开发者弄这些花里胡哨的吗？

这是CC为了解决渐进式组件化改造核心诉求而选择的实现方式，我并不觉得它花里胡哨哦

以前参加饿了么的技术分享,它们的测试运行包都是去平台上选择需要测试的业务模块然后平台会负责依赖选择的模块然后打出一个 Apk

解耦后（或者不存在耦合的情况下），CC的组件同样可以选择模块然后打出一个Apk。当然，这个管理后台需要自行实现，CC作为一个android组件化开源框架并未提供这个功能

我觉得 CC 这种真的没必要了.害人害己

对于技术选型，永远是最适合自己项目的才是最好的，我之前也有过一次总结：多个维度对比一些有代表性的开源android组件化开发方案

至于是否害人，见仁见智吧~

更多未尽内容，欢迎加入CC交流群（QQ群：686844583）讨论交流。

luckybilly / CC