是否有团队尝试用Skia全量渲染React Native/React组件？探讨其不可行原因

已有的尝试 #

• 确实有个人开发者和小型团队做过这类实验性项目，比如基于Skia实现React组件的全量渲染引擎原型，也有开发者尝试拓展React Native Skia来覆盖全组件渲染场景，但这些项目大多停留在实验阶段，没有进入大规模生产应用。

核心落地障碍 #

• 跨线程通信的性能损耗：Flutter的Skia渲染与Dart逻辑调度高度耦合，渲染指令无需跨引擎传递；但JS+React栈下，React的虚拟DOM计算、状态更新都在JS线程，渲染指令要序列化后传递给Skia渲染线程，频繁的线程通信会抵消Skia的性能优势，复杂页面下卡顿问题会比原生React Native更突出。
• 生态兼容的巨大工作量：React和React Native拥有海量第三方组件，几乎都依赖iOS/Android原生视图系统（如TextInput、ScrollView），要全量用Skia重写这些组件的交互逻辑、平台特性（比如iOS键盘适配、Android手势导航），工作量堪比从零搭建新生态，且无法直接复用现有组件资源。
• 平台适配的复杂度：Skia在不同平台（iOS/Android/Web/桌面）的渲染上下文、编译逻辑差异极大，JS栈下要做全平台适配，需要单独处理Web端Canvas/WebGL对接、桌面端系统窗口适配等问题，很难做到与原生平台一致的字体渲染、系统动画曲线体验。
• 长期维护的资源门槛：维护这类全量Skia渲染的React引擎，需要同时精通React调度机制、Skia底层渲染、JS引擎性能优化，还要持续跟进React和Skia的版本迭代，个人或小团队难以承担长期投入，大厂也更倾向于优化现有框架而非重复造轮子。
• 系统级能力的适配短板：原生平台的无障碍功能（屏幕阅读器、语音控制）、多任务切换、应用间共享等能力都与原生视图绑定，Skia渲染的自定义视图无法无缝对接这些系统级特性，用户体验很难达到原生应用标准。

内容的提问来源于stack exchange，提问作者Mars