注:這是本人對多年來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
=====================
當我們進入到新的公司的第一天,看到以前老員工編寫的代碼,找個東西累死人咧,那個抓耳撓腮的啊,一般情況下都有想揍人的趕腳. 哈哈, 包忙, 先想一下自己的代碼! 想一下自己寫的代碼怎么才能新來的人一眼就能看懂,想找什么,在幾秒之內就能找到?這個就要在前期創建項目的時候留神了, 要保證項目的易讀性、易維護性、易擴展性:
在我看來, 作為一個項目開發的領頭人, 你可以從兩個方面着手:
- 項目的結構;
- 代碼的規范;
今天就先介紹我在做新項目的時候項目架構(代碼規范我會在下一篇文章以總結的形式羅列出來),搞理論,這個我不擅長,只好整個例子說一說;考慮到很多人在剛學OC的時候都用`新浪微博`來練手,所以這里就拿新浪微博的iPhone客戶端來說事, 也正好對比一下, 這樣更能看出問題所在.(其實,目前市場上基本所有的應用都適用,本文說的就是一個思想,不論平台,不論語言,只要能理解,就可以應用到實際的應用開發中.)
為了為項目代碼創建一個易讀性、易維護性、易擴展性都相當不錯的代碼模板，現在要求項目代碼的搭建者按照如下的步驟進行：
1、 所有新建項目最好是「Single View Application」：
2、 填好各個項目,這里注意,項目名稱最好使用英文:
3、 項目創建好之后,第一件事就是修改最低部署系統的Target版本:
4、 接下來就是源文件管理,我們看左側的導航區域:
- 非代碼源文件全部移動到「Supporting Files」中；
- 選中Appdelegate和ViewController的.h和.m，右鍵「Show In Finder」，然后把Appdelegate和ViewController的.h和.m移到廢紙簍,回到Xcode,刪除紅色的剛才我們刪除的文件(也可以直接在Xcode中右鍵->delete->movetotrash, 但是有時候會刪除地不干凈);
5、 導入我們已經准備好的項目結構文件(就是項目結構的文件夾和文件的集合在這下載查看)到與項目名稱相同的目錄之下,如圖:
,
結果是這樣的:
6、 其中文件夾`QLClasses`中是該項目中的所有源代碼,`QLResources`中存放的是所有的非代碼資源文件,下面就這兩個文件夾的結構就新浪微博目前的結構進行詳細的說明:
- 整體的框架圖如下(這才是重點):
- 需要注意的是圖片的處理,在`QLResources`中有個`QLImages`文件夾,這個文件夾是供特殊的圖片文件而設立的,你不能把所有的圖片都塞到這里,這個不科學.最好還是放在Assets.xcassets中.那么到底是哪些圖片呢?在有些項目中,大量使用了全屏的背景圖片,這樣的圖片我們一定不能使用[UIImage imageNamed:@"imageName"]的方式加載,因為這個方法會把圖片直接緩存到內存中,試想一下,如果很多張圖片都塞進內存是什么情況?那就只能使用[UIImage imageWithContentsOfFile:@"imagePath"]的方式,但是我們知道, Assets.xcassets中的圖片在生成ipa后會被打包成一個壓縮文件,以減少內存的占用,這個`imagePath`從哪里來呢,所以問題就解決了,把這些圖片放到這個文件夾下面,加載的時候直接用NSBundle解決path的問題,ok;
- 項目中肯定會遇到多個界面使用同一個數據模型的問題,最好還是在`QLMain`文件夾中創建兩個文件夾`QLCommonModel`和`QLCommonView`兩個文件夾,以便統一管理;
- 在Xcode左側導航中看到的結構中的每一個文件夾(除卻Supporting Files),必須映射到Finder中的文件夾中,這樣在不打開項目的情況下,我們就可以迅速的定位出以前寫過的工具類的位置,也方便在Finder中查看當前項目的結構.
剛才看到有人提出了不同的觀點,在此表示衷心的感謝.他的意思是項目的代碼量如果太大,這種結構根本就不適用.
其實大家誤解了,我忘記在文中說明這樣設計的初衷和好處,在這里補一下:
- 這樣設計的初衷就是為了解決項目中文件雜亂,放置位置不規范,造成新員工修改Bug時,還需要從Appdelegate文件,一步一步的`CMD+CLICK`點擊跳轉查找頁面所歸屬的控制器
- 也是為了項目的整潔.在我剛學OC的時候,就特別的注重項目的整潔性,然而缺乏項目的實戰,后來收到很多源代碼的啟發.這個結構就是這么來的.
- 另外還要說的是,這個結構就是為大型項目准備的.但是就我目前接手的項目,代碼量還沒有特別貼別的多.因為就是為了高效的管理源代碼,所以也就考慮了代碼多的情況,`末端細化`就是說,根據不同項目的業務邏輯,在最后一張概覽圖中的藍色方框內繼續細化,直到你覺得夠清晰, 當然最后一個末端肯定是個MVC結構.
- 我把標題由`架構`改為了`結構`,是因為我覺得對於`架構`這兩個字,我的認識還是不夠深刻,歡迎大牛發帖,指點迷津.
任何的問題都有兩面性,我們面臨的問題是`變數`太多,而我們的任務就是把`變數`降到最低,直到我們想要的答案距離近到我們能夠接受.