OnCreateViewHolderのパフォーマンスの問題

OmriBager:

私はRecyclerViewで問題に遭遇し、皆さんが私を助けることができると思いました。そのため、問題は次のとおりです。アイテムビューのXMLの展開に時間がかかりすぎる。レイアウトは、3つのアイテムが並んだグリッドレイアウトで、各アイテムは複雑なUIの外観を持っています。

それで、最初にandroid studioのプロファイラーを使用してそれを分析しましたが、作成の時点でCPUに大きなバンプがあることがわかりました。バインドコード全体を削除しても、この画面に移動してリサイクラービュー内をスクロールすると、まだ時間がかかります。

アイテムを小さなアイテムに分離することは、既にマトリックス(私が言ったように、3つのアイテムが連続している)であるため、クレイジーになります。

だから私は2つのことを考えました:

  1. 多分私は前もってもっと多くのビューホルダーを作成することができます、それを行う方法はありますか?私はRecyclerView.setItemViewCacheSizeやなどのメソッドを見ましたLayoutManager.setInitialPrefetchItemCountが、それを実現する運がありませんでした(それでもcreateを何度も呼び出しています)

  2. AsyncLayoutInflaterについてはどうですか?誰かがRecyclerViewでそれを使用していますか?

どんな新しいアイデアも素晴らしいでしょう!

ビューxmlは次のようになります。

<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:card_view="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <android.support.v7.widget.CardView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        card_view:cardCornerRadius="3dp"
        card_view:cardElevation="2.5dp"
        card_view:cardUseCompatPadding="true">

        <CustomView1>

        </CustomView1>

        <CustomView2>

        </CustomView2>

        <CustomView3>

        </CustomView3>

        <ImageView
            android:id="@+id/imageView"
            android:layout_width="wrap_content"
            android:layout_height="30dp"
            android:layout_gravity="end"
            android:layout_marginEnd="2dp"
            android:layout_marginStart="2dp"
            android:layout_marginTop="2dp"
            android:adjustViewBounds="true" />

        <TextView
            android:layout_width="wrap_content"
            android:layout_height="wrap_content" />

        <include layout="@layout/someLayoutToInclude" />

    </android.support.v7.widget.CardView>
</FrameLayout>

OnCreateViewHolderは次のようになります。

LayoutInflater layoutInflater = LayoutInflater.from(parent.getContext());
View view = layoutInflater.inflate(viewType, parent, false);
return new ItemViewHolder(view);

グリッドレイアウトの初期化:

final GridLayoutManager gridLayoutManager = new GridLayoutManager(getContext(), 3);
        gridLayoutManager.setSpanSizeLookup(new GridLayoutManager.SpanSizeLookup() {
            @Override
            public int getSpanSize(int position) {
                return 1;
            }
        });

ありがとう

OmriBager:

これが私が最後に行った解決策です:先に述べたように、私の問題は、onCreateViewHolderが変更できない巨大な階層を持つ複雑なビューを作成することでした(製品単位)。

そのため、うまくいかなかったことが2つありました。

  1. 高速にスクロール/フリンジすると、スクロール中に新しいアイテムが作成され、UIが数ミリ秒間フリーズしました。
  2. 前の画面とRecyclerViewを使用した画面の間のアニメーションは、見た目が悪く、脚が長く見えました。

だから私がしたことは:

上で述べたように、AsyncLayoutInflaterがあります。これを使用するには、ダミーのViewGroupをインフレートする必要があり、その後、このダミーのビューに非同期インフレートビューを追加する必要がありました。もちろん、onBindViewHolderをサポートするためにいくつかの追加ロジックを実行する必要があります。

public ItemViewHolder onCreateViewHolder(@NonNull ViewGroup parent, int viewType) {
    LayoutInflater layoutInflater = LayoutInflater.from(parent.getContext());

    View view = layoutInflater.inflate(R.layout.async_holder_item, parent, false);
    AsyncLayoutInflater asyncLayoutInflater = new AsyncLayoutInflater(parent.getContext());
    asyncLayoutInflater.inflate(viewType, (ViewGroup) view, new AsyncLayoutInflater.OnInflateFinishedListener() {
        @Override
        public void onInflateFinished(@NonNull View view, int resid, @Nullable ViewGroup parent) {
            parent.addView(view);
        }
    });

    return new ItemViewHolder(view, viewType);
}

ダミービューでちらつきまたは読み込み状態を使用して(レイアウトをシンプルに保つ!)、android:animateLayoutChanges = "true"をトップビューグループに追加して、スムーズにすることもできます。

この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。

侵害の場合は、連絡してください[email protected]

編集
0

コメントを追加

0

関連記事

分類Dev

パフォーマンスの問題

分類Dev

Rのループのパフォーマンスの問題

分類Dev

春の起動時のパフォーマンスの問題

分類Dev

matplotlibの凡例のパフォーマンスの問題

分類Dev

PageStorageKeyでのFlutterListViewのパフォーマンスの問題

分類Dev

VirtualBoxでのLinuxMintのパフォーマンスの問題

分類Dev

Burrows-PythonのWheelerのパフォーマンスの問題

分類Dev

Djangoの多対多のパフォーマンスの問題

分類Dev

SQLでのUNION句のパフォーマンスの問題

分類Dev

Where andContainsでのLINQtoEntitiesのパフォーマンスの問題

分類Dev

HikariCP での Postgresql のパフォーマンスの問題

分類Dev

NestJsテストのパフォーマンスの問題

分類Dev

システムのパフォーマンスの問題

分類Dev

Pythonリスト操作のパフォーマンスの問題

分類Dev

iOSデバイスのパフォーマンスの問題

分類Dev

イオンタブのパフォーマンスの問題

分類Dev

イオンタブのパフォーマンスの問題

分類Dev

ループ内のjQueryパフォーマンスの問題

分類Dev

SSESIMDコードのパフォーマンスの問題

分類Dev

カーソルのパフォーマンス低下の問題

分類Dev

Retina Macbook ProでのWebGLパフォーマンスの問題

分類Dev

LinkedBlockingQueueでのJavaパフォーマンスの問題

分類Dev

Java ByteBufferのパフォーマンスの問題

分類Dev

RegexクエリのMongoDBパフォーマンスの問題

分類Dev

SpringバッチJPAItemReaderのパフォーマンスの問題

分類Dev

IE 11-DataTablesDOMのパフォーマンスの問題

分類Dev

SwiftUI-ObservableObjectのパフォーマンスの問題

分類Dev

SwiftUI-ObservableObjectのパフォーマンスの問題

分類Dev

Spring 4TaskSchedulerのパフォーマンスの問題

Related 関連記事

  1. 1

    パフォーマンスの問題

  2. 2

    Rのループのパフォーマンスの問題

  3. 3

    春の起動時のパフォーマンスの問題

  4. 4

    matplotlibの凡例のパフォーマンスの問題

  5. 5

    PageStorageKeyでのFlutterListViewのパフォーマンスの問題

  6. 6

    VirtualBoxでのLinuxMintのパフォーマンスの問題

  7. 7

    Burrows-PythonのWheelerのパフォーマンスの問題

  8. 8

    Djangoの多対多のパフォーマンスの問題

  9. 9

    SQLでのUNION句のパフォーマンスの問題

  10. 10

    Where andContainsでのLINQtoEntitiesのパフォーマンスの問題

  11. 11

    HikariCP での Postgresql のパフォーマンスの問題

  12. 12

    NestJsテストのパフォーマンスの問題

  13. 13

    システムのパフォーマンスの問題

  14. 14

    Pythonリスト操作のパフォーマンスの問題

  15. 15

    iOSデバイスのパフォーマンスの問題

  16. 16

    イオンタブのパフォーマンスの問題

  17. 17

    イオンタブのパフォーマンスの問題

  18. 18

    ループ内のjQueryパフォーマンスの問題

  19. 19

    SSESIMDコードのパフォーマンスの問題

  20. 20

    カーソルのパフォーマンス低下の問題

  21. 21

    Retina Macbook ProでのWebGLパフォーマンスの問題

  22. 22

    LinkedBlockingQueueでのJavaパフォーマンスの問題

  23. 23

    Java ByteBufferのパフォーマンスの問題

  24. 24

    RegexクエリのMongoDBパフォーマンスの問題

  25. 25

    SpringバッチJPAItemReaderのパフォーマンスの問題

  26. 26

    IE 11-DataTablesDOMのパフォーマンスの問題

  27. 27

    SwiftUI-ObservableObjectのパフォーマンスの問題

  28. 28

    SwiftUI-ObservableObjectのパフォーマンスの問題

  29. 29

    Spring 4TaskSchedulerのパフォーマンスの問題

ホットタグ

アーカイブ