JTACMonthView.scrollToDate() leaks memory when animateScroll is false

[rayx]

(Required) Version Number:

Master branch (pulled from main repo about 1 month ago)

Description

When animateScroll param is false, calling JTACMonthView.scrollToDate() prevents date cell objects moved out of the screen from being delocated. As a result, the number of the date cell objects in memory increases linearly with the number of scrollToDate() calls.

Steps To Reproduce

The issue can be reproduced by modifying SampleJTAppleCalendar demo app, as follows:

class ViewController: UIViewController {
    ...

    var nextDate = 1

    @IBAction func printSelectedDates() {
        let dateString = String(format: "2018/%02d/01 00:01", nextDate)
        nextDate += 1
        print(dateString)

        let fmt = DateFormatter()
        fmt.dateFormat = "yyyy/MM/dd HH:mm"
        let date = fmt.date(from: dateString)!

        calendarView.scrollToDate(date, animateScroll: false)
    }
}

Start the app and click on "Print Selected Dates" button multiple times. Then check Memory Graph Hierarchy in Xcode, you should see there are hundreds of CellView objects in the memory, most of which should haven been delocated.

Calling scrollToDate() with animateScroll param being true doesn't have this issue.

Expected Behavior

According to my observation, there are usually less than 100 cell objects in the memory. One month vew has 42 cells. The others are created perhaps because of UICollectionView prefetching.

I observe that scrolling to date animatedly doesn't increase the number, which is as expected.

Scrolling to date non-animatedly, however, causes cell object failed to be released by ARC. The number of cell objects in memory increases linearly. A bug?

Additional Context

I didn't check if year view has the same issue or not.

[patchthecode]

What version of Xcode are you using?

[rayx]

I'm using latest version of Xcode (11.4) and macOS (10.15.4). I ran the memory leak test on simulator, which runs iOS 13.4.

One more thing. As there were no code change in the main repo in the past two month, the code I used to reproduce the issue is the latest code in the repo.