在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
的最佳实践、上限、瓶颈等?
https://stackoverflow.com/questions/15442262
复制相似问题