【理論】【轉】Android項目重構之路:界面篇

在前一篇文章《Android項目重構之路:架構篇》中已經簡單說明了項目的架構，將項目分爲了四個層級：模型層、接口層、核心層、界面層。其中，最上層的界面，是變化最頻繁的一個層面，也是最複雜最容易出問題的一個層面，若是規劃很差，很容易作着作着，又亂成一團了。
要規劃好界面層，至少應該遵循幾條基本的原則：

1. 保持規範性：定義好開發規範，包括書寫規範、命名規範、註釋規範等，並按照規範嚴格執行；

2. 保持單一性：佈局就只作佈局，內容就只作內容，各自分離好；每一個方法、每一個類，也只作一件事情；

3. 保持簡潔性：保持代碼和結構的簡潔，每一個方法，每一個類，每一個包，每一個文件，都不要塞太多代碼或資源，感受多了就應該拆分。

規範性

每一個人的編碼習慣和風格都不一樣，不說那些缺少良好編碼習慣的開發人員，就連那些已經養成良好編碼習慣的人員，不少方面都會不一樣。好比縮進，有的喜歡4個空格，有的喜歡兩個空格；好比變量名，有的喜歡m開頭，例如mValue，有的喜歡直接就命名爲value。若是不設定好規範，讓每一個人都按照本身的習慣和風格去編碼，久了確定亂，尤爲當團隊中存在還沒養成良好編碼習慣的人員時，更容易亂。所謂無規矩不成方圓，若無規範，久必亂。定義好規範，才能統一風格，纔可提升代碼可讀性，同時也提升了維護性，還減低了引入bug的機會。
開發規範並無統一的標準，在這裏，我只是根據本身的經驗對一些點提供一點建議，僅供參考。

• 縮進

  不少人都習慣用Tab縮進，不論是規範4個空格仍是2個空格，統一設置好Tab縮進的size就行了，這樣就不用讓每一個人都去敲空格。

• 命名

  一個好的命名，一眼就能夠從名字中看到它是幹嗎的，作什麼用，什麼類型等等。舉個id命名的例子，看到有些團隊喜歡將一些控件縮寫，好比TextView縮寫爲tv，ListView縮寫爲lv，這種縮寫卻是挺簡潔的，可是並不能一眼就能看出它是什麼，對於不熟悉的人來講，誰知道tv和lv是什麼啊，還不如用text和list更明確些。我喜歡的id命名結構爲：控件_範圍_功能，例如：edit_login_password，這是一個登陸頁的密碼輸入框。

• 單位

  文字大小的單位應該統一用sp，其餘元素用dp。由於這兩個單位是與設備分辨率無關的，可以解決在不一樣分辨率設備上顯示效果不一樣的問題。另外，SDK裏面，對文字大小系統默認是用sp單位的，但其餘元素單位默認卻不是dp，而是px的，同時也沒有提供dp的設置接口，因此，本身寫兩個dp和px轉換的方法是頗有必要的。

最重要的並不在於規範怎麼定義，而是在於規範的嚴格執行。若是規範定義好了，但卻不遵照，那規範就等於形同虛設，所以，規範一旦設定，就要嚴格執行。

單一性

咱們都知道，面向對象設計中，有一個基本原則就是單一職責原則，它規定一個類應該只有一個發生變化的緣由。而這裏說的單一性，不僅是規定類，也規定了方法、包，甚至到最大層面的分層架構。保持單一性是減低耦合度的關鍵標準，其目的就是各方面的解耦。架構上的分層就是最大層面的解耦，而方法上的單一就是最小層面的解耦了。

• 界面的單一

  界面上的單一，首先是界面的佈局和界面的數據應該分離。這一點，Android已經用layout和Activity作好解耦了，咱們只要確保用layout文件排好佈局，在Activity展現數據就行了。另外，界面數據的獲取和展現也應該分離。不少開發團隊習慣將數據的獲取和展現都放在Activity或Fragment裏完成的，架構篇的讀者裏也有人反映了這個狀況，請求接口、獲取數據、檢查數據、顯示數據更新UI，全都在界面上完成的。這樣子的話，當數據的獲取發生改變時，好比要添加緩存，這時候界面就須要改動了，當數據的展現也須要修改時，好比某個控件要展現其餘數據，界面也同樣須要改動，也就是說，界面上已經有兩個發生變化的緣由，這就違反了單一職責原則。
  界面上的單一，就是要保持界面上每一個維度都作好分離，從界面的佈局，到數據的獲取，數據的檢查，數據的展現。

• 包和類的單一

  定義包以前，須要先想好它的職責是什麼，明肯定義並確保它只有一個職責。例如，com.keegan.activity，就是activity類的包，不會有其餘組件；com.keegan.adapter，就是存放各類適配器的包；com.keegan.util就是工具包了。一樣，類的定義，也是須要明確它的單一職責。有些人習慣將adapter寫在Activity裏，由於以爲這個adapter只在這個Activity裏用到，不必再把它獨立出來。之前的我也是這麼幹的，這麼作了一段時間以後，以爲實在糟糕透了，重複的代碼沒法複用，界面上的一點小需求調整時，不少代碼須要跟着調整。後來，進行了一番重構，將全部adapter獨立了出來，並抽象出了一個adapter的基類，自此，當須要再添加adapter時，編寫的代碼量大大減小了，當界面需求調整時，修改的地方也大大減小了。因此，不要讓一個類作太多事情，要分離好各類元素，每一個元素只作一件簡單的事。

• 方法的單一

  方法的單一，表現爲一個方法是對一個行爲的封裝。然而，一個行爲又能夠拆分爲多個步驟，每一個步驟其實也是一個更細的行爲，又能夠封裝成一個新的方法。所以，方法嵌套方法是一種常態。那麼，保持方法的單一性，關鍵並不在於怎麼定義這個方法的行爲，而在於這個行爲要怎麼拆分紅更細的行爲。舉個例子，一般在Activity的onCreate方法，作數據的初始化，細分出來就分爲了：控件的初始化、邏輯變量的初始化、數據的加載和展現。數據的加載和展現能夠再細分：從緩存加載數據、從網絡加載數據、展現數據。每一個細化的行爲都應該封裝爲一個獨立的方法，這樣，才真正符合方法的單一性。

• 資源文件的單一

  Android提供了各類資源文件，strings.xml用來存儲字符串，arrays.xml用來存儲字符串數組，colors.xml用來存儲顏色值，dimens.xml用來存儲尺寸值，等等。資源文件的單一，是說全部相關的資源信息要在資源文件裏定義並引用到代碼或佈局文件裏，而不是在代碼或佈局文件裏直接定義。不少開發人員，爲了圖方便，應用界面中出現的字符串常常在代碼或佈局文件裏直接定義的，尺寸值也是，這樣形成的結果就是，當某些字符串須要修改時，好比要支持國際化，或一些尺寸值須要修改時，一般是不少地方都要修改。所以，就必須規範好，應用界面中的字符串統一在strings.xml中定義，顏色值統一在colors.xml中定義，尺寸值統一在dimens.xml中定義，代碼或佈局裏須要用到的都去引用資源文件相應的字段。

要保持單一性，一定伴隨着重構。需求總會變更，代碼總會擴展，擴展了慢慢就會破壞原有的單一性，所以就須要重構，再次保持單一性。不斷擴展，不斷重構，這樣才能不斷保持良好的單一性。

簡潔性

代碼最怕的就是臃腫，臃腫的代碼可讀性差，維護麻煩，擴展更不用說了。沒有人會喜歡看臃腫的代碼，去維護更痛苦。我看到臃腫的代碼，都巴不得即刻進行重構。讓代碼保持簡潔，會讓人看得舒服，一目瞭然，維護和擴展起來也都很是方便。簡潔的代碼，甚至不須要寫註釋，只從代碼就能讓人一眼看懂其作了什麼。簡潔也並不僅表如今代碼上，類、包、資源文件等的命名和組織結構等也一樣須要保持簡潔。
如何保持簡潔？這個問題並無一個標準的答案，但有一個判斷是否簡潔的簡單標準，那就是：直接閱讀代碼就可以理解代碼的意圖，若是意圖不夠明顯，那就說明這段代碼還不夠簡潔。類、包、資源文件等等，也是一樣的評判標準。下面是我以爲對保持簡潔有必定做用的一些操做方法。

• 包的組織

  按照組件類型來分包，而不是按業務模塊來分包。業務有可能會變，但組件類型是基本不變的。另外，新加入的開發人員，對業務不熟悉，但對組件是很清楚的，理解快，入手也快。

• 類和接口的命名

  組件類的命名添加該組件的後綴，例如：Activity類命名添加Activity後綴，Fragment類命令添加Fragment後綴，適配器添加Adapter後綴，等等。實體類則可添加BO的後綴名稱，工具類添加util後綴，接口的實現類添加Impl的後綴。接口的命名也同樣，好比，個人項目中，接口層的接口後綴都帶上了Api，核心層的接口後綴都帶Action。

• 資源文件的分類

  strings.xml文件用來存儲應用中的全部字符串，包括頁面標題，按鈕文字，標籤文字，提示文字等等，應該作好分類並統一存放。下面是我推薦的分類方法，若是某個分類的字符串數量太多了，還能夠拆分出來放到一個獨立的文件，好比頁面標題，能夠拆分到strings_title.xml文件裏，其餘資源文件也能夠用相似的方式進行處理：

• 頁面標題，命名格式爲：title_{頁面}

• 按鈕文字，命名格式爲：btn_{按鈕事件}

• 標籤文字，命名格式爲：label_{標籤文字}

• 選項卡文字，命名格式爲：tab_{選項卡文字}

• 消息框文字，命名格式爲：toast_{消息}

• 編輯框的提示文字，命名格式爲：hint_{提示信息}

• 圖片的描述文字，命名格式爲：desc_{圖片文字}

• 對話框的文字，命名格式爲：dialog_{文字}

總結

規範性、單一性、簡潔性，這三個基本原則是相輔相成的。單一性和簡潔性是規範定義的標準，不能脫離這兩個原則去定義規範。而對規範的嚴格執行，則保證了後兩個原則的有效性。