
我们的操作系统需要运行各种各样程序,为了程序的管理,进行了各种各样的抽象,对内存的管理,抽象了虚拟内存,对程序抽象出了进程。随着cpu核心的增多,进程的抽象有点笨重,主要原因是
- 创建进程的开销比较大,父子进程之间需要拷贝的东西比较多,虽然为解决内存共享的一些问题,提出了写时拷贝技术,但是写时拷贝会造成延时
- 进程之间通信的开销高,共享数据和同步数据比较麻烦
我们的操作系统需要运行各种各样程序,为了程序的管理,进行了各种各样的抽象,对内存的管理,抽象了虚拟内存,对程序抽象出了进程。随着cpu核心的增多,进程的抽象有点笨重,主要原因是
在vk不做数图业务之后,现在负责slider业务的重构,slider其实是交互式课件的加载器,渲染器,主要有以下4个功能
由于slider模块,1v1直播课,大米网校, 超级课堂,数学课等几乎公司所有的直播涉及到课件的业务都在使用。不同业务对slider有不同需求,而且有些业务信令不同,如数学课的信令与1v1所使用的信令协议不一样,所使用的教具,数学课有12个教具,而1v1只有8个教具,教具ui也不一致,1v1的翻页按钮,与数学课的翻页按钮ui不一致。之前的架构将所有融合在一块导致slider代码臃肿。
1.由于是响应式课件,学生可操作课件上按钮,动画,在老师端能显示对应学生的操作,老师能够限制学生操作
2.教具模块,例如学生老师能够实时划线,并显示在屏幕上,老师能够删除每一个划线,当学生断开连接,重新进入,能够保持当时状态(快照功能)
发表评论这一章会介绍Orinoco垃圾回收器对应知识,之前垃圾回收是有序执行,stop-the-world(STW),Orinoco垃圾回收器是一个在大部分情况下进行并行以及并发运作,来快速的进行垃圾回收。下面是相关视频的介绍
我们都清楚任何垃圾回收器都有一些周期性需要完成的工作
垃圾回收的运行会阻断渲染进程的运行,这会影响浏览器的体验。V8引擎的开发者打算优化v8的垃圾回收模块,优化的垃圾收集器代号为Orinoco。Orinoco与之前未优化的垃圾回收器相比
在这篇文章中我们讨论新的垃圾收集器的三个特性,他们分别是
V8实现了代际垃圾收集器,新生代对象在经历两次回收生存下来的对象会被划分到老生代对象存储空间。对象在内存中移动的代价是很昂贵的,主要是在引擎中我们需要对象的需要复制到新的位置,此外我们还需要更新这些对象的指针。图1显示了Orinoco之前的阶段及其执行方式。基本上,对象先被移动,之后再更新这些对象之间的指针,所有这些都是按顺序进行的,消耗的时间过长。
javascript 是带有gc机制的语言,与c,c++ 这种需要用户手动进行内存的管理语言不同,带有gc机制的语言,我们在写代码的过程无需管理已分配的内存块,减少我们编写的代码心智成本。
chrome浏览器js引擎是v8, 起初v8的大部分垃圾回收工作是在主渲染线程上进行的。我们清楚当浏览器器在16.66ms内无法完成一帧的渲染时,那么就会出现页面卡顿现象。当GC需要维护的对象变多时,垃圾回收过程所占用的时间也会导致页面卡顿。如下图所示
本文翻译转载自https://increment.com/frontend/making-vue-3/
重写下个Vue.js下一个主要版本的收获
在上一年,vue团队一直在开发vue3这个版本,我们希望在2020的上半年发布。(在写这篇文章的时候,我们还在开发中)。新版本功能定型在2018年末,vue2已经有两年多没有大的更新。对于一般的软件来说,这个时间不算长,但是前端有很多东西发生变化。
重写vue有两个关键原因,第一,javascript 新特征,主流浏览器都支持的不错,第二点,当前版本的设计和架构问题有很长时间没有解决了。
阅读 “打造vue3的历程” 发表评论无限滚动在实际项目中用到很多,比较在vipkid 数字图书馆的的书库这个业务中,就用到滚动加载,如下视频所示
正常思路是,我们监听scroll事件,当滚动条滑到底部的时候,触发加载,请求数据,将新数据插入尾部。
这里面,我们会碰到两个问题,