书接上回https://lrdcq.com/me/read.php/165.htm，我们探索了iOS26中液态玻璃的实现，同时在末尾留了一个尾巴，说：

- 统一渲染的操作系统，除非操作系统的renderserver支持，应该无法在性能可以接受的情况下重现这个流程的。因此旧版本iOS系统与鸿蒙系统扑街。对应，Android系统利用runtimeEffect，可以至少从流程上完整重现这个过程。

因此我们来整理一下在Android中实现液态玻璃效果需要经历哪些流程。
目前的效果如下，同时相关Demo完整代码附本文末尾：

每次有新的GUI框架推出了一个新的GUI效果，当然要逆向探索一下这个效果的实现原理，来明确：

1. 这个效果的整体实现流程，性能消耗，与优化路径与空间。
2. 这个效果在其他操作系统上/旧版本操作系统上是否可以对等或者降级的重现。

iOS26的Liquid Glass效果（液态玻璃效果）确实令人纠结，上手后大家都觉得又酷炫又卡，有些人觉得是GUI效果的全新上限，有些人觉得是纯粹的吃力不讨好的花活。抛开主观判断，这个效果确实值得对以上两个问题做判断。
当然作为成熟的iOS GUI开发者，了解苹果的尿性，虽然苹果是纯闭源的，看到这个效果和暴露的API之后就已经会有一些大致的判断了：

先看一下Android和iOS的GUI渲染流程

现代Android的GUI绘制流程，排除软件渲染（无硬件加速）的理想的普通GUI渲染流程如下：


1. 一个Android的View，会通过draw()调用到一系列属性与绘制方法（Canvas API），来完成一个View的绘制。

2. 但是实际上调用draw()方法，并不会立刻绘制，而是在执行完成之后，对当前ViewTree得到对应的RenderNode Tree，而Canvas调用转换为了绘制命令列表DrawCmd也被称为DisplayList。这些数据会发送到RenderThread中。

背景

我们知道iOS项目产物中是可以加入开发者的动态库（framework）的，如我们工程中使用的UnityFramework.framework。
正常情况下，在工程中link的动态库是程序启动时就会加载的（通过macho的LC_LOAD_DYLIB指令），会加载起包括用户加入的动态库和所有系统库。不过如果我们将framework构建完成并签名，不参与link而是直接放入资源中，这个动态库就会像资源一样正常的放在那里，程序中则可以通过dlopen或者CFBundleLoadExecutable将动态库手动加载起来，实现部分代码的用时加载，即iOS的动态库懒加载。

大量使用lottie的iOS应用会注意到，线上会存在大量的imageWithContentsOfFile卡顿。lottie使用imageWithContentsOfFile的地方很显然，即LOTLayerContainer的_setImageForAsset方法。这个方法在做啥？即如果当前layer是位图layer，从磁盘或者别的地方加载位图。而这里的卡顿，很显然：

1. 每个lottie从文件加载时，都会在此处从磁盘imageWithContentsOfFile加载图片，在主线程IO卡顿和图片解码产生卡顿风险。
2. 因为lottieView每次创建都是从文件创建的，即lottie资源本身没有实例机制，因此每一个重复的lottie创建都会重复imageWithContentsOfFile过程，加剧卡顿。

在上次讨论iDOT多线程png时，搜索到另一个领域的文章：iOS减包实战Compress PNG Files作用分析。其中提到了XCode构建过程中pngcrush的压缩过程会对png文件逆优化，就包括将png更新为iDOT格式（上文还不清楚iDOT的含义）。该文章建议的修复方案是修改资源属性，让构建过程对png不做处理，但是显然pngcrush对png渲染肯定有正向收益的，本文的目的即分析pngcrush的逆优化的实际缺陷与修复方案。（结合上文阅读）

最近有老外建立了一个新的项目，Block Protocol（https://blockprotocol.org），暂时简称“块协议”，目前还处于非常前期的阶段。它提出了一种思路与面向Web GUI的方案，通过块协议标准化的GUI块搭建应用与数据驱动逻辑，来构成人类与机器均友好的GUI应用。

听起来和一般我们所说的组件式或者模块式开发并没有什么不同，但是从块协议本身的视角，协议比实现更有价值，因此小议下blockprotocol的零零碎碎。

前一篇博客iDOT：iOS/OSX的PNG多线程解码提速格式（About Precise Format of iDOT Chunk）的视频版本

最近网络上有这么一个帖子：https://www.da.vidbuchanan.co.uk/widgets/pngdiff/。其中展示了一张图片，下半部分在苹果的系统与其他系统上展示不一致，其中的讨论使用苹果系统（包括iOS/OS X）设计的一种私有png chunk即iDOT，在mac上通过系统截屏截取的png就可以看到这个chunk。

目前网络上能搜到关于iDOT的描述，都是以截图的这种png为基准，分析出png分为两段的情况下，双线程解析png是iDOT是如何描述的（https://www.hackerfactor.com/blog/index.php?/archives/895-Connecting-the-iDOTs.html），不过其中还包含大量不准确（unknown）的字段，并且也不清晰如何描述分为两段以上即开启更多线程解析的方式。因此本次笔者经过逆向分析，得到了准确的多线程iDOT数据结构与全部字段含义，与一部分苹果的png decoder的iDOT校验逻辑，希望对后续该格式利用有所帮助。

在讨论js容器桥注入方案时，不可避免的会聊到react-native所搭建的JavascriptInterface（这是RN自己造的词，不过本文用JSI指代相同类型的方案）。JSI类方案一般确实不会有人提，核心原因是——除了RN，几乎没有什么方案是直接使用JSCore进行js执行的，而是通过Webview进行的h5页面执行，而对于webview来说，是无法直接拿到jscore的（严格来说只有iOS的UIWebview能拿到jscore，但是已经被淘汰了），