在GPS应用程序中,允许用户显示我们称为各种不同类型地图上的轨道的复杂位置点列表,每个轨道可以包含2k到10k的位置点.当在非Google地图类型上渲染轨道时,轨道会被大量剪裁,修剪和路径简化.这是为了降低内存使用率并提高性能.我们通常最终只会向OpenGL管道提交远远少于一千(聚合)转换的位置点,即使在最坏的情况下也是如此.
在整合Google Maps SDK for iOS时,我们最初尝试继续利用我们自己的OpenGL轨道渲染系统,但遇到了与OpenGL上下文冲突相关的问题(渲染工作正常,但我们无法获得GMSMapView和我们自己的内部OpenGL资源在没有人触摸已删除的内存的情况下释放.
因此,我们正在尝试利用GMSPolyline构造并让Google SDK执行轨道渲染,但我们遇到了主要的内存使用问题,并正在寻找解决它们的指导.
使用Xcode Instruments,我们在创建大约25条多线路时监控内存使用情况,总线位置总数约为23k(不是每个).在创建多线路的过程中,应用内存使用量从大约14 MB增加到大约172 MB,净峰值大约为158 MB.在创建所有多边形线之后不久,内存使用率最终下降到大约19 MB并且看起来稳定,累积净值大约为5 MB,所以看起来每个位置点需要大约220个字节(5 MB/23k点)到商店.
令我们伤心的是峰值内存使用率.虽然我们的实验室测试只用23K的位置点,在现实世界中往往有更多的人,和iOS似乎要抛弃我们的应用程序后,谷歌地图有大约450 MB消耗上的iPhone 5(而我们内部的多线大约渲染系统峰12 MB用于相同的测试用例).
显然,该GMSPolyLine结构不适用于我们需要的重量级使用.
我们尝试使用单独的自动释放池包装一些多边形线创建循环,然后在适当的位置排出这些循环,但这对内存使用没有影响.在创建多边形线并且控制返回到主运行循环之后的峰值内存使用根本没有改变.后来很明显为什么; 在创建多边形线之后,第一个DisplayLink回调之前,Google Map系统不会释放资源.
我们接下来的努力将是手动限制我们在GMSPolyline上推送的数据量,可能使用我们自己的边界测试,裁剪,修剪和最小化,而不是依靠Google Maps来有效地执行此操作.
这里的缺点是,当用户在地图上平移/缩放时,可能会分配和释放更多GMSPolyline对象.这些对象中的每一个都将具有更少的位置点,但是,我们仍然担心这种方法的无法预料的后果,许多GMSPolyline分配和解除分配的隐藏开销.
所以问题是,处理这种情况的最佳方法是什么,谷歌的某些人是否可以对任何GMSPolyline最佳实践,上限,瓶颈等有所了解？