C++/CX性能陷阱

使用C++/CX编写应用程序和编写正常的C++应用程序不一样。纯C++代码和Windows运行时（WinRT）之间的互操作性出奇的昂贵。基于Sridhar Madhugiri的视频 C++/CX 最佳实战中的内容，我们在本文中列举了一些在Windows 8开发中避免性能问题的方式。

边界

在应用程序的边界上会产生多种性能障碍。

数据转换就是其中的一个例子。考虑一下一个Web服务客户端和应用程序剩余部分之间的典型边界。大多数Web服务是使用UTF-8编码的，而大多数Windows应用程序的内部则是使用UTF-16编码的。在Windows中UTF-16编码是如此的流行以致于人们有时会将它错误地称为“Unicode”编码。数据转换的成本可能是确定的，也可能广泛变化，这依赖于它在数据本身中的特定值。

下一种性能消耗来自于类型转换。例如，你可能需要一个wstring，但是却有一个wchar_t *。尽管在内存中每种类型所包含的数据看起来是一样的，但是将这些内容从一个数据结构复制到另一个数据结构依然是有性能成本的。

最后一种性能消耗来自于数据复制操作。有时候你必须为边界处的数据复制付出代价，哪怕它们并不需要数据转换和类型转换。

我们为什么要在现在讨论这些内容呢？原因是WinRT本身就是应用程序和操作系统其余部分之间的边界。编写高性能C++/CX应用程序的本质就是识别边界并在可能的情况下避免跨越边界。

如果跨越WinRT边界的操作无法避免，那么就寻找一些方式减少数据复制、类型转换和数据转换操作的数量。例如，如果数据源和目标都使用UTF-8编码，那么就没必要将数据转换为UTF-16，因为你最终还是需要将其再转换回来。

字符串

在大多数应用程序中字符串都是主要的数据类型。文件系统、Web服务、UI、消息、符文和契约等领域对字符串的依赖性日益加深。不幸的是人们所使用的字符串类型非常多。

在内部，大多数应用程序可能会使用std::wstring或者std::wchar_t*，你所依赖的大多数第三方类库也是如此。但是在与WinRT类库进行通信的时候你需要切换到Platform::String^。每一次转换都需要一次内存分配和一次数据复制操作。

String^和本地C++版本之间的一个关键区别是：String^是不可变的。WinRT运行时对不可变字符串的这种强调可能来自于.NET和CLR。正如^符号所表示的，String^也是引用计数。

人们可能会对可变和不可变字符串相关的优点争论一整天，但是最终只有一个事实。因为C++标准类库只理解可变字符串，而WinRT仅理解不可变字符串，所以对这两者你都必须进行处理。正如前面所提到的，这意味着需要对字符串进行复制。

类库作者：如果你正在构建一个一般用途的类库供他人使用，那么你应该考虑提供多个不同版本的API，为每种字符串类型提供一个API。这样你就不需要猜测API的使用者在调用类库的时候使用的是哪种字符串类型了。

很多基于字符串的操作实际上并不需要使用字符串，但是开发者宁可选择使用字符串迭代器。因为可变和不可变数据结构的迭代操作是一样的，你可以在使用常规xxx_iterator( begin(string), end(string), …)语法的字符串平台上直接创建STL样式的迭代器。

另外，首先要查找直接返回wchar_t*的API，而不是将它封装成一个wstring。如果你找到了这样的API，那么你就能够通过数组中第一个元素的地址以及数组的长度创建一个新的platform string。这样就不需要创建一个在匹配的platform string被创建之后立即就会被废弃的wstring。

调用带有字符串引用（StringReference ）类型输入参数的WinRT API时有一个小窍门。你可以向一个参数类型为platform string的WinRT函数传递一个wchar_t* 或者wstring参数，这种情况下将创建一个轻量级外观。无论如何，这里有一些需要注意的地方。

1. 字符串必须是空终止否则将会抛出一个错误。
2. 如果字符串在函数之外的任何地方发生了变化，那么结果将无法确定。
3. 如果函数之内有任何字符串的引用，那么无论如何都会生成一个完整副本。

上面的第1条内容很容易验证，第2条则仅会在碰见线程安全问题的时候发生。在大多数环境下这应该是一个非常有用的技巧。

类库作者：为了确保上面的方案是真实可能的，首先尽量避免让它引用你以StringReference参数的方式获取到的字符串。因为随后的引用并不会引入额外的复制，所以不要担心使用第二个引用。

集合

与C++中常见的集合相比，WinRT中的集合是非常昂贵的。和.NET中可观察的集合一样，对WinRT集合的每一次修改都会产生一个通知。该通知主要用于XAML数据绑定以便于更新UI。

在初始化期间避免这种损失的一种方式是，首先在堆栈上创建并填充一个标准的vector，然后使用move函数初始化一个platform vector。你能够这样做，因为标准的vector将会被销毁，同时它的动态内存无论如何都会被释放。

在更新很多元素的时候，考虑使用ReplaceAll方法。这仅会触发一个通知而不是每一条记录一个通知。在WPF和Silverlight中没有与之相对应的方法，因为这些UI堆栈本身不支持一次性插入或者移除多个条目。

WinRT集合中的另一种性能消耗来自于元素的读取。WinRT集合是以接口的形式暴露的，因此它们是虚的，这就意味着它们并不能像普通的函数那样被内联。此外，每一次读取都需要进行范围检查。所以如果你需要多次读取同一个值，考虑将它复制到一个局部变量中，不要每次都从集合中读取。实际上复制的缺点是，你必须复制值或者增加对象上的引用数，这是一个连锁操作。

完全避免这种消耗的一种方式是在迭代集合之前复制它。分配一个正确大小的局部vector，然后在ArrayReference上使用GetMany函数。然后结合使用ReplaceAll方法，你就能够对集合进行几次迭代，仅需要跨越WinRT边界三次就能够做一系列复杂的修改。

WinRT接口

和传统的COM一样，在WinRT中一个对象的成员仅会通过接口暴露。你永远都不可能直接访问对象。C++/CX通过做必要的隐式转换对你隐藏了这些细节。这样做之所以必要的一个常见原因是，可以满足调用非默认接口上的方法时的需要。

WinRT中的转换不是廉价的。它需要调用QueryInterface这个虚方法，同时有一个增加引用数的连锁操作。一旦完成了对非默认接口的调用，还需要另一个减少引用数的连锁操作。

类库作者：

确保类中所有的常用方法在默认接口上都是可用的，这样就不需要转换成另一个接口了。

如果要对同一个非默认接口进行多次调用，那么创建一个该接口类型的局部变量。这样仅需要执行一次转换，而不是每次方法调用时都做一次转换。

类

在任何可能的时候你都应该使用堆栈分配或者unique_ptr类。因为这样你将获得所有选项的最好性能。

在你确实需要一个复杂生命周期的时候，你的下一个选择是通过一个shared_ptr访问的普通C++类。这种方式和上面选项之间的主要区别在于引用数开销。

你选择的最后一种手段应该是ref类。一个ref类拥有和shared_ptr相似的引用数语义，但是能够带来其他基于WinRT的开销。所以仅在需要将类传递到一个WinRT函数或者在XAML的数据绑定中使用ref类。

在使用ref类的时候，尽量保持较浅的继承层次。WinRT继承和C++继承不一样，它有额外的开销。

XAML数据绑定

在WinRT+XAML数据绑定中你应该避免实现INotifyPropertyChanged，除非你确实希望在属性被填充之后发生改变。同样的，不要暴露公共set函数，除非UI确实需要修改数据。

XAML所调用的get函数应该是廉价的。不仅仅是因为它们是在UI线程上被调用的，还因为我们可能会调用它们多次。所以不要在get函数中分配内存或者执行昂贵的计算。

对于所有基于XAML的UI（WPF、Silverlight、WinRT+XAML）而言，一点非常重要的建议是保持较浅的数据层次。绑定表达式中的每一个点都代表了一次属性改变事件，而为了保持屏幕及时更新数据绑定引擎必须监听这些事件。

关于作者

Jonathan Allen 从2006年开始就一直在为InfoQ编写新闻，现在是.NET版块的首席编辑。如果你有兴趣为InfoQ撰写新闻或者教育性的文章，那么请联系他：[email protected].

查看英文原文：C++/CX Performance Pitfalls