动态输入法iOS版开发总结

写作时间:2016-02-14 22:13

动态输入法 iOS 版 v2.0.1 已经于昨天提交审核了，这个浩大的工程算是告一段落。为了那些心力憔悴的日日夜夜，留下一些回忆吧。

感谢我的老婆和女儿的支持，没有老婆辛苦的带女儿，没有女儿独自玩耍，我不会有足够的时间来完成这些工作。

开发历程：

2015年5月：启动。

2015年6月：注册了一个开发者账号。6月~8月间，出差1个月。

2015年9月2日：发布1.0版。

2015年9月17日：发布1.0.3版。更正若干BUG。

2015年10月25日：发布1.2版，使用了表格UI，添加了长按功能，添加了内支付，添加了按键提示。

2015年11月21日：发布1.3.1版，使用NSDictionary查找笔画，添加了快捷笔画，添加了字母颜文字键盘等。

2016年1月22日：发布1.3.2版，更正了键盘无法弹出的BUG。

2015年5月的一天，得知iOS 8开始支持第三方输入法，上网查了查，发现有教程，于是就试着做一下。正好也是老婆有MAC电脑。开发iOS APP 需要用Xcode，教程语言是SWIFT。兴奋的去ZBB买了本SWIFT的书。其实这本书没有太多的用处，大部分的问题都是网络解决。有书的唯一好处就是，有时候可以在手边应急。

在1.0版发布之前，主要的工作在于：（1）最早的问题在于，怎么设计键盘按键，按键的排列都是依靠Constraints来限定的，需要自己编排。而在Android，这些都不用管，只要在xml文件里填写按键上的字符就可以生成键盘了。教程代码里的按键约束是循环引用的，不好，我改成了根据按键数量来计算尺寸。这里涉及的都是UI的问题，例如，按键上的文字，怎么改颜色，字体，背景色，边框等等。在Container的UI上，控件的位置经常错乱，是一个很大的困扰，默认的UI不能VScrow，总之克服了很多困难做出一个简单的UI。（2）然后，要解决按键的滑动、长按、滑动和长按。iOS的机制和Android完全不同。在Android里，只有 onPress 和 onLongPress，为了判断按键的滑动，可费了不少脑筋。在iOS里，判断按键滑动很简单，只要在保持按键按下而没有抬起的过程中加一个计数器就可以了，而判断按键的长按，比较复杂，需要为父视图添加一个长按的observer，还要自定义长按触发时间，默认为0.8秒好像。Android里的长按没有设置触发时间的方法。长按的功能直到10月才完成。（3）AES加密和解密：在CSDN找到了示例代码，并且可用，不过是ObjectC的，需要加入一个bridge文件桥接OC和SWIFT。（4）代码的移植：把主要的算法从java转写为SWIFT，并尽量保持与java相同的结构。SWIFT对字符串缺乏很多常用的方法，例如取子串，替换等等，都需要自己写。其中，String类型有From(to end)和(from start)To两种方法，但是取中段还是要自己实现，不太方便效率也不高。（5）软件参数设置：这是一个大坑，很久才爬出来。原本，iOS在设置、通用、键盘里，为第三方输入法保留了一个参数设置界面，然而怎么都不起作用，许久之后才在stackoverflow查到，这是iOS的一个BUG。然后，考虑把参数放置在Container的设置里面，但是这里参数的改变，不能通知Container，还得让Container设置一个监听，太麻烦了。最后只好吧设置参数放置到Container的UI上。传递参数的原理是，Container和Extension共享一个AppGroup，类型还是NSUserDefault，在Container里设置保存的参数，Extension立马就能知道，很简便。（6）为APP编写使用帮助，这里的帮助非常详细，为此又深入研究了一遍笔顺的规律，这部分内容都作为文本放置在Container的设置里面。（7）iOS的速度比不上普通的Android手机，在Android里，可以即时地把12笔画简化为5笔画，在iOS里太慢了，于是单独制作了带5笔画的码表。（8）真机调试，按照百度经验上的步骤配置开发者账户，也是很麻烦的。（9）补充：最初的文件读取也是一个起点，iOS支持UTF-8，Windows下处理的码表格式为Unicode即UTF-16，代码转换要留心。（10）横屏竖屏的判断，以及键盘高度，不管怎么设置键盘高度，在弹出时总是要闪一下原始尺寸，百试不得其解，后来才发现百度，搜狗皆然，是iOS的BUG。

1.0.3版的主要工作是，在使用中发现了若干字的笔画有误。对汉字笔画表又进行了详查，又更正了几十个字的笔画。

1.2版的主要工作是，（1）经过与用户的初步的沟通，了解到一般人不习惯我的按键布局，于是增加了自定义布局，由于设置参数的增加，原先的UI不便于扩展，于是整个更改为TableView，并扩展为多页面结构，对TableCell可以像按钮一样添加响应函数，实现了一些功能。（2）添加了内支付功能，这也是找的示例代码，经过艰苦的调试，凑效了。（3）添加按键提示，这是一个子视图，在iOS中创建视图非常的简便，而在Android中十分的繁琐，要专门写一个类。为了这个按键提示，动用PS制作了12种笔画的典型笔形图片。按键提示也有创新点，能提示4种按键操作。（4）增加了长按输入数字的功能。

1.3.1版的主要工作是：（1）采用java的算法匹配连笔键，效率十分低，为此使用了NSPredicate的方法，把所有的笔画匹配算法替代了，并且对数据类型也做了更改，原先是若干独立的String数组，为了能用NSPredicate，新建了一个cnChara的类，匹配到笔画后同时获得其字频等信息，此外还有valueForKey过滤，总之是尽量利用固有的方法避免自己编写低效率的循环。（2）数据持久化方法的改动，原先是每次弹出键盘后，读取加密的码表，然后解密，造成运算量大，键盘显示迟缓，为此，采用了归档的方法，第一次解密后存档，以后再弹出键盘直接解档即可。如果归档自带数据类型，数据是透明的，因此必须归档自定义类型，因此又新建了cnDict的类，其中有一些encode,decode的方法。（3）增加了字母键盘、希腊文、俄文、注音字母、假名、常用符号、颜文字等键盘，并支持自定义键盘。自定义数据可以在Container里设置。（4）为APP制作了精美的视频、图片。（5）更新了字频信息。在网上找到若干版本的字频表，但还是有不合常理的地方。

1.3.1版本在12月初提交，由于一个简单的错误，在UI上显示了版本号，被退回，于是快速更正再次提交，顺利赶在了圣诞节前上线。仓促上线，没有经过iPhone6的真机调试，只经过了iPadmini2的测试，结果在上线后，发现在iPhone6上不能弹出键盘。这是一个重大的BUG，可能是这个原因导致了下载量下降。问题发现后，一度以为是iOS版本问题，直到1月初，有用户反映无法使用，才引起重视。经过一番排故，发现是归档造成的错误。这个错误至今没有找到根本原因，只是采取措施回避了。可能是归档数据量大？问题是归档数据中必须有一个空成员变量才行。更正后的版本1.3.2版于1月底上线。

随后，又展开了对词语预测和分词的攻坚战。（1）实现了对分词符号的按键处理，包括插入、显示、删除等等，为处理词库提供操作框架。（2）对词语的预测，采用即时计算下一个字的列表的算法，实际上很顺利，在1月底实现了。（3）分词，这是一个异常摧心的算法，经过几天的突击，也在春节前实现了，主要的问题在于：减少载入数据量，把词库分成了25个；处理删除键；使用正则表达式过滤词库。（4）算法的优化：春节后，经过iPhone6真机调试，发现弹出键盘时崩溃，于是又突击2天解决了问题。原因有很多，集中在readStrokeTable函数中，主要问题有：频繁同步AppGroup共享，单个共享文件太大，归档时崩溃等等。解决措施为：优化了共享数据的结构，最大限度减少弹出键盘时的运算量；把词库分割存储，并且在弹出键盘时不读词库，只有在打字时即时读取，竟然也不影响速度。这是因为，如果在弹出键盘时读取，需要保留所有9万多条词汇，严重占用内存导致崩溃，而在打字时读取，则立即使用前一个字过滤，仅剩下很少的条数，其余的丢弃了。经过优化之后，弹出键盘加速了，词语预测和分词功能都不受影响。（5）对Sqlite3进行了研究，也找到了示例代码，不过难以操作，因为只在Extension里处理数据库是不可能的，仍然需要把db.data保存在AppGroup中，和之前的方法没有本质区别，于是放弃了。目前的算法，处理约10万条词汇，可能已经达到了极限，如果后续还要扩充词汇量，可能还需要更高级的工具。

总的来说，用到了以下比较高级的工具：

（1）AES 加密解密；

（2）APP 内支付模块；

（3）NSPredicate过滤，valeForKey过滤，正则表达式的运用；

（4）数据持久化：AppGoup，归档，解档。