笑联 x mPaaS | 12 个模块，全面小程序化，如何打造真正的一次开发复用多端？

Z时代
2024-01-10
分类：技术分享

这篇故事围绕着一款 App 基于 mPaaS 小程序进行改造娓娓展开。
作为国内校园服务场景最丰富的平台，笑联 App 已覆盖国内 130 所高校，服务近百万高校学生。
截止目前，笑联 App 内的 12 个业务模块目前已顺利实现小程序化。不仅获得媲美原生应用的用户体验，同时有效规避“发版周期长”、“无法快速在线修复 Bug”等弊端，实现真正的动态发布与更新能力。

项目背景

开篇先做个自我介绍，笑联 App 目前已是国内提供校园服务场景最丰富的平台，目前已覆盖 130 所高校，服务近百万高校学生。

因我们提供的服务类型囊括洗衣机、热水器、淋浴等多项功能，业务模块多元化，并且需满足每所学校在服务类型、标准方面的个性化设计，笑联 App 长期堆叠业务模块，缺乏规范的模块化设计，导致代码愈发臃肿，开发效率低下。

与此同时，随着业务的持续扩张，任一需求的迭代均需要重新发版审核，很显然如此繁琐的发版工期已无法满足高频更新的业务需要。

我们急需在技术侧找到对应的解决思路，一方面简化业务模块之间的耦合，加速日常的开发速度；另一方面架构上需实现模块化，找到动态发布与更新的解决方式。

我们针对市面上已开放的技术选型做了调研，Flutter 和 mPaaS 理论上都可以满足我们当时的选型要求，但 mPaaS 小程序动态更新的能力跟我们业务需求相吻合，避免需要频繁更新整个 App。

接入过程

回顾 mPaaS 的接入过程，笑联作为早期用户，和 mPaaS 技术团队建立了深入合作的革命友谊：一方面对于 mPaaS 整体的技术体系有了更全面的了解，另一方面双方协作，针对“产品接入、功能丰富”做了很多改进工作。

Android 接入初期使用 Inside 模式，适用于业务复杂的 App，尤其是多个业务模块并行开发、迭代且需要多人多团队协同。
但由于框架中包含一些通用第三方 SDK（如支付宝支付、微信支付、微信分享等），因这些集成的第三方 SDK 自身版本过低或者功能不全，存在一定的解除依赖工作。
后续 mPaaS 推出 AAR 原生接入模式后，由 Inside 升级至 AAR 在早期还需要技术同学的协助支持。
目前，mPaaS 已经实现针对 AAR 接入模式较好的支持：通过 mPaaS IDE 插件，可以简单地点击两下，便完成小程序能力的接入。而三方 SDK 的冲突，目前配备对应的详细文档说明。

作为早期用户，尤其是不熟悉 mPaaS 技术体系全貌的情况下，初期遇到接入出错时日志查看不够方便，不利于研发团队快速定位问题。
关于这块，我们也和 mPaaS 官方团队做了交流，目前已将「问题定位」和「排查」作为专项重点跟进治理，我们期待后续的产品使用及问题自排查可以得到较大的体验改善。

mPaaS 早期依赖的 Gradle 版本较低，笑联 App 在集成的时候由于 Gradle 版本的兼容问题，使得研发团队花费大量的时间定位编译失败的原因，后明确是低版本 Gradle 与其他第三方库的兼容性问题导致，如 ButterKnife。
不过现在，mPaaS 已经完美适配了高版本 Gradle，初期接入过程中遇到的问题大部分已经迎刃而解。