Технология, которую SproutCore использует для плавного отображения и прокрутки «бесконечных» списков данных, имеет очень мало общего с тем, откуда поступают данные, и почти все связано с интеграцией специальных классов представления SproutCore, SC.CollectionView (родительский класс SC.ListView и SC.GridView) и SC.ScrollView;коллекция мощных клиентских классов хранилищ данных: SC.Store и SC.SparseArray;и среда выполнения SproutCore и архитектура контроллера.
Дело в том, что вы просто не можете отобразить список из нескольких сотен тысяч элементов в нем и ожидать, что браузер не остановится.Это слишком много элементов для вставки в дерево DOM, и поэтому SC.CollectionView оптимизирован для , генерирует только элементы для отображаемых в данный момент элементов в списке (например, если из 20 видны только 20 элементовмиллион, только 20 элементов находятся в DOM).Хотя это становится еще лучше, потому что по умолчанию, когда элементы прокручиваются и выходят из поля зрения, несколько существующих элементов обновляются на месте с информацией о новом элементе, так что дерево DOM даже не затрагивается .Это было бы невозможно, хотя без интеграции SC.ScrollView, которая позволяет коллекции знать о своем видимом прямоугольнике, и когда должна произойти прокрутка.
Кроме того, существует вся среда выполнения SproutCore.архитектура, которая используется для обеспечения того, чтобы все манипуляции с DOM были поставлены в очередь, так что вы касаетесь DOM только один раз за цикл выполнения, если необходимо , когда изменяется свойство отображения (например, переключение свойства отображения 50 раз в одном цикле выполнениятолько касается DOM один раз с окончательным значением).Это важный фактор экстремальной производительности, который влияет на все представления SproutCore, включая SC.CollectionView.
Наконец, чтобы сделать список по-настоящему кричащим, вы не можете загрузить несколько миллионов элементов в клиент за один запрос, а также даже не можетесохранить их все в памяти клиента.Это приводит меня к другой оптимизации SC.CollectionView и хранилища данных SproutCore, которая должна работать с разреженными данными .SC.CollectionView никогда не будет пытаться перебирать каждый элемент в его содержимом, поэтому ему не нужны все имеющиеся данные, только то, что показывается.Когда мы загружаем данные в клиент, мы используем SC.SparseArray для вставки части данных за раз по мере необходимости.Вся система очень элегантно спроектирована так, что когда представление коллекции запрашивает элемент, которого у разреженного массива еще нет, разреженный массив извлекает его (или следующую страницу элементов) в фоновом режиме.Из-за привязок и наблюдателей, когда поступают новые данные, мы можем обновить список на месте, что означает, что прокрутка не блокируется, пока данные вводятся в .
Эта демонстрациявыше очень устарел, вот новый, который использует технологии, которые я упомянул выше: http://showcase.sproutcore.com/#demos/Big%20Data (источник здесь: https://github.com/sproutcore/demos/tree/master/apps/big_data). В этой демонстрации я прокручиваю 50 000 имен , это все, что я мог сгенерировать и разбить на 500 файлов JSON по 100 имен, каждый из которых загружается удаленно с сервера. Как только вы прокрутите 100 имен, вы увидите, что следующие 100 имен выгружены, и происходит короткая флэш-память.текста заполнителя "…" (как долго вы видите, текст заполнителя зависит от вашего интернет-соединения).
Я использовал 50 000 имен, но я не вижу проблем с отображением списка из 500 000 или 5миллион имен . Однако при таком масштабе вам также понадобится «разгрузить» данные при вводе новых данных, используя SC.Store#unloadRecords, чтобы уменьшить использование памяти.
There 'В игре есть несколько других технологий, чтобы сделать все это возможным, что я пропустил, но это, по крайней мере, главные из них.