UITableView的cell的释放、内容消失等的思考总结

   首先问题是在tableview的某个cell上面放了一个UITextField,然后textField填写的东西划出屏幕，再回来内容就消失了。后来知道是cell被替换（不是释放）了，然后又重新构建了一个textField，已经不是以前的那个，所以肯定是空的。不过这里倒是有个好玩的，就是如果你正在编辑某个textField，你把它划出屏幕，这个textfield所在的cell是不会释放的，内容也还在，不过这点倒是对整体没有帮助。关于UITableView会释放他的划出屏幕的cell，有几点总结：1、这个跟重用没关系，不知是从别人那里看来的还是我自己一开始就想错了，以为使用了UITableView的重用机制，它的cell才会在划出屏幕的时候被释放，其实不使用它也会释放。我的实验思路是在不使用重用的时候，添加一个__weak 修饰的UITableViewCell指针 成员变量，然后在tableViewCell构建的时候，让它指向某个cell，然后在cell构建之前输入它。

@interface ViewController (){
    __weak UITableViewCell* _testCell;
    
}

-(UITableViewCell*)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
    UITableViewCell* cell = nil;
    
    if (indexPath.row == 1) {
        NSLog(@"_testCell >>> %@",_testCell);
        if (_testCell != nil) {
            return _testCell;
        }
    }
    
    if (cell == nil) {
        cell = [[UITableViewCell alloc]initWithStyle:(UITableViewCellStyleDefault) reuseIdentifier:@"Cell"];
        UITextField* textField = [[UITextField alloc]initWithFrame:CGRectMake(10, 0, 100, 44)];
        textField.tag = 1000;
        textField.borderStyle = UITextBorderStyleRoundedRect;
        textField.text = @"XXX";
        
        [cell addSubview:textField];
    }
    
    if (indexPath.row == 1) {	//引用第2个cell，但弱引用不会干扰它原本的释放
        _testCell = cell;
    }
    return cell;
}

发现输入来不是空，且内存地址一致，说明这个被引用的cell时没有释放的。也就是说划出屏幕的cell是没有被释放的，但是cell里面的内容为什么更改的呢？是因为屏幕外的cell在进入屏幕内时，tableView会调用

-(UITableViewCell*)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

这个委托方法，然后我们会给它一个新的cell。就是tableview本身有一个，然后你又给了它一个，然后原来的就被挤掉了。所以这里的关键问题就变成了，在上面的这个委托方法里是否总是返回新构建的cell还是返回之前已有的cell的区别。

    为什么以前没有注意过这个问题？我自身的理解过程来看，在开始接触tableView的时候，都是使用它来承载label。因为label是不可编辑的，所以显示内容必定是有一个固定的数据源，比如一个装满NSString的数组，然后每构建一个cell就丢给它一个字符串显示，这时就算是使用了新的cell那也没有问题，因为内容总是会被再次加上去。而textField是编辑的，一般初始状态是不给它text赋值的，这样构建一个新的cell的时候它的内容就是空的，那么看起来就像是已编辑的内容消失了。所以label的性质让我一开始并没有发现这些问题。

   怎么让textField在划出屏幕后再回来内容还在呢？就是把原来的内容保存下来，再次调用

-(UITableViewCell*)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

的时候，把原来的东西丢回去。所以有3个层次：保存cell、保存cell上面的内容承载控件（UITextField、UIButton等），保存cell上面的内容（比如UITextField里面的文字）。具体操作就是：

（1）、保存cell:前面已经说了，cell其实没有被释放，是因为我们给了tableView一个新的cell替换掉了原来的，所以导致原来的内容没了。所以这里需要一个数组，把所有已经的cell保存进来，然后在每次需要cell的时候先从这个数组里面取，如果有就拿出来用。就像上面写的：

 if (indexPath.row == 1) {
        NSLog(@"_testCell >>> %@",_testCell);
        if (_testCell != nil) {		//如果不为空就直接返回这个cell
            return _testCell;
        }
    }

当然如果是数组保存，那么还需要给每个cell添加一个标识，以便从数组里面筛选出正确的。发现照着这个思路，直接就变成了UITableView的重用机制了，而cell的ReuseIdentifier不就是用来筛选的标识吗？虽然不知道UITableView本身的源码是怎么处理的，但我看过有些源码，有类似的重用机制，也都是把东西放进一个数组，然后有需要的就取出来重新使用。那为什么要自己构建一个数组来保存cell而不是直接使用系统的重用呢？因为系统的重用是同一个ReuseIdentifier的cell是通用的，比如你有3个cell是同样的布局，假设叫A、B、C，然后都有一个UITextField来填写内容，那么如果它们使用同样的ReuseIdentifier，那么需要A的时候系统可能会把C给你，那么就会乱套。自己构建数组，自己筛选、自己设定标识，那么每个cell都有自己独特的标志，该是它的时候就是它，绝对不会重。当然，这样就必须把所有的cell保存下来，内容上是不是会有隐患？我的理解是，一般需要进行输入的tableView都不会是很长的，不可能会有一个界面，需要用户自己手动输入100行信息吧？!

   还有一点，cell = [tableView cellForRowAtIndexPath:indexPath] 这样是取不到屏幕外的cell的，文档里说了、也试了，即使那个cell其实根本没释放。

  (2)保存承载内容的控件：这太累了，每次cell都建都要先判断这个控件是否存在，不存在构建，然后添加到cell上面，如果每个cell长得不一样，那么每个cell都得单独出来判断

（3）保存cell上的内容：就是在内容修改后，保存下来，然后在cell构建的时候，再把内容填回去。这个其实也挺累的，关键在于需要把内容实时的保存下来，比如textField，你必须要设置委托，在编辑结束时，及时的把他的内容存起来，否则下次textField构建，你给它什么东西呢？那假如这个tableview里还有UITextView,那又要设置UITextView的委托，还有button呢？假设每一种都有多个呢？还得区分开来，因为委托方法只有一个。