打造基于 JS 的跨平台脚本引擎

鸿蒙 C/C++ 开发笔记

最近在做 C/C++ 跨平台开发，需要适配鸿蒙（Next），踩了不少坑（可能跟笔者之前对 Node-API 不熟悉有关）； 鸿蒙 NAPI 虽然官方说跟 Node-API 有差异，但 API 基本一致；总体来说，跟 NodeJS C/C++ AddOn 开发模式很像，下面详细展开。

打造基于 Lua 的跨平台脚本引擎

Lua 是一门短小精悍的脚本语言，在游戏和图形渲染领域早已有广泛应用。 同时，由于它能方便的和 C 语言交互、以及动态解释执行的特性，易于实现热更新，因此很适合用于二次开发实现跨平台脚本引擎。

RenderDoc 源码分析：OpenGL 资源监控

做渲染相关的开发，离不开图形调试工具。Android Studio 的 AGI 和 Xcode 的 Instruments 都提供了各自平台的相关能力。 若是做跨平台渲染，或追求更高阶的调试能力，需要用到 RenderDoc。

继续深挖 Android/iOS 的图形内存共享

前文在聊到跨 CPU/GPU 内存共享时，提到 Android 的外部纹理和 iOS 的 IOSurface，但并未深入展开。 那么，为什么它们能实现内存共享呢？ 先说结论：但凡涉及零拷贝内存共享，基本都离不开硬件的 DMA 能力。 下面我们抽丝剥茧地聊一聊。

聊聊 Android/iOS 的视频采集、渲染、编码

虽然 18 年就做过跨 Android/iOS 双端渲染的项目，但只是单纯地 2D 纹理渲染，不涉及视频流； 而后 19 年参与的图像识别项目，虽然涉及 Camera，但也仅限 Android 侧，而且也不涉及渲染。 近期有机会同时接触到 Android/iOS 直播项目，串联起图像采集/编码/渲染，终于深刻认识到双端图像处理的差异。 下面简单做下梳理。

基于栈 or 寄存器的 VM 有啥区别？

最近项目中有涉及 Lua，在查阅其 VM 资料时发现：从 5.0 开始，用了十年的基于栈的 VM 切换到了基于寄存器的 VM。 猛然联想到，当年校招背 Android 八股文时，也有一段类似的描述：“与基于栈的 JVM 不同，Dalvik 基于寄存器。” 当时也是一头雾水：有函数调用，就离不开栈，莫非基于寄存器的 VM 还能做到不用栈？ 初出茅庐时囫囵吞枣、不求甚解，结果多年后终究还是绕不开这个话

音频处理相关梳理

关于音频处理，最近之前做智能语音助手简单接触过 speex 压缩，最近做直播算是有了更进一步的认识，这里简单做下梳理。

梳理下 FFmpeg 的一些有用的命令

最近在探索图像处理类应用端到端耗时如何量化，最终方案是： 录视频 -> FFmpeg 分帧 -> 根据帧数量化耗时。 另外，平时自己从网上爬取 m3u8 视频，也会用到 FFmpeg。 所以，这里梳理下 FFmpeg 的一些比较有用的命令。

buffer 流的常见处理策略

最近发现，无论音频还是图像，无论是 AI 识别，还是音视频编码，只要实时处理，都涉及一个关键场景：buffer 流的处理。 这里简单梳理下常见的处理策略。

图像压缩原理及 libjpeg 源码分析

最近在做图像处理项目的性能优化时发现，RGB 转 JPG 压缩的文件大小有波动，而这个会显著影响图像上传耗时。 为什么会有波动呢？通过了解 JPG 压缩编码的原理，我找到了答案。

YUV 相关内容梳理

最近做了差不多半年的图像识别相关项目，涉及到 YUV 图像的处理，这里对相关内容作下简单梳理。

Android 图片压缩内存泄漏问题

最近在做 Android 相关的 YUV 图像压缩处理时，发现某些设备有内存泄露问题，这里作个简单梳理。

Kotlin/Native 跨平台实战从入门到“放弃”

JetBrains 推出的 Kotlin 语言相信 Android 和 Java 开发者都不陌生。作为一门现代编程语言，不仅支持函数式、Coroutine 等特性，而且拥有良好的 Java 互操作性，将 Java 社区海量的开源项目为我所用。所以，Google 官方已将其列为 Android 的首选语言，对标 Apple 的 Swift。 而最近推出的 Kotlin/Native 则

图形渲染性能优化之压缩纹理

PNG 是我们非常熟悉的一种无损压缩图片格式，常用于网络图片传输。而在图形渲染场景，对于 PNG 素材，我们一般要先将其解码为位图，然后转换为 GPU 纹理，处理完之后再释放内存中的位图对象。(iOS 有 GLKTextureLoader 帮我们封装了这一过程，但其实内部还是会做转换)在这一过程中，解码消耗 CPU，存储位图消耗内存；如果需要处理多帧纹理，则不断分配和释放内存还会造成内存“抖动