上次写了浏览器渲染出网页的过程，想到了一些代码优化的小知识，当然了，我学识太浅，想到了还是太少了，所以这篇文章就长期更新啦。以后可能还有其他的框架如React等单独的代码优化的知识，毕竟这样的知识实在是太多了，一篇文章也会有些乱。
个人能力有限，文中可能会有很多错误之处，希望大家看到后可以在评论里指出来，一起进步，谢谢啦。
那下面开始正文。
操作DOM比较慢的原因
在浏览器中，DOM是属于渲染引擎的，JS是属于JS引擎的，JS来操作DOM，也就是两个引擎之间进行通信。
浏览器中，这个通信是需要通过接口来实现的，而每次使用这个接口就会产生一些性能的损耗。
async和defer的作用和区别
在引用JS的时候，会有三种使用方法，1. 直接使用；2. async加载；3. defer加载
在浏览器中会出行下面这样的区别

图画的不太好，见谅哈。
1. 直接使用
<script src = "script.js"></script>

在浏览器中遇到JS代码，就会阻塞HTML解析，进行JS的加载和执行，等执行结束后，再进行HTML解析，这样是最基本的使用方法，也是比较常见的。
2. async加载
<script async src = "script.js"></script>

异步加载执行，从图中我们可以看到，当浏览器遇到JS代码，就会再开一个线程，先去加载JS，等加载完之后，阻塞HTML解析，执行JS，执行完再回去解析HTML。
也就是说，这种方式，也会阻塞HTML的进行，但是时间可能是在HTML解析，也可能是在解析完成后进行。
3. defer
<script defer src = "script.js"></script>

延迟加载执行，在图中可以看到，当浏览器遇到JS代码，会另开一个线程，加载JS代码，加载完后不会立即执行JS，而会等整个文档解析完毕后，再执行JS代码。之后进行DOM加载。

至于到底使用async还是的defer就看具体要求了，但是这两个基本都会提升一定的性能。

回流（Reflow）和重绘（Repiont）
首先介绍一下这两个概念：


回流

浏览器根据浏览器可见区域的大小，将所有的“盒子模型”的大小，位置转换为实际的像素值。


重绘

当“盒子模型”的一些样式发生变化，这里样式指的是颜色，背景，前景等，不会引起盒子大小和位置的。会发生重绘。


回流一定重绘，但重绘一定会出现回流，回流在重绘之前进行
下面看一下什么时候发生回流和重绘

发生回流的时刻

添加或删除可见DOM元素（不包括display: none 的）
元素尺寸发生变化，包括margin, brder, padding, width, height等
位置发生变化
元素内容变化，包括input 框中输入文字
浏览器尺寸发生变化（这也是很多网站在我们改变浏览器宽度的时候会卡的原因）
设置style属性的值


发生重绘的时刻

基本都是CSS样式，颜色、边框样式、背景（包括改变背景图片、背景尺寸）、阴影等



代码优化的方法就是尽量减少回流，或者用重绘来替代回流

使用Transform替代Top等
使用visibility替代display: none
复杂的动画可以使用absolute ，可以让动画的对象脱离文档流，这样，只会让动画的元素产生回流，而页面其他元素不会受动画影响也产生回流。
GPU加速，这个就不介绍了，毕竟我也不会

大概就写这么多了，以后遇到了再补上
参考链接
你真的了解回流和重绘吗
深入浅出浏览器渲染原理

简介
本文介绍了进行Python代码优化需要遵循的基本原则，该原则也适用于其它语言的代码优化工作。
优化原则
不论最终的优化结果如何，代码优化工作总是有代价的。如果代码能够正常工作，却花了大量精力是其运行的更快，未必是一件值得尝试的有价值的事情。
进行代码优化，需要记住几条原则：
1) 确保代码能够正常工作之前不要考虑优化工作
应该避免在编写代码的同时，对其进行优化，这是程序员最常见的错误。因为实际情况是，对于复杂的系统，在你编写代码的时候，你并不能得到系统运行的完整视图，因此也无法确定当前的代码是否会成为系统性能的瓶颈。
但这并不意味着程序员不需要尝试编写运行更快的代码。这里强调的是首先保证程序能够正常的工作。在使代码能够正常工作并且进行代码的剖析之前，不要做代码优化工作，如用C/C++语言来对代码的一个部分进行扩展。
二八原则：1897年，意大利经济学家帕列托在对19世纪英国社会各阶层的财富和收益统计分析时发现：80%的社会财富集中在20%的人手里，而80%的人只拥有社会财富的20%，这就是“二八法则”。“二八法则”反应了一种不平衡性，但它却在社会、经济及生活中无处不在。在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的，因此又称二八定律。
对于代码优化工作，帕列托定律同样适用。影响性能的代码往往集中在少部分代码，过早的或不必要的性能优化，往往是项目和程序员的噩梦。
用Kent Beck的话来作为本小结的小结：
Optimization is carried out on programs that already work. 
“Make it work, then make it right, then make it fast.” 
2)  做必要的优化
优化工作是有成本的，开发团队需要对优化进行仔细的评估并认真地安排优化的优先级。做相关工作时，不妨问问自己下列的问题：

优化的要求是否来自真正的客户（对开发框架或程序库，开发人员也是客户）
程序真的运行很慢，还是处于可以接受的范围；是否有相关的度量数据，还是用户的直观体验
提升运行速度的成本（时间成本，财务成本，对现有版本稳定性的影响等）是多少？是否值得做？
具体程序的哪部分需要优化？

3) 代码优化不应该牺牲代码的可读性和可维护性
优化工作可能使代码变得混乱，并且牺牲代码的可读性。如果确实发生这种情况，首先评估当前优化是否已经满足性能的要求；如果确实需要进一步优化，需要考虑替代的方案，如扩展或重新设计。总之， 需要在生成易读且易维护的代码和运行速度之间找到一个平衡点。
参考资料
1. Expert Python Programming
2.80/20法则：http://wiki.mbalib.com/wiki/80/20%E6%B3%95%E5%88%99
 

VS-IDE代码优化：

属性->配置属性->C/C++->代码生成：启用增强指令集，可选用 流式处理 SIMD 扩展 2 (/arch:SSE2) (/arch:SSE2)、流式处理 SIMD 扩展 2 (/arch:SSE2) (/arch:SSE2) 进行加速浮点模型，可选用 快速 (/fp:fast) 进行浮点数据运算的加速



属性->配置属性->C/C++->优化：可选用 使速度最大化 (/O2) 进行优化。全程序优化选择是（/GL），在debug版本下不能这样设置，必须在release版本

 

Unity性能优化（一）-脚本代码优化

英文原文：https://unity3d.com/cn/learn/tutorials/topics/performance-optimization

脚本代码优化
托管代码和托管运行时简介
在Unity工程的 构建（Build） 过程中，C# 代码首先会被编译成 CIL(Common Intermediate Language)，进而根据工程的目标运行平台被编译成相应的 本地代码（Native Code）。
被编译成CIL的代码（即C#），称为 托管代码（Managed Code）。当托管代码被编译成本地代码时，它被集成到 托管运行时（Managed Runtime）。托管运行时将会处理自动内存管理和安全性检查等事项。
引起代码性能低下的原因

第一种可能的原因：代码结构欠佳。例如，重复调用无需多次执行的方法。
第二种可能的原因：调用其他代码引起的不必要开销。例如，托管代码和引擎代码（C++）之间不必要的调用。
第三种可能的原因：调用不需要调用的代码。例如，在玩家离敌人（AI）很远时调用模拟敌人视线的方法。
最后的可能的原因：代码过分严谨（过犹不及）。例如，对大量使用复杂AI的代理进行十分细致的模拟。

提升代码效率


减少循环的执行次数和循环中的指令数目。


将不需要频繁执行的方法从 Update() 中移出。


只在变化发生时才去执行代码。例如，不对未变化的量进行反复的输出。


将需要频繁执行且不能通过事件触发的方法改为每隔几帧执行一次。例如，记录帧数（Time.frameCount）并通过模运算跳过某些帧，通过该方式，也能做到让几个方法不在同一帧中执行。


使用缓存存储需要反复获取和使用的值。例如，将GetComponent()方法的返回值存储到变量中，避免反复获取。


根据需求选用正确的数据结构，尤其是在数据驱动的开发模式中。相关教程


使用对象池优化内存使用和降低CPU开销。创建和销毁对象的开销通常要比激活（SetActive(true)）和取消激活对象的开销更高，尤其是对于那些含有初始化内容的对象。相关教程


避免调用高开销的Unity API


SendMessage()和BroadcastMessage()。在了解项目结构的前提下，SendMessage()和BroadcastMessage()方法使用起来非常灵活而且容易实现，但它使用了反射，而反射会造成更多的CPU开销。在清楚要调用哪个组件的哪个方法时应该通过组件的引用直接调用方法；在不清楚具体要用的组件和方法时，考虑使用 事件 和 委托 替代。


Find()。Find()方法会遍历内存中的每个GameObject和组件，随着项目规模的扩张，它的开销将会越来越大。不要频繁的使用Find()和与其类似的方法，可以考虑在Inspector中设置对对象的引用，或者创建一个专门用于管理需要搜索的对象的引用的脚本。


Transform。设置position和rotation会触发内部的OnTransformChanged事件并传播到所有的子级对象中，对于含有非常对子物体的对象来说，这种操作开销很大，应该 减少对position和rotation的修改。如果某个方法中要分别设置position的xyz，可以创建一个Vector3然后分别将xyz设置到该Vector3中，最后将Vector3设置给position，而不要每次分开设置position的xyz。尝试使用localPosition替代position。localPosition存储在transform中，访问该值时，Unity会直接将其返回，而position在每次访问时都会重新计算，如果要经常获取position，可以将其缓存起来。


Update()。Update()和LateUpdate()等事件方法的每次调用都需要引擎代码与托管代码之间进行通信，还要Unity进行安全检查（GameObject状态是否合法等），即使这些事件方法的方法体是空的，引擎任然会对其进行调用。因此，为避免浪费CPU时间，应该 删除空的事件方法。另外，如果某个活动状态（gameObject.active == true）的GameObject上的脚本中含有Awake()方法，即使这个脚本没有被启用（enabled==false），Awake()方法也会执行。如果游戏中含有非常多的带有Update()方法的MonoBehavior，应该尝试改变代码结构来减少开销，这有一篇相关的博客。


Vector2和Vector3()。向量的数学运算要比普通的浮点数和整数的数学运算更加复杂，访问向量的某些属性可能会带来隐含的开销，例如magnitude属性（不仅针对向量，例如上文提到的Transform.position）。每次访问magnitude，引擎都会进行开平方运算，虽然单次计算并不会消耗多少时间， 但当数量级足够大时，这种开销将变得明显。可以尝试使用sqrMagnitude（即magnitude的平方）替代magnitude，减少开平方操作。


Camera.main。Camera.main所引起的问题与Find()方法类似，应该避免使用Camera.main并且手动管理对相机的引用。


其他Unity API调用和优化。


对象的某些成员看起来像是个变量，但其实它是个访问器（get，set），除了返回值，它其中还包含了额外的操作，例如数学计算、触发事件或在托管代码中调用引擎代码。上文中提到的Transform中的position、向量中的magnitude和Camera.main等都属于访问器，在编码过程中，应该注意经常访问的数据中是否含有访问器。

这里对Unity的性能优化进行了更多的指导。
仅在有需要时才去运行代码


视截体剔除（Frustum Culling）。仅在对象可见时才执行与其视觉效果相关的代码，可以通过 GetComponent<Renderer>().isVisible 得知对象是否可见，或者通过事件方法OnBecameInvisible()和OnBecameVisible()来修改对象变得可见/不可见时的代码执行方式。


细节层次（Level of Detail，LOD）。通过LOD技术，为离玩家近的对象渲染高精度的网格和贴图，为离玩家远的对象渲染低精度的网格和贴图。可以在代码中进行类似于LOD的优化，例如，只为离玩家近的AI进行高精度的模拟操作，而远处的AI则不进行复杂的模拟运算。CullingGroup手册介绍了更多关于如何使用LOD的内容。