《Android構建MVVM》系列(一) 之 MVVM架構快速入門

時間 2019-12-12

標籤 Android構建MVVM 系列 mvvm 架構快速入門欄目系統架構简体版

原文原文鏈接

前言

　　本文屬於《Android構建MVVM》系列開篇，共六個篇章，詳見目錄樹。java

　　該系列文章旨在爲Android的開發者入門MVVM架構，掌握其基本開發模式。android

　　輔以講解Android Architecture Components，使得更好的實現MVVM架構。git

目錄樹

《Android構建MVVM》系列(一) 之 MVVM架構快速入門
- 前言
- 分層思想
- 什麼是MVC/MVP？
- MVVM是什麼，與MVC/MVP有何區別？
- Android Architecture Components(架構組件)
- 一個MVVM的Demo
- 結語
《Android構建MVVM》系列(二) 之架構組件LiveData
《Android構建MVVM》系列(三) 之架構組件ViewModel
《Android構建MVVM》系列(四) 之架構組件Room
《Android構建MVVM》系列(五) 之構建更好的Demo
《Android構建MVVM》系列(六) 之總結與展望

正文

1、分層思想

　　分層是一種思想，同時也是一種架構模式。它的特色是專職，即某一層的職責是相同的、肯定的；好比咱們平時所謂的Dao、Controller層…他們都有明確的職責。github

　　分層思想具體表現爲，經過抽象某一類的邏輯構成一個水平功能面，進而對上層提供API；多個層面相互依賴、配合提供總體解決方案。層與層之間的依賴關係是自上而下的，即上層依賴下層，下層不能依賴上層，最底層的組件沒有依賴。編程

　初學者每每搞不明白爲何明明能夠直接編碼業務邏輯，還要去作所謂的分層架構呢？json

其實對僅僅實現需求來講，用不用分層架構沒有關係的，不分層照樣能夠實現；那麼爲何咱們還要徒增煩惱呢？有句話說的好：「存在即合理」，也就是說既然咱們的前輩研究出了所謂的分層架構，而且沿用至今；那麼就必定有它的優勢，必定是解決了某一領域的痛點而誕生的api

試想如下場景：當你的項目隨着需求的增長和不斷調整，不可避免的就要去改動已有的代碼，若是項目規模不大還好，若是是個老古董項目，可能某個類裏面上萬行的代碼，沒有註釋，沒有采用分層架構，相信我，你會哭的緩存

　　分層架構雖然說不能完徹底全的解決項目程序複雜度高的問題，可是經過分層，將大的問題抽象分解成了小的功能面，局部化在每一層中，這樣就有效的下降了單個問題的規模和複雜度；另外層與層之間也能夠經過簡單的調整，插入新的層面，用以知足不斷變化的需求，同一層面來講也可近乎0成本的水平擴展；而且易於後期的Debug、測試。微信

2、什麼是MVC/MVP？

　　先來講說MVC吧，其實MVX模式都是分層思想的一種具體實現，上文提到的分層思想其實是一種抽象層面的分層，着重表如今抽象和解耦。網絡

　　MVC其實是一種分層思想的踐行者和改進者，在GUI編程中，MVC已經有幾十年的歷史了。

　顧名思義M(Model)即數據模型層，Model層頗有意思，對於服務端編程來講咱們把MVC中的M極有多是包括了業務處理(Service)和實體類的，對於客戶端編程來講MVC中的M可能就僅僅是數據模型，固然以上的說法只是於我我的而言的體會，不表明廣義立場。

　　V(View)即視圖層/表現層，主要負責數據的展現和用戶的交互，C(Controller)即控制層，主要負責一些數據傳遞、請求轉發、業務處理的委派。

　　以上是標準意義上的MVC，對於Android來講：

Model：數據模型(實體類、持久化、IO)
View：佈局文件
Controller：對應於Activity、Fragment，包含一些業務邏輯的處理

　　這裏咱們會發現，Android的MVC事實上V層的職責一部分被C層承擔了，好比一些Activity/Fragment中不可避免的一些交互邏輯等，這樣就會致使C層既包含UI交互，又有網絡請求、業務處理等；致使C層過於臃腫，不利於項目後期的維護和擴展。

　　因此，MVP就應運而生了，MVP其實是由MVC進化而來，它比較好的解決了MVC時代遺留的問題，MVP中的各層含義：

Model：數據模型(實體類、持久化、IO)
View：Activity/Fragment和佈局文件
Presenter：負責完成View和Model之間的交互和業務邏輯

　　其核心思想是：設計一個抽象的V層接口，並由具體的View實現該接口，P層內部維護一個該接口的實例引用，通常在構造函數中傳遞進來賦值(即View層初始化P層實例時)，彼時P層便可經過調用該接口來完成對View層的操做,V層也因持有P層實例，能夠進行業務邏輯處理委派。

3、MVVM是什麼？與MVC/MVP有何區別？

　　MVVM是對MVP/MVC的一種改進，既解決了MVC時代的職責不明的問題，也很好的解決了MVP模式中須要編寫過多繁瑣的接口，以及V層和P層互相依賴所產生的一些隱式問題。

　　在MVVM中，各層含義以下：

Model：數據模型(實體類、持久化、IO)
View：Activity/Fragment和佈局文件
ViewModel：業務邏輯的處理、數據的轉換、鏈接M層和V層的橋樑

　　看上去彷佛和MVP中各層的職責是相似的，並無顯著的不一樣和改進；那麼咱們爲什麼要使用MVVM架構呢？

　　引入美團技術團隊的一段解釋：

雙向綁定、數據驅動
在常規的開發模式中，數據變化須要更新UI的時候，須要先獲取UI控件的引用，而後再更新UI。獲取用戶的輸入和操做也須要經過UI控件的引用。在MVVM中，這些都是經過數據驅動來自動完成的，數據變化後會自動更新UI，UI的改變也能自動反饋到數據層，數據成爲主導因素。這樣MVVM層在業務邏輯處理中只要關心數據，不須要直接和UI打交道，在業務處理過程當中簡單方便不少。

高度解耦
MVVM模式中，數據是獨立於UI的。
數據和業務邏輯處於一個獨立的ViewModel中，ViewModel只須要關注數據和業務邏輯，不須要和UI或者控件打交道。UI想怎麼處理數據都由UI本身決定，ViewModel不涉及任何和UI相關的事，也不持有UI控件的引用。即使是控件改變了（好比：TextView換成EditText），ViewModel也幾乎不須要更改任何代碼。它很是完美的解耦了View層和ViewModel，解決了上面咱們所說的MVP的痛點。

可複用、易測試、方便協同開發
一個ViewModel能夠複用到多個View中。一樣的一份數據，能夠提供給不一樣的UI去作展現。對於版本迭代中頻繁的UI改動，更新或新增一套View便可。若是想在UI上作A/B Testing，那MVVM是你不二選擇。
MVVM的分工是很是明顯的，因爲View和ViewModel之間是鬆散耦合的：一個是處理業務和數據、一個是專門的UI處理。因此，徹底由兩我的分工來作，一個作UI（XML和Activity）一個寫ViewModel，效率更高
ViewModel層作的事是數據處理和業務邏輯，View層中關注的是UI，二者徹底沒有依賴。無論是UI的單元測試仍是業務邏輯的單元測試，都是低耦合的。在MVVM中數據是直接綁定到UI控件上（部分數據是能夠直接反映出UI上的內容），那麼咱們就能夠直接經過修改綁定的數據源來間接作一些Android UI上的測試。

4、Android Architecture Components(架構組件)

　　實現MVVM的方式和工具備不少，既可使用Google在2015年推出的DataBinding庫，亦或是其餘。也能夠選擇Google IO 2017 推出的Android Architecture Components即架構組件，亦或是其餘方式。

　　本文采用的解決方案：使用Architecture Components架構MVVM。

　　上圖是官方給出的架構模型，包含如下組件：

生命週期管理庫 - Lifecycle

Lifecycle組件，爲下面兩個組件提供了生命週期感知的基礎

LiveData組件，可觀測的、可感知生命週期的數據

ViewModel組件，不依賴於View、提供UI數據、橋接持久層、業務邏輯

數據持久化庫 - Room，Sqlite的ORM

　　事實上，Architecture Components實現了一個比較理想化的依賴方式，自上而下，單向依賴；VM層並不持有View層的任何引用，但倒是生命週期感知的，在新版的AS中View也不用去實現某些接口或繼承特定的類，AppCompatActivity已經幫你整合了這一切。

　　另外，關於Repository的解釋，它並非架構組件的成員，可是Google推薦引入Repository層，來做爲咱們惟一的數據來源接口，咱們從圖中也很好理解，他的職責就是使VM層對數據來源是無感知的，包裝了數據來源，提供統一的API，供上層透明化的調用。

　　更多的關於Android Architecture Components的教程，歡迎關注咱們後續的架構組件篇章。

5、一個MVVM的Demo

　　下面咱們經過設計App《每日美文》的Demo，並使用Architecture Components架構MVVM的方式去完成。

　　這個Demo使用Kotlin開發，沒接觸過Kotlin的童鞋也沒必要擔憂，本文沒有用到Kotlin的一些高級特性，只須要Google花個半小時時間學習基本的Kotlin語法即可無障礙閱讀

　　項目地址：https://github.com/xykjlcx/OneArticleDemo

1. 首先咱們建立工程

項目建立完成後的目錄結構

架構組件的相關依賴

// livedata viewmodel
    def lifecycle_version = "1.1.1"
    implementation "android.arch.lifecycle:extensions:$lifecycle_version"
    implementation "android.arch.lifecycle:viewmodel:$lifecycle_version"
    implementation "android.arch.lifecycle:livedata:$lifecycle_version"
    implementation "android.arch.lifecycle:runtime:$lifecycle_version"
    annotationProcessor "android.arch.lifecycle:compiler:$lifecycle_version"

　　PS：視圖(佈局xml)就不帶你們看了，很簡單，有興趣的童鞋能夠直接到Github上看源碼

2. 工具類：OceanUtil

　　網絡請求封裝的有些隨意，輕噴😂

/**
 * Created by ocean on 2018/8/11
 * Author :  ocean
 * Email  :  348686686@qq.com
 */

object OceanUtil{

    object Holder{
        val OK_HTTP_CLIENT = OkHttpClient()
        val GSON = Gson()
    }

    private const val TAG:String = "ocean"

    /**
     * 網絡請求工具方法demo
     * @param url api接口地址
     * @param handler
     */
    fun httpRequest(url: String,params: HashMap<String,Any>,handler: Handler){
        var jsonObject = JSONObject(params)
        var requestBody = RequestBody.create(AppConstant.MEDIA_TYPE_JSON,jsonObject.toString())
        val okHttpClient = Holder.OK_HTTP_CLIENT
        val request = Request.Builder()
                .url(url)
                .post(requestBody)
                .build()
        okHttpClient.newCall(request).enqueue(object: Callback{
            override fun onFailure(call: Call?, e: IOException?) {
                logE("請求失敗")
            }

            override fun onResponse(call: Call?, response: Response?) {
                logE("請求成功")
                val result:String = response!!.body().string().toString()
                val message = Message()
                message.what = 200
                message.obj = result
                handler.sendMessage(message)
            }

        })
    }

    /**
     * 日誌打印
     * @param any
     */
    fun logE(any: Any) {
        if (AppConstant.isDegug)
            Log.e(TAG,"-> -> -> 日誌打印【 $any 】")
    }

    /**
     * 數據轉換
     */
    fun convertData(result:String): ArticleModel {
        return Holder.GSON.fromJson(
                result,
                object : TypeToken<ArticleModel>(){}.type
        )
    }

}

OK，下面咱們將自下而上的構建MVVM

3. 第一步：建立實體Model(Java混編)

　　Ps:使用了GsonFormat暫時還不支持Kotlin的數據類(data class)，因此這裏採用混編的方式。

　　這裏咱們使用GsonFormat插件直接生成Java實體類，也就是咱們的每日美文的Model。

　　都是一些屬性和get/set方法，咱們用到的字段也就三四個,你們瀏覽一遍便可。

/**
 * Created by ocean on 2018/8/11
 * Author :  ocean
 * Email  :  348686686@qq.com
 */
public class ArticleModel{

    /**
     * ResultCode : 1
     * ErrCode : OK
     * Body : {"id":4861,"vol":"VOL.2135","img_url":"http://image.wufazhuce.com/FhUGpJBjkcod8DHH7OSieT-8ODKz","img_author":"Ethan Yang","img_kind":"攝影","date":"2018-08-11 06:00:00","url":"http://m.wufazhuce.com/one/2165","word":"本身被傷害的時候，有的人生氣，有的人傷心。生氣的人是憎恨的，將本身束之高閣而去攻擊對方，歇斯底里地喊叫起來。懂得悲傷的人，必定懂得愛，只是靜靜地如時間停滯般，獨自哀傷。人們總說愛恨參半，其實這是不可能存在的，既愛之，何恨之。","word_from":"《高嶺之花》","word_id":2165}
     */

    private int ResultCode;
    private String ErrCode;
    private BodyBean Body;

    public int getResultCode() {
        return ResultCode;
    }

    public void setResultCode(int ResultCode) {
        this.ResultCode = ResultCode;
    }

    public String getErrCode() {
        return ErrCode;
    }

    public void setErrCode(String ErrCode) {
        this.ErrCode = ErrCode;
    }

    public BodyBean getBody() {
        return Body;
    }

    public void setBody(BodyBean Body) {
        this.Body = Body;
    }

    @Override
    public String toString() {
        return "ArticleModel{" +
                "ResultCode=" + ResultCode +
                ", ErrCode='" + ErrCode + '\'' +
                ", Body=" + Body +
                '}';
    }

    public static class BodyBean {
        /**
         * id : 4861
         * vol : VOL.2135
         * img_url : http://image.wufazhuce.com/FhUGpJBjkcod8DHH7OSieT-8ODKz
         * img_author : Ethan Yang
         * img_kind : 攝影
         * date : 2018-08-11 06:00:00
         * url : http://m.wufazhuce.com/one/2165
         * word : 本身被傷害的時候，有的人生氣，有的人傷心。生氣的人是憎恨的，將本身束之高閣而去攻擊對方，歇斯底里地喊叫起來。懂得悲傷的人，必定懂得愛，只是靜靜地如時間停滯般，獨自哀傷。人們總說愛恨參半，其實這是不可能存在的，既愛之，何恨之。
         * word_from : 《高嶺之花》
         * word_id : 2165
         */

        private int id;
        private String vol;
        private String img_url;
        private String img_author;
        private String img_kind;
        private String date;
        private String url;
        private String word;
        private String word_from;
        private int word_id;

        public int getId() {
            return id;
        }

        public void setId(int id) {
            this.id = id;
        }

        public String getVol() {
            return vol;
        }

        public void setVol(String vol) {
            this.vol = vol;
        }

        public String getImg_url() {
            return img_url;
        }

        public void setImg_url(String img_url) {
            this.img_url = img_url;
        }

        public String getImg_author() {
            return img_author;
        }

        public void setImg_author(String img_author) {
            this.img_author = img_author;
        }

        public String getImg_kind() {
            return img_kind;
        }

        public void setImg_kind(String img_kind) {
            this.img_kind = img_kind;
        }

        public String getDate() {
            return date;
        }

        public void setDate(String date) {
            this.date = date;
        }

        public String getUrl() {
            return url;
        }

        public void setUrl(String url) {
            this.url = url;
        }

        public String getWord() {
            return word;
        }

        public void setWord(String word) {
            this.word = word;
        }

        public String getWord_from() {
            return word_from;
        }

        public void setWord_from(String word_from) {
            this.word_from = word_from;
        }

        public int getWord_id() {
            return word_id;
        }

        public void setWord_id(int word_id) {
            this.word_id = word_id;
        }

        @Override
        public String toString() {
            return "BodyBean{" +
                    "id=" + id +
                    ", vol='" + vol + '\'' +
                    ", img_url='" + img_url + '\'' +
                    ", img_author='" + img_author + '\'' +
                    ", img_kind='" + img_kind + '\'' +
                    ", date='" + date + '\'' +
                    ", url='" + url + '\'' +
                    ", word='" + word + '\'' +
                    ", word_from='" + word_from + '\'' +
                    ", word_id=" + word_id +
                    '}';
        }
    }
}

4. 第二步：引入Repository層

　　前面咱們說過，Repository層是爲了屏蔽底層數據來源，透明的被上層所調用

class ArticRepository(application: Application){

    private var liveData = MutableLiveData<ArticleModel>()

    init {
       getHttpData()
    }

    fun getLiveDta():MutableLiveData<ArticleModel>{
        return liveData
    }

    fun getHttpData(){
        val params : HashMap<String,Any> = HashMap()
        params["TransCode"] = "030111"
        params["OpenId"] = "123456789"
        OceanUtil.httpRequest(
                AppConstant.URL,
                params,
                object : Handler(){
                    override fun handleMessage(msg: Message?) {
                        super.handleMessage(msg)
                        val result = msg?.obj as String
                        OceanUtil.logE("打印請求結果：$result")
                        liveData.value = OceanUtil.convertData(result)
                    }
                }
        )
    }

}

　　能夠看到，內部獲取數據實際上使用的就是Okhttp的工具方法，不過對於調用者來講，上層並不關心數據是從Sqlite讀出來的，仍是網絡請求響應的，亦或是其餘數據來源。這樣在Repository層咱們能夠很輕鬆的完成緩存、數據轉化等操做，而不影響上層。
　　後面的文章，咱們會使用Room對網絡數據進行持久化緩存，在無網絡環境下，保證用戶使用軟件的完整性，給用戶更好的體驗。

5. 第三步：建立你的ViewModel

　　咱們能夠選擇繼承ViewModel/AndroidViewModel類來編寫咱們項目的ViewModel實現

/**
 * Created by ocean on 2018/8/12
 * Author :  ocean
 * Email  :  348686686@qq.com
 */
class ArticleViewModel(application: Application) : AndroidViewModel(application) {

    private var repository : ArticRepository? = null
    private var data:MutableLiveData<ArticleModel>? = null

    init {
        repository = ArticRepository(application)
        data = repository?.getLiveDta()
    }

    fun getData(): MutableLiveData<ArticleModel>? {
        return data
    }

    fun requestData(){
        repository?.getHttpData()
    }

}

　　VM層看起來很簡潔，是的。得益於MutableLiveData(LiveData的子類)，咱們沒必要要作不少複雜的工做；就像這樣，咱們僅僅只是聲明瞭一個MutableLiveData的引用、獲取實例、調用Repository層獲得數據這樣微小的工做。

6. 第四步：在View層使用

　　在View層調用VM很是簡單，Architecture Components的開發者已經幫咱們處理了這一切。

　　另外，在Fragment中使用ViewModel咱們一般在ViewModelProviders.of()方法中傳入getActivity()；事實上因爲傳入的Context相同(同一個activity)，咱們獲得的VM也是相同的，因此ViewModel還能夠處理Fragment之間的通訊。

class MainActivity : AppCompatActivity() {

    private var vm : ArticleViewModel? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        // 獲取vm對象
        vm = ViewModelProviders.of(this).get(ArticleViewModel::class.java)
        initData()
    }

    fun initData(){
        btn_get.setOnClickListener(View.OnClickListener {
            vm?.requestData()
        })
        vm?.getData()?.observe(this, Observer {
            it?.let { it1 -> updateView(it1) }
        })
    }

    fun updateView(model: ArticleModel){
        tv_title.text = model.body.word_from
        tv_author.text = "—— " +  model.body.img_author
        tv_digest.text = model.body.word
        Glide
                .with(this)
                .load(model.body.img_url)
                .dontAnimate()
                .centerCrop()
                .into(img_left)
        Toast.makeText(this,"更新成功",Toast.LENGTH_SHORT).show()
    }

}

　　就像這樣，咱們只須要經過ViewModelProviders.of().get方法獲得VM的引用，接下來咱們只須要獲取LiveData對象的引用，對其添加.observe()方法，以後組件便會自動觀察LiveData數據的變化，當數據發生變化時，系統會調用Observer接口的onChanged()方法，因此咱們只須要將更新UI的邏輯寫在onChanged()方法體內便可。

7. 告一段落

　　至此，咱們基本已經完成了這個Demo，應該說仍是蠻Easy的，後期咱們會迭代初一個更好的Demo。

　　但願你們持續關注個人微信公衆號😀

Ps：附上接口地址

// url接口地址：https://api.hibai.cn/api/index/index
// 入參："TransCode"="030111","OpenId":"123456789"
// 這是接口返回json數據
{
    "ResultCode": 1,
    "ErrCode": "OK",
    "Body": {
        "id": 4860,
        "vol": "VOL.2136",
        "img_url": "http://image.wufazhuce.com/FpXhraPX6RVOiEVBkxL2mJzd1Lb5",
        "img_author": "狐狸狐狸魚",
        "img_kind": "插畫",
        "date": "2018-08-12 06:00:00",
        "url": "http://m.wufazhuce.com/one/2166",
        "word": "仍是想在夏天與你相戀，不只是夜晚溫熱的風，清爽的白色短袖，仍是冰鎮西瓜或者幻想中的漫長暑假，多是曾經以爲夏天就屬於慵懶，因此纔會以爲要搭配一個你，在懶洋洋裏帶着些許的緊張。是你啊，又見面了。",
        "word_from": "鹹貴人",
        "word_id": 2166
    }
}

6、結語

　　不知不覺已經寫了這麼多了，這是做者第一次寫這麼長的技術文章。
　　在發稿前，Review文章；總絕對沒有符合「單一職責」原則
　　本身也在想，技術類文章在講重心以前，作一些前置知識點的解釋，是否必要。好比本文:分層思想->MVC/MVP->MVVM，相比較開門見山的講解MVVM是更好理解仍是以爲更加臃腫呢？
　　因此，筆者也但願你們若是讀了這篇文章，能夠在留言區評論本身的感覺，我將進一步改善文章框架，儘可能讓你們能夠高效的學習。
　　最後，筆者技術能力和文筆能力有限，有什麼寫的不妥的地方，也請你們予以斧正和諒解。