臉書重建iOS版Messenger，程式碼從170萬行縮減到36萬行

臉書在去年的F8開發者大會上揭露了光速（LightSpeed）專案，宣布將重新打造iOS版的Messenger，該專案的首個成果已於本周發表，新版iOS Messenger的程式碼數量，從170萬行減少到36萬行，整整少了84%，而它的執行檔大小則只有原先的1/4，在Messenger功能未縮水的狀態下，光速專案還讓Messenger的啟用速度，達到舊版的兩倍快。

臉書公布了光速專案的四大核心概念，分別是盡量利用原生作業系統的功能，藉由SQLite的動態範本重覆使用UI，以SQLite作為通用系統，以及建置一個能夠介接程式與伺服器功能的伺服器代理人。

臉書表示，當Messenger在2011年成為獨立的程式時，他們的目標是建置一個功能最齊全的傳訊程式，導致Messenger的執行檔案大小一度高達130MB，使得它的啟動變慢了，特別是在較老舊的裝置上。

最後臉書想開了，認為Messenger的核心功能應該是能夠很快傳遞文字，因而計畫把Messenger重新改建成一個簡單又輕量的實用程式。臉書對新一代Messenger的期望是能夠快速的下載、安裝、更新及啟動，而不必在乎裝置的新舊或網路狀態，而且一個小型的程式也更易於管理、更新、測試及最佳化，但當時Messenger已有多達170萬行的程式碼，於是提出光速專案，完全翻轉Messenger的架構，打造一個全新的程式。

事實上，完全重寫一個程式庫是非常罕見的事，因為其投資報酬率多半不高，但臉書相信光速專案可帶來截然不同的結果，並調動了上百名工程師參與此一專案。

充份利用作業系統功能

為了搶快，傳統行動程式多半是在作業系統上建置抽象層來新增功能、提高工程的彈性與建立跨平台的使用經驗，但現在的行動作業系統已經先進到能夠滿足許多功能的需求，使得臉書決定充份利用iOS的能力，包括渲染、轉碼、執行緒處理或日誌，都由作業系統來負責，亦直接使用作業系統上的UI框架。

這樣一來，即可避免快取或載入大型的客製化框架，減少程式的份量，也更精簡。同時臉書也採用了許多iOS既有的函式庫，包括JSON處理函式庫，而不再於程式庫中建置及儲存自己的函式庫。

總之，只要作業系統能做的，臉書就把它們交給作業系統，只有在iOS無法滿足需求時，才會撰寫小程式來彌補。

重覆使用UI

過去的Messenger在同樣的UI經驗上有眾多的版本，例如在光速專案之前，Messenger有超過40種不同的聯絡人名單螢幕，每個螢幕的設計都有些微不同，而且每種螢幕都必須支援橫向模式、深色模式及無障礙模式，而這些就占了很大的程式空間。

而現在Messenger的聯絡人名單，則是簡單的以一個動態範本來呈現，不必再額外撰寫程式來改變螢幕的樣貌。當有人載入螢幕來傳送訊息或讀取訊息時，Messenger就會連結SQLite資料庫來載入適當的名字或照片，而且還可支援諸如名單管理、群組建立或搜尋等豐富的功能。

以SQLite作為通用系統

大多數的行動程式都使用SQLite作為儲存資料庫，但隨著功能的新增，最後總是會變成，每個功能都有各自的儲存與存取資料的方式與邏輯，因此，臉書向桌面世界借鏡，與其讓每個功能都有自己的快取，臉書利用SQLite作為一個支援所有功能的通用系統。

過去不同功能的資料分享，需要藉由開發客製化的資料快取與執行子系統來完成，但這些程序會拖慢程式速度，但新版Messenger則是讓SQLite直接處理快取與執行，不管是要顯示朋友的活動、更新友人的檔案照片、取回所接收的訊息，或是從資料庫中請求資料，所有的快取、篩選、執行或查詢，都在SQLite中完成。

此外，臉書也以C語言打造了一個能夠整合所有功能的MSYS平台，來協調對SQLite資料庫的所有存取活動，包括佇列的變更、延遲或恢復任務，或是資料同步等。

全新的伺服器架構

為了配合新的Messenger客戶端，臉書亦建置了全新的伺服器架構，過去的Messenger採用傳統的客戶端與伺服器端互動模式，這意味著程式上的每個功能，在伺服器端都必須有大量相對應的客製化邏輯 ，而功能愈來愈多，它們之間的協調邏輯也會愈趨複雜，且容易出錯。

臉書則替新的Messenger設計了一個通用的靈活同步系統，允許伺服器能夠定義及實施商業與同步邏輯，並確保客戶端與伺服器端的所有互動都是一致的。如同客戶端的MSYS平台，臉書在Messenger伺服器端也建立了一個代理人，作為Messenger與所有伺服器功能之間的統一閘道。

既已打造了一個更輕盈也更快速的Messenger程式，臉書也立下了規定，未來若要在Messenger新增功能，除了必須符合上述架構之外，臉書也替每個功能設定了可使用的執行檔空間預算。

此一基於光速專案的新版Messenger只支援iOS，將在未來幾周陸續部署至全球市場。