在之前也写过一些关于apns的事情，不过都没有深究。都是抄抄改改，写写弄弄，近日 在与人讨论时，人说纯中文可以发76个汉字左右。当时我就想了，这不应该啊。apns总长度不能超过256字节，76个汉字。json_encode一下。一个汉字8个字节，早就超了不知道多少了。还要组成payload。。难道不超吗？
然后看了一下别人的函数，原来是用了一个自定义的json_encode。看了他的自定义json_encode之后，突然想起，风雪之隅在他的博客上提到过，5.4的json_encode加了一些参数（参考： 让Json更懂中文(JSON_UNESCAPED_UNICODE)），于是看了一下。json_encode($str,JSON_UNESCAPED_UNICODE)。计算下来的长度与那个自定义的json_encode一样了。
自此，记录下来。推送的时候也可以多推几个汉字了。（仅限php5.4，之前的版本还是网上找自定义的json_encode函数吧，关键字：中文自定义 php json_encode ，或者直接看：http://yige.org/p/458）
早期关于APNS的文章 ：
此段内容其实有很多都知道,只是这里把问题相对集中的显示出来,也容易找到问题.所以我就转载了一下...
内容来自
http://blog.latermoon.com/?p=878
- 以下是大杂烩：
-
- 1.不要用一个开源的叫javapns的lib来推送，这个项目代码臃肿混乱，过度设计，还内存溢出；可以使用notnoop.apns
- 2.Push会延时，也会被丢弃，似乎网络情况，Push本身带有Expiry，超过该值APNS会丢掉Push
- 3.Push有三个基本属性，alert、badge、sound，通过将一些置空，可以实现只修改App上的气泡不出现文本、出现文本但不提示声音，发出声音而不出现任何提示等等效果
- 4.Push除了三个基本属性，还可以附带任意json数据，但总大小不能超过256字节
- 5.要异步发送Push，可以将应用内的Push序列化到Redis队列再消费，并且增加队列监控
- 6.和国外服务的连接速度比较慢，要建立多个连接，使用多线程发送
- 7.APNS有提供feedback服务，用于查询一个Token是否有效
- 8.一台iPhone上的一个App会有两种Token，一种是Developer的，一种是正式Product的，不能混用，在一个与APNS的SSL连接里，使用Developer Token向Product发送Push是无法送达的，同时在十几秒内即使用正确的Product Token发送也无法送达，效果就像直接丢弃
- 9.iPhone上的App处于前台运行时，即使受到Push也不会在界面出现提示，此时App内的回调函数会收到
- 10.高速地向一台设备发送大量Push，Apple会自动丢掉部分Push
今天要說的還是推送，NND，這個推送這玩意，折騰死人
1、aps中是否只能有badge/alert/sound等參數？
答：不是，這個只是最基本的參數，可以有很多參數，但aps標記需要一定存在，其他參數可以自定義，比如：
JavaScript代码
- {
- "aps" : {
- },
- "acme2" : [ 5, 8 ]
- }
aps参数可以是空，但一定要有，上面这个可不是我杜撰的，这是官方的例子：http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW12
2、aps中的content-available是什么意思
答：这个是有特殊需要的时候才需要用，比如用来后台下载？说实话，我在官方没找到文档，反而在adobe找到一个小的介绍 ：
第一个介绍：http://www.adobe.com/devnet/digitalpublishingsuite/articles/dps-push-notification.html
Table 3. Parameters for APNS messages
| Property |
value |
description |
alert |
<string> |
The text message to display to the user. No localization arguments are supported. |
badge |
<number> |
If non-zero, it displays the number on the icon of the application. If zero, no number is displayed. |
content-available |
0 | 1 |
Non-zero indicates a Newsstand push message. The receipt of this will wake the viewer to begin a background download. See Notes. |
sound |
"default" |
Only the default notification sound is supported. |
productID |
<string> |
Product. |
Notes about Newsstand background downloading
- Background downloads are limited to once every 24 hours, +/- 1 hour (or so). You can send as many alert messages you like, but only background downloading will be throttled.
- Background downloading will only happen over WiFi connections. If the user is on 3G and the push is received, the background download is lost.
- A valid subscription via Apple or direct entitlement (CDS, TCS, PCD, Dovetail, or other) must exist.
- Only the most recent folio will be background-downloaded. The user must be entitled to this content.
- Apple attempts a number of times to deliver the push payload. As such, the actual download may begin a significant amount of time after it was originally sent or scheduled.
用了content-available参数后，下一次接收一定是在24小时后。看上面的notes
还有一个介绍在这里：http://www.viggiosoft.com/blog/blog/2011/10/17/ios-newsstand-tutorial/，这篇博客很详细，还告诉你在APP中怎么设置，内容过长，我就不一一贴出来了。
它这么说：
The push notification message has the same syntax as standard push notifications with the only difference that the payload must contain the content-available key set to 1:
JavaScript代码
- {
- "aps":{
- "content-available":1,
- },
- "device_tokens": ["E9623F5CFDE92B40DA4AA90B97B70428BCD8FFCBA067BE17A6EF5102651E66E9"]
- }
There is one importation limitation related to the frequency of pushes: to limit the consumption of resources due to background downloading (which, by the way, we’ll happen only if the device is connected to a Wi-Fi network) Newsstand push notifications are coalesced and only one background download is permitted per day. For testing purposes you can remove this limit by setting an appropriate key in the user defaults (do this at startup in your App Delegate)
APNS 这玩意啊。关于它曾经转载过N篇文章：
不过自己在實際使用中，也還是遇到了問題。
在測試的時候，我連接apns服務器時，發一條推送就斷開，導致我發送上萬條消息的時候需要幾個小時。我就納悶了，如果大家都這樣，那豈不是那些大網站都要崩潰？這時候，有兩位朋友告訴我，不要斷開，用長鏈接。。。於是乎我重改了代碼，然後就看到消息發送的時候刷刷刷的就出去了。心裏還是非常開心的。
但偶爾還是會有發送失敗的情況出現，所以我做了一點處理，如果取回來的代碼不正確，我會一直重發，直到正確。當然，每次發完後，用usleep，休息了10ms，避免數據過度發送。當然每1000條推送後，我會斷開一下鏈接，再重新鏈接。以防萬一
說白了，還是糾結。
