关于递归和迭代两种方式的性能优劣以及相关心得

我们都知道，递归和迭代是写代码的时候的两种思路，下文介绍一下他们的性能以及各自的优缺点，以及两种思路的相互转化的心得。
递归的优点：

• 代码简洁
• 优秀的运行速度
• 以及代码简洁带来的程序的易维护性

递归的缺点：

• 函数的调用势必带来出栈入栈的操作，递归次数增多随之会带来的是内存的消耗增加
• 代码的过于简洁，会带来程序的理解问题而七拐八拐的函数调用也不利于代码理解

** 迭代的优点：**

• 相对递归来说较少的内存占用
• 优秀的执行速度
• 相对于递归来说其实更容易理解
  这一点指的是，相对于递归来说，迭代的代码执行流程相对来说更加的通俗易懂，迭代的代码不包含各种匪夷所思的函数调用，跳转和返回值所带来的困惑，程序流程较为通俗

** 迭代的缺点：**

-代码的过于依赖循环和判断等结构，势必导致代码的行数增加，随之而来的便是程序的难以理解，复杂晦涩。

记得有人说过，递归能做的，其实迭代都能做，而且有些情况下，迭代由于没有函数的入栈出栈，占用的内存要少于递归这个方式，但是同时并没有什么执行速度的差别，因此迭代是优于递归的我觉得这个说法其实不尽然。

我的理解是：递归相对于迭代，其实相当于内存的占用和代码复杂度的交换，解决问题时，更多的应该各取所需，是一个代码维护代价和运行时占用内存代价的权衡问题，有时不能因为要节省一些可以接受的内存代价，去写一个超级复杂的迭代过程代码，思路是个问题，如果思路不够清晰，可能写代码的速度可能堪忧，还有就是如果程序存在漏洞，并且你的测试用例不够全面，你也可能比较难发现，甚至一些经典递归思路的问题，如果强行使用迭代，写代码时思路可能会不可抑制的转向使用递归（别问我怎么知道的），迭代虽好可不要贪杯哦~，另外，如果可以预见的是代码执行过程使用递归要经过多次函数调用，这时使用递归便有些不值得，迭代的目标在于降快速的执行速度，递归的目标在于简洁的代码和不低的执行速度以及较少的额外内存开销。

递归思路和迭代思路的转换心得

我感觉最直观的是，迭代的视角是宏观的，写代码时，站在上帝视角，可以看见、使用全局的属性以及相应方法
递归的视角则是微观的，由于递归的特殊性要求我们将一个复杂问题拆分成一些重复“行为”能解决的简单问题，程序员只能看见当前小问题的解决方案，并试图去归纳一个，不断解决小问题从而解决拆分为小问题的大问题的通解。

递归的本质还是函数的入栈和出栈操作，递归思路转为迭代思路的时候，可以用一个可增长数组来模拟这个操作，使用循环来模拟递归过程中的函数调用，以及使用continue和break等关键字及时停止后续代码的执行（递归过程中遇到调用自身时会进入另一个函数，函数下方的代码暂时得不到执行的情况）重点在于弄清数据出栈入栈的时机，以及合适的过程中断

迭代方法转为递归则需要重视，复杂问题的拆分，一个复杂问题能否拆分为合适的小问题与递归代码的简洁度紧密相关，还有就是对递归过程的把握，关系到代码是否会如你所想的执行。

最后，为什么说迭代的视角是宏观的，而递归视角是微观的呢？
就像你从家去上学，迭代就是对着地图或者开导航，你就知道，前面那个路口，你需要左拐，左拐之后要右拐…
递归则是，你不管不顾往前走，然后走一段路程，抓个路人问一句，学校该往哪走，然后他只给你路，过一段路程又抓个路人，又问，反复这个过程
两种方法最终都能达到目的，区别在于，迭代时，你需要不断看着地图，对准方向以及相应地标建筑，递归时，你只需要学会，问路这个简单的操作，迭代时，你对于后续的路程心中有数，顺着预定好的路线最终一定能达到目标，而递归就是，你也不知道学校在哪，执行完路人给的提示你并不知道往哪里走，但是你知道，一直问路，只要路人没给你指错路，你最终也一定能达到目的。