MvvmCross: IoC and ServiceLocation performance
本文关键字：ServiceLocation performance and IoC MvvmCross | 更新日期: 2023-09-27 18:17:36
我已经看了http://slodge.blogspot.co.uk/2013/06/ioc-and-servicelocation-in-v3-brain-dump.html关于" v3中的IoC和ServiceLocation "的文章。
那里一切都很清楚。但是，这种逻辑性能如何呢?通常反射用于这种类型的东西(我假设MvvmCross也这样做)。每个人(至少，或多或少有经验的开发人员)都知道反射是性能的"恶魔"。
所以，据我所知，框架通过应用程序中的所有类(可能，Core汇编只有)，并找到那些需要注入等，对吧?我相信这在小型项目中是可以的，但对于web项目(启动时间较长)这样的项目来说是不够的，但对于移动应用程序(通常具有更有限的处理器能力，启动时间对用户来说至关重要)又如何呢?你对此有什么想法吗?您如何评价"开发便利性"answers"首次性能降低"在这个意义上的关系?
谢谢。
一般回答
MvvmCross关于性能的理念是:
- 我们让开发更方便，这样开发者就可以做出更多令人愉快的应用
- 我们知道平台的某些部分确实增加了一定程度的开销，但我们已经努力确保它不是一个很大的开销
- 我们为开发人员提供了构建解耦视图、视图模型和组件的工具——我们认为这允许开发人员编写更高效、更健壮的组件
- ，因为我们允许开发人员构建解耦的组件，然后如果/当他们遇到性能问题，那么我们相信这使他们更能够优化，当他们需要。
- 因为我们提供了一个重用的平台，我们相信开发人员将更有能力开发和使用更好的组件——例如，因为开发人员可以重用我们的表/列表适配器，他们不必在每个应用程序中修复和优化新的表/列表适配器
- 我们努力确保几乎所有都可以在平台中被覆盖，这样你就可以在以后优化，如果你需要-如果你的应用程序想要手动调整IoC注册，它可以-你的应用程序不必使用反射。
- 我们认为。net(包括Microsoft和Mono版本)还有助于通过以下方式提高应用程序的性能:
- 高效内存管理
- 库，如linq和TPL
- TPL与编译器工具(如await/async )相结合
- 在需要时通过PInvoke提供本机访问
当然，如果你绝对需要达到200kB的包大小限制，你将无法使用MvvmCross;当然，即使使用世界上最好的工具，开发者仍然可以做出表现不佳的应用……但我们定位MvvmCross是为了帮助优秀的开发者制作令人愉快的跨平台应用。
技术分
有限的处理器功率
现代移动平台有:
- 2到8个CPU内核，每个内核运行在>1 ghz
- 1+GB快速内存
- 16+GB超高速存储(Flash)
这几乎不是限制 -它比10年前的pc更快，更强大。
每个人……知道反射是性能的"恶"
对不起，我不认为你是正确的。
和我一起工作的人都知道反射引入了一个小的开销，但它并没有主导我们的性能考虑。
我更同意Donald Knuth的话:
从http://en.wikipedia.org/wiki/Program_optimization"我们应该忘记小效率，说大约97%的时间:过早的优化是所有罪恶的根源"
这在有很多版本的应用/项目/产品中尤其如此——在紧密耦合的项目中，为v1创建的小优化通常会在你达到v10或v11时导致严重的性能问题，因为平台的变化会导致"旧代码"以"新模式"执行。
如果有人真的对微优化感兴趣，那么MvvmCross也值得注意，它使用了许多标记为虚拟的方法，许多小接口/对象和使用"{0}{1}"格式化字符串。类型模式——如果任何人真的想的话，所有这些都可以被优化。
好的。经过一番讨论，我想有必要总结一下。我认为答案是:
在常用应用程序开发中使用MvvmCross时，没有任何性能问题，然而，由于上面提到的在框架构建中使用技术，并且由于该框架的第一个目标是开发过程的便利性，因此应用程序结构增长可能会影响其性能 (而不是应用程序启动)。在这种情况下，可以使用自己的优化方法来覆盖一些逻辑来解决可能的问题。