简介: 一款 App 基于 mPaaS 小程序如何进行改造?

笑联 x mPaaS | 12 个模块,全面小程序化,如何打造真正的一次开发复用多端?_第1张图片

这篇故事围绕着一款 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,初期接入过程中遇到的问题大部分已经迎刃而解。

价值沉淀

经过一段时间的调试,最终我们成功实现 mPaaS 的接入。一鼓作气,现阶段 12 个核心业务模块已全部完成改造,以“小程序”的方式嵌入到 App 中。

引入 mPaaS 小程序,虽过程有坎坷,仍然要多谢 mPaaS 的技术同学及时答复与支持,最终一个个问题都得到了相应的解决。

笑联 x mPaaS | 12 个模块,全面小程序化,如何打造真正的一次开发复用多端?_第2张图片

但实际上“mPaaS 小程序”对我们的价值远不止于此。

首先,借助小程序的开发标准能够快速覆盖 Android/iOS 双端。小程序的语法并不算难,对于新手而言上手也很快,作为客户端同学目前可以干两个人的活(开玩笑)

从研发效率的提升角度来看,小程序技术栈的引入确实给我们带来了很多改善。作为客户端开发,不用疲于在需求的高频迭代中,给自己更多的时间去思考去沉淀客户端本身的移动中台能力,利用 mPaaS 小程序提供的自定义扩展机制,反哺给小程序来使用。

其次,mPaaS 小程序使用了 Web 能力来进行 UI 渲染加 JSCore 处理逻辑。在渲染逻辑上,和纯原生开发的页面相比还有一点点差距,但换来的是强大的动态性以及一端开发双端适配的研发效能提升。

另外 mPaaS 提供了独立的 UC 内核,小程序凭借独立内核,针对性的渲染优化,其性能相较 HTML5 已做了明显优化。还有即小程序的这套设计,其实渲染引擎可以无感替换,期待未来 mPaaS 可以结合 Flutter 的绘制引擎,带来高性能的小程序方案。

再者,基于小程序开发标准,我们有能力做到丰富笑联的生态。

笑联 App 中可以嵌入自身业务相关小程序,也可以开放其他第三方小程序接入笑联的功能。像笑联是面对高校市场,未来是不是可以结合 mPaaS 开放接口,将小程序开放能力提供给高校开发者,让更多高校开发者参与进来共建生态?

接入 mPaaS 至今,笑联开发团队对 mPaaS 极为肯定:

  • 站在开发者的角度来看,mPaaS 结构清晰,语法简洁明了,API 接口充足(还可以在客户端中自定义接口