暂时未有相关云产品技术能力~
移动端领域 Bug 贡献者
这是在UI开发中经常会遇到的场景:界面有两种状态,每一种状态下界面元素对应的操作都不同。比如在 offline 状态下点击大叉会直接退出应用,而在 login 状态下点击大叉会退出登录。 最简单直观的
上篇讲了一个使用组合的设计模式:装饰者模式。它通过继承复用了类型,通过组合复用了行为,最终达到扩展类功能的目的。 代理模式也运用了组合的实现方法,它和装饰者模式非常像,比较它们之间微妙的差别很有意思。
几乎所有的设计模式都是通过增加一层抽象来解决问题,装饰者模式也不例外,这一篇分析一下它新增了哪层抽象,以及这样做有什么好处。
变化是永恒的,产品需求稳定不变是不可能的,和产品经理互怼是没有用的,但有一个方向是可以努力的:让代码更有弹性,以不变应万变。 继上一次发版前突然变更单选按钮样式之后,又新增了两个和选项按钮有关的需求。
虽然不同的设计模式解决的问题各不相同,但从一个更高的抽象层次来看,它们通过相同的手段来实现相同的目的。本文将以更抽象的视角剖析工厂模式、策略模式、模版方法模式,以及这些模式所遵循的设计原则。
继上篇用“SurfaceView逐帧解析&帧复用”优化了帧动画内存性能后,一个更复杂的问题浮出水面:帧动画时间性能。这一篇试着让每帧素材大小 1MB 的帧动画流畅播放的同时不让内存膨胀。
应用 SurfaceView 逐帧绘制帧动画配合 Bitmap 复用。和原生帧动画的内存压力及卡顿说再见!
这一篇接着上一篇继续走查源码,分析拦截事件以及 ACTION_DOWN 事件的后续事件 ACTION_MOVE 及 ACTION_UP。
Android触摸事件和领导安排任务的过程很相似,也会经历“递”和“归”。这一篇会试着阅读源码来分析ACTION_DOWN事件的这个递归过程。
SparseArray可直译为“稀疏数组”,虽然听上去很“松散”,但它其实非常“紧致”。这一篇将会通过分析SparseArray的源码来展现这个类的矛盾之处。
从源码的角度分析“绘制(draw)”。View绘制只决定绘制的顺序,具体绘制内容由各个子View自己决定。
从源码的角度分析“定位(layout)”。 位置都是相对的,比如“我在你的右边”、“你在广场的西边”。为了表明位置,总是需要一个参照物。。。
这一篇将以源码中的几个关键函数为线索分析“测量(measure)”。 如果想直接看结论可以移步到第三篇末尾。 真正的测量工作在onMeasure()中进行。。。
产品需求的变更总是随心所以,猝不及防。如何让代码变得更有扩展性,以让我们在面对频繁需求变更时,不至于狼狈不堪?
本篇介绍了如何写出难以维护的 Feeds 流,为什么难以维护,可以运用哪些语言特性,哪些设计模式进行重构。
当列表数据变更时,调用 notifyDataSetChanged() 是最省事的。无需关心变更的细节,一股脑统统刷一遍就完事了。但这样做也是最昂贵的。读完这一篇源码走查就知道为啥它这么昂贵了。
上一篇介绍了手指滑动过程中,列表的滚动是如何实现的。那脱手之后,列表仍会滚动一段距离,即 fling,这又是如何实现的?走查源码一探究竟。
RecyclerView 是一个展示列表的控件,其中的子控件可以被滚动。这是怎么实现的?以走查源码的方式一探究竟。 切入点:触摸事件 阅读源码时,如何在浩瀚的源码中选择合适的切入点很重要,选好了能少走
该系列介绍如何高效地量化绘制性能,上两篇的 4 种优化手段已经把表项加载速度减半,这一篇在此基础上继续把加载时间打对折。
该系列介绍如何高效地量化绘制性能,上两篇的 4 种优化手段已经把表项加载速度减半,这一篇在此基础上继续把加载时间打对折。
在什么情况下 RecyclerView 的缓存机制会失效?即本该被回收的表项没能回收,无法回收就无法复用,这对列表的性能会有多大影响?从一个实例出发,探究下答案。 列表表项是一个 TextView,它
上一篇介绍了如何高效地量化绘制性能,并对 RecyclerView 加载速度做了 2 次优化,使得表项加载耗时从 370 ms 缩减到 288 ms。这一篇继续介绍后续的 2 种优化手段
RecyclerView 出场率很高。它的加载性能影响着用户体检。本篇分享一次完整的 RecyclerView 性能优化过程:从用工具定位问题,再不断尝试各种优化方案,最终达成 50% 的性能优化。
缓存是 RecyclerView 时间性能优越的重要原因。缓存池是所有缓存中速度最慢的。这一篇从源码出发,探究哪些情况下表项会被缓存到缓存池。
又一道关于 RecyclerView 面试题:“RecyclerView 滚动时,新表项是如何一个个被填充进来的?旧表项是如何一个个被回收的?”这篇以走读源码的方式,解答这个问题。
RecyclerView 表项动画的属性值是怎么获取的,又存储在哪里?这一篇继续通过 走查源码 的方式解答这个疑问。
RecyclerView 缓存之一的 scrap 结构中存的是什么?为什么要 scrap 缓存?pre-layout 及 post-layout 过程中 scrap 缓存内容如何变化?读源码来解答。
RecyclerView 表项动画是怎么实现的?RecyclerView 在做表项动画时会布局几次?pre-layout 是什么意思?一起来读一读源码,对这些问题追根溯源。
如何让列表加载分页数据过程无感知。一种实现方案是预加载,即在一页数据还未看完时就请求下一页数据。这一篇介绍一个超简单的预加载实现方案。
每次数据变化都全量刷新整个列表是很奢侈的,不仅整个列表会闪烁一下,而且所有可见表项都会重新绑定一遍数据。这一篇对 DiffUtil 进行二次封装以让其更易于使用。
上篇介绍了一种新的监听 RecyclerView 表项点击事件的方法。实现了将点击事件和RecyclerView.Adapter解耦。这一篇介绍如何监听 RecyclerView 表项子控件点击事件。
App 界面愈发复杂,元素越来越多,将不同类型的元素组织成 RecyclerView 就可以超越屏幕的限制。常用的RecyclerView在使用时有诸多痛点。这一篇尝试让扩展列表数据类型变得简单。
RecyclerView没有提供表项点击事件监听器,只能自己处理。这一篇介绍一种更加解耦,更易于使用的表项点击事件监听方法。
--- # 主题列表:juejin, github, smartblue, cyanosis, channing-cyan, fancy # 贡献主题:https://github.com/xitu/juejin-markdown-themes theme: github highlight: github --- RecyclerView 内存性能优越,这得益于它独特的缓存机制,上两篇已经分析了 RecyclerView 缓存机制会回收哪些表项,及如何从缓存中获取表项。本篇在此基础上继续走读源码,分析“回收的表项是以怎样的形式存放”。 这是`RecyclerView`缓存机制系列文章的第三
RecyclerView 缓存机制是面试中的常客。上一篇文章讲述了“从哪里获得回收的表项”,这一篇会结合实际回收场景分析下“回收哪些表项?”。
RecyclerView 内存性能优越,这得益于它独特的缓存机制,这一篇以走读源码的方式探究 RecyclerView 的缓存机制。