AAC框架改造总结

近期主要工作之一是一个模块的AAC框架改造，在此记录一下改造过程中遇到的问题以及一些改造经验。

 

AAC框架的概念和意义，先不细讲，日后有时间补上。

关于AAC框架的概念和意义，在看了官方文档后写了一篇整理：AAC框架中的一些基础概念整理

简单来说，AAC是一个将代码结构更加解耦的框架。新引入的livedata，可以与控件绑定，通过监听自身数据的改变通知控件刷新。节省了手动set的过程。

那么一个简单的AAC框架代码应用，都包括哪些内容呢。以下是个人见解。

首先，AAC整体结构上还是基于MVVM框架，要有Model，View和ViewModel。其中Model就是LiveData，View是UI控件，ViewModel是负责逻辑以及数据处理，通过它联系View和Model使得View和Model做到完全解耦（实际上model与view进行了绑定）。

我们把数据转化封装成我们想要且使用方便的LiveData，之后建立ViewModel。View部分也很简单，就是找到UI布局控件。重头戏可以说全在ViewModel上了。ViewModel会持有LiveData，同时提供方法将View与LiveData绑定，绑定时提供LiveData改变时View的刷新策略。至于ViewModel该不该持有View，个人觉得可以不持有，因为这样更符合解耦的大前提，而且View与其它二者的关系就在绑定那一瞬间。剩下的就是ViewModel自己的表演了，里面会处理一些数据逻辑，如何展示之类的。

之前写的可能有些乱，总结一下

一 Model

在AAC框架中为LiveData，把数据封装成我们想要的结构，之后建立对应的LiveData。

二 View

仍然是传统的UI控件，通过findViewById形式找到。

三 ViewModel

1 持有LiveData，可以通过set等方式设置LiveData

2 绑定View，通过bindView等方法将View作为参数，与LiveData绑定，同时提供数据变化是的刷新方法。

3 处理逻辑，有一些逻辑需要viewModel处理完再讲结果更新到LiveData同时刷新View。

 

最后一点延伸，最简单的结构莫过于一个控件对应一套MVVM组合，然后实际开发中，控件和功能的嵌套是比较复杂的，这就要求我们把最小的控件单位区分好，之后再将它们整合到一起。整合过程中，View和Model是解耦的，然而ViewModel则需要有一定关联。往往是一个大的ViewModel中包含很多小的ViewModel，逻辑全都在里面。不过只要我们做到将MVVM最小化，代码结构还是很清晰的，其中的任意一个viewModel拿出去，都是可以独立使用的。

 

经过一天思考和测试，发现recyclerView和listView可能不太适合liveData结构，因为LiveData本身是基于观察者模式，而adapter其实也是基于观察者模式的，两者同时使用会有些重复。对于列表来讲，使用recyclerView或者Listview的adapter就已经足够了。AAC模式应该针对于那种在acitivty或者fragment大布局中的固定控件布局，通过数据的变化实现其刷新，而adapter本身具有刷新功能，在重构代码时要额外注意。