51信用卡Android架构演进：从组件化到动态化的探索与实践

51信用卡Android架构演进实践 随着51信用卡业务的快速发展，原有的单体工程开发模式逐渐无法适应日益增长的需求。为了解决这个问题，早在大约两年前，51信用卡管家开始实施架构改造，将通用功能组件和部分业务模块拆分成独立的SDK，形成了一个中型项目，支持多人并行开发，同时也为未来的组件化设计奠定了基础。 初期架构的优势在于降低了代码耦合，促进了模块化开发，然而随着时间的推移，出现了几个主要问题： 1. **主工程代码耦合严重**：随着业务需求的增加和开发团队扩大，代码之间的相互关联过于紧密，一个模块的改动可能影响全局，导致整体测试复杂度提高。 2. **业务模块聚焦不清**：主工程代码增多，编译时间变长，导致无法专注于单一业务模块的优化。 3. **依赖管理问题**：业务代码对App工程的依赖关系混乱，界限不明，导致类库管理困难。 4. **动态化需求**：随着业务灵活性的需求增强，使用Hybrid+H5方式处理动态页面加载的问题逐渐显现，速度慢且性能有限。 在面对这些问题时，51信用卡考虑了组件化和插件化两种动态化方案。组件化被视为一种平衡性能和动态性的解决方案，插件化框架如当时广泛流行，但由于其涉及hook framework、修改编译工具等非标准操作，维护成本高，且随着Android P限制了hook framework，插件化的吸引力逐渐减弱。 考虑到这些因素，51信用卡决定不急于采用插件化，而是先从业务组件拆分入手，同时关注React Native和Weex等大前端技术的发展。尽管大前端技术（如Weex）提供了更好的用户体验和灵活性，但在51信用卡的实际场景中，它们可能需要更多地权衡性能和工程复杂度。 最终，51信用卡的决策是保持谨慎态度，继续观察市场和技术趋势，同时根据自身业务需求和团队能力，逐步推进架构的优化和调整。这表明，公司在架构演进过程中注重的是长期的可持续性和适应性，而非盲目追求最新的技术潮流。