Google应用在Android上的Push机制以及C2DM框架的底层实现

楼主的文章很棒！我目前也在研究C2DM，看来同道中人真的不少。初步看来，自己实现类似架构没有问题。需要重点考虑的是安全性和长期性能。

C2DM的一个不好的地方是服务器端又要使用Google的API. 自己实现的话其实不难, 就是一个XMPP协议的通信, 安全性的话应该问题不大, 就是使用XMPP的安全机制. 我觉得更重要的问题是XMPP服务器的负载均衡和Cluster等问题.

我提到的安全性是指在XMPP传输以外，如何避免已经发送到设备端的数据被一些恶意应用截获或者破坏。感觉目前C2DM在这方面做得不够好。

不会的. C2DM发送broadcast intent的时候使用了signature方式的permission, 所以只有同样signature的apk的broadcast receiver才能注册并成功接收该broadcast intent.

这正是我所说的薄弱之处。我举个例子。

应用A是合法的C2DM应用，应用B是黑客应用。应用B声明并使用了与应用A完全一样的C2D_MESSAGE permission，并且也接收与应用A一样category的C2DM信息。首先在手机上安装应用A并正常运作，然后卸载应用A，再安装应用B，我们会发现应用B也会接收到应用A的C2DM消息。当然，消息里面的数据格式对应用B来说还是未知的，不过通过反编译应用A的APK也不难获得。这样应用B就得到应用A的数据了。

这个例子说明了C2DM数据被截获的一种可能性。在实际操作中黑客应用也许很难创造合适的机会，但毕竟存在隐患。我们如果设计类似的架构，最好还是多考虑一下。

楼上说的case我倒是没有试过. 这也许是整个Android系统存在的问题. 通常来说, 很多broadcast的intent都没有permission(可能开发人员没有意识到), 意味着你往往可以截获这些intent. 所以才有了OpenIntent这样的项目专门收集一些intent.

楼主不是说还有包签名的验证这一步吗？包的签名不太可能拿得到吧。

我说的包签名指的是Google一系列apps之间用的是包签名. 如果开发人员开发一个使用C2DM机制的应用, 就没办法使用包签名了, 因为发送C2DM broadcast action的肯定是Google的service.
总的来说呢, 没必要担心这个问题, 因为这是个common的问题, 不是C2DM框架特有的问题.

没错，是Android的问题。但我希望可以通过合理的设计堵住C2DM数据泄露的可能性。

我只想知道"这样当Server端有changes后, 会通过C2DM框架发送"com.google.android.c2dm.intent.RECEIVE" action" service 是怎么发送给客户端的