深入解析Android架构中的MVVM模式及其应用步骤
Android MVVM 分析以及使用
首先我们需要知道什么是MVVM,他的功能和优点,以及他的缺点。
MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化,让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了,它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑。微软的WPF带来了新的技术体验,如Silverlight、音频、视频、3D、动画……,这导致了软件UI层更加细节化、可定制化。同时,在技术层面,WPF也带来了 诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM(Model-View-ViewModel)框架的由来便是MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性糅合进去,以应对客户日益复杂的需求变化。
WPF的数据绑定与Presentation Model相结合是非常好的做法,使得开发人员可以将View和逻辑分离出来,但这种数据绑定技术非常简单实用,也是WPF所特有的,所以我们又称之为Model-View-ViewModel(MVVM)。这种模式跟经典的MVP(Model-View-Presenter)模式很相似,除了你需要一个为View量身定制的model,这个model就是ViewModel。ViewModel包含所有由UI特定的接口和属性,并由一个 ViewModel 的视图的绑定属性,并可获得二者之间的松散耦合,所以需要在ViewModel 直接更新视图中编写相应代码。数据绑定系统还支持提供了标准化的方式传输到视图的验证错误的输入的验证。
在视图(View)部分,通常也就是一个Aspx页面。在以前设计模式中由于没有清晰的职责划分,UI 层经常成为逻辑层的全能代理,而后者实际上属于应用程序的其他层。MVP 里的M 其实和MVC里的M是一个,都是封装了核心数据、逻辑和功能的计算关系的模型,而V是视图(窗体),P就是封装了窗体中的所有操作、响应用户的输入输出、事件等,与MVC里的C差不多,区别是MVC是系统级架构的,而MVP是用在某个特定页面上的,也就是说MVP的灵活性要远远大于MVC,实现起来也极为简单。
我们再从IView这个interface层来解析,它可以帮助我们把各类UI与逻辑层解耦,同时可以从UI层进入自动化测试(Unit/Automatic Test)并提供了入口,在以前可以由WinForm/Web Form/MFC等编写的UI是通过事件Windows消息与IView层沟通的。WPF与IView层的沟通,最佳的手段是使用Binding,当然,也可以使用事件;Presenter层要实现IView,多态机制可以保证运行时UI层显示恰当的数据。比如Binding,在程序中,你可能看到Binding的Source是某个interface类型的变量,实际上,这个interface变量引用着的对象才是真正的数据源。
MVC模式大家都已经非常熟悉了,在这里我就不赘述,这些模式也是依次进化而形成MVC—>MVP—>MVVM。有一句话说的好:当物体受到接力的时候,凡是有界面的地方就是最容易被撕下来的地方。因此,IView作为公共视图接口约束(契约)的一层意思;View则能传达解耦的一层意思。
设计模式
因为WPF技术出现,从而使MVC架构模式有所改进,MVVM 模式便是使用的是数据绑定基础架构。它们可以轻松构建UI的必要元素。
可以参考The Composite Application Guidance for WPF(prism)
View绑定到ViewModel,然后执行一些命令在向它请求一个动作。而反过来,ViewModel跟Model通讯,告诉它更新来响应UI。这样便使得为应用构建UI非常的容易。往一个应用程序上贴一个界面越容易,外观设计师就越容易使用Blend来创建一个漂亮的界面。同时,当UI和功能越来越松耦合的时候,功能的可测试性就越来越强。
在MVP模式中,为了让UI层能够从逻辑层上分离下来,设计师们在UI层与逻辑层之间加了一层interface。无论是UI开发人员还是数据开发人员,都要尊重这个契约、按照它进行设计和开发。这样,理想状态下无论是Web UI还是Window UI就都可以使用同一套数据逻辑了。借鉴MVP的IView层,养成习惯。View Model听起来比Presenter要贴切得多;会把一些跟事件、命令相关的东西放在MVC的'C',或者是MVVM的'Vm'。
MVVM优点
MVVM模式和MVC模式一样,主要目的是分离视图(View)和模型(Model),有几大优点
- 低耦合。视图(View)可以独立于Model变化和修改,一个ViewModel可以绑定到不同的"View"上,当View变化的时候Model可以不变,当Model变化的时候View也可以不变。
- 可重用性。你可以把一些视图逻辑放在一个ViewModel里面,让很多view重用这段视图逻辑。
- 独立开发。开发人员可以专注于业务逻辑和数据的开发(ViewModel),设计人员可以专注于页面设计,使用Expression Blend可以很容易设计界面并生成xaml代码。
- 可测试。界面素来是比较难于测试的,测试可以针对ViewModel来写。
MVVM控件
使用MVVM来开发用户控件。由于用户控件在大部分情况下不涉及到数据的持久化,所以如果将M纯粹理解为DomainModel的话,使用MVVM模式来进行自定义控件开发实际上可以省略掉M,变成了VVM
MVVM的核心是databidning 这是一个用于数据双向绑定的,他的强大之处,出了双向绑定之外,还可以代替butterknife。众所周知butterknife需要对每一个控件进行单独的绑定,这样子不但非常的费时间,而且会导致代码看起来极其的复杂。下面上图展示一下实际的差距。
这是butterknife这个样子只是进行了,绑定但是在用的时候还是不够方便因为你去要根据你的id去写出,对应的id方可进行操作。
这个databinding的是绑定声明,使用起来是这样子的
databinding后面直接点就可以,选择绑定页面的中的控件。
而且他的强大之处就是,databinding绑定之后就相当于一个viewgroup。这个在适配器中或者自定义页面的情况下极大地减少了,代码量。而且更不易出错。非常的稳定。
那么可能会有人问,既然使用了kotlin,那么我为什么还有使用databinding呢,没错总是有些杠精要和你杠一下,kotlin中的自带的id调用,是不错的。除非的你每个id开通都不重复否则。
那你就等根据后面的所属的activity慢慢选吧,而且kotlin绑定的控件,无法传递内存地址,你想把这个控件传到适配器里,那是不可能的。
接下来我们就说一下databinding的数据绑定,databinding自带的数据双向绑定,首先在使用之间,需要在gradle引入
这就就是打开databinding,那么如果使用数据绑定
首先使用databinding时 布局必须以开头,结尾。然后就可以在代码中绑定以开头结尾的文件了。
然后在布局中声明的id,
就可以直接调用
现在只是绑定了布局,还并没有绑定数据,数据绑定可以使bean也可以直接是数据。下面是数据的绑定,可以直接在
也可以在代码中声明一个数据源,例如:
这个要在标签中声明。type就是他的类型。然后在代码中绑定这个数据
然后就可以直接在布局中设置数据了
这个样子已经是实现了,datanbinding的双向绑定,但是还不是 所有,当数据刷新时,我们通常需要手动刷新或者在代码里重新赋值,但是databinding是不需要的,你只需要在bean中实现一个生命就可以,例如
在类的后面继承BaseObservable(是每一个类,一个bean中可能有多个类),
然后在get方法上面声明@Bindable,之后就可以了。当数据发生改变,绑定的数据就会自动改变,是不是很强大。现在只是介绍了databinding,接下来我们来看看MVVM。
MVVM分为model,view,modelView(简称vm),所以我们在使用是就可以像mvp一样分开文件,具有解耦效果,为了保证代码的安全性,我们分别使用modelIpl,VmIPL,就是让他们继承自接口,保证文件的安全性,下面开始实战操作。
首先是model
interface MassageModel { fun initData(context: Context?,activity: Activity?,page:Int,size :Int,stringCallback: StringCallback) fun upData(context: Context?,activity: Activity?,page:Int,size :Int,stringCallback: StringCallback) fun LoadMoreData(context: Context?,activity: Activity?,page:Int,size :Int,stringCallback: StringCallback) fun readAll(context: Context?,activity: Activity?,stringCallback: StringCallback) fun delectSelect(context: Context?,activity: Activity?,ids: String,stringCallback: StringCallback) fun updateUerNews(context: Context?,activity: Activity?,id:Int,stringCallback: StringCallback) }
然后实现model的接口modelIpl
class MassageModelIpl:MassageModel { override fun initData(context: Context?, activity: Activity?, page: Int, size: Int, stringCallback: StringCallback) { NetControl(context, activity).queryUerList(page,size,stringCallback) } override fun upData(context: Context?, activity: Activity?, page: Int, size: Int, stringCallback: StringCallback) { NetControl(context, activity).queryUerList(page,size,stringCallback) } override fun LoadMoreData(context: Context?, activity: Activity?, page: Int, size: Int, stringCallback: StringCallback) { NetControl(context, activity).queryUerList(page,size,stringCallback) } override fun readAll(context: Context?, activity: Activity?, stringCallback: StringCallback) { NetControl(context, activity).uerNewsReaded(stringCallback) } override fun delectSelect(context: Context?, activity: Activity?, ids: String, stringCallback: StringCallback) { NetControl(context, activity).deleteUerList(ids,stringCallback) } override fun updateUerNews(context: Context?, activity: Activity?, id: Int, stringCallback: StringCallback) { NetControl(context, activity).updateUerNews(id,stringCallback) } }
然后是ViewModelListener(Vm)
Vm
class MassageVm(activity: Activity, context: Context, massageBinding: ActivityMassageBinding, layoutInflater: LayoutInflater) : MassageListener { var activity: Activity var context: Context var massageBinding: ActivityMassageBinding var massageModelIpl: MassageModelIpl var massageBean: MassageBean? = null; var massageAdapter: MassageAdapter? = null var layoutInflater: LayoutInflater init { this.context = context this.layoutInflater = layoutInflater this.activity = activity this.massageBinding = massageBinding massageModelIpl = MassageModelIpl() } /** * 加载第一次的数据 */ override fun initData() { } /** * 加载适配器 */ private fun initListViewData() { } /** * 下拉刷新 */ override fun update() { } /** * 上拉加载 */ override fun loadMore() { } /** * 全部已读 */ override fun readAll() { } /** * 删除选中 */ override fun delectSelect() { } override fun ReadSimple(id: Int) { } /** * dialog提示 */ private fun ShowToast(s: String, type: Int) { } }
最后就是讲view和Vm绑定
就是activity或者Fragment
class MassageActivity : BaseMVVMActivity() { lateinit var activityMassageBinding: ActivityMassageBinding lateinit var massageVm: MassageVm override fun InitNew() { } override fun setVM() { massageVm = MassageVm(this, this, activityMassageBinding, layoutInflater) } override fun InitData() { massageVm.initData() } override fun SetLayout(): Int { return R.layout.activity_massage } override fun FindView() { } override fun SetListener() { activityMassageBinding.listView.setOnLoadMoreListener { massageVm.loadMore() } activityMassageBinding.listView.setOnRefreshListener { massageVm.update() } activityMassageBinding.btnSelectIsRead.setOnClickListener { massageVm.readAll() } activityMassageBinding.btnSelectDelete.setOnClickListener { massageVm.delectSelect() } } override fun SetBindingLayout() { activityMassageBinding = DataBindingUtil.setContentView(this, R.layout.activity_massage) } override fun onBackPressed() { val intent = Intent(this, MainActivity::class.java) startActivity(intent) overridePendingTransition(R.anim.fade_in, android.R.anim.slide_out_right) finish() } /** * 返回 * * @param view */ fun btnPrevious(view: View?) { onBackPressed() } }
需要说明一个fragment/adapter/viewgroup中需要一个layoutInflater这个就决定了activity的绑定方式和fragment的绑定方式不是相同的,下面说一个fragment中的绑定方式。(adapter和viewgroup的也是相同的方法)
var itemMyorderList1Binding: ItemMyorderList1Binding = DataBindingUtil.inflate(layoutInflater, R.layout.item_myorder_list1, null, false)
ItemMyorderList1Binding 这个就是你布局的名字后面加上一个binding。
最后送上套简单的activity和fragment的封装
public abstract class BaseMVVMActivity extends AppCompatActivity { @Override protected void onCreate(@Nullable Bundle savedInstanceState) { super.onCreate(savedInstanceState); DataBindingUtil.setContentView(this, SetLayout()); SetBindingLayout(); FindView(); setVM(); InitNew(); InitData(); SetListener(); } public void SetBindingLayout() { } protected abstract void setVM(); protected abstract int SetLayout(); protected abstract void FindView(); protected abstract void InitNew(); protected abstract void InitData(); protected abstract void SetListener(); }
public abstract class BaseMVVMFragment extends Fragment { LayoutInflater flater; @Nullable @Override public View onCreateView(@NonNull LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) { flater = inflater; View view = SetView(); findView(); initVM(); initData(); SetListener(); return view; } public void initData() { } protected abstract View SetView(); protected abstract void initVM(); protected abstract void findView(); protected abstract void SetListener(); public LayoutInflater GetInflater() { return flater; } }
以上就是详解Android框架MVVM分析以及使用的详细内容,更多关于Android框架MVVM使用的资料请关注其它相关文章!
上一篇: 浅析三层架构
推荐阅读
-
深入解析Android架构中的MVVM模式及其应用步骤
-
【Netty】「萌新入门」(七)ByteBuf 的性能优化-堆内存的分配和释放都是由 Java 虚拟机自动管理的,这意味着它们可以快速地被分配和释放,但是也会产生一些开销。 直接内存需要手动分配和释放,因为它由操作系统管理,这使得分配和释放的速度更快,但是也需要更多的系统资源。 另外,直接内存可以映射到本地文件中,这对于需要频繁读写文件的应用程序非常有用。 此外,直接内存还可以避免在使用 NIO 进行网络传输时发生数据拷贝的情况。在使用传统的 I/O 时,数据必须先从文件或网络中读取到堆内存中,然后再从堆内存中复制到直接缓冲区中,最后再通过 SocketChannel 发送到网络中。而使用直接缓冲区时,数据可以直接从文件或网络中读取到直接缓冲区中,并且可以直接从直接缓冲区中发送到网络中,避免了不必要的数据拷贝和内存分配。 通过 ByteBufAllocator.DEFAULT.directBuffer 方法来创建基于直接内存的 ByteBuf: ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); 通过 ByteBufAllocator.DEFAULT.heapBuffer 方法来创建基于堆内存的 ByteBuf: ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); 注意: 直接内存是一种特殊的内存分配方式,可以通过在堆外申请内存来避免 JVM 堆内存的限制,从而提高读写性能和降低 GC 压力。但是,直接内存的创建和销毁代价昂贵,因此需要慎重使用。 此外,由于直接内存不受 JVM 垃圾回收的管理,我们需要主动释放这部分内存,否则会造成内存泄漏。通常情况下,可以使用 ByteBuffer.clear 方法来释放直接内存中的数据,或者使用 ByteBuffer.cleaner 方法来手动释放直接内存空间。 测试代码: public static void testCreateByteBuf { ByteBuf buf = ByteBufAllocator.DEFAULT.buffer(16); System.out.println(buf.getClass); ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); System.out.println(heapBuf.getClass); ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); System.out.println(directBuf.getClass); } 运行结果: class io.netty.buffer.PooledUnsafeDirectByteBuf class io.netty.buffer.PooledUnsafeHeapByteBuf class io.netty.buffer.PooledUnsafeDirectByteBuf 池化技术 在 Netty 中,池化技术指的是通过对象池来重用已经创建的对象,从而避免了频繁地创建和销毁对象,这种技术可以提高系统的性能和可伸缩性。 通过设置 VM options,来决定池化功能是否开启: -Dio.netty.allocator.type={unpooled|pooled} 在 Netty 4.1 版本以后,非 Android 平台默认启用池化实现,Android 平台启用非池化实现; 这里我们使用非池化功能进行测试,依旧使用的是上面的测试代码 testCreateByteBuf,运行结果如下所示: class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf 可以看到,ByteBuf 类由 PooledUnsafeDirectByteBuf 变成了 UnpooledUnsafeDirectByteBuf; 在没有池化的情况下,每次使用都需要创建新的 ByteBuf 实例,这个操作会涉及到内存的分配和初始化,如果是直接内存则代价更为昂贵,而且频繁的内存分配也可能导致内存碎片问题,增加 GC 压力。 使用池化技术可以避免频繁内存分配带来的开销,并且重用池中的 ByteBuf 实例,减少了内存占用和内存碎片问题。另外,池化技术还可以采用类似 jemalloc 的内存分配算法,进一步提升分配效率。 在高并发环境下,池化技术的优点更加明显,因为内存的分配和释放都是比较耗时的操作,频繁的内存分配和释放会导致系统性能下降,甚至可能出现内存溢出的风险。使用池化技术可以将内存分配和释放的操作集中到预先分配的池中,从而有效地降低系统的内存开销和风险。 内存释放 当在 Netty 中使用 ByteBuf 来处理数据时,需要特别注意内存回收问题。 Netty 提供了不同类型的 ByteBuf 实现,包括堆内存(JVM 内存)实现 UnpooledHeapByteBuf 和堆外内存(直接内存)实现 UnpooledDirectByteBuf,以及池化技术实现的 PooledByteBuf 及其子类。 UnpooledHeapByteBuf:通过 Java 的垃圾回收机制来自动回收内存; UnpooledDirectByteBuf:由于 JVM 的垃圾回收机制无法管理这些内存,因此需要手动调用 release 方法来释放内存; PooledByteBuf:使用了池化机制,需要更复杂的规则来回收内存; 由于池化技术的特殊性质,释放 PooledByteBuf 对象所使用的内存并不是立即被回收的,而是被放入一个内存池中,待下次分配内存时再次使用。因此,释放 PooledByteBuf 对象的内存可能会延迟到后续的某个时间点。为了避免内存泄漏和占用过多内存,我们需要根据实际情况来设置池化技术的相关参数,以便及时回收内存; Netty 采用了引用计数法来控制 ByteBuf 对象的内存回收,在博文 「源码解析」ByteBuf 的引用计数机制 中将会通过解读源码的形式对 ByteBuf 的引用计数法进行深入理解; 每个 ByteBuf 对象被创建时,都会初始化为1,表示该对象的初始计数为1。 在使用 ByteBuf 对象过程中,如果当前 handler 已经使用完该对象,需要通过调用 release 方法将计数减1,当计数为0时,底层内存会被回收,该对象也就被销毁了。此时即使 ByteBuf 对象还在,其各个方法均无法正常使用。 但是,如果当前 handler 还需要继续使用该对象,可以通过调用 retain 方法将计数加1,这样即使其他 handler 已经调用了 release 方法,该对象的内存仍然不会被回收。这种机制可以有效地避免了内存泄漏和意外访问已经释放的内存的情况。 一般来说,应该尽可能地保证 retain 和 release 方法成对出现,以确保计数正确。