问GMSPolyline超大内存峰值

EN

在GPS应用程序中，用户可以显示复杂位置点的列表，我们称之为各种不同类型地图上的轨迹，每个轨迹可以由2k到10k个位置点组成。当它们被渲染到非Google地图类型上时，这些轨迹被大量地裁剪、修剪和路径简化。这是为了保持低内存使用率和高性能。即使在最糟糕的情况下，我们通常只会向OpenGL管道提交不到1000个(总计)转换后的位置点。

在集成Google Maps SDK for iOS时，我们最初试图继续利用我们自己的OpenGL track渲染系统，但遇到了OpenGL上下文使用冲突的问题(渲染有效，但如果没有人接触到已删除的内存，我们无法让GMSMapView和我们自己的内部OpenGL资源都释放)。

因此，我们试图利用GMSPolyline结构，让Google SDK来进行曲目渲染，但我们遇到了严重的内存使用问题，并正在寻找解决这些问题的指导。

使用Xcode Instruments，我们已经监控了创建25条折线时的内存使用情况，这些折线总共有23k个位置点(不是每个)。在创建折线的过程中，应用程序内存使用量从大约14MB增长到大约172MB，净峰值约为158MB。在创建所有折线后不久，内存使用量最终下降到19MB左右，并且看起来很稳定，累积净值约为5MB，因此似乎每个位置点需要大约220字节(5MB/ 23k点)来存储。

最让我们头疼的是内存使用的峰值。

显然，GMSPolyLine构造并不适用于我们所需要的重量级应用。

我们尝试用单独的自动释放池包装一些折线创建循环，然后在适当的点排出这些循环，但这对内存使用没有影响。在创建多段线并将控制权返回到主运行循环之后，内存使用的峰值根本没有改变。后来，原因变得很清楚了；Google Map系统直到创建折线之后的第一个DisplayLink回调时才释放资源。

我们的下一步工作将是手动限制我们在GMSPolyline上推送的数据量，可能会使用我们自己的边界测试、裁剪、剪枝和最小化，而不是依赖谷歌地图来有效地完成这一点。

这里的缺点是，它将意味着更多的GMSPolyline对象将被分配和释放，可能是当用户在地图周围平移/缩放时。这些对象中的每一个都将具有更少的定位点，然而，我们仍然担心这种方法的不可预见的后果，许多GMSPolyline分配和释放的隐藏开销。

所以问题是，处理这种情况的最佳方法是什么，谷歌的某个人能否解释一下GMSPolyline的最佳实践、上限、瓶颈等？