Приведи пример кейса с негативной обратной связью

Пример кейса с негативной обратной связью: управление memory leak в RecyclerView

Рассмотрим реальную проблему, которая может возникнуть при работе с RecyclerView и адаптерами, — memory leak из-за утечки ссылок на контекст или View через слушатели событий.

Ситуация и исходная проблема

Исходный код (с ошибкой):

class MyAdapter(private val items: List<String>) : RecyclerView.Adapter<MyViewHolder>() {
    
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): MyViewHolder {
        val view = LayoutInflater.from(parent.context).inflate(R.layout.item_view, parent, false)
        val button = view.findViewById<Button>(R.id.item_button)
        
        // Проблема: слушатель события содержит ссылку на View и потенциально на контекст
        button.setOnClickListener {
            // Действие, зависящее от позиции элемента
            val position = holder.adapterPosition
            Toast.makeText(parent.context, "Clicked item $position", Toast.LENGTH_SHORT).show()
        }
        
        return MyViewHolder(view)
    }
    
    override fun onBindViewHolder(holder: MyViewHolder, position: Int) {
        holder.bind(items[position])
    }
}

Проблемы в исходном коде:

1. Слушатель создаётся в onCreateViewHolder, но ссылается на parent.context. Если адаптер используется в нескольких активностях или фрагментах, это может привести к удержанию ссылки на уничтоженный контекст.
2. Неявная зависимость от holder.adapterPosition внутри лямбды — при быстрых обновлениях данных или асинхронных операциях позиция может быть невалидной.
3. Повторное создание слушателей при каждом вызове onCreateViewHolder — неоптимально для памяти и производительности.

Негативная обратная связь и её применение

Негативная обратная связь (negative feedback) в разработке — это процесс обнаружения проблем, их анализа и внедрения корректирующих изменений. В данном случае:

1. Обнаружение: QA или тестирование выявляют рост потребления памяти при частых пересозданиях фрагментов с RecyclerView. Инструменты (LeakCanary, Android Studio Profiler) указывают на удерживаемые Activity или Fragment.
2. Анализ: Разработчик изучает код адаптера и видит потенциальные источники утечек — слушатели, использующие контекст.
3. Корректировка: Применяется паттерн отделения слушателей от контекста и управления жизненным циклом ссылок.

Корректированный код с исправлениями

class MyAdapter(
    private val items: List<String>,
    private val onItemClick: (Int) -> Unit // Делегирование обработки кликов
) : RecyclerView.Adapter<MyViewHolder>() {

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): MyViewHolder {
        val view = LayoutInflater.from(parent.context).inflate(R.layout.item_view, parent, false)
        return MyViewHolder(view, onItemClick) // Передача слушателя в ViewHolder
    }
    
    override fun onBindViewHolder(holder: MyViewHolder, position: Int) {
        holder.bind(items[position], position)
    }
}

class MyViewHolder(
    itemView: View,
    private val onItemClick: (Int) -> Unit
) : RecyclerView.ViewHolder(itemView) {
    
    private val button: Button = itemView.findViewById(R.id.item_button)
    
    fun bind(item: String, position: Int) {
        // Назначение слушателя с текущей позицией, но без прямого захвата контекста
        button.setOnClickListener {
            onItemClick(position) // Позиция передаётся явно
        }
        button.text = item
    }
}

// Использование в Activity/Fragment
class MyFragment : Fragment() {
    
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        val recyclerView = view.findViewById<RecyclerView>(R.id.recycler)
        val adapter = MyAdapter(listOf("Item 1", "Item 2")) { position ->
            // Обработка клика в контексте фрагмента, но без утечки
            Toast.makeText(requireContext(), "Clicked item $position", Toast.LENGTH_SHORT).show()
        }
        recyclerView.adapter = adapter
    }
}

Ключевые улучшения после негативной обратной связи:

• Делегирование ответственности: Адаптер не создаёт слушателей, зависящих от контекста, а принимает лямбду из внешнего слоя (фрагмента/активности). Это позволяет управлять жизненным циклом слушателя вместе с жизненным циклом владельца.
• Избавление от утечек: Ссылка на контекст (parent.context) не захватывается внутри адаптера. Контекст используется только в момент инфлейта View и затем отпускается.
• Стабильность позиций: Позиция передаётся явно в bind(), что предотвращает использование потенциально невалидного adapterPosition из лямбды.
• Производительность: Слушатель назначается в onBindViewHolder, что позволяет повторно использовать ViewHolder без создания новых объектов лямбд.

Вывод: негативная обратная связь в этом кейсе превратила проблему memory leak в улучшение архитектуры компонента — внедрение принципа единственной ответственности и управления зависимостью контекста. Это показывает, что негативные отзывы (через инструменты, тестирование, ревью кода) часто являются драйвером для рефакторинга и повышения качества кода.