mPaaS集成：基于内嵌View形式优化首页更新

Here_
2,430 阅读4分钟

环境接入

  • 依赖问题带来的环境冲突处理
  • 配置生产or测试环境一键切换

刚开始时每次切换mPaaS环境都特别麻烦，环境切换涉及到的配置文件也需要完整修改，不然会出现小程序无法打开的问题。由于配置文件繁琐容易出现遗漏导致不可预知的异常，基于此问题写了Gradle脚本处理配置问题，后来官方文档也完善了这部分Gradle代码。我们也在原来的基础上根据官方文档的对自己的这部分代码做出了优化。 配置文件涉及到以下的修改点：

1、00000001_0.0.0.1.amr；
2、Ant-mpaas-xxxxxxx-test-Android.config;
3、custom_config.json;
4、h5_json.json；
5、MPNebula.loadOfflineNebula（）配置离线包信息。

优化首页对更新及时性的要求

1.首页架构

首页根据mPaaS的特点及文档。我们最后采用了基于内嵌view形式接入首页；但带来的问题就是更新不及时；下面具体分析一下这种不及时导致的异常场景。

2.场景分析

由于我司医疗APP（以下简称APP）对首页的实时性要求较高。但依据文档和工单表明：

正常情况下30min只能才能触发更新机制，但次更新机制仅仅更新本地的离线包数据，并不提供刷新机制。这就导致会出现这种场景，用户A在开启APP的情况下，此时我们后台更新发布了新的手首页，而且在30min冷却时间之内mPaaS不会触发更新机制，这就导致用户需要在下次打开应用触发更新，然后下下次打开应用才可以看到我们已经发布的最新的首页。后来经过和mPaaS的同学沟通发现，总结出了一点“无论何种方式触发更新机制并成功下载最新版本离线包至本地，都无法将已经加载完成的页面进行刷新操作，刷新操作只会在下载加载时才可以看到上次下载好的离线包更新的内容”；此举官方应该也是出于用户体验的考虑。不过我们还是期待官方可以提供更灵活的API，让开发者有更多的操作空间

3.解决方案-暂时（待官方提供方案优化）

观察到一些电商APP对页面的实时性处理，即后台发布页面更新->页面弹窗提示用户是否更新->用户确定然后更新页面；也算是在数据实时性和用户体验上的一个平衡； 当然对于我们APP首页的更新我们也做了多种尝试，以下是一些的尝试（当然其中一些「无效」的方案可能是我们的操作方式有误，仅供参考）：

  • 采用apwebview 的reload方法->无效
  • 同步or异步再次生成内嵌view，替换至首页->无效
  • 启动页调用MPNebula.updateAllApp（）然后在成功回调中启动首页->有效但依赖回调，受网络环境等其他因素的影响，会增加APP启动时间；（此方案也和mPaaS客服沟通过，mPaaS同学说可行，但不建议。因此我们没有采用）
  • 此方案有效。我们APP暂时采用的就是此方案（此处期待官方后期能提供API支持）
graph TD
A[APP启动至首页] -->|检查mPaaS分发后台最新版本与本地版本比较| C(是否有更新)
C -->|是| D[异步更新下载离线包至本地 并提示用户更新首页]
C -->|否| E[无操作]
D -->|确认更新| F[销毁首页Fragment并重新载入 达到更新目的]
D -->|取消更新| G[无操作]

H5容器和离线包相关问题

自定义API

  • 方法命名不可与内置API冲突
  • 前端初始化mPaaS环境的时机需要注意

小程序栈相关问题

页面栈限制

小程序跳转异常

注：以下小程序均为同一个小程序（id为xxxxx1）

  • 【小程序页面A】->【原生Activity页面B】->【小程序页面C】 此种栈结构会出现【小程序页面C】无法打开的情况
  • 在打开【小程序页面C】之前kill【小程序页面A】，此时可以打开【小程序页面C】但【小程序页面C】页面数据显示可能会出现异常。

未完待续……

说明

  1. 个人接入经验记录仅参考，如有错误欢迎指正，谢谢！！！
  2. 该文章基于mPaaS 基线版本 10.1.60.14 、小程序基础库版本1.14.1
avatar
文章
阅读
粉丝