易栈网-膘叔

雪豹系统我没用地，我只用了lion，我对电池能够用7小时感到震惊，也为一个晚上待机10%的电没了感到郁闷。本来以为升级成mountain lion后会好一点，结果看到这个新闻，我还是先忍忍吧。。。

Mountain Lion更新后设备电池寿命受严重影响

新闻来源:weiphone
苹果最新发布的新操作系统Mountain Lion，在电池寿命方面，貌似也引起了和此前从Snow Leopard更新至Lion时候出现的问题，目 前不同的用户群都受到这个问题的困扰。据用户反应，更新至Mountain Lion后设备掉电十分严重，已经达到了先前电池寿命的50%。

更严重是，至今还没人能发现Snow Leopard更新至Lion时导致电池寿命问题的原因。苹果方面也不清楚这个原因，无法发布修复解决电池寿命 问题。目前从Lion更新至Mountain Lion后，此前受电池问题影响的用户还是没有得到解决。另外，本次更新甚至影响了一些此前在Lion系统 下没有受到影响的设备。

或许最让我们担心一点是，目前在受到影响的用户和没有受到电池问题影响的用户群中，根本无法对他们进行分类，增加了找出原因的难度。在苹果自己也搞不清楚症结所在的情况下，用户只能够继续忍受这个问题，而且此前在Lion上出现的问题苹果也没有尽全力去修复。

原文来自http://www.cnbeta.com/articles/199641.htm

为那些电量越来越不够用的人默哀三分钟先

之前在家裏的時候，為了方便，所以我的無線路由器其實一直都没有设密码，为此很多時候都被其他人所使用。
當很多人在使用我們的無線時，我不得已為它加上了MAC地址過濾。
誰知道，問題就這樣發生了。。。。。。
iphone就死活連接不上了，其實以前IPOD也連接不上，我還一直以為是ipod的原因，因為。。IPAD可以正常連接，心中實在糾結啊。
google了一下，发现很多人连接不上tplink。所以我重新做了一个尝试，不再使用 不设密码而用mac地址过滤的办法。而是使用密码。。。

结果，这样居然可以用了。可怜我苦了一年多。。想偷懒不使用密码，结果导致一年多没有好好上网。
现在开心了，所以做个笔记。

這篇文章很有意思，它。居然是模仿了windows下面那些操作：創建一個同名文件，然後設為只讀（windows下面因為有一些奇怪，即，如果目錄名和文件名一樣，先有目錄的時候，同名文件是不能寫入的，也不能創建，所以在windows下面的時候，我們為了防止會創建這種病毒性文件，可以預先創建一個同名目錄。黑黑，好象就是當年優盤的autorun.inf的無敵解決方法）
現在開始轉貼內容 ：http://apple4.us/2012/07/how-to-remove-sleepimage-in-mac-os-x-when-pmset-command-does-not-work.html

用 SSD 的朋友硬盘空间不大，需要节省。而 Mac OS X 的冬眠模式会自动放一个和内存等大的名叫「sleepimage」的文件到 /private/var/vm 目录，换言之，你的内存是多少 GB，就有多少 GB 的硬盘空间会被这个文件吃掉。

江疆以前介绍过用命令行方法禁用冬眠模式，只要在终端里运行 sudo pmset -a hibernatemode 0 即可。但这招在 Mac OS X 10.7 (Lion) 上似乎行不通，禁用之后删除 sleepimage，过不了多久它又会死灰复燃。

我试过一个叫 SmartSleep 的软件，同样无效。

最后网上搜到一个偏方，问题解决。分享给大家。

1. 打开 TextEdit，建立一个空的文本文件，取名为 sleepimage，保存到桌面。
2. 去 Finder 里找到这个文件，选中，按 return，将后缀名（.rtf 或 .txt）删除。
3. 在 Finder 里按 Command + Shift + G，输入 /private/var/vm，回车。
4. 新开一个 Finder 窗口，将桌面的 sleepimage 文件拖入上述第三步中的窗口。这时系统会要求你输入管理员账号密码。
5. 在 /private/var/vm 中选中 sleep image，按 Command + i，把 Locked 勾上。

完毕。

（这个偏方的原理是将一个体积极小的同名文件放入 sleepimage 所在的目录（/private/var/vm），并禁止系统对该文件进行写操作。）

----------EOF------

我試著看了一下我的本地：

mac$ ls -lh
total 20971520
-rw------T  1 root  wheel   8.0G  7 22 20:07 sleepimage
-rw-------  1 root  wheel    64M  6 21 14:31 swapfile0
-rw-------  1 root  wheel    64M  7 22 21:04 swapfile1
-rw-------  1 root  wheel   128M  7 22 21:04 swapfile2
-rw-------  1 root  wheel   256M  7 22 21:04 swapfile3
-rw-------  1 root  wheel   512M  7 22 21:04 swapfile4
-rw-------  1 root  wheel   1.0G  7 22 21:04 swapfile5
好吧，8G空间就这么没有了。。。凄凉啊。不过我还不敢删除，毕竟 ，我真的有时候会用到没电。。。。

今天要說的還是推送，NND，這個推送這玩意，折騰死人
1、aps中是否只能有badge/alert/sound等參數？
答：不是，這個只是最基本的參數，可以有很多參數，但aps標記需要一定存在，其他參數可以自定義，比如：

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

Notes about Newsstand background downloading

1. 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.
2. Background downloading will only happen over WiFi connections. If the user is on 3G and the push is received, the background download is lost.
3. A valid subscription via Apple or direct entitlement (CDS, TCS, PCD, Dovetail, or other) must exist.
4. Only the most recent folio will be background-downloaded. The user must be entitled to this content.
5. 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:

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篇文章：

• [2012-04-17] - 供应商与苹果推送信息服务器通信 翻译苹果文档 (浏览:714,评论:0)
• [2012-04-17] - 苹果服务器反馈服务 (浏览:695,评论:0)
• [2012-04-17] - 苹果推送注意事项 (浏览:653,评论:0)
• [2011-12-07] - 伤不起的程序猿 (浏览:1079,评论:0)

不过自己在實際使用中，也還是遇到了問題。

在測試的時候，我連接apns服務器時，發一條推送就斷開，導致我發送上萬條消息的時候需要幾個小時。我就納悶了，如果大家都這樣，那豈不是那些大網站都要崩潰？這時候，有兩位朋友告訴我，不要斷開，用長鏈接。。。於是乎我重改了代碼，然後就看到消息發送的時候刷刷刷的就出去了。心裏還是非常開心的。

但偶爾還是會有發送失敗的情況出現，所以我做了一點處理，如果取回來的代碼不正確，我會一直重發，直到正確。當然，每次發完後，用usleep，休息了10ms，避免數據過度發送。當然每1000條推送後，我會斷開一下鏈接，再重新鏈接。以防萬一

說白了，還是糾結。