问答丨升级了iOS11.3 为什么多了个Feedback软件？

问题 1

刚刚升级了iOS113 为什么多了个 Feedback软件？

因为iOS 113目前只是测试版，你可能安装了开发者描述文件，才会收到113的测试版推送。普通用户如果没有安装开发者描述文件，目前能接收到的推送版本为iOS 1125。

至于新增了一个Feedback应用，这是测试版里独有的，用于反馈测试版使用体检还有bug等，你把描述文件删除，并且安装正式版的iOS系统版本，就不会出现这个应用。

问题 2

iPhone8用的是LCD屏还是OLED屏？

iPhone8和8 Plus用的都是ICD屏幕，目前iPhone的产品线中，只有iPhone X使用OLED屏幕。

问题 3

为什么我的iPhone弹窗提示有微信消息，点击进去又显示接收中，等上一段时间才收到推送？

这和iPhone的后台机制有关，微信只是给苹果的推送服务器一个消息，然后苹果的推送服务器推送给你一个消息说微信收到新消息了，但是整个过程你手机的微信并没有在运行，而且消耗的流量也非常小。

所以当你打开微信应用，微信才重新运行起来并重新接收消息。一般从安卓手机新换到到iPhone手机的用户，会觉得很奇怪，其实用久了就习惯了。

问题 4

iPhone的系统内存怎么删除？

iPhone这个系统内存显示是升级到iOS 11后显示出来的，无法直接删除。一般只能通过删除应用再重新安装，或者一个个打开应用，清空缓存。

另外在iPhone内存将满时，会触发iOS的自动清理机制，自动清理APP内的一些缓存文件。

iOS 的推送iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。所以， iOS 的推送，可以不严谨的理解为：苹果服务器朝手机后台挂的一个 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://wwwifanrcom/3979。但是复杂度无疑降低很多了。

Android 的推送

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

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

用户的电池？

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

但是， Google 的方案也并非全是悲剧：

也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。

像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。

最后的话

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

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

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

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

　　Notification Services是iOS机制的一个重要特色，是Apple为实现IP基础之上的＂移动通讯寻呼＂替代功能的重要举措。Google有类似的Push服务，但从结构上和功能上分析，都没有Apple的给力。

　　1 Notification解决的是下行推送问题，不涉及上行；

　　2 Apple负责建立独立的Notification服务器群，隔绝并代理所有第三方应用的服务器端（Server）针对自己应用的客户端（Client）所发起的推送服务；

　　3 Notification服务器独立建立自身和所有在iOS设备上开启Notification服务的客户端之间的推送关系和数据库，对客户端的识别方案建立在特别的Token上，一个iOS设备可以根据不同的应用申领不同的Token；

　　4 Notification服务器会将基于应用的数据库管理结果通报应用的服务器端，不影响第三方应用的业务逻辑和管理方式，透明；

　　5 Notification服务器建立并维护一一对应的Notification管道，到每一部开启Notification服务的iOS设备，具体形式为TLS-Https安全链接（基于IP），保活方式为每十五分钟触发一次，本质为应用层长链接，但效率有提升且集中管理；

　　6 Apple明文声明不保证推送的及时性和先后顺序，不建议将其作为IM工具的基础，但实际上Apple自有的Facetime和iMessenger类似IM的工具都建立在Notification基础之上，也确实有送不达、次序混乱的现象；

　　7 Apple很棒，系统初期即在iOS上植入Paging功能，高瞻远瞩，有取代运营商旁路整个3GPP体系的决心和才华，让人激赏！

ios开发实现app的消息推送步骤:

1、IOS应用需要去注册APNS消息推送功能。

2、当苹果APNS推送服收到来自你应用的注册消息就会返回一串device token给你（很重要）

3、将应用收到的device Token传给你本地的Push服务器。

4、当你需要为应用推送消息的时候，你本地的推送服务器会将消息，以及Device Token打包发送到苹果的APNS服

5、APNS再将消息推送给目的iphone

JPush 是经过考验的大规模 APP 推送平台，每天推送消息数超过 5 亿条。开发者集成 SDK 后，可以通过调用 API 推送消息。同时，JPush 提供可视化的 Web 端控制台发送通知，统计分析推送效果。JPush 全面支持 Android, iOS, Winphone 三大手机平台。同时支持的 iOS 版本为 60 及以上版本。支持 iOS 版本为 100 以上的版本。