我在框架中见过很多代码,比如下面的代码。@pragma注解有什么作用?
@pragma
@pragma("vm:entry-point", "call") @pragma("vm:entry-point", "set") @pragma("vm:entry-point", "get") @pragma("vm:prefer-inline")` ......
zzlelutf1#
对于@pragma的一般含义cfr高于NKSM's answer。我将列举两个重要具体用例:
@pragma('vm:prefer-inline')
(我指的是编译时内联,它与作为 closure/lambda 同义词的'inline function'无关,有时也会这样做)此注解类似于inline keyword in Kotlin
@pragma("vm:entry-point")
关于entry-point的一个非常好的文档(写得比平常清楚得多)是https://github.com/dart-lang/sdk/blob/master/runtime/docs/compiler/aot/entry_point_pragma.md如果您想在dart中使用内联进行第一次测试,我建议您使用dart 2 js进行编译,它会输出相当可读的javascript代码(至少在您将收缩级别提高到超过默认值之前;和可读性,显然只有在最小的程序中才是体面的)。然而,dart/js中的内联需要一个稍微不同的@pragma注解:@pragma ('dart2js: tryInline') .dart-lang issue #40522 - Annotation for method inlining中有一个关于dart中内联的有趣讨论。总的来说,我建议使用Mraleph blog,他最近的文章是关于dart中的基准测试的,也展示了@pragma(vm:entry-point)的使用,Mraleph是Dart Sdk的开发者(他也是上面引用的官方doc的作者),它是关于Dart VM相关主题的非常珍贵的来源。
entry-point
@pragma ('dart2js: tryInline')
@pragma(vm:entry-point)
mccptt672#
Flutter使用**Dart**编程语言。
编译指示类是工具提示。
与Dart程序一起工作的工具可以接受提示来指导它们的行为,作为声明上的pragma注解。每个工具都决定它接受哪些提示,它们的含义,以及它们是否以及如何应用于带注解实体的子部分。识别pragma提示的工具应选择一个pragma前缀来标识该工具。它们应识别名称以前缀开头、后跟:的任何提示,就好像该提示是为该工具准备的一样。应忽略带有其他工具前缀的提示(除非目标是与其他工具兼容)。工具也可以识别无前缀的名称,如果它们能够识别前面带有自己前缀的名称的话。如果提示可以参数化,则还可以添加额外的选项对象。例如:
pragma
:
@pragma('Tool:pragma-name', [param1, param2, ...]) class Foo { } @pragma('OtherTool:other-pragma') void foo() { }
这里,类Foo用工具特定的pragma 'pragma-name'注解,函数foo用OtherTool特定的pragma 'other-pragma'注解。以上内容可在dart.dev documentation上找到。这里的@pragma('vm:entry-point')注解,它的核心逻辑是Tree-Shaking,在AOT(Ahead of Time)编译中,如果不能被应用的Main入口调用,就会被当作无用代码丢弃,AOP代码的注入逻辑是非侵入性的,所以显然不会被Main入口调用,所以需要这个注解来告诉编译器不要丢弃这个逻辑。
@pragma('vm:entry-point')
2条答案
按热度按时间zzlelutf1#
对于
@pragma
的一般含义cfr高于NKSM's answer。我将列举两个重要具体用例:
@pragma('vm:prefer-inline')
到内联函数(我指的是编译时内联,它与作为 closure/lambda 同义词的'inline function'无关,有时也会这样做)
此注解类似于inline keyword in Kotlin
@pragma("vm:entry-point")
标记函数(或其他实体,如类),以向编译器指示它将从本机代码中使用。如果没有此注解,dart编译器可能会删除未使用的函数,将它们内联,收缩名称等,本机代码将无法调用它。关于
entry-point
的一个非常好的文档(写得比平常清楚得多)是https://github.com/dart-lang/sdk/blob/master/runtime/docs/compiler/aot/entry_point_pragma.md如果您想在dart中使用内联进行第一次测试,我建议您使用dart 2 js进行编译,它会输出相当可读的javascript代码(至少在您将收缩级别提高到超过默认值之前;和可读性,显然只有在最小的程序中才是体面的)。然而,dart/js中的内联需要一个稍微不同的@pragma注解:
@pragma ('dart2js: tryInline')
.dart-lang issue #40522 - Annotation for method inlining中有一个关于dart中内联的有趣讨论。
总的来说,我建议使用Mraleph blog,他最近的文章是关于dart中的基准测试的,也展示了
@pragma(vm:entry-point)
的使用,Mraleph是Dart Sdk的开发者(他也是上面引用的官方doc的作者),它是关于Dart VM相关主题的非常珍贵的来源。mccptt672#
Flutter使用**Dart**编程语言。
编译指示类是工具提示。
与Dart程序一起工作的工具可以接受提示来指导它们的行为,作为声明上的
pragma
注解。每个工具都决定它接受哪些提示,它们的含义,以及它们是否以及如何应用于带注解实体的子部分。识别
pragma
提示的工具应选择一个pragma前缀来标识该工具。它们应识别名称以前缀开头、后跟:
的任何提示,就好像该提示是为该工具准备的一样。应忽略带有其他工具前缀的提示(除非目标是与其他工具兼容)。工具也可以识别无前缀的名称,如果它们能够识别前面带有自己前缀的名称的话。
如果提示可以参数化,则还可以添加额外的选项对象。
例如:
这里,类Foo用工具特定的pragma 'pragma-name'注解,函数foo用OtherTool特定的pragma 'other-pragma'注解。
以上内容可在dart.dev documentation上找到。
这里的
@pragma('vm:entry-point')
注解,它的核心逻辑是Tree-Shaking,在AOT(Ahead of Time)编译中,如果不能被应用的Main入口调用,就会被当作无用代码丢弃,AOP代码的注入逻辑是非侵入性的,所以显然不会被Main入口调用,所以需要这个注解来告诉编译器不要丢弃这个逻辑。