起

亲爱的甲方在键盘的Container App里面做一个「学习模块」，想要就是在Container App里面让用户学习使用键盘的模式。这是基于我们 keyboard Extension 本身功能已经健全(绝对没有一丝的设计不合理，也不是因为输入法学习成本高，只是为某些 LowB 用户提供的智商扶贫计划 😉)。

基于这样的需求，我们不能简单给用户一个输入框，让用户自己切换输入法在那练练练，而是把键盘直接植入到应用程序画面中，用户进入画面中，我们的键盘就已经在画面中 stand by 了。

承

项目开始调查，我开始了植入方案的研究。项目会议时，我提出了几个方案：

1. 将现有的输入法代码加入容器 App 的编译，并在容器中以某种方式实现加载该输入法，并实现联动输入框
2. 在容器 App 中重新实现(Copy)一套输入法逻辑，就像普通的自定义轮子一样加载 View，并不与输入法的一套规则产生联系
3. 告诉客户：这个方案太贵了，原因如下。。。

方案选择：

方案 1

当然是最好的方案，优点是完全重用现有输入法逻辑，与现有产品在功能式样上保持高度一致，将来需求的变更可以同步反映，代码量少，大量的代码规模都可以用于业务逻辑 ✌️。但缺点也很明显：可行性未知，国内相关经验少，相关资料几乎为 0，仅在栈溢出论坛上有少量的有用信息。

方案 2

一个泥瓦匠刚刚学会砌墙，就希望拿手上这点手艺，修建高楼大厦，用这种无限使用于未来的方法，置换体内星辰河流。这个方法无疑是最体力活、最屌丝的方法：大量重复逻辑的编写，工匠之心囿于界面与接口；无法反映将来输入法需求变更的修改；随着项目规模扩大，它将难以维护。但就目前来说，它具有高可行性，能实现现阶段的客户需求。

方案 3

却下，客户说：有的是钱。

讨论的结果是，先前期调查方案 1的可行性，并尝试实现植入，如果可行，便上马，如若不行或短时间内不行，还有方案 2作为备胎方案，暂时放下你的破情怀，先面向需求编程再说。