【问题标题】:Long loading time for map地图加载时间长
【发布时间】:2021-06-25 05:56:38
【问题描述】:

我正面临与来自Here-SDK-iOS 的空地图加载时间过长有关的问题。

我打开了示例项目,看起来它冻结了一段时间,接下来是初始化代码:

  override func loadView() {
    super.loadView()
    
    NSLog("%@", ">>>>>>>>>> Load View \(Date())")
  }
  
  override func viewDidLoad() {
    super.viewDidLoad()
    
    mapView = MapView(frame: view.bounds)
    view.addSubview(mapView)
    
    mapView.mapScene.loadScene(mapScheme: .normalDay, completion: self.onLoadScene)
    mapView.gestures.tapDelegate = self
    
    NSLog("%@", ">>>>>>>>>> View Did Load \(Date())")
  }

  override func didReceiveMemoryWarning() {
    super.didReceiveMemoryWarning()

    mapView.handleLowMemory()
  }

  func onLoadScene(_ error: MapError?) {
    guard error == nil else {
      print("Error: Map scene not loaded, \(String(describing: error))")
      return
    }

    // Configure the map.
    let camera = mapView.camera
    camera.lookAt(point: GeoCoordinates(latitude: 52.518043, longitude: 13.405991),
                  distanceInMeters: 1000 * 10)
  }

日志:

2021-06-25 08:45:27.500549+0300 testDrawing[50019:31547554] >>>>>>>>>> 加载视图 2021-06-25 05:45:27 +0000

...

2021-06-25 08:45:31.301998+0300 testDrawing[50019:31547554] >>>>>>>>>> 查看已加载 2021-06-25 05:45:31 +0000

如您所见,使用初始位置初始化地图大约需要 4 秒。注意:我使用免费增值帐户进行测试。

我还可以看到其他警告,例如

[WARN] harp-sdk - 忽略添加无效的观察者

[WARN] ResponseFromJsonBuilder - 缺少值, response=olp::authentication::IntrospectAppResult, field=description

[INFO] harp-sdk - 添加数据源

[INFO] Storage.LevelDB - 清除文件夹中的其他数据库:“/Users//Library/Developer/CoreSimulator/Devices/61082972-C4BE-42E2-9696-0D2458D475D5/data/Containers/Data/Application/74E993BF-7111 -4E08-A27F-A7F62B3ADA1D/Library/Caches/v1/sSR8TFucGSrS94S4sDvrsA/analyticsData/events.sqlite

[INFO] ThreadPoolTask​​Scheduler - 启动线程 'OLPSDKPOOL_0'

最耗时的操作 - 是Cleared other DB in folder- 大约 3 秒。

任何人都可以建议这种行为的原因是什么。

---- 更新 -----

我也收到随机崩溃

版本 = heresdk-explore-ios-4.7.5.0.5737

---- 更新 -----

几个模式技术细节:

对于问题«freeze on start":

在带有 M1 和模拟器的 Mac(12 Pro、iOS 14.5)和设备 12 Pro iOS 14.5 上进行了测试。 在设备上滞后一点 - 1-3 秒,在模拟器上 - 最多 7 秒。 heresdk-explore-ios-4.7.5.0.5737 heresdk-navigate-ios-4.7.6.0.5863

对于“启动时崩溃”:

12 Pro,iOS 14.5 两者 heresdk-explore-ios-4.7.5.0.5737

---- 更新----

您好,分析服务的崩溃必须在即将发布的版本中修复。最耗时的操作 - 是Cleared other DB in folder- about 3 sec. 没有证据表明此操作消耗 3 秒,可能在此操作之后发生了一些事情。 – 希尔戈斯

@Hsilgos,

是的,没有证据表明这个操作确实消耗了 3 秒 - 这只是我的猜测(当我删除 sdk 时 - 一切都会立即运行,所以这是简单的检查)。

以下是分析器的几张截图:

这里是trace file

在这里你可以看到 HARP.SDK.RENDERER(我猜是地图渲染器)消耗了大量资源,并且看起来 MainThread 正在等待它完成。

再一次 - 这只是一个猜测。

还有一点需要改进 - 在 M1 上的 arm64 达尔文模拟器上添加对运行 fat 的支持。因为不是我需要使用 Rosetta ( - 这令人失望....

---- 更新----

绘图性能问题 - 示例(当一次绘制大约 200 个项目时,更准确地说 - 一个接一个 - 没有用于批量绘图的 API):

查看第二个绘图区域 - 那里的性能问题更加明显

【问题讨论】:

  • 我添加了与您相同的日志,并使用github.com/heremaps/here-sdk-examples/tree/master/examples/… 进行了测试,大约需要 1-2 秒。我从未经历过您所看到的崩溃,也从未经历过 Storage.LevelDB 日志。我已经使用 HERE SDK for iOS (Explore Edition) 4.7.7 进行了测试。 - 这是一个更新的版本,所以也许同时情况有所改善。可能建议使用较新的版本进行测试,而且如果您可以共享您用于测试的设备,那将是一件好事。在模拟器上它通常启动较慢。
  • 请点赞问题以获得更多关注
  • PS:当你使用基于 M1 的计算机运行 Xcode 时,需要一个解决方法来运行模拟器(如文档中所述),所以我假设这意味着 x86 架构需要由 Rosetta 效仿,这可能会进一步放慢速度。在非 M1 芯片上,模拟器使用 x86 运行,因此速度更快(默认情况下,HERE SDK 附带 arm 和 x86 二进制文件,但在 M1 上,它的工作方式不同)。
  • @Datasun U 绝对正确,我明白如果我在与 Rosetta 的兼容模式下运行 Xcode,这可能会导致速度变慢。但是我没有使用 Rosetta,而是将 arm64 排除在模拟器架构中:构建设置-> 排除架构-> 任何 iOS 模拟器 SDK-> 值 arm64` 或换句话说 EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64。这里的问题不在于模拟器减速,而更多在于设备减速......我猜这是不可接受的
  • 您好,分析服务崩溃必须在即将发布的版本中修复。 The most time consuming operation - is Cleared other DB in folder- about 3 sec. 没有证据表明这个操作消耗了 3 秒,可能在这个操作之后发生了什么。

标签: ios swift here-api heremaps heremaps-ios-sdk


【解决方案1】:

HERE SDK 团队今天宣布,计划添加对 M1 arm64 模拟器构建的明确支持。目前还不清楚这将在何时以及如何发生,但由于它现在缺失,与真实设备相比,在 Apple M1 处理器上运行模拟器会减慢速度。但是,对我来说,在 M1 上运行模拟器仍然比在非 M1 上运行模拟器快,只是因为 M1 速度非常快,而我的非 M1 MacBook 的设置速度不是最快的。

此外,分析崩溃似乎是一个已知问题。因此,希望我们能尽快找到解决这两个问题的方法。

【讨论】:

  • @Datasub - 感谢更新。如何调查较长的加载时间(因此这很容易在真实设备上重现)。另外,我还有其他关于绘图性能的问题 - 我应该打开一个新线程还是可以在这里更新问题
  • 对问题添加了小更新 - 更具体
  • 不支持批量绘制,所以大量资产可能会有影响。听起来像是一个功能请求,所以我希望您最好直接联系 HERE 团队并提出请求。
  • 好的,谢谢你的回复,已经问过了 - 答案是 - 没有计划这样的活动,你可以使用现有的 API :(
  • 经过近一个月的讨论,总共解决了 4 个问题(崩溃、m1、设备速度慢、多图)中的 1 个)。还有一点需要改进——为库添加包管理器……目前 600mb 的快乐(胖 xcframework 的大小)不是最好的解决方案……
猜你喜欢
  • 1970-01-01
  • 2016-03-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-01-20
  • 2023-04-06
相关资源
最近更新 更多