浅谈tableView内存优化行高问题

一、基本概念：tableView的cell在显示的过程是先计算行高，然后再返回cell到界面显示。tableView是继承自UIScrollView

设置行高有两种方式：一种通过tableView.rowHeight直接设置行高，这种方式的效率最高。但是返回的行高都是一样的，如果要求返回的行高不一样则需要第二种方式：通过实现代理方法动态返回每一行的行高。

   提示：如果表格高度是固定的，一定不要通过代理返回行高！可以直接设置属性！！

   表格 &
数据源执行的顺序 
     有预估行高
     1>
行数，知道多少行，根据预估行高(tableView.estimatedRowHeight)，计算整个
tableView 的预估 contentSize，
   保证能够滚动
     2>
数据源cell，获取要显示的 cell，会直接调用行高方法，返回当前行的高度
     3>
行高
     2.3会重复调用，一直到超出当前屏幕位置
         contentSize
会有一个变化，显示的行会用计算好的行高，没有显示的行，仍然用预估行高
         如果都滚动完成，contentSize
才是一个准确的值
         好处，提前计算的数据量小
         缺点，滚动过程中，临时计算行高，如果行高计算过于复杂，会影响性能！

       
没有预估行高
            1>
行数，知道有多少行
            2>
行高，计算每一行的行高，累加，就能够得到 contentSize
的 height
            3>
数据源cell，当 cell
显示的时候，整个 tableView
的 contentSize
已经计算完毕，能够保证快速滚动！
       
重点：UITableView
是继承自 UIScrollView，滚动依赖于 `contentSize`
        tableView.cellForRowAtIndexPath(indexPath)
通常是在表格的其他代理方法，例如：选中行中根据索引获取 cell
       
注意：调用的时候，cell一定已经被创建出来！因为在计算行高的时候，cell还没有被创建出来，所以不能使用此方法。一般使用

    tableView.dequeueReusableCellWithIdentifier("Cell")