4

我看过文章http://slodge.blogspot.co.uk/2013/06/ioc-and-servicelocation-in-v3-brain-dump.html关于“v3 中的 IoC 和 ServiceLocation”

那里一切都很清楚。但是，这种逻辑性能如何呢？通常反射用于此类类型的东西（我假设 MvvmCross 也这样做）。每个人（至少，或多或少有经验的开发人员）都知道反射是性能的“邪恶”。

因此，据我了解，该框架会遍历应用程序中的所有类（可能仅是 Core assemply）并找到需要注入的类等，对吗？我确信这在小型项目中是可以的，对于网络项目（启动时间很长）这样的项目也是不够的，但是移动应用程序呢（通常处理器能力有限，启动时间对用户来说至关重要） ? 你对此有什么想法吗？您如何评价“开发便利”与“首次性能降低”之间的关系”之间的关系？

谢谢你。

4

2 回答 2

19

一般回答

MvvmCross 关于性能的理念是：

  • 我们让开发更方便，让开发者可以做出更有趣的应用程序
  • 我们知道平台的某些部分确实会增加一定程度的开销 - 但我们已经努力确保它不是一个大的
  • 我们为开发人员提供了构建解耦视图、视图模型和组件的工具——我们认为这允许开发人员编写更高效、更健壮的组件
  • 因为我们允许开发人员构建解耦的组件，然后如果/当他们遇到性能问题，那么我们相信这使他们更有能力在他们需要的时间和地点进行优化。
  • 因为我们提供了一个可重用的平台，我们相信开发人员将更有能力开发和使用更好的组件 - 例如，因为开发人员可以重用我们的表格/列表适配器，他们不必在每个应用程序中修复和优化新的表格/列表适配器
  • 我们努力确保平台中的几乎所有内容都可以被覆盖，以便您以后可以在需要时进行优化 - 如果您的应用程序想要手动调整 IoC 注册它可以 - 您的应用程序不必使用反射。
  • 我们认为 .Net（Microsoft 和 Mono 版本）还有助于通过以下方式提高应用程序的性能：
    • 高效的内存管理
    • 像 linq 和 TPL 这样的库
    • TPL 与编译器工具（如 await/async）相结合
    • 在需要时通过 PInvoke 提供本机访问

当然，如果你绝对需要达到小于 200kB 的包大小限制，你将无法使用 MvvmCross；当然，即使使用世界上最好的工具，开发人员仍然可以制作性能不佳的应用程序……但我们将 MvvmCross 定位为帮助优秀的开发人员制作令人愉快的跨平台应用程序。

技术要点

有限的处理器能力

现代移动平台具有：

  • 2 到 8 个 CPU 内核，每个内核运行频率 > 1GHz
  • 1+GB 快速 RAM
  • 16+GB 非常快的存储空间（闪存）

这几乎没有限制——它比 10 年前的 PC 更快、更强大。

每个人......都知道反射是性能的“邪恶”

对不起 - 我不认为你是正确的。

与我一起工作的人都知道反射引入了一个小的开销，但它并没有支配我们的性能考虑。

我更同意Donald Knuth的说法：

“我们应该忘记小的效率，比如大约 97% 的时间：过早的优化是万恶之源”

来自http://en.wikipedia.org/wiki/Program_optimization

在具有许多版本的应用程序/项目/产品中尤其如此 - 在紧密耦合的项目中，为 v1 创建的小型优化通常会在您达到 v10 或 v11 时导致严重的性能问题，其中平台的更改会导致“旧代码”以“新模式”执行。

如果有人真的喜欢微优化，那么还值得注意的是，MvvmCross 使用了许多标记为虚拟的方法、许多小接口/对象以及使用“{0}{1}”类型模式的字符串格式——所有这些都可以如果有人真的想优化。

于 2013-06-07T15:59:33.893 回答
-4

好的。经过一番讨论，我想总结一下是有道理的。我认为答案是：

在通常的应用程序开发中使用 MvvmCross 时性能没有任何问题，但是由于框架构建中使用了上述技术，并且由于该框架的第一个目标是开发过程的便利性，应用程序结构有可能增长影响他们的表现（更确切地说是应用程序启动）。在这种情况下，可以使用自己的优化方法覆盖某些逻辑来解决可能的问题。

于 2013-06-26T15:30:33.477 回答