vue3 -- @vue/compiler-sfc 单文件转换工具

@vue/compiler-sfc

"version": "3.2.37"

SFC是vue中重要的一环,也是vue3中对于静态节点进行缓存提升的重要位置

SFC -- single file Component 单文件组件,以 .vue 进行结尾,这个文件浏览器也不会识别,最终也是要被转换成js代码

SFC中包含三块,template、script、style等三块代码,分别表示模版、脚本、样式三块

@vue/compiler-sfc的作用就是把单文件组件编译成为js代码

parse

下面就看一看具体的使用

新建一个Foo.vue组件

组件同时包括templatescriptstyle三块

新建一个nodejs脚本

用fs读取到文件的内容后,使用parse解析, 最终会返回一个对象

setup脚本改造foo.vue

setup语法编译后的结果

唯一的不同就是编译后的结果从原来的script上迁移到scriptSetup

compileTemplate

拿到之前parse后的结果后,需要对template进行进一步的转换,把template结果进一步编译成对应的js vnode函数

其中code的值就是最终模版编译的结果

我们把结果单独拿出来看下

最终返回了一个render函数,这里也就符合预期,vue组件中如果使用js的方式写,可以写一个render函数去渲染组件

compilerScript

根据parsed的结果来解析脚本部分,compileScript接收2个参数,第一个就是之前parse的结果, 然后再传入相应的option

编译后的结果,content就是最终编译出的代码

content格式化之后的结果, 所以说setup只是语法糖,最终还是以defineComponent去包裹一个对象进行返回的形式

compileStyle

compileStyle 即解析SFC style模块的入口函数

由于sfc中style块是可以写多个的,所以parse最终的结果styles其实是个数组

由变量签名也可以看出

这里我们取第一个块打印出来看一下,实际情况下应该是去循环的

编译结果

其中code即是最终的css结果

参考链接


vue3 -- @vue/compiler-sfc 单文件转换工具 -- 学习笔记

Android-Bitmap回收/复用机制

包括 recycle() 方法 bitmap 回收时机。

Android 系统版本的内存分配策略也有所不同,这是我们需要了解的:

系统版本 Bitmap 内存分配策略
Android 3.0 之前

Bitmap 对象存放在 Java Heap,而像素数据是存放在 native 内存中。

缺点:如果不手动调用 bitmap.recycle(),Bitmap native 内存的回收完全依赖 finalize() 回调,但是回调时机是不可控的

Android 3.0~7.0

Bitmap 对象和像素数据统一放到 Java Heap,即使不调用 bitmap.recycle(),Bitmap 像素也会随着对象一起被回收。

缺点:

1、Bitmap 全部放在 Java Heap,Bitmap 是内存消耗的大户,而 Max Heap 一般限制为 256、512MB,Bitmap 过大过多容易导致 OOM。

2、容易引起大量 GC,没有充分利用系统的可用内存

Android 8.0 及以后

1、使用了能够辅助回收 native 内存的 NativeAllocationRegistry 实现将像素数据放到 native 内存,并且可以和 Bitmap 对象一起快速释放,在 GC 的时候还可以考虑到这些 Bitmap 内存以防止被滥用。

2、新增硬件位图 Hardware Bitmap 解决图片内存占用过多和图像绘制效率过慢问题

手动调用recycle()

2.3 及以下版本,保存在 jvm + native 中,手动调用 recycle() 。

7.0 和 8.0 不需要调用 recycle(),下面是该版本下代码。

7.0 跟 8.0 nativeRecycle 实现不同。

8.0 版本 Bitmap

7.0 版本 Bitmap

  1. 8.0 中,手动调用 recycle() 方法,像素数据会立即释放;

  2. 7.0 版本中,调用 recycle() 方法像素数据不会立即释放,而是通过 DeleteWeakGlobalRef 交由 Jvm GC 处理。Java 层主动调用 recycle() 或者在 Bitmap 析构函数 freePixels() ,移除 Global 对象引用,这个对象是 Heap 内存一堆像素的空间。GC 时释放掉。二是 JNI 不再持有 Global Reference,并 native 函数执行后释放掉,但 Java 层的 Bitmap 对象还在,只是它的 mBuffer 和 mNativePtr 是无效地址,没有像素 Heap 的 Bitmap 也就几乎不消耗内存。Java 层 Bitmap 对象什么时候释放,生命周期结束自然会 free 掉。

回收机制

7.0 通过 java 层 BitmapFinalizer.finalize 实现,8.0 通过 native 层 NativeAllocationRegistry 实现。

7.0 及以下,保存在 jvm 虚拟机中,回收机制通过 BitmapFinalizer. finalize 实现。跟 BitmapFinalizer 而不跟 Bitmap 关联的原因是重写 finalize 方法的对象会被延迟回收,经过两次 gc 才会被回收。原因是重写 finalize 的对象在创建时会创建 FinalizerReference 并引用 Object,并将FR 关联到 ReferenceQueue 中,当第一次执行 gc 时候,会把 FR 放在 queue 中,其中有个守护线程持续读取 queue 中的数据,并执行 finalize 方法。

8.0 以上,保存在 jvm + native 中,NativeAllocationRegistry 中把 native 的文件描述符(句柄)跟 Cleaner 关联,Cleaner 其实是个虚应用,会在没有强应用关联的时候进行内存回收。

下面是 NativeAllocationRegistry.java 代码

NativeAllocationRegistry 内部是利用了 sun.misc.Cleaner.java 机制,简单来说:使用虚引用得知对象被GC的时机,在GC前执行额外的回收工作。

nativeGetNativeFinalizer()

nativeGetNativeFinalizer 是一个 native 函数,返回值是一个 long,这个值其实相当于 Bitmap_destruct() 函数的直接地址,Bitmap_destruct() 就是用来回收 native 层内存的。

故 NativeAllocationRegistry 利用虚引用感知 Java 对象被回收的时机,来回收 native 层内存;在 Android 8.0 (API 27) 之前,Android 通常使用Object#finalize() 调用时机来回收 native 层内存

Tips:Fresco 在 Android 4.4 及以下版本对 bitmap 内存做了优化,通过设置 BitmapFactory.Options.inPurgeable = true 使得 bitmap 保存在匿名共享内存中,减少了 Jvm 虚拟机内存占用。

继续阅读Android-Bitmap回收/复用机制

Spring Boot启动报错-"类文件具有错误的版本 61.0, 应为 52.0"

项目使用的 Spring Boot 升级到 3.0.5 版本

编译的时候报错如下:

或者:

原因

SpringBoot 使用了 3.0 或者 3.0 以上,因为 Spring 官方发布从 Spring 6 以及 SprinBoot 3.0 开始最低支持 JDK17,所以仅需将 SpringBoot 版本降低为 3.0 以下即可。

参考链接


.gitignore文件无法提交

问题

创建的 .gitignore 文件无法提交到 git 上

场景

log路径下创建了.gitignore文件, 文件内容:

想着忽略当前文件夹的所有内容. 此时想将 .gitignore文件提交上去, 运行git status 发现没有.gitignore文件的变动.

于是想着可能没反应过来, 就直接提交吧, 运行命令: git add .gitignore, 提示信息如下:

解决

如此看来, 是我将这个文件忽略了, 运行命令检查是那里将其忽略了git check-ignore -v .gitignore. 输出结果:

表明, 是在.gitignore文件的第一行, 规则* 忽略了此文件.

吆西, 明白了, 解决方法也简单, 修改.gitignore文件内容, 将此文件排除即可, 修改后的内容:

此时就可以正常提交。

参考链接


.gitignore 文件无法提交

Android Cuttlefish模拟器(Android Cloud)

macOS Big Sur(11.7.5)编译Android 12.0源码过程总结

Android 11系统映像可直接将 ARM 指令转换成 x86 指令,因此以前很多需要真机测试的情况,现在只需要模拟器就可以进行操作了。

不过,根据官方博客 Run ARM apps on the Android Emulator 尾部的一段注意事项:

Note that the ARM to x86 translation technology enables the execution of intellectual property owned by Arm Limited. It will only be available on Google APIs and Play Store system images, and can only be used for application development and debug purposes on x86 desktop, laptop, customer on-premises servers, and customer-procured cloud-based environments. The technology should not be used in the provision of commercial hosted services.

这段事项说明,自己编译的镜像是没办法用上这个功能的,必须是Google编译好的镜像。

前置条件


  • macOS Big Sur(11.7.5)
  • Homebrew (1.1.9 或更高版本)
  • Xcode (13.2.1或更高版本)
  • Android Studio Electric Eel | 2022.1.1 Patch 2

注意:根据Google官方文档,2021年6月22日之后的Android系统版本不支持在macOS系统上构建,我们只能构建之前的版本,或者之后发布的以前版本的补丁修复。目前测试最高只能编译到Android 12.0,  Android  12.1编译不通过。

继续阅读macOS Big Sur(11.7.5)编译Android 12.0源码过程总结

macOS Big Sur(11.7.5)编译Android 11.0源码过程总结

Android 11系统映像可直接将 ARM 指令转换成 x86 指令,因此以前很多需要真机测试的情况,现在只需要模拟器就可以进行操作了。

不过,根据官方博客 Run ARM apps on the Android Emulator 尾部的一段注意事项:

Note that the ARM to x86 translation technology enables the execution of intellectual property owned by Arm Limited. It will only be available on Google APIs and Play Store system images, and can only be used for application development and debug purposes on x86 desktop, laptop, customer on-premises servers, and customer-procured cloud-based environments. The technology should not be used in the provision of commercial hosted services.

这段事项说明,自己编译的镜像是没办法用上这个功能的,必须是Google编译好的镜像。

前置条件


  • macOS Big Sur(11.7.5)
  • Homebrew (1.1.9 或更高版本)
  • Xcode (13.2.1或更高版本)
  • Android Studio Electric Eel | 2022.1.1 Patch 2

注意:根据Google官方文档,2021年6月22日之后的Android系统版本不支持在macOS系统上构建,我们只能构建之前的版本,或者之后发布的以前版本的补丁修复。目前测试最高只能编译到Android 12.0,  Android  12.1编译不通过。

继续阅读macOS Big Sur(11.7.5)编译Android 11.0源码过程总结