問題タブ [apple-watch-complication]

いくつかのコントローラーを備えた単純なアプリを作成しています。Complication インターフェイスを使用してアプリを実行した後、メイン ビュー コントローラーをスキップして、すぐに 2 つ目のビュー コントローラーに渡したいと思います。このアクションを実行する方法は知っていますが、複雑化を使用してアプリが起動されたという情報を取得する方法がわかりません。出来ますか？もしそうなら、どのように？

CLKComplicationTemplateModularLargeColumns template で列幅を調整する方法がわかりません。

私は常に 2 列目に省略記号を付けます。

2番目の列が読みやすいようにレイアウトを修正するにはどうすればよいですか?

すべてのコンプリケーション テンプレートを設定せずにシミュレーターにアプリをインストールするというミスを犯しました。ドキュメントの状態として、getPlaceholderTemplate は 1 回呼び出されてからキャッシュされます。

時計のコンプリケーション テンプレートをすべて設定したので、Modular フェイスをカスタマイズしてテキストを出力したいと思います。ただし、最初に作成した 1 つのテンプレートのみが表示され、残りのテンプレートには白いボックスが表示されます。これは、私が懸念している静的テンプレートです。

シミュレーターからアプリを削除し、Watch アプリから削除して再インストールしようとしましたが、テンプレートを更新するために関数を再度呼び出していないようです。何かご意見は？ありがとう。

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

次に呼び出します：

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

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

空のハンドラを送り返すだけです。しかし、このシナリオでも、タイムラインが 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 でこの問題を修正しました。シミュレーターと実際の時計の両方でテストしています。すべてが正常に機能しており、メモリ リークやパフォーマンスの低下はもうありません。最終的に、彼らが修正することを決定するまで、これに対する回避策はありませんでした。

階層ナビゲーションを使用する単純な「タイマー」watchOS アプリがあります。デジタル クラウンを押して時計のスプリングボードに戻り、アプリ アイコンをタップすると、使用していたのと同じインターフェイス コントローラーに戻ることができます。

ウォッチフェイスに戻ってアプリのコンプリケーションをタップすると、アプリは起動しますが、再起動したように見えます: 現在の状態が失われます。これを防ぐ方法はありますか？