起因

事情是这样的。

4年前毕业那会，呆在公司的短视频项目，做视频。那会做得比抖音还早，但是由于短视频太烧钱了，项目被公司关掉了。当时需要开发横竖屏直播/异步视频的场景，就研究下了市场上的 app，发现输入弹幕的交互并不友好。最直接的体验就是，微信比绝大部分IM软件在聊天场景下输入法与表情面板频繁切换时表现得更为平滑，不会给用户很突兀的闪烁感。但我们除了适配竖屏，们还需要兼容横屏/满屏/沉浸等场景。

摸索了一段时间之后，做出来的效果挺不错，比市面上的直播/异步视频播放场景下的输入交互体验都要好。于是写了个记录的 Blog Android -SystemUI的那点事。主要是将如何设计横竖屏直/点播场景下良好的输入交互。但是文章并没有写完... 留了横屏模式下使用 PopupWindow 来实现的悬念... 本打算继续接着写第二篇。结果一拖，就是三年。

而在这三年里，前后参与开发了十多个项目（我们是流水线生产，老工具人），而涉及到输入交互的模块已经有IM聊天，直播间，异步视频播放页面，信息流评论等等。这些页面从最初使用 Activity 实现到演化成可用 Fragment，Dialog，PopupWindow 代替。所以原来那套技术实现已经不能满足。在寻找外部开源项目/技术博文无果的前提下，慢慢积累了一个库。也就是今想推荐的 PanelSwitchHelper，并且还了三年前博文的债。

PanelSwitchHelper 技术篇

网络上随便搜索 “聊天输入框跳闪” 就有大量讲述同个技术方案的博文，依靠动态更改 LinearLayout - weight 数值，随 Window 更改动态调整内容区域高度来做到不闪跳的效果。但是也是仅仅不闪跳，但是会有生硬的 “忽隐忽现” 的效果。PanelSwitchHelper 早期也是如此实现。微信前几年的体验也是如此，后来体验做得越来越好，过渡变得十分平滑，其方案应该不是这样做的（个人见解）。为了能做到这种平滑的效果，尝试在原来的技术进行优化，但是效果很不如意，因为这些缺陷是由技术选型决定的，所以开始寻找新的技术方案。

为了更好的讲述下面方案，我们把输入法和表情面板等都统称为功能面板。

实践了一段时间后，决定使用手动干预 Layout 逻辑并借助系统过渡动画来实现 “类微信” 的平滑过渡。

新的模式

我们称新的实现为 “内容滑动模式”，旧的实现为 “内容固定模式”。输入交互切换前后大概如下图。

蓝色区域为内容区域，比如聊天IM界面上，蓝色区域大多数为 Recyclerview 实现的聊天列表
绿色区域为面板区域，用于存储功能面板，比如微信的表情界面

在滑动模式下，图2是功能面板显示的结构图。也就是说，无论是输入法显示与否，蓝色区域相对于图一向上滑动了等量输入法高度的距离。当从输入法切换到其他功能面板（比如表情面板）时，如果原表情面板就已经显示在输入法底下，则可无缝的显露出来。

而上述的想法，需要干预到蓝色及绿色区域的 layout 逻辑。从滑动模式下的图一切换称图二时，其整体高度实际上不变，而 layout 的启始坐标是改变的，整体 Bound 也是发生了更改，借助 ChangeBounds 可实现平滑过渡。

实现之后效果大致如下。

使用也是非常简单。

new PanelSwitchHelper.Builder(this)
                    .addKeyboardStateListener {}
                    .addEditTextFocusChangeListener {}
                    .addViewClickListener {}
                    .addPanelChangeListener {}
                    .contentCanScrollOutside(true)
                    .logTrack(true)                  
                    .build()    
复制代码

为了追求更高的实时体验，我们还需要兼容用户可能随时调整输入法高度，随时显示/隐藏导航栏配置。