雪球 Android 客户端通信重构实战

雪球 Android 客户端旧版通信重构实战

在众所周知，所谓通信Framework (Framework 也称作FrameWork ，即“Framework ”)就是通信组件的封装，它为业务的数据通信提供了基础支持，其重要性不言而喻。雪球上一个版本的Framework ，由于历史原因，已有数个年头未曾更新，由此也带来了诸多问题，比如：

• 业务接入复杂：业务层需要学习多门语言（协议相关语言、Framework 使用规范等）；
• 耗时巨大：业务接入往往需要耗时数周甚至数月，导致新业务难以快速上线；
• 稳定性堪忧：老旧代码缺陷较多，稳定性较差，经常出现莫名宕机情况；
• 可扩展性较差：随着业务日益复杂，老旧Framework 的扩展性已经难以满足需求，经常需要对其进行“缝缝补补”式的修改，这极大增加了开发和测试工作量，也为系统稳定性埋下了隐患。

针对以上种种问题，经过多方论证，我们Android 客户端团队决定对Framework 进行一次大规模重构，以期解决上述问题，打造一个高性能、易用性强、可扩展性好的Framework 。

此次Framework 重构，主要围绕以下几个方面进行：

1. 协议栈 ：摒弃原有复杂的私有协议栈，改为基于Protobuf 进行通信协议定义和解析；
2. 通信模型 ：将原有单向通信模型改为双向通信模型，简化业务接入，提高开发效率；
3. 通信组件 ：重写所有通信组件，包括网络层、RPC 层、Codec 层，大幅提升通信性能和稳定性；
4. 自动化测试 ：增加全面的自动化测试，保障Framework 稳定性。

1. 协议栈

原有Framework 使用的是一套复杂的私有协议栈，这给业务接入带来了极大的负担。业务人员需要学习多种语言（协议相关语言、Framework 使用规范等）才能进行业务接入，这极大增加了业务接入时间和成本。

此次重构中，我们摒弃了原有的私有协议栈，改为基于Protobuf 进行通信协议定义和解析。Protobuf 是一种跨语言、平台无关的协议编码格式，它使用IDL（Interface Definition Language） 语言来定义消息类型，并生成多种语言的代码。这极大简化了业务接入，业务人员只需要学习Protobuf 语言即可。

2. 通信模型

原有Framework 的通信模型是单向的，即服务端只能响应客户端的请求，而不能主动推送消息给客户端。这给业务的实现带来了诸多限制，比如：

• 无法实现实时推送：由于服务端不能主动推送消息，所以无法实现实时推送功能；
• 业务耦 Robust性高：由于服务端无法主动推送消息，所以业务需要不断向服务端发起请求来获取最新的数据，这增加了业务耦合性。

此次重构中，我们改变了通信模型，将原有的单向通信模型改为双向通信模型。在新的通信模型中，服务端可以主动推送消息给客户端，这极大提升了业务开发的灵活度和效率。

3. 通信组件

原有Framework 的通信组件存在诸多问题，包括：

• 网络层性能低下：网络层使用的是HttpClient ，性能较差，经常出现连接不稳定、超时重传等情况；
• RPC 层功能单一：RPC 层只支持单向通信，无法实现双向通信；
• Codec 层代码老旧：Codec 层代码老旧，稳定性较差，经常出现莫名宕机情况。

此次重构中，我们重写了所有通信组件，包括网络层、RPC 层、Codec 层。新的通信组件性能更强、功能更完善、稳定性更好。

4.自动化测试

原有Framework 没有全面的自动化测试，这给Framework 的稳定性带来了隐患。此次重构中，我们增加了全面的自动化测试，包括单元测试、Mock 测试、压力测试等。这极大保障了Framework 的稳定性。

5. 总结

经过数月的努力，Framework 重构终于圆满完成。新Framework 较于旧Framework ，在性能、易用性、可扩展性等方面都有了大幅提升。这将极大提升Android 客户端的开发效率和稳定性，为雪球业务的持续发展提供坚实的基础。

**</#description>