APP開發兩年的心得：App代碼架構設計(1)

這篇文章全程文字，不帶圖，不帶電影。但真的有可能給你帶來不同的視角；要認真看！

還有不對的地方留言評論。也但願多評論留下你的見解，這也許能幫助到我。感謝

前言

工做兩年，一直都是從事App開發方面，作過原生App，混合App，公衆號，小程序也偶爾寫一下簡單的後臺接口。在開發一個App的過程當中，開發原生以及混合的方式有很大不一樣。 在原生（java）的時候常常會盡力的去構想如何構建基類，如何抽象。代碼的分層分類都井井有理的感受。而在混合開發（前端代碼）中，對封裝，基類，類等等的構思十分少，僅僅是作一些相似工具類的封裝。我本來覺得前端是不支持繼承多態之類的，但沒想到我錯了，這僅僅是由於我不會而已。

看完能學到什麼？

這裏沒有具體的代碼，有的僅僅是本身這兩年接觸的項目總結，從架構的角度儘可能去思考。 不管哪一種開發形式，原生App，混合App，公衆號，小程序，網站等等在開發前都應該先有對總體的設計。

博主小白的見解 框架設計是從上到下去思考，而實現代碼是由下往上去實現。 舉個例子，當你要去完成一個開發App的項目的時候。每每需求都不是那麼的明確，總有那麼一些不明確，可能被修改的點。而框架的作法就是把這些問題都抽象起來，避免具體實現；也就是說構思框架的時候不要跟業務扯上關係；不過一樣有說法就是，不考慮業務的框架都是shit。這也對，總之見仁見智。

開始作一個項目以前應該要考慮的事情：

因此我在剛開始思考的是：

1. 總體框架搭建
2. 結合業務需求進行技術選型

總體框架搭建：

APP交互分層：MVC / MVP / MVVM；最總體的代碼分層，各層之間的關係。 例如MVP在其中再細分層： M：

• core(核心實體類)
• domain(app輔助實體交互類)
• func(業務類)

V:

• activity/page
• fragment/component

P:

• presenter

通常我會新建一層與MVP同級別的，O(other)；這一層是輔助MVP可以順利工做的。可以讓MVP可以更加專心作本身只關心的是。 O:

• base (存放base類的定義)；
• constant（全局常量定義）
• util（工具類相關）
• http（網絡相關）
• sql（數據庫相關）
• imageLoader（圖片相關）
• toast（）
• dialog（）
• ...

這裏有不少人會有疑問，爲何toast，dialog都要做爲一層？直接Toast.show這樣不就行了嗎？其實也行，功能照樣可以實現。不過你把他定義爲toast到外層，每一個須要彈toast的找他。若是你的app不少地方都能作到這樣的話，那說明會是一個很不錯的點。譬如，你的項目經理說：那個toast有點醜，能不能把背景顏色改一改啊？只是後你就知道這樣統一的出口是多麼重要了，而不是散落在各個地方。觸類旁通...很重要

構建基類： 也就是base類的建設， BaseApplication、BaseActivity、BaseView、BasePresenter、BaseModel、BaseMvpView.... 等等。對於基類的建設有一點要注意的是，真的只放最通用的行爲在裏面。不要爲了貪圖方便而把一些基類不該該作的事情強迫基類去作，否則基類不變成gay類了。或者是這些動做不該該是該類或者該方法去作的，卻爲了方便貪圖一時酒池肉林而縱容本身寫下這該死的代碼。

案例1：

BasePresenter，以及BaseMvpPresenter。BasePresenter只放最基本的，而在MVP模式中每每須要針對MVP模式區構建一個更加適用的Presenter，好多同窗會把這些功能寫到BasePresenter中去；這真的不太好。咱們要新增BaseMvpPresenter去繼承BasePresenter再完成BaseMvpPresenter該作的事情。

案例2：

關於網絡請求Http的封裝，Http中核心方法，request()這個方法是真正發起請求的，那麼就讓他只作這些如何發起請求相關的事情吧，至於後面須要控制個loading顯示與否；就不要讓這個方法去控制了；又或者說組裝參數什麼的...亂起八糟的事情就不要讓人家去作，真的很煩大家這樣。否則到時候改個loading的控制以後,"咦，怎麼喔的傳參穿錯了？不可能啊根本沒動過這個代碼...".觸類旁通...很重要。。 這個話題不只僅是針對構建基類的了，而是從框架分層--->類--->方法；都要保持這樣的底線。這樣滿滿培養好的習慣，到之後接手別人代碼的時候你就會想打人了，這個時候也說明你真的很不錯。

結合業務需求進行技術選型

而後就是結合業務需求去進行技術選型，像圖片加載的框架呀，網絡請求框架呀。其實這些我我的大多都是喜歡哪一個用哪一個！！！ 最基本的網絡請求框架：okhttp，retrofit，volley這幾個確定要知道他們之間的優缺點差別的...不須要都會用，可是要清楚他們的優缺點，能知道用這個能作哪些不能作哪些基本就能夠了，這根本不影響單手敲代碼的速度。

差很少能夠進入真正敲代碼的階段了！！！ 敬請收看下一篇：

雖然只有兩年的開發經驗，在一些大牛眼裏看來可能以爲對框架設計怎麼可能有什麼看法；你說對了，但每一個開發者都會經歷的過程，從擼代碼到思考設計。我是小白，但有一些比我更白的人他們有時可能會更願意看到通常白的人是怎麼開發的？由於更符合實際，哈哈哈。