对于任何一个使用手机的人，有一样工具是不可能缺少的，它既不是微信之类的社交工具，也不是支付宝之类的金融工具(事实上这两个都越界了)，而是输入法这样的输入工具。更重要的是，输入法还是一种特权工具，因为它能够与其它任何可以接受信息录入的应用进行配合，帮助用户完成信息输入，这也就意味着，输入法有更多的机会接触到用户的个人信息和隐私信息。那么，作为一名手机使用者，你对手机输入法背后的运作机制了解吗？你有没有怀疑过输入法会在你不知情的情况下窃取你的个人信息呢？如果你是一位对输入法开发感兴趣的人，你是否想知道Android平台和iOS平台的输入法开发框架有何异同？作为一名输入法的开发者，我将结合我在两个平台上的输入法开发经验，告诉你，我的所见所得与所践所得。
输入法开发入门
两个平台的输入法框架有一定的相似性，根本上都是通过继承某个指定的类来实现输入法开发。Android平台上是InputMethodService，而iOS则是UIInputViewController。
在Android平台上，除了继承InputMethodService类，还要在AndroidManifest.xml文件中加入下列表明：
android:name=".MyService"
android:permission="android.permission.BIND_INPUT_METHOD">
android:name="android.view.im"
android:resource="@xml/method" />其中android:resource="@xml/method" ，意指在xml文件夹下有个method.xml文件，里面的内容应当是这样的：
<?xml version="1.0" encoding="utf-8"?>
android:settingsActivity="com.android.inputmethod.pinyin.SettingsActivity"/>其中SettingsActivity是输入法相对应的设置程序，以下称为主程序。
相比而言，iOS的入门还要更简单一些。这里有我此前写的一篇介绍iOS输入法开发入门的文章，虽然我使用的技术是Xamarin，但是流程是大同小异的：
与输入框如何交互
在Android平台下，我们是这样向输入框发送文本的：InputConnection ic = getCurrentInputConnection();
if (null != ic)
ic.commitText("hello world", 1);而在iOS下，则是TextDocumentProxy.InsertText("hello world");。
如果要向输入框发送一个删除命令，Android的做法是模仿删除键的按下操作：//调用该方法模仿删除键按下：
simulateKeyEventDownUp(KeyEvent.KEYCODE_DEL);
private void simulateKeyEventDownUp(int keyCode) {
InputConnection ic = getCurrentInputConnection();
if (null == ic)
return;
ic.sendKeyEvent(new KeyEvent(KeyEvent.ACTION_DOWN, keyCode));
ic.sendKeyEvent(new KeyEvent(KeyEvent.ACTION_UP, keyCode));
}而在iOS下，则是TextDocumentProxy.DeleteBackward();。
从这个角度看，iOS的API设计要简洁许多，但事实上，Android平台所提供的接口要远比iOS丰富，能做许多iOS下做不了的事情，比如选中输入框的文本，和更丰富的生命周期。
Android输入法服务的生命周期
UI上的异同
在Android平台下，创建键盘的界面与平常开发Activity相似：@Override
public View onCreateInputView() {
MyKeyboardView inputView =
(MyKeyboardView) getLayoutInflater().inflate(R.layout.input, null);
inputView.setOnKeyboardActionListener(this);
inputView.setKeyboard(mLatinKeyboard);
return mInputView;
}而iOS平台也与开发一般的iOS App类似：/*下述iOS平台的代码示例都是Xamarin下的C#实现，
本质上与swift或Object-C并无不同*/
public override void ViewDidLoad() {
try {
base.ViewDidLoad();
var v = getKeyBoardView();
View.AddSubview(v);
v.MakeConstraints(make => {
make.Height.EqualTo(new NSNumber(height));
make.Width.EqualTo(new NSNumber(width));
make.Edges.EqualTo(View);
});
} catch (Exception e) {
ErrorReporter.Report(e);
}
// Perform custom UI setup here
}但是呢，iOS下，输入法键盘的UI有一个限制，就是不用实现悬浮窗体，或者说，输入法的显示区间无法延展到host App上。而在Android平台上则没有这种限制；所以Android输入法的拼音栏可以悬浮在输入框的上面，而iOS输入法则不行。
其实，不允许越过键盘显示，我说忍也就忍了，我不能忍的是，为什么你他喵的系统键盘就可以这么做！！！
你说我该怎么办？当然是原谅她了，谁让她是苹果呢！
进程空间上的异同
一个输入法在结构上往往分成两个部分，一个是输入法键盘，一个是主程序。在Android平台的输入法中，他们分别对应一个Service和一个Activity，而且这两个对象是运行在同一个进程空间下的。而在iOS平台的输入法中，他们分别是一个App Extension和一个Containing App，他们是两个独立的程序，运行在不同的进程空间中。
运行在不同的进程空间意味着什么呢？假使某个类下定义了一个静态变量，在Android平台下Service和Activity访问到的都是同一个对象，而对于iOS平台则不然，他们读写的会是两个不同的对象，这也就意味着，iOS下输入法和主程序之间无法通过静态变量进行信息交流。
iOS输入法的基本结构图
文件空间上的异同
输入法与主程序之间不可避免的是要交换信息，甚至是读写文件，否则主程序也就起不到对输入法的设置作用。在Android平台下，这一点相对比较容易实现，因为输入法和主程序既然运行在相同的进程空间，那么他们也就必然共享同一个文件空间。
而iOS上则不同了，输入法和主程序之间不仅运行在不同的进程空间，他们还各拥有互相独立的文件空间，彼此都不能读取对方空间中的文件。注意，是都不能。
那么他们之间的文件交流共享如何实现呢？答案是App Groups。App Groups可以用于创造第三个文件空间，输入法键盘和主程序通过这个空间进行文件共享。他们的关系是这样的：
iOS平台下输入法与主程序的关系图
必须指出的是，主程序对App Groups中的文件拥有读写权限的，而输入法在“允许完全访问”没有打开之前，对App Groups只有读取权限，而没有写入权限。
这在客观上给开发者设置了许多困难，比如我要为岁寒输入法开发一个词条导入功能，首先我无法将文件直接共享到输入法键盘的文件空间下，而只能共享到主程序的文件空间下，再由主程序将文件复制到App Groups下，供输入法键盘进行访问。而由输入法键盘去将这个文件中的信息导入的其文件空间下的词库中是非常耗时的操作，会导致输入法卡死，因此我只能将导入的信息放在App Groups下的词库中，这存在一个小问题，就是在“允许完全访问”不开启的情况下，输入法键盘无法更新App Groups中的词频信息。
值得欣慰的是，这还只是众多困难中的一个。
权限管理上的异同
在Android平台上，输入法和主程序的权限声明是一体的，都放在AndroidManifest.xml文件下。
换言之，主程序可以访问网络，则输入法也可以访问网络；主程序可以读写SD卡，则输入法也可以读写SD卡；主程序可以访问通讯录，则输入法也可以访问通讯录；所以呢：
而在iOS平台上，主程序和输入法的权限相互独立，而且主程序：嗨，兄弟，我能访问图片库了！
输入法：。。。(关我屁事)
主程序：嗨，兄弟，我能访问通讯录了！
输入法：。。。(关我屁事)
主程序：嗨，兄弟，我能访问网络了！
输入法：。。。(关我屁事)
据我所知，在“允许完全访问”关闭的情况下，输入法几乎无法向主程序传递任何信息，哪怕是一个字。只有一种情况例外，那就是输入法通过Open Url调用主程序时，可以通过设置参数传递一些信息。
值得一提的是，“允许完全访问”机制确实给开发工作带来了极大的不便。一开始，我发现输入法甚至无法向App Groups写入数据时，我是极为不解的。我当时想，哪怕将输入法的权限细分也好呀，网络的归网络，存储的归存储。但仔细一想，不得不承认，只有一个“允许完全访问”开关的设计是正确的。因为如果只是授予了存储，输入法就可以向App Groups写入数据，主程序获得数据之后就可以通过网络将数据发送出去。也就是说，只要有一处授权，其它的权限限制就会变得毫无意义，变成只防君子，不防小人的假把式。于是，开则全开，闭则全闭，没有中间状态。
还有一点必须说到，就是iOS输入法是无论如何也获取不了录音权限的。当然了，你会说，系统输入法可以呀，你都知道那是系统输入法啦~据说现在讯飞输入法可以在输入法界面录音，我要告诉你的是，执行录音操作的一定不是输入法，而是另外一种服务，只不过讯飞的工程师使了障眼法，让用户误以为输入法可以录音而已。
到底哪个平台更安全
最后一个问题，那么到底哪个平台的输入法更加安全呢？
你可能会觉得，答案显而易见，果然是iOS啦。但我要说的是，这也分情况。iOS输入法只有在关闭“允许完全访问”才比Androis输入法安全，一旦打开，其实两者没差。所以，你觉得两个大佬的提醒都只是在给你开玩笑吗？其实他们的潜台词是，你可想好了啊，按了确定之后，出了啥事，你就自己兜着了哈。
事情到了这个层次就已然不是技术可以解决的问题了。惟一可以解决这个问题的方法是信任。
今时今日，我们每个人都在信息的海洋里裸泳，你相信我一直闭着眼睛，不去看你在水里的样子吗？
我是岁寒，感谢你使用岁寒输入法，感谢你的信任。
