2012-02-22 12 views
10

Tytan twierdzi, że potrafi zrobić tę samą aplikację średnio o 70% szybciej niż natywny XCode.appcelerator vs phonegap vs natywna szybkość XCode na rynek

Co było doświadczeniem innych osób pod względem różnicy w szybkości rozwoju (pomiędzy natywnym XCode i PhoneGap lub tytanem)?

Powiedzmy aplikację jak Kik Messenger lub Badoo ....

Zazwyczaj dobry XCode deweloper może to zrobić w 4-5 tygodni, przy założeniu, grafika i backend są na miejscu.

Co trzeba zrobić, aby doświadczona osoba z Titanium (HTML5) mogła to osiągnąć? (w przybliżeniu)

+3

Skąd otrzymałeś dane, że te aplikacje zostały zbudowane w ciągu 4-5 tygodni? Warto również omówić swoje cele dotyczące jakości. Czy chcesz po prostu czegoś, co jest "ok" lub czegoś, co jest naprawdę doskonałe i wyróżnia się? Wiele zalet JavaScriptu wyparowuje, gdy próbujesz przejść od "wystarczająco dobry, jeśli nie przejmujesz się zbytnio" do wspaniałego. –

+0

Rob, zdecydowanie chcę czegoś, co się wyróżnia, gdy zostanie wypchnięty z UI/UX i punktu widzenia wydajności (szybkość działania). W tym sensie, przypuszczam, że w odniesieniu do tempa rozwoju, natywna jest droga, ale próbuję po prostu zmierzyć, ile czasu jest to obniżenie, robiąc to natywnie, mając doświadczonego kodera HTML5 poprzez rozwiązania wieloplatformowe. – xrave3

+2

Aby dostać się do czegoś, co się wyróżnia, natywna generalnie szybciej się tam dostanie (zakładając podobne zestawy umiejętności). To nie jest porażka. Język natywny może Cię nieco wydłużyć, aby dostać się do wersji 0.1, ale jest znacznie szybszy do wersji 1.0 (jeśli v1.0 ma być bardzo dobry). Przyjęcie "kodera HTML5", który nie jest doświadczony w programowaniu HTML5 specjalnie dla platformy mobilnej, stanowiłoby dramatyczną porażkę. Tworzenie HTML5 na komputerze nie jest tym samym. Jeśli wszystko, co masz, to programiści HTML5, to oczywiście będą rozwijać się szybciej niż HTML5. –

Odpowiedz

21

Czas wprowadzania na rynek zależy od jakości specyfikacji, procesu i ludzi, znacznie więcej niż bazowa technologia lub struktura.

Kodowanie prawdziwej aplikacji za pomocą Appceleratora Titanium nie jest takie proste, a wydajność środowiska wykonawczego jest WOLNA niż kod natywny, ponieważ wykorzystuje mechanizm javascript jako pomost. Zwłaszcza przy dużym TableView jest znacznie wolniej, a uczucie to nie to samo. Ale gdy już przeczyścisz wycieki pamięci, to uczucie jest niewiarygodnie lepsze niż w HTML5.

powinien być zainteresowany Titanium lub PhoneGap (obecnie znany jako Cordova), jeśli masz zamiar dystrybuować swoją aplikację w innych urządzeniach lub jeśli naprawdę nie lubią Objective C.

Jeśli nie, należy go z Natywny Xcode.

Chciałbym dodać, że Cordova nie stworzy żadnego interfejsu użytkownika, ale pozwoli na dostęp do kamery, akcelerometru lub GPS z javascript wewnątrz kodu HTML5. Prawdopodobnie używałbyś Sencha Touch lub jqueryMobile z Cordova.

+0

Aby dodać do tego, Titanium dodała ostatnio Komponent ListView, który powinien naprawić większość problemów z wydajnością związanych ze składnikiem TableView. – Jorre

+0

Powiedziałeś: << wydajności środowiska wykonawczego są WOLNE niż kod natywny, ponieważ używają silnika javascript jako mostu. >> Myślę, że aplikacja nie użyje żadnego javascriptu w środowisku wykonawczym, ponieważ javascript jest używany tylko w fazie rozwoju, a następnie aplikacja zostanie wygenerowana na natywnym kodzie, dzięki czemu będzie tak szybka, jak aplikacja stworzona bezpośrednio z natywnego kodu. Proszę, powiedz mi, czy to jest złe czy prawdziwe. – Bardelman

+1

To jest złe. JavaScript jest uruchamiany na urządzeniach. Twoja aplikacja jest dostarczana z silnikiem JavaScript. – krisdyson

8

Jeśli jesteś programistą iOS i rozwijasz go tylko na urządzenia z systemem iOS, lepiej jest kodować przy pomocy XCode. Jeśli bardziej interesujesz się JavaScriptem i tworzeniem dla Androida i iOS, powinieneś używać Tytanu lub Fonegapa. Pomiędzy tytanem i Phonegapem, łatwiej było kodować przy użyciu Titanium (i tak szybko). Ale nie jestem pewien, ile warte jest użycie tytanu. http://usingimho.wordpress.com/2011/06/14/why-you-should-stay-away-from-appcelerators-titanium/

+1

Dobry link. Nie byłem jeszcze przekonany, że jeśli chcesz zbudować najwyższej klasy aplikację, możesz czerpać wiele korzyści z wieloplatformowych frameworków. Przez cały czas, gdy poświęcasz trochę czasu na rozwiązywanie drobnych problemów, aby uzyskać rozwiązanie o najniższym wspólnym mianowniku, możesz zamiast tego napisać dwie natywne aplikacje, które znacznie lepiej zintegrowałyby się z ich platformami. –

+0

Rob, co myślisz o używaniu szablonów i bibliotek w porównaniu z natywnymi? http://stackoverflow.com/questions/8756/iphone-web-applications-templates-frameworks – xrave3

+1

Jest kilka rzeczy, które warto wiedzieć o Titanium, jak każdy inny framework. http: // stackoverflow.com/questions/9115811/what-is-some-of-the-best-way-to-optimize-a-titanium-app/9148044 # 9148044 –

10

Z mojego doświadczenia wynika, że ​​jeśli aplikacja nie jest prostą aplikacją do tworzenia szablonów, lepiej jest utworzyć aplikację natywną dla każdej platformy.

Jak mówi Rob, próba przezwyciężenia najmniejszego wspólnego mianownika i przezwyciężenia ograniczeń międzyplatformowych "rozwiązań" zwykle oznacza, że ​​kodowanie trwa dłużej niż na początku.

Możesz nawet trafić problem, który powoduje, że porzucasz statek i zaczynasz od zera jako aplikacje natywne. Jeśli więc zdecydujesz się na trasę PhoneGap lub Titanium, upewnij się, że w pełni zbadałeś ją przed rozpoczęciem i że nie będziesz mieć przyszłych wymagań, których nie pokrywają.

+0

Naprawdę akceptuję: "Możesz nawet trafić problem, który powoduje, że porzucasz statek i zaczynasz od zera jako aplikacje natywne" .. –

5

Aktualnie przeprowadzam dość intensywną ankietę dotyczącą wszystkich głównych wieloplatformowych zestawów programistycznych dla urządzeń przenośnych. Zacząłem od zrobienia przykładowej aplikacji od podstaw w IOS, która używa kilku prostych funkcji urządzenia, a następnie ponownie zaimplementowałem to jako aplikację Adroid. Obie trwały około jednego dnia (android trwał może pół dnia dłużej). Ponieważ nigdy wcześniej nie napisałem aplikacji na Androida, uważam, że jest to dobry punkt odniesienia, jeśli chodzi o porównywanie czasu rozwoju między różnymi innymi testowanymi przeze mnie frameworkami.

Będę aktualizować ten komentarz w ciągu kilku tygodni za pomocą posta na blogu, kiedy skończę, ale na razie stwierdzam, że te wieloplatformowe zestawy są znacznie łatwiejsze w użyciu i podejmują trudniejsze w użyciu dużo więcej czasu, nawet dla najprostszych aplikacji. i mimo to wciąż jest sporo niestandardowego kodu na urządzenie, który musi być napisany dla interfejsu użytkownika i podstawowych idiosynkratycznych różnic między działaniem usług urządzeń, więc tak naprawdę nie otrzymuje się wartości prawdziwej "bazy jednokodowej", która możesz się spodziewać.

Myślę, że główna wartość w nich może okazać się niezwiązana z czasem rozwoju lub ponownym użyciem kodu, ale tylko jako sposób dla programistów niebędących aplikacjami do tworzenia prostych prototypów, które mogą później zostać przekazane do "prawdziwych" twórców aplikacji mobilnych, które później zostaną wbudowane w prawdziwe rodzime aplikacje ... Nie jest to w sumie moim zdaniem przydatne, ale może moje myśli ulegną zmianie, gdy będę zagłębiał się w to dalej.

+0

wszelkie aktualizacje w ankiecie? :) –

2

Appcelerator nie jest HTML5, jest natywną aplikacją zbudowaną na wyższym poziomie języka JavaScript. Usuwa złożoność wspólnych elementów i zapewnia ogromną wartość, pinguj mnie offline, aby dowiedzieć się więcej. Prowadzę działalność w Kalifornii.

Powiązane problemy