我們可能已經(jīng)在研發(fā)的這條道路上持續(xù)了5年，甚至更久的時間，如何才能拉開和大眾的距離，讓自己的工作能力提升一步？架構(gòu)設(shè)計應(yīng)該是其中一個方向，大到App整個的設(shè)計，小到每一個頁面、功能，都需要設(shè)計。這篇文章根據(jù)我的研發(fā)經(jīng)驗談一談App的架構(gòu)設(shè)計。

一、代碼需要可讀性

可讀性是十分必要的，我們甚至可以在一個UIViewController中完成一個APP的所有功能，它可能有幾萬行，幾十萬行代碼，該怎么維護(hù)，怎么讀，寫的時候只有你和天明白是怎么回事，過了幾天就只有天知道代碼為什么這么寫了。因為代碼太復(fù)雜，幾十萬行的邏輯在你腦子里，估計腦袋會炸掉，現(xiàn)在在MVC框架中Controller有一千行代碼，都覺得都痛苦了，更何況是幾十萬。

所以要本著一個原則，可讀性。 代碼可以不漂亮。

針對可讀性，我們老一輩得人，做了很多嘗試，最后有一些被證明是合適的，用起來蠻舒服的，這樣的嘗試，被總結(jié)出來，形成了原則，我們大家共同去遵守，達(dá)成共識。比如：六大設(shè)計原則。

感謝他們，我們是站在他們的肩膀上。

二、代碼需要擴(kuò)展性

擴(kuò)展性、仁者見仁智者見智，這是十分考驗得內(nèi)功得事情，有些人開始時就可以做出很好的架構(gòu)，也有工作幾年的人依舊不能做出前瞻性得技術(shù)思考。代碼的擴(kuò)展性按照我的理解需要有注意如下幾個方面：

產(chǎn)品思維
設(shè)計規(guī)范
技術(shù)選型

代碼需要產(chǎn)品思維

代碼的擴(kuò)展性與產(chǎn)品思維是離不開的，你要知道產(chǎn)品現(xiàn)在做的什么功能，以后可能會做什么功能，以及要和產(chǎn)品經(jīng)理聊天，直到他們大致的規(guī)劃；可能有些產(chǎn)品在實踐的過程中慢慢就會發(fā)生變化，工程師也要跟隨著一起做出改變，而且一旦反向改變，一定要在代碼上果斷的做出改變，否則，后續(xù)的問題會越來越嚴(yán)重。

比如產(chǎn)品定位于直播，那么相應(yīng)的技術(shù)棧就出來了：FFmpeg、GPUImage、AVFoundation、OpenGL ES、Metal、即時通信。可能會有直播帶貨，網(wǎng)頁，支付等。

當(dāng)產(chǎn)品經(jīng)理的操作過于復(fù)雜時，記得要battle，（如：產(chǎn)品自己講著講著就懵逼了，這是一定battle）,不然出來的代碼也是一片狼藉，用戶估計也不會喜歡。

查看競品軟件更直觀、更有效。我們通過以下手段獲取有用信息：

競品的現(xiàn)有功能
競品的技術(shù)選型（簡單的逆向、分析出用的Swift還是OC、FFmpeg還是GPUImage、以及用的第三方框架都有哪些）
競品的規(guī)劃方向

設(shè)計規(guī)范驅(qū)動代碼

為什么代碼的擴(kuò)展性還要考慮設(shè)計呢？

我們在研發(fā)的過程中很多時候都是和設(shè)計打交道，可以說一個好的設(shè)計師，可以讓我們的代碼質(zhì)量提升，可以減少我們的研發(fā)時間，那么對于工程師什么是好的設(shè)計師呢？

有規(guī)劃（知道自己現(xiàn)在以及未來，將會做出是什么樣的設(shè)計，能找出共性，會抽象）
有邏輯（好的設(shè)計圖管理、交互的邏輯性，各種極端情況的考慮：如無網(wǎng)絡(luò)，無數(shù)據(jù)，大屏幕、小屏幕、全面屏，錯誤提示，完成提示）

如果設(shè)計不夠成熟，讓他多去看看大廠得軟件，學(xué)習(xí)去吧。同時我們也要幫助設(shè)計童鞋進(jìn)行抽象。

技術(shù)選型是骨架

根據(jù)產(chǎn)品的方向類型，進(jìn)行技術(shù)選型，技術(shù)選型包含以下幾個方面：

語言： OC、Swift、RN
編程方式：面向?qū)ο蟆⒑瘮?shù)式、面向協(xié)議
第三方庫：這是個自己造輪子還是用別人的輪子的問題
布局方式：autolayout、frame、xib、storyboard

做技術(shù)選型時，要調(diào)研好社區(qū)情況，是否活躍，是否繼續(xù)維護(hù)，支持的IOS系統(tǒng)。比如目前的SwiftUI目前就不適合作為一個商業(yè)項目的選型，F(xiàn)lutter，目前也不適合，要考慮之后項目新人的接手難度，招聘情況，雖然各大廠不斷鼓吹Flutter,真正用到的很少很少，甚至我發(fā)現(xiàn)，各大廠不斷開Flutter交流會，但是本身并不使用。無論是SwiftUI還是Flutter距離使用都還有一段考驗期，小廠不要去考慮，大廠可以盡情折騰。

2016年，在一家創(chuàng)業(yè)公司，用Swift2.0寫項目，現(xiàn)在想想，那是一個錯誤的決定，不成熟的Swift并不友好，尤其是每個版本不兼容，一年一度的升級，讓我們不堪重負(fù)，拖累我們的研發(fā)進(jìn)度。

競品的技術(shù)選型是一個重要的參考方向。

三、App需要加速框架（知識庫）

公司要積累自己的知識庫，也成為加速框架，比如網(wǎng)絡(luò)，肯定要自己再封裝一層吧，各個項目的網(wǎng)絡(luò)庫統(tǒng)一用同一個，這樣節(jié)省開發(fā)者的時間；通常這些加速框架與App的耦合程度不大，可以獨立封裝。常見的加速模塊：

網(wǎng)絡(luò)模塊（上傳、下載、加密、重試、緩存、請求以及任務(wù)管理）
音視頻模塊（濾鏡、播放、裁剪、合生、AV數(shù)據(jù)采集）
基礎(chǔ)框架（String、Array、Dictionary、TableView、Date等原生框架的補充）
數(shù)據(jù)（同步、讀寫、升級、清除緩存）
彈窗（toast、hint、alert）

音視頻框架可以細(xì)分：圖片處理、視頻處理、渲染處理。

這些都是公司的寶貴財富，需要一點一點積累，還好我們也是站在巨人的肩膀上，github中有很多可以參考借鑒的例子。完善公司的知識庫后，必將如虎添翼，加速開發(fā)節(jié)奏。

如何提升自己架構(gòu)設(shè)計的感覺？

代碼的可讀性、擴(kuò)展性、完善自己的加速框架（知識庫）。
勤于思考，在下筆之前，一定要做結(jié)構(gòu)、圖表分析。
多溝通，無論是自己的組員還是自己的上司，或者是設(shè)計還是產(chǎn)品，往往靈感一觸即發(fā)。
多讀第三方的源碼，思考為什么作者這樣設(shè)計，這樣做有什么好處和壞處。
做垂直領(lǐng)域，完善自己的技術(shù)壁壘
做寬度領(lǐng)域，多看一些Python、Go、Swift、JAVA、JS、php等語言，見得多才能更全面的分析。

我收藏的第三方庫

1.Hue               顏色擴(kuò)展相關(guān)
2.Snapkit           autolayout布局
3.Realm             數(shù)據(jù)庫
4.RxSwift           響應(yīng)式
5.Hero              轉(zhuǎn)場動畫
6.Lottie            設(shè)計師動畫
7.Alamofire         網(wǎng)絡(luò)
8.messageKit        聊天UI框架
9.Charts            表格
10.Kingfisher       輕量級下載、圖像緩存
11.ImageScout       最小網(wǎng)絡(luò)代價獲得圖片大小及類型類
12.Gifu             高性能gif加載
13.Proposer         請求本地設(shè)備權(quán)限
14.MonkeyKing       無SDK的分享支付（文本、圖像、音視頻、URL）
15.Wormhole         設(shè)備之間的分享iphone watch
16.Promisekit       異步編程
17.Chamele          顏色框架
18.Reachability     網(wǎng)絡(luò)監(jiān)察
19.FloatingPanel    浮動界面
20.LSAnimator       鏈?zhǔn)絼赢嫽贑oreAnimation
21.Blueprints       多種瀑布流
22、SwiftyStoreKit 應(yīng)用內(nèi)購
23、SideMenu 左右菜單欄
24、ActiveLabel 替代UILabel
25、Nuke 代替Kingfisher
26、NotificationBanner  app內(nèi)通知欄
27、XLPagerTabStrip 頂部Tap切換
28、SwiftyCam  相機(jī)封裝的很好
MonkeyKing 分享平臺
Debug：FLEX、VZInspector、MT、GT、Matrix