在 iOS 上不使用 Facebook App 時要完全砍掉 process

在「The Background Data and Battery Usage of Facebook’s iOS App」這邊提到 Facebook AppiOS 上使用了非常吃電的技巧來強制背景更新。

作者猜測,如果你把 Facebook App 設定成不允許背景更新,那麼 Facebook App 會利用 iOS 在「播放音樂」可以在背景執行來進行更新:(所以只是打開播放的 channel,但是沒有聲音)

My guess is that Facebook is hijacking audio sessions on iOS by keeping silent audio in the background whenever a video plays in the app. And because, by default, videos on Facebook auto-play on both Wi-Fi and Cellular and few people ever bother to turn it off, that means there's a high chance the Facebook app will always find a way to play a video, keep audio in the background, and consume energy to perform background tasks.

而且有些人也發現了類似的現象:

I'm not alone in noticing the mysterious "Facebook audio" background consumption, and video auto-play seems to me the most likely explanation at this point. I don't know if turning off auto-play may fix the problem, but I'd recommend doing that anyway to save data.

印象中我們家的 zonble 也有提過類似的事情,當時他好像還有抱怨不知道 Facebook App 在搞什麼鬼... Anyway,這就可以理解作者提到為什麼這麼吃電:

On my girlfriend's iPhone, for instance, iOS 9 reports 5 hours of on-screen usage for the last 7 days, and another 11 hours of background audio usage with Background App Refresh turned off.

我的想法是,如果不用的時候就按兩下 home 鍵把 Facebook App 整個踢出去,或者就如同作者建議用 Safari 開行動版本:

I wonder if Apple should consider additional battery controls to take action against shady practices like invisible background audio. What Facebook is doing shows a deep lack of respect for iOS users. I continue to recommend using Safari instead.

Facebook 研究用鋰電池當作 UPS 替代方案

Slashdot 上看到「Facebook Testing Lithium-Ion Batteries For Backup Power」,原報導出自「Facebook gives its server racks a Tesla touch」。

這讓我想到之前 Google 也做過類似的架構,不過是用蓄電池:「Google Finally Declassifies Some Key Server Design Secrets」。

上圖右上邊的那個區塊就是蓄電池。

Facebook 會考慮鋰電池是因為 Telsa 的需求使得價錢往下掉,進而考慮將本來的 UPS 換成鋰電池。

加速 iPhone 6 與 iPhone 6+ 的充電速度

出自「This killer trick will charge your iPhone 6 in half the time」,他們發現拿 iPad 的 12W 充電器充會快很多:

You can use a 12-watt iPad charger to juice up the iPhone 6 and iPhone 6 Plus in half the time when compared to the 5-watt iPhone charger your device ships with by default.

RAID 卡的電池維護

實際的世界都是由 workaround 疊 workaround 解決問題的...

MySQL 資料庫一般都用 RAID 10,利用 RAID 1 的特性保護資料,並且利用 RAID 0 的特性提昇 IOPS 能力。

而這些 RAID 卡通常都會提供 cache,預設應該都會開 read cache,可以大幅增加 random read 的速度。而另外也可以打開 write cache (也就是 write-back),寫入時先寫到 cache 裡,RAID 卡馬上就會跟作業系統回報完成,藉以加速 random write 的速度。

但這樣就會有風險,當資料還沒寫入硬碟就斷電時就會遺失資料。所以在設定 write-back 的 RAID 卡上安裝電池就變成解法之一。

而電池會有壽命問題,所以配電池的 RAID 卡會每隔一陣子就放電測試電池可以撐多久,但在放電測試時,如果斷電就有可能造成資料遺失,於是又冒出很多方法解決。

也就是在「Learning to Deal With Learning」這篇提到 RAID 卡電池維護的事情。

每一層都是 workaround 想辦法解決問題,然後再用 workaround 解決前面造成的問題...

Anyway,有幾種解法,其中仍然對上層作業系統與應用程式透明的解法是:

  • 雙電池架構,很明顯的可以一次只測一顆。
  • 改用 NVRAM,就不需要電池了,不過速度以及成本會是另外一個問題。

另外,對上層作業系統與應用程式有影響的方式:

  • 放電測試時將 write cache 關閉,切回 write-through。這點在原文裡也有提到,效能其實會受到蠻大的影響。
  • 不放電測試了,但這樣的缺點就是拿安全性交換,當斷電時不知道能不撐過去。
  • 或是自己控制放電測試的時間,這可以配合上面切回 write-through 的方式,挑負載比較輕的離峰時間做。

看了下來雙電池架構還不錯,增加的成本還算可以接受,而且因為效能不受到影響,也確保資料安全性,整體維護起來比較簡單。而之後在規模更大的時候,應該就會直接考慮跳到自己放電測試的方式來處理電池問題...