TGFC Lifestyle - Powered by Discuz! Board

标题: [数码手机] 我来科普一下：通知和轮询的区别 [打印本页]

作者: 潜水艇的水 时间: 2011-6-23 20:14 标题: 我来科普一下：通知和轮询的区别

我还是单独开一贴吧，免得再哪贴里面光喷去了。。。
通知实现的方法，按我的理解和linux下很多程序实现的方法如下：
程序再起socket的时候，设定socket为柱塞的方式，也就是说socket监听端口的时候，如果没有数据，监听进程就是挂起休眠起来，实际上，这个时候程序已经休眠，不占用cpu资源，也就谈不上费电，当基带从空口获取到一个数据片的时候，底层会触发一个中断给cpu，cpu判断这个中断类型，如果是ip包，cpu会吧数据传给tcp/ip协议栈，协议栈根据socket注册情况，唤醒相应的程序，这个时候就可以切换到真正处理的app里面去了，这样实现起来省电，高效，但是ios悲催的内存大小和进程调度方式，可能会导致休眠的程序丢失一部分进程资源，导致切换会app的时候，可能还需要重新登陆==一系列动作，这样造成用户体验不好，但是我觉得这个机制是非常适合手持设备的，希望将来ios能解决进程切换的问题。这就是为什么有个兄弟说一个ios设备给另外一个ios设备发消息，可能再1秒以内能收到的原因。因为全部都是主动触发的方式，相当于多米诺骨牌一样，自然速度会很快

所谓轮询的方式，
哪就是很多现在pc和android上实现的方法，注册socket为非柱塞的方式，也就是说socket监听端口的时候，如果没有数据，监听进程就会放过这次监听，使用timer/sleep 固定时间，然后到一个门限的时候，比如说1秒/30秒的时候，主动向server发送查询的数据包，server查询结果，然后返回给设备，设备就知道这个查询时间片内有没有本程序的数据，这样实现起来费电，复杂，但是由于android使用linux进程调度算法，最终结果看起来也是可以接受的。

以上2中方式差别，再linux和xp下面使用ping就可以看到差别，linux ping包的延时可能再1ms级别，xp就是10ms级别，延时差的很远。性能也差不少，至于android为什么不使用push通知+完善的后台调度，我只能说这是历史原因造成的，以前android就是个野孩子，没有通知服务器这种数据中心，直接蛮干就ok了。导致出现现在各种费电的程序跑再后台。

作者: burnfox 时间: 2011-6-23 20:33

飞行模式、不开第三方后台的原生Android也很耗电是怎么回事？它在轮询什么？电量统计？

[ 本帖最后由 burnfox 于 2011-6-23 21:01 编辑 ]

作者: jun4rui 时间: 2011-6-23 20:39

posted by wap, platform: Chrome

Android是轮询和推送并存，官方的是推送，第三方的是轮询

作者: jun4rui 时间: 2011-6-23 20:49

posted by wap, platform: Chrome

不用瞎猜了，我给出Google日历和联系人的同步时序图吧：

作者: jun4rui 时间: 2011-6-23 20:51

posted by wap, platform: Chrome

具体这里有：http://mysuperbaby.iteye.com/blog/902054

作者: kamuiyay 时间: 2011-6-23 20:56

我觉得这个帖子里2楼完全是多余的
当然大家看完我这句话也可以把我这楼忽略

作者: 潜水艇的水 时间: 2011-6-23 21:05

引用:

原帖由 jun4rui 于 2011-6-23 20:51 发表
posted by wap, platform: Chrome

具体这里有：http://mysuperbaby.iteye.com/blog/902054

这个只是消息流程图，不是具体实现机制上的讨论

作者: 潜水艇的水 时间: 2011-6-23 21:07

引用:

原帖由 jun4rui 于 2011-6-23 20:49 发表
posted by wap, platform: Chrome

不用瞎猜了，我给出Google日历和联系人的同步时序图吧：

还有，我相信google自己的消息都是push机制的。而且应该实现的很好。

作者: 潜水艇的水 时间: 2011-6-23 21:09

引用:

原帖由 burnfox 于 2011-6-23 20:33 发表
飞行模式、不开第三方后台的原生Android也很耗电是怎么回事？它在轮询什么？电量统计？

不至于吧，飞行不开第三放后台程序一个晚上能耗多少电？能超过10%么？

作者: jun4rui 时间: 2011-6-23 21:11

posted by wap, platform: Chrome

你可以看时序图的发起方，显然有变动后，是服务器主动发起的。

而且里面说了：

Google Sync是通过Atom Feed协议进行的. 这样当Server端有changes后, 会通过C2DM框架发送"com.google.android.c2dm.intent.RECEIVE" action给SubscribedFeedsBroadcastReceiver, 而SubscribedFeedsBroadcastReceiver在onReceive()方法启动SubscribedFeedsIntentService.

是服务器发生变动后，通过C2DM发送消息到接收方的。

作者: burnfox 时间: 2011-6-23 21:14

引用:

原帖由 潜水艇的水 于 2011-6-23 21:09 发表

不至于吧，飞行不开第三放后台程序一个晚上能耗多少电？能超过10%么？

7个小时11%，未root

在tompda老卖家那买的，以前也买过好多次了，没问题，电池连个触点划痕都没有，所以相信是原装电池。

作者: zmqzmq2010 时间: 2011-6-23 21:15

LZ我就请教1个问题：
IOS5敢于把维特+IM+云端大量数据同步集成到系统内核里，是否代表苹果自家PUSH服务器+系统推送部分的可靠性足够应付QQ之类信息及时准确传递？

作者: cf3b5 时间: 2011-6-23 21:18

实在受不了，这个破东西都能折腾这么久，而且都没有说到点子上～
其实轮询还是通知这东西根本就没啥差别，去到最底层肯定还是轮询机制，只不过底层轮询速度超快，去到应用层可以看成是无缝的事件触发机制的而已～
ios和andorid真正的区别在于ios的推送协议是死的，任何第三方厂商的推送内容只能由系统统一来显示，因此内容和格式都是基本固定的，功能能较弱，但是优点是安全性和省电！
andorid这方面是开放的，厂商可以选择驻留自己的应用程序，用自己的应用接收和渲染推送协议内容～所以展现的内容和功能可以强大很多很多！

作者: cc0128 时间: 2011-6-23 21:20

posted by wap, platform: SAMSUNG (Nexus S)

阻塞和非阻塞不是程序代码可以控制的么。

作者: cf3b5 时间: 2011-6-23 21:20

引用:

原帖由 burnfox 于 2011-6-23 21:14 发表

7个小时11%，未root

在tompda老卖家那买的，以前也买过好多次了，没问题，电池连个触点划痕都没有，所以相信是原装电池。

这叫做物似主人形！

作者: 潜水艇的水 时间: 2011-6-23 21:23

引用:

原帖由 zmqzmq2010 于 2011-6-23 21:15 发表
LZ我就请教1个问题：
IOS5敢于把维特+IM+云端大量数据同步集成到系统内核里，是否代表苹果自家PUSH服务器+系统推送部分的可靠性足够应付QQ之类信息及时准确传递？

这有什么可靠性的问题么？手持设备能有多少数据流量。手机端不会出现任何性能上的问题，关键看服务器上面消息队列和调度算法实现的怎么样。这个apple不推出服务，我们是的不到结果的。不过我猜想，没问题。
正常情况下，push机制绝对不管再性能上还是在节省系统资源上都比轮询好很多，当然这个前提条件是服务器端服务正常，要不android搞个屁的push机制啊。直接用以前的轮询不就ok了么

作者: 潜水艇的水 时间: 2011-6-23 21:24

引用:

原帖由 cc0128 于 2011-6-23 21:20 发表
posted by wap, platform: SAMSUNG (Nexus S)

阻塞和非阻塞不是程序代码可以控制的么。

对，如果柱塞的话，又没有服务器唤醒，哪你不就一直祖塞再那里收不到消息了嘛，说白了push就是吧一部分手机上需要实现的功能放到服务器上去了，节省手机cpu和网络资源

作者: 潜水艇的水 时间: 2011-6-23 21:26

引用:

原帖由 jun4rui 于 2011-6-23 21:11 发表
posted by wap, platform: Chrome

你可以看时序图的发起方，显然有变动后，是服务器主动发起的。

而且里面说了：

Google Sync是通过Atom Feed协议进行的. 这样当Server端有changes后, 会通过C2DM框架发送"com ...

哪不就得了，主动发起方是服务器端，如果google不脑抽，必然是通过硬件中断间接唤醒手机上的进程去服务器同步数据，这就是push的方式啊

作者: 潜水艇的水 时间: 2011-6-23 21:29

引用:

原帖由 cf3b5 于 2011-6-23 21:18 发表
实在受不了，这个破东西都能折腾这么久，而且都没有说到点子上～
其实轮询还是通知这东西根本就没啥差别，去到最底层肯定还是轮询机制，只不过底层轮询速度超快，去到应用层可以看成是无缝的事件触发机制的而已～
...

你看懂我说的东西了么？socket阻塞这种push的方式根本就不是底层轮询，而是由硬件驱动唤醒的。摆脱先看看操作系统实现的机制再出来喷

作者: burnfox 时间: 2011-6-23 21:30

引用:

原帖由 cf3b5 于 2011-6-23 21:20 发表

这叫做物似主人形！

可惜有这问题的不止我一个，A粉丝大有人在。

作者: masterfish 时间: 2011-6-23 21:35

引用:

原帖由 潜水艇的水 于 2011-6-23 21:24 发表

对，如果柱塞的话，又没有服务器唤醒，哪你不就一直祖塞再那里收不到消息了嘛，说白了push就是吧一部分手机上需要实现的功能放到服务器上去了，节省手机cpu和网络资源

这个不知道android下的解决如何，反正阻塞模式在windows下很蛋疼，好多次都把程序搞死了。。。

作者: masterfish 时间: 2011-6-23 21:36

引用:

原帖由 潜水艇的水 于 2011-6-23 21:29 发表

你看懂我说的东西了么？socket阻塞这种push的方式根本就不是底层轮询，而是由硬件驱动唤醒的。摆脱先看看操作系统实现的机制再出来喷

我觉得其实他说的没错，只不过轮询的不是app的socket，而是OS，再由OS来触发唤醒。。。

作者: 潜水艇的水 时间: 2011-6-23 21:37

引用:

原帖由 masterfish 于 2011-6-23 21:35 发表
这个不知道android下的解决如何，反正阻塞模式在windows下很蛋疼，好多次都把程序搞死了。。。

这个是实现的问题，不是机制上的问题。呵呵

作者: 潜水艇的水 时间: 2011-6-23 21:41

引用:

原帖由 masterfish 于 2011-6-23 21:36 发表
我觉得其实他说的没错，只不过轮询的不是app的socket，而是OS，再由OS来触发唤醒。。。

不一样，其实OS根本没有轮询数据包的动作。
数据包都是硬件收到后，主动通知cpu有个任务要做，然后再有os调度哪个app来完成这个任务。触发点不一样

作者: Eclipses 时间: 2011-6-23 22:09

posted by wap, platform: SAMSUNG (I9000)

任何的聊天工具应该都是双工的，所以肯定是有一个监听端口监听服务器的连接，一旦连接成功，这个连接就会持续的接受数据，不用自己去获取的

作者: LTFYH 时间: 2011-6-24 10:16

同意楼上的，肯定有个系统级的进程是开了监听端口的。

作者: 潜水艇的水 时间: 2011-6-24 10:20

ls和lss属于不看帖回帖的，懒得解释了。呵呵

作者: LTFYH 时间: 2011-6-24 10:35

我看了，感觉你完全没说到点子上，你说的是异步和同步的区别，阻塞是同步方式，非阻塞是异步，但这种方式不是消息推送和拉取的本质区别,因为即使是同步的方式接收数据也可只是一个背景线程或是进程，对整体性能不会造成过大的影响.而且同步和异步的实现机制你也说得不对，异步等待时不可能是向服务器确认数据的。

作者: shangchi 时间: 2011-6-24 11:12

引用:

原帖由 潜水艇的水 于 2011-6-23 21:09 发表

不至于吧，飞行不开第三放后台程序一个晚上能耗多少电？能超过10%么？

那么多亲儿子二儿子用户，就2楼莫名其妙的问题多，甭理他……不具有代表性
不手动关闭任何进程开飞行模式8小时耗电1%的未root亲儿子用户路过

作者: 大家好我是小叮当 时间: 2011-6-24 11:20

引用:

原帖由 zmqzmq2010 于 2011-6-23 21:15 发表
LZ我就请教1个问题：
IOS5敢于把维特+IM+云端大量数据同步集成到系统内核里，是否代表苹果自家PUSH服务器+系统推送部分的可靠性足够应付QQ之类信息及时准确传递？

苹果的APNS服务器是可靠的.
ios的push是建立在一个TLS连接上的, TLS连到苹果的APNS,15分钟握手保活.

然后各种应用程序的服务器,比如exchange server,qq等,是和APNS建立连接,发送消息到APNS,然后才由APNS根据TLS里包含的iphone的证书信息,发送消息去iphone.
设备证书是连接的时候通过token key生成的.

欢迎光临 TGFC Lifestyle (http://bbs.tgfcer.com/)