在开发软件时,我们必须记住,我们的首要任务是满足客户的需求 - 即使我们的软件可用。性能往往是可用软件的关键因素。让我们看看我们如何在每个发展阶段考虑绩效,让我们的客户满意。(无论您是按照瀑布还是迭代开发风格,您都会经历这些阶段。)
在需求阶段了解您的用例和性能需求
头号规则是了解你的客户需要什么。客户需求将推动您需要担心的性能。您的首要任务应该是让您的客户满意,并提高效率,客户永远不会注意到,只需要花费时间从他们关心的功能。
典型的事情要考虑影响性能:
延迟要求 - 交易/框架需要多快?
每秒交易次数 - 您每秒钟得到多少次请求?
我们要存储多少数据?
我们可以容忍多少错误?
我们将如何衡量它?
如果你在制作游戏,你可能需要每秒60帧作为你的目标。在4K中,60 FPS对于一款重磅AAA游戏来说可能会很复杂,但是如果你正在制作一款没有很多复杂交互的PC的2D游戏,你不需要担心性能。
如果你使一个后端系统运行得不是很好,而且没有人在等待输出,那么可能没有理由使它非常有效。(成本可能是您可能担心的公平原因。)
如果你正在制作一个人类互动的网站或应用程序,你会希望它更快。
人类感到--1秒是瞬间的
超过1秒钟会干扰流量
10秒钟是保持人类注意力的极限
注意架构阶段的典型瓶颈
瓶颈是驱动性能问题的原因。瓶颈是系统中最慢的部分。不管其他事情多快,你都不能走得比你的瓶颈更快。
在规划新系统或功能的体系结构时,最有可能会看到与典型瓶颈相关的性能权衡。这些决定以后可能很难改变,因此早点考虑这些决定是很重要的。
典型的瓶颈(你可能有不同的):
对超大型数据库的查询效率低下
通过互联网呼叫外部系统(例如,AWS)
读/写磁盘
在3D游戏中渲染到屏幕
这是什么意思?我们需要构建我们的系统来解决这些瓶颈。
我们想要对我们如何组织我们的数据库以及我们使用的技术做出明智的决定
我们希望尽量减少对外部系统和磁盘的呼叫
我们希望在不同的线程中将渲染与计算分开(游戏引擎通常会为您处理)
高速缓存的形式可以帮助您处理一些瓶颈,但是您必须考虑如果缓存失败将会发生什么情况。依靠单独的缓存是危险的。
请记住使用这些用例来推动这些决策,这样您就不必浪费时间来决定无关紧要的事情,而是可以专注于解决客户需求。(如果我们不存储太多的数据并从客户的角度访问它,那么我们选择的数据库可能不太相关。)
编码阶段不要太担心
您可能想知道:“您提供的许多与可读性或可扩展性相关的建议都会牺牲性能,例如将代码分解为多个函数或使用多态性来获得可扩展性。”现在,计算机速度很快,编译器非常聪明,为你做优化。因此,您应该很少牺牲性能的可读性或可扩展性。能够快速而安全地理解你的代码并做出改变,而不用担心微不足道的性能收益,这是非常重要的。
担心诸如多态函数调用这样的小事通常是徒劳的。在需要担心使用多态函数之前,经常会遇到一个缓慢的算法或网络调用的瓶颈。在花费时间对这些小型预感进行预优化之前,请先看看编写代码后您的代码是否太慢。
这就是说,别傻了。如果使用正确的库,算法可能非常重要,而且通常很容易实现。如果您需要对大量对象进行排序,则应避免使用诸如选择排序等较慢的排序算法。这有助于了解算法的复杂性和不同类型的数据结构,可以帮助您生成高效的代码。散列是每个开发人员必须理解的东西,因为它经常是制定高效算法的关键。
在测试阶段的配置文件,如果你需要
如果你不符合你在要求阶段所规定的要求,现在是你修理它的机会。如果您确定自己的性能不佳,那么一定要运行一个分析器来查看性能瓶颈的位置。一旦你知道了,你可以把重点放在你能够迅速赢得大胜的地方。
分析器会告诉你你在哪里使用你的CPU.它可能会显示缓慢的算法或低效的内存使用。Unity有一个内置的分析器 供你在游戏开发中使用。
更多武汉IT培训相关资讯,请扫描下方二维码