Titanium Appcelerator: Зареждане на тежък потребителски интерфейс в различна нишка

Работя върху първото си приложение за Titanium. В момента го тествам на Android. Трябва да актуализирам няколко scrollviews от json данни.

Има ли все пак използване на някакъв вид резба в titanium, за да поддържа потребителския интерфейс отзивчив, докато моите изгледи се зареждат. Продължавам да получавам тези съобщения.

[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.

Опитайте да не показвате изгледа за превъртане на екрана, докато не изградите напълно потребителския интерфейс, след което извикайте шоу. Това означава, че може да начертае изгледа веднъж, когато всичко е заедно.

Освен това какво показвате в scrollView, имаме нужда от повече информация тук? Защо използвате ScrollView, а не tableView? Ако това са таблични данни, това е доста просто и имате много 1000 реда, опитайте да разгледате негъвкавия, но производителен контрол 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 реда без никакви проблеми. Моят tableview реагира по-бързо и се чувства по-бърз.

Честно казано, бях се отказал да се опитвам да разреша този проблем, след като гугълнах. Надявам се това да помогне на други хора. Благодаря!

person DevIntern    schedule 02.12.2014

arrow_upward
0
arrow_downward

Мисля, че най-добрата практика сега е да използвате a вместо a, ако имате някакъв размер на данните. Производителността е спомената като конкретна причина, поради която трябва да използвате вместо ;-)

person John Dalsgaard    schedule 02.12.2014