怎样取消来自iosarm9开发板推荐的推送?

来源：蜘蛛抓取(WebSpider) 时间：2015-09-21 21:58 标签： fpga开发板推荐
当前位置： >
iOS 9新 beta 推送了？似乎又是一次小故障
[摘要]今天据闻很多朋友都收到了新的推送，不过却空欢喜一场。
今天据闻很多朋友都收到了新的推送，不过却空欢喜一场。今天凌晨，有不少用户都收到了一个来自苹果的软件更新(弹出窗口)，更新写道：现有新的 iOS 更新可用。请从 iOS 9 beta 版进行更新。不过，当你进入设置-软件更新的时候，你却发现该更新并不存在。经过查证，苹果的开发者页面也并没有放出相关的更新，如此看来这似乎是一次小“故障”。在 9 月 10 日的发布会之前，苹果应该是不会发布新的 iOS 9 beta 了。一般来说，苹果会在发布会过后马上发布一个 iOS 9 GM
版，而正式版一般会在发布会一周后推送。所谓的GM(Golden Master)版通常是正式版发布之前的最后一个测试版。iOS 的 GM
版和最终推送的正式版之间的差异性非常小，使用体验也非常接近，甚至连固件版本号都一样。开发者们也可以在 iOS 9 GM 的环境中提交兼容 iOS 9
的应用。有网友指出，iOS 9 beta 里面本来有一个计时器，当进入 9 月 7 日的时候便会启动，塬因是苹果在此之前已经准备好了新的
beta，只是目前不知道苹果为何突然取消。
责任编辑：兔小编iOS和Android的后台推送工作原理各是如何？
iOS和Android的后台推送工作原理各是如何？有什么区别？修改比如像是QQ，为何我的手机已经通知我了信息，甚至都已经预读了内容，但是打开QQ后还需要连接网络，接收信息后才能看到新
本文选自知乎：
修改比如像是QQ，为何我的手机已经通知我了信息，甚至都已经预读了内容，但是打开QQ后还需要连接网络，接收信息后才能看到新信息。
李楠，ERP/SAP/移动互联网/日本/苹&
101票，来自韩笑笑、BrianQuan、杨霄更多
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.开发容易。当然，开发者还是要做些事情，比如维护个服务器什么的：/3979。但是复杂度无疑降低很多了。
Android的推送
Apps挂后台一直是Android引以为豪的特性（虽然我真的不知道是好处多还是坏处多），大家挂后台等待推送就成为技术选择。当然，Google事后也提供类似苹果的推送方式了，倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。
用户的电池？
Apps的开发者不会站在系统层面考虑的。他会假设其他Apps没有那么&不自觉&。而Google不强制的结果就是：没人真正为用户的电池负责。
但是，Google的方案也并非全是悲剧：也因为整个技术方案非强制，Android的Apps在接收到推送后的表现更为灵活。
像Line的Android版本可以在推送通知的Popup上直接回复，iOS就需要越狱才能做到了。
强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。所以，如果说苹果的推送方案有何创新？
我以为是超越技术，不惜让公司承担更多风险和责任的解决方案（类似的还有BB的专用网络，Kindle的全球3G）。个人相信，担负起这些&额外&的责任，是值得的......只要是为了用户。
PS：勇于承担责任的公司也更像个可靠的成年人，而不是一个随意胡闹的孩子。
郑紫阳，表演时不知应该望向边。
51票，来自周文杰、闲云野鹤、谢浩然更多
iOS系统的推送（APNS，即ApplePushNotificationService）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。
你的例子里面，腾讯QQ的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。
而Android就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实Android也有类似APNS的GCM（GoogleCloudMessage），属于开发者可选，非强制。（更多请看本回答评论区里面@BillCheng的补充）
所以你大概看出来区别，iOS的消息推送机制面世之时是一种全新的解决方案（堪称平台中的平台），应用本身不能有常驻的后台进程，系统的开销少，内存使用更少，电量也更少（把更多的运算和资源开销放在云端，非设备端）。而Android的特点，虽然开销大，优点是更稳定快速，但不明显。
更多请阅开发文档：ApplePushNotificationService(APNs)|
方家文，Oldcodingman
3票，来自任雪涛、雁渡、王仲禹
我感觉以上的回答，并没有正点地谈到&原理&，并且我对其评判断观点也不认同，所以尝试来回答下这个问题。
我的观点是：APNs是iOS成功的一个非常重要的设计！
iOS的推送：就是Apple官方的APNs（ApplePushNotificationservice）。Android的推送：Google官方的是GCM(GoogleCloudMessaging）。
本质上，APNs与GCM是类似的技术实现原理：即系统层有一个常驻的TCP长连接，一直保持的长连接，即使手机休眠的时候也在保持的长连接。这里对于大部分人来说，最不理解的就是，休眠时候都保持在那里的TCP长连接，不会耗电很厉害么？
答案是：不会。这是手机的设计来做到的。TCP长连接有个心跳的时间，在国外可以很长比如30分钟，在国内则因为网络环境复杂一般10分钟。客户端发起的心跳，会短暂地消耗手机电能，但在这个心跳间隔期间，则消耗电能是很少的。当在心跳期间服务器端有推送信息过来时，客户端可以收到并做处理。
这里有篇文章以Android为例做原理解释：/index.php/jpush_wireless_push_principle/...
再说APNs的设计成功处
iOS为了真正地为用户体验负责，不允许应用在后台活动。有了这个限制，但是对于终端设备，应用又是有必要&通知&到达用户的，随时与用户主动沟通起来的（典型的如聊天应用）。
这就是APNs的逻辑所在：iOS自己做个长驻后台保持连接。所有应用，有必要（申请）并且被允许（用户可以改设置）的话，可以通过APNs中转到达用户。这样就完善了！
有可能很多人没有真正地体会到iOS不允许后台应用的好处。我是Android开发人员，Android手机上一般只保留几个常用的应用，不常用就卸载。但是我的iPhone/iPad上则是，除非空间不足，一般不会删除应用。
Android就像Windows，你要真的很费心去维护：有软件在干背后干坏事么？设备又给拖慢了，要清理。要考虑杀毒了......
Android因为后台可以长驻，尤其是国内的Android的手机上Google自家的推送服务GCM处于基本不可用的状态。所以，各App各显神通。聊天类应用的话，大多数直接借用XMPP规范里的一些成果。少量如微信有IM底子的，自己开发协议。这些在实现原理上与APNs/GCM没有本质的区别，但有一定的技术门槛。而大多数普遍应用，要使用推送的话，则使用轮询的方式简单实现。
其实，国外如UrbanAirship自己实现了Android上的第三方提供的推送平台。近期国内如极光推送也实现了第三方的推送平台（技术与微信、GCM、APNs类似）。理论上，如果一个Android设备上多款应用都使用极光推送这种第三方推送平台的话，也可以如APNs一样达到节省电量、流量消耗的效果。
CocoaChina是全球最大的苹果开发中文社区，官方微信每日定时推送各种精彩的研发教程资源和工具，介绍app推广营销经验，最新企业招聘和外包信息，以及Cocos2d引擎、Cocos Studio开发工具包的最新动态及培训信息。关注微信可以第一时间了解最新产品和服务动态，微信在手，天下我有！
请搜索微信号“CocoaChina”关注我们！
关注微信 每日推荐
扫一扫 浏览移动版

我要回帖

更多关于 fpga开发板推荐 的文章

 

随机推荐