代码优化的层次

前二周做了一个4X的项目可行性调研，就是要把一个系统的运行效率提高4倍。我把期间的一些思考整理了一下。先做一个假设，不讨论逆向工程，重点放在正向工程。先举个逆向工程的例子：测试反馈新开发的系统比较慢，于是用profiler诊断一下那个函数的耗时最长或者某个类的实例太多，然后有针对性地做优化调整。下面就开始讨论正向工程的程序优化。

代码优化

对关键路径中的代码，简化多重循环中的逻辑；对比较耗时或者高频的外部调用，选择更优化的调用方法。举两个栗子：A）如果你要把一个小图片拷贝到一个大图片中。码农都知道可以一个像素一个像素的复制，也可以一行一行的拷贝，当然一行一行的拷贝效果会高一些，当然代价是要事先计划好行偏移量。在代码里面表现出来的就是For-For-If的语句简化为For-For语句。B）用过open GL的同学都知道glDrawArrays支持TRIANGLES和TRIANGLES_STRIP和TRIANGLES_FAN，那么我在绘制一个矩形的时候，用STRIP或FAN就只用4个顶点就可表示，如果用TRIANGLES还需要6个顶点，当然代价是你事先要把对接口的参数有个全面的了解。代码优化的局部效果可以做到20%的提升，这种优化在代码中比较容易发现，也不必了解整体架构，但是提升效果不很明显。

逻辑优化

对于必不可少的的逻辑，去除不必要的计算和调用。举两个栗子：A）地图的移动场景，我发现地图移动后计算了3个metrix，但是这3个metrix的值都是一样的，也就是这3个metrix和地图的位置无关，那完全可以不去计算这3个metrix。B）计算地图视窗的边界会调用4次投影运算，但是每次投影运算中80%的计算是相同和而且和参数无关，那我就可以把4次运算合并后去掉重复的计算。逻辑优化的局部效果很容易达到50%的提升，但这种优化往往需要对跨模块的一个整体逻辑有全面的了解，对于高度模块分工的开发团队，这种优化是重点。

架构优化

对于必不可少的的计算，你放在哪里计算是最优化。举两个例子：A）地图中的元素都是在构建环节计算一部分，然后在绘制环节计算另外一部分，那么一个逻辑计算如果放在构建中就计算一次，但是放在绘制中每绘制一次就要计算一次，那么我们就要将没有依赖的计算全部放到构建环节是最优化的。B）同样是地图绘制的过程，CPU的计算是比较慢的GPU的技术是并非比较快的，那么我们就要把有依赖的部分放在CPU部分执行，把独立性强的计算放到GPU部分执行。架构优化得当可以做到80%以上的提升，但是这要求架构师的架构和接口设计能非常准确的传达到最一线的开发工程师，最好是有跨级的代码评审+2机制。

体验优化

对于必不可少的逻辑，评估对终端用户的体验的效果和效率，对于有负面效果的逻辑必须删除，同时寻求更高效率的逻辑去替换低效率的逻辑。每个码农都有这样的经历，按照PRD开发完成后自己体验整体的效果，你会发现不少PD我要我还要的逻辑的都是起副作用的，或者开销非常巨大同时有非常高效的可替换逻辑。这是软件开发工业化的必然产物，在这里我不展开这个话题。举一个例子：A）要在汉字显示的时候再上4个像素的晕，对于简单汉字“一”很美，对于普通汉字“中国”其实更模糊了。如果体验优化的提升比非常高，意味着产品、UED和开发的协作效率有待提升。

后记

其实一直到周五我做完内部的分享，都有一个疑问一直萦绕着我。为什么是四个层次？而不是三个或五个？直到晚上一个人洗澡的时候，终于找到一点线索。

原文配图  https://mp.weixin.qq.com/s?__biz=MzA3NTQ1MDM0MQ==&mid=2654978809&idx=1&sn=963d5d6dfbd38556a11f2c3d51d898af&chksm=84bb3073b3ccb965bb0951b8b0d1c02c47af30b550bf699698e1112262dc06dfb8c70ed7c6c0#rd