讓人點碎屏幕的Nice如何作iOS客戶端架構

極牛技術實踐分享活動 設計模式

極牛技術實踐分享系列活動是極牛聯合頂級VC、技術專家,爲企業、技術人提供的一種系統的線上技術分享活動。
每期不一樣的技術主題,和行業專家深度探討,專一解決技術實踐難點,推進技術創新,每週三20點正式開課。歡迎各個機構、企業、行業專家、技術人報名參加。架構

嘉賓介紹app

劉詩彬,畢業於北京郵電大學電子信息科學與技術專業。曾在創業公司工做2年,12年加入新浪微博,資深iOS工程師,做爲核心團隊成員參與了微博iOS客戶端的重構和發展。2014年加入Nice圖片社交app,擔任iOS技術負責人。框架

萬事開頭難,當你開始着手設計並實現iOS客戶端架構的時候,極可能會出現暫時無從下手的狀況。
那麼,一個創業產品的iOS客戶端架構到底怎麼作呢?現下最有活力的圖片社交軟件Nice的技術負責人劉詩彬將爲咱們解答創業產品如何實現iOS客戶端架構。模塊化

01/創業項目的特色和問題工具

做爲創業產品,無論從產品、技術、團隊、節奏仍是業務特色等都與相對成熟的大產品有有很大的區別。首先分析一下創業公司作產品的一些特色:性能

1.團隊不夠成熟
成熟的產品團隊會有一套共同的作事方式,新人會慢慢被同化,而創業公司不少時候都是在較短期的把你們召集在一塊兒,團隊須要融合到一塊兒,因此找到適合的共同作事方式是很是重要的。測試

2.基礎建設不夠完善
做爲一個新的產品,有不少基礎工做,從技術框架,協做方式甚至到代碼風格也須要逐漸創建起來的,爲了支撐產品健康發展的基礎建設是很重要的。優化

3.產品不夠穩定
做爲一個創新產品,在產品迭代過程當中可能有各類的創新和嘗試,反映到技術實現上就是常常會有各類的須要變動,代碼可能會須要常常重構,爲了能比較好的適應產品的節奏,在架構和具體實現設計上須要慎重考慮。
技術團隊須要能很好的支持這些變化和調整,作到最高的效率和效果,不然很容易在這個過程當中欠下不少債,最後會慢慢累積到拖整個產品的後腿。spa

4.迭代速度快
你們都能看到如今市場的節奏,創業就是在和時間賽跑,快速的迭代是基本的原則。
從微博的一個半月一個版本到如今的一到兩週一個版本,不一樣的狀況須要不一樣的作事方式,設計一個支持快速變化的框架來協調好不一樣優先級的事情是很重要的。

02/基於創業特色的技術框架設計和分析

針對前面提到的特色,咱們慢慢總結出一些方案來適應,整體來說就是:

1.技術核心
團隊是作事的根本,保證團隊對基本技術思想和方案的共同認識很是重要。在快速變化的產品節奏中,若是團隊有高度的默契,每每能專一在業務自己,作到事半功倍。若是不能統一你們的認識,溝通會遇到很多問題,項目可能愈來愈繁雜,各個模塊會愈來愈難以維護,最後會浪費不少時間在沒必要要的管理上。

2.可擴展性
創業產品初期大多仍是以需求爲核心的項目,在設計實現方案時須要把爲適應產品需求的擴展性放在較高的位置,要有適應環境和需求變化的能力。

3.集成性
創業產品通常都有一個肯定的產品核心價值,核心體驗是一個產品成功的關鍵,在考慮擴展性同時不能脫離這個產品核心,怎麼圍繞核心產品功能來協調各模塊的實現也很重要。要把各模塊能有效的結合起來,發揮最好的產品效果。

4.可成長性
各部分能獨立成長優化,適應產品的快速發展。
到具體方案實現上總結爲如下幾個方面:

1.層次化
最開始接手的時候咱們的項目沒有模塊的和模型的概念,各類基礎功能可能混雜在各類具體業務裏,業務調整和擴展很是困難,例如沒有數據模型,不能統一解析。第三方服務沒有統一,各個地方各自實現。帳戶信息沒有統一管理,狀態很難同步。在把能獨立和抽象的邏輯各自整理後,按照不一樣的特色咱們把項目總結爲三層:
技術基礎:這一層是與業務無關的支撐一個項目開發的基礎,雖然不涉及到具體業務,可是他決定了項目的基礎技術指標。
業務支持:這一層實現了最基礎的業務邏輯,通常一個項目的最核心的功能不會改變,這一層的實現基本體現了項目最基本的核心邏輯,實現相對也比較穩定。
具體業務:這是真正的各類具體功能,基於下面的基礎,在實現具體業務時能專一於具體功能的開發,根據產品功能的劃分,實現上也能再具體化分爲各個模塊。
不一樣的層次有不一樣的特色,基礎要求穩定高效可擴展,具體業務要求用戶體驗和開發效率,根據不一樣的特色在實現上就能夠對症下藥,設計不一樣的方案。只要定義好各個層次之間和模塊之間的接口就能很方便的進行協同開發。按照不一樣的特色,團隊分工合做上也能夠更合理的協調不一樣的資源。

2.模塊化
其次是根據剛纔的分層,咱們同時已經把項目分爲了各個模塊,根據特色各個層次的模塊也有不一樣的設計思想。
首先,定義好大的框架,在創業階段,框架可能只須要知足簡單清晰,高效和快速,可是保留足夠的擴展性。只要保證好肯定的接口,基礎框架還能夠獨立進行優化和調整。
而後是對業務模塊的劃分,不一樣的業務模塊可能也有不一樣的特色,好比有的注重效率有的注重交互的體驗,有的注重擴展性。不少時候咱們討論的設計模式可能都屬於這一層,相似MVC,MVP,MVVM,其實我以爲不一樣的模塊不必定要徹底統一,適合最重要。
在咱們的項目中,大部分業務邏輯自己內容都沒有很大變化,可是交互和UI會常常有較大調整,因此咱們把各模塊的接口交互和數據處理等肯定邏輯抽象出來,提供出特定的接口,咱們稱之爲「Engine」,UI則專門拿出來做爲適配,只要知足固定的接口就能和對Engine對接,協調和組織的的工做則放在Controller,逐漸造成了Controller-Engine-Model-View的模型。
最後是具體業務的實現細節,通常前面兩個層次是須要相對穩定的,因爲涉及到團隊合做,在具體細節上可能就很難保證統一了,具體狀況具體分析是這一層的方法,至少能夠把差別性和風險都控制在很具體的點上。

3.插件化
爲了作到前面所提的適應性和擴展性,不少時候咱們會用到插件化的設計。
以微博發佈系統基本結構爲例,首先發布內容這個基本功能自己基本不會有大的變化,因此抽象出了負責管理數據和邏輯流程的發佈隊列和負責交互和UI框架的發佈器容器。
可是,隨着業務的發展和各類產品層面的調整發布的內容和形式經常會有較大的變化,爲了使各類邏輯更加清晰,每種內容能夠獨立成一個子模塊,他們本身可能有本身的交互、UI和數據等邏輯。

03/實踐經驗重點總結

接口設計
爲了把這些模塊比較方便的結合在一塊兒,便抽象出一個通用接口與發佈器交互,這樣無論單獨模塊怎麼調整通常都不會影響總體的邏輯。也能夠作到方便的擴展和業務調整。
涉及到模塊間和模塊內結合須要用到對應的接口形式。
接口形式有不少種,常常會有很多人習慣性選擇某種特定形式,可是其實並無那麼合適。其實每種形式都有本身的特色,須要針對實際狀況選擇,這每每是須要注意的。
在實際開發過程當中咱們仍是會常常遇到以前的設計或者實現不能知足最新的需求,這時候就須要涉及到重構。怎麼在保證產品節奏的同時作到及時的作好合適重構是常常遇到的衝突。

什麼時候重構
咱們常常可能會由於本身的感受來以爲那些實現不爽就想要重構,其實重構以前仍是應該多作好準備。重構要知足三個條件:實現新需求時;修復bug時;有足夠時間來優化。那麼什麼時候要避免重構呢?沒有產品生命裏的模塊,時間不能保證的時候,沒有較爲明確的預期時,都是要儘可能避免重構的。
在實際項目中不僅是代碼邏輯,整個流程須要不少基礎設施來保障,我總結爲三部分:
首先是業務流程 從產品需求提出到評審開發,再到測試迴歸最後檢驗產品效果,整個流程須要有比較清楚的流程控制來保障高效的執行。
而後到具體的開發中其實有不少東西能夠用來提升效率,開源工具,自動化腳本,基礎工具等等。

基礎設施建設

1.業務流程管理

除了代碼實現外開發流程中還會涉及到不少必要流程,打包分發測試,Crash和性能收集分析等。
上面是咱們用到過的一些流程管理工具:
Wiki:https://www.atlassian.com/sof...
Trello:https://trello.com
JIRA:https://www.atlassian.com/sof...
Tower:https://tower.im
咱們使用Wiki來管理產品文檔,技術規劃,項目排期等文檔,能比較方便的跟蹤和多人協做。
Trello能很方便的跟蹤工做流程和任務協做以及時間計劃。
JIRA是也是任務跟蹤,可是通常你們都用來做爲bug管理,由於他的責任跟蹤和流程管理很是明確。
之前是試用過Tower,是國產的一個協做和任務管理工具,前面三個功能他都有,可是可能沒有每一個專業的那麼細化。
各類工具都有優缺點,選擇一個適合的工具能保證流程的控制和效率。

2.代碼和實現
在開發過程當中只要留心會有不少細節能夠優化,甚至能極大的提升質量和效率。好比如今在ARC環境下其實常常有人會忽略內存管理的問題,經過一些簡單的代碼就能幫助發現可能的內存泄露。
clipboard.png

clipboard.png

不少代碼邏輯能夠抽象出來實現自動處理,每每能極大的優化成本和性能,好比咱們結合項目實際和各類開源項目實現的自動解析和序列化數據。

clipboard.png

clipboard.png

隨着項目快速的發展和變化,項目很容易變得臃腫,中間可能有不少無用的資源和邏輯,經過一些簡單的腳本就能發現項目裏的無用資源和邏輯。最近咱們經過腳本檢查和整理項目讓安裝包減小了十幾M。

clipboard.png

Crash統計分析,BUG修復,動態配置等都有不少成熟的解決方案,也能夠根據項目實際本身優化。

3.輔助工具
除了代碼外還有不少事情能夠提升工做效率,有很多現成的工具能使用,若是須要也能夠開發適合本身的輔助工具。

clipboard.png

在咱們的項目中,節奏很是快,常常會有各類嘗試demo或者需求須要測試review。
以前的打包測試的效率很是低,首先是開發須要花不少精力在打包上,而後須要用各類方式把安裝包分發給不一樣的人,而後還要跟蹤反饋。
因此咱們開發了一套自動化打包平臺省去打包和分發跟蹤的成本。包括Xcode套件裏有不少功能和工具能幫助發現解決問題和提升效率,善於使用會受益無窮。其餘相似Charles,Sketch等工具也是應用普遍。

*此分享由Nice企業的劉詩彬在極牛線上技術分享羣裏所分享,有意加入的技術朋友,請在極牛公衆號(ji-niu)裏回覆「技術分享」。

相關文章
相關標籤/搜索