在 GWT 中，“linker” 和 DFN 代码拆分之间有什么关系？为什么链接器需要支持代码拆分，而有些链接器不支持呢？如何选择您的应用程序应使用哪个链接器，以及做出这一决定的因素是什么？
1个回答
12
主要的链接器（还有次要链接器，但在此不涉及）负责创建*.js或*.html文件来托管编译后的JS代码，当然也负责如何将它们引导/加载到浏览器中。
一旦你知道这一点，就很明显它们必须明确支持代码分割。
例如，xs（跨站点）链接器将整个脚本包装在匿名函数中，以便它不会“污染全局作用域”（该技术也称为模块模式）。因此，它无法动态地将其他脚本注入页面并访问其内部。sso（单脚本）链接器具有相同的限制。
std（iframe）链接器在动态创建的iframe中加载您的应用程序，该iframe作为沙箱：iframe的全局作用域不是主机页面的全局作用域。然后，它可以动态地在iframe中注入一个脚本，该脚本可以访问已经存在的所有内容（iframe的全局作用域）。
但实际上，您不必“选择应用程序应使用哪个链接器”：使用xsiframe即可（但需要显式激活，目前为止是这样）。它将xs链接器的跨站点友好性与std链接器的iframe沙盒相结合。
您可以预期，所有其他链接器（除了可能的sso链接器）将在未来的GWT版本中被弃用，并最终被完全删除；std链接器将被xsiframe链接器替换为默认链接器。
一旦你知道这一点，就很明显它们必须明确支持代码分割。
例如，xs（跨站点）链接器将整个脚本包装在匿名函数中，以便它不会“污染全局作用域”（该技术也称为模块模式）。因此，它无法动态地将其他脚本注入页面并访问其内部。sso（单脚本）链接器具有相同的限制。
std（iframe）链接器在动态创建的iframe中加载您的应用程序，该iframe作为沙箱：iframe的全局作用域不是主机页面的全局作用域。然后，它可以动态地在iframe中注入一个脚本，该脚本可以访问已经存在的所有内容（iframe的全局作用域）。
但实际上，您不必“选择应用程序应使用哪个链接器”：使用xsiframe即可（但需要显式激活，目前为止是这样）。它将xs链接器的跨站点友好性与std链接器的iframe沙盒相结合。
您可以预期，所有其他链接器（除了可能的sso链接器）将在未来的GWT版本中被弃用，并最终被完全删除；std链接器将被xsiframe链接器替换为默认链接器。
- Thomas Broyer
2
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
xsiframe链接器（请参见我的回答的最后两段），它支持代码拆分。 - Thomas Broyer