三層架構中，資料層和業務層都已經做過了簡單的分享，最後，就剩下展示層了。本篇就給各位分享下我在展示層設計方面的一些經驗心得。
展示層是三層架構中最複雜的一層了，需要考慮的包括但不限於介面布局、螢幕適配、文字大小、顏色、資源、提示資訊、動畫等等。展示層也是變化最頻繁的乙個層面，每天改得最多的就是介面了。因此，展示層也是最容易變得混亂不堪的乙個層面。乙個良好的展示層，應該有較好的可讀性、健壯性、維護性、擴充套件性。
我在android專案重構之路:介面篇中提到過三個原則，要設計好展示層，至少需要遵循好這三條基本的原則：
保持規範性：定義好開發規範，包括書寫規範、命名規範、注釋規範等，並按照規範嚴格執行；
保持單一性：布局就只做布局，內容就只做內容，各自分離好，每個方法、每個類，也只做一件事情；
保持簡潔性：保持**和結構的簡潔，每個方法，每個類，每個包，每個檔案，都不要塞太多**或資源，感覺多了就應該拆分。
關於這三個原則詳細的解說，介面篇已經講過的，我這裡就不再重複。在此，我只做些補充。
最重要的不是開發規範的制定，而是開發規範的執行。如果沒有按照開發規範去執行，那開發規範就等於形同虛設，那**混亂的問題依然得不到解決。
另外，android系統本身已經對資源進行了很好的分離，字串、顏色值、尺寸大小、、動畫等等都用不同的xml檔案定義。而ios系統在這方面就遜色很多，只能自己實現，其中一種實現方案就是通過plist檔案的方式實現和android一樣的機制。
工程結構其實就是模組的劃分，無非分為兩類：按業務劃分或按元件劃分。
同樣的，ios則分為四個分組：home、nearby、category、user。
之後，每個模組下相應的頁面就放入相應的模組。那麼，問題來了，商品詳情頁應該屬於哪個模組呢？首頁會跳轉到商品詳情頁，附近也會跳轉到商品詳情頁，分類也會跳轉到商品詳情頁，使用者檢視訂單時也能跳轉到商品詳情頁。有些頁面，並不能很明顯的區分出屬於哪個模組的。我接手過的，按業務劃分的二手專案中（即不是由我搭建的專案），我要找乙個頁面時，我認為應該屬於a模組的，但在a模組卻找不到，問了同事才知道在b模組。類似的情況出現過很多次，而且不止出現在我身上，對業務不熟悉的開發人員都會出現這個問題。而且，對業務不熟悉的開發人員開發新的頁面或功能時，如果對業務理解不深，劃分出錯，那也將成為問題，其他人員要找該頁面時更難找到了。
因此，我更喜歡按元件劃分的工程結構，因為元件每個人都懂，不管對業務熟不熟悉，查詢起來都明顯方便很多。android按元件劃分大致如下：
ios的分組則大致如下：
android的activity、fragment、adapter，ios的viewcontroller，分別定義乙個基類，將大部分通用的變數和方法定義和封裝好，將減少很多任務作量，而且有了統一的設定，也會減少**的混亂。比如我在android專案重構之路:實現篇中提到的kbaseactivity和kbaseadapter的實現就是例子，當然還可以抽離出更多變數和方法。
每個activity的oncreate()方法，一般分為三步：
變數的初始化；
view的初始化；
載入資料。
因此，其實可以將oncreate()方法拆分成三個方法：
initvariables()
initviews()
loaddata()
在基類中將這三個方法定義為抽象方法，由子類去實現，這樣，子類就不需要實現oncreate()方法了，只要實現更細化的上述三個方法即可。
ios的viewcontroller也是同樣的方式，這裡就不重複了。
App架構設計經驗談 展示層的設計
三層架構中，資料層和業務層都已經做過了簡單的分享，最後，就剩下展示層了。本篇就給各位分享下我在展示層設計方面的一些經驗心得。展示層是三層架構中最複雜的一層了，需要考慮的包括但不限於介面布局 螢幕適配 文字大小 顏色 資源 提示資訊 動畫等等。展示層也是變化最頻繁的乙個層面，每天改得最多的就是介面了。...
App架構設計經驗談 資料層的設計
資料層，是三層架構中的最底層，負責資料的管理。它主要的任務就是 呼叫網路api，獲取資料 將資料快取到本地 將資料交付給上一層。根據這三個任務，資料層可以再拆分為三層 網路層 本地資料層 交付層。網路層主要就是對網路api的封裝。關於api的設計，該系列的第一篇文章介面的設計已經講過一些。關於如何封...
App架構設計經驗談 資料層的設計
寫於2016 01 07 使用者用密碼登入成功後，伺服器返回token給客戶端 客戶端將token儲存在本地，發起後續的相關請求時，將token發回給伺服器 伺服器檢查token的有效性，有效則返回資料，若無效，分兩種情況 然而，此種驗證方式存在乙個安全性問題 當登入介面被劫持時，黑客就獲取到了使用...