碼上快樂

相關內容    簡體    繁體

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

本文轉載自   查看原文   2018-08-18 15:39   1050    架構/ mvvm/ android

前言

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

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

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

目錄樹

  • 《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》系列(六) 之 總結與展望

正文

一、分層思想

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

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

 　初學者往往搞不明白為什么明明可以直接編碼業務邏輯，還要去做所謂的分層架構呢？

    其實對僅僅實現需求來說，用不用分層架構沒有關系的，不分層照樣可以實現；那么為什么我們還要徒增煩惱呢？有句話說的好：“存在即合理”，也就是說既然我們的前輩研究出了所謂的分層架構，並且沿用至今；那么就一定有它的優點，一定是解決了某一領域的痛點而誕生的

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

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

二、什么是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層實例，可以進行業務邏輯處理委派。

三、MVVM是什么？與MVC/MVP有何區別？

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

　　在MVVM中，各層含義如下：

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

　　看上去似乎和MVP中各層的職責是類似的，並沒有顯著的不同和改進；那么我們為何要使用MVVM架構呢？

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

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

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

    3. 可復用、易測試、方便協同開發
      一個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上的測試。

四、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的教程，歡迎關注我們后續的架構組件篇章。

五、一個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
    }
}

六、結語

　　不知不覺已經寫了這么多了，這是作者第一次寫這么長的技術文章。
　　在發稿前，Review文章；總絕對沒有符合“單一職責”原則
　　自己也在想，技術類文章在講重心之前，做一些前置知識點的解釋，是否必要。比如本文:分層思想->MVC/MVP->MVVM，相比較開門見山的講解MVVM是更好理解還是覺得更加臃腫呢？
　　所以，筆者也希望大家如果讀了這篇文章，可以在留言區評論自己的感受，我將進一步改善文章框架，盡量讓大家可以高效的學習。
　　最后，筆者技術能力和文筆能力有限，有什么寫的不妥的地方，也請大家予以斧正和諒解。

 


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 WPF快速入門系列(8)——MVVM快速入門 淺談Android架構之MVP,MVVM 架構-MVVM：MVVM核心概念 MVVM架構~Knockoutjs系列之對象與對象組合 MVVM架構~knockoutjs系列之級聯select MVVM架構~Knockoutjs系列之驗證機制的引入 MVVM架構~knockoutjs系列之數組的$index和$data 什么是MVVM？ 什么是mvvm？ MVVM
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM