区块链技术博客
www.b2bchain.cn

DialogX为什么放弃传统Window体系去使用View体系制作对话框的讨论和探究求职学习资料

本文介绍了DialogX为什么放弃传统Window体系去使用View体系制作对话框的讨论和探究求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

对技术面试,学习经验等有一些体会,在此分享。

问题简述

之前就有网友提出这个疑问,DialogX对话框组件 为什么不使用类似于传统 AlertDialog、Dialog 的 Window 体系进行实现,并质疑这会造成界面过度绘制的问题,在此我对这个问题进行一些我的想法的阐述。

因为觉得这个问题还是挺有意思的所以记录下来,以下是 Issues 的原文记录。

问题的重点主要在于不持有独立的 Window,将会对宿主 Window 造成过度绘制,弹窗时的背景遮罩算一层(绿色),对话框的背景算一层(浅红),这时候再布置些内容,就已经触及性能的红线了。

原答复

  1. 首先因为创建Window则会导致在Activity先于Dialog被关闭时发生WindowLeaked错误,我认为这反而不符合常识理解,按照正常理解,宿主Activity关闭相关联的基于宿主创建的组件理应自动卸载,但显然Google并未考虑这种问题,而开发APP的过程中因需要执行费时操作显示一个例如WaitDialog等待提示而在事务执行完毕后直接关闭Activity是一种常见操作,为避免这里出现问题通常不得不额外的在onDestroy时需要对Dialog进行dismiss我认为过于麻烦。 经过测试目前大部分设备性能并不会因为这层DialogX创建的布局发生卡顿。

  2. Kongzue Dialog前几代作品(例如DialogV3)都是基于AlertDialog或DialogFragment的Window体系制作的,但存在大量的不可避免的问题,诸如受到Window限制,无法做到底部导航栏自由沉浸式处理的问题,DialogFragment依然存在无法处理的内存泄漏问题,以及由Window引发的WindowLeaked泄露问题,另外经过我们测试,使用非Window改用View渲染模式实际上在Dialog UI显示和关闭时动画会更流畅而不是更卡顿,创建Window事务事实上开销成本并不低。目前DialogX已经应用于我们已上架应用和即将上架的测试版本,实际效果都非常不错。至于担心渲染层级多导致卡顿的问题,我们也做过实际试验,Android的Activity在同一界面同时渲染上千个View是不存在问题的,至于复杂场景,我更建议去考虑从UI设计上简化界面结构,而不是担心DialogX会增加很多负担,另外在dismiss后,DialogX会从当前界面完全remove掉,并不会增加太多性能持续消耗的开销。

额外的探究

实际上,这是一个权衡的问题。

权衡的重点在于重复绘制对实际上界面造成的渲染压力和相应能带来多少问题减少的优势之间的平衡。事实上使用传统 AlertDialog、Dialog 的 Window 体系进行对话框的创建因为要增加一层 Window 的创建,不可避免的是系统需要读取大量的 style 设置信息以及对 Window 创建相应步骤进行处理,而对话框的背景是透明的,底下的 Activity 也并不是就暂停不再进行渲染,实际造成的瞬间性能压力我并不认为会比创建一个 View 在 Activity 上小。

同时会造成的问题也远比 View 要大得多,至少到目前为止,使用传统 Window 体系创建对话框的用户依然会面临沉浸式状态栏、导航栏的着色问题、原本全屏的界面会被弹出的对话框“挤”成非全屏的问题,以及最为严重的因 Activity 先于 Dialog 被关闭的话就会出现 WindowLeaked 错误的崩溃问题,这反而增加了很多开发时需要处理的难度,基于减少开发量和减少问题的目的,DialogX 抛弃了 Window 体系创建对话框的方案改为了 View 的方案。

对于性能损失问题,事实上在大部分应用场景下,过渡渲染并没有造成太大的卡顿和相关问题,而对话框一般属于阻断式操作,也就是说在弹出对话框后,用户并不能操作后边的界面,而需要对对话框的内容进行处理。这种场景下造成了一定的渲染层级增加我认为并不会有太大影响,在操作完毕后,对话框布局会从界面布局直接卸载,也就是不会再继续渲染,这样只会造成短时间的渲染压力。

因为不去创建 Window,事实上经过我们对比评估,使用布局形式去创建对话框,在启动对话框时的动画流畅程度上也要比 Window 创建对话框要流畅的多,甚至能达到“丝般顺滑”的体验,这都是基于布局体系所带来的优势。

经过权衡,我依然认为使用布局体系的优势是大于 Window 体系的,而现如今 Window 体系下创建的对话框也并不能跨界面、跨应用去显示(悬浮窗除外)那么这种体系在一般开发场景下的优势已经不大了,基于 View 体系能实现更少问题、更易于维护何乐而不为呢。

如有疑问也欢迎继续理性讨论,探索最为有效的方案也是我持续最求的目标。

问题简述

之前就有网友提出这个疑问,DialogX对话框组件 为什么不使用类似于传统 AlertDialog、Dialog 的 Window 体系进行实现,并质疑这会造成界面过度绘制的问题,在此我对这个问题进行一些我的想法的阐述。

因为觉得这个问题还是挺有意思的所以记录下来,以下是 Issues 的原文记录。

问题的重点主要在于不持有独立的 Window,将会对宿主 Window 造成过度绘制,弹窗时的背景遮罩算一层(绿色),对话框的背景算一层(浅红),这时候再布置些内容,就已经触及性能的红线了。

原答复

  1. 首先因为创建Window则会导致在Activity先于Dialog被关闭时发生WindowLeaked错误,我认为这反而不符合常识理解,按照正常理解,宿主Activity关闭相关联的基于宿主创建的组件理应自动卸载,但显然Google并未考虑这种问题,而开发APP的过程中因需要执行费时操作显示一个例如WaitDialog等待提示而在事务执行完毕后直接关闭Activity是一种常见操作,为避免这里出现问题通常不得不额外的在onDestroy时需要对Dialog进行dismiss我认为过于麻烦。 经过测试目前大部分设备性能并不会因为这层DialogX创建的布局发生卡顿。

  2. Kongzue Dialog前几代作品(例如DialogV3)都是基于AlertDialog或DialogFragment的Window体系制作的,但存在大量的不可避免的问题,诸如受到Window限制,无法做到底部导航栏自由沉浸式处理的问题,DialogFragment依然存在无法处理的内存泄漏问题,以及由Window引发的WindowLeaked泄露问题,另外经过我们测试,使用非Window改用View渲染模式实际上在Dialog UI显示和关闭时动画会更流畅而不是更卡顿,创建Window事务事实上开销成本并不低。目前DialogX已经应用于我们已上架应用和即将上架的测试版本,实际效果都非常不错。至于担心渲染层级多导致卡顿的问题,我们也做过实际试验,Android的Activity在同一界面同时渲染上千个View是不存在问题的,至于复杂场景,我更建议去考虑从UI设计上简化界面结构,而不是担心DialogX会增加很多负担,另外在dismiss后,DialogX会从当前界面完全remove掉,并不会增加太多性能持续消耗的开销。

额外的探究

实际上,这是一个权衡的问题。

权衡的重点在于重复绘制对实际上界面造成的渲染压力和相应能带来多少问题减少的优势之间的平衡。事实上使用传统 AlertDialog、Dialog 的 Window 体系进行对话框的创建因为要增加一层 Window 的创建,不可避免的是系统需要读取大量的 style 设置信息以及对 Window 创建相应步骤进行处理,而对话框的背景是透明的,底下的 Activity 也并不是就暂停不再进行渲染,实际造成的瞬间性能压力我并不认为会比创建一个 View 在 Activity 上小。

同时会造成的问题也远比 View 要大得多,至少到目前为止,使用传统 Window 体系创建对话框的用户依然会面临沉浸式状态栏、导航栏的着色问题、原本全屏的界面会被弹出的对话框“挤”成非全屏的问题,以及最为严重的因 Activity 先于 Dialog 被关闭的话就会出现 WindowLeaked 错误的崩溃问题,这反而增加了很多开发时需要处理的难度,基于减少开发量和减少问题的目的,DialogX 抛弃了 Window 体系创建对话框的方案改为了 View 的方案。

对于性能损失问题,事实上在大部分应用场景下,过渡渲染并没有造成太大的卡顿和相关问题,而对话框一般属于阻断式操作,也就是说在弹出对话框后,用户并不能操作后边的界面,而需要对对话框的内容进行处理。这种场景下造成了一定的渲染层级增加我认为并不会有太大影响,在操作完毕后,对话框布局会从界面布局直接卸载,也就是不会再继续渲染,这样只会造成短时间的渲染压力。

因为不去创建 Window,事实上经过我们对比评估,使用布局形式去创建对话框,在启动对话框时的动画流畅程度上也要比 Window 创建对话框要流畅的多,甚至能达到“丝般顺滑”的体验,这都是基于布局体系所带来的优势。

经过权衡,我依然认为使用布局体系的优势是大于 Window 体系的,而现如今 Window 体系下创建的对话框也并不能跨界面、跨应用去显示(悬浮窗除外)那么这种体系在一般开发场景下的优势已经不大了,基于 View 体系能实现更少问题、更易于维护何乐而不为呢。

如有疑问也欢迎继续理性讨论,探索最为有效的方案也是我持续最求的目标。

问题简述

之前就有网友提出这个疑问,DialogX对话框组件 为什么不使用类似于传统 AlertDialog、Dialog 的 Window 体系进行实现,并质疑这会造成界面过度绘制的问题,在此我对这个问题进行一些我的想法的阐述。

因为觉得这个问题还是挺有意思的所以记录下来,以下是 Issues 的原文记录。

问题的重点主要在于不持有独立的 Window,将会对宿主 Window 造成过度绘制,弹窗时的背景遮罩算一层(绿色),对话框的背景算一层(浅红),这时候再布置些内容,就已经触及性能的红线了。

原答复

  1. 首先因为创建Window则会导致在Activity先于Dialog被关闭时发生WindowLeaked错误,我认为这反而不符合常识理解,按照正常理解,宿主Activity关闭相关联的基于宿主创建的组件理应自动卸载,但显然Google并未考虑这种问题,而开发APP的过程中因需要执行费时操作显示一个例如WaitDialog等待提示而在事务执行完毕后直接关闭Activity是一种常见操作,为避免这里出现问题通常不得不额外的在onDestroy时需要对Dialog进行dismiss我认为过于麻烦。 经过测试目前大部分设备性能并不会因为这层DialogX创建的布局发生卡顿。

  2. Kongzue Dialog前几代作品(例如DialogV3)都是基于AlertDialog或DialogFragment的Window体系制作的,但存在大量的不可避免的问题,诸如受到Window限制,无法做到底部导航栏自由沉浸式处理的问题,DialogFragment依然存在无法处理的内存泄漏问题,以及由Window引发的WindowLeaked泄露问题,另外经过我们测试,使用非Window改用View渲染模式实际上在Dialog UI显示和关闭时动画会更流畅而不是更卡顿,创建Window事务事实上开销成本并不低。目前DialogX已经应用于我们已上架应用和即将上架的测试版本,实际效果都非常不错。至于担心渲染层级多导致卡顿的问题,我们也做过实际试验,Android的Activity在同一界面同时渲染上千个View是不存在问题的,至于复杂场景,我更建议去考虑从UI设计上简化界面结构,而不是担心DialogX会增加很多负担,另外在dismiss后,DialogX会从当前界面完全remove掉,并不会增加太多性能持续消耗的开销。

额外的探究

实际上,这是一个权衡的问题。

权衡的重点在于重复绘制对实际上界面造成的渲染压力和相应能带来多少问题减少的优势之间的平衡。事实上使用传统 AlertDialog、Dialog 的 Window 体系进行对话框的创建因为要增加一层 Window 的创建,不可避免的是系统需要读取大量的 style 设置信息以及对 Window 创建相应步骤进行处理,而对话框的背景是透明的,底下的 Activity 也并不是就暂停不再进行渲染,实际造成的瞬间性能压力我并不认为会比创建一个 View 在 Activity 上小。

同时会造成的问题也远比 View 要大得多,至少到目前为止,使用传统 Window 体系创建对话框的用户依然会面临沉浸式状态栏、导航栏的着色问题、原本全屏的界面会被弹出的对话框“挤”成非全屏的问题,以及最为严重的因 Activity 先于 Dialog 被关闭的话就会出现 WindowLeaked 错误的崩溃问题,这反而增加了很多开发时需要处理的难度,基于减少开发量和减少问题的目的,DialogX 抛弃了 Window 体系创建对话框的方案改为了 View 的方案。

对于性能损失问题,事实上在大部分应用场景下,过渡渲染并没有造成太大的卡顿和相关问题,而对话框一般属于阻断式操作,也就是说在弹出对话框后,用户并不能操作后边的界面,而需要对对话框的内容进行处理。这种场景下造成了一定的渲染层级增加我认为并不会有太大影响,在操作完毕后,对话框布局会从界面布局直接卸载,也就是不会再继续渲染,这样只会造成短时间的渲染压力。

因为不去创建 Window,事实上经过我们对比评估,使用布局形式去创建对话框,在启动对话框时的动画流畅程度上也要比 Window 创建对话框要流畅的多,甚至能达到“丝般顺滑”的体验,这都是基于布局体系所带来的优势。

经过权衡,我依然认为使用布局体系的优势是大于 Window 体系的,而现如今 Window 体系下创建的对话框也并不能跨界面、跨应用去显示(悬浮窗除外)那么这种体系在一般开发场景下的优势已经不大了,基于 View 体系能实现更少问题、更易于维护何乐而不为呢。

如有疑问也欢迎继续理性讨论,探索最为有效的方案也是我持续最求的目标。

部分转自互联网,侵权删除联系

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » DialogX为什么放弃传统Window体系去使用View体系制作对话框的讨论和探究求职学习资料
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

b2b链

联系我们联系我们