Android開發規範：包命名規範
-
簡介
android包目錄的命名的好壞，會直接影響到整個app工程後期的開發效率和擴充套件性。
所以在建立專案的初期，建立一個好的包目錄的命名非常重要。
一般來說android包命名的方式有兩種：PBL和PBF。
我們現在分別來介紹下這兩種命名規則以及各自的優缺點。 -
PBL(Package By Layer)
字面意思是按層次劃分，實際上就是按照職能劃分，比如app裡面分為activity、fragment、view、service、db、net、util、base等。
顧名思義，activity的職能是管理所有的activity類，只要這個類是extends Activity的，都放到這個目錄下面；以此類推，fragment目錄放所有extends Fragment的類。view放置自定義的View，net放置管理網路相關的，bean放置
bean物件。
參考如下目錄結構：
└─src └─com └─android └─demo ├─activity │ LoginActivity.java │ SettingActivity.java │ ├─bean │ UserBean.java │ ├─db │ DBManager.java │ ├─fragment │ NewsFragment.java │ PictureFragment.java │ ├─net │ RetrofitManager.java │ └─service BackgroundService.java
這也是我們以前開發專案常用的包目錄結構。
PBL的優點：
- 專案結構簡潔明瞭，上手快；
- 適合開發人員不多，後期變動不大的專案；
PBL的缺點：
-
低內聚
同一個包下會是各種功能模組的集合。比如activity包，下面放置了登入、設定等功能模組；這幾個模組本身並沒有很強的關聯性，卻放在了一起，聚合性降低。 -
高耦合
這裡講的高耦合是指package之間的關聯性，比如activity包內的類往往引用到了fragment或者view裡面的類，package之間的關聯性比較緊密。 -
開發效率
開發一個功能模組，往往需要到不同的package裡面來回切換。比如登入模組，需要到activity裡面開發LoginActivity，Activity往往包含了fragment，這時又需要去fragment裡面找到對應的fragment來開發。package之間相互切換確實會影響開發效率。同樣，修改、除錯一個功能也需要這樣的操作。如果後期專案功能和程式碼增多，會大大降低開發效率。 -
PBL(Package By Feature)
PBL的意思是：按照功能劃分包名。就是app裡面有什麼功能模組，就以這個功能模組作為包名，所有這個功能模組的開發都在這個包名下進行。
我們看一個很經典的google iosched app的包結構，相信大家對比PBL很容易看出差別。
PBF的優點：
- 高內聚
所有功能都在一個包名下面完成。比如map模組：
所有的activity和fragment都在這裡面，包括相關的util。
這裡需要說明的是，功能模組裡面的util一般都是和這個功能模組強相關的，如果是功能模組包名外的util包名，一般放置的是跟專案相關的util類，能作用於整個或者多個功能模組的util類。
其它包名類推，比如ui包名下面放置了BaseActivity。 - 低耦合
package之間沒有很強的關聯性，開發此模組的功能只需要在對應的包名下面進行開發即可，除了基礎類外，一般不需要引入其它包的類。 - 開發效率高
增刪改查都只要在對應的包名下面進行即可，後面的開發人員接手也方便。 - 便於後期元件化轉化
如果專案是按照PBF來進行包名劃分的，後期進行元件化改造的時候就會非常方便。
可以直接把功能模組獨立出來作為一個元件，同時劃分好程式碼邊界，對外保留好訪問介面。
比如上面的map功能，我們可以把map獨立出來作為一個library工程。