開發較複雜的 iOS 應用時，在建立清晰易懂的項目目錄結構這方面，你有什麼好的經驗或心得？

目錄結構就是指這個：

在簡單的應用中，我們用蘋果默認的目錄結構就可以讓人看懂分辨各個類的作用。然而在一個較大型的項目中，會有幾十個甚至上百個類，並且還會不斷增加。如何建立一個清晰易懂的文件夾結構（目錄結構），讓一個新加入項目的成員也可以快速掌握各個類的功能和相互關係？

目錄結構是按照相似功能（比如較重要的ViewController放到一起）分類好呢，還是對應應用的畫面結構分類（比如搜索結果畫面下面放置相關類）好呢？我想後者在實際應用中很多，但似乎也有缺陷。比如畫面過多過於複雜的時候，難以對他們進行清晰的樹狀分類。

我在網上找到的較好的資料比如這個帖子：iOS項目的目錄結構和開發流程

歡迎大家積極分享自己的心得經驗，或者分享網路上的優質資料。

注

本問題無需涉及Xcode默認生成的初始文件目錄結構的講解。

拒絕毫無乾貨的答案比如「不需要考慮這種結構」「用蘋果的默認結構就行了啊」。

---

實習期間學到的東西 + 自己的一些小小改動，我想大概是這個樣子：

劃分為 MainProject 和 SubProject ，其中 SubProject 用來解耦讓數據模型和網路、數據處理的邏輯和UI的邏輯分開，並將SubProject模塊化成靜態庫，用Git Submodule管理SubProject與3rd庫版本，功能一目了然。MainProject 主要是功能、根類、美術資源、文檔、第三方庫、系統庫的劃分

見圖：

---------------------------------Main Project--------------------------------------------

Base （用於繼承公共根類）

• RootNavigationController
• RootViewController
• RootToolBarView
• RootView
• ···

Main （AppDelegate、容器視圖控制器、宏）

• AppDelegate
• ContainerViewController
• Marco
• ···

Features （功能）

• Feature 1 Group - Feature 1 View Controller
• Feature 2 Group - Feature 2 View Controller
• Feature 3 Group - Feature 3 View Controller
• ···

3rd （第三方庫）

• SDWebImage

• Masonry

• ···

Images （圖庫資產）

• DarkMode Group - ···.png
• DayMode Group - ···.png
• ···

Doc （文檔）

• UI Group - UI.md
• Kernel Group - API.md
• ···

SystemFrameworks （系統框架）

• Fundation
• ···

---------------------------------Sub Project （模塊化成靜態庫）--------------------------------------------

Model （數據模型）

• Person
• Dog
• Cat
• ···

Handler （對應功能的網路、數據處理邏輯）

• Feature 1 Group - feature1handler
• Feature 2 Group - feature2handler
• Feature 3 Group - feature3handler
• ···

Script

• ConvertJsonToModel
• UpdateModel

---

哇塞大神提問啊~~~我也來回答一下。

我的思路是先按 MVC、工具和第三方庫 劃分成為頂層目錄，再根據各自的特性劃分二級甚至三級目錄，但一般不超過三級。

題主這個問題：

目錄結構是按照相似功能（比如較重要的ViewController放到一起）分類好呢，還是對應應用的畫面結構分類（比如搜索結果畫面下面放置相關類）好呢？

在我的項目經驗中，全部是第二種分類，目錄結構中，頁面之間是平行關係，在程序界面過多的時候（我還沒有碰到過這麼多界面的項目o(╯□╰)o）我認為可以按大功能模塊再次劃分。

以下以我個人寫的一個小 App 為例（後有截圖供參考）：

------

ThirdParty（第三方類 / 庫）

　　|- UMessage

　　　　|- UMessage.h

　　　　|- ...

　　|- UMAnalytics

　　|- ...

Utils（工具類）

　　|-Network（網路工具，比如 HTTP、Socket 封裝等）

　　|- UI（UI 工具，封裝一些動畫等）

　　　　|- FLUIUtils.h

　　　　|- FLUIUtils.m

　　　　|- ...

　　|- ...

Models（模型 M）

　　|- ModelUtils（僅用於模型的工具）

　　|- LocalStorage（本地存取封裝）

　　|- ZFSystem（特定功能相關，內容分析等）

　　　　|- xxx.h

　　　　|- xxx.m

　　|- MessageBoard（留言板）

　　|- ...

ViewControllers（VC）

　　|- Login（登錄頁）

　　　　|- ZQVCLogin.h

　　　　|- ZQVCLogin.m

　　　　|- ZQVCLogin.xib（這個 App 寫得比較早，所以還在用 xib）

　　|- User（用戶信息頁）

　　|- Library（圖書館功能頁）

　　|- Score（查分頁）

　　|- About（關於頁）

　　|- ...

res（資源）

　　|- common（通用資源）

　　　　|- xxx.png

　　|- animations

　　|- login

　　|- ...

------

這個工程 MyGDUT 開發的時間較早（12年底）現在 Xcode 已經可以用 Asset Catalog 來管理資源。

另外在源文件較多的時候搜索一下也是很快的~~

求各路大神路過拍磚~

-----

附工程截圖：

---

WordPress 是開源的，我建議參考下。它是我見過開源里寫的少數大的、完整的，而且確實有很多用戶（當然不包括天朝用戶）的項目

https://github.com/wordpress-mobile/WordPress-iOS

---

拆分子項目。

======== 具體回答 ========

做過最複雜的iOS項目是《極品飛車》，資源文件數十GB，源代碼純文本數GB（不能寫具體數字）。

項目大到這個規模，有一部分代碼是編輯器生成的，但是生成的過程耗時太久不能每次都運行，所以還是保存起來。

其他代碼是通過獨立的工程編譯，到主工程去組裝的，主工程打包95%是自動運行的，很少人工介入。

---

有些公司的做法是，儘可能的把各個模塊變異成庫，iOS就直接用靜態庫，少使用源代碼。

---

第一大利器，就是上Cocoapods，現在的項目如果不用pod，估計沒法看！

剩下就是自己代碼的組織了。最近幾年寫服務端都是用的Rails，深受影響。

iOS項目里我的習慣是這樣的：

1. 所有的Models在一個目錄

2. 各種單例形式的Managers有一個目錄

3. 整個項目都可能引用的類會放進Common目錄，其中可能再劃分一下，雖然已經不重要了

4. 獨立業務模塊的按業務建目錄，像知乎裡面的Question/Answer/People這樣分目錄，其中可能再劃分一下，如Question可以分為QuestionList/QuestionDetail

5. 剩下大多數的ViewControllers都有自己的一個目錄

6. Views和綁定的ViewController放在同一目錄

Xcode里的目錄都是虛擬的，這個有點噁心，在Finder里看就是一陣亂麻，幸好這種場景不多。目錄命名都用英文，不過由於是虛擬的，那麼中文命名也是可以接受的。

---

我們的目錄結構年初大概是這個樣子..當然現在已經進化了..

NOTE:最好不要讓不參與開發的架構師/其他平台開發人員們過分干預..很難受 不說了..

UI(Views/ViewControllers)

• Navigation
• NavigationTitleView
• NavigationBar
• BaseController
• ...
• Login
• LoadingView
• LoginViewController
• ErrorView
• ...
• Home
• HomeView
• HomeViewController
• ContentScrollView
• ...
• ...

Model

• UserModel
• FoodModel
• CarClassModel
• ...

Macro

• AppMacro
• NotificationMacro
• FunctionMacro
• ...

Tools

• NetWorkManager
• DBManager
• FileManager
• Category
• NSString+Utils
• UIView+Utils
• ...

Resources

• Images
• Login
• OK.png
• cancle.png
• ...
• Navigation
• Background.png
• backBtn.png
• ...
• ...
• LocalFiles
• ...

FrameWorks

• ThirdLib
• ASIHTTPRequest
• FMDB
• ReachAbility
• ...
• SystemFrameWorks
• CoreGraphics.framework
• Foundation.framework
• UIKit.framework
• ...

Others

---

用Cocoapods做private庫多好，誰開發誰的組件，別人調介面就行了。group再好再結構化，文件一多也沒辦法了。這麼堆一起怎麼跟別人的項目合併呢？

---

Cocoapods 這個是一個小的分水嶺

善用Cocoapods會非常快速提高整個編碼效率/復用效率/框架效率

CocoaPods安裝和使用教程還沒用起來的同學速度,有使用問題私信

---

看過lz關於收納的長文，覺得lz太適合問這個問題了...

---

我自己常用的目錄結構：

|—MyProject

....|—ignore-folder // 放置不想同步到代碼伺服器上的內容，通常包括一些體積太大、經常變動、對項目運行影響不大的文件。需要在該目錄下添加 .gitignore 對本目錄做一些設置。

........|—readme.log // 因為 ignore-folder 目錄下的內容都是不會同步到代碼伺服器上的，所以最好加一個 log 文件記錄一下你在該目錄的操作。

........|—3rdparty // 比如，一些不能用 CocoaPods 管理也不想同步到代碼伺服器上的第三方庫。

........|—data // 比如，一些經常會變動的、自己的測試數據文件。

....|—Utility // 自己實現的一些通用性較好的功能代碼，這些代碼有比較好的介面且與本項目不存在耦合，可直接復用於其他項目。

....|—Common // 本項目的一些全局性代碼，這些代碼通常與本項目的業務邏輯存在一些耦合，所以不放在 Utility 目錄中。

....|—Feature // 本項目的功能模塊目錄，該目錄下將項目的功能劃分為多個模塊，每個模塊穿透 MVC，可以獨立劃分出去。當然，在模塊下你不採用 MVC，採用 MVVM 或其他架構方式也沒問題的。

........|—Base // 定義本項目中各種 Controller、View、Model 的基礎類或基礎介面。

............|—Controller

............|—View

............|—Model

........|—Main

............|—Controller

............|—View

............|—Model

........|—User

............|—Controller

............|—View

............|—Model

....|—Resource // 本項目的資源目錄，放置圖片、音頻等資料。

........|—Image

........|—Sound

|—Pods // 採用 CocoaPods 管理的第三方庫。

上面的目錄結構不一定適合所有人吧，參考項目情況而定。就我自己而言，我希望的是一個好的目錄結構能夠解決這些問題：

1）使項目更適合於團隊開發，能夠降低耦合、便於任務的劃分和代碼的整合管理。

2）使項目能夠積累出更多可復用的代碼和框架。

目錄結構也會隨著項目不斷地進化，我覺得有兩個原則比較重要：

1）主幹簡潔。主幹上防止過度劃分，過度劃分會讓代碼放在這個目錄下也可以，放在另一個目錄下好像也行，容易混亂。

2）分支開放。不對過於細節的分支做嚴格規範，可以發揮大家的靈活性和創造性，回頭來再迭代一些規範出來。

---

同推薦cocoapods，統一管理第三方庫，乾淨利索

---

先劃分主工程和子工程，再劃分目錄層次結構。

---

---

推薦閱讀：