軟件架構雜談(三) --- APNS

淺談軟件架構(三)

—— APNS

----cnyinlinux

本文將討論的是常見軟件架構中的三角關係——APNS。

 

APNS是Apple Push Notification Service的簡稱，即蘋果推送通知服務。它用在當前很火熱的蘋果手機系統中。固然，它不是在手機iOS上運行的一個軟件，而是牽扯普通APP應用商和蘋果官方服務以及iPhone三方的軟件架構。故而我把它稱爲三角關係。

這是一種新的架構，或者說模式，它並不是傳統的節點—服務器模式。目前微軟的WP系統也採用此種工做模式。它的目標是：提升應用響應速度。

首先看一張圖：

從圖中能夠看出，整個APNS的拓撲結構。若是拿騰訊QQ舉例的話，「Provider」就是騰訊服務器(簡稱TS)，「Client App」就是手機上的QQ軟件。能夠看到，APNS就橫在你的QQ和TS之間。一般咱們用QQ跟好友交際時，消息都會經過TS來轉發。咱們的好友列表等等也都是在TS上保存。這樣一來，每一次QQ要向好友發消息，或者接受好友消息，都須要經過APNS過一次手。不少人就會說，這樣不是反而使軟件應用速度變慢了嗎？彷佛是這樣的，可是看看後面的分析咱們就知道真相了。

衆所周知，蘋果手機不支持後臺進程，即你的QQ、微信等軟件應用不能打到後臺，這跟安卓的模式徹底不同。被打倒後臺的App就會被剝奪CPU，甚至內存不足時也會強制清理掉該App所佔內存。這也就是坊間傳聞的「單進程模式」。

的確，iOS的資源管理思想與傳統的多任務操做系統(Linux,Android等)不同。全部資源管理權都交給系統，只有處於前臺的應用進程纔會被系統重視而集中服務，其餘後臺進程幾乎被無視(除了極個別應用例外，如iOS自帶音樂播放器)。全部的資源都儘可能知足當前的前臺進程，所以處於前臺的進程響應速度會較快。這也就是蘋果用戶以爲iPhone速度快的緣由。固然，APNS是同時服務於全部蘋果用戶的。

爲何蘋果要這樣設計呢？答案得從技術角度分析。咱們都知道，通常而言，支持後臺進程的系統，後臺進程與前臺進程區別不大，都有資源使用權，也都佔用CPU運行。這樣系統對應用App的管理是自由的。只要資源還有，誰想用均可以申請。不少流氓軟件佔用不少資源並無有效利用(固然包括程序設計缺陷形成的資源泄漏)。如此一來，系統越用越慢，過一段時間以後幾乎沒法響應咱們新的應用使用響應。因此用戶不得不重啓，這樣所有應用佔用的內存都被強制清零。這也是衆多安卓機油的心聲和經驗吧。

於是，蘋果採用了另外一種思惟。不少打到後臺的應用，並非用戶當前高優先級在使用的程序，那爲何要讓它在後臺無止境消耗資源呢？乾脆將後臺程序所有中止調度，內存緊張時無條件回收後臺進程佔用的資源分配給前臺進程。這樣一來，就能極大保證當前正運行的App的一切資源請求，天然它就是運行最流暢的了。事實上確實如此，通常咱們打到後臺的進程就是當前不使用的，或者說是有別的應用要優先運行。因此關閉後臺進程對咱們的影響並不大。

那麼，問題來了。若是打到後臺就沒法就被剝奪資源的話，那QQ和微信這種應用，一旦打入後臺不就沒法及時接收好友消息了？？別急，APNS就是來解決這個問題的。

先看圖，這就是APNS的工做模型：

當App到後臺以後，它本身沒法及時接收消息，這時候有一我的一直在運行着，並且始終運行着——內核，或者說iOS系統。如上圖所示，當服務器(TS)有消息須要推送給客戶端(QQ)時，TS將消息發送給蘋果Server(APNS-Server)，然後APNS-Server將消息推送給你的手機系統(iOS)，而後iOS作出消息處理(推送提醒消息，標記App圖標等等，這跟iOS的「通知中心」設置有關係)。這樣用戶就能夠經過手機提醒或者應用圖標知道有新消息。接下來用戶決定是否處理此消息，點擊通知提醒查看消息內容，亦或是點擊App圖標打開應用。具體的消息處理受App的設計決定，已再也不是APNS的範疇了。

如此過程，就算是單進程的iOS也能使不在前臺的進程接收到消息。即作到了單進程的快速響應，也兼顧了後臺進程的消息推送。相比之下，安卓的客戶端徹底沒有這樣的過程，後臺的客戶端本身運行着與本身的Server創建通訊，如QQ時刻在後臺與TS進行網絡通訊。具體的通訊細節屬於iOS開發的知識，本文不做贅述。

iOS上如何實現消息通知的概略流程可參照下圖。

 

用戶打開App處理消息時，數據流向請參考下圖：

<<本文完結>>