HTML5, 네이티브 및 하이브리드 모바일 앱 접근 방식의 장단점은 무엇입니까?


25

모바일 애플리케이션을 개발하고 싶습니다. 최근에 Telerik Forum 에 관한 기사를 읽었습니다.이 기사에서는 세 가지 유형의 모바일 응용 프로그램을 비교하고 어떤 것을 시작해야하는지 모르겠습니다. 다음은 다양한 모바일 디자인 선택의 장단점을 설명하는 이미지입니다.

Telerik 모바일 디자인 차트

이러한 디자인 선택을 결정하기 위해 다이어그램에 나열된 각 아키텍처 선택의 장단점을 더 잘 이해하고 싶습니다. 각 아키텍처 접근 방식의 장단점은 무엇입니까?


5
이 질문은 이 프로토 타입을 기반으로하는 것으로 보입니다 . 원래의 질문은 88 개의 답변을 받았으며 그 중 하나만이 예시 적입니다. 저자가 원래의 질문에 넣은 노력에 감사하지만 역사는 이러한 종류의 질문에 호의적이지 않았으므로 그에 따라이 질문을 끝내기로 투표했습니다.
Robert Harvey

1
@just_name 어느 것이 더 좋은지 묻는 것은 주제와 다른 것이지만 각 아키텍처 접근 방식에 대한 장단점을 요청하도록 질문을 수정했습니다. 그런 다음 질문을 다시 열었습니다. 잘하면 지금 더 나은 답변을 얻을 수 있기를 바랍니다.
maple_shaft

표현을 바탕으로 일종의 일반적인 비 노화 원칙 (예 : 배터리 수명, 연결 / 연결 끊기 등)에 대한 논의가있을 것으로 예상했습니다. 대신 다른 HTML5와 네이티브가 있습니다.
Den

당신은 찾을 수 이 문서 LinkedIn의 의사 결정 과정의 흥미에 대한합니다.
Brian

답변:


23

이 문제를 고려하는 데 많은 시간을 소비 한 모바일 개발자입니다.

왜 물어?

대부분 다음과 같은 방법으로 앱 개발 비용을 절감하고자합니다.

  • 기존 HTML5 / 자바 스크립트 개발 기술 사용
  • 여러 앱을 처음부터 작성하지 않고 여러 플랫폼 타겟팅
  • 향후 여러 코드베이스를 유지할 필요가 없습니다.

이유는 다음과 같습니다.

  • 네이티브 플랫폼 개발보다 "쉬운"것으로 인식되는 HTML5 / 자바 스크립트 개발
  • 개발자 프로그램 등록비 지불 방지
  • 앱 스토어 콘텐츠 제한 피하기 (도박 등)
  • 개발 하드웨어 구매 방지 (예 : iPhone 개발 용 Mac)

정의

언급 된 세 가지 접근 방식 각각에 의해 우리가 의미하는 바를 정확하게 설정합시다.

네이티브
일반적으로 앱 스토어에서 장치에 설치되는 앱입니다 (때로는 사이드로드 할 수 있음). 이 논의의 목적으로, 기본 앱의 UI는 일반적으로 전체 화면 웹뷰만으로 구성되지 않습니다.

모바일 웹
이것은 실제로 모든 웹 페이지가 될 수 있지만,이 토론에서는 기본 앱의 모양과 느낌을 모방하려는 단일 페이지 웹 앱을 고려해 보겠습니다. 기본 앱이 아니며 장치의 브라우저에서 실행됩니다.

하이브리드
하이브리드 앱 instanceof기본 앱.

대부분의 사람들은 하이브리드 앱을 단일 페이지 모바일 웹 앱으로 이해하지만 (기본 앱의 모양과 느낌을 모방 할 가능성이 높지만) 기본 서비스 (la Phonegap)에 액세스 할 수있는 기본 앱으로 패키지되어 있습니다.

그러나 Phonegap 모델과 완전 네이티브 모델 사이에는 스펙트럼이 있습니다.

모바일 웹

기술 제한 사항
먼저 수행중인 작업에 따라 모바일 웹 앱에 대한 기술적 제한 사항을 나열 할 수 있습니다.

  • HTML / 캔버스 UI 만
  • 특정 장치 이벤트 및 서비스에 액세스 할 수 없음 (일반적으로 문서화 됨)
  • 앱 스토어에 상장 할 수 없음 (검색 가능성에 영향을 미침)
  • iOS에서 전체 화면으로 전환되고 홈 화면 아이콘이 표시 될 수 있지만 이는 대부분의 사용자에게 특이하고 생소한 경험입니다.

위의 모든 내용을 적용 할 수 있다면 단일 페이지 기본 스타일 웹 앱의 문제에 대해 자세히 읽어보십시오. 그러나이 섹션은 FT 앱을 참조하지 않으면 완료되지 않습니다.

파이낸셜 타임스 FT 웹 응용 프로그램은 응용 프로그램이 스타일의 유명한 예이다. 영국 가디언 신문의 흥미로운 기능은 다음과 같습니다.

공학의 놀라운 업적입니다. 현재 iOS에서만 계속 사용할 수 있습니다. 이것은 고급 크로스 브라우저 개발 문제를 해결하는 것이 실제로 매우 어렵다는 것을 알게되었습니다.

단일 페이지 기본 스타일 웹 앱

이 섹션은 모바일 웹 및 Phonegap 스타일 앱 모두에 적용됩니다.

웹 앱 내에서 기본 스타일의 룩앤필은 일반적으로 사용할 수있는 UI 구성 요소를 제공하는 Sencha Touch 와 같은 프레임 워크를 통해 달성됩니다 .

이러한 프레임 워크는 매우 간단한 UI에 적합합니다. 그러나 유연성이 부족합니다. Sencha를 사용하여 기본 앱 디자인을 구현할 수 없으므로 프레임 워크가 수용 할 수있는 내용에 맞게 디자인을 조정해야합니다.

이러한 프레임 워크가 겪는 주된 방법은 플랫폼 자체의 UI 복잡성을 모방하는 것입니다. iPhone의 목록 끝으로 스크롤했을 때 얻는 멋진 수신 거부 효과는 무엇입니까? 프레임 워크는 Javascript에서이를 에뮬레이션해야합니다. 완전히 재생산하는 것은 불가능하며 속도가 느려질 수 있으며 사용자는 일종의 네이티브처럼 보이지만 명확하지 않고 비 기술적 인 앱의 "고르지 않은 계곡"에 갇히게됩니다 사용자는 정확히 왜 손가락을 댈 수 없습니다.

"HTML5 / 자바 스크립트는 쉽다"신화

웹 브라우저 내의 장치 조각화는 거의 없으며 가장 기본적인 HTML 및 CSS를 넘어 서면 예상대로 작동하지 않는 것을 알 수 있습니다. UI 문제를 기본적으로 두 배 이상 절약했을 때보 다 더 까다로운 UI 문제를 해결하는 데 더 많은 시간을 소비 할 수 있습니다. 네이티브가는 경우 네이티브 앱 웹뷰는 장치 브라우저와 동일 하지 않으며 자체 조각화 문제가 있습니다.

그리고 앱이 기능적으로 복잡 해짐에 따라 Javascript를 깨끗하고 유지 관리 할 수있게하려면 기본 jquery 기술 이상이 필요하다는 것을 알게 될 것입니다.

즉,이 방법으로 간단하고 기능적인 앱을 매우 빠르게 만들 수 있습니다. 그러나 앱이이를 수행 할 때는 분명합니다.

스펙트럼을 따라 더

따라서 모든 것을 처음부터 여러 번 작성하지 않고도 Phonegap 스타일 앱보다 더 나은 UX를 원합니다. 우리는 무엇을 할 수 있습니까?

비 UI 코드 공유

여러 기본 플랫폼에서 비즈니스 로직을 공유하는 데 사용할 수있는 다양한 기술이 있습니다. Google은 Java를 Objective-C로 변환하는 J2ObjC 를 시작했습니다 . 코드를 신중하게 고려하면 Android와 iOS 모두에서 Java 라이브러리를 사용할 수 있습니다.

CalatravaKirin 과 같은 라이브러리를 사용하면 Javascript로 작성된 코드베이스 (및 Javascript로 컴파일 할 수있는 모든 것)를 기본 코드에서 조작 할 수 있습니다. 면책 조항 : Kirin을 만든 미래 플랫폼에서 일합니다. 우리는 Java에서 GWT를 사용하여 Java에서 생성 된 Javascript를 사용하여 iOS에서 성공적으로 사용했으며 Java 코드도 기본적으로 Android에서 실행되었습니다.

필요한 경우 웹뷰 사용 ...

전체 화면 웹뷰는 화면 전환 및 바운스 효과를 모방하기 위해해야 ​​할 일이 많습니다. 그러나 기본 앱 크롬 내부의 웹보기는 기본과 구별 할 수 없습니다.

기본 앱과 웹뷰가 통신 할 수있는 잘 문서화 된 표준 방법이 있습니다.

이러한 방식으로 수행하면 목록과 테이블이 특히 잘 작동 할 수 있지만 텍스트 입력은 기본적으로 가장 잘 처리 된 것의 예입니다 (키보드를 완전히 제어하기 위해).

요약해서 말하자면

귀하에게 맞는 접근 방식은 앱이 얼마나 복잡한 지, 만족할만한 수준의 UI 광택에 달려 있습니다.

나의 좌우명 : 가능한 한 웹뷰를 사용하지만 사용자가 말할 수 없도록하십시오 .


2
좋은 답변입니다! 그리고 당신이 J2ObjC에 대해 이야기 한 것을 잘 알고 있습니다.
momo

4

먼저이 설문 조사 를 통해 무슨 일이 일어나고 있는지 알 수 있습니다!

세 가지 유형의 비교 : 모바일 애플리케이션 개발 옵션 이해

네이티브와 hyprid의 비교 :

HTML5와 네이티브

HTML5 대 네이티브 앱 : 선택할 수있는 ??

이 사람은 정말 좋은 : HTML5의 V 네이티브 응용 프로그램 : 주요 고려 사항 모바일 전략

코멘트:

  • 당신이 그들 중 하나를 위해 갈 수있는 것은 당신이 가지고있는 기술에 달려 있습니다.
  • 모든 모바일 앱 개발자는 첫 번째 버전과 향후 버전을 위해 개발하려는 응용 프로그램에 대한 명확한 비전 / 요구 사항이 있어야합니다! 그가 사용할 옵션이 특정 시점에서 그를 제한하지 않도록하십시오.
  • 세 가지 방법에 대한 실제 경험과 동시에 최신 정보를 얻는 것만 큼 좋은 것은 없습니다. 이것은 올바른 결정을 내릴 수있는 감각과 능력을 줄 것입니다.

2

전화 하드웨어에 액세스해야하는 경우 기본 앱을 빌드해야합니다 (HTML5에서는 GPS와 같은 장치의 일부 하드웨어 구성 요소에 액세스 할 수 있음).

웹 개발에 더 익숙하다면 기본 앱을 만들지 않는 한이를 고수해야합니다.

알아야 할 한, 모든 다른 화면 크기 (수직 및 수평 방향 포함)를 명심해야한다고 말하고 싶습니다. 다양한 버전의 OS를 염두에 두어야합니다 (Android 용). 이들은 모바일 장치이므로 사용자가 전화를 받으면 전화를받을 가능성이 있으며 데스크톱 또는 서버의 컴퓨팅 성능이 없습니다.


2

소비자 앱을 작성할 때 나에게있어 성공의 가장 중요한 것은 사용자의 승인과 앱 인식입니다. 학습, 교육 및 WORA 손실 (어디서나 한 번 실행)과 관련된 추가 비용에도 불구하고 기본 앱을 선호하는 4 가지 이유는 다음과 같습니다.

  1. 더 빠른 앱 시작
  2. 부드러운 스크롤
  3. 나머지 OS 및 앱과보다 일관되게 연결되는보다 일관성있는 앱 UI
  4. 더 빠른 앱 UI 응답

무엇보다 원하는 것은 앱이 시장에서 성공할 수 있도록 도와주는 훌륭한 사용자 경험입니다. 물론 스킬 셋 부족, 시간 및 예산 부족은 예외입니다. 때때로 앱은 이러한 것들에 대해 그다지 신경 쓰지 않을 제한된 비즈니스 사용자 세트를 대상으로합니다.

Facebook이 IOS 및 Android 용 기본 앱을 선호하여 앱 전략을 버린 것은 다음과 유사한 이유입니다.

읽어주세요:

Mark Zuckerberg : HTML5에서 가장 큰 실수가 너무 많이 걸었습니다 http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on- html5 /

Facebook이 새로운 iOS 앱을 사용하여 모바일 웹을 버리고 네이티브로 갔던 이유 http://readwrite.com/2012/08/23/how-facebook-ditched-the-mobile-web-went-native-with-its-new- ios-app # awesm = ~ o9jDrRefxdgnpS

이것이 도움이되기를 바랍니다.


2

아래 에서이 혼란에 대한 나의 입장은 하이브리드가 시작하고, 앱을 탐색하고, 고객 피드백을 신속하게 반복하고 기능 세트를 안정화하는 것이 좋습니다. 그런 다음 사양에 따라 기본 앱을 다시 작성하여 경험을 향상시킵니다.

모바일 웹은 완전히 다른 목적으로 사용되기 때문에 제외했습니다. 앱 스토어에 참여하려면 Native / Hybrid를 사용하십시오. 배포를 단순화하고 경험과 기술 능력을 기꺼이 희생하려는 경우 모바일 웹으로 이동하십시오.

프로 / 단점 기본 :

  • 찬성 : 그것은 장치 경험의 나머지 부분에 적합하며, 거친 계곡 문제는 없습니다 .
  • 장점 : 주로 일관된 UI 환경과 지연 시간, 끊김 현상이 없습니다.
  • 장점 : 기술적 인 제한이 거의 없으므로 장치를 완전히 활용할 수 있습니다.
  • Pro : 기본 도구는 앱 스토어 유효성 검사를 준수합니다.
  • 장점 : 기본 프레임 워크에는 플랫폼 버전 당 조정이 포함되어 미세 조정에 소요되는 시간이 줄어 듭니다.
  • 단점 : 오래 지속되는 빌드이므로 빌드하는 데 시간이 더 걸립니다.
  • 단점 : 찾기가 어렵고 비용이 많이 드는 폴리 글 로트 개발자가 필요합니다.
  • 단점 : 각 장치 플랫폼 API (iOS / Android / etc)를 숙지해야합니다.
  • 단점 : 가파른 학습 곡선.
  • 단점 : 플랫폼마다 다른 툴셋.

프로 / 단점 하이브리드 :

  • Pro : 여러 장치 플랫폼을 대상으로하는 단일 코드베이스
  • Pro : 빠른 개발주기, 뛰어난 레이아웃 기능, 프로토 타입 및 MVP에 적합 합니다.
  • 장점 : 편안한 학습 곡선, 많은 문서, 프레임 워크가 도움이됩니다.
  • 장점 : 단일 개발 툴셋. 크롬 디버거 도구는 훌륭합니다.
  • Pro : 여러 장치 플랫폼을 대상으로하는 하나의 코드베이스.
  • 전문가 : 많은 개발자가 이용 가능하고 배우기 쉽습니다.
  • 단점 : 모든 플랫폼에 맞게 UI를 조정하여 장치 환경과 일치하도록 적절한 UI 프레임 워크가 필요합니다. Kendo UI , Sencha Touch 와 같은 솔루션이 있습니다 .
  • 단점 : 메모리와 컴퓨팅 사용량에 대해 매우 신중해야하며 일부 CSS, 자바 스크립트 루프는 앱 속도를 심각하게 늦출 수 있습니다. 장치에서 디버깅 할 때 사용할 수있는 도구는 그리 좋지 않습니다.
  • 단점 : 아직 성숙하지는 않았지만 상황이 갑자기 바뀔 수 있으며 도구가 향상되고 있습니다.

2

모바일 개발자이기 때문에 최악의 상황은 오프라인 액세스입니다. 단순히 사용자가 온라인 상태가되게하여 많은 앱에서 작동해야하지만 전부는 아닙니다.

또 다른 큰 나쁜 측면은 속도 저하입니다. 원격 데이터를 구문 분석하는 데 시간이 오래 걸릴 수 있습니다. 예,로드 시간 동안 데이터를 프리 페치 할 수 있지만 다른 모든 경우에는 속도 저하를 피할 수 없습니다.

나는 그러한 앱이 네이티브 앱보다 앱이 더 비싸다는 것을 알았습니다. 나는 더 이상 내 고객에게 추천하지 않습니다.


1

하이브리드 앱의 큰 문제는 프레임 워크의 단편화입니다. 관심있는 네이티브 모바일 플랫폼 (보통 Android 및 iOS)보다 훨씬 더 많은 프레임 워크 (Ionic, Xamarin, React Native 등)가 있습니다. 이러한 프레임 워크는 경쟁, 등장, 쇠퇴하므로 하이브리드 팀이 되더라도 현재 팀을 평생 동안 유지할 계획이더라도 플랫폼에서 플랫폼으로 점프하지 않아도됩니다.

Google과 Apple은 편집기, 디버거, 테스트 프레임 워크, 리팩토링 도구 및 기타 플랫폼 개발 도구를 제공하고 지원하는 데 최선을 다하고 있습니다. 따라서 나는 합리적인 예약으로 " 하이브리드 앱을 개발하고, 좋아하는 편집기로 편집하고, 브라우저에서 여는 것이 훨씬 쉽다 "라는 전형적인 문구를 사용합니다 . Xamarin과 React Native는 Swift 나 Java / Android와 같은 개발 플랫폼이며 "hello world"는 더 짧아 보일 수 있지만 결국 제대로 배우려면 비슷한 시간이 걸립니다.

어쨌든 기본 구성 요소가 필요한 경우 (예 : 기존 타사 라이브러리를 통합해야 함) iOS, Android 및 하이브리드 프레임 워크가 두 개가 아닌 세 가지 프레임 워크로 끝납니다. 더 복잡한 아키텍처. 이러한 앱을 디버깅하고, 계층 간 호출간에 스테핑하고, 모든 계층을 기록하고, 코드를 동기화 상태로 유지하는 것은 때때로 불가능합니다.

어떤 사람들은 " 앱이 모든 플랫폼에서 똑같이 보일 것 "이라고 말합니다 . 정말 좋은가요? Android 앱은 Android 앱과 같아야하고 iOS 앱은 iOS 앱과 같아야합니다.

새로운 기능은 어떻습니까? 웨어러블? 이제 Android 플랫폼에서 제공하는 인스턴트 앱? 외부 디스플레이에 추가 데이터를 표시하고 있습니까? 하이브리드 앱은 이제 많은 기본 기능을 지원하지만 실제로 모든 기능을 지원 합니까? 언제든지, 즉시?

마지막으로 성능 및 사용자 경험뿐만 아니라 보안도 기본 앱 측면에서 더 중요 할 수 있습니다. 하이브리드 프레임 워크는 자체 버그, 보안 버그 등을 포함 할 수있는 간접 계층을 추가합니다.

위의 결론을 모두 선택하면 선택의 여지가 있지만 두 가지 기본 앱, iOS 용과 Android 용 중 하나를 선택하거나 플랫폼에 대한 앱 개발을 전혀 신경 쓰지 않고 단순히 웹 사이트의 모바일 버전을 디자인 할 것입니다. .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.