网站微信二维码侧边栏漂浮框,怎样建设个人影视网站,公司网站介绍范文,网站建设优化的技巧在去年春节#xff0c;Flutter 官方发布了宏#xff08;Macros#xff09;编程的原型支持#xff0c; 同年的 5 月份在 Google I/O 发布的 Dart 3.4 宣布了宏的实验性支持#xff0c;但是对于 Dart 内部来说#xff0c;从启动宏编程实验开始已经过去了几年#xff0c;但…在去年春节Flutter 官方发布了宏Macros编程的原型支持 同年的 5 月份在 Google I/O 发布的 Dart 3.4 宣布了宏的实验性支持但是对于 Dart 内部来说从启动宏编程实验开始已经过去了几年但是从目前的推进趋势看完全的宏功能支持并不理想结论大概是 能用是能用但是质量和性能都达不到一开始的预期。 具体原来在于 Dart 的静态语言提前编译和有状态的热重载等方面对于元编程而言需要建立在强大的内省基础支持之上但是对于 Dart 目前来说运行时内省例如反射会让 tree-shaking 优化变得困难 而 tree-shaking 优化是 Dart 在二进制优化的重要指标之一。
一开始 Dart 的目标是构建一个完整的宏系统从而让该系统支持在编译时对程序进行深度语义内省但是在实现语义内省时引入了大量的编译时成本而这让有状态的热重载保持变得困难。 目前的宏编程还让 Flutter 开发时的 IDE 编辑与补全体验下降。 同时带来的还有依赖项里的宏循环依赖等问题例如在 IDE 中输入“.foo” 可能需要重新处理所有宏从而执行正确的代码目前来看要么处理得太频繁要么给出的结果不正确。 在过去的测试里宏在小型库上的性能非常好但是在真实应用的大周期开发里会让 Dart 的体验变得很差例如在顶层编辑声明、方法头、字段等时基本上每次键入都需要重新运行整个宏构建。 而针对当前宏支持采用缓存的提议也存在宏生成的代码的整个版本适配问题例如 现在有一个依赖于 foo 和 bar 的 my_app 包如果你只在 foo 上运行 pub get解析器可能会给你 bar 1.2.3而当你在 my_app上运行 pub get 时也许会得到 bar 2.3.4大概可能是 doStuff 宏内省的 type from bar 在这些版本之间不同。 虽然也可以通过限制内省来避免这种深层依赖但带来的一些其他负面例如你可能正在为 foo 生成 JSON 序列化代码并且宏正在尝试判断其类型来自 bar 的字段是否支持 JSON 序列化甚至前面提到的循环依赖问题。
当然针对和这个可能还有其他解决方案相比较目前带来的编译时间、静态分析和整个程序的优化问题对于 Dart 来说运行时方法并不现实。
所以最终 Dart 团队决定由于宏的性能具体目标还太遥远团队决定把当前的实现回归到编辑例如静态分析和代码完成和增量编译热重载的第一步上。
具体在于重新投资Dart 中的数据支持**因为这也是Dart Flutter issue 里请求最多的问题事实上一开始 Dart 对宏支持的主要动机也是提供更好的数据序列化和反序列化但是目前看来通过更多定制语言功能来实现这一点更加实际。
另外通过缩短构建时间和整体代码生成体验来弥补宏的确实也是未来目标之一目前 Dart 已经确定了 build_runner 的改进支持。
另外还计划提供 augmentations 功能这是作为宏的一部分制作原型的功能例如增加修饰符 augment 作为扩充声明而该功能也是独立的部份并将改进现有的代码生成。 通过 augment 实现将一个功能部署到多个文件里同时可以添加新的顶级声明将新成员注入类并将函数和变量包装在其他代码中。 相信宏支持停止这个消息会让大家感到失望尽管从长远来看 Dart 仍然对通用元编程感兴趣因为它在数据之外还有许多潜在的用例但是在短期之内Dart 应该是不会发布宏支持。
对于包开发者来说比如之前的 equatable 在 3.0.0-dev.1 就发布过宏的实验性版本体验还不错但是现在看来只能继续“实验”下去。
最后祝大家 2025 新春快乐
参考链接
https://medium.com/dartlang/an-update-on-dart-macros-data-serialization-06d3037d4f12https://github.com/dart-lang/build/issues/3800
