今天尝试使用litho实现了略懂的首页列表.
总的来说, UI显示还是比较好实现的, 各种效果, 像是描边啊, 动态设置固定宽高什么的, 都能实现.
但是结果却有点失望, 在某些手机上, 效果(目测效果和gpu渲染丢帧率)竟然还不如目前的RecyclerView实现.
这些机型目前有mate10 pro.
怀疑, 自己对litho的使用还是不够最优, 可能有些地方还有改进优化的空间.
可能使用 glide显示图片, 这是一个问题, 使用的方法自己还没有搞清楚, 所以可能某些做法不够最优.
如果换成fressco库, 可能会有更好的性能. ---- 后续尝试一下.
内存占用量确实下降了. 目前还没有详细对比数据, 只能说大部分手机上, 都少占用30M左右
代码放在
https://github.com/shaopx/LithoDemo
其他一些问题:
- 有时候图片显示会闪动, 比如滑动出屏幕, 再滑回来之后, 图片的scaleType变了, 给人的感觉是图片放大了.
- 有些头像的显示, 无法显示, 滑动一下之后就可以了.
- 如何在列表中播放视频, 这还需要研究一下. 目前的demo不支持
- 为什么列表显示出来之后, 屏幕直接跳到了列表的中间位置?
2018.6.26 补充
确认, 对于RecyclerCollectionComponent这种用法, 底层实现的就是RecyclerView, 只是每个item的view都是优化精简过的LithoView
图片.png
这给了我们启示, 其实我们也可以自己搞的. 自定义布局, 自己通过非UI线程计算出各个控件的位置, 对于文本就直接在onDraw里面画, 对于图片, 也可以直接画, 但是设计图片加载的逻辑, 可能需要单独定义一种图片控件.
怎么布局? 可以按照安卓的这套规则布局, 但是解析起来不具备平台通用性, 在ios上就没有这种逻辑, 可能是这个原因, 所以facebook选择的flexbox语法, 并实现了一个native层的解析库yoga, 效率与兼容性并存.
但是也只能是想一想, 自己搞的话, 根本没有足够的精力和技术储备.
对glide的使用这块, 到是可以考虑优化, glide对图片的设置, 也就是最有的那步into()操作, 太耗时了, 基本上已经成为列表流畅度的最大绊脚石了.
图片.png
替换图片加载库为fressco
替换完成之后, 流畅度大大提升, 基本很少出现丢帧现象. 如丝般顺滑!
查看布局结构, 也看不到单独的ImageView了.
图片.png
图片.png
最重要的流畅度解决了. 剩下的就是要面对几个问题:
-
如何在列表上播放视频, 具体来说如何把exoplayer转换成Component
-
如何在点开图片的时候, 获取图片的位置尺寸, 因为要进行动态缩放进入图片查看activity.
-
很难做出下面这种弹框及动画吧:
图片.png
因为无法在代码中计算出一个view片段的屏幕位置. 这是一个很大的局限.
-
litho目前还不支持androidx(截止2018.9月)
网友评论