iOS 專案架構與程式碼規範
*非原創, copy自多位大神力作
iOS 專案架構與程式碼規範
一. 專案架構:
架構原則:易讀性、易維護性、易擴充套件性。
1.應用入口
AppDelegate是應用的代理,應用級的事件都委託它處理,包含啟動退出、推送等事件,以及IM、支付等第三方的回撥,這使得AppDelegate內程式碼龐大,錯綜複雜,十分不利於閱讀和維護,因此我新增了一個AppDelegate+AppService類別,用來處理生命週期之外的業務,AppDelegate作為事件入口,具體實現直接呼叫類別裡的方法,只為更清晰。
2.主目錄按照模組分類,內目錄按照業務分類
Modules包含了應用內的功能模組,根據底部Tab欄劃分並關聯實體資料夾(預設是虛擬的要手動建立實體資料夾拖進來),每個模組內使用的是MVC模式,有人會問為什麼多了Resource和Service資料夾,MVC是一種設計思想,並非死套路就仨資料夾,根據實際需求適當增加,在這我選擇在Service封裝資料請求,VC裡呼叫拿資料即可,至於Resource為什麼在這,我認為當功能模組層級較多時,每個大功能模組都對應許多資源,對應到模組內用起來方便,當然也可以放到最外層的Resource資料夾裡,建立對應的模組名稱,在這兒我是選擇把公共的放到最外層Resource裡,功能相關的放到模組裡的Resource資料夾內,只為更清晰。
優點:對模組的類集中化,方便管理與開發。
缺點:當幾個模組共用一些類時,不太好歸類。
3. 管理模組
Manager的定義是全域性基礎服務,通常使用類方法或者單例來實現,主要包含對應用、使用者的管理和服務,例如網路狀態監聽,廣告頁應用介紹頁等;使用者快速登入退出操作以及登入狀態的獲取等。只為更清晰。
4. 工具類
Utils資料夾內主要包含全域性通用工具,來源於對三方框架的二次封裝,或是自己寫的工具類。在這個專案裡,我封裝了帶AES加密網路請求工具,全域性Toast提示,廣告頁等。只為更清晰。
5. 基類
Base資料夾用來存放專案的基類,基類作用包含一些定製化的內容,例如頁面樣式,空資料頁面等,使用基類來實現,可以統一控制,利於維護,減少冗餘,也為更清晰。
6. 第三方 & 全域性巨集定義
- 第三方資料夾放一些第三方的類庫和對第三方封裝,比如第三方登入、支付、IM等,現在專案我還沒有新增第三方框架。
全域性巨集顧名思義是定義了一些全域性通用巨集。我這裡定義了四個:
UtilsMacros定義的是一些工具巨集,比如獲取螢幕寬高,系統版本,資料型別驗證等;
URLMacros定義伺服器介面地址以及環境開關;
FontAndColorMacros定義全域性用的色值、字型大小,這裡建議跟設計師共同維護一個設計規範,例如:定義一個主色調巨集 MainColor,色值是 0x333333,我們全域性使用MainColor巨集作為背景顏色,當某天App改版,色值改變,我們只需要去更改 0x333333即可,其他程式碼不需要動,同時也能一定程度約束設計師,不要隨便增加一種顏色,非常接近的顏色應當使用一個。如果設計師不願意維護這個規範,你可以嘗試打一架,打不過的話,就只能自己維護了,只為更清晰。
ThirdMacros 包含第三方框架相關的定義,例如keySecret等。只為更清晰。
7. 資原始檔
資原始檔,上面說到過,這裡我是存放了全域性的一些資原始檔,功能模組的我放到了模組內的Resource資料夾內,個人喜好,只為更清晰。
8. Pods三方管理
CocoaPods是iOS專案的依賴管理工具,開發iOS專案不可避免地要使用第三方開源庫,CocoaPods的出現使得我們可以節省設定和第三方開源庫的時間。
二. 程式碼規範:
1. 常量的命名
對於常量的命名最好在前面加上字母k作為標記. 如:
static const NSTimeInterval kAnimationDuration = 0.3;
定義作為NSDictionary或者Notification等的Key值字串時加上const關鍵字, 以防止被修改. 如:
NSString *const UIApplicationDidEnterBackgroundNotification
Tips:
I. 若常量作用域超出編譯單元(實現檔案), 需要在類外可見時, 使用extern關鍵字, 並加上該類名作為字首. 如 extern NSString *const PGThumbnailSize
II.全域性常量(通知或者關鍵字等)儘量用const來定義. 因為如果使用巨集定義, 一來巨集可能被重定義. 二來引用不同的檔案可能會導致巨集的不同. P.S. 對於#define也新增一下字首k(強迫症, 哈哈…)
2. pragma mark 使用
#pragma mark <#註釋的內容#>
#pragma mark- ============ LifeCycle ============
#pragma mark- ============ Method ============
#pragma mark- ============ getter and setter ============
相關文章
- iOS程式碼規範iOS
- iOS 程式碼規範iOS
- 淺談專案程式碼規範
- 微服務架構下程式碼管理規範微服務架構
- 17joys專案程式碼的命名規範
- iOSOC開發程式碼規範iOS
- iOS專案自動程式碼風格規範化--團隊協作的福音iOS
- iOS 開發(一) 程式碼規範篇iOS
- 前端規範之vue 專案規範前端Vue
- 基於專案實戰整理的一份 Flutter 程式碼規範與目錄規範v1.0Flutter
- 程式碼生成器專案架構圖架構
- Vue專案使用eslint + prettier規範程式碼風格VueEsLint
- vue-cli3專案配置eslint程式碼規範VueEsLint
- J2EE專案程式碼編寫規範分享
- python基礎1 - 多檔案專案和程式碼規範Python
- PHP 規範 - Symfony 程式碼規範PHP
- iOS開發總結之程式碼規範iOS
- ReactNative專案實踐編碼規範React
- Android 程式碼規範 - 命名規範Android
- Android程式碼規範:命名規範Android
- 程式碼規範之前端編寫碼規範前端
- Linux專案組程式設計規範Linux程式設計
- iOS程式碼規範之駝峰命名法camelCaseiOS
- 專案規範筆記筆記
- Android 專案規範Android
- iOS的編碼規範(1.1)iOS
- iOS團隊編碼規範iOS
- 測開入門篇《環境管理、編碼規範、專案結構》
- 【iOS 搭建基礎框架】編碼規範 (程式碼格式篇)iOS框架
- 專案目錄結構規範
- NodeJs專案開發中應用ESLint程式碼規範NodeJSEsLint
- 【iOS 搭建基礎框架】編碼規範 (命名規範篇)iOS框架
- 前後端專案結構規範性記錄後端
- 程式碼分支規範
- 程式碼規範整理
- JS程式碼規範JS
- 前端程式碼規範前端
- Less程式碼規範