第三场阴影场与属性访问器接口

这是“ 影子字段与属性访问器”界面的 第3轮 。如果您是新手，但不确定要怎么做，请查看我以前的文章或关于开发JavaFX应用程序时节省内存的第一篇文章。作为Java开发人员，我主要关心的是在开发JavaFX域模型时在性能，内存使用和降低样板代码（易于使用API）之间取得良好的平衡。通常，应用程序框架提供模型视图控制器（MVC）或表示模型模式以将UI代码与域对象分开。实际上，想到的是域模型类型对象应该易于创建或生成（ IDE ）。在此博客条目中，您将看到第3轮的结果，其中包括两个部分 。第1部分是使用Marcel Heckel的想法实施的，第2部分是我最终根据性能， 内存使用和易用性实现的一种实现。

免责声明：使用任何代码均需自担风险。这纯粹是实验性的，不应在生产中使用。这是一个进展中的工作。

最新的代码在这里—> [ PropertyAccessors接口 ]

第二轮回顾

尽管上一轮（ 第2轮 ）表明我的Property Accessors策略在内存消耗方面比标准（fat）特性对象策略稍微好一点，但是当创建2,000,000个具有本地类型的Employee类型类的对象时，它在性能方面仍然令人失望输入对象 。与Dirk的实现相比，我对第二轮实现的内存使用仍然不满意。如果您只关心我在第3轮中的最终成绩，请跳至“ 结果”部分。

因为，可能会有新的回合，如果您决定使用它，或者假设Dirk决定在此处接受我的拉取请求，请转到此处查看当前代码。

在第2轮中，我使用了一个哈希映射查找，因为随着O（1）时间复杂度（搜索）越来越多地添加了越来越多的字段，它的查找速度可能会非常慢。有趣的是，Marcel Heckel提出了一种创建对象索引数组的简单方法，该方法不仅可以节省更多内存，而且速度更快。与键/值对查找相比，直接访问字段绝对是必经之路。尽管Marcel的代码速度更快，但它仍然比Dirk的Shadow Fields代码占用更多的内存。额外的内存实际上是通过预分配一个数组来占用的，该数组将保存每个字段的值。即使它们全为空，也会为每个员工对象创建数组本身。我在这里实施了Marcel的策略（第23行）。让我们看一下索引字段数组策略的结果。

第1部分：使用索引字段数组

private final Object[] modelProperties =new Object[FIELDS.values().length];public Object[] getModelProperties(){return modelProperties;}

测试：对象不使用属性字段

下面显示的是混合使用Marcel的索引数组思想和我使用枚举类型指定属性名称以将字段表示为属性字段的方式。

与所有字段均作为JavaFX属性的标准（胖）对象相比，未使用JavaFX属性的对象。此实现对每个字段使用数组索引，并使用数组保存每个值。

在上方，您会注意到未选中该复选框，以指示不要在域对象上创建JavaFX 属性（ 不使用xxxxProperty（）方法 ）。您会注意到，与第二回合的代码相比，性能得到了显着提高，并且内存使用量也减少了。在上图中， Property Accessor界面比Shadow Fields的模式实现多了16MB 。在瘦对象性能和内存使用的第1部分中， Shadow Fields是明显的赢家。但是，Shadow Fields仍然不太干净。还要注意的另一件事是，对于200万个对象，Property Accessors接口仅不到14毫秒！正如我们将在第2部分稍后将带回专用实例变量作为字段所看到的那样，Property Accessors界面将真正随着内存使用而发光。

测试：对象使用属性字段

以下是对象的所有字段都使用JavaFX属性时的结果。

使用JavaFX属性的对象与标准（胖）对象相比，所有字段均作为Javafx属性。此实现对每个字段使用数组索引，并使用数组保存每个值。

在这里，您会注意到200万个对象的Accessor列（Property Accessors接口）在916毫秒内执行，使用了576 MB的内存。在这种情况下，就544 MB的内存空间而言，标准（胖）对象是获胜者。到目前为止，Shadow Fields在每一轮比赛中都表现出色。

Marcel的代码示例（在注释部分）的一个小细节是，在创建新的属性对象实例时，它没有考虑属性的字符串名称 。例如，以下语句显示变量totalProperty ，其属性名为“ total ”，该属性与totalProperty（）方法匹配。在更改过程中触发属性名称对于读取代码，测试和工具很重要。

属性totalProperty = new SimpleIntegerProperty（this，“ total”，new Integer（5））;

为了同时拥有一个命名字段和一个类似于Marcel的想法的索引，我只创建了一个枚举来声明每个字段的属性。这些枚举在Employee类上创建。

// Part 1 implementation
public class EmployeePropertyAccessor implements PropertyAccessors{public enum FIELDS {name,powers,supervisor,minions}private final Object[] modelProperties =new Object[FIELDS.values().length];public Object[] getModelProperties(){return modelProperties;}// The rest of the code...

在上面，您会注意到将如何基于已定义字段（枚举FIELDS）的数量创建模型Properties数组。我使用FIELDS.value（）。length定义数组的大小。另外， PropertyAccessors接口（ 第1部分的实现 ）强制开发人员实现getModelProperties（）方法。在这里，我只是返回对对象数组的modelProperties引用。 “ 必须 ”实现一个数组和一个getModelProperties（）方法并不是一件很愉快的事情。

在本文的第2部分中，我以不同的方式实现了一些事情，其中开发人员没有被迫实现modelProperties数组和getModelProperties（）方法。我将解决此问题，使代码看起来更简洁，性能更好（API观点的用户）。

第2部分：重新引入实例变量

在第2部分中，我将把私有实例变量重新添加到Employee类（ EmployeePropertyAccessor ）中，以保存字段值，而不是像第1部分中那样包含数组。我的想法是使字段变量与指向本机对象的任一点互斥类型或JavaFX属性，从而与“影子字段”模式代码相比节省了内存。由于“ 阴影字段”代码使用两个变量来表示字段值，因此它将具有一个额外的引用，当对象使用属性时，该引用将不可避免地增加其内存。正如您在下面看到的那样，该代码看起来与第1部分相似，但也将具有一个静态块以在类中注册属性字段。这很重要，因为您可能不希望某些实例变量作为JavaFX属性参与。

// Part 2 implementation
public class EmployeePropertyAccessor implements PropertyAccessors {private Object name;private Object powers;private Object supervisor;private Object minions;enum FIELDS {name,powers,supervisor,minions}static {// register fields one time.// (Warning: enum's ordinal value is reassigned an index number)registerFields(EmployeePropertyAccessor.class, FIELDS.values());}public EmployeePropertyAccessor(String name, String powers) {setName(name);setPowers(powers);}public final String getName() {return getValue(FIELDS.name, "");}public final void setName(String name) {setValue(FIELDS.name, name);}public final StringProperty nameProperty() {return refProperty(FIELDS.name,
SimpleStringProperty.class, String.class);}// The rest of the code...

上面的代码清单在调用registerFields（）方法时做了一些有趣的魔术。使用反射重新分配 FIELDS枚举的序数值，从而为每个枚举赋予一个新的id作为数组的索引。这提供了不可变的枚举，同时还包含要通过索引快速访问的每个字段的唯一标识符。由于枚举用于表示要用作属性的字段，因此序数值在其他上下文中没有意义。这意味着：谁在乎，是否在这些声明的枚举上重新分配了序数值？它们仅用于“ 注册字段 ”。

测试：对象不使用属性字段[NEW]

下面显示的是使用Property Accessors接口API的新实现的测试结果。下面的测试显示了与标准胖对象相比，何时不使用属性字段。

将标准对象（使用属性的所有字段）与使用本机对象的对象进行比较的测试。现在，Property Accessors接口API使用实例变量作为字段，而不是对数组的引用。

正如您在上面看到的那样，Property Accessors接口的新实现显然是内存使用率和易用性的赢家。性能比第1部分的实现稍慢，但是节省内存是值得的。您会注意到，“影子字段”的内存使用量比“属性访问器”的使用量多16 MB。

测试：对象使用属性字段[NEW]

下面显示的是使用Property Accessors接口API的新实现的测试结果。下面的测试显示与标准脂肪对象相比，何时使用属性字段。（在“开始”按钮下方选中了该复选框）

screen-shot-2016-04-09-at-12-36-02-pm

第三回合的结果

以下是我根据表格中的结果汇总在一起的条形图。我觉得人们喜欢看图表而不是表格，单元格和文本。

对象不使用JavaFX属性时的性能测试结果。较小的数字（以毫秒为单位）更好。

对象使用JavaFX属性时的性能测试结果。较小的数字（以毫秒为单位）更好。

对象不使用JavaFX属性时的内存使用情况测试结果。较小的数字（以兆字节为单位）更好。

对象使用JavaFX属性时的内存使用情况测试结果。较小的数字（以兆字节为单位）更好。

结论

根据结果，我的目标是明确实现的 （IMHO），我最初希望代码在对象可能使用或不使用JavaFX属性时都易于阅读并且易于实现（ 当字段不使用JavaFX时还可以节省内存）属性[本机类型] ）。尽管在所有测试运行中都赢得了性能方面的Shadow Fields的认可，但Property Accessors界面并没有落后。当不使用属性时，在创建200万条记录时，Property Accessors界面仅比标准对象策略短5毫秒。

对于创建200万个对象的内存使用情况，以及当策略未使用属性作为字段时， Property Accessors界面显然是赢家，与Shadow Fields模式相比至少节省16MB ，与Shadow Fields模式相比节省240MB。标准属性代码。最后，但并非最不重要的是，当对象将属性用作字段时，Property Accessors接口与有关内存消耗的Standard对象策略相关联。 Shadow Fields策略使用的内存至少比其他策略多20MB。

尽管在使用或不使用所有字段作为200万个对象的属性时，Properties Accessors接口会稍慢一些（以毫秒为单位的微小差异），但我相信该API可以在任何JavaFX应用程序大小上使用，以简化域的开发模型和对象。我鼓励其他人在决定使用API之前先测试代码。请注意，该代码不适合生产，并且处于试验阶段。这是一项正在进行中的工作，因此，在我开始吃自己的狗食（工作时）之前，我真的不建议您使用Property Accessors API。我将在下面重申免责声明：