我的Android项目架构进化论（一）

wuzhuoyu
342 阅读3分钟

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第12天，点击查看活动详情

前言

当我们开始准备新起项目前，我们总是会优先去思考我们的app应该拥有一个什么样的架构。我们希望它能兼容于过去、适配于当下、拓展于未来。

我一般会将整个应用结构定义为应用架构，会将代码结构定义为业务架构。像组件化、模块化、插件化我会归整在应用架构，像MVC、MVP、MVVM、MVI我会规整为业务架构。

今天就来说说我工作这几年项目的业务架构变化。主要谈谈现在使用的这套框架

MVC时代

MVC的业务架构在Android当中已经是非常少见的了，但是我一直认为MVC是业务架构的基础，它作为早期的Android业务架构在这条架构演变的长河当中功不可没，无论是后来的MVP还是MVVM都是在其基础上演变而来的。

职能

类型职能
M-Model模型层，主要用于数据的处理及存储，像网络请求和本地存储数据请求及处理等。
V-View视图层，主要用于UI样式的呈现及处理，像xml布局和Activity中的控件及其展示效果等。
C-Controller逻辑层，主要用于业务逻辑的处理，像逻辑判断，页面展示判断等

实例展示

假设我们需要展示某个列表数据

  • Model
class ListModel{
	fun getListDataByNet(callBack:MVCCallBack){
        thread {
            val okHttpClient = OkHttpClient()
            val request = Request.Builder().get().url("https://api/getListDataByNet").build()
            okHttpClient.newCall(request).enqueue(object : Callback {
                override fun onFailure(call: Call, e: IOException) {
                    callBack.onFailure("失败")
                }

                override fun onResponse(call: Call, response: Response) {
                 callBack.onSuccess(Gson().fromJson(response.body?.string(), ListEntity::class.java))
                }
            })
        }
	}
}
  • View和Controller，这里省略Adater和RecyclerView的实现
class MACtivity : AppCompatActivity() {

    private lateinit var adapter: MVCListAdapter
    private var list = ArrayList<DataEntity>()
    private var rv：RecyclerView

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_mvc)

        initView()
    }

	// View实现，包括Adater和RecyclerView的实现
    private fun initView() {
        val lm = LinearLayoutManager(this)
        rv.layoutManager = lm
        rv.addItemDecoration(DividerItemDecoration(this, DividerItemDecoration.VERTICAL))
        adapter = MVCListAdapter(list, this)
        rv.adapter = adapter

        getListDataByNet()
    }

	// Contrller实现
    private fun getListDataByNet() {
        ListModel().getListDataByNet(object : MVCCallBack {
            override fun onSuccess(listEntity: ListEntity) {
                list = listEntity.list
                runOnUiThread {
                    adapter.notifyDataSetChanged()
                }
            }

            override fun onFailure(errorMsg: String) {
                Toast.makeText(thi, errorMsg Toast.LENGTH_SHORT).show()
            }
        })
    }
}

理解

当用户触发View层逻辑事件时会调用Controller层的getListDataByNet事件，接下来Controller层会通知Model层进行网络数据的获取，当Model层的Api产生回调时，会通过Controller层让View层进行数据列表的展示。

优点

  • 简单业务且无后期迭代需求的情况下使用MVC可以减少代码量，降低代码的理解难度，开发成本低。
  • 一定程度上实现了View层和Model层的分离，降低了一点点耦合度问题。

缺点

  • 复杂业务完全不适合，开发成本和后期维护成本非常高，同时也增加了代码理解的难度。
  • View层和Controller层耦合度非常高，基本上都在同一个类当中实现，代码臃肿不堪，涉及到的视图和业务交织在一起，违背单一职能的原则。

总结

对于MVC这种业务架构而言，它的优点便是开发成本低，但是它的缺点同样明显，当我们的业务和逻辑复杂度提高时，承载View层和Controller层的Activity就会显得十分臃肿，有时一个Activity/Fragment可能有几千上万行代码，使得后期维护成本相当大。

为了解决上述 MVC 模式存在的问题，分离Activity/Fragment中的 View 层和 Controller层，从而对Activity/Fragment代码精简，所以就有了 MVP 模式。下一篇我们将一起看看MVP又是什么样的。

avatar
文章
阅读
粉丝