QA@IT
«回答へ戻る

回答を投稿

提示して頂いたソースコードを元に、こちらでサンプルアプリを作り動作を検証しました。
そして、症状が再現することを確認しました。

結論から言うと、これはバグです。

DecorationViewの再利用は、UICollectionViewLayoutではなくUICollectionViewの中で行われています。
UICollectionViewは、DecorationViewやSupplementaryViewをプールするためのNSDictionaryなオブジェクトを持っており、今回のケースでは"DecoView/DecoView"というキーでちゃんとプールされています。
そして、プールしたDecorationViewを取り出すときに、"UICollectionElementKindDecorationView/DecoView"というキーを使用しています。
当然キーが一致しないのでnilが返ってきてしまい、結果プールしているオブジェクトは無いとうことになり、新規に生成されます。
DecorationViewの新規生成は、UICollectionViewLayoutが行っています。

回避策は、これといって思いつきませんが、、、
例えば、UICollectionView全体を覆うDecorationViewを作れば、絶対に画面外に出て行かないので1度しか生成されないはずです。とりあえず、これでメモリリークは防げそうかな?

提示して頂いたソースコードを元に、こちらでサンプルアプリを作り動作を検証しました。
そして、症状が再現することを確認しました。

結論から言うと、これはバグです。

DecorationViewの再利用は、UICollectionViewLayoutではなくUICollectionViewの中で行われています。
UICollectionViewは、DecorationViewやSupplementaryViewをプールするためのNSDictionaryなオブジェクトを持っており、今回のケースでは"DecoView/DecoView"というキーでちゃんとプールされています。
そして、プールしたDecorationViewを取り出すときに、"UICollectionElementKindDecorationView/DecoView"というキーを使用しています。
当然キーが一致しないのでnilが返ってきてしまい、結果プールしているオブジェクトは無いとうことになり、新規に生成されます。
DecorationViewの新規生成は、UICollectionViewLayoutが行っています。


回避策は、これといって思いつきませんが、、、
例えば、UICollectionView全体を覆うDecorationViewを作れば、絶対に画面外に出て行かないので1度しか生成されないはずです。とりあえず、これでメモリリークは防げそうかな?