脸书重建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，将在未来几周陆续部署至全球市场。