使用View来搭建UI
本文主要是想表达一下在Android UI开发中我对
View的看法,个人经验有限,有什么问题欢迎一块讨论。
如果说Activity是Android提供的页面容器的话，那View就是最基础的UI组件(有点是废话)。什么意思呢？我认为绝大部分UI开发工作都可以使用View来完成。下文就结合我工作中的一些实际case来谈一下View的使用。(当然不是讲怎么自定义View)
Fragment与View
Google推荐使用Fragment来在Activity中搭建碎片化UI，但我感觉完全可以使用View来代替Fragment完成这个功能，并且代码简单易懂可维护、bug也少。
为什么不推荐使用Fragment呢？可以看一下这篇文章:
Fragment都有哪些坑呢？下面这两篇文章了解一下:
当然我也是踩过Fragment很多坑的,比如在使用ViewPager + Fragment + LifeCycle这种架构时,ViewPager切换Fragment时，LifeCycle根本没做通知。
View相较于Fragment的优势
当然都是一些个人观点
-
View复用性更强,不像Fragment那样需要依赖于FrameLayout。其实Fragment的UI显示逻辑也是交给View的呀(有点是废话)。 -
View使用起来更灵活,你可以对他进行各种操作，比如remove/add、嵌套在任何地方等等，而且回调写起来更扁平。 - 使用
View不需要理会复杂的生命周期，其实你大部分情况下View的生命周期已经足够你使用了，大不了写个方法让Activity来回调就可以了。 - 都是用来显示UI，
View相较于Fragment更直接更纯粹,更轻量级,当然bug更少。
我们只需要使用View创建响应式UI，实现回退栈以及屏幕事件的处理，不用Fragment也能满足实际开发的需求。《出自Square：从今天开始抛弃Fragment吧!》
View使用实战
下面从几个不同的case来讲一下在实际场景中View的使用。
使用View来代替Fragment
很简单，只需要自定义一个ViewGroup就Ok了。不过对于一些逻辑复杂的页面我们会引入MVP，那么如何让Presenter来感知生命周期事件呢？在使用Fragment时，我们可以直接感受生命周期，对于View的话我们可以引入LifeCycle，即View感知Activity的生命周期，其实Fragment的生命周期也是跟着Activity走的呀。
View的Presenter对生命周期的感知
假设项目引入了LifeCycle， 那么可以这样设计:
Presenter实现LifecycleObserver
class DemoPresenter(demoPage:DemoPageProtocol) : LifecycleObserver {
private val model...
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
fun destroy() {
model.clearDisposable() //释放model中的网络资源
}
}
View把Presenter注册到LifeCycle中
class DemoPage(context: Context) : LinearLayout(context), DemoPageProtocol{
private val presenter: DemoPresenter by lazy { DemoPresenter(this) }
init {
LayoutInflater.from(context).inflate(R.layout.demo_page, this) //这里可以使用merge来消除冗余的父节点
(context as AppCompatActivity).lifecycle.addObserver(presenter)
}
}
这里的强转其实是没有问题的，我们使用的Activity基本都继承自AppCompatActivity。（当然你要知道你在写什么）
RecyclerView中的View
RecyclerView是使用频率非常高的一个控件，我个人比较推荐的一种写法是:直接写View,View到ViewHolder的映射交给Adapter来完成。具体封装方式可以参考下面这篇文章:
View中可以做一些简单的网络请求
RecyclerView中的View有时是会含有一些简单的网络事件的比如点赞、关注等等。我一般是直接写在View中，因为我感觉这样写起来更直观。但是网络请求在什么时候释放呢？我感觉可以在View onDetachedFromWindow时把这些网络事件释放掉:
override fun onDetachedFromWindow() {
super.onDetachedFromWindow()
disposableList.forEach { //释放 disposable, 防止内存泄漏问题
it.dispose()
}
}
PopupWindow与View
为什么说这个呢？ 其实是对应到DialogFragment。对于这个我想说还是别用。它的内部实现是: Fragment->(Dialog ->(PhoneWindow))。这3个东西加在一起就够头疼的了。
所以对于一些侧滑弹窗、上下操作弹窗可以使用PopupWindow+View来实现，不过PopupWindow在这种场景下也有一些问题，但相较于DialogFragment少一些:
PopupWindow不显示的问题:其实这篇文章也没有完全解决，在某些手机上你一定要定死宽高，PopupWindow才可以显示出来。
PopupWindow的弹出位置:PopupWindow弹出位置的计算。其实我目前使用的都是基于参照物Anchor(一般我都是取Activity.window.decorView)的相对位置来展示的。
在具体使用时最好采用组合的方式,比如:
class SimplePopupWindow(val context: Context, val mContentView: View) {
private var mWindow = PopupWindow()
init {
mWindow.apply {
contentView = mContentView
height = UIUtil.getScreenHeight()
width = UIUtil.getScreenWidth()
...
}
}
fun show(anchor: View) {
mWindow.update()
mWindow.showAsDropDown(anchor, 0, 0, Gravity.TOP)
}
.....
}
View的生命周期
想较于Fragment的生命周期来说，View的生命周期就很弱了，View的生命周期相关方法可以参考下面这篇文章:
这里重点提一下:对于View.onAttatchToWindow方法你应该知道它是在ViewRootImpl.performTraversal()中开始回调的，具体回调时机是measure前。
但是当使用View来搭建页面级UI时，像onAttatchToWindow、onDetachedFromWindow这种方法可能就不是很适用了。我的一般操作是写个方法直接让上层(Activity)来调用:
DemoPage
class DemoPage(context: Context) : LinearLayout(context),DemoPageProtocol{
//View被展示时,Activtiy回调这个方法
fun show() {
//load data
}
//对应Activtiy的onResume
fun onResume(){
}
}
对于ViewPager+View的架构来说，完成View的懒加载并不是什么难事。
Dialog与View
我曾经遇到过这样一个需求:
项目中的一个全局loading是使用Dialog来实现的，这就造成在loading出现时界面是锁死的,在这种情况下如果网络比较慢的话，很容易就让用户以为我们的app死掉了。所以需要实现这样一个全局loading:在它出现的时候不能锁死界面，并且用户点击返回键可以关掉它。
我是怎么实现的呢？其实我的实现方法比较取巧,好不好先不说，说一下思路吧:
- 自定义一个
ViewGroup, 它出现时会展示loading动画。 - 其内部含有一个看不见的
EditText，用于监听用户是否点击了返回键，点击了返回键的话就关掉loading。 - 可以自动attach到
Activity的DecorView上，当然也可以当做一个普通的View由其他组件来使用。
我个人感觉使用View来实现这个loading，相较于Dialog来说，还是很灵活的，有兴趣的同学可以看一下代码:
