iOS-NSUndoManager与怎样弄崩微信

序

检查项目bug的时候偶然发现，做过限制（比如说字数、表情）的textField、textView,触发限制条件后，会在使用undo功能时crash,之后发现微信也是一样的。
有朋友问在哪里崩了，不能复现，我举几个例子，其实有字数限制的输入框应该都有问题

我->个人信息->我的地址->新增地址

我->个人信息->名字

我->个人信息->个性签名

随便试了试qq、yy、简书、喜马拉雅的能输入汉字的输入框的字数限制，发现qq一般只提示不限制；yy禁用了undo；简书没做限制；做的最烂的是喜马拉雅，做了限制，但是可以轻松突破，输入任意长度的字符串。

DEMO

https://github.com/liulishuo/testUndo

思路

出现crash是因为，为了实现输入的过滤效果，会监听输入框的UIControlEventEditingChanged事件，截取字符串，手动给输入框的text属性赋值。正常情况下输入框执行setText：，默认不会注册到自己的undoManager上，并且会清空undoManger的undo、redo栈，这样并没有问题，问题是在于监听UIControlEventEditingChanged事件所执行的方法里是先对输入框的text做截取然后执行setText：。
看起来是截取的操作会入undo栈，之后的setText：方法并不会清空undo栈，导致做undo操作时，逆操作的是字符串截取的操作，操作的数据对不上，导致崩溃，这是我觉得比较合理的解释。

*** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSBigMutableString substringWithRange:]: Range {6, 4} out of bounds; string length 6'

以此为前提，我们有三个解决问题的方向：

• 禁用undo功能，绕过去，yy是这样做的。

• 使用setText:，每次在过滤操作时先将setText：注册到undoManager上，再进行setText：赋值操作。我试过不行。
  还是一样的错误-[NSBigMutableString substringWithRange:] range超限了，setText：的逆操作为啥也是这个，我不清楚。

• 使用setText:，并确保和系统默认行为一致，也就是用setText：赋值，并清空undo栈。
  个人觉得这样能达到目的，最方便。

实现

先说微信，微信的输入框特点是：
1.汉字联想的时的字符数也一样有限制
2.文本长度满了，输入框就不能从任意位置插入任何字符（可能是为了规避系统九宫格键盘输入汉字的问题）
（不太好归纳，我的地址的收货人输入框貌似有两套逻辑，一个是最大长度16个字，另外一个是最大长度50个字，我每次crash回来都会切换。。。，但是两套逻辑都有各自的问题，有兴趣的同学自己试一下，我们这里只讨论会crash的情况，也就是最大长度16个字的限制条件下的问题）
所以我一开始以为，微信应该是这么实现的

- (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string{     //退格    if([string isEqualToString:@""])    {        return YES;    }    //文本长度满不允许编辑 防止系统九宫格键盘在此时传入数字标号字符    if(textField.text.length >= kMaxLength)    {        return NO;    }    //非联想状态    if(!textField.markedTextRange)    {        NSString * tempString = [textField.text stringByReplacingCharactersInRange:range withString:string];        NSLog(@"%@",tempString);        if (tempString.length > kMaxLength)        {            textField.text = [tempString substringToIndex:kMaxLength];            return NO;        }    }    return YES;}

但是这样写不会因为undo而crash，并且还有汉字联想无限输入的bug。
所以微信应该还用了这种方式

//微信[_tf addTarget:self action:@selector(textFieldTextDidChanged:) forControlEvents:UIControlEventEditingChanged];- (void)textFieldTextDidChanged:(UITextField *)sender{    NSString * tempString = sender.text;    if (sender.markedTextRange == nil && tempString.length > kMaxLength)    {        sender.text = [tempString substringToIndex:kMaxLength];    }}

这种方式除了undo会crash，没有其他明显的漏洞。

修复这个bug，只需要加一行代码

- (void)textFieldTextDidChanged:(UITextField *)sender{    NSString * tempString = sender.text;    if (sender.markedTextRange == nil && tempString.length > kMaxLength)    {        sender.text = [tempString substringToIndex:kMaxLength];        [sender.undoManager removeAllActions];    }}

末

just for fun 我们来猜一下其他人的实现
yy的实现（机智）

//yy- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {     application.applicationSupportsShakeToEdit = NO;    return YES;}

喜马拉雅的实现（漏洞最多）

//喜马拉雅- (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string{    if(range.location >= kMaxLength)    {        return NO;    }    else    {        return YES;    }}

其实我觉得在用户的输入阶段就屏蔽掉某些可能的输入，真是一件吃力不讨好的事情。

文／cocoa（简书作者）
原文链接：http://www.jianshu.com/p/b302a7c66741/comments/1096790
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。