Android APP架構心得

前言

從JavaEE轉到Android開發也2年多了，開發的項目也有4,5個了（公司項目），其中有3個項目前期都是自己獨立開發，從一開始的毫無架構到現在對如何架構也有一點心得，所以在此分享出來，大家一起交流

什麼是架構

在我看來，軟件架構絕對不只是框架的堆砌，看我看來，架構是為了方便軟件維護、擴展、安全性、切入性（我也不知道有沒有人提出過這個關鍵字，因為的確很少看見，簡單來說我這裡說的切入性就是指一個以前沒有接觸過這個項目的人，能快速加入到這個項目中，對項目進行維護、修改和擴展）

維護性

一個好的軟件（不一定是成功的軟件，這裡說的好只是程序員認為的代碼方面）肯定是能方便維護的，出了問題能快速定位，需要修改時能快速修改，並且在一定程度上不會說一修改就一堆bug，這就是我認為的可維護性，當然後面要說到的切入性其實也算是維護性，不過為什麼單獨放出來在切入性時我會詳細說明。至於怎麼樣才能使一個軟件維護方便，我覺得有以下幾點：

1.代碼規范

一份代碼如果沒有遵循任何規范，那麼我相信它的可維護性是很差的，就算是你一個人做出來的，估計過了幾個月去修改的時候也會冒出一句這TM是什麼鬼

2.框架穩定性

很多時候很多開源框架剛出來的時候，也許功能十分強大，但是畢竟剛出來，沒有經過充分的測試，所以還是會或多或少存在一個不穩定因子，所以建議在選擇框架時盡量選擇成熟穩定的框架，哪怕功能和性能的確比不上剛出來的框架。當然這也不是說完全不用剛出來的框架，畢竟都不用，那麼它也永遠成熟不了，至於到底用不用和怎麼用，本文的框架選擇和使用篇也會詳細分析說明

3.封裝

本來想說AOP的，但是個人覺得很多專業性的名詞也比不上一些通俗的形容，畢竟本文主要的目的是讓人理解，不是提出理論。封裝這個在Android中是經常使用的，簡單來說就是把一些常用的、通用的東西進行一個封裝，通過統一入口進行調用，這樣出問題就只需要修改一個地方，就能全部修改過來。同時封裝也要注意一些常見的坑，比如我曾經就踩過的context坑，當時封裝了一個UIUtils（主要是針對UI相關的工具類），因為很多方法都要使用context，所以直接application傳進去，保存了，所有方法都不用傳context，但是這樣卻出了一個bug，那就是有些操作用application的context是有問題的。當然這種還比較好處理，但是如果因為封裝導致內存洩露，這就難以查找了，比如你傳入了一個activity的context，但是activity已經關閉了，但是因為你封裝的方法裡面還在繼續使用這個context，所以activity的內存也是不會釋放的，所以封裝的時候也一定要注意，不要給自己挖坑

4.耦合

針對耦合這個東西相信很多文章都說過了，如何解耦合，不過個人感覺解耦合這個東西也要適度，不要因為解決一點耦合，花了大量的代碼，浪費了大量的性能，所以解耦合這個東西就一定要把握這個度，過度設計是有問題的設計，這點我是贊同的。同時很多時候封裝會導致一些耦合的問題，比如我曾經一個項目中就有個這個一個情況：

因為項目中使用了滑動選取身高的WheelView，因為當時是彈Dialog出來選擇的，所以當時想也沒想就直接封裝了一個Dialog，後面又出來了一個選取年齡的，然後又封裝了一個Dialog，以至於到後面封裝的Dialog有7,8個了，但是有些界面因為選中後的處理有些不一樣，導致Dialog裡面的代碼混亂，所以後面就直接簡單的封裝了一個Dialog，傳入需要選中的數據集合和選中監聽，這樣就用了一個Dialog就能處理多種數據的選擇，還能根據不同界面分別處理，當然這樣也不是萬金油，畢竟這樣每個界面都需要自己實現監聽，所以很多時候有利就有弊，至於具體怎麼取捨，就看利是否大於弊

擴展性

擴展性簡單來說就是當程序需要新的功能時，能否對其進行擴展以及擴展的難度來判斷，如何提高擴展性，我覺得有以下幾點：

1.抽象接口

這點相信大家都經常遇到，比如Android的點擊事件，你想要實現什麼樣的點擊效果，自己實現一個點擊監聽，然後設置給控件就可以了

2.元素重用

很多時候，很多功能模塊可能使用到相同或者類似的元素，如何Android中的一些布局，這些如果抽取出公共部分在進行擴展的時候方便對其快速擴展，當然這個是項目一開始並不能預見的，所以需要在開發中不斷的去重構

3.單一職責

這個跟其實就是面向對象的單一職責，比如前面提到的Dialog，一開始只有選擇身高的功能，看起來是單一職責，但是其實相關處理也包含在其中，所以那個Dialog類本身職責已經不單純，當然如果一直只有這一個，這樣做沒有任何問題，也能看做單一職責，但是如果有多個選擇和處理的時候，就必須對其重構了

4.替換性

替換性包含裡氏代換但是也不僅僅是裡氏代換，比如常見的Android布局不同，但是其顯示內容大致相同，這樣寫布局的時候就可以對相同內容的控件指定相同的id，這樣就算替換布局，也不用重寫ViewHolder，當然對於Adapter也僅僅只需要替換相應的布局就ok

5.耦合

這個和維護的耦合相同，畢竟很多地方本來就存在交叉，所以就沒有必要再說了

安全性

個人覺得數據安全性並不僅僅是數據安全，還有程序的一些操作安全性（簡單來說就是避免程序出現一些非崩潰性異常）

1.數據安全性

數據安全就包括數據抓取、數據攔截以及數據修改。當然這些並不能完全避免，只能是由我們寫出盡量安全的代碼，比如關鍵數據使用HTTPS以及對數據進行md5驗證完整性，對於數據修改，可以通過多文件多地址保存文件修改記錄，來確定保存的數據是否被修改，畢竟Android只要獲取root權限，就能對很多文件進行修改了

2.操作安全性

簡單來說經常遇到的一個問題，比如按鈕的點擊事件，有可能這個點擊事件是請求網絡或者打開Activity，這樣就會存在事件還未處理完成再次收到事件，只要你一直猛點，肯定可以的，所以這樣就需要我們隊控件事件進行一些封裝，比如打開界面的，可以在點擊後禁用按鈕，界面打開完成後才啟用，請求網絡的可以在開始就禁用按鈕，請求結果反饋了才啟用（不管是請求成功或者失敗）

切入性

切入性就是當另外一個從未接觸過此項目的人，能快速進入這個項目進行開發，當然想要切入性好，前面的維護和擴展是必須要滿足的，下面我就說說我認為能增加切入性的一些點

1.文檔

開發都不喜歡寫文檔，這是肯定的，但是每當我們去接手一個項目的時候，發現沒有文檔估計就要開始罵娘了，所以文檔不僅要寫，還要寫的規范。我認為開發中必須要有的幾個文檔：代碼規范文檔（比如包名規范，文件命名規范，id命名規范等等，具體依據項目情況而定）、接口文檔

2.注釋

每個類必須要有注釋，方法也要有注釋，同時也要標注好方法最後修改人是誰，這樣出現疑問或者問題別人就知道該去找誰了，當然有些方法是不需要有注釋的，比如重寫父類的方法，只是如果方法內邏輯很復雜，可以在方法中添加一些對邏輯的說明。當然注釋也不是越多越好，具體注釋該怎麼寫，Google最清楚，不能Google百度也行

3.包名

什麼類放什麼包簡單，但是一但一個包中的類太多，也是非常不方便，所以正確的分包也是非常重要的，目前常見的Android分包包括針對功能分包（不是指程序功能，而是指UI,http,bean這些功能），還有就是模塊分包（這就是程序的功能了，比如login，user等），當然具體怎麼分包需要團隊協商，防止一個包中類太多，而我現在一個程序很大的情況下，采用的分包是先功能分包，再模塊分包，比如：

wang.raye.demo
|-activity
| |-user
| |-login
|-fragment
| |–user
| |–login

這樣能減少每個包的類數量，當然如果項目本身並不是很大，可以完全不用這種分包模式，畢竟如果只是小項目，這樣會使項目變得更加難以閱讀

MVC 還是 MVP

現在針對移動端開發，衍生了很多種架構，如MVC、MVP、MVVM，當然這裡著重分析MVC和MVP，畢竟MVVM我也只是了解過一下，沒有詳細接觸，至於什麼是MVC和MVP我也不想做過多描述，這類的文章實在太多，這裡主要分析一下什麼情況下用MVC和MVP

至於很多人接觸過MVP後就覺得MVC就一無是處，我個人覺得這是不對的，不同的項目，不同的業務，用不同的架構，這是我覺得應該做的事，沒有一種架構能適合所有項目開發（畢竟現在還沒有），所以我們分析MVC和MVP分別在Android以什麼樣的方式實現

MVC

MVC是以XML布局為V（視圖），Activity或Fragment為C（控制器），數據實體為M（模型），但是因為XML的局限性，所以其實我們還是需要在Activity或Fragment中對視圖進行操作，所以這也就是為什麼那麼多人抵制MVC的原因，因為這也算不上完整的MVC

優點：開發迅速，結構易理解

缺點：當一個界面業務邏輯一多，不方便維護

MVP

MVP是為XML配合Activity或Fragment為V（視圖），同時抽象出接口，界面相關業務抽離出來的P(Presenter)同時通過視圖接口來更新UI,數據實體為M（模型）

優點：業務發生變化時易修改，同時能減少修改過程中引發bug，也能將多人協同開發充分調用起來（並不是針對一個人負責一個模塊的模式，而是多人協同開發一個模塊）

缺點：開發速度會有所降低

所以對比2種架構，發現MVC適合不需要太多業務邏輯和功能性少的APP，比如數據展示類應用，MVP適合每個界面有復雜邏輯以及大型多人開發的APP

框架選擇及使用

如何選擇框架

1.穩定性

如果框架本身就不穩定，那麼導致的結果就是程序本身也會漏洞百出，所以選擇框架一定要選擇經歷過考驗的穩定的框架

2.擴展性

隨著程序功能的增加，以前的框架可能會出現功能不足的情況，但是因為這點是不可預見的，所以我們選擇框架時一定要了解好框架本身的擴展性如何，或者對框架有較深的理解，能夠自己擴展框架，當然有些框架解決的問題比較單一，一般也不用擔心過多的擴展性，比如Butterknife或PreIOC這類單一性框架，但是有些框架經常需要配合做一些操作，比如圖片加載框架，常見的一些就是清理圖片緩存、獲取圖片緩存大小、顯示圓角或者圓形圖片， 常用的圖片加載框架UniversalImageLoader都提供了相關的方法或接口來實現

3.封裝性

封裝性是指能否針對框架進行二次封裝，以及封裝後的耦合度，詳細會在使用篇說明

如何使用

選擇好了框架千萬不要拿來就用，因為再好的框架也有它局限的地方，當然你也可以簡單的在遇到這個框架不能實現的時候，添加另外一種框架，只是這樣項目會越來越大，對於APP來說APK也越來越大，65535 的問題也會提前出現，所以為了方便以後有可能出現的切換框架，以及防止初期對框架使用不熟悉而引發出新的bug，在選擇好了框架後，一定要對框架進行二次封裝，當然有些框架是不需要二次封裝的，比如前面說的單一性的框架Butterknife或PreIOC，但是像UniversalImageLoader、OKHttp等框架，必須要進行二次封裝，至於封裝原則，則是封裝後，調用框架對於調用代碼來說是透明的，簡單來說，就是對於框架調用都通過一個統一的入口進入，並且調用時，不需要傳入任何跟框架相關的東西，如果必須要傳入接口，可以通過繼承框架來實現新的接口傳入，這樣在真正的使用框架的地方，沒有任何關於框架的引用

封裝的好處

之所以要這樣封裝，最大的好處就是一旦框架不能滿足需求時，需要進行框架更換時，只需要換掉框架，同時修改統一入口處的代碼，就能快速的替換整個框架

結尾

以上就是我在Android APP架構上面的一些心得，此文可能並沒有教你快速搭建一個框架，只是指明搭建框架時需要注意和搭建框架的一個方向，當然軟件是死的人是活的，具體項目具體處理，畢竟別人的東西只能是借鑒和學習其好的思想。同時也歡迎大家吐槽交流（QQ群:123965382）