iceman 10:50:14

网络请求的数据返回使用callback形式和使用事件通知形式相比有什么优缺点?
携程是callback,我们现在用的localbroadcast通知,
同事现在觉得还是callback比较直接,也不用写那么多广播事件的tag来区分.
我也觉得callback写起来比较方便,也方便查看代码,但是似乎比较low?因为耦合度太高?
小白同学你怎么看?
小白 10:53:10

从效率来说，callback。
iceman 10:54:09

执行效率?
小白 10:54:28

从设计来说，callback比较直接，而且很方便java写匿名内部类，这样发送和接收逻辑基本在一起，方便维护方便调试。

iceman 10:54:49

嗯…这是公认的优点
小白 10:55:30

广播需要定义事件id来区分，这势必成为一个全局变量表。全局就是个坑。
iceman 10:56:17

即使使用local的广播?
小白 10:56:43

需要注册、解注册，是无谓的逻辑负担。可以被包装起来自动化处理，但和回调也没有多大区别。
小白 10:58:06

local的广播依然是使用了队列。只不过是在进程内非常快速而已。
iceman 10:58:30

嗯,之前看过一些事件通知的开源项目,eventbus什么的.后来觉得跟android的localbroadcast没啥区别,所以就先用这个通知了.注册和解注册写在基类就好,就是慢慢同事都觉得用起来不方便.
小白 10:59:04

其实，“广播”就已经说明了问题。。。明明不是广播的场景，何必用广播？
iceman 10:59:29

广播就是用于事件通知的啊…网络请求,不也是事件么
小白 10:59:36

就像你想传话给你老婆，非要使用登报、广播、订阅报纸、阅读这一公共渠道，何必。
小白 11:01:00

广播是事件通知的一种没错。但事件通知不止广播这么一种吧？网络请求和响应，反过来就是广播了？
iceman 11:02:21

我是说,事件通知可以用callback,也可以用广播…只不过广播的功能可以更广泛,用于不同页面的,我们目前仅仅是用于当前页面的一些网络事件回传而已…
小白 11:02:48

前提是，如果你有需求。
小白 11:03:31

如果你有需求让发送者不一定是接收者，如果发送接收不一定是一对一关系，那就广播。
小白 11:03:51

而网络请求不符合这个模型。
iceman 11:03:57

嗯.如果可以确定都是一对一关系.那就还是用callback了吧?
小白 11:06:23

理论上广播、消息、总线结构可以做所有事，架构非常灵活。但代价就是，所有成员不管需不需要都得接入总线，这就是成本。总线的结构本身也是成本：比如线程安全、事件驱动等。在复杂模型里这些值得去付出，比如企业级系统里使用JMS。
iceman 11:06:26

嗯,我们之所以有换成callback的原因是:目前的业务和架构在网络请求这个模块上都没有一对多的需求,广播能做的,callback完全能做.
有点点小纠结的是:
1.广播在别的模块还是有用到,比如确实要一对多的情形,既然这样,何不整成一套呢?总是使用适应性更广的方案,似乎也没错.
2.还是那个虚无缥缈的话题,”解耦”的大趋势下…
小白 11:10:10

1，如果需要，那就做。但做出来消息系统可以不包含网络请求和处理，因为网络请求和处理没有这个需求。电脑可以有总线，可以纳入显卡和鼠标这样的极度异构的子系统。但如果显卡渲染单元之间交流都走总线，那就等死吧。。。
小白 11:12:03

2，解耦的目标是可扩展性可维护性，而不是以解得干干净净为目的。干净到变态的极致，那叫过度设计。网上可以搜到用满了23个设计模式的hello world作为模式使用的反例。
iceman 11:13:28

了解了!!可扩展,可维护,那就从callback着手吧.感谢白大神啊.同事一直说要换callback,我还没决定要改,总算能说服自己,开始动手了…
小白 11:14:23

另外，我想起来了，如果是Activities之间传递数据，一个负责发起请求，然后就退到后台或者销毁。然后另一个负责接收处理数据。这种模式确实可以考虑使用总线和消息池。
iceman 11:14:58

嗯.那不属于网络请求嘛.可以再看.情形比较多,就考虑出个方案
iceman 11:15:02

好咯,.干活去咯~
小白 11:15:07

哈哈。
小白 11:15:29

也是网络请求啊。比如说我们公司以前的跳转加载。
iceman 11:15:40

那是坑
iceman 11:15:46

跳转加载并不能增加效率…
小白 11:15:51

为什么？
iceman 11:16:11

在下一个页面的oncreate中开始执行网络请求,并不会慢多少.
iceman 11:16:26

我觉得没有必要为了省这一点点时间,而把架构搞的这么麻烦
小白 11:17:00

主要是。。。你看我们的页面，一个个重的要死，走到oncreate都半天过去了。
iceman 11:17:03

我当初面试的时候说携程的网络请求,说到一个读线程一个写线程,把人家吓尿了…觉得我们好NB
iceman 11:17:16

走到oncreate怎么会半天过去啊
iceman 11:17:26

oncreate那里还没开始页面渲染啊
iceman 11:17:38

基类太重了?
小白 11:17:55

cpu负担，基类，动画。。。各种重。
小白 11:18:42

作用还是有的。但我确实不喜欢使用这么复杂的架构去解决这么小的一个问题。从其他方面优化效果更好。
小白 11:18:53

你们要是不用，那就算了。
iceman 11:19:01

优化一下基类呗..就像当初网络请求的方法重载了10多个一样….哈哈哈,动画嘛.也可以放后面一点
iceman 11:19:13

哈哈..那个得不偿失啊.我们就不用了
iceman 11:21:25

话说我突然想起,那个DialogManager也是一样的道理….小郭把所有界面上需要展示的悬浮控件(单按钮,多按钮,progress,自定义对话框)写到了一起….这个和直接使用某些基类方法,然后传入按钮文字,按钮点击时间监听,优势又在哪里呢?
为了可维护性?
小白 11:21:40

蛋。
小白 11:21:45

那是被方法数逼的。
iceman 11:21:54

卧槽…..
小白 11:25:41

哦严格的说，这得分好几个事。
1，方法数逼的，不用回调和内隐类，用接口。
2，Manager情结，这个好像很多人都有。用对了就算不上错。
3，他爱上了builder模式，因为manager集大成了，所以可配置参数太多，所以builder。
4，其实正确的姿势是继承、多态和匿名回调。但方法数压力更大。。。
iceman 11:26:51

哈哈哈哈…..方法数…看来在这个压力下,我不能认为携程的都是好的了
小白 11:27:52

所幸这年头这个问题越来越小了。