歡迎光臨
每天分享高質量文章

開發雜談:Android 移動應用架構發展簡史

作者:門心叼龍

連結:https://www.jianshu.com/p/9968d4a6e417

我們經常在感嘆,技術更新換代太快,但是不管怎麼變,永遠不變的一個核心思想就是“呼叫更加方便、更加安全、架構清晰,程式碼簡潔、反對臃腫、程式碼之間的耦合度更低”,這是一個好的軟體永遠追求的標的。

忙了將近兩個月,也算告一段落,一直打算寫一篇關於專案架構方面的文章,也是對這段時間工作的一個歸納總結,正好清明節放了三天假,難得有時間…

一週科技雜談:

上個周,王興團長在接受境外媒體參訪的時候,舊事重提了當年支付寶獨立的陳芝麻爛穀子的事兒,指責馬雲有誠信問題,這件事兒其實和美團一點關係都沒有,這事兒還不夠,又發了一個朋友圈對阿裡的人事進行指手畫腳,給阿裡指定“太子”。去年還是東哥的輿論場,如今卻變成了王興輿論場,眾所周知,東哥由於明尼蘇達事件已經是身敗名裂,現在是徹底退居二線了,東哥現在確實低調了很多,微博個性簽名都改成了,“低調,低調,在低調”。

我們還記得在2017年烏鎮世界網際網路大會上東哥和王興組了聲勢浩大晚宴“東興”局,照片一齣,馬雲騰C位正襟危坐,左右分別是劉強東和王興,其他各網際網路大佬都列作於此,唯獨不見馬雲,明眼人都能看出來,這就是要孤立馬雲,隨後劉強東參加了“共享紅利–網際網路精準扶貧”的論壇,劉強東講到:“有人說一個月賺幾十億已經成為讓人痛苦的事情,在我國還有幾千萬的生活在極端貧困的狀態,這是中國已經富起來的這些人的恥辱”,很明顯這話是在懟馬雲。

事後,馬雲在接受媒體採訪時說“我馬雲豈能是一場飯局就能擊垮的,我可以把世界級的大佬邀請來,也搞一個有必要嗎?沒有”,這就是馬老師的格局,隨後劉強東異常高調,但是還不到一年的時間,就出了劉強性情事件的醜聞,估計馬雲聽到這事情會大笑三天三夜。現在東哥消停了,王團長又來了,不管是蹭熱度還是有其他什麼目的,但是在公開場合作為企業創始人公開懟別人,這就是你的不對了,俗話說:“凡事留一線,日後好見面”,劉強東的事兒雖然沒有觸犯法律,但是卻徹底失聲了,自己也是身敗名裂,企業形象嚴重受損,有人說被人“做局了”,我想無論是有沒有被“做局”,但是事情你終歸還是做了,就是被人做局,也是別人抓住了你的人性的弱點。用當年上大學時宿舍裡面經常說的一句陝西口頭禪:“娃是好娃,女人把娃害了”。

企業之間競爭不可避免,搞團團夥夥,拉幫結派,公開懟,這就有些太小肚雞腸,小人形象暴露無遺,劉強東徹底消停了,王興又來了,我想這小子會不會是下個東哥?平日除了研究技術,最大的愛好就是寫毛筆字練書法,最愛寫的八個字就是,“上善若水”、“厚德載物”,水利萬物而不爭,君子以厚德載物,如果德不配位,早晚遭殃。

專案架構的重要性:

好了,我們言歸正傳,我們在前面幾篇文章談到了一些專案架構的問題,年前寫了一篇“Android元件化最佳實踐”,年後寫了一篇“淺談單一結構體專案的元件化改造”,我們提到了單一結構專案裡,結構混亂,層次不清,有些模組同一功能解決方案不統一、有了新需求只是在原有專案上不斷的砌程式碼罷了。長此以往,整個專案就是鐵板一塊,為後期的專案維護和擴充套件造成了極大的困難。

我們在軟體開發的時候,在做一個專案之前,架構師做工作就是搭專案框架,這是一個前提工作,給整個專案制定開發標準,開發規範,如果沒有規範,專案可以搞起來嗎?當然可以,就是個開發人員各行其是,最後的結果就是,專案做完了,整個專案結構混亂,層次不清。反之,一旦形成自己的一套框架體系,就可以長期使用,甚至成為整個公司的一套開發標準,大大提高後期的專案開發效率,來了新專案就直接可以在新專案中使用,而把主要的精力放在業務功能的實現上。

架構的變:

前陣子在一個技術群裡面,有人說他們現在還用的是傳統的架構MVC的架構,覺得挺好,甚至還在用ListView,我只能說,你感覺良好就行,有這種情況嗎?肯定有,以前的一些老技術,老方案,能實現嗎?當然可以,可以實現具體的開發要求,就好比你去理髮店理髮,你進店之後,前臺就會問你,你要找那個老師給你理?我們這裡有20塊的,也有50塊,最高是200塊的,問你要選一種?20塊也能做,200塊也能做,價格卻整整差了10倍,為什麼?這就是不同老師他們水平不一樣,做法不一樣罷了,你20元有20元的做法,你200元當然有200元的做法,我們做軟體開發也一樣,同一個專案,你給兩千元有兩千架構的做法,你給二十萬也有二十萬元的架構的做法,最終功能都能實現,只是軟體質量不同罷了。

架構的不變:

在後移動時代我的一些思考的這篇文章裡,我們談到這是一個知識爆炸的時代,尤其是做技術這一行業的,不像一些傳統的行業,例如醫生、律師這些知識結構相對穩定的行業,可以說日新月異,技術更新換代太快了,但是不管技術怎麼變,但是永遠不變的一個核心思想就是“呼叫更加方便、更加安全、程式碼之間的耦合度更低”,這是一個好的軟體永遠追求的標的。

程式碼質量問題:

同樣的一個功能初級工程師能實現嗎?可以,高階工程師可以做嗎?當然也可以,有何不同?可能高階工程師1個小時就能實現的功能,作為一個初級工程師可能需要1天時間才能完成,一個高階工程師可能需要50行程式碼實現的問題,初級工程師可能花了兩三百行才能搞定,高階工程師實現的功能bug率很低,而初級工程師可能一測試到處都是bug,這就是區別,這就是軟體的質量不同。

當然,在實際工作當中有很多時候,專案需要趕進度,領導看的是結果,就看你功能實現了沒有?你沒有辦法,只能選擇做20元了,因為你想要做好,你就需要花更多的時間了,而現在沒有人給你這個時間去做這個工作。

程式碼簡潔之道:

在唐代有一位大詩人叫白居易,他每作一首詩,都要給不識字的老太太念念,老太太能聽懂的,就要,聽不大懂的,就改,這也是為什麼他的詩一直在民間廣為流傳,而且還流傳到了日本,而我們寫程式碼也是一樣的道理,越簡單也好,我曾經看過別人寫的一個關於app應用市場下載的功能,一個簡單的功能搞了十幾個類,各個類之間層次不清,取用關係混亂,實在讓人看不下去,一個好的工程師,不在於你寫了多麼複雜的功能,而在於你寫了一個多麼好的功能,程式碼簡潔,結構清晰,人人都能看懂,這才是好程式碼,反對臃腫,真正的做到了簡約而不簡單,這才是編碼高手。

Android應用架構發展史

一代MVC架構:

 

  • Model: 用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法

  • View: 渲染頁面

  • Controller: 控制器,他是M和V之間的聯結器,處理相關的業務邏輯

標準的MVC架構它的工作流程:

  1. View接受使用者的互動請求

  2. View將請求轉交給Controller

  3. Controller操作Model進行資料更新

  4. 資料更新之後,Model通知View資料變化

  5. View顯示更新之後的資料

MVC工作流程圖:

在最早從事android開發這批人員,最早使用的是都是MVC架構,這是一種非標準的MVC架構,因為Activity及承擔Controller的角色,又承擔了View的角色。Activity 和 Fragment 越來越多的同時承擔了 Controller 和 View 的職責,導致他們變得及其臃腫且難以維護,由於 Controller 和 View 的揉合,回呼巢狀太多,程式碼邏輯不清晰,難以理解且不利於後期維護,各層次模組之間職責不清晰等等。

二代MVP架構:


在2016年,Google 推出的基於 MVP 架構的 Demo 後,我們發現 MVP 架構能解決現在所面臨過的很多問題

MVP工作流程圖:

  1. View接受使用者的互動請求

  2. View將請求轉交給Presenter

  3. Presenter操作Model進行資料庫更新

  4. 資料更新之後,Model通知Presenter資料發生變化

  5. Presenter更新View的資料

MVP架構圖如下:

  • View Layer: 負責繪製UI元素、與使用者進行互動,對應於xml、Activity、Fragment、Adapter,包含一些自定義的 UI 元件

  • Model Layer: 負責檢索、儲存、運算元據,包括來自網路、資料庫、磁碟檔案和SharedPreferences的資料

  • Presenter Layer: 作為 View Layer 和 Module Layer 的之間的紐帶,它從 Model 層中獲取資料,然後呼叫 View 的介面去把資料顯示在View上

  • Contract: 參照 Google 的 Demo 加入契約類 Contract 來統一管理 View 和 Presenter 的介面,使得某一功能模組的介面能更加直觀的呈現出來,這樣做是有利於後期維護的。

儘管這樣,MVP樣式也有不足之處,不然也不會推出MVVM了,缺點如下:

  • Presente層與View層是透過介面進行互動的,View層可能會有大量的介面,因為有可能好幾個Activity都是去實現同一個View介面,那麼所有用到的Activity都要去實現所有的方法(不管你是否用到),而且如果後面有些方法要刪改,Presenter和Activity都要改動,比較麻煩;

  • MVP把Activity相當的一部分責任放到了Presenter來處理,複雜的業務同時也可能會導致P層太大,一旦業務邏輯越來越多,View定義的方法越來越多,會造成Activity和Fragment實現的方法越來越多,依然臃腫。

 

三代MVVM架構:


相對於 MVC 的歷史來說,MVVM 是一個相當新的架構,MVVM樣式不是四層,任然是3層,分別是Model、View、ViewModel,MVVM 在使用當中,通常還會利用雙向系結技術,使得 Model 變化時,ViewModel 會自動更新,而 ViewModel 變化時,View 也會自動變化。所以,MVVM 樣式有些時候又被稱作:model-view-binder 樣式。

MVVM 在實際使用中,確實能夠使得 Model 層和 View 層解耦,但是如果你需要實現 MVVM 中的雙向系結的話,那麼通常就需要引入更多複雜的框架來實現了。

  • View:檢視層,採用XML檔案進行介面的描述

  • Model:模型層,透過網路和本地資料庫獲取檢視層所需資料

  • ViewModel:檢視-模型層,負責View和Model之間的通訊,以此分離檢視和資料

工作流程:

  1. View中使用DataBinding的Command來系結事件和響應事件,觸髮網路請求

  2. ViewModel進行分析處理,呼叫Model的方法去請求資料

  3. Model將收到的請求引數等資訊封裝,呼叫網路請求庫

  4. 伺服器將資料傳回Retrofit等網路庫,再傳回到Model層中

  5. ViewModel在回呼中收到傳回的物體類物件

  6. 因為xml與物體類物件實現了雙向系結,物體類更新,使得UI更新

MVVM也存在著自己的一些缺點:

  • 資料系結使得 Bug 很難被除錯。你看到介面異常了,有可能是你 View 的程式碼有 Bug,也可能是 Model 的程式碼有問題。資料系結使得一個位置的 Bug 被快速傳遞到別的位置,要定位原始出問題的地方就變得不那麼容易了

  • 對於過大的專案,資料系結需要花費更多的記憶體

某種意義上來說,我認為就是資料系結使得 MVVM 變得複雜和難用了

四代架構MVP+元件化


前面講的這三種android開發中常用的專案架構,不管是哪一種架構,它始終是一個單一結構體專案,各個模組之間還是以傳統的包名來區分的,其各個模組還是強耦合在一的,自然而然元件化的方案就出現了,元件化有開發樣式和釋出樣式之分,在開發樣式下每個業務模組都是都是一個獨立的apk,在釋出樣式打包的時候,每個業務模組都變成了一個個獨立的元件library,這就完成了各個模組之間的徹底解耦。

今年開年以來公司就上了一個新專案Vcars,就採用了MVP + 元件化的解決方案,現在透過文字的形式把它記錄下來,也是對這段時間工作的一個歸納總結。

Vcars元件化架構圖:

  • 整合樣式:所有的業務元件被“app殼工程”依賴,組成一個完整的APP;

  • 元件樣式:可以獨立開發業務元件,每一個業務元件就是一個APP;

  • app殼工程:負責管理各個業務元件,和打包apk,沒有具體的業務功能;

  • 業務元件:根據公司具體業務而獨立形成一個的工程;

  • 功能元件:提供開發APP的某些基礎功能,例如列印日誌、下拉掃清控制元件等;

  • Main元件:屬於業務元件,指定APP啟動頁面、主介面;

  • Common元件:屬於功能元件,支撐業務元件的基礎,提供多數業務元件需要的功能

Vcars專案類圖

  • Activity關係圖:

  • Fragment類關係圖:

  • BaseRefreshActivity類圖:

  • BasePresenter類關係圖:

  • BaseModel類關係圖:

總結:

整體來看MVVM 比MVC/MVP精簡了很多,不僅僅簡化了業務與介面的依賴,在MVVM中,View不知道Model的存在,ViewModel和Model也察覺不到View,這種低耦合樣式可以使開發過程更加容易,提高應用的可重用性。

不管是MVC,MVP還是MVVM,他們都屬於專案的編碼架構,而元件化是整個工程的工程架構,它的主要意義在於,對原來以包來區分的各個模組進行完全的解耦,但是不管技術怎麼怎麼更新換代,但是永遠不變的一個核心思想就是“呼叫更加方便、更加安全、程式碼之間的耦合度更低”,這是一個好的軟體永遠追求的標的。

已同步到看一看
贊(0)

分享創造快樂