Keep 4.0 背後的技術團隊
Keep 自 2015 年 2 月上線以來，現在已影響了超過 8000 萬人的運動習慣。作為一家初創公司，Keep 在媒體上並不算十分活躍。外界關注到 Keep 大多是因為 Keep 的用戶增速、公司融資速度，最近的則是蘋果公司 CEO Tim Cook 參觀 Keep，以及 Keep 發佈 4.0 新版本宣佈由「移動健身教練」向「自由運動場」轉型。歸根結底，Keep 被人關注的根本是用戶對 Keep 產品的認可，而受人喜愛的產品背後必然要有可信賴的技術開發做支撐。
接下來的這篇文章，是 Keep 技術團隊對外的首次分享，包括 Tim Cook 來訪時與 Keep 技術團隊之間的互動，技術團隊的工作流程以及 iOS 技術上的一些分享。另外，如果你有興趣加入 Keep 的技術團隊，可以在文末查看招聘信息。
Tim Cook 的來訪
3 月 21 日 Tim Cook 亮相位於亮點設計中心的 Keep 辦公室，在王寧的陪同下參觀了 Keep 的辦公室和 GYM。
首先 Tim Cook 駐足前臺觀看了「自律給我自由」的宣傳片。
隨後 Tim Cook 來到技術團隊的辦公區，當途經 iOS 團隊工位時，熱心的詢問關於 iOS 開發上的一些問題。Keep 客戶端負責人在向 Tim Cook 簡單介紹了正在開發的 4.0 版本之後，提到有很多模塊已經採用 Swift 編程時，Tim Cook 表示很開心，鼓勵 Keep 繼續積極使用蘋果推出的新技術，並加倍努力做出更棒的產品。
乘車離開後 Tim Cook 在微博上寫道：“An inspiring visit with Wang Ning and his team at Keep. Congratulations on 80,000,000 downloads and helping people get and keep healthy! 初遇 @王寧同學 和他的 @Keep 團隊，深受鼓舞。祝賀你們喜獲 8,000 萬下載，更要為你們幫助每個人收穫和保持健康而喝彩！”
4.0 版本發佈上線
最新版本 Keep 4.0 已發佈上線，此次更新包含了以下功能：首頁結構和數據中心界面升級；支持了戶外騎行、跑步機跑步並添加了跑步路線；新增了直播和私信功能；個人主頁改版，支持「運動日記」生成。
截止目前，Keep 已經集合了全國 8000 萬用戶，覆蓋全國一、二線城市本科及以上高學歷、高薪白領階層的年輕群體，包括明星、運動教練、達人團隊等，其中超過 6 成都是 90 後年輕用戶，隨時隨地為他們提供運動生活體驗服務。
究竟是什麼吸引了 Tim Cook 前來參觀，究竟是什麼吸引了 8000 萬用戶的喜愛，本文將從 Keep 技術團隊和 iOS 技術這兩部分來介紹。
技術團隊
Keep 技術團隊主要由後臺、運維、數據、前端和客戶端組成，接下來會從敏捷的開發流程、高效的工具使用、高標準的產品質量和多方位的成長路線來給大家介紹 Keep 技術團隊的全貌。
敏捷的開發流程
Keep 的開發流程是基於 Scrum 框架建立的。該流程要求在特定的一段時間內，輸出確定的需求，在開發中需求儘量不要變更，開發人員快速完成開發。在一般情況下 Keep 的 Product Owner 和 Scrum Master 都是產品經理（除了技術推動的一些技術優化需求），大需求中涉及多端協同開發的功能會指定技術同事來負責溝通和協調。
目前的 Keep 迭代週期為兩週，發版也保持兩週一更新。這樣既能讓用戶對產品保持新鮮，也不會讓團隊內部時間安排太過緊張。從每兩週的週三開始一個新的 Sprint， 在新的 Sprint 的第二週開始具體的需求講解和評審，並在下週週三完成迭代。下圖描繪了 Keep 目前迭代週期的重要時間點和大概流程。
在執行 Sprint 流程時，必要的溝通會議是不可或缺的。會議的預訂採用 Google Calendar 邀約的方式。目前主要固定會議分為以下三種：
計劃會議：規劃下一個 Sprint 的開發任務。產品經理給開發人員講解需求後，開發人員將需求拆解成子任務，並對任務時間進行評估。最後雙方基於優先級和開發時間得到一個 Sprint 計劃的開發任務列表。
每日站會：開發團隊互相瞭解進度。主要關注：昨天做了什麼，今天要做的任務，遇到了什麼問題。會議一般簡短，控制在十分鐘以內，無需涉及太多細節。
回顧會議：總結和覆盤開發過程中的問題。展示上一個 Sprint 的成果，回顧產品線上數據，討論其中的非業務相關的問題，並討論解決方案。
在瞭解完基本的 Scrum 流程模型後，那麼具體 Scrum 中是如何進行任務拆分的。下面來看任務拆分環節。
產品經理和開發人員首先就需求實現的意義和可能性進行討論，以便對需求進行篩選；然後對確定要開發的 Task 進行拆分。一般來說涉及多端的大 Task 會拆分為 UI Task，Server Task，Android Task，iOS Task，Web Task，以及 QA Task 六大子 Task，其中 UI Task 和 Server Task 可能會先行一週，給客戶端和 Web 前端開發聯調留足時間。
子 Task 被分配到具體技術組後，首先在組內會將子 Task 再次拆分為子任務，分發給開發 Owner，一般以 Point（1 Point 代表一天）為單位來拆分出最小粒度單位，原則上被拆分的 Task 完成時間最好不超過 2 Points；然後組內同事對開發 Owner 提出的設計方案進行評估，得出拆解完的子任務和對應的估點時間表；最後統計每個開發人員的開發總時間，再做任務上的合理調整。
任務拆分環節之後，開發人員會在下一個迭代進行功能開發。在整個 Sprint 開發過程中，開發人員在每日站會上同步每天的進度和棘手問題，把握現有的開發節奏。下圖為需求拆分基本流程。
迭代完成後，會先在一週內進行內部測試和灰度測試。內部測試覆蓋規模大致為 500 人，灰度測試的覆蓋規模增加到 2000 人，一方面驗證內測的 Bug 是否被解決，另一方面避免遺漏概率低於 0.1% 的 Bug。最後在下週二提交 App Store 和各大應用商店，iOS、Android 同步上線。
高效的工具使用
工具是第一生產力，Keep 技術團隊非常重視對工具的使用。
團隊常用且不限於的工具有以下：Phabricator, BearyChat (早期使用Slack) , Seafile, Google 企業套件 (Google Doc，Google Mail，Google Calendar )，Reveal，Alfred，ResuceTime，OhMyZsh，Paw 等。這裡僅例舉 Phabricator 和 Google 企業套件的使用情況。
Phabricator 是 Facebook 開源的一個開發流程工具，集成了項目管理、代碼審計、代碼管理等功能。Keep 技術團隊的日常工作任務安排全部由 Phabricator 完成；時代碼都託管在 Phabricator 的 Diffusion 上，並配合 Arcanist 工具進行 Code Review；Keep 也利用Phabricator 的 Maniphest 模塊來創建和指派任務；此外， Phabricator 提供了諸多 Application 供團隊使用，比如 Phame 中可以寫 Blog，公司可以維護自己的 Wiki。Wiki 的編寫不限於技術同事，根據公司內部的 Wiki 文案撰寫說明所有同事都可以發佈 Wiki，例如工作居住證的辦理流程就是行政同事利用 Markdown 編輯的 Wiki。下圖為公司所有公告資源均被整理到 Wiki 上，達到資源共享，提升辦工效率。
Keep 已引入了企業應用套件 Google Apps For Business。無論是會議預訂、技術文檔撰寫都通過 Google 這一系列軟件來完成。例如會議預訂可以先確定邀約的人當下 Calendar 是否方便，技術方案評估前會提前在 Google Doc 上討論然後再組織開會確定方案。
高標準的產品質量
Keep 團隊對數據十分重視，很多決策都是基於 A/B 測試做出的決定。一般來說新產品需求都會加上對應的埋點，每次產品會議回顧的時候，會分析上線版本數據的一個概況，同時產品經理會根據數據做出對應的調整。
另外一方面，分析數據不是萬能的。Keep 團隊還會在每上線版本之後進行用戶反饋的收集和處理，不斷的調整優化產品。
數據的關注不僅僅停留在產品層面上。在技術方面也做了諸多監控，比如上傳下載的成功率，Bug 率，API 監控等數據。
一個優秀的技術團隊一定是對代碼質量有著高品質的要求。在代碼 Review 方面來看，Review工作是技術成長的最好方式。Keep 做到良好的 Review 首先基於 Commit 的細粒度提交，技術團隊內部規定：每次提交不應過大，保持代碼功能單一的職責。但整體的提交應該包含一個已完成的完整功能, 未完成的功能不應該 Commit，代碼作者在每次提交之前都應該自己過一遍代碼，走一遍冒煙測試，確保基本的功能是完整的。
其次 Keep 代碼的每個 Commit 都必須經過 Code Review。我們做法是強制在 Phabricator 代碼庫上限制了不能直接合入，必須經過 Review。
在選取合適 Reviewer 方面，功能改動和擴展時 Reviewer 選擇模塊原作者或者同一組的同事。複雜功能或牽涉到算法相關的 Review, 通常需要和 Author 一起進行 Review。對於超大型 Diff，本組內同事再一起拉會議室進行 Review。
多方位的成長路線
《Google 是如何運營的》曾提到， 人才即我們的「創意精英」才是公司的最大核心競爭力。由此可見，人才的培養非常重要。
對於新入職的同事，Keep 技術團隊一般會指定一名 Mentor 來引導和熟悉公司業務流程，進而融入到團隊中；對於初級工程師，Mentor 也負責指導功能實現設計和前期代碼 Review 工作。
另外，每個迭代後的例會也是團隊交流的重要一環。例會內容分為幾個部分：簡要介紹當前週期每個人任務安排，上期 Task 技術總結回顧，並抽取上期較有價值部分或者近期研究內容進行分享。
除了團隊內部分享之外，也會組織和外界技術團隊進行交流合作，例如 iOS T 社區。iOS T 社區是一個閉門的 iOS 技術沙龍，經常會舉辦線下交流活動。 Keep 曾作為主辦方進行了 IM 實戰、Clang 分享以及 iOS 測試相關的分享。下圖為大家對議題的熱烈討論。
值得一提的是，由於和 Google Wear 以及 Apple 的合作，Keep 也得到了今年 WWDC 和 Google I/O 會議的名額。
Cook 此次訪華在 Keep 特意和 iOS Team 開發人員進行了交流，所以，大致聊完 Keep 技術團隊的組成和工作流程後，對技術團隊中 iOS 開發再進行重點介紹。
iOS 技術
目前 Keep iOS 團隊一共有 9 名成員。從業務上劃分為 TC，SU，RT 三大塊。TC (Training Course) 包含課程列表、參加訓練、訓練過程和課程表等訓練健身的相關功能。SU (Social & User) 包含了社區、動態、消息、登錄註冊、相機、直播等功能。RT (Running Track) 目前有戶外跑步、跑步機、騎行、跑步路線等。在瞭解完 iOS 團隊情況和業務劃分後，本文從 iOS 基本架構模型說起，隨後描述技術選型和實現的一些細節，最後從技術展望的角度簡單談談之後的發展和規劃。
架構模型
Keep iOS 基本架構模型設計如下所示：
上圖模型從下到上依次分為 Core, Service, Business 三層：
Core 層主要包含網絡請求、基礎通用模塊、數據存儲以及第三方服務模塊，這些模塊接口直接提供給上層服務。
Service 層包含了各種包裝好的服務給業務層調用，比如本地日誌系統、統計埋點以及第三方服務的封裝等等。這一層承上啟下，連接了 Core 層和 Business 層。
Business (SU/TC/RT) 的解耦以 KEPMedium 模塊作為共同依賴組件，其核心實現是採用 Runtime 利用反射 Class 動態調用達到解耦的效果。 需要特別指出的是，由於項目龐大，在 Business 中首先需要將具體業務細化為子業務模塊，比如圖示的 Timeline 模塊和 Live 模塊；然後子業務內部再劃分 MVC/MVVM ，但業務相關的工具類需要單獨抽出；另外， Core 層和 Service 層的部分模塊被要求放到私有倉庫中，用 Carthage 作為Framework 為日後 Keep 其他 App 提供基礎依賴。
技術實現
最開始 Keep 項目的 UI 編寫主要採用 Storyboard 和 XIB，因為當時正處於蘋果積極推崇 StoryBoard 的階段。直至 2016 年5 月份，由於 Xcode 升級導致了 Storyboard 兼容性上的一些問題，外加項目工程大，導致 Storyboard 打開更耗費系統資源、編譯時間更長，因此之後選取了 Masonry 作為 AutoLayout 主要開發庫，同時資源圖片採用 PDF 矢量圖。
IDE 的選擇
Tim Cook 來 Keep 參觀時曾詢問到 Xcode 能否滿足當前的開發需求。作為 Apple 推出的官方 IDE，Xcode 對蘋果特有的 Storyboard、XIB、plist 等文件類型均支持地比較全面，但在代碼提示、自動補全等功能方面，同專攻 IDE 的 JetBrains 等公司推出的類似工具相比還略顯遜色，例如 AppCode。iOS 開發團隊也曾嘗試過 AppCode，感受是：純寫代碼較順暢，靜態檢查也超讚，內置的 Git 操作、Refactor 等功能都非常好用；但 AppCode 對 Swift 和 Objective-C 混編、XIB 等支持的並不佳。目前開發團隊中編譯器的選擇主要依據個人喜好，在純寫代碼時更加偏向於 AppCode。
對 Swift 的態度
在 Swift 發佈初期，Keep 項目即引入了 Swift 代碼，但僅有一部分邊緣模塊採用 Swift 編寫。主要考慮到 Swift 語言不夠成熟，有可能存在一些隱形的坑；而且當時人手並不充裕，擔心用一門不熟悉的語言而降低開發效率。事實證明當時的決定是正確的，隨後 Swift 2.0 和 Swift 3.0 的兩次大改動，給使用老版本 Swift 編寫的應用帶來了不小的升級工作量。但隨著 Swift 3.0 的發佈，Swift API 逐漸穩定，之後基本不會出現較大改動。所以目前 Keep 項目中新的業務模塊幾乎都用 Swift 編寫，因為與 Objective-C 相比，Swift 語言更簡潔，語法更 Modern。另外，團隊中偶爾一些腳本、爬蟲等項目也直接用 Swift 編寫。
編譯的優化
由於需求眾多， Keep 項目逐漸龐大，導致編譯時間加長，需要對其進行優化，iOS 團隊主要從以下幾個方面入手：
1、儘可能減少宏的定義，使用靜態常量代替。
2、刪除無用的頭文件引用，採取 @class 或 @import module 方式代替。
3、減少 Storyboard、XIB 的使用，因為 Storyboard 需要編譯 Copy 等過程。
4、第三方庫儘量使用靜態庫 Framework。
優化過後，整個工程編譯時間從 15 分鐘縮短至 7 分鐘左右，而且隨著組件化的細分，相信這個時間還會繼續縮短。另外，業務模塊相互獨立後，Business 中各個業務也將單獨拆成獨立 Project 進行編譯，使業務人員開發時只需編譯自己的模塊，開發效率更高。
自動化流程
iOS 團隊採用 Jenkins + Xcodebuild + Fastlane 的方式，編寫了打包上傳 App Store、發佈內測、灰度的自動化流程工具，並在公司的 Mac Pro 上部署了這一工具。當然除了打包之外，還部署了其他一些自動化服務，比如前臺接待系統，辦公網絡抓包工具等等。
「前臺接待系統」是 iOS 團隊成員在業餘時間，用 Swift + Spring Boot + Mysql 開發的一個自動接待工具。快遞小哥來了之後只需進行掃碼就可用短信通知快遞收件人，基本替代了收發快遞的工作，前臺人員工作量明顯減少了。像這種常用工具的搭建在 Keep 技術團隊中非常常見，也是探索新技術的一種方式。
展望規劃
在編程語言選擇方面，iOS 開發團隊會持續使用 Swift 來開展新的業務和重寫舊的業務。另外近期也打算使用 RxSwift + Alamofire 重新編寫網絡層，逐步替代原有的 AFNetworking。
另外組件化的細粒度拆分還需進一步進行，實現各個業務組件可單獨編譯運行；Apple Watch 等外設提供的訓練和跑步功能進行豐富和優化。
客戶端性能優化也是今年的工作重點。iOS 開發團隊會繼續完善內部 KEPProtectKit 模塊，降低崩潰率，監控和優化 FPS，減少網絡延遲，提高 Web 頁面加載速度，縮短冷啟動時間，並加大單元測試的覆蓋量，結合 Jenkins 更好的完成自動化測試和分析。
Keep 創立至今，其高速增長已不是什麼祕密。但一般外界都是從 Keep 用戶發展、產品形態、融資情況等方面報道。本文以 4.0 版本發佈為契機，從 Keep 技術團隊內部的工作流程、高效工具的使用、對人才重視以及部分技術實現等方面進行介紹，為大家展示了 Tim Cook 拜訪的 Keep 背後的一個擁有相同價值觀、崇尚效率並務實的團隊。Keep 的願景是打造出一個「自由運動場」，讓更多人勇敢和堅定地邁出運動的第一步，將運動融入生活，更好的認知自我，追求更高的目標，最終讓世界動起來！
如果你喜歡我們這樣的團隊，如果你熱愛運動，那麼，趕快加入我們吧！！
【 iOS 開發工程師 】
職責：
要求：
1、負責 Keep 跑步或社區業務線的業務開發和重構工作；
2、負責新技術的研究和調研工作。
1、2 年以上工作經驗，本科以上學歷；
2、有豐富的業務開發和一定的重構經驗。
【 數據開發工程師 】
職責：
要求：
1、負責 Keep 的數據流水線、用戶畫像和用戶流失分析等系統的設計和開發；
2、負責推薦、反作弊的數據分析，為算法提供數據支持。
1、2 年以上工作經驗，本科以上學歷；
2、熟練掌握 Java/Python/Scala 中至少一門語言，熟悉 Hadoop，Spark，Hive，Storm，Kafka 等開源項目。
【 Java 開發工程師 】
職責：
要求：
1、參與 Keep 課程、社區和商業化等核心業務的研發工作；
2、參與基礎服務和中間件等平臺項目的研發工作。
1、兩年及以上 Unix/Linux 平臺下高性能服務器端架構設計與開發經驗，本科以上學歷；
2、熟練掌握 Java/Go 等後端開發語言，瞭解 JVM 的運作機制；
3、熟悉 Docker、MC、Redis、MySQL、MongoDB、HBase 等基礎組件源碼和模塊開發, 有大規模在線服務開發經驗者優先。
---------------------------------------
關於 Keep：
互聯網健身 App「 Keep-移動健身教練」，在各大應用市場搜索 Keep 即可下載，為你量身打造最適合自己的健身計劃。
微信公眾號：Keep，分享最實用的健身知識、最有趣的生活指南