Class 通过使用具体类而不是接口，编译后的js的大小减少了多少

我已经阅读了GWT，指定了返回具体实现的方法，例如：

public ArrayList<String> getList();

public List<String> getList();

public ArrayList getList（）；

而不是通常首选的“抽象接口”，例如：

public ArrayList<String> getList();

public List<String> getList();

public List getList（）；

导致GWT生成更小的编译javascript文件，因为客户端（ie js）代码不必满足接口的所有已知实现（在

列表

的示例中，客户端代码必须能够处理

链接列表

，

数组列表

，

向量

等），因此，它可以通过不编译未使用的实现来优化js

与我密切相关的问题是：

• 这是真的吗？（以下问题假设这是真的）
• 优化是针对使用接口的每个类，还是针对每个应用程序？即
• 我看到重构一个类的好处了吗？或
• 我是否只在所有客户机类被重构为不使用接口时才看到好处

---

以下假设您使用该接口作为GWT RPC服务签名的一部分。我认为，如果在GWT RPC服务的签名中不使用接口，那么使用类而不是接口的效果应该是最小的（例如，GWT编译器将只编译使用过的实现）

• 这是真的吗？（以下问题假设这是真的）

是的，当GWT编译器更好地“知道”哪些类可以从服务器发送到客户端时，它的输出就会变小

• 优化是针对使用接口的每个类，还是针对每个应用程序？即

对于GWT RPC，每个应用程序

• 我看到重构一个类的好处了吗

是的，如果接口需要包含多个类的代码，用实现替换一个接口可以将生成的代码大小减少几kb

但是，除了使用实现而不是接口之外，还可以在模块定义文件中定义类的“黑名单”，以明确避免在生成的代码中包含实现：类似于

<extend-configuration-property name="rpc.blacklist"
    value="-java.util.ArrayList" />  

---

我刚刚根据生成的示例应用程序做了一个测试，但我添加了3个简单的服务，根据构建返回

List

或

ArrayList

结果是，让所有服务使用

ArrayList

比混合使用任何返回类型都能从编译后的javascript中节省大约5Kb

这证明了每个应用程序（而不是每个服务）的节省是真实的

---

它还显示了它节省了多少（在本例中）。

这通常对GWT编译器来说并不实际。这种方法仅适用于与代码生成一起使用的类。例如，当使用远程过程调用时。有关更多详细信息，请参见此。因此，如果将接口而不是具体类声明为返回类型，编译器将在编译代码中包含所有可能的实现。这增加了编译时间和生成的代码量

---

实际上，可以在不使用RPC的情况下使用GWT开发应用程序。在这种情况下，编译后的代码在使用接口时不会膨胀。

测试这一点很容易。