大佬，跳转的时候，如何附带 Intent.FLAG？

[zomll]

大佬，跳转的时候，如何附带 Intent.FLAG？

[xiaojinzi123]

大佬，跳转的时候，如何附带 Intent.FLAG？

建议使用 Component,这个库很久不维护了
Component 库中附带 Intent.FLAG 可以使用如下的
intentConsumer 去拿到 intent,你也可以使用自定义跳转,那样子你也可以拿到 Intent,具体请看
Component

Router.with(this).host(xxx).path(xxx).intentConsumer(ccc).....

[leobert-lan]

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题

From gitme Android

[xiaojinzi123]

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题

From gitme Android

当初我是学习的态度来看代码的,然后仿造这个项目写,最终一年过来了,我发现这里面其实好多个点有些问题的,当然了可能每个人看法不同,我对那些有问题的要不就是修复了,要不就是去掉了,然后我看到 美团和其他路由框架有页面拦截器这个概念我也吸收进来了,然后我还支持了自定义跳转,通过RxJava 方式拿 onActivity 数据,路由手动和自动取消,具体的我还是希望大佬您能去看下
Component

[YummyLau]

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题

From gitme Android

从 DDComponentForAndroid到jimu，到升级维护的 component。小弟收益匪浅。
但是我一直的想法是 “路由的方案真的是最好的吗？”
通过路由意味着需要维护路由表且需要硬编码，同时除了强大的arouter用于页面跳转场景/api提供场景外，基本项目router用于页面跳转。个人觉得很没有必要。
无论是java/kotlin编程，面向接口编程一直是首要的，特别是开发阶段。所以如果能让组件在非assemble阶段暴露接口，在assemble阶段把接口和实现都进行打包，无疑是极佳的方案。整个开发过程废弃硬编码面向接口编程，依赖组件只需要知道组件暴露的接口，同时解决暴露的接口不需要下沉到公有模块，这才是组件化的极佳归属。 从jimu的思想上孵化了一个插件，同时解决调试配置的问题。目前项目运行良好。 https://github.com/YummyLau/ComponentPlugin 希望您能给一下意见或者建议

[xiaojinzi123]

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题
From gitme Android

从 DDComponentForAndroid到jimu，到升级维护的 component。小弟收益匪浅。
但是我一直的想法是 “路由的方案真的是最好的吗？”
通过路由意味着需要维护路由表且需要硬编码，同时除了强大的arouter用于页面跳转场景/api提供场景外，基本项目router用于页面跳转。个人觉得很没有必要。
无论是java/kotlin编程，面向接口编程一直是首要的，特别是开发阶段。所以如果能让组件在非assemble阶段暴露接口，在assemble阶段把接口和实现都进行打包，无疑是极佳的方案。整个开发过程废弃硬编码面向接口编程，依赖组件只需要知道组件暴露的接口，同时解决暴露的接口不需要下沉到公有模块，这才是组件化的极佳归属。 从jimu的思想上孵化了一个插件，同时解决调试配置的问题。目前项目运行良好。 https://github.com/YummyLau/ComponentPlugin 希望您能给一下意见或者建议

实现组件化, 其实最关键是解决跨组件的调用. 一个纯跨组件调用的框架是 CC, 它没有路由的概念. 就是帮助你实现跨组件调用
另外的就是路由方面的框架了

• Component
• ARouter
• WMRouter
• ActivityRouter

等等都是基于 URI 设计的路由框架. 跨组件调用采用的是 SPI 的思想.

而你说的, 接口不需要下沉就可以实现调用, 除非你像 CC 利用字符串去跨组件.
否则你怎么可能不引用到具体的接口.

调用一个其他模块的具体功能, 你总得给这个功能起个别名或者直接接口暴露给人家, 否则我实在想不出, 这两种都不用可以实现调用另一个模块的功能

最后一点, 我实现想不出你为何说路由没有必要, 你是做何种考虑。你请求后台接口还是写死的 path 呢, 这其实就是一种解耦的方式. 配合配套的插件其实也不会有维护难的问题.
况且, 基于 URI 我看来为什么比其他方案好,

• 是因为 URI 是一个跨语言、跨平台的概念. 如果有一天 IOS 团队也基于 URI 来设计组件化, 那么两端的表现可以是一样的
• URI 天然和 H5 能结合
• URI 这种形式对于后台的配置也更为简单, 只要保存对应的字符串就可以了

我个人感觉, 技术没有错, 但是我觉得很多时候要考虑的大一点. 有兴趣的话你可以去抓包一下很多 App 的接口. 你会发现他们下发的 path 很多都是基于 URI 的.

[leobert-lan]

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题
From gitme Android

从 DDComponentForAndroid到jimu，到升级维护的 component。小弟收益匪浅。
但是我一直的想法是 “路由的方案真的是最好的吗？”
通过路由意味着需要维护路由表且需要硬编码，同时除了强大的arouter用于页面跳转场景/api提供场景外，基本项目router用于页面跳转。个人觉得很没有必要。
无论是java/kotlin编程，面向接口编程一直是首要的，特别是开发阶段。所以如果能让组件在非assemble阶段暴露接口，在assemble阶段把接口和实现都进行打包，无疑是极佳的方案。整个开发过程废弃硬编码面向接口编程，依赖组件只需要知道组件暴露的接口，同时解决暴露的接口不需要下沉到公有模块，这才是组件化的极佳归属。 从jimu的思想上孵化了一个插件，同时解决调试配置的问题。目前项目运行良好。 https://github.com/YummyLau/ComponentPlugin 希望您能给一下意见或者建议

实现组件化, 其实最关键是解决跨组件的调用. 一个纯跨组件调用的框架是 CC, 它没有路由的概念. 就是帮助你实现跨组件调用
另外的就是路由方面的框架了

* Component

* ARouter

* WMRouter

* ActivityRouter

等等都是基于 URI 设计的路由框架. 跨组件调用采用的是 SPI 的思想.

而你说的, 接口不需要下沉就可以实现调用, 除非你像 CC 利用字符串去跨组件.
否则你怎么可能不引用到具体的接口.

调用一个其他模块的具体功能, 你总得给这个功能起个别名或者直接接口暴露给人家, 否则我实在想不出, 这两种都不用可以实现调用另一个模块的功能

最后一点, 我实现想不出你为何说路由没有必要, 你是做何种考虑。你请求后台接口还是写死的 path 呢, 这其实就是一种解耦的方式. 配合配套的插件其实也不会有维护难的问题.
况且, 基于 URI 我看来为什么比其他方案好,

* 是因为 URI 是一个跨语言、跨平台的概念. 如果有一天 IOS 团队也基于 URI 来设计组件化, 那么两端的表现可以是一样的

* URI 天然和 H5 能结合

* URI 这种形式对于后台的配置也更为简单, 只要保存对应的字符串就可以了

我个人感觉, 技术没有错, 但是我觉得很多时候要考虑的大一点. 有兴趣的话你可以去抓包一下很多 App 的接口. 你会发现他们下发的 path 很多都是基于 URI 的.

组件化和路由机制是两个范畴但经常联系在一起谈的东西，组件化研究的是业务的划分解耦，组件的拆分归纳，组件的独立部署和被集成，组件间交互；路由研究的是服务分发、服务注册、以及分发环节中的拦截、降级、错误处理；

如你所说，组件间交互确实是很重要的一环，但基于URI的路由机制并不是解决这一个环节的必要条件，而是一个很成熟、能够避免一些问题的解决方案，理论上，一套能解决服务注册+服务发现+服务调用的解决方案是必要条件。这样的一种机制我们可以广义的、笼统的、不严谨的都称之为路由方案，但不一定是基于URI的，在以前，我习惯称之为：一种IoC容器。

那么基于URI的路由方案有啥特殊好处呢：

• 按照URI的规则去描述你的意图（协议），目标（domain和path），数据（querystring）

• 一个语法式（URI）表达了内容，这个语法式可以实现多端统一而不用再做中间映射层

有好处当然也有坏处，坏处就是你要维护你可能写死的、hardcode的语法式（URI）

按照伟大的神棍卡尔-马克思的想法，这玩意只要能解决我们的问题，那就可以拿来用，至于里面用不着的东西，爱扔扔

@YummyLau @xiaojinzi123

[YummyLau]

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题
From gitme Android

从 DDComponentForAndroid到jimu，到升级维护的 component。小弟收益匪浅。
但是我一直的想法是 “路由的方案真的是最好的吗？”
通过路由意味着需要维护路由表且需要硬编码，同时除了强大的arouter用于页面跳转场景/api提供场景外，基本项目router用于页面跳转。个人觉得很没有必要。
无论是java/kotlin编程，面向接口编程一直是首要的，特别是开发阶段。所以如果能让组件在非assemble阶段暴露接口，在assemble阶段把接口和实现都进行打包，无疑是极佳的方案。整个开发过程废弃硬编码面向接口编程，依赖组件只需要知道组件暴露的接口，同时解决暴露的接口不需要下沉到公有模块，这才是组件化的极佳归属。 从jimu的思想上孵化了一个插件，同时解决调试配置的问题。目前项目运行良好。 https://github.com/YummyLau/ComponentPlugin 希望您能给一下意见或者建议

实现组件化, 其实最关键是解决跨组件的调用. 一个纯跨组件调用的框架是 CC, 它没有路由的概念. 就是帮助你实现跨组件调用
另外的就是路由方面的框架了

• Component
• ARouter
• WMRouter
• ActivityRouter

等等都是基于 URI 设计的路由框架. 跨组件调用采用的是 SPI 的思想.

而你说的, 接口不需要下沉就可以实现调用, 除非你像 CC 利用字符串去跨组件.
否则你怎么可能不引用到具体的接口.

调用一个其他模块的具体功能, 你总得给这个功能起个别名或者直接接口暴露给人家, 否则我实在想不出, 这两种都不用可以实现调用另一个模块的功能

最后一点, 我实现想不出你为何说路由没有必要, 你是做何种考虑。你请求后台接口还是写死的 path 呢, 这其实就是一种解耦的方式. 配合配套的插件其实也不会有维护难的问题.
况且, 基于 URI 我看来为什么比其他方案好,

• 是因为 URI 是一个跨语言、跨平台的概念. 如果有一天 IOS 团队也基于 URI 来设计组件化, 那么两端的表现可以是一样的
• URI 天然和 H5 能结合
• URI 这种形式对于后台的配置也更为简单, 只要保存对应的字符串就可以了

我个人感觉, 技术没有错, 但是我觉得很多时候要考虑的大一点. 有兴趣的话你可以去抓包一下很多 App 的接口. 你会发现他们下发的 path 很多都是基于 URI 的.

你没有好好看 https://github.com/YummyLau/ComponentPlugin 的文档。确实是不需要下沉就能解决。你说的没错，但是对于组件来说router确实是非必要的。 leobert-lan 的回答很对。

[YummyLau]

@leobert-lan 确实如此。 组件化研究的是业务的划分解藕，无论用不用路由，能解决的都是好方法。 @xiaojinzi123 诚如所说，技术没有错，可能理解不同。

[xiaojinzi123]

@leobert-lan 确实如此。 组件化研究的是业务的划分解藕，无论用不用路由，能解决的都是好方法。 @xiaojinzi123 诚如所说，技术没有错，可能理解不同。

上面说了, 组件化的核心其实就是解决跨组件调用的都可称为组件化.
侧重点不同, 我们基于 URI 的是更多的关注路由方面. 跨组件调用也是支持的. 而你们可能是把跨组件调用做的更好.

另外你加我 347837667, 我和你聊一下你的这个项目. 我觉得我会给你一些好的建议了, 这里我就不回复了

[YummyLau]

@leobert-lan 确实如此。 组件化研究的是业务的划分解藕，无论用不用路由，能解决的都是好方法。 @xiaojinzi123 诚如所说，技术没有错，可能理解不同。

上面说了, 组件化的核心其实就是解决跨组件调用的都可称为组件化.
侧重点不同, 我们基于 URI 的是更多的关注路由方面. 跨组件调用也是支持的. 而你们可能是把跨组件调用做的更好.

另外你加我 347837667, 我和你聊一下你的这个项目. 我觉得我会给你一些好的建议了, 这里我就不回复了

嗯嗯 ，一起交流 😊 😊

[YummyLau]

@leobert-lan 确实如此。 组件化研究的是业务的划分解藕，无论用不用路由，能解决的都是好方法。 @xiaojinzi123 诚如所说，技术没有错，可能理解不同。

上面说了, 组件化的核心其实就是解决跨组件调用的都可称为组件化.
侧重点不同, 我们基于 URI 的是更多的关注路由方面. 跨组件调用也是支持的. 而你们可能是把跨组件调用做的更好.

另外你加我 347837667, 我和你聊一下你的这个项目. 我觉得我会给你一些好的建议了, 这里我就不回复了

加了你微信呢～ 你留意下哈，我木有扣扣