Блог

Я создаю небольшое приложение для торговой точки для друга. Ей нужно приложение на планшете, в котором есть 40 кнопок добавления (и 40 кнопок удаления). Каждая кнопка представляет продукт и имеет другую метку. В левой части экрана должно быть 20 вертикальных кнопок, а в правой части также должно быть 20 вертикальных кнопок. Все кнопки должны умещаться на одном экране.

Я попытался использовать два recyclerview рядом друг с другом — с привязкой к размеру экрана — с одним и тем же адаптером и пользовательскими представлениями внутри каждого recyclerview, но это вызвало большую задержку, и я получил предупреждения в своем эмуляторе о том, что кадры были пропущены. Я думаю, это связано с большим количеством просмотров внутри recyclerview (более 80 кнопок).

Затем я попробовал 1 recyclerview с двумя продуктами на 1 горизонтальной строке, но это, похоже, не улучшило производительность и усложнило мое приложение (потому что мне нужно установить два продукта на строку). Я также пытался использовать ListView, потому что думал, что у него меньше накладных расходов, но продолжал получать задержки и «Я / хореограф: пропущено 44 кадра! Возможно, приложение выполняет слишком много работы в своем основном потоке. »

Единственный способ, при котором кажется, что фреймы не пропущены, — это когда я жестко кодирую 80 кнопок, но это не оптимальное решение, потому что количество продуктов будет меняться со временем. При изменении продуктов (сохраненных в формате csv) количество кнопок также должно обновляться без необходимости изменения кода.

Есть ли способ создать представление с 80 кнопками, которое менее требовательно к системе? В идеале я бы ввел 1 список продуктов в 1 представлении.

Пример 1 продукта:

 <?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="horizontal"
    android:paddingHorizontal="10dip"
    android:paddingTop="1dp"
    android:paddingBottom="4dp">

    <Button
        android:id="@ id/add_button"
        android:layout_width="200dp"
        android:layout_height="44dp"
        android:minHeight="1dip"
        android:text="BUT L"
        android:textSize="22sp" />

    <TextView
        android:id="@ id/amount"
        android:layout_width="80dp"
        android:layout_height="44dp"
        android:paddingHorizontal="20dip"
        android:layout_gravity="center"
        android:textAlignment="center"
        android:text="0"
        android:textSize="22sp" />

    <Button
        android:id="@ id/delete_button"
        android:layout_width="60dp"
        android:layout_height="44dp"
        android:minWidth="1dip"
        android:minHeight="1dip"
        android:text="-"
        android:textSize="22sp" />

</LinearLayout>
 

Лично я бы не стал беспокоиться о сообщениях с пропущенными кадрами в журнале — это больше связано с тем, как работает ваш эмулятор на вашем компьютере, происходит ли сборка мусора, что еще происходит с системой и другими приложениями…

RecyclerView это правильный способ сделать это — они разработаны, чтобы быть эффективными! Старый ListView подход создавал бы ваши 40 записей с их собственными Button представлениями — RecyclerViews создавайте только несколько (достаточно, чтобы заполнить экран и пару с обеих сторон, чтобы они могли заглядывать при прокрутке).

Затем они перерабатывают их, снимая ViewHolder прокручиваемый экран и заполняя его данными для элемента, который собирается прокручиваться в поле зрения (вот в чем суть onBindViewHolder метода — заполнение этих данных). Таким образом, у вас есть только несколько из ViewHolders них с их макетами просмотра, и не имеет значения, представляет ли ваш список 40 элементов или 40 000!

На самом деле вам следует профилировать производительность на реальном устройстве, но у вас не должно возникнуть никаких проблем с базовым RecyclerView макетом, это вряд ли что-то с точки зрения пользовательского интерфейса. Если хотите, вы можете опубликовать свой Adapter ViewHolder код and, и люди могут сказать вам, делаете ли вы что-то очень медленное или требующее много памяти в реальной логике обработки.

Также убедитесь, что вы просматриваете элементы пользовательского интерфейса один раз для каждого ViewHolder созданного вами и сохраняете их как свойства, которые вы можете установить onBindViewHolder . Если вы работаете findViewById в onBindViewHolder (который, помните, запускается каждый раз, когда элемент готовится к прокрутке в поле зрения), это большая дублированная работа. Вероятно, в этом случае не будет сбоев, но все же лучше избегать этого, если сможете!