AndroidProject技术选型：为什么我们没有用Retrofit和RxJava
项目地址: https://gitcode.com/gh_mirrors/an/AndroidProject 在Android开发领域，Retrofit和RxJava无疑是两个备受推崇的框架，但AndroidProject技术中台却选择了不同的道路。本文将深入分析AndroidProject技术选型的决策过程，揭秘为什么这个备受关注的Android技术中台项目没有采用这两个流行的网络请求框架，而是选择了自主研发的道路。🤔
为什么选择放弃Retrofit？
功能封装不足
Retrofit虽然设计优雅，但在实际项目开发中经常遇到功能不足的问题。常用的功能如添加通用请求头和参数、请求和响应的日志打印、动态Host及多域名配置等，Retrofit都没有提供现成的解决方案，需要开发者自行实现。这直接增加了开发者的工作负担。
灵活性受限
Retrofit支持文件上传，但无法获取上传进度监听，只能获取到成功和失败的状态。虽然网上有一些通过拦截器包装RequestBody的解决方案，但实现过程十分麻烦。😓
学习成本过高
Retrofit的主要学习成本来源于其复杂的注解系统。开发者需要掌握@Url、@Body、@Field、@FieldMap、@FormUrlEncoded、@Header、@HeaderMap、@Headers、@HTTP、@Multipart、@Part、@PartMap、@Path、@Query、@QueryMap、@QueryName、@Streaming等众多注解。对于大多数开发者来说，往往只能记住最常用的几个。
RxJava的复杂性挑战
RxJava虽然功能强大，但在实际项目中的使用往往过于复杂。对于大多数中小型项目来说，RxJava的学习曲线和实际收益不成正比。
AndroidProject的解决方案：EasyHttp框架
经过半年多的精心设计和开发，AndroidProject团队推出了自主研发的EasyHttp网络请求框架。这个框架在功能性和灵活性之间找到了更好的平衡点。
开箱即用的功能特性
- 通用请求头和参数自动添加
- 完整的日志打印系统
- 动态Host及多域名配置支持
- 上传下载进度监听
- 生命周期自动管理
技术选型的深度思考
在技术选型过程中，AndroidProject团队进行了深入的思考：
- 实际需求分析：不是最流行的就是最适合的
- 维护成本考虑：简单易用的代码更容易长期维护
- 团队协作效率：降低团队学习成本，提升开发效率
为什么坚持自主研发？
更好的技术控制权
自主研发意味着对技术栈的完全控制，可以根据项目需求灵活调整和优化。
更贴近业务需求
EasyHttp框架专门针对AndroidProject的技术中台架构进行优化，确保与项目其他组件的无缝集成。
结语
AndroidProject的技术选型决策体现了对实际项目需求的深刻理解。不是盲目追随流行趋势，而是基于项目特点、团队能力和长期维护考虑，选择了最适合的技术路线。💪
在技术快速发展的今天，理性分析、独立思考比盲目从众更加重要。AndroidProject通过自主研发的EasyHttp框架，在保持功能强大的同时，大大降低了使用复杂度，为开发者提供了更好的开发体验。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
