android 的推送

转载文章请注明出处：http://write.blog.csdn.net/postedit/14644511

先来对比一下ios的推送：

iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。

所以， iOS 的推送，可以不严谨的理解为：
苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。
然后，系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事。
然后，系统分别通知这些 Apps 。

这个消息的内容是这样的：
应该说，苹果这种方式在技术上没有什么创新。但是，整个架构是很了不起的。 因为：
1 
使用久经考验的协议，技术风险小。

2 
苹果勇于承担责任：
他需要维护一个代价不小的服务器集群，而且要为服务器的 down 机负责。

选择低风险的技术方案 Bug 更少，减轻了用户的痛苦，这是构架师的功劳。
苹果承担责任，尽可能的减少了不可控的意外，保证了用户体验。
这，只能说是公司决策者的功劳。
（从侧面说明有个懂技术的 VP 是多重要。。。而 Scott 走人了。。）

他们带给用户的好处也是实实在在的。
1 安全。
只有登录过的开发者可以通过苹果的服务器推送。

2 快速，稳定，可靠。
苹果掌控推送服务器和 OS 。

3 更省电。

4 让整个系统的体验更统一和简单。
不会出现杀后台这种脑残事。（不用大量 Apps / Apps 的服务为了推送挂后台）。
也不会出现 Apps 被杀就收不到推送这种脑残事（早一点的新浪微博 Android 版仍然如此）。

5 开发容易。

当然，开发者还是要做些事情，比如维护个服务器什么的： http://www.ifanr.com/3979。但是复杂度无疑降低很多了。

Android 的推送
Apps 挂后台一直是 Android 引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。）。。。大家挂后台等待推送就成为技术选择。

当然， Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。

用户的电池？ 

Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”。而 Google 不强制的结果就是： 没人真正为用户的电池负责。

但是， Google 的方案也并非全是悲剧：
也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。
像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。

最后的话
强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。

所以，如果说苹果的推送方案有何创新？

我以为是超越技术，不惜让公司承担更多风险和责任的解决方案。（类似的还有 BB 的专用网络， Kindle 的全球 3G ）

个人相信，担负起这些“额外”的责任，是值得的。。。

只要是为了用户。


PS

勇于承担责任的公司也更像个可靠的成年人，而不是一个随意胡闹的孩子。（以上摘选自知乎：http://www.zhihu.com/question/20667886）

 谈谈个人的看法吧，

他说的过激，其实google是有走服务器的推送的，即GCM。google也一直在鼓励开发者使用，而且国外大公司的产品一般也是使用GCM的。

接下来记录代码，当时偷懒，直接copy的别人的代码：

private void AddNotification(String title,String name){
		count++;
		//添加通知到顶部任务栏
		//获得NotificationManager实例
		String service = NOTIFICATION_SERVICE;
		NotificationManager nm = (NotificationManager)getSystemService(service);
		//实例化Notification
		Notification n = new Notification();
		//设置显示图标
		int icon = R.drawable.ic_launcher;
		//设置提示信息
		String tickerText ="有新消息";
		//显示时间
		long when = System.currentTimeMillis();
		 
		n.icon = icon;
		n.tickerText = tickerText;
		n.when = when;
		//显示在“正在进行中”
		//  n.flags = Notification.FLAG_ONGOING_EVENT;
		n.flags|=Notification.FLAG_AUTO_CANCEL; //自动终止
		//实例化Intent
		Intent it = new Intent(this,MainActivity.class);
		it.putExtra(KEY_COUNT, count);
		/*********************
		 *获得PendingIntent  
		 *FLAG_CANCEL_CURRENT:
		 *		如果当前系统中已经存在一个相同的PendingIntent对象，
		 *		那么就将先将已有的PendingIntent取消，然后重新生成一个PendingIntent对象。 
		 *FLAG_NO_CREATE:
		 *		如果当前系统中不存在相同的PendingIntent对象，
		 *		系统将不会创建该PendingIntent对象而是直接返回null。 
		 *FLAG_ONE_SHOT:
		 *		该PendingIntent只作用一次，
		 *		如果该PendingIntent对象已经触发过一次，
		 *		那么下次再获取该PendingIntent并且再触发时，
		 *		系统将会返回一个SendIntentException，在使用这个标志的时候一定要注意哦。 
		 *FLAG_UPDATE_CURRENT:
		 *		如果系统中已存在该PendingIntent对象，
		 *		那么系统将保留该PendingIntent对象，
		 *		但是会使用新的Intent来更新之前PendingIntent中的Intent对象数据，
		 *		例如更新Intent中的Extras。这个非常有用，
		 *		例如之前提到的，我们需要在每次更新之后更y新Intent中的Extras数据，
		 *		达到在不同时机传递给MainActivity不同的参数，实现不同的效果。 
		 *********************/
		 
		PendingIntent pi = PendingIntent.getActivity(this, 0, it, PendingIntent.FLAG_UPDATE_CURRENT);
		
		//设置事件信息，显示在拉开的里面
		n.setLatestEventInfo(updateService.this,title, name, pi);
	 
		//发出通知
		nm.notify(ID,n);
    }

写入之后才发现

n.setLatestEventInfo(updateService.this,title, name, pi);

这行代码被无情的扫了条横线，丫的，过时了。

查看api发现：

也就是说现在用Notification.Builder 代替了，打开其讲解：

http://developer.android.com/reference/android/app/Notification.Builder.html

发现还确实挺好。可以直接使用：

Notification noti = new Notification.Builder(mContext)
         .setContentTitle("New mail from " + sender.toString())
         .setContentText(subject)
         .setSmallIcon(R.drawable.new_mail)
         .setLargeIcon(aBitmap)
         .build();

来代替。然后直接notify即可。