技术选型从 HTML5 到小程序，走过逐步熟悉产品的阶段后，即可获得飞升的研发效能和流畅体验。

瞰聆信息科技有限公司是一家专注移动医疗的公司，聚焦于采用移动化的技术手段实现医疗高效协作和精细化敏捷管理。业务服务结合国内医院的实际情况进行创新，致力于构建国内细分领域最先进的产品和解决方案。

「南京儿医在线」是瞰聆科技为南京儿童医院开发的官方就医 App，支持线上线下一体化就医体验。本文介绍了其如何通过接入 mPaaS 小程序从而提升应用体验性能的故事。

项目背景

瞰聆成立以来，业务大多集中在移动端对外开放。而在 App 发展初期，我们所服务的受众人群以 B 端医生为主，考虑到医院端业务量大、场景丰富、产品线广，同时项目需要支持“微信公众号”及“支付宝公众号”。

因此我们采用了「原生 App 作为容器 + HTML5」的技术选型支撑业务开发：App 提供统一的用户认证体系，在线加载 HTML5 页面，并对 HTML5 提供相应的 JSSDK。由此，医疗相关的业务我们基本统一使用 HTML5 开发，期望做到一端开发，两端适配。

然而，跑了一段时间之后，我们发现纯 HTML5 开发的方式，性能体验问题较大。比如，HTML5 页面在用户手机上经常出现打不开、一直加载中、卡顿等问题。

当然，面向 toB 类的业务还好，医生用户群的体量相对可控，能够针对性优化解决性能问题。但一旦业务面向 toC，如若我们的 App 持续出现性能问题，随之而来的就是不可控的患者投诉和差评，既影响用户体验，也对公司的品牌有所伤害。

评估“南京儿医在线”App 的用户体量将持续增长，我们决定不再忍受纯 HTML5 开发的模式，重新改造 App，势必输出一款能够满足消费级市场要求的应用。

接触 mPaaS 之前，实际上我们也尝试过其他跨平台的解决方案，如 Cordova、Uni-App、Flutter，甚至还有个人开发者输出的微信小程序框架 Hera。测试了一段时间之后：

• Cordova 的性能无法满足要求，兼容性也有不少问题；
• Uni-App 倾向于纯 HTML5 开发模式，评估后不太适合与原生 App 结合；
• Flutter 现阶段生态还有待完善，且对应的学习成本较高，不适合我们团队。

最终我们把目光投向了小程序。

小程序针对浏览器内核进行了优化，分离渲染和逻辑执行引擎，再加上对渲染层做了一些优化。除了首次下载需要花一些时间，之后的体验已经非常接近原生应用。虽然个人开发者的 Hera 框架也提供了我们一些思路，但由于后续开发扩展的东西太多，如扩展 API、HTML5 端 SDK、离线下载策略、渲染优化……很显然，短时间内我们无法完成。

接入 mPaaS 过程回顾

经过一系列调研之后，我们发现 mPaaS 小程序与我们当前的需求不谋而合，同时也已沉淀了很多大客户案例。于是我们决定接入测试 mPaaS，通过 mPaaS 小程序来提升 App 性能体验。

当然，在对接测试过程中，我们确实也踩了不少坑，借助 mPaaS 技术团队的支持，问题逐一得到解决。而对我们而言，实际上是逐步熟悉产品、积累经验的过程。下面列举一些有代表性的问题，供大家参考：

1.初期对接阶段，安卓端遇到加载在线 HTML5/小程序报【网络不给力，请稍后再试】的问题。调试下来发现有个 RPC 请求报 7001，验签未通过。最后提了工单，开发同学提示需求将安装包上传至 mPaaS 控制台，并下载新的配置文件 ‘Ant-mpaas-xxxxx.config’，覆盖原来的配置文件。（实际上是我们需要将安装包的签名做更新，修改其中 ‘base64’ 字段内容）
这个问题反映出由于我们前期没有熟读文档，对问题的判断以及解决思路不够清晰，由此走了很多弯路。因此，开发者一定要通读文档，了解接入流程，从而能够更好地提升接入效率。

2.离线包实时更新。mPaaS 离线包默认每隔 30 分钟自动更新。但我们偶有紧急业务调整或者 Bug 需快速修复，希望用户打开的时候就能加载最新的包。
基于这个需求，我们自主实现了一个实时更新机制。
大致思路是启动的时候即刻检测是否有离线包更新，如果有，便请求下载，然后重新渲染页面。（当然这种机制相对消耗流量，也并非常规做法，我们仍在持续优化中。）如果对实现方法感兴趣，大家可以参考我同事的这篇文章：《mPaaS 集成：基于内嵌 View 形式优化首页更新》

3.键盘样式问题。fixed 定位中的输入框弹出的键盘会把输入框顶上去，而输入框内容保持不动（如下图所示）
经过排查后，核心原因在于一开始我们没有获取键盘的展开缩起（高度变化）的状态，对应的解决方案即通过配置属性即可：enableNative="false"

（原本应该在体重输入框的，键盘弹起后，跑到了下面输入框）

4.接口仅支持 GET、POST 请求。原因是由于支付宝小程序限制。
目前我们采取的方式是后台接口添加 GET/POST 支持，比如 PATCH/USER，用 POST 便变成 POST/USER/PATCH。
当然，还有个办法是 App 提供 JSAPI，网络通信交给 App 来做，前端调用 JSAPI 来实现。

5.iOS 端小程序标题不显示。这个问题从接入开始，持续到项目近上线最终被解决，具体表现是 iOS 端小程序不显示默认标题，小程序手动调用 ‘my.setNavigationBar’ 设置的方可显示。期间我们尝试了很多方案，虽然定位问题在客户端，但始终没有找到问题。
最终通过 mPaaS 开发同学发现其中一个叫 SSZipArchive 的 pod 库，影响了框架的执行，删掉了这个引用解决了问题。

6.关于依赖库冲突/报错问题。
建议大家可以根据 mPaaS 官方文档，尽量使用 mPaaS 自身的依赖，挨个排查替换即可。

7.多个小程序之间跳转问题。在实际需求中，有小程序跳 HTML5 再跳小程序等需求。而后我们发现 App 端只能同时存在一个小程序，无法实现小程序互跳。具体表现即，跳转小程序之前必须关掉当前小程序，否则跳转无效。
后来通过提工单，并通过对比文档发现，有一个参数设置可以实现多个小程序互跳：在创建小程序的时候通过 startTinyAppWithId 方法传入启动参数即可实现：@{@"startMultApp":@"YES",@"appClearTop":@NO}

全新的开发体验

借助 mPaaS 开发同学的帮助，我们的问题最终都得到了解决，项目也成功上线。上线之后，我们对部分家长用户进行了回访，家长的评价都是新 App 的体验非常流畅、好用。

在第一个版本之后，我们又进行了几次版本迭代。迭代开发过程中，我们的客户端只需关注与“HTML5/小程序”的交互接口扩展，HTML5/小程序端更多关注业务开发，需要什么接口，和客户端约定一下协议即可，几乎实现了和客户端的“分离”开发。

业务开发完成后，可以在支付宝小程序 IDE 上一键发版提测，非常方便。上线也只需在 mPaaS 控制台手动发布一下版本即可，实现了秒级更新。

接着还有新同事参与进来开发了医生端的新业务。基于之前的积累，以及 mPaaS 小程序的开发文档，大家很快就能上手。几天时间就开发出了一个在线开处方的应用，mPaaS 大大地提高了我们的研发效率。

综合来看，mPaaS 帮助我们解决了最为头疼的性能体验问题，让我们可以集中精力进行业务模块的开发。

当然，mPaaS 带来的价值还有很多。它不光解放了我们的客户端，让客户端可以专注在 App 容器，不断丰富平台能力，比如统一 UI 组件库、身份认证体系、IM 通信、音视频直播等等；而且统一了我们的前端开发规范，让我们得以在统一的平台上进行业务开发，形成自己的规范，有利于代码的沉淀和管理。

「南京儿医在线」应用界面

未来展望

对瞰聆来说，医疗业务是我们的生命线。

我们只有不断地迭代、创新，才能做出真正有价值的产品，满足用户和客户的要求。项目上线才是开始，我们后面要面对的问题还有很多。

基于 mPaaS，后续我们希望进一步接入其他能力，比如移动端日志上传，帮助我们获得用户端 Bug 报错；比如热修复，帮助我们实现无感更新。

最后，我们感谢 mPaaS 团队的无私贡献，感谢节假日还在帮助我们解决问题的开发同学。mPaaS 还在不断完善，我们相信 mPaaS 是一个可以依靠的平台，mPaaS 未来一定会更加强大！

特别鸣谢：特别鸣谢：熊晨良、李俊、陈刚、徐精华

END

关于 mPaaS 小程序

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