iOS-NSUndoManager与怎样弄崩微信

96
cocoa
1.5 2015.12.23 19:47* 字数 931

检查项目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;
    }
}

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

日记本
Web note ad 1