一般我们说web页面解析特别是其中的js执行是“单线程”的，并且这是js这门语言的特点。本身确实没什么，但是实际项目实践中，特别是目前重js的spa大行其道的今天，界面中绝大部分的运行时卡顿，如滚动掉帧，事件响应延迟，均是js卡顿引起的。比较常见的卡顿常见如大量json序列化反序列化，对象deepcopy，界面diff刷新不收敛，总之代码稍微写得烂了一点页面性能就不堪入目，更别说编写大型项目如动画/3d内项目时大量货真价实的运输拖慢帧率了。

前一篇博客从“离屏渲染”到UIKit界面渲染管线分析的视频版本

在iOS的学习过程中，我们总会聊到“离屏渲染”，在百度上能搜到的关于离屏渲染的描述都是

什么是离屏渲染. 离屏渲染（offscreen-rendering）顾名思义为屏幕外的渲染，即渲染的结果不会直接呈现到当前屏幕上，而是等待合适的时机才会被显示。

但是每次我问到候选人为什么UIKit会在这种情况下发生离屏渲染，极限是什么，根因是什么，可以避免么这样的问题时，大概率得不到方向正确的答案。毕竟是猜测UIKit的渲染行为，不像是安卓苹果的全闭源策略当然给开发者带来了理解困难。

当然也不全是，通过理解一个自然的GUI框架包含内容/搭建方案，结合苹果提供给我们的已知工具，我们应该可以分析出UIKit离屏渲染的逻辑与基础界面合成行为到底怎么回事。同时也可以通过苹果公开的一些文档进行验证。

CALayer的filters属性能为Layer渲染时添加CoreImage滤镜来做特殊效果。然而因为某些原因，根据苹果文档https://developer.apple.com/documentation/quartzcore/calayer/1410901-filters：

Special Considerations
This property is not supported on layers in iOS.

这个功能在iOS上是无法使用的。而在OS X上看起来则是能够轻易的使用：

我们知道在移动端设备上，GPU环节大多都会采用Tile Based Rendering方案。更具体来说，所有的iOS设备的GPU都采用的Tile-Based Deferred Rendering（TBDR）架构。正好翻阅到一篇WWDC2014的Advanced Graphics And Animation Performance文章对iOS中的TBDR进行了详解，因此针对iOS中Tile Based Rendering的基本情况与可能存在并可以进行的适配方案进行讨论。

最近使用html2canvas时遇到一个文字排版错误的缺陷，虽然html2canvas本身兼容性问题挺多的，但是这个看起来是一个广泛发生的问题，便进行了深入追踪。问题现象如下：

相关issues包括 https://github.com/niklasvh/html2canvas/issues/2648，https://github.com/niklasvh/html2canvas/issues/2696等，挺多的。

大家有没有注意到js中有两种对象，一种叫object一般翻译为“对象”，一种叫Object一般不作翻译。typeof得到的"object"即object，除了翻译为对象之外，在讨论时更常见的叫法叫“引用对象”。如果要用实际的例子，"typeof {}"与"typeof []"得到的都是"object"即对象；"[].toString()"得到的[object Array]而"{}.toString()"得到的[object Object]即表示[]属于object数据结构是Array而{}属于object数据结构是Object，同理比如我createElement('div')即能得到一个[object HTMLDivElement]。

在HTML中的input有一个maxLength的属性，可以很好的控制最大输入文本长度。但是其他GUI框架如iOS/OSX，flutter就没有这样的东西，Android的textview和react-native的input的功能也不健全，web开发也有遇到自己处理input的情况，就需要自己处理maxLength的问题。本小记记录标准的处理方案逻辑。

maxLength咋看起来好处理，但是一不留心bug特别多，看看京东web结算页的input出现的问题：

前几天Log4j的问题爆出，虽然和移动端无关，不少Android同学也顺带排查了下java项目中是否被误引入log4j（毕竟log4j还真有Android桥接版）。当然除了线下工具链里，线上代码是不存在log4j的，不过话说回来，同时也注意到各个项目中logger使用的混乱与标准不一致。从根因上讲，移动端的logger在解决团队问题的同时也有大量技术问题要解决，因此整理一下，一个优秀的移动端Logger，需要符合哪些期待并且目前最合理的技术方案有哪些？

随着现在互联网工程无限扩大的趋势，每一个技术方向均在经历各种拆拆拆，模块化解耦的过程，当然客户端也不例外。客户端早在5年前就完成了组件化到模块化这一过程，各种模块化方法层出不穷并在各大项目中落地。然而模块化之后，大家前往配置化的路途上却是相当坎坷，相对于服务端方案，web前端方案来说确实拿不出手。在服务端spring风格的xml配置和注解配置让javaweb服务业务基础搭建效率大大提升，web配置甚至能让运营完成活动落地页的搭建而不关心基建部分，它们的配置化都是革新性的银弹技术方案。而客户端做配置化能成为银弹么？