文章參照了《iOS應(yīng)用架構(gòu)談》，對比自己的項目進行了總結(jié)。會持續(xù)修改，感謝《iOS應(yīng)用架構(gòu)談》的作者。
RLMZiOS客戶端架構(gòu)看似簡單，其實要考慮的事情也不少。
針對App進行要求
View層
View層是最接近業(yè)務(wù)底層的架構(gòu)，影響業(yè)務(wù)層代碼程度最深，所以View層一旦定性，改動空間最小。所以在View層不光要實現(xiàn)功能，還要考慮更多規(guī)范的東西，防止業(yè)務(wù)工程師的代碼腐蝕View架構(gòu)。
要點如下
所有的屬相都使用getter和setter方法,@synthesize,@dynamic根據(jù)不同的情況，酌情使用，正確運用內(nèi)存管理語義。
getter 和 setter全部都放在最后
每一個delegate都把對應(yīng)的protocol名字帶上，delegate方法不要到處亂寫，寫到一塊區(qū)域里面。建議使用#pragma mark - 進行標明。button ,getsturRecognizer等響應(yīng)事件放在一個區(qū)域里面，總之就是把delegate，event response,life cycle等方法都合理的分塊放置。
對于view的布局，無論使用Frame還是使用Autolayout,都需要經(jīng)過精心的設(shè)計，Autolayout可以考慮使用Masonry,Frame的話，一定要控制好可讀性。
關(guān)于storyboard,nib和代碼寫View如果是簡單視圖，個人建議多使用code，對于簡單界面，code一樣簡單，復(fù)雜界面，code比storyBoard更簡單，所以個人更喜歡用code畫View而不是其他。
對于業(yè)務(wù)抽象，建議還是MVC設(shè)計模式，M-model做的事包括（給viewcontroller提供數(shù)據(jù)，給viewcontroller存儲數(shù)據(jù)提供接口，提供經(jīng)過抽象的業(yè)務(wù)基本組件，供controller調(diào)度），C-Controller做的包括（管理view Controller的生命周期,負責生成所有view的實例，監(jiān)聽來自View與業(yè)務(wù)有關(guān)的事情，通過Model的合作，來完成對應(yīng)事件的業(yè)務(wù)）,v-View做的事情（1.響應(yīng)與業(yè)務(wù)無關(guān)的事件 ，并因此引發(fā)動畫效果，點擊反饋。2.界面元素表達）
也可以用MVCS，至于MVVM，理解尚欠，只膚淺的知道ReactiveCocoa。
調(diào)用網(wǎng)絡(luò)API
iOS端，AFNetworking幾乎已經(jīng)成為了業(yè)界新項目的標配。
網(wǎng)絡(luò)層跟業(yè)務(wù)對接部分的設(shè)計
以什么樣的方式將數(shù)據(jù)交付給業(yè)務(wù)層
大多數(shù)App在網(wǎng)絡(luò)層采用的方案大概有三種：Delegate，Notification，block。目前RLWapp采用的是Notification為主，delegate輔助的方式。RLMZapp采用的是block的方式。
比較兩款app，根據(jù)以往經(jīng)驗和跟其他同學討論，個人覺得，比較好的方式是Delegate為主，Notification為輔的方式。盡管我認為，最方便的，最炫的還是用block。
因為這樣可以盡可能的減少跨層數(shù)據(jù)交流的可能，限制了耦合。（RLWNotification為主的方式，偶核性比較大，后來以Delegate方式輔助的原因也是為了降低耦合性）。
統(tǒng)一回調(diào)方法，便于調(diào)試和維護（RLW采用的是統(tǒng)一的回調(diào)方法，相比于瑞麗沒賺，更易維護。）
在跟業(yè)務(wù)層對接的部分只采用一種對接手段，限制靈活性來換取更多的可維護性。
交付什么樣的數(shù)據(jù)給業(yè)務(wù)層
RLMZApp網(wǎng)絡(luò)層拿到的數(shù)據(jù)是JSON,然后將JSON轉(zhuǎn)換成對應(yīng)的對象模型，目前RLW，RLMZ都是采用的這種方式。這種做法是能夠提高后續(xù)操作的可讀性。當然Model轉(zhuǎn)化過程成本很大。目前的兩款app解析json都是采用的手動解析JSON 數(shù)據(jù)，優(yōu)點是效率是最高的，缺點是費時間，轉(zhuǎn)化之后的模型不能直接被展示，如果想展示，需要二次轉(zhuǎn)化，調(diào)試的時候也不直觀。但是目前沒有找到更好的處理方法。
對于手動解析JSON，也可以利用github上的知名JSON直接轉(zhuǎn)NSObject的三方庫來進行處理。
對于API的調(diào)用，是使用集約型API調(diào)用方式還是使用離散型API調(diào)用方式
集約型API調(diào)用方式就是API的調(diào)用就用一個類，然后這個類接收API的名字，API參數(shù)還有回調(diào)著陸點（block,delegate）等作為參數(shù)。RLMZ在使用這種方式。
離散型API調(diào)用，就是一個API對應(yīng)一個APIRequest。RLW在使用這種方式。
個人喜歡更熟練使用離散型API調(diào)用。
網(wǎng)絡(luò)層的安全機制的實現(xiàn)
網(wǎng)絡(luò)安全機制，目前主要考慮的就兩點。
確保API的調(diào)用者是來自你我們自己的APP，防止競爭對手爬我們的API。
解決方法個人感覺讓服務(wù)端給一個秘鑰，調(diào)用API的時候使用這個秘鑰+API名字+API參數(shù)算一個hash。如果我做，就用hash算法（md5）,請求的時候帶上這個hash。服務(wù)端收到請求后，按照同樣的秘鑰同樣的算法也算出一個hash。然后做一個比較，如果一致，就確認確實是自己的APP。（目前咱們這塊應(yīng)該是也沒有完成。）
如果我們對外提供了需要注冊才能使用的API平臺。我們需要有個機制來識別是否注冊用戶調(diào)用了我們的API 。（感覺目前咱們用不到，沒多研究）、
保證傳輸數(shù)據(jù)的安全
蘋果目前已經(jīng)要求使用Https，挺復(fù)雜的，了解不多。目前咱們用的是http協(xié)議。這方面有待學習。
?
網(wǎng)絡(luò)層的優(yōu)化方案
從App本身來做的優(yōu)化
使用緩存手段，減少請求的發(fā)起次數(shù)。API調(diào)用請求來說，有些API請求所帶來的數(shù)據(jù)的時效性是比較長的，比如RLMZ的試用，試用詳情，試用報告，試用文章。都可以針對這些數(shù)據(jù)做本地緩存，
還有對圖片的緩存，圖片緩存的緩存策略一般都是利用比較知名的三方庫，比如SDWebImage幾乎成了蘋果應(yīng)用的標配。
試用策略來減少請求的發(fā)起次數(shù)，主要是針對重復(fù)請求策略的。
界面下拉刷新的這種請求，存在重復(fù)請求的情況。（比如下拉刷新的時候，在請求著陸之前，用戶可能會不斷執(zhí)行下拉刷新操作，那么這個時候，后面重復(fù)的API請求就可以不必發(fā)送了）
如果是條件篩選這種，就要取消前面已經(jīng)發(fā)送的請求。雖然很有可能這個請求已經(jīng)被執(zhí)行了，那么取消所帶來的性能提升就基本沒有了。但如果這個請求還在隊列中待執(zhí)行的話，那么對應(yīng)的這次鏈接就可以省掉了。
數(shù)據(jù)本地持久化
?
動態(tài)部署方案
對App團隊進行的要求
收集用戶數(shù)據(jù)，給產(chǎn)品和運營提供參考
合理的組織各業(yè)務(wù)方開發(fā)的業(yè)務(wù)模塊，以及相關(guān)基礎(chǔ)模塊
每日APP都需要打包，提供給QA工程師測試。
?
?
?
