Хотя я также предлагаю вам сделать то, что опубликовал Артем, это не устранило этот пробел для меня напрямую. Оказывается, я столкнулся с двумя разными проблемами, связанными с UIRefreshControl, и нашел несколько «хаков», чтобы обойти их. Простое исправление состоит в том, чтобы установить цвет фона tableView на тот же цвет, что и элемент управления обновлением, но это имеет побочный эффект, видя тот же цвет в нижней части представления таблицы.

Моя установка - это UINavigationController, на котором размещается UIViewController с подпредставлением UITableView, и UISearchBar, установленным в качестве tableHeaderView tableView. Моя цель — подобрать цвет панели навигации, элемента управления обновлением и панели поиска.

Выпуск 1

Я думаю, что это та же проблема, что вы видите. Кажется, что как только вы перетаскиваете, чтобы начать действие «тянуть, чтобы обновить», в течение первых нескольких точек жеста появляется пробел. После некоторого порога элемент управления обновлением приобретает правильный цвет. Однако на обратном пути к состоянию покоя прокрутки табличного представления мы снова видим тот же пробел, как раз перед тем, как он достигает смещения содержимого, равного 0. Вот как это выглядит:

Решение 1

Если вы создадите подкласс UIRefreshControl и переопределите свойства frame и isHidden и просто распечатаете их значения, когда они будут установлены, вы заметите, что элемент управления обновлением на самом деле не становится скрытым, пока расстояние от верхней части табличного представления не станет равным 4pt. Точно так же, когда вы прокрутите вниз, вы также увидите, что он скрыт в том же месте, что и до того, как вы больше не можете видеть элемент управления обновлением, и почему мы видим пробел, выглядывающий на фон tableView.

В нашем подклассе мы можем предотвратить это «раннее» скрытие и «позднее» отображение, переопределив сеттер и геттер isHidden и didSet frame, чтобы скрывать только тогда, когда смещение элемента управления обновлением фактически равно 0.

class RefreshControl: UIRefreshControl {

    override var isHidden: Bool {
        get {
            return super.isHidden
        }
        set(hiding) {
            if hiding {
                guard frame.origin.y >= 0 else { return }
                super.isHidden = hiding
            } else {
                guard frame.origin.y < 0 else { return }
                super.isHidden = hiding
            }
        }
    }

    override var frame: CGRect {
        didSet {
            if frame.origin.y < 0 {
                isHidden = false
            } else {
                isHidden = true
            }
        }
    }
}

Я называю это хаком, потому что я не большой поклонник изменения существующего поведения UIRefreshControl, но я пока не нашел лучшего способа обойти это.

Выпуск 2

Когда вы тянете, чтобы обновить этот порог разрыва в проблеме 1, кажется, что кадр UIRefreshControl не может идти в ногу с панелью поиска. Это дает нам еще один тип пробела, который следует за строкой поиска. Вот как это выглядит:

Решение 2

Этот запаздывающий разрыв выглядит так, будто кадры обновляются не так быстро, как наша прокрутка, возможно, даже анимирована. Оказывается, если мы установим фрейм на себя где-то вроде layoutSubviews, мы получим следующее поведение:

override func layoutSubviews() {
    super.layoutSubviews()
    var originalFrame = frame
    frame = originalFrame
}

Опять же, это довольно хакерски, но я не нашел другого способа сделать это.

Результат

Почему вы добавляете refreshControl в качестве подвида? Вы должны сделать это:

refreshControl.addTarget(self, action: Selector(("refresh:")), for: UIControlEvents.valueChanged)
 if #available(iOS 10.0, *) {
     tableView.refreshControl = refreshControl
 }
 else {
     tableView.backgroundView = refreshControl
 }