Titanium Appcelerator: загрузка тяжелого пользовательского интерфейса в другом потоке

Я работаю над своим первым приложением Titanium. Сейчас тестирую на Android. Мне нужно обновить пару прокруток из данных json.

Можно ли в любом случае использовать какую-либо поточность в титане, чтобы пользовательский интерфейс оставался отзывчивым, пока мои представления загружаются. Я продолжаю получать эти сообщения.

[INFO] :   Choreographer: Skipped 191 frames!  The application may be doing too much work on its main thread.
[INFO] :   Choreographer: Skipped 72 frames!  The application may be doing too much work on its main thread.

Вероятно, они в порядке, но это сломает приложение, если данные станут тяжелее.


multithreading appcelerator titanium
person Muqeet    schedule 14.04.2014    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Нет, у вас нет доступа к многопоточности по умолчанию в Titanium.

Попробуйте не отображать прокрутку на экране, пока вы полностью не создадите пользовательский интерфейс, а затем вызовите show. Это означает, что он может нарисовать вид один раз, когда все вместе.

Кроме того, что вы показываете в scrollView, нам нужно больше информации здесь? Почему вы используете ScrollView, а не tableView? Если это табличные данные, которые довольно просты, и у вас много тысяч строк, попробуйте изучить негибкий, но производительный элемент управления ListView, который по сути является оптимизированным TableView.

Это также может помочь: http://www.slideshare.net/omorandi/titanium-mobile-flexibility-vs-performance-13102557

person Markive    schedule 22.04.2014

arrow_upward
0
arrow_downward

@Muqeet: у меня была такая же проблема с моим приложением для Android / Titanium. Мой хореограф пропускал более 300 кадров. Я наткнулся на этот самородок из документации Titanium здесь

Улучшенная производительность таблицы (Android)

Если у вас возникают проблемы с производительностью на Android при использовании пользовательских строк, вы можете попробовать установить свойство className. Имя класса служит подсказкой для повторного использования базовых представлений, используемых для отображения строк.

Заданное значение className указывает на строку с определенным набором дочерних представлений. Все строки с общим именем класса должны иметь один и тот же набор дочерних элементов — например, имя класса myCustomRow может идентифицировать строку, содержащую две метки и представление изображения.

Вот пример кода, в котором я изменил класс строки на className.

<Alloy>
<!--TableViewRow class="row" dataId="" details = "" isComplete = "" title="" id="rowView"-->
<TableViewRow className="row" dataId="" details = "" isComplete = "" title="" id="rowView">
    <View class="viewCircle" id="viewCircle">
        <Label class="lblPlayer" id="lblPlayer"></Label>    
    </View>
    <Label class="title" id="lblTitle"/>
</TableViewRow>

Как видите, у моей строки другой вид и две метки. Теперь я больше не получаю это предупреждение, и мое табличное представление без проблем загружает 30-45 строк. Мое табличное представление реагирует быстрее и кажется более быстрым.

Честно говоря, я отказался от попыток решить эту проблему после того, как погуглил. Надеюсь, это поможет другим людям. Спасибо!

person DevIntern    schedule 02.12.2014

arrow_upward
0
arrow_downward

Я думаю, что сейчас лучше всего использовать a вместо a, если у вас есть данные любого размера. Производительность была упомянута как конкретная причина, по которой вы должны использовать вместо ;-)

person John Dalsgaard    schedule 02.12.2014