关于输入法的两个问题
转载时请注明出处：http://blog.csdn.net/absurd
前段时间和苏哲(SCIM的创始人)聊天，他得知我们采用SCIM作为手机的输入法时有些惊讶，因为SCIM在手机上使用还是第一次。我答应他把移植经验写出来和大家分享，现在输入法已经由另外一位同事负责了，尽管我了解其中部分内容，但没有亲历的经验，也不知够不够格去写，不过这是后话，暂且不管。今天帮同事解决了两个关于输入法的问题，这里做个笔记吧。
1. 手写时内存泄露的问题。笔迹的显示和记录是在DirectFB的窗口管理器里实现的。当处于手写状态时：它把笔迹直接显示到屏幕上，它有一个独立的surface，先把笔迹画在surface上，然后和窗口的surface迭加。它同时还会把笔迹数据上报给手写helper，笔迹数据是放在共享内存中的，提交给helper时只需要传递一个指针。
在DirectFB中，每个输入设备都有一个独立的线程负责处理，触摸屏也是一样。这些线程都是在master进程中运行的，它把输入事件dispatch到窗口管理器。我们手写功能是放在窗口管理中的，当然这也未必是个好方法，只是在这里拦截输入事件和显示笔迹都比较方便，效率也比较高。
同事说在手写时，master的内存使用量会狂飙，但是从代码来看，手写功能使用的内存都是初始化时分配的，中途没有显式的内存分配操作，所以一下查不出原因。这段代码的原型是我写的，这我清楚，也觉得奇怪。由于DirectFB使用了共享内存，valgrind无法运行(不知道大家有什么好办法没有？)，只好用最土的mtrace帮忙，mtrace提供的信息还是有些用处，很快知道是gAcquire里分配的内存泄露了，但不知道是谁调用它的。
在gAcquire设置了断点，发现是画笔迹时从dfb_gfxcard_drawlines调过来的，因为state->gfxs是空值，所以每次都会分配内存，而且没有哪里释放它。后来发现了原因，每次画笔迹时都调用了dfb_state_init去重置CardState的内容，这让state->gfxs变成了空值。我想起这是因为当时一个BUG：尽管在初始化时调过dfb_state_init，但若在画线时不调用dfb_state_init，程序就会莫名其妙的死掉，一直没找到问题的本质，于是就调了dfb_state_init把这个问题绕过去了。
我想今天一定找到问题的本质原因，如果再绕过去，只会把问题隐藏得更深。我发现每次画线时，如果不调用dfb_state_init，state->gfxs就是一个无效的指针。真笨，既然mtrace说state->gfxs泄露了，state->gfxs当然是从堆里分配出来的。原来，清屏操作是slave进程调用的，它为state->gfxs分配了内存。而master画直线时，使用的state->gfxs是指向是另外一个进程(slave)的地址空间，当然会出现问题了。
相关的数据结构(包括state本身)都是放在一块共享内存里的，当时没有想到state中的一个指针是指向堆内存的，压根儿都没有想到这一点，所以才让这个BUG隐藏了这么久。失败，失败。
2. 拼音和手写切换的问题。同事最近一直忙于编写输入法panel和helper的代码，SCIM自带的panel和helper都不适用于手机这样小屏幕的设备，所以这部分代码整个要重写。
全屏手写和区域手写是两个独立helper，考虑到两者的关联性，就把它们放在了一个共享库中，并且在同一个进程中执行。而拼音输入法的软键盘和候选字区，以及相关的符号键盘是在panel里运行的。手机的屏幕不像PC上那么大，显示空间有限，这些输入法不能同时出现在屏幕上，切换时要先隐藏掉先前的，再才显示要切换的新界面。
SCIM中所有的命令都是异步的，而且不关心命令的返回值，即把命令写入到socket之后，函数调用就返回了。这在一般情况工作都正常，但在切换输入法，我们遇到一个问题：比如从全屏手写切换到拼音输入法时，当通过trigger_property关闭了全屏手写，由于命令是异步的，调用者不知道关闭操作何时完成，若此时立即打开拼音输入法，会出现全屏手写的helper和拼音输入法的panel同时存在的情况。
把命令改为同步操作可以避免上述情况，但是要修改scim框架代码，这是我不愿意看到。为此和苏哲讨论了一会儿，最后得出的结论是：helper把自己关闭(隐藏)后，调用update_property向panel发送一个事件，panel在收到该事件后，再切换到拼音输入法，这样就不用修改框架代码了。
这个方法还没有来得及验证，从逻辑上来说应该是没有问题的。终于解决了这个难题，在此感谢苏哲。
~~end~~
