这篇故事围绕着一款 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 投放小程序，更可疾速构建打包笼罩支付宝、淘宝、钉钉等利用。