一款App基于mPaaS小程序如何进行改造？

---

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

---

项目背景

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

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

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

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

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

接入过程

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

1. Android 接入初期使用 Inside 模式，适用于业务复杂的 App，尤其是多个业务模块并行开发、迭代且需要多人多团队协同。但由于框架中包含一些通用第三方 SDK（如支付宝支付、微信支付、微信分享等），因这些集成的第三方 SDK 自身版本过低或者功能不全，存在一定的解除依赖工作。
   后续 mPaaS 推出 AAR 原生接入模式后，由 Inside 升级至 AAR 在早期还需要技术同学的协助支持。

目前，mPaaS 已经实现针对 AAR 接入模式较好的支持：通过 mPaaS IDE 插件，可以简单地点击两下，便完成小程序能力的接入。而三方 SDK 的冲突，目前配备对应的详细文档说明。

1. 作为早期用户，尤其是不熟悉 mPaaS 技术体系全貌的情况下，初期遇到接入出错时日志查看不够方便，不利于研发团队快速定位问题。
   关于这块，我们也和 mPaaS 官方团队做了交流，目前已将「问题定位」和「排查」作为专项重点跟进治理，我们期待后续的产品使用及问题自排查可以得到较大的体验改善。
2. mPaaS 早期依赖的 Gradle 版本较低，笑联 App 在集成的时候由于 Gradle 版本的兼容问题，使得研发团队花费大量的时间定位编译失败的原因，后明确是低版本 Gradle 与其他第三方库的兼容性问题导致，如 ButterKnife。
   不过现在，mPaaS 已经完美适配了高版本 Gradle，初期接入过程中遇到的问题大部分已经迎刃而解。

价值沉淀

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

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

 

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

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

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

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

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

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

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

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

1. 站在开发者的角度来看，mPaaS 结构清晰，语法简洁明了，API 接口充足（还可以在客户端中自定义接口）。开发成本低、效率高发布简单，一套代码覆盖双端，不用去考虑复杂的适配问题，甚至无需顾虑打包、审核等繁琐流程。
2. 站在用户的角度来讲，小程序带来的“即开即用”体验，其效果几乎与原生相同。不用单独安装，客户端抛去小程序所实现的功能后，体积小，大大节省了用户的手机存储空间。
3. 站在公司角度来看，引入 mPaaS 后，我们已具备能力将 App 打造出生态。目前 App 扩展性非常高，将来有其他的业务，可以继续开发成小程序嵌入到 App 中，甚至在将来，还会像支付宝一样，可以把其他合作伙伴的小程序接入到我们的 App 中。

---

关于 mPaaS 小程序：源自于支付宝小程序框架，亿级线上业务体量的锤炼。安全性媲美支付宝原生能力，不仅面向自有 App 投放小程序，更可快速构建打包覆盖支付宝、淘宝、钉钉等应用。

原文链接

本文为云栖社区原创内容，未经允许不得转载。