optimization - GMSPolyline 非常大的内存峰值

Question

在允许用户在各种不同类型的 map 上显示复杂位置点列表(我们称之为轨迹)的 GPS 应用中，每个轨迹可以包含 2k 到 10k 个位置点。当轨迹在非 Google map 类型上呈现时，它们会被大量剪切、修剪和路径简化。这是为了降低内存使用量并提高性能。即使在最坏的情况下，我们通常也只会向 OpenGL 管道提交远少于一千个(聚合)转换后的位置点。

在集成适用于 iOS 的 Google Maps SDK 时，我们最初尝试继续利用我们自己的 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 个位置点，但在现实世界中通常有更多的位置点，并且在 Google map 在 iPhone 5< 上消耗了大约 450 MB 的空间后，iOS 似乎放弃了我们的应用程序。/em> (而对于相同的测试用例，我们的内部折线渲染系统峰值约为 12 MB)。

显然，GMSPolyLine 构造并不适合我们需要的大量使用。

我们尝试使用单独的自动释放池包装一些折线创建循环，然后在适当的点耗尽这些循环，但这对内存使用没有影响。创建多段线并将控制返回到主运行循环后的峰值内存使用量根本没有变化。后来原因就清楚了；在创建折线后的第一个 DisplayLink 回调之前，Google map 系统不会释放资源。

我们的下一步工作将是手动限制我们在 GMSPolyline 推送的数据量，可能使用我们自己的边界测试、裁剪、修剪和最小化，而不是依赖 Google map 来有效地完成此操作。

这里的缺点是，这意味着将分配和释放更多的 GMSPolyline 对象，可能是在用户在 map 上平移/缩放时进行的。每个对象的位置点都会少得多，但我们仍然担心这种方法的不可预见的后果，即许多 GMSPolyline 分配和释放的隐藏开销。

所以问题是，处理这种情况的最佳方法是什么？Google 的人员能否阐明任何 GMSPolyline 最佳实践、上限、瓶颈等？

Answer 1

为什么不尝试使用基于基本 http 请求的 google API 进行指导。 https://developers.google.com/maps/documentation/directions/ 。 (检查许可条件和请求数量)。

然后使用 IOS MKPolyline 绘制数据。我相信你会有更好的表现。而且您将只依赖谷歌获取定位数据。

要将 google API 的响应转换为坐标，请使用下面众所周知的方法(取自其他帖子):

- (NSMutableArray *)parseResponse:(NSDictionary *)response
{
    NSArray *routes = [response objectForKey:@"routes"];
    NSDictionary *route = [routes lastObject];
    if (route) {
        NSString *overviewPolyline = [[route objectForKey: @"overview_polyline"] objectForKey:@"points"];
        return  [self decodePolyLine:overviewPolyline];
    }
    return nil;
}


-(NSMutableArray *)decodePolyLine:(NSString *)encodedStr {

    NSMutableString *encoded = [[NSMutableString alloc]initWithCapacity:[encodedStr length]];
    [encoded appendString:encodedStr];
    [encoded replaceOccurrencesOfString:@"\\\\" withString:@"\\"
                                options:NSLiteralSearch range:NSMakeRange(0,
                                                                          [encoded length])];
    NSInteger len = [encoded length];
    NSInteger index = 0;
    NSMutableArray *array = [[NSMutableArray alloc] init]; NSInteger lat=0;
    NSInteger lng=0;
    while (index < len) {
        NSInteger b; NSInteger shift = 0; NSInteger result = 0; do {
            b = [encoded characterAtIndex:index++] - 63; result |= (b & 0x1f) << shift;
            shift += 5;
        } while (b >= 0x20);
        NSInteger dlat = ((result & 1) ? ~(result >> 1)
                          : (result >> 1)); lat += dlat;
        shift = 0; result = 0; do {
            b = [encoded characterAtIndex:index++] - 63; result |= (b & 0x1f) << shift;
            shift += 5;
        } while (b >= 0x20);
        NSInteger dlng = ((result & 1) ? ~(result >> 1)
                          : (result >> 1)); lng += dlng;
        NSNumber *latitude = [[NSNumber alloc] initWithFloat:lat * 1e-5]; NSNumber *longitude = [[NSNumber alloc] initWithFloat:lng * 1e-5];
        CLLocation *location = [[CLLocation alloc] initWithLatitude: [latitude floatValue] longitude:[longitude floatValue]];
        [array addObject:location]; }
    return array;
}

我在 google sdk 上遇到了类似的性能问题，它对我有用。