熟悉我的人都知道我其实是一个游戏爱好者，只是很少在博客写非技术文章而已。我在11月左右，因为受不了某日厂的PC独占行为而决定入手Steam Deck，这也是我自从2017年彻底放弃PC阵营之后第一次重回PC游戏领域，因此这里从一个主机玩家的视角整理一下我自己对Steam Deck，SteamOS的一些指南，希望能帮助中文领域的类似玩家快速上手和方便折腾。
断断续续写了几个小时，后续不断把我遇到的一些折腾指南都在这里更新吧，可以借助目录树来查看感兴趣的内容。
Steam Deck官网：https://www.steamdeck.com/zh-cn/
主机的规格主要是：
ImageIO是Apple提供的上层框架，用于处理常见图像格式的编解码支持。这篇文章主要讲述了三个子话题：WebP/AVIF的支持进展，IOSurafce和硬件解码优化50%内存开销，以及CGImageSource机制变化导致的线程安全问题
ImageIO的定位是上层的支持框架，其封装了诸多的苹果的底层解码器，开源编解码器，硬件HEVC/ProRes加速器等等底层细节，致力于提供和上层UI框架（如UIKit/CoreGraphics）的可交互性。
在早些年的时候，我写过一系列文章，介绍了其API使用的基本流程（参考：《iOS平台图片编解码入门教程（Image/IO篇）》），以及有关其惰性解码的机制（参考：《主流图片加载库所使用的预解码究竟干了什么》）。
实话说，自从重心从iOS开发，转移到做LLVM工具链相关工作之后，我本以为不会再写这些上层iOS框架的文章了，但是SDWebImage这个开源库依旧没有合我预期的新Maintainer，来作为交接，因此现在还是忍不住先写这一篇吐槽和说明文章。
这篇文章会介绍，自iOS 13时代之后，苹果在ImageIO上做的一系列优化（“机制变化”），以及对开发者生态带来的影响。
此篇文章在字节跳动的技术公众号已经刊登：《字节跳动DanceCC工具链系列之Xcode LLDB耗时监控统计方案》
在《Swift 调试性能的优化方案 》一文中，我们介绍了如何使用自定义的工具链，来针对性优化调试器的性能，解决大型Swift项目的调试痛点。
在经过内部项目的接入以及一段时间的试用之后，为了精确测量经过优化后的LLDB调试Xcode项目效率提升效果，衡量项目收益，需要开发一套能够同时获取Xcode官方工具链与DanceCC工具链调试耗时的耗时监控方案。
一般来说，LLDB内置的工作耗时，可以通过输入log timers dump来获取粗略的累计耗时，但是这个耗时只包括了源代码中插入了LLDB_SCOPED_TIMER()宏的函数，并不代表完整的真实耗时。并且这个耗时统计需要用户手动触发，如果要单独获取某次操作的耗时还需要先进行reset操作清空之前的耗时记录；对于我们目前的需求而言不够精确也不够自动。
此篇文章在字节跳动的技术公众号已经刊登：《字节跳动DanceCC工具链系列之Swift调试性能的优化方案》
原作者是我自己（李卓立 @dreampiggy）而非抄袭，这里在个人博客同时转发一下，去掉了招聘相关文案。不过依旧欢迎大家有兴趣的有志之士加入。
通常来说，大型Swift项目常含有大量混编（Objc/C/C++甚至是Rust）代码，含有超过100个以上的Swift Module，并可能同时包含二进制部分和源码部分。而这种大型项目在目前的Xcode 13体验下非常不好，经常存在类似“断点陷入后变量面板卡顿转菊花”、“显示变量失效”等问题。而且一直存在于多个历史Xcode版本。
图1：Xcode变量区显示卡顿转菊花，测试使用Xcode 13.3和下文提到的复现Demo
因为众所周知的原因，苹果的Xcode版本会不断提高自己的最低安装版本，在Xcode 13.0-13.2.1上，这个最低安装版本是macOS 11
而随着Xcode 13.3正式版放出，这个最低部署版本在最后关头被提升到了macOS 12
一般来说，各位开发者或者众多基建，总有各种各样的原因需要暂时留在老版本的macOS系统上，但是又希望使用新Xcode版本自带的Toolchain进行一些工作开发调试，有些是主观问题，有些是客观限制：
举例子：
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate off绕过GUI配置，导致一些公司采取Apple Device Management管理的电脑，无法正常关闭TCP拦截，会导致一些服务异常这些都是闲聊，进入正题。那么有没有办法能够绕开，或者从原理上来讲，是否这个系统绑定的最低部署版本限制是必要的？
自己很早之前曾经写过一些CocoaPods管理Resource资源的文章：CocoaPods的资源管理和Asset Catalog优化 ，当时列举了对普通图片类型的管理方式和一些用法，也普及了一下UIImage获取Bundle去加载不在mainBundle图像的方式。
但是苹果早在iOS 9，Xcode 7时代，苹果就已经推出了Data Asset的概念，并在随后的Xcode，尤其是Xcode 10中，为Data Asset提供了App Slicing的能力（即App Store提审包会根据选择的不同设备/内存/分辨率/GPU/CPU，最终下载到唯一匹配的一份文件），这个功能渐渐地开始被一些国内开发者使用。
在NSHipster这里，有一篇专门的文章介绍：《NSDataAsset》
不过，这篇文章主要的内容是，最近有同事踩到一个关于Data Asset和最低部署版本的坑，这里单独列举一下以防后人重复踩坑。
矢量图，指的是通过一系列数学描述，能够进行无损级别的变化和缩放的一种图像。相比于标量图（如JPEG等标量图压缩格式），能够在绘制时进行任意大小伸缩而不产生模糊，甚至能够实现动态着色，动画等等一系列交互。
在当今移动端设备尺寸越来越复杂，各种操作系统级别的夜间主题（或者Dark Mode）越来越提倡的场景下，如果依旧使用标量图，我们需要针对不同的屏幕大小（如2x，3x），和对应主题场景（Light/Dark），提供NxM数量级的标量图，对于App大小开销是很大的。因此，使用矢量图是一个非常有效的解决方案。这个系列文章，就是主要侧重讲解iOS端上的矢量图解决方案。
第一章是关于SVG及其相应衍生方案的解决方案，后续会有其他矢量图相关的PDF章节，Lottie等。他们各自有不同的细节场景区分和优缺点。
