iOS新建項目結構規範

注:這是本人對多年來iOS開發中項目結構一點本身的看法也是爲公司內部制定的iOS項目建立模板結構;文中引入了sina的iOS-iPhone的客戶端的界面架構,可是本人並不是sina的工做人員,只是根據本身的理解劃分了項目結構,歡迎提出不一樣觀點,gwinabc@foxmail.com,歡迎轉載,轉載時請保留文章的全部內容,謝謝.

本篇文章原文(http://www.cnblogs.com/Shreker/p/5018629.html)會不定時更新...

項目結構GitHub地址:https://github.com/Shreker/QLProjectDemo.git

 

UPDATE: 這些天把文件從新整理一下，添加了一些經常使用的東西，更新見GitHub

=====================

 

　　當咱們進入到新的公司的第一天,看到之前老員工編寫的代碼,找個東西累死人咧,那個抓耳撓腮的啊,通常狀況下都有想揍人的趕腳. 哈哈, 包忙, 先想一下本身的代碼! 想一下本身寫的代碼怎麼才能新來的人一眼就能看懂,想找什麼,在幾秒以內就能找到?這個就要在前期建立項目的時候留神了, 要保證項目的易讀性、易維護性、易擴展性:

在我看來, 做爲一個項目開發的領頭人, 你能夠從兩個方面着手:

1. 項目的結構;
2. 代碼的規範;

　　今天就先介紹我在作新項目的時候項目架構(代碼規範我會在下一篇文章以總結的形式羅列出來),搞理論,這個我不擅長,只好整個例子說一說;考慮到不少人在剛學OC的時候都用`新浪微博`來練手,因此這裏就拿新浪微博的iPhone客戶端來講事, 也正好對比一下, 這樣更能看出問題所在.(其實,目前市場上基本全部的應用都適用,本文說的就是一個思想,不論平臺,不論語言,只要能理解,就能夠應用到實際的應用開發中.)

 

　　爲了爲項目代碼建立一個易讀性、易維護性、易擴展性都至關不錯的代碼模板，如今要求項目代碼的搭建者按照以下的步驟進行：

一、  全部新建項目最好是「Single View Application」：

二、  填好各個項目,這裏注意,項目名稱最好使用英文:

三、  項目建立好以後,第一件事就是修改最低部署系統的Target版本:

四、  接下來就是源文件管理,咱們看左側的導航區域:

1. 非代碼源文件所有移動到「Supporting Files」中；
2. 選中Appdelegate和ViewController的.h和.m，右鍵「Show In Finder」，而後把Appdelegate和ViewController的.h和.m移到廢紙簍,回到Xcode,刪除紅色的剛纔咱們刪除的文件(也能夠直接在Xcode中右鍵->delete->movetotrash, 可是有時候會刪除地不乾淨);

五、  導入咱們已經準備好的項目結構文件(就是項目結構的文件夾和文件的集合在這下載查看)到與項目名稱相同的目錄之下,如圖:

,

結果是這樣的:

 

六、  其中文件夾`QLClasses`中是該項目中的全部源代碼,`QLResources`中存放的是全部的非代碼資源文件,下面就這兩個文件夾的結構就新浪微博目前的結構進行詳細的說明:

1. 總體的框架圖以下(這纔是重點):

1. 須要注意的是圖片的處理,在`QLResources`中有個`QLImages`文件夾,這個文件夾是供特殊的圖片文件而設立的,你不能把全部的圖片都塞到這裏,這個不科學.最好仍是放在Assets.xcassets中.那麼究竟是哪些圖片呢?在有些項目中,大量使用了全屏的背景圖片,這樣的圖片咱們必定不能使用[UIImage imageNamed:@"imageName"]的方式加載,由於這個方法會把圖片直接緩存到內存中,試想一下,若是不少張圖片都塞進內存是什麼狀況?那就只能使用[UIImage imageWithContentsOfFile:@"imagePath"]的方式,可是咱們知道, Assets.xcassets中的圖片在生成ipa後會被打包成一個壓縮文件,以減小內存的佔用,這個`imagePath`從哪裏來呢,因此問題就解決了,把這些圖片放到這個文件夾下面,加載的時候直接用NSBundle解決path的問題,ok;
2. 項目中確定會遇到多個界面使用同一個數據模型的問題,最好仍是在`QLMain`文件夾中建立兩個文件夾`QLCommonModel`和`QLCommonView`兩個文件夾,以便統一管理;
3. 在Xcode左側導航中看到的結構中的每個文件夾(除卻Supporting Files),必須映射到Finder中的文件夾中,這樣在不打開項目的狀況下,咱們就能夠迅速的定位出之前寫過的工具類的位置,也方便在Finder中查看當前項目的結構.

 

　　剛纔看到有人提出了不一樣的觀點,在此表示衷心的感謝.他的意思是項目的代碼量若是太大,這種結構根本就不適用.

　　其實你們誤解了,我忘記在文中說明這樣設計的初衷和好處,在這裏補一下:

• 這樣設計的初衷就是爲了解決項目中文件雜亂,放置位置不規範,形成新員工修改Bug時,還須要從Appdelegate文件,一步一步的`CMD+CLICK`點擊跳轉查找頁面所歸屬的控制器
• 也是爲了項目的整潔.在我剛學OC的時候,就特別的注重項目的整潔性,然而缺少項目的實戰,後來收到不少源代碼的啓發.這個結構就是這麼來的.
• 另外還要說的是,這個結構就是爲大型項目準備的.可是就我目前接手的項目,代碼量尚未特別貼別的多.由於就是爲了高效的管理源代碼,因此也就考慮了代碼多的狀況,`末端細化`就是說,根據不一樣項目的業務邏輯,在最後一張概覽圖中的藍色方框內繼續細化,直到你以爲夠清晰, 固然最後一個末端確定是個MVC結構.
• 我把標題由`架構`改成了`結構`,是由於我以爲對於`架構`這兩個字,個人認識仍是不夠深入,歡迎大牛發帖,指點迷津.

 

任何的問題都有兩面性,咱們面臨的問題是`變數`太多,而咱們的任務就是把`變數`降到最低,直到咱們想要的答案距離近到咱們可以接受.