暂时未有相关云产品技术能力~
移动端领域 Bug 贡献者
RecyclerView 的滚动是怎么实现的?(一)| 解锁阅读源码新姿势
RecyclerView 性能优化 | 把加载表项耗时减半 (三)
RecyclerView 性能优化 | 把加载表项耗时减半 (三)
RecyclerView 性能优化 | 是什么在破坏缓存机制?
RecyclerView 性能优化 | 把加载表项耗时减半 (二)
RecyclerView 性能优化 | 把加载表项耗时减半 (一)
RecyclerView 面试题 | 哪些情况下表项会被回收到缓存池?
Kotlin 进阶 | 不变型、协变、逆变
讲述一个代码随需求而变的过程,曾一度因为既有代码不能满足新的需求而卡壳。在阅读了 Android 源码后茅塞顿开,立马一顿重构。但重构完成之后,我陷入了沉思。。。。 新的需求是渐变色的进度条。只需在绘
如何让列表加载分页数据过程无感知。一种实现方案是预加载,即在一页数据还未看完时就请求下一页数据。这一篇介绍一个超简单的预加载实现方案。
每次数据变化都全量刷新整个列表是很奢侈的,不仅整个列表会闪烁一下,而且所有可见表项都会重新绑定一遍数据。这一篇对 DiffUtil 进行二次封装以让其更易于使用。
上篇介绍了一种新的监听 RecyclerView 表项点击事件的方法。实现了将点击事件和RecyclerView.Adapter解耦。这一篇介绍如何监听 RecyclerView 表项子控件点击事件。
App 界面愈发复杂,元素越来越多,将不同类型的元素组织成 RecyclerView 就可以超越屏幕的限制。常用的RecyclerView在使用时有诸多痛点。这一篇尝试让扩展列表数据类型变得简单。
项目中的各种描述形状的 xml 文件多如牛毛。虽然 xml 提供了可视化效果,但不能复用,读取耗时也是它的缺点。用 Kotlin 语法糖包装一下就可以和 xml 说再见。
掉帧是因为生产帧速度跟不上消费帧速度。Choreographer 用于同步生产和消费帧的速度。以读源码方式还原掉帧时软件层面发生的事情。
一年前,用 Java 写了一个高可扩展选择按钮库。只用单个控件实现单选、多选、菜单选,且选择模式可动态扩展。 一年后,试着用 Kotlin 重写该控件。
实现夜间模式有很多种方式,经过多次尝试,算是找到了一种性价比较高的方式。 这是最正统的方式,但工作量巨大,因为要全局替换 xml 布局中所有硬编码的色值,将其换成主题色。然后通过换主题达到换肤的效果。
刚踏入计算机行业那一年,单纯的我觉得“只要技术足够牛,就能使项目成功 。”但随着时间这把剃头刀不断地推高发际线,越发察觉到有一股技术以外的力量起着更大的作用。这也促使我跳出“写代码”边界,思考代码以外
在阅读viewModelScope源码时,发现了一种新的方式。 协程需隶属于某 CoroutineScope ,以实现structured-concurrency,而 CoroutineScope 应
本文以一个真实项目的业务场景为载体,描述了经历一次次重构后,代码变得越来越复杂(you ya)的过程。
上一篇讲述了 Activity 构建布局的过程,及测量其耗时的方法。这一篇在此基础上给出优化构建布局的方案。
上一篇讲述了 Activity 构建布局的过程,及测量其耗时的方法。这一篇在此基础上给出优化构建布局的方案。
xml 布局文件是如何变成 View 并填入 View 树的?带着这个问题,阅读源码,居然发现了一个优化布局构建时间的方案。
上一篇通过在父控件绘制前景的方式展示小红点,在布局文件中配置标记控件就能为任意子控件添加小红点。实现方案是”布局文件中配置带小红点控件 id,在父控件中获取它们的坐标,并在其右上角绘制圆圈“。但这个方
设计模式中的单例模式在多进程场景下会演变成多例,存在线程安全问题。本文通过跨进程通信机制让多进程共享单例。
上篇介绍了两种实现小红点的方案,分别是多控件叠加和单控件绘制,其中第二个方案有一个缺点:类型绑定。导致它无法被不同类型控件所复用。这篇给出一种新的方案。
小红点用于通知未读消息,在应用中到处可见。本文将介绍三种实现方案。分别是:多控件方案、单控件绘制方案、容器控件绘制方案。不知道你会更偏向哪种方案?
当你浏览公众号时来了一条新消息,通知在屏幕顶部会以自顶向下动画的形式入场,而且它是跨界面的全局浮窗(效果如下图)。虽然上一篇中抽象的浮窗工具类已经能实现这个需求。但本文在此基础上再封装一些更加友好的
本文以业务应用为出发点,从零开始抽象一个浮窗工具类,它用于在任意业务界面上展示悬浮窗。它可以同时管理多个浮窗,而且浮窗可以响应触摸事件,可拖拽,有贴边动画。
回想一下在作文本上写作的场景,当从左到右写满一行后,会切换到下一行的开头继续写。如果把“作文本”比作容器控件,把“字”比作子控件。Android 原生控件中没有能“自动换行”的容器控件。
吴宇森导演大家一点不陌生,听了他的故事后,我对 delay 的理解更深刻了。 吴宇森,中国香港导演、编剧、监制、演员。1986年执导的枪战片《英雄本色》奠定其暴力美学的电影风格,并获得第6届香港电影金
你一定在内心吐槽过他的代码太烂:没注释、逻辑混乱、到处都是 magic number、实现方案过时、耦合严重、一改就出 bug。 此时心中的怒火油然而生,仿佛自己是正义的化身。。。
这是在UI开发中经常会遇到的场景:界面有两种状态,每一种状态下界面元素对应的操作都不同。比如在 offline 状态下点击大叉会直接退出应用,而在 login 状态下点击大叉会退出登录。 最简单直观的
上篇讲了一个使用组合的设计模式:装饰者模式。它通过继承复用了类型,通过组合复用了行为,最终达到扩展类功能的目的。 代理模式也运用了组合的实现方法,它和装饰者模式非常像,比较它们之间微妙的差别很有意思。
几乎所有的设计模式都是通过增加一层抽象来解决问题,装饰者模式也不例外,这一篇分析一下它新增了哪层抽象,以及这样做有什么好处。
变化是永恒的,产品需求稳定不变是不可能的,和产品经理互怼是没有用的,但有一个方向是可以努力的:让代码更有弹性,以不变应万变。 继上一次发版前突然变更单选按钮样式之后,又新增了两个和选项按钮有关的需求。
虽然不同的设计模式解决的问题各不相同,但从一个更高的抽象层次来看,它们通过相同的手段来实现相同的目的。本文将以更抽象的视角剖析工厂模式、策略模式、模版方法模式,以及这些模式所遵循的设计原则。
继上篇用“SurfaceView逐帧解析&帧复用”优化了帧动画内存性能后,一个更复杂的问题浮出水面:帧动画时间性能。这一篇试着让每帧素材大小 1MB 的帧动画流畅播放的同时不让内存膨胀。
应用 SurfaceView 逐帧绘制帧动画配合 Bitmap 复用。和原生帧动画的内存压力及卡顿说再见!
从源码的角度分析“绘制(draw)”。View绘制只决定绘制的顺序,具体绘制内容由各个子View自己决定。
从源码的角度分析“定位(layout)”。 位置都是相对的,比如“我在你的右边”、“你在广场的西边”。为了表明位置,总是需要一个参照物。。。
这一篇将以源码中的几个关键函数为线索分析“测量(measure)”。 如果想直接看结论可以移步到第三篇末尾。 真正的测量工作在onMeasure()中进行。。。
产品需求的变更总是随心所以,猝不及防。如何让代码变得更有扩展性,以让我们在面对频繁需求变更时,不至于狼狈不堪?
本篇介绍了如何写出难以维护的 Feeds 流,为什么难以维护,可以运用哪些语言特性,哪些设计模式进行重构。
当列表数据变更时,调用 notifyDataSetChanged() 是最省事的。无需关心变更的细节,一股脑统统刷一遍就完事了。但这样做也是最昂贵的。读完这一篇源码走查就知道为啥它这么昂贵了。
上一篇介绍了手指滑动过程中,列表的滚动是如何实现的。那脱手之后,列表仍会滚动一段距离,即 fling,这又是如何实现的?走查源码一探究竟。
RecyclerView 是一个展示列表的控件,其中的子控件可以被滚动。这是怎么实现的?以走查源码的方式一探究竟。 切入点:触摸事件 阅读源码时,如何在浩瀚的源码中选择合适的切入点很重要,选好了能少走
该系列介绍如何高效地量化绘制性能,上两篇的 4 种优化手段已经把表项加载速度减半,这一篇在此基础上继续把加载时间打对折。
该系列介绍如何高效地量化绘制性能,上两篇的 4 种优化手段已经把表项加载速度减半,这一篇在此基础上继续把加载时间打对折。
在什么情况下 RecyclerView 的缓存机制会失效?即本该被回收的表项没能回收,无法回收就无法复用,这对列表的性能会有多大影响?从一个实例出发,探究下答案。 列表表项是一个 TextView,它