WWDC20221讲到iOS15在相机部分新增了不少识别相关的功能，一种有一项就是人物聚焦——对应背景模糊。同时，我们排查SDK变化时，注意到CIFilter新增了一个personSegmentationFilter，看起来就是对应这个功能的实现了。不过翻阅文档https://developer.apple.com/documentation/coreimage/cifilter/3750390-personsegmentationfilter?language=objc，苹果真是啥都没有讲。尝试了之后，我得到了能实现人物聚焦（背景虚化）的效果的CIFilter使用方式。

iOS15在UIKit中的改动并不多，其中一大项目是为UIButton新增了UIButtonConfiguration功能，为标准化button组件样式复用增加了更多的可能性。
之前我提过从里氏替换原则的角度，目前我们常用的复用UIButton的方法——继承+约束，其实是不合理的，那UIButtonConfiguration能解决我们的问题么？看起来不能。

业务客户端开发，在某些业务领域总会遇到高并发问题。这里并不是指的日常访问流量高并发，比如本来应用访问流量大QPS高并不是问题。而是特指的用户业务流程高并发影响大：交易系统订单秒杀如何处理？营销推送同时触达怎么处理？紧急业务状态变更证明处理？当然这些问题在服务端高并发的解决方案中均有涉及，但是随着治理与优化的深入一定会到客户端这边来。同时客户端还有一个问题分发滞后性，假如1个月之后双11我们要提前进行并发优化储备，到双11应用覆盖面能有80%顶天了。

因此本文讨论的是，具有高并发业务特征的客户端，如何在业务开发设计阶段针对这一特点做好开发储备，防范于未然。

在客户端开发的过程中，我们总是会考虑下系统大字号的支持。之前的产品App统计的数据上，实际上有25%的用户调整到了比系统默认字号更大的字体，甚至在iOS上有10%的用户调整到归为Accessibility的特大号字体了（如图）。而事实上，iOS应用几乎没有应用去做大字号适配，目前的主流App相对来说腾讯的软件做得最好，QQ会根据系统设置自动适配，而微信则单独提供了内部字号设置界面。

目前业界普遍认可的认知上，对于Javascript这门语言来说，最大的包袱或者隐患就是this与其动态绑定问题。this的动态绑定问题带来的不止是写出bug的风险，还在代码可维护性，性能与语言发展上设置了无数障碍，同时也是典型的反直觉产物。因此业界一直在讨论，能否在javascript开发最佳实践中摒弃this，即实现thisless的Javascript。

之前在team里展开过一次“论战”，背景是咱们大型app的容器（Web容器，ReactNative容器）内页面/功能发均是react背景，同时开发人员native背景与h5背景均存在，实际开发过程中类组件与函数组件均有使用，并且在各个方向上有所踩坑。因此发起“论战”，即容器react开发类组件与函数组件谁更合适？

自视程序员中壮士书生，然而审视案台之间，程序员的桌面总归是与文人墨客不同。

程序员的桌面不会总是一壶煮茶对酒当歌，一觞一咏一朝共语小窗前，枸杞茉莉花也不过是保温杯的伴侣，高糖配上咖啡因才是居家必备救心丸，一口下去般醍醐灌顶妙语连珠指尖生。程序员的桌边也没有文竹拂霜根苔色含羞隐，窗寒西岭孤城万山仞门泊东吴一船春色尽，除去工位间绿萝阴长，也就窗口多肉溢满园一抹油绿如蓝哑然青青青江平。自然，文房四宝笔墨纸砚必然也不会出现在我的案头，程序员不会凭君轻点染落笔把身藏惹得全身闻墨香，而是笔记本pad工作站一把梭哈走天下。

在js完成驱动式动画，复杂动效，物理引擎，与3d场景数据预处理（比如threejs）的过程中，不可避免的会遇到需要在js中执行几何数学运算的场景。具体来说，比如操作css的transform样式，直接计算输出matrix或者matrix3d的值（比如https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Matrix_math_for_the_web写的这样）。只是一两个matrix还好，如果在dom中搭建了复杂的动效场景，并且动画效果需要逐帧驱动（requestAnimationFrame驱动）效果实效，并且保持在合理的60fps，几何数学运算的性能就相当关键了。

在图形学特别是游戏技术领域，通过SDF【Signed Distance Field】以及其衍生技术进行文字渲染已经是通用技术了，当然玩Webgl的人也都知道，我们知道这是在相关领域最常见的可缩放文本（但是不是矢量文本）方案。SDF定义上严格来说包含了字体储存和渲染方案二合一，因此既然我们可以用IconFont来解决图标问题，也可以用SDF来解决图标问题。

另外乍看起来，SDF还有IconFont没有的优势，包括：a. 资源分发灵活性，毕竟图片解决问题。b. 图形可延展，便于做描边，宽窄字体用同一资源。c. web兼容性，反正是自己写render，有canvas就行，计算复杂度远低于一般的canvas做其他图片格式兼容方案或者特殊渲染方案。d. 易使用，输出结果为canvas或者继续导出imageurl，icon即图片更合理。

我们做客户端包括并不限于Android/iOS/Windows/嵌入式程序等，核心指标之首均Crash率，我们通过Crash率来衡量咱们工程的可用性高低。目前业界Crash率的定义的定义有两种：

- Crash次数/启动次数，这样能测算出每次启动后到底有多少概率是正常离开的，多少概率是闪退的，非常理论化的一个数字。
- Crash次数/用户数，比如每日Crash次数除以日活即今日Crash率，这样可以准确评估出用户感知到的可用性闪退率到底是多少。