與天鬥與地鬥與人鬥其樂無窮
Jun 22
WWDC20221讲到iOS15在相机部分新增了不少识别相关的功能,一种有一项就是人物聚焦——对应背景模糊。同时,我们排查SDK变化时,注意到CIFilter新增了一个personSegmentationFilter,看起来就是对应这个功能的实现了。不过翻阅文档https://developer.apple.com/documentation/coreimage/cifilter/3750390-personsegmentationfilter?language=objc,苹果真是啥都没有讲。尝试了之后,我得到了能实现人物聚焦(背景虚化)的效果的CIFilter使用方式。
Jun 10
iOS15在UIKit中的改动并不多,其中一大项目是为UIButton新增了UIButtonConfiguration功能,为标准化button组件样式复用增加了更多的可能性。
之前我提过从里氏替换原则的角度,目前我们常用的复用UIButton的方法——继承+约束,其实是不合理的,那UIButtonConfiguration能解决我们的问题么?看起来不能。
Jan 31
自视程序员中壮士书生,然而审视案台之间,程序员的桌面总归是与文人墨客不同。

程序员的桌面不会总是一壶煮茶对酒当歌,一觞一咏一朝共语小窗前,枸杞茉莉花也不过是保温杯的伴侣,高糖配上咖啡因才是居家必备救心丸,一口下去般醍醐灌顶妙语连珠指尖生。程序员的桌边也没有文竹拂霜根苔色含羞隐,窗寒西岭孤城万山仞门泊东吴一船春色尽,除去工位间绿萝阴长,也就窗口多肉溢满园一抹油绿如蓝哑然青青青江平。自然,文房四宝笔墨纸砚必然也不会出现在我的案头,程序员不会凭君轻点染落笔把身藏惹得全身闻墨香,而是笔记本pad工作站一把梭哈走天下。
Dec 31
在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,几何数学运算的性能就相当关键了。
Dec 18
在图形学特别是游戏技术领域,通过SDF【Signed Distance Field】以及其衍生技术进行文字渲染已经是通用技术了,当然玩Webgl的人也都知道,我们知道这是在相关领域最常见的可缩放文本(但是不是矢量文本)方案。SDF定义上严格来说包含了字体储存和渲染方案二合一,因此既然我们可以用IconFont来解决图标问题,也可以用SDF来解决图标问题。

另外乍看起来,SDF还有IconFont没有的优势,包括:a. 资源分发灵活性,毕竟图片解决问题。b. 图形可延展,便于做描边,宽窄字体用同一资源。c. web兼容性,反正是自己写render,有canvas就行,计算复杂度远低于一般的canvas做其他图片格式兼容方案或者特殊渲染方案。d. 易使用,输出结果为canvas或者继续导出imageurl,icon即图片更合理。
Nov 21
我们做客户端包括并不限于Android/iOS/Windows/嵌入式程序等,核心指标之首均Crash率,我们通过Crash率来衡量咱们工程的可用性高低。目前业界Crash率的定义的定义有两种:

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

Oct 31
遇到这个问题的场景是,在react-native容器里,我们可以通过react-native-canvas绘制图片,并且拿到图片的base64信息。但是怎么把这个base64上传到服务端呢。谷歌搜索一番,一般的做法是通过类似于react-native-fs储存到本地,然后通过给地址的方式从formdata上传文件。由于我们的react-native容器有一套几乎和微信小程序一样的请求api,我们也搜索了小程序一般上传base64文件的方式——通过filesystemmanager储存到本地,然后通过uploadfile桥上传。
Oct 29
一般现代ReactNative二次封装框架除了处理bundle热更新,下发等,有一个设定是考虑到大量混合开发的情况,RN的应用级使用会改成页面级使用,以降低应用颗粒度的同时更自然的混合运行。但是这样做有一个存在疑问的地方,即每一个页面都会是用一个RN引擎即一个JSCore,内存占用高不说,每个页面的引擎创建成本也是相当高的,从性能/用户体验上均难以接受。因此会做“引擎复用”,即直观理解jscore复用这个事情。如果不对facebook的RN本身做大改而是基本基于其现有的api做二封的形式来完成,那引擎复用的方案/实现/与限制显然受到RN本身影响。因此本笔记讨论的是ReactNative到底做了啥,可以做到啥,哪儿来的限制。