
对于业务快速成长的中小型企业来说,移动应用开发面临巨大挑战。企业需适配 iOS、Android 和 Harmony Next 等多平台,传统原生开发模式导致开发成本高、迭代慢,对人力紧张的中小型团队几乎是难以承受之重。
开源地址:https://github.com/xtransferorg/xrn
同时,主流的跨端开发方案也存在三大痛点,一是对新兴平台的兼容性和维护保障不足,比如 RN 和 Flutter 就不支持 Harmony Next;二是开发效率与用户体验难平衡,Hybrid 方案虽能快速覆盖多端,但在性能和用户体验上有较大牺牲,难以满足中小型企业快速出海的需求;三是业务发展迅速,传统单应用开发模式难以支撑不同业务功能的快速迭代。
中国 B2B 外贸金融平台 XTransfer 在 2023 年开启国际化征程时,也曾遇到挑战。如何以有限开发资源快速构建并维护多个国际站点的移动应用,同时覆盖 iOS、安卓及鸿蒙系统?这一问题的答案最终凝聚为名为 XRN 的内部开发框架。
近日,XTransfer 宣布将这一经过两年业务验证的解决方案正式开源,为面临类似困境的中小型科技企业及技术团队提供新的移动端技术选择。
业务痛点催生技术创新
XTransfer 前端团队高级技术总监左磊在接受 InfoQ 采访时透露,公司最初只做大陆版 APP,也是 B2B 跨境支付行业内唯一一个 App。但随着 2023 年国际化战略的推进,前端团队需要快速开发全球版、不同国家版等多个应用。
左磊回忆,“当时我们只有一位原生开发工程师,不可能采用原生模式来开发;同时业务模式上要求不同国家版能在同一个 App 内做切换,根据企业的注册地提供千人千面的金融服务。”团队很快意识到,必须采用一个跨端框架,让 web 同学来开发业务,同时这个框架要支持拆包和动态下发,以便像堆积木一样自由组合业务模块。
基于这一需求,团队充分调研了业界现有方案,却发现并无好的解决方案。前端团队决定自研 XRN 框架,通过架构创新,将业务逻辑与平台特性解耦,实现用一份业务代码按模块拆包和动态组装,同时支撑多个站点和三端应用,从而高效支持业务的快速扩张。“相比传统开发模式,我们节省了约 70%的人力成本。”左磊补充道。
技术选型与架构设计
在技术选型上,XTransfer 前端团队经过多轮深入评估和可行性分析,最终放弃了 Flutter 和纯原生方案。“出于人力等投入的综合考虑,我们排除了对原生能力要求较高的方案,”左磊表示。同时,“由于 B2B 跨境金融业务的特殊性——用户主要集中在华为设备占比较高的外贸企业群体,我们还要考虑对纯血鸿蒙系统的兼容。”
更重要的是,基于国际化的业务背景,团队需要考虑在非洲、拉美等欠发达地区,网络条件不稳定,低端设备占比高,这对应用性能提出了苛刻要求。纯 Webview 方案虽然开发效率高,但性能和体验难以满足要求;而纯原生方案虽然性能优异,但开发成本过高,无法快速响应多地域扩展的需求。
最终,团队选择基于 React Native 0.72 进行深度二次开发,充分利用其新架构特性(JSI、Fabric、Turbo Module)提升性能。XRN 的核心创新在于容器层设计,彻底抹平了三端差异,使业务开发者无需关注底层平台细节。这个容器层不仅抽象了平台 API 差异,还实现了统一的生命周期管理和资源调度,为上层业务提供一致的开发体验。
那么,在自研该项目时,最难的环节是什么?
鸿蒙 NEXT 适配攻坚
左磊表示,“兼容鸿蒙 NEXT 成为项目中最具挑战性的任务”。
XTransfer 前端团队需要系统性地适配 57 个社区三方库和大量内部组件、工具链。“首先梳理所有依赖库,统一升级至鸿蒙要求的版本,”左磊介绍,“对于尚未兼容的库,我们通过鸿蒙原生 API 重新实现。”
在这个过程中,团队遇到了不少技术难题。例如鸿蒙 RN 缺少字符串本地化方法,团队通过原型链注入的方式解决:
此外,Hermes 引擎不支持 with 和 eval 语法,导致 formily 等三方库无法使用,最终通过 patch 方式修改源码解决。监控系统也面临挑战,Sentry Native SDK 在初始化后无法修改 DSN,团队创新地在不同 bundle 的 JS 侧初始化独立实例,却复用原生上报能力,既保证隔离性又确保数据完整性。
适配过程中最复杂的部分在于构建工具链和发布系统的改造。鸿蒙的构建体系与 Android 有着显著差异,团队需要重写大量的 Gradle 插件和构建脚本,同时保持与现有 CI/CD 流程的兼容性。发布系统也需要支持鸿蒙特有的应用签名和应用市场发布流程,这些工作都需要深入理解鸿蒙平台的特性。
微前端架构实现团队协作
为解决多团队协作问题,XRN 借鉴了 Web 端微前端思想,设计了一套完整的分布式开发体系。“我们将原生仓库作为基座,业务仓库作为子应用,"左磊描述道,"公共依赖收敛到基座打包为 common 包,各业务团队独立开发、测试和发布。”
这种架构带来了显著的协作优势,开发人员可通过端口映射在真机上调试特定业务,发布后不同 bundle 支持独立热更新,线上问题能够精准定位到具体业务模块。“实现了微应用级别的完全隔离,”左磊强调,“这对大型项目的可维护性至关重要。”
在实际落地过程中,XTransfer 前端团队建立了一套标准的协作流程。首先,基础架构团队负责维护原生基座,提供稳定的运行时环境和公共能力;其次,各业务团队基于统一的开发规范创建独立仓库,通过 XRN 提供的 CLI 工具快速初始化项目;最后,通过自动化的依赖管理和版本控制机制,确保各个子应用之间的兼容性。
用户体验与性能优化
保证三端体验一致性是另一个重点挑战。团队发现 RN 基础组件在不同平台表现不一致,如日历组件在各平台风格迥异。“我们自行设计统一 UI 样式和交互逻辑,”左磊表示,“在 JS 层抹平平台差异,对外提供一致 API。”
为了达到原生级的用户体验,团队投入大量精力优化渲染性能。特别是在列表滚动、动画效果等敏感场景下,通过预加载、内存优化、渲染管线调整等手段,显著提升流畅度。此外,还实现了平台特定的性能优化:在 iOS 上利用 Metal 加速图形渲染,在 Android 上优化内存管理,在鸿蒙上利用方舟编译器的优化能力。
热更新方案也经过精心设计,仅更新 JS 代码和资源,既兼容鸿蒙平台又符合苹果 App Store 审核政策。XTransfer 前端团队还实现了增量更新机制,通过差分算法减少更新包大小,在弱网环境下也能快速完成更新。这种设计确保了用户能够及时获得功能更新,同时避免应用商店重新审核的延迟。
开发体验与工具链建设
XRN 在开发体验方面做了大量改进,提供从创建到部署的全链路工具支持。开发阶段提供项目模板生成、一键调试、可视化调试面板等工具;调试阶段支持三端真机实时调试,能够快速定位平台差异问题;构建阶段提供多环境配置、自动打包、持续集成等能力。
需要强调的是,跨端调试工具 XRN-cli的研发突破。XTransfer 前端团队发现,无原生经验的开发者因跨端环境配置复杂、版本匹配困难,常面临调试效率低下的痛点。
为此,团队研发了 XRN-cli,通过标准化指令体系,工具可自动完成环境预安装、调试包精准匹配及一键调试,将跨端调试的前置准备流程高度自动化。上线后,无原生经验开发者的跨端调试前置准备时间从平均 8-16 小时缩短至 1-2 小时,显著提升了复杂跨端项目的开发效率。
在质量保障方面,XRN 集成了自动化测试框架,支持单元测试、集成测试和端到端测试。通过模拟三端环境,能够在开发早期发现兼容性问题。此外,还建立了完善的数据监控体系,实时收集线上性能数据和异常信息,为持续优化提供数据支撑。
开源战略与未来规划
选择开源这一决策背后有着深层次的考量。“我们凭借如此精简的团队规模,不仅成功支撑了业务发展,还做到了开源,这在国内同类企业中是不常见的。我们坚信,扎实的基础设施建设是业务迈向成功的关键基石。开源不仅为社区贡献了力量,更是一种对自身代码质量的严格约束,促使我们不断打磨和完善,进而形成良性循环。”左磊分享道,“过去,我们的技术团队曾在 Flink CDC 基础上通过 MongoDB Change Streams 特性实现了 Flink MongoDB CDC Connector,并贡献给了 Flink CDC 社区。这既是对社区的一大贡献,也极大地优化了我们内部的实时计算平台,这让我们对本次开源更有信心。”
他补充道,“可以这样说,如果按照常规标准,开发一个金融生产级 App 的 0.1 版本通常需要 20 人,那么借助 XRN,如今只需 5 人就能完成。如此一来,节省下来的人力就可以全身心地投入到业务创新中,而无需再为复杂的基建开发工作耗费精力。”
开源生态的建设已经纳入长期规划。XTransfer 前端团队计划建立完善的贡献者指南、行为准则和治理模型,确保社区健康发展的同时,也保证项目技术路线的连贯性。“社区的有价值反馈将融入内部版本,经过线上验证后同步回开源仓库,形成良性循环的发展模式。”左磊表示。
展望未来,团队将重点优化首屏加载性能,通过按页面拆包、资源预加载、渲染优化等手段,将加载时间缩短 50%以上。同时也在评估 Web 端兼容方案,计划通过编译时转换和运行时适配,实现同一套代码同时输出移动端和 Web 端应用。
XRN 在 9 月初正式开源,这个诞生于业务实践、经过复杂场景验证的框架,有望为移动开发领域带来新的思路和选择。
评论