java - Android Views 的 WeakReference 安全吗？

Question

你好，我正在编写一个应用程序，它使用许多 customView(父级作为 FrameLayout 持有 Activity 的上下文)。

在应用程序中有一个 recyclerView 它的持有者有 N(非常大的数量) View (自定义)。

由于 View 的数量是动态添加的(我正在测试 10k+ View )。

在回收器 View 中，我没有做任何特别的事情，而是使用协程，这样 10k View 的渲染就不会阻塞 Main Thread

但是由于每个 RecyclerView Holder 中的大量 View ，当我滚动并给出 OOM(内存不足)崩溃时，它会非常快地填满应用程序的堆内存。

To solve this issue i read and found I can use weak reference's to the View.But i have not found any example or reference to this approach.So i am not sure if using WeakReference on the Android View is a good solution or not.

下面的代码和演示项目引用​​。

RecyclerView Adapter :

override fun onBindViewHolder(holder: ViewPageHolder, position: Int) {
        val slideViewMultipleCanvas = SlideViewMultipleCanvas(context)
        holder.slideViewItemHolder.addView(slideViewMultipleCanvas)
        holder.positionHolder = position
        val childJob = launch {
            //this is where 10k+ view's are created
            slideViewMultipleCanvas.setNumOfObjects(numOfItemsInViewPage)
            slideViewMultipleCanvas.startJob()
        }
        map[position] = childJob
    }

CustomView :

...
...
suspend fun setNumOfObjects(numberOfObjects: Int) {
        withContext(Dispatchers.Default) {
            for (i in 0 until numberOfObjects) {
                // To solve OOM as number of view here in heap are >10k
                listOfObject.add(WeakReference(ShapeView(context)))
            }
        }
    }
...
...
private fun addViewInScope(): Boolean {
        for (shapeView in listOfObject) {
            shapeView.get()?.let {
                addView(it)
            }
        }
        return true
    }
....
....

在我的测试中使用 Wea​​kReference 之后，直到现在我还没有遇到任何问题(NO OOM's)但是每当 GC(Garbage Collector) 启动并收集时我仍然会遇到 Lag's所有弱引用。

我主要担心的是

• 有没有其他方法可以在不使用 Wea​​kReference 的情况下处理大量 View 的创建？
• 如果我对 View 使用弱引用会有什么问题吗？
• 如何减少 GC 延迟？(即使使用 Wea​​kReference 我也无法平滑滚动)

附言: 我已经在处理:

• 如果 GC 收集的是弱引用 View ，则为空情况
• 在 RecyclerView 中回收 View 时取消协程作业。(我也可以释放此 ViewHolder 的弱引用 View 吗？？？)

Answer 1

查看 RecyclerViewPools，您应该能够使用 itemType 分配特定 View (如果动态创建的 View 是相同的 View )，并让 recyclerView 也重用这些 View

主要延迟不是来自弱引用，而是纯粹需要如此快速地生成如此多的 View ，如果您可以保留一个缓存的 View 列表以供重用(有点像 recyclerViewPool)，那么这将减少膨胀延迟

唯一的问题是，如果你有太多的 View 会导致 OOM，是否可以将 View 组合成具有多种功能的通用 View (物理 View 较少，但每个 View 的逻辑和复杂性更高，以满足在多个 View 下使用情况

这将允许您多次重复使用相同的 View ，意味着更少的缓存/膨胀，您只需要确保代码高效执行