search

YuanhuiQu / ibus-cloud-pinyin

Automatically exported from code.google.com/p/ibus-cloud-pinyin
GNU General Public License v3.0
1 stars 1 forks source link

一个建议 #41

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
  ibus-cloud-pinyin只是从服务端返回首个结果项，考虑到带宽、服务器负载的限制，这是有道理的。
  问题在于，这样做，使得ibus-cloud-pinyin依赖于整句输入，以获得更高的命中率，避免在本地词库中一一选词。然而，实际情况是，输入句子一部分，发现获取的结果是正确的，当专注于后部分的输入时，经常前面得到想要的“正确的结果”发生了改变。
  后果是，输入完大量文本，回过头来检测时，发现了很多错误，不得不一一修改；另一方面，即使输入句子时发现了问题，但要句子重新选词，由于本地端词库比较缺乏，可能是一个一个“选字”。这两种后果，都大大抵消了ibus-cloud-pinyin的云端优势，某些时候，输入效率甚至还不如本地词库丰富，以“词语”为单位进行输入的本地输入法。
  可以考虑，在输入句子时，对空格键功能进行转变，不是简单的录入当前输入部分，而是对句子已输入部分的锁定。同时，为了保持整句查询的优势，可以同时通过两个线程进行服务端查询：一个线程仅发送锁定后输入的拼音进行服务端查询；另一个线程将锁定部分文字的拼音和后续输入的拼音完整的都发送到服务端查询，同时将返回的结果和已锁定部分比较，如果锁定部分相同，那么将该线程结果作为正确结果。如果与锁定部分不同，那么，取第一个线程返回的结果作为正确结果。
  句子最终可以以标点结束，当然，也可以以回车结束。也可以用其他键完成上述空格键的锁定功能，空格键原来的功能保持不变。
  这样做，只是比之前多了一个线程进行查询，同时多了一次简单的字符串比较操作，应该不会太大地影响效率，但是，效率却会提高很多。
  当然，想当然耳。最终还是作者妥善考虑。

Original issue reported on code.google.com by nick198...@gmail.com on 26 Sep 2010 at 7:11

GoogleCodeExporter commented 8 years ago 
你说的“双线程”的方法的话会有一些得不偿失，因为多了��
�倍的请求，系统资源占用不说，用户会感到的延迟也会多一�
��，而且当 fallback 
到你说的“第一个线程”取得的结果，那时候就和直接按空��
�确认输入内容无异了。所以即便要实现这个功能的话，也是�
��比较低的优先级。

输入长句导致前面变化的情况和远程的 Web 
输入法具体是如何做得很有关系，个人觉得目前搜狗的效果��
�好一些，不妨禁用 QQ 引擎来试试看。

Original comment by arcpp.zju@gmail.com on 28 Sep 2010 at 3:54