http://www.cocoachina.com/ios/20160106/14889.html
检查项目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个字的限制条件下的问题)
所以我一开始以为,微信应该是这么实现的
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
- (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。
所以微信应该还用了这种方式
1
2
3
4
5
6
7
8
9
10
11
12
13
|
//微信
[_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,只需要加一行代码
1
2
3
4
5
6
7
8
9
10
|
- (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的实现(机智)
1
2
3
4
5
6
7
|
//yy
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
application.applicationSupportsShakeToEdit = NO;
return
YES;
}
|
喜马拉雅的实现(漏洞最多)
1
2
3
4
5
6
7
8
9
10
11
12
|
//喜马拉雅
- (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string
{
if
(range.location >= kMaxLength)
{
return
NO;
}
else
{
return
YES;
}
}
|
其实我觉得在用户的输入阶段就屏蔽掉某些可能的输入,真是一件吃力不讨好的事情。