项目背景：

我们的小程序是基于地图组件开发的，其内部使用到了大量的组件接口，如

一、10-100个（根据用户设备数量）marker 同时在每间隔10秒内更新经纬度，

二、根据用户使用场景，会分别在地图上绘制多条polyline，

所以在整个data这维护了一个marker数组、polyline数组和markertips数组，这三个数组算是内存大户，因为会不断的接收到后端socket来的经纬度进行初始化marker和tips等信息。项目的内存大户大概就是这么个情况，而且进入小程序登陆成功第一个界面就是这个地图业务场景页面。

现象：

我所遇到的问题就是，大多数几乎所有的用户在第一次打开小程序30秒内会收到内存不足需要重新打开的提醒，以后再使用此问题几乎不会在重现~~我想这个原因应该是微信使用了某种规则去标记每个小程序所需要的内存大小，当小程序打开后由于内存警告被重启，那么下次就会给小程序分配更多的内存，这个策略和机制很不错，保障了微信对宿主机内存的占用…

让我们团队快崩溃了的问题：

不过现在的问题是，每一个新用户第一次使用小程序都会当头一棒，提示内存不足，这种用户体验对该小程序和品牌造成的影响是致命的，即使我们小程序做的再好、再怎么工匠精神、再怎么优化用户体验……都抵不过这当头一棒带来的反作用力，用户直接的反应就是垃圾·还闪退…内存不足~太垃圾~

不知道小程序团队是否考虑过这个问题，我们使用小程序是为了更好的给客户服务，缩短与客户之间的距离，但提高用户对重app的依赖度，但现在这种体验倒逼我们几乎快要放弃小程序了，我们技术也经历了很多轮的内存优化，业务精简，但再精简下去我们整个team就可以滚蛋了~~

可能的解决方案？

目前就的情况是从代码层面优化的可能性很小了，对于这种地图类中度点复杂交互的应用，是否可以给予一个预先设定的大内存申请通道？

比如我们上线后可以申请大内存或复杂交互app内存配额权限，用户第一次访问小程序不再默认最小内存分配，而使用申请的大内存替代，这样就避免了首次使用的低劣体验。

由于项目原因，无法分享代码，如果贵团队重视此类现象，我愿意配合一起解决~期待回复