lichen

当你尝试在WSL上运行32位的程序时，shell将会报错：cannot execute binary file: Exec format error. 这是因为WSL目前暂不支持32位的ELF可执行文件。 在命令行中加入下面代码就可以了 sudo apt install qemu-user-static sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\

V8垃圾回收分析 关于垃圾回收机制 由于JavaScript 的对象是在V8上生产的，所以生命周期也是由V8来控制，这里就牵扯到了垃圾回收。任何垃圾回收都会做以下三件事情： * 识别不再被引用的对象（Dead Objects） * 回收这些对象所占用的内存 * 重新压碎整理碎片化的内存块（可选的） 分代机制 V8的垃圾回收机制也与其他主流语言一样（有垃圾回收机制的语言），使用的世代回收机制，主要有两个世代：新生代（Young generation）和老年代（Old generation），V8在这个两个世代的前提下，又增加了独特的空间，用来存放专门的对象。以下是V8在内存管理中的所有空间： RO_SPACE, // Immortal, immovable and immutable objects, NEW_SPACE, // Young generation semispaces for regular objects collected with // Scavenger. OLD_SPACE, // Old ge

InputFilter这个interface相信大家也不会陌生,任何对EditText的输入第一步就会经过它,而它的名字也十分的直白——输入过滤器.InputFilter只有一个方法,就是 filter方法,而这个方法却对你的输入过滤有着至关重要的结果,我们现在看看google的官方文档是怎么描述这个filter方法的. > This method is called when the buffer is going to replace the range dstart … dend of dest with the new text from the range start … end of source. Return the CharSequence that you would like to have placed there instead,

在Blink上工作不是件容易的事.Blink有很多专有的概念,并且有一套为了实现快速渲染引擎而引入的编码规范,这个对于新开发者来说并不是易事.即使是经验丰富的Blink开发人员也不容易,因为Blink非常庞大,对性能,内存和安全性极为敏感. 这篇文档的目的是帮助Blink的开发者快速熟悉架构: * 该文档并不是讲述Blink的详细架构和编码规则教程.相反,该文档简明的描述了Blink的短期内不太可能发生变化基本面,并指出如果你想了解更多信息,你可以阅读的资源有哪些。 * 该文档没有解释具体的某些功能（例如，ServiceWorkers，编辑）.相反,该文档解释了基本功能(例如，存储器管理，V8 API)。 Blink是干什么的? 进程/线程架构 * 进程 * 线程 * 初始化Blink 目录结构 * Content公开API和blink公开API * 目录结构和依赖 [Directory_structure_and_dependencies] * Web Template Framework(WTF) 内存

堆排序的主要步骤分为三部分: 1. 建堆 2. 维持堆的性质 3. 排序 首先是建堆,建堆的主要目的是建立一个最大堆,这样我们就可以保证堆顶的元素一定是这个数组中最大的元素. void buildHeap(int *array, int size) { for (int i = size / 2; i >= 0; i--) { maxHeapify(array, i, size); //维持最大堆性质 } } 其次是维持最大堆性质,其过程如下: 1. 比较当前节点(父节点)和自己的2个子节点(可能是1个)的大小. 2. 将3个节点中最大值的点与当前节点交换位置. 3. 如果产生了节点交换,那么继续以交换后的节点作为父节点继续执行maxHeapify. 4. 直到不再产生节点位置交换. void maxHeapify(int *array, int

这边文章讲的内容为chromium的上层架构. 问题 构建一个不崩溃或者绝对安全的渲染引擎几乎是不可能的. 在2006年左右,浏览器的状态类似于过去的单用户,协作式操作系统.由于一些程序的错误行为可能导致整个系统都崩溃,同样某些页面的错误操作会使整个浏览器奔溃,这只是一个页面的错误或者插件的bug就会导致整个浏览器关闭和所有的Tabs. 现在的操作系统往往都更健壮,因为它将不同的程序放到了彼此隔离的单独进程中.一个应用崩溃通常不会影响其他应用或者整个系统,并且每个用户访问其他用户的数据是受限的. 架构概览 我们对浏览器的Tab页使用单独进程,可以避免整个应用受到渲染引擎的bug或者小故障的影响.我们也限制每个渲染引擎进程访问其他进程和系统的其他部分.这为浏览器带来了内存保护和访问控制操作系统带来了好处. 我们将运行UI的主线程和管理Tabs和插件进程的作为"浏览器进程"或者"浏览器".同样的,特定Tab的进程称为"渲染进程"或者"渲染器".渲染器使用Blink开源布局引擎来解释和布局HTML. 管理渲染引擎 每个渲染过程都有一个全局RenderProcess对象，该对象

最近开发功能的时候monkey总是能跑出一个bug, java.lang.RuntimeException: Could not read input channel file descriptors from parcel. 百思不得其解,认为是系统上面的bug,实时证明自己还是太年轻.现在开始分析一下这个bug产生的原因. 一.为什么会产生句柄泄露? 众所周知Android是linux内核,也就是可以理解linux下,一切资源都是句柄,每个进程都有自己的句柄上限,而超过了这个句柄上线,就会发生异常.一般android的App都是在单个进程下运行的,FD的句柄上限是1024,这个在后面的会说明.一切的重点都在**proc(Processes,虚拟的目录，是系统内存的映射。可直接访问这个目录来获取系统信息。 )**这个文件夹下的内容. 这里有参考The proc File System [https://www.centos.org/docs/5/html/5.1/Deployment_Guide/

1. Vue的生命周期中, $rounter 可能在 created 和 mounted 阶段并没有初始化好,这时使用 push 或者 replace 是无效的,这时我们可以使用这个方法来解决这个问题: this.queryParams = this.$route.query this.$router.onReady(() => { this.$router.push({ query }) })