一、搭建項目方式？
iOS 純代碼、xib、sb的選擇：
三者不是互斥的，可以互相摻雜著使用，就比如我最喜歡的就是代碼摻雜著少量的xib（主要是cell）使用。
1.純代碼搭建項目：
a.主要是由于它靈活，方便，所有的屬性都可以通過代碼來控制，簡單來說，storyboard 和 xib 能做的，純代碼都能做而他們不能做的，純代碼也能做。
b.純代碼對大型項目、團隊開發(fā)都很友好，尤其是在版本控制，代碼管理方面。唯一的缺點就是繁瑣以及代碼量大，不過這都不是什么問題。
c.純代碼更好的是所有都能掌控在手中，以及能夠使用各種黑科技。同時只有多用代碼生成和運用各個控件，才能更好的理解底層以及各種實現(xiàn)。
2.通過Stroybord搭建項目：
<1>.storyboard 是個好東西，不過建議還是在單獨開發(fā)，并且是中小型項目的時候使用。
<2>.storyboard 好處是所有的控件都可以拖拽到控制器上，并且可以設置好大部分的 autolayout 和大部分的屬性，少量不適合的可以在代碼中另外一個方法中額外設置。可以大大的減少代碼數(shù)量，也方便在不運行的時候展示出修改后樣子。
<3>.storyboard 的壞處也很明顯:
a.對于控件的細節(jié)把握不足，靈活性不足（比如需要layer的屬性，autolayout需要額外的設置等）
b.在大型項目中，需要多個 storyboard 配合，且單個 storyboard 不能有太多的控制器，否則就會牽絲扳藤，糾纏不清。（想象一下印度的電線纏繞）
c.在多人合作的時候，如果有人點進了 storyboard 則會自動視為對 storyboard進行修改，那就很容易造成沖突，而且在造成沖突之后，也不好修改。
3.xib：
<1>.xib 是在 storyboard 之前出現(xiàn)的，也是很多老一輩的人愛用的，storyboard 可以看成是 xib 的集合再加上部分的功能吧。
<2>.xib 可以在一些例如 cell 或者一些比較簡單的 View 中使用，當然是屬于個人建議，好處與壞處都和 storyboard 差不多，也就不做太多的介紹了
二、好項目需要考慮那些方面？
1.需求文檔的探討
2.人員配備（團隊開發(fā) or 個人）組建項目組，開發(fā)周期
3.語言選擇（Swift or Objective-C）
4.前后端規(guī)范，接口設計，數(shù)據(jù)結(jié)構(gòu)（常用Json）等探討
5.設計模式（delegate，觀察者KVO，單例，工廠，MVC，MVVM，MVP）
6.項目架構(gòu)（MVC，MVVM，MVP目錄結(jié)構(gòu)）
7.工程配置
8.三方庫選擇和管理
9.公共模塊，業(yè)務邏輯，網(wǎng)絡層設計，數(shù)據(jù)解析和存儲層設計等
10.定制導航欄，tabBar等等
三、都有那些架構(gòu)模式或者設計模式？
常用架構(gòu)：
-
MVC：
場景：是一中非常古老的設計模式，通過數(shù)據(jù)模型，控制器邏輯，視圖展示將應用程序進行邏輯劃分。
優(yōu)勢：使系統(tǒng)，層次清晰，職責分明，易于維護
敏捷原則：對擴展開放-對修改封閉
實例：model-即數(shù)據(jù)模型，view-視圖展示，controller進行UI展現(xiàn)和數(shù)據(jù)交互的邏輯控制。
MVC關(guān)系圖 -
MVVM：
為了不讓控制器日益增大,便于測試管理,便出現(xiàn)了MVVM，它其實是一個 MVC 的增強版，并將表示邏輯從 Controller 移出放到一個新的對象里，即 View Model，它位于 View/Controller 與 Model 之間。在 iOS 上使用 MVVM 的動機,就是讓它能減少 View Controller 的復雜性并使得表示邏輯更易于測試，如下圖：
MVVM關(guān)系圖 MVP：
設計模式：
目前常用的幾種設計模式：代理模式、觀察者模式、MVC模式、單例模式、策略模式、工廠模式、MVVM，MVP
1.代理（delegate）
場景：當一個類的某些功能需要由別的類來實現(xiàn)，但是又不確定具體會是哪個類實現(xiàn)。
優(yōu)勢：解耦合
敏捷原則：開放-封閉原則
實例：tableview的 數(shù)據(jù)源delegate，通過和protocol的配合，完成委托訴求。
列表row個數(shù)delegate
自定義的delegate
一句話總結(jié)：傳入對象實現(xiàn)對象的功能
2.觀察者
場景：一般為model層對，controller和view進行的通知方式，不關(guān)心誰去接收，只負責發(fā)布信息。
優(yōu)勢：解耦合
敏捷原則：接口隔離原則，開放-封閉原則
實例：Notification通知中心，注冊通知中心，任何位置可以發(fā)送消息，注冊觀察者的對象可以接收。
kvo，鍵值對改變通知的觀察者，平時基本沒用過。
3.單例
場景：確保程序運行期某個類，只有一份實例，用于進行資源共享控制。
優(yōu)勢：使用簡單，延時求值，易于跨模塊
敏捷原則：單一職責原則
實例：[UIApplication sharedApplication]。
注意事項：確保使用者只能通過 getInstance方法才能獲得，單例類的唯一實例。java，C++中使其沒有公有構(gòu)造函數(shù)，私有化并覆蓋其構(gòu)造函數(shù)。Objective-C中，重寫allocWithZone方法，保證即使用戶用 alloc方法直接創(chuàng)建單例類的實例，返回的也只是此單例類的唯一靜態(tài)變量。
4.工廠
場景：
工廠方式創(chuàng)建類的實例，多與proxy模式配合，創(chuàng)建可替換代理類。
“專門定義一個類來負責創(chuàng)建其他類的實例，被創(chuàng)建的實例通常具有共同的父類?！?br>
世界上就是由一個工廠類，根據(jù)傳入的參數(shù)，動態(tài)地決定創(chuàng)建出哪一個產(chǎn)品類的實例。
簡要分析結(jié)構(gòu)圖：
ConcreteProduct1和ConcreteProduct2兩個產(chǎn)品具有一個共同的父類IProject，簡單工廠類為SimpleFactory，負責根據(jù)傳入的不同參數(shù)來決定生產(chǎn)ConcreteProduct1還是ConcreteProduct2產(chǎn)品。
優(yōu)勢：
易于替換，面向抽象編程，application只與抽象工廠和易變類的共性抽象類發(fā)生調(diào)用關(guān)系。 通過簡單工廠模式的重構(gòu)，我們就是閑了低耦合度的代碼結(jié)構(gòu)，做到了對外擴展開放，對修改關(guān)閉。如果再增加任何的 操作方法，只需要繼承操作方法父類，新建一個操作子類，并且在簡單工廠類里面多添加一個else if的判斷即可。
優(yōu)點：
簡單工廠模式的優(yōu)點是客戶端可以直接消費產(chǎn)品，而不必關(guān)心具體產(chǎn)品的實現(xiàn)，消除了客戶端直接創(chuàng)建產(chǎn)品對象的責任，實現(xiàn)了對責任的分割。
缺點：
是工廠類幾種了所有產(chǎn)品的創(chuàng)建邏輯，一旦不能正常工作，整個系統(tǒng)都會受到影響，而且當產(chǎn)品類多結(jié)構(gòu)復雜的時候，把所有創(chuàng)建工作放進一個工廠中來，回事后期程序的擴展較為困難。
通過優(yōu)缺點的分析，我們可以再如下場景中使用簡單工廠模式：
（1）工廠類負責創(chuàng)建的對象較少時；
（2）客戶端只知道傳入工廠類的參數(shù)，對于如何創(chuàng)建對象的邏輯不必關(guān)心時。
敏捷原則：DIP依賴倒置原則
實例：項目部署環(huán)境中依賴多個不同類型的數(shù)據(jù)庫時，需要使用工廠配合proxy完成易用性替換
注意事項：項目初期，軟件結(jié)構(gòu)和需求都沒有穩(wěn)定下來時，不建議使用此模式，因為其劣勢也很明顯，增 加了代碼的復雜度，增加了調(diào)用層次，增加了內(nèi)存負擔。所以要注意防止模式的濫用。
四、從零到整完美項目？
A.純代碼搭建項目：
一、打開xcode新建工程
1.刪除沒用的文件
-
刪除不相關(guān)的類
刪除文件 -
刪除info.plist下Main storyboard file base name一項
刪除該選項 - 設置appdelegete代碼
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{
self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
self.window.backgroundColor = [UIColor whiteColor];
//設置啟動項、跟視圖，廣告頁等內(nèi)容
[self.window makeKeyAndVisible];
}
2.創(chuàng)建不同的target管理工程
有時候我們需要多個版本，開發(fā)版、測試版或者線上版，或因渠道不同需要區(qū)分企業(yè)版，AppStore版等。這個時候使用target來管理就比較方便
2-1.如圖2.1創(chuàng)建target
2-2.修改名字
需要修改下名字target、scheme、info.plist三項的名字，主要用來區(qū)分下版本
注意:修改了info.plist名字需要修改新建的target的配置信息文件，讓其能找到info.plist文件
2-3.修改下工程配置文件,如圖2.3
切換target方法
#if DEVELOPMENT
NSLog(@"development");
#else
NSLog(@"release");
#endif
更多target管理參考：多個target管理
3.導入CocoaPods管理依賴庫
自從CocoaPods升級到1.0.1之后,為多個target導入依賴庫,之前的link_with語法不能用了,使用如下方法:
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, ‘7.0’
# ruby語法
# target數(shù)組 如果有新的target直接加入該數(shù)組
targetsArray = [‘MyApp’, ‘MyAppTest’]
# 循環(huán)
targetsArray.each do |t|
target t do
pod 'MJRefresh', '~> 3.1.12'
pod 'Masonry', '~> 0.6.1'
pod 'AFNetworking', '~> 3.1.0'
pod 'MJExtension'
pod 'MBProgressHUD'
pod 'SDWebImage'
end
end
使用方法參考：CocoaPods安裝教程
4.info.plist配置
-
網(wǎng)絡請求適配，如下圖：
允許http請求
5.添加應用白名單
iOS9之后分享等必須添加白名單后才可以打開相關(guān)應用。字段值為LSApplicationQueriesSchemes
6.其他
設置分享到微信、微博啊等URL Types
二、項目模塊化
-
根據(jù)選擇等架構(gòu)（MVC/MVVM/MVP/MVS）和業(yè)務模塊需求去創(chuàng)建清晰等項目目錄結(jié)構(gòu)
image.png NavigationViewController封裝
tabBarController封裝
創(chuàng)建pch文件：這個文件用來包含全局使用的頭文件，例如:
1.第三方頭文件
2.全局宏定義
3.自定義的頭文件包含主題、網(wǎng)絡請求地址、全局方法、key等UITools：一些公共控件的封裝，常用的一些控件進行封裝（彈窗、廣告輪播等），方便以后統(tǒng)一修改
DataMange：
1.存放對文件的處理方法，文件的路徑
1.數(shù)據(jù)庫的處理
1.NSUserDefault的處理全局配置參數(shù)DefineMacro：全局宏定義包含一些屏幕寬高、iOS版本、手機類型等
樣式定義DefineTheme：主要包含樣式上的定義,主題顏色、各類字體大小顏色、控件大小等
選擇封裝適合自己的網(wǎng)絡框架
B.Stroybord搭建項目：后期更新
說明：自己學習記錄，希望大家給點建議
參考
文中的內(nèi)容有參考過以下文章，大家可以參考下
多個Target管理
CocoaPods安裝教程
Pch 文件的正確使用
iOS黑魔法－Method Swizzling
手把手教你iOS項目基本框架
