3

私は約 1 週間、この問題について強調してきており、Apple Watch アプリのパフォーマンス低下がゆっくりではあるが着実に低下している原因を突き止めようとしている。約 2 日間で、アプリの UI が徐々に遅くなりました。複雑な更新コードに絞り込みました。コンプリケーションの更新を最小限に抑えても、実際のデータでコンプリケーションを更新する場合よりも遅くなりますが、この問題は引き続き発生します。コンプリケーションは 10 分ごとに更新されます。新しいデータが来たら、単純に実行します

for (CLKComplication *comp in [CLKComplicationServer sharedInstance].activeComplications) {  
     [[CLKComplicationServer sharedInstance] reloadTimelineForComplication:comp];  
}

次に呼び出します：

- (void)getCurrentTimelineEntryForComplication:(CLKComplication *)complication withHandler:(void(^)(CLKComplicationTimelineEntry * __nullable))handler {  
...  
}

これは正常に機能し、新しいデータが表示されますが、数十回繰り返すと、メイン アプリの UI の応答性が著しく低下し始め、約 100 回繰り返すと (10 分の更新で 1 日未満で発生します) UI の速度が大幅に低下します。

コンプリケーションの構造については特に何も考えていません。タイム トラベルはなく、現在のデータを表示するだけで、すべてがそのように設定されています。間違った場所を見ていないことを確認するために、タイムラインを毎秒リロードするテストを作成しました。このテストでは、getCurrentTimelineEntryForComplication は次のようになります。

- (void)getCurrentTimelineEntryForComplication:(CLKComplication *)complication withHandler:(void(^)(CLKComplicationTimelineEntry * __nullable))handler {  
     handler(nil);  
}

空のハンドラを送り返すだけです。しかし、このシナリオでも、タイムラインが 100 回ほどリロードされると、メイン アプリの UI が目に見えて遅くなります。

その他の注意事項:

  • コンプリケーションを更新していない場合、アプリを何度開いても、どれだけ長く使用しても、データ取得コードがバックグラウンドで何回実行されても、アプリの UI パフォーマンスが低下することはありません。

  • シミュレーターでこれをテストすると、パフォーマンスの低下は発生しませんが、コンプリケーションの更新により、小さいながらも安定したメモリ リークが発生していることが一貫して確認できます (繰り返しになりますが、これは内部でどんなに単純な更新を行っても発生します)。 getCurrentTimelineEntryForComplication メソッド。

他の誰かがこれに気づいたことがありますか?それに対処する希望はありますか? 私は何か間違ったことをしていますか？当分の間、データが変更された場合にのみ合併症を更新するようにしていますが、それは問題を解決するのではなく、問題を延期するだけです.

10月24日編集

私は実際の時計でより慎重なテストを行いましたが、以前は何らかの理由で実際の時計でこれに関連するメモリ リークに気付かなかったのですが、今では確実に発生しています。実際のデバイスは、シミュレーターで見られる問題を完全に反映していますが、メモリ割り当ての初期量が異なるだけです。

繰り返しますが、定数ループで reloadTimelineForComplication を呼び出すだけで、キャッシュされたデータ オブジェクトから 1 行のテキストでコンプリケーションが更新されます。それ以外の場合、コンプリケーション コントローラーは最小限に取り除かれます。コンプリケーションがウォッチフェイスから削除されると、メモリ リークは予想どおり停止します。

私のメイン プロジェクトは ObjectiveC で書かれていますが、Swift で作成されたテスト プロジェクトでテストを繰り返しましたが、違いはありません。また、最新の XCode 8.1 GM と、付属のシミュレーターに付属の watchOS 3.1 ベータ版、および watchOS3.1 がインストールされた実際の時計で実行しても問題は解決しません。

2017年1月24日 編集

悲しいことに、この問題は watchOS 3.1.3 でも解決されず、まったく変更されていません。それまでの間、私は Apple のコード レベル サポートに連絡し、サンプル コードを送ったところ、問題が存在することが確認され、バグ レポートを提出するように言われました。私は約 2 か月前にバグ レポートを提出しましたが、今まで未分類のままでした。つまり、まだ誰も見ていないということです。

2017年1月31日編集

Apple は watchOS3.2 beta 1 でこの問題を修正しました。シミュレーターと実際の時計の両方でテストしています。すべてが正常に機能しており、メモリ リークやパフォーマンスの低下はもうありません。最終的に、彼らが修正することを決定するまで、これに対する回避策はありませんでした。

4

2 に答える 2

4

Apple は watchOS3.2 beta 1 でこの問題を修正しました。シミュレーターと実際の時計の両方でテストしています。すべてが正常に機能しており、メモリ リークやパフォーマンスの低下はもうありません。最終的に、彼らが修正することを決定するまで、これに対する回避策はありませんでした。

于 2017-02-02T18:18:14.873 に答える
0

ネイティブのカレンダー コンプリケーションを使用すると、すべての操作が非常に遅くなることに気付きました。だから多分それは新しい時計OSのバグです. カレンダーのコンプリケーションを数日間使用した後、そのウォッチフェイスを使用することは不可能です. 別のコンプリケーションに変更してカレンダーに戻しても、パフォーマンスが「リセット」されることはありません。解決する唯一のことは、時計を再起動することです。(または、カレンダーのことは忘れて、代わりに別のコンプリケーションを使用してください)

于 2016-10-16T17:31:58.730 に答える