获得徽章 1
- #青训营笔记创作活动#
2月18日,打卡day58
人脸特征提取就是针对人脸的某些特征进行判断(以下的动作判断仅供参考,实际情况下需要多个特征点来判断某个动作)
人脸的远近
取4帧 人脸占画面的比例,判断这组值是递增或递减,取第一帧和最后最后一帧的占比,根据阈值判断人脸的远近。展开评论点赞 - #青训营笔记创作活动#
2月16日,打卡day57
SanpshotSandbox
第一种是快照沙箱。
它的原理是:把主应用的 window 对象做浅拷贝,将 window 的键值对存成一个 Hash Map。之后无论微应用对 window 做任何改动,当要在恢复环境时,把这个 Hash Map 又应用到 window 上就可以了。
展开评论点赞 - #青训营笔记创作活动#
2月15日,打卡day56
Pinia 号称下一代的 Vuex。
经过初步体验,发现相比于 Vuex,Pinia 确实有了很大进步,最明显的就是删减了复杂的概念,简化了数据流转的过程,现在只剩下了 store、state、getters、actions 这四个核心概念。
接下来使用一个用户登录的案例,来学习 Pinia 的使用。
展开评论点赞 - #青训营笔记创作活动#
2月14日,打卡day55
在vue中key可以没有,没有也可以运行并且不会报错,但是建议加上key。
另外,我们必须知道,vue中key运用的地方------配合v-for使用。key是vue中虚拟dom标记的唯一标识,通过这个key,diff算法能更加准确和快捷。不使用key的情况下,因为vue的就地更新会选择复用节点,之前的状态被保存,可能会产生一系列的bug。另外,key的唯一性可以被map数据结构充分利用,时间复杂度仅为o(1)。
简单来说,key是唯一标识,为了让diff算法更准确的找到需要被对比的两个节点展开评论点赞 - #青训营笔记创作活动#
2月13日,打卡day54
前端的一整套东西覆盖也非常广泛,从开发、规范、测试、lint、构建、部署、监控、集成、微服务等等链路都隶属于前端工程化,所以一看这么长的链路再去考虑如何总结这个问题就显得务虚了,我们需要尽量将其简化,来逐个击破。逐渐完善我们对工程化的认知。展开评论点赞 - #青训营笔记创作活动#
2月13日,打卡day52
现在我们已经大致捋清楚了我们开发的思路,Block块是我们游戏中最重要的一个部分,我们现在来创建一下我们的Block块,这里我是使用了一个Class类来声明的,为什么要使用Class 而不是直接直接使用createElement渲染Dom块,我在这里说明一下,因为我们后续需要不断地判断Blcok块高亮,我这里是用的暴力检测法,选择的方法是重新渲染Dom,使用Class类,保存他的const aCs = new XXX()实例化结果,可以造成一种映射关系,aCs存储着生成dom的参数,这样我们需要修改页面上的dom的时候,不需要通过获取dom的方式来获取它的参数,而是直接使用aCs映射的参数即可展开评论点赞 - #青训营笔记创作活动#
2月10日,打卡day52
先实例化一个 DisplacementFilter 类,把纹理错位图传入进去,然后把这个过滤器实例添加到 filters 数组里面,最后执行 ticker 在 step 方法里会连续不断的执行, 通过不停改变 x 轴坐标,来实现纹理偏移水体扭曲的效果。展开评论点赞 - #青训营笔记创作活动#
2月9日,打卡day51
高亮部分 通过 el.cloneNode(true) 复制对应目标元素节点,并将克隆节点添加到蒙层上
- 通过 margin(或 tranlate、position 等)实现克隆节点的位置与目标节点重合
引导部分 通过 position: fixed 实现定位效果,并通过动态修改 left、top 属性实现引导弹窗跟随目标移动
过渡动画 通过 transition 实现位置的平滑移动
页面 位置/内容 发生变化时(如:resize、scroll 事件),需要重新计算位置信息展开评论点赞 - #青训营笔记创作活动#
1月28日,打卡day50
SetModifyResponse 与 SetErrorHandler 分别设置来自后端的响应以及到达后台错误的处理。 SetModifyResponse 实则是在设置反向代理拓展中的 modifyResponse ,如果后端返回任意响应,不管状态码是什么,这个方法将会被调用。如果 modifyResponse 方法返回一个错误,errorHandler 方法将会使用错误做入参被调用。展开评论点赞 - #青训营笔记创作活动#
1月27日,打卡day49
- 以锁粒度的维度划分:
- ①表锁:
- 全局锁:加上全局锁之后,整个数据库只能允许读,不允许做任何写操作。
- 元数据锁 / MDL锁:基于表的元数据加锁,加锁后整张表不允许其他事务操作。
- 意向锁:这个是InnoDB中为了支持多粒度的锁,为了兼容行锁、表锁而设计的。
- 自增锁 / AUTO-INC锁:这个是为了提升自增ID的并发插入性能而设计的。
- ②页面锁
- ③行锁:
- 记录锁 / Record锁:也就是行锁,一条记录和一行数据是同一个意思。
- 间隙锁 / Gap锁:InnoDB中解决幻读问题的一种锁机制。
- 临建锁 / Next-Key锁:间隙锁的升级版,同时具备记录锁+间隙锁的功能。
- 以互斥性的维度划分:
- 共享锁 / S锁:不同事务之间不会相互排斥、可以同时获取的锁。
- 排他锁 / X锁:不同事务之间会相互排斥、同时只能允许一个事务获取的锁。
- 共享排他锁 / SX锁:MySQL5.7版本中新引入的锁,主要是解决SMO带来的问题。
- 以操作类型的维度划分:
- 读锁:查询数据时使用的锁。
- 写锁:执行插入、删除、修改、DDL语句时使用的锁。
- 以加锁方式的维度划分:
- 显示锁:编写SQL语句时,手动指定加锁的粒度。
- 隐式锁:执行SQL语句时,根据隔离级别自动为SQL操作加锁。
- 以思想的维度划分:
- 乐观锁:每次执行前认为自己会成功,因此先尝试执行,失败时再获取锁。
- 悲观锁:每次执行前都认为自己无法成功,因此会先获取锁,然后再执行。展开评论点赞