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开发类组件与函数组件谁更合适？

在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率，这样可以准确评估出用户感知到的可用性闪退率到底是多少。

遇到这个问题的场景是，在react-native容器里，我们可以通过react-native-canvas绘制图片，并且拿到图片的base64信息。但是怎么把这个base64上传到服务端呢。谷歌搜索一番，一般的做法是通过类似于react-native-fs储存到本地，然后通过给地址的方式从formdata上传文件。由于我们的react-native容器有一套几乎和微信小程序一样的请求api，我们也搜索了小程序一般上传base64文件的方式——通过filesystemmanager储存到本地，然后通过uploadfile桥上传。

一般现代ReactNative二次封装框架除了处理bundle热更新，下发等，有一个设定是考虑到大量混合开发的情况，RN的应用级使用会改成页面级使用，以降低应用颗粒度的同时更自然的混合运行。但是这样做有一个存在疑问的地方，即每一个页面都会是用一个RN引擎即一个JSCore，内存占用高不说，每个页面的引擎创建成本也是相当高的，从性能/用户体验上均难以接受。因此会做“引擎复用”，即直观理解jscore复用这个事情。如果不对facebook的RN本身做大改而是基本基于其现有的api做二封的形式来完成，那引擎复用的方案/实现/与限制显然受到RN本身影响。因此本笔记讨论的是ReactNative到底做了啥，可以做到啥，哪儿来的限制。