App架構設計經驗談:展示層的設計

App架構設計經驗談:介面的設計
App架構設計經驗談:技術選型
App架構設計經驗談:資料層的設計
App架構設計經驗談:業務層的設計
App架構設計經驗談:展示層的設計

三層架構中，資料層和業務層都已經做過了簡單的分享，最後，就剩下展示層了。本篇就給各位分享下我在展示層設計方面的一些經驗心得。

展示層是三層架構中最複雜的一層了，需要考慮的包括但不限於介面佈局、螢幕適配、文字大小、顏色、圖片資源、提示資訊、動畫等等。展示層也是變化最頻繁的一個層面，每天改得最多的就是介面了。因此，展示層也是最容易變得混亂不堪的一個層面。一個良好的展示層，應該有較好的可讀性、健壯性、維護性、擴充套件性。

三原則

我在Android專案重構之路:介面篇中提到過三個原則，要設計好展示層，至少需要遵循好這三條基本的原則：

1. 保持規範性：定義好開發規範，包括書寫規範、命名規範、註釋規範等，並按照規範嚴格執行；
2. 保持單一性：佈局就只做佈局，內容就只做內容，各自分離好，每個方法、每個類，也只做一件事情；
3. 保持簡潔性：保持程式碼和結構的簡潔，每個方法，每個類，每個包，每個檔案，都不要塞太多程式碼或資源，感覺多了就應該拆分。

關於這三個原則詳細的解說，介面篇已經講過的，我這裡就不再重複。在此，我只做些補充。

關於規範，Android方面，我已經分享過一套Android技術積累:開發規範，主要分為書寫規範、命名規範、註釋規範三部分。iOS方面，蘋果已經有一套Coding Guidelines，主要屬於命名方面的規範。當我們制定自己的開發規範時，首先就要遵守蘋果的這份規範，在此基礎上再加上自己的規範。

最重要的不是開發規範的制定，而是開發規範的執行。如果沒有按照開發規範去執行，那開發規範就等於形同虛設，那程式碼混亂的問題依然得不到解決。

另外，Android系統本身已經對資源進行了很好的分離，字串、顏色值、尺寸大小、圖片、動畫等等都用不同的xml檔案定義。而iOS系統在這方面就遜色很多，只能自己實現，其中一種實現方案就是通過plist檔案的方式實現和Android一樣的機制。

工程結構

工程結構其實就是模組的劃分，無非分為兩類：按業務劃分或按元件劃分。

比如一個電商App，可能會有首頁、附近、分類、我的四大模組，工程結構也根據這四大模組進行劃分，Android可能就分為了四個模組包：

• com.domain.home 首頁
• com.domain.nearby 附近
• com.domain.category 分類
• com.domain.user 我的

同樣的，iOS則分為四個分組：home、nearby、category、user。

之後，每個模組下相應的頁面就放入相應的模組。那麼，問題來了，商品詳情頁應該屬於哪個模組呢？首頁會跳轉到商品詳情頁，附近也會跳轉到商品詳情頁，分類也會跳轉到商品詳情頁，使用者檢視訂單時也能跳轉到商品詳情頁。有些頁面，並不能很明顯的區分出屬於哪個模組的。我接手過的，按業務劃分的二手專案中（即不是由我搭建的專案），我要找一個頁面時，我認為應該屬於A模組的，但在A模組卻找不到，問了同事才知道在B模組。類似的情況出現過很多次，而且不止出現在我身上，對業務不熟悉的開發人員都會出現這個問題。而且，對業務不熟悉的開發人員開發新的頁面或功能時，如果對業務理解不深，劃分出錯，那也將成為問題，其他人員要找該頁面時更難找到了。

因此，我更喜歡按元件劃分的工程結構，因為元件每個人都懂，不管對業務熟不熟悉，查詢起來都明顯方便很多。Android按元件劃分大致如下：

• com.domain.activities 存放所有的Activity
• com.domain.fragments 存放所有的Fragment
• com.domain.adapters 存放所有的Adapter
• com.domain.services 存放所有的Service
• com.domain.views 存放所有的自定義View
• com.domain.utils 存放所有的工具類

iOS的分組則大致如下：

• controllers 存放所有ViewController
• cells 存放所有Cell，包括TableViewCell和CollectionViewCell
• views 存放所有自定義控制元件或對系統控制元件的擴充套件
• utils 存放所有的工具類

基類的定義

Android的Activity、Fragment、Adapter，iOS的ViewController，分別定義一個基類，將大部分通用的變數和方法定義和封裝好，將減少很多工作量，而且有了統一的設定，也會減少程式碼的混亂。比如我在Android專案重構之路:實現篇中提到的KBaseActivity和KBaseAdapter的實現就是例子，當然還可以抽離出更多變數和方法。

每個Activity的onCreate()方法，一般分為三步：

1. 變數的初始化；
2. View的初始化；
3. 載入資料。

因此，其實可以將onCreate()方法拆分成三個方法：

1. initVariables()
2. initViews()
3. loadData()

在基類中將這三個方法定義為抽象方法，由子類去實現，這樣，子類就不需要實現onCreate()方法了，只要實現更細化的上述三個方法即可。

iOS的ViewController也是同樣的方式，這裡就不重複了。

寫在最後

自此，該系列的文章暫時就完結了，方法論比較多，很少涉及到具體的實現。因為具體實現的方案很多，而且還要結合實際專案，無法說哪個方案好哪個方案差。但方法論大部分是想通的，所以，本系列主要講方法論。