MVP，MVC，MVVM

mvc

• 视图层(View) 对应于xml布局文件和java代码动态view部分
• 控制层(Controller) Android的控制层是由Activity来承担的，Activity本来主要是作为初始化页面，展示数据的操作
• 模型层(Model) 针对业务模型，建立的数据结构和相关的类，它主要负责网络请求，数据库处理

总结：
具有一定的分层，model彻底解耦，controller和view并没有解耦 层与层之间的交互尽量使用回调或者去使用消息机制去完成，尽量避免直接持有controller和view在android中无法做到彻底分离，但在代码逻辑层面一定要分清业务逻辑被放置在model层，能够更好的复用和修改增加业务

MVP

• 视图层(View) 对应于xml布局文件和java代码动态view部分
• 控制层(Controller) Android的控制层是由Activity来承担的，Activity本来主要是作为初始化页面，展示数据的操作
• 逻辑处理层（Presenter）作为View与Model交互的中间纽带，处理与用户交互的负责逻辑

总结：
实现了视图层的独立，通过中间层Preseter实现了Model和View的完全解耦。MVP彻底解决了MVC中View和Controller混淆的问题，

mvvm

• 模型层(Model)
  负责存储、检索、操纵来自数据库或者网络的数据
• 视图层(View)
  用户界面，一般采用XML文件进行界面的描述
• 视图-模型层(ViewModel)
  负责View和Model之间的通信，以此分离视图和数据。

总结：
1、低耦合。View可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
2、可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
3、ViewModel解决MVP中View(Activity)和Presenter相互持有对方应用的问题，界面由数据进行驱动，响应界面操作无需由View(Activity)传递，数据的变化也无需Presenter调用View(Activity)实现，使得数据传递的过程更加简洁，高效。
eg:DataBinding
参考：https://www.jianshu.com/p/8e3d4ab80714

ScrollView和listView结合会出现什么情况

会出现滑动冲突问题。scrllview 和listview 因为都可以滑动，所以他们的滑动事件就容易冲突，造成内部无法滑动的问题。

解决一：改变技术方案

解决二：拦截滑动事件，

listview图片错乱 及优化

listview 内部实现是recycleBin机制，它会自动复用布局组件对象来提高性能。但是当异步加载图片时，图片加载需要时间，等图片加载完毕，可能该组件已经滑出屏幕且当前item被复用，再次请求图片被加载，因此会出现闪烁错乱。

解决：使用findViewWithTag ，给imageview 设置tag 为url,这样滚动tag值会被覆盖，保证数据的及时性。

约束布局

ConstraintLayout 是一个 ViewGroup，它的出现是为了解决复杂布局时，布局嵌套（布局内的布局）过多的问题（嵌套布局会增加绘制界面所需的时间）。它可以根据同级视图和父布局的约束条件为每个视图定义位置，类似于 RelativeLayout 所有视图都是根据兄弟视图和父级布局之间的关系来布局的，但是与 RelativeLayout 相比，它更加灵活，更易于使用。

GreenDao如何升级，常用Sql语句

在版本迭代时，我们经常需要对数据库进行升级，而GreenDAO默认的DaoMaster.DevOpenHelper在进行数据升级时，会把旧表删除，然后创建新表，并没有迁移旧数据到新表中，从而造成数据丢失。
我们借助MigrationHelper类来完成升级同时保证旧数据的完整性。它主要是通过创建一个临时表，将旧表的数据迁移到新表中。
//创建表（ 主键id name age ）
create table user(id INTEGER PRIMARY KEY AUTOINCREMENT,name varchar(20), content TEXT)
// 删除表
drop table tabname
// 插入数据
insert into user(name,content) values(lisi,xxxxx)
//查询所有
select * from table1
//删除数据
delete from table1 where 范围
//更新数据
update user set name=lisi where name=zhangsan
//条件查询数据
select * from table1 where id='11'

Glide图片加载缓存 glide清除缓存 glide,picasso缓存区别

Glide 默认加载缓存，分为内存和硬盘缓存。
Glide.with(this).clear(mImage);

两个库都支持缓存图片，都通过下载图片后，缓存到本地。但是这里对于缓存本地的机制，两个库是完全不同的做法。
Picasso 是下载图片然后缓存完整的大小到本地，比如说图片的大小是1080p的，之后如果我需要同一张图片，就会返回这张 full size 的，如果我需要resize，也是对这种 full size 的做 resize。
Glide 则是完全不一样的做法。Glide 是会先下载图片，然后改变图片的大小，以适应 imageView 的要求，然后缓存到本地。 所以如果你是下载同一张图片，但是设定两个不一样大小的 imageView, 那么Glide 实际上是会缓存两份。
换个角度来看，这里不仅仅是缓存的问题，比如一个 ImageView 要改变它的大小，PIcasso 就只需要下载一次 full size 的图片，但是 Glide 实际上就不仅仅是下载一次了，它需要去单独下载然后改变大小适配 imageView，因为对于 Glide 来讲，需要缓存不同大小的同一张图片。

RecyclerView的上拉加载怎么实现、下拉刷新--RecyclerView原生实现侧滑、拖动

recyclerview 可以使用第三方的框架实现刷新和加载更多，也可以自己实现。
自定义：

答案就是自定义一个WrapAdapter适配器，通过包装Adapter来提供header和footer。因为RecyclerView的Adapter是支持显示多种不同类型的view的，只需要重写RecyclerView.Adapter的 getItemViewType(int position)方法，根据不同位置返回不同类型即可。可以利用这个特性把第0个位置和最后一个位置预留出来，固定把第0个item存放下拉刷新的view，把最后一个位置存放加载更多的view。
实现侧滑、拖动
RecyclerView没有提供现成的API供我们操作，所幸SDK提供了ItemTouchHelper这样一个工具类帮助我们快速实现以上功能。
需要一个接口来实现Adapter和ItemTouchHelper之间涉及数据的操作，因为ItemTouchHelper在完成触摸的各种动画后，就要对Adapter的数据进行操作。
使用ItemTouchHelper需要一个Callback，该Callback是ItemTouchHelper.Callback的子类，我们可以重写其数个方法来实现我们的需求。