GluonのListViewパフォーマンスが悪い

Question

私はカスタムListCellの実装をしています（下の図を参照）。 HBoxに含まれる各桁のTextFieldと、VBoxとカウンタからなる「CounterContent」に入れ

3つの標識からなる、日付を表す左側、、、及びkWh、kWh /日のラベルを含む2つのHboxesなどがあります。そして、それはあまりにも多くの、performantly実行するように見えます。

バックグラウンドタスクにデータをロードしようとしましたが、タスクが実行されている間に進行状況インジケーターが表示されましたが、デスクトップとは異なり、アンドロイドではパフォーマンスが非常に悪いです。リストビューに切り替えるたびに、ガベージコレクションが開始され、進行状況インジケータが表示されないようにUIスレッドがブロックされます。

私はHuawei Y-300、Android 4.1.1、javafxports 8.60.6（javafxports 8.60.7が原因でTextFieldが使用できなくなるため、バグが発生するため）、およびSamsung S5 mini、Android 5 +。サムスンの携帯電話では、Ahead-of-Timeのコンパイルのために一般的にパフォーマンスは良くなっていますが、ガベージコレクションの問題はまだあります。さらに、リストビューにセルが設定された後、スクロールはあまりスムーズではありません。

パフォーマンスが悪いためにリストセルが複雑になることがありますか？

UPDATE：滑らかでなくスクロールがパフォーマンスの問題が原因ではないと思われる多くのテストを実行した後

。少なくともS5（javafxports 8.60.7）。

私はすべてのCSSスタイルを除去し、そして単一のラベル（対向ノードが既に2 Regions（不HBoxesでテキストフィールドをレイアウトカスタムコントロール（すなわち忘れ）、である）とのノードがテキストフィールドを置き換えListCellがコンストラクタでインスタンス化されます）。さらに、ListViewをCharmListViewに変更し、android.monocle.input.touchRadius = 1に設定しました。

これらのステップのいずれも、大幅な改善をもたらさなかった。

明確にする：Huaweiの携帯電話とは対照的に、S5とアンドロイド5+のスクロールは使えますが、それほど滑らかではなく、不満足なユーザー体験になります。

Huawei（javafxports 8.60.6）では、ラベルのカウンタテキストフィールドを変更すると大幅に改善されましたが、スクロールが使用可能になった時点では改善されませんでした。私がこの魔法の実験的なスイッチを設定するまでは：gluon.experimental.performance = true。リストビューのスクロールが速く（あまりウォーミングアップの遅れをとって）スローされますが、まだ滑らかではありません。

Answer 1

複雑なシーンのパフォーマンスが低下する理由はたくさんあります。したがって、これはどのような順序ででも改善するのに役立つ可能性のあるアイデアの一覧に過ぎません。手始めに

のlistcell

、セル内のノードの数が本当に高いです。スクロールするたびに、表示されているセルを保持する仮想フローの完全なレンダリングを意味することに注意してください。そして、すべての細胞にとって、それはその内容を何度も作り直すことを意味します。

コードは表示されませんが、セル内のすべてのノードの新しいインスタンスを1つのインスタンスだけで作成することは避けてください。updateItemメソッドではノードの内容のみを変更します。

これを見てくださいsample。 NoteCellクラスはカスタムセルで、ListTileが使用されます。ノード

の

数は、あなたは8つのテキストフィールドと3つのボックスを交換するだけでLabelを使用してみましたか？

あなたがインターネットからダウンロードした画像を使用している場合は、キャッシュ

は、何度も何度もダウンロードされている同じ画像を避けるために、グルーオンチャームダウンCacheを使用しています。

このsampleをご覧ください。キャッシュがなければ、デスクトップ上でさえパフォーマンスは本当に影響を受けます。

異なるキャッシュ方式を試して、任意のノードにJavaFX組み込みキャッシュを使用することもできます。

CSS

複雑なCSSは長いCPU時間を必要とします。それを単純化してみてください。クイックテストのためにCSS全体を削除することもできます。次に、あなたが使うことができるかどうかを決めます。

同じことがアニメーションに適用されます：可能であれば、アニメーション、トランジション、またはCSSエフェクトを避けてください。

カスタムコントロール

カウンタ複雑なノードは、おそらくレンダリングを最適化するカスタムコントロールで置き換えることができます。

CharmListView

は、あなたの代わりにListViewのグルーオンチャームCharmListViewコントロールを使用してみましたか？

リストをスクロールしながらパフォーマンスを向上させる可能性のある最適化をテストするための新しい実験的なフラグがあります。 java.custom.propertiesファイルにgluon.experimental.performance=trueを設定し、試してください。

JavaFXPortsバージョン

はあなたが理由のTextFieldバグの8.60.6を使用している言及しました。この場合、TextFieldノードは編集可能ですか？もしそうでなければ、私はそれらを他のノードに置き換え、8.60.7で実行することを提案したい。

パフォーマンスツール

使用パフォーマンスMonitorようなツールとあなたはすべての可能なボトルネックを下にトレースできるように、そのprofilingオプションを使用しています。少なくとも最後にではなく、

CPU

：お使いのモバイルデバイスのスペックは常に重要です。

Cortex A5で複雑なシーンをレンダリングしようとすると、「最小、最低コスト、最低出力のARMv7アプリケーションprocessor」、または非常に古いAndroid 4.1.1を使用すると、新しい仕様の高性能デバイスで動作させます。

また、Cortex A7で実行すると「良い方法」が実行されます。このcomparisonを見て、その仕事に適したアーキテクチャを見つけてください。

とにかく、常に改善の余地があり、多くの努力が払われています。ご意見はいつでも歓迎します。