모바일 개발 아키텍처에 대한 매우 상세하지만 결정적인 가이드

네이티브, 웹, PWA, 하이브리드, 크로스 컴파일… Android 및 iOS 플랫폼을위한 "최상의"방법은 무엇입니까? 무엇이 합리적으로 보입니까? 그리고 옵션 중에서 어떻게 선택해야합니까? 이 기사에서는 정보를 바탕으로 결정을 내릴 수 있도록 모든 내용을 설명하겠습니다.

먼저, 약간의 맥락을 알려 드리겠습니다. 저는 IT 수석 컨설턴트이며이 가이드를 구성한다는 아이디어는 고객 중 한 사람과 가장 적합한 방법에 대한 토론에서 시작되었습니다. 그렇습니다. 그리고 우리는 정답을 도출하는 데 도움이되는 잘 정의 된 전략, 견고하고 안정적인 기반이 없다는 것을 깨달았습니다.

그리고 당신은 무엇을 알고 있습니까? 인터넷 어디에서나 그러한 안내서를 쉽게 찾을 수 없었습니다. 이 주제에 관한 몇 가지 기사가 있지만, 내가 본 기사 중 어느 것도 합리적으로 완성되지 않았습니다. 불행히도 대다수는 많은 개념을 간과하거나 심지어 더 나쁜 것은 본질적으로 잘못된 것입니다.

이제 더 넓게보고 싶습니다. 또한 누군가 자신의 결정을 내리는 데 도움을 줄 수있을뿐만 아니라이 주제에 대해 더 많은 의견을 구하기 위해 커뮤니티를 둘러보고 있습니다.

이 안내서는 두 부분으로 구성됩니다.

  1. 모바일 개발 아키텍처 계층 (this)
  2. 결정하는 방법

YouTube에서 10 개의 비디오 시리즈로 제공되며 Udemy의 무료 과정으로도 제공됩니다. 여기에서 동일한 주제의 기사, YouTube 시리즈의 동일한 동영상 및 모든 주제를 수정하는 퀴즈 및 최종 인증을 찾을 수 있습니다.

이제 시작하겠습니다.

소개

모바일 플랫폼에 관해서는 안드로이드와 iOS의 두 가지 큰 플레이어가 있다고 주장 할 수 있습니다. Tizen, Blackberry 또는 Windows Phone과 같은 다른 기술은 이미 사용되지 않았거나 오랫동안 사용되어 왔으며 상당한 시장 점유율에 도달 할 가능성이 없습니다.

이 거대한 듀오 폴리를 간단히 살펴보면 개발자가 모바일 앱을 만들 때 많은 옵션이 없다고 생각할 수 있습니다. 그러나이 아이디어는 진실에서 멀어 질 수 없습니다. C / C ++, Java, Kotlin, Objective-C, Swift, JavaScript, TypeScript, C #, Dart, Ruby와 같이 사용되는 수많은 프로그래밍 언어를 신속하게 발견 할 수 있습니다. 더.

모바일 개발 프레임 워크도 마찬가지입니다. 개발자가 아니거나 지난 10 년 동안 새로운 기술을 모르는 경우가 아니면 Cordova / PhoneGap, React Native, Xamarin, Ionic, Nativescript 또는 Flutter에 대해 들어 보셨을 것입니다. 모바일 앱을위한 플랫폼 솔루션.

자,이 아키텍처의 모든 부분을 살펴보고 약간 세분화하겠습니다.

TL; DR

확실한 승자는 없습니다. 모든 접근 방식에는 장단점이 있으며 다음 프로젝트에 가장 적합하거나 가장 적합 할 수 있습니다. 이 가이드에서는 아키텍처가 기본 플랫폼과 거리에 따라 다양한 솔루션을 여러 계층으로 분류하고 있습니다.

기본 앱

시작하려면 금속으로 곧장 가십시오. 첫 번째 아키텍처 계층은 기본 앱입니다.

Native Apps Tier — 각 특정 플랫폼을 위해 개발하는 곳 (NDK를 고려할 때 더 구체적 일 수 있음)

각 플랫폼의 고유성을 인식해야하는 계층입니다. 그들에게 파고 드는 것은 나의 의도가 아니며, 단지 약간의 맥락에서 몇 가지를 언급하고 싶습니다.

iOS

iOS 측면에서 시작하면 더 간단하기 때문에 세계를 지배하는 Apple 만 있습니다. 원래 개발자는 SmallTalk (및 엄청나게 긴 이름의 API)에서 영감을 얻은 C의 독점 객체 지향 변형 인 Objective-C를 배워야했습니다.

2014 년에 애플은 멀티 패러다임 언어 인 스위프트 (Swift)를 발표했다. Objective-C 레거시 코드를 처리하는 것은 여전히 ​​가능하지만 Swift는 높은 성숙도 수준에 도달했습니다. 따라서 iOS 용 기본 개발 방법을 배우려는 경우 Swift가 시작해야 할 곳입니다.

기계적 인조 인간

안드로이드 측면에는 여러 제조업체가 있습니다. 대부분은 ARM 프로세서에 의존합니다. 그러나 일반적으로 Android 앱은 가상 머신 인스턴스 (ART의 인스턴스)를 기반으로 잠재적 인 기본 특성을 처리하는 데 도움이됩니다 (많은 놀라운 트릭이 없음).

이것이 원래 선택한 언어가 Java 인 이유입니다. 이 언어는 거의 20 년 동안 세계에서 가장 인기있는 언어 일뿐 아니라 (C와 몇 개의 위치 스왑으로) Java JVM (Java Virtual Machine)으로도 유명합니다. 이를 통해 개발자는 JVM에서 읽고 실행할 수있는 중간 바이트 코드로 코드를 컴파일 할 수있었습니다.

NDK (Android Native Development Kit)를 사용하면 C / C ++로 작성하여 앱의 중요한 부분을 네이티브 코드로 직접 개발할 수도 있습니다. 이 경우 기본 플랫폼 문제를 알고 있어야합니다.

Kotlin은 JetBrains에서 2011 년에 공개 한 언어입니다. 유연성과 간결함에도 불구하고 Scala, Clojure 또는 Groovy와 같은 더 성공적인 경쟁 업체를 갖춘 또 다른 JVM 언어는 아닙니다. 그러나 2016 년 첫 번째 주요 릴리스 이후, 특히 Google이 2017 년 I / O 2017의 Android 플랫폼에서 공식적으로 지원 될 것이라고 발표 한 이후에 빠르게 눈에 띄기 시작했습니다.

Kotlin은 Google의 첫 번째 언어가되고 있습니다 (현재 Kotlin과 Java는이 순서대로 Android 공식 문서 전체에서 사용됨). 미연방 항소 법원이 구글이 Java 저작권을 침해했다고 고발 한 오라클의 끝없는 소송에 판결을 내렸다.

기본 구성 요소

이 계층에서 개발하면 모든 기본 API, 특히 기본 구성 요소를 활용할 수도 있습니다. 이렇게하면 앱이 휠을 재발견 할 필요가 없습니다.

Xcode (iOS) 및 Android Studio에서 간단한 프로젝트를 만드는 방법에 대한 비디오 데모를 게시했습니다. 당신이 그것을 확인하려면 :

기본 앱의 장점

  • 최고의 성능과 최고의 사용자 참여
  • 최첨단 기본 기능
  • 특히 좋은 IDEs Android Studio / Xcode
  • 현대적인 고급 언어 Kotlin / Swift
  • NDK를 통한 매우 낮은 수준의 접근 방식

기본 앱의 단점

  • 유지할 두 개의 코드베이스
  • 설치 필요 (Android Instant Apps 제외)
  • SEO를 분석하기 어렵다
  • 사용자가 앱을 다운로드하도록하는 데 비용이 많이 듭니다

웹앱

스펙트럼의 반대편에는 Web Apps가 있습니다. 웹 앱은 기본적으로 브라우저에서 실행하는 앱입니다. 플랫폼을 대상으로하는 코드를 작성하는 것이 아니라 그 위에 실행되는 모든 브라우저를 작성하십시오.

Web Apps Tier — Android와 iOS 사이에있는 짐승을 대상으로하는 브라우저 막대 위에 있습니다.

이 단계에서는 서로의 목을 뛰어 넘는 미친 경쟁자를 찾을 수 있습니다. 그러나 그들은 모두 같은 무기로 구성된 무기고를 사용합니다 : HTML, CSS, Javascript.

웹 프레임 워크 및 라이브러리, 심지어 LESS 또는 SASS와 같은 CSS 프리 컴파일러, TypeScript, CoffeeScript 또는 Flow와 같은 자바 스크립트 사전 컴파일 된 언어, JSX 또는 Elm과 같은 공생 언어를 활용하는 경우에도 Babel과 같은 도구는 모든 것을 다른 자바 스크립트로 변환하는 데 사용됩니다. ECMAScript 연간 사양 (ES6 / ES7 / ES8 또는 ES2015 / ES2016 / ES2017 / ES2018을 선호하는 경우)에 따라 구성 가능한 수준의 적합성.

하루가 끝나면 브라우저에서 렌더링하고 실행하는 HTML, CSS 및 JavaScript입니다. 카메라, 진동, 배터리 상태 또는 파일 시스템과 같은 기본 API에 직접 액세스 할 수는 없지만 Web API를 통해 일부 API를 얻을 수 있습니다.

웹 플랫폼 기능을 사용하여 앱을 빌드 할 수 있습니까?

웹 API의 가장 큰 문제는 성숙도입니다. 일부는 일부 브라우저에서 지원되지 않습니다. 특히 모바일 브라우저마다 구현에 차이가 있습니다.

웹앱 장점

  • 플랫폼과 데스크탑 브라우저 간의 공유 코드
  • 이전 설치가 필요하지 않고 탐색하고 사용하십시오.
  • 함께 사용할 수있는 수많은 프레임 워크와 라이브러리
  • SEO에 가장 적합

웹앱 단점

  • 성능 저하
  • 기본 사용자 경험을 얻기 어렵다
  • 인터넷 연결이 필요합니다
  • 공식 앱 스토어에서는 사용할 수 없습니다
  • 기본 API만큼 성숙하지 않고 신뢰할 수있는 API

프레임 워크 및 웹 구성 요소

Angular, React 및 Vue는 2018 년 현재 가장 인기있는 웹 프레임 워크 일 것입니다. 그러나 React는 유연하고 의견이 적은 특성으로 인해 라이브러리로만 간주됩니다. 반면 각도는 강력하게 평가 된 프레임 워크입니다. Vue는 그들 사이의 어느 시점에 산다.

각도 대 반응 대 Vue

원래 AngularJS라고 불리는 Angular는 2010 년 Google에 의해 전세계에 소개되었습니다. 그 당시 다른 라이브러리와 비교할 때 패러다임의 역전으로 인해 빠르게 빛을 발하기 시작했습니다 (jQuery와 같은 당시 가장 인기있는). AngularJS를 사용하여 UI 상태를 조작하기 위해 HTML 요소와 직접 대화하는 대신 JavaScript 모델이 업데이트 될 때마다 템플릿이 마술처럼 업데이트되었습니다.

AngularJS가 점점 더 대중화되면서 목적도 커졌습니다. SPA (Single Page Apps)를 가장 중요하게 생각한 첫 번째 프레임 워크 중 하나 인 완전하고 의견이 많은 프레임 워크로 바뀌 었습니다. 이 두 가지 측면에서 이러한 성장은 일부 API 팽창 및 성능 문제를 야기했습니다.

React는 프레젠테이션 레이어에서 자신의 요구를 해결하기 위해 Facebook에서 만들었습니다. 가상 DOM, 일방적 인 데이터 흐름 (원래 Flux, 특히 Redux라는 구현 라이브러리를 통해 널리 사용됨), HTML과 JavaScript가 JSX라는 혼합형 등 갑자기 인기가 높아지는 여러 측면을 소개했습니다.

2016 년에 오랜 논쟁과 예상치 못한 큰 변화 끝에 Google은 인기있는 웹 프레임 워크의 두 번째 버전을 출시했습니다. 그들은 AngularJS 대신 Angular라고 불렀습니다. 그러나 많은 사람들이 이미 첫 번째 버전 인 "Angular"( "JS"접미사 없음)를 불렀기 때문에 사람들은 새로운 버전 인 Angular 2를 호출하기 시작했습니다. 6 개월.

제 생각에는 그것은 엄청난 실수였습니다. 전에 이것을 보았습니다 (예를 들어 Struts vs Struts 2 / WebWork). 그들은 인기가 높은 제품을 가지고 있으며 고원에 도달 한 것으로 보이며 칭찬보다 더 비판을 받기 시작했습니다. Google이 처음부터 다시 빌드하기로 결정한 경우 절대로 주 버전을 변경해서는 안됩니다. 사람들은 새로운 주요 버전이 출시 될 때마다 반복하지 않을 것이라고 어떻게 신뢰합니까? 버전 2는 주요 변경 사항을 제시하지만 완전히 개정 할 수있는 것은 아닙니다.

Angular는 훌륭한 웹 프레임 워크이며 정말 열정적입니다. 그러나 완전히 새로운 짐승입니다. AngularJS와는 관련이 없습니다. 또 다른 놀라운 프레임 워크 인 Vue조차 (아마도 작업하기에 가장 즐거운 중 하나 일 것입니다) 조감도에서 AngularJS와 더 유사합니다. 나는 이것이 Angular에서 멀어지게 움직이며 React의 인기에 크게 기여했다고 생각합니다.

Vue는 대기업이 지원하지 않는 가장 널리 사용되는 3 가지 웹 프레임 워크 중 하나입니다. 실제로 전 Google 개발자가 시작했습니다. 강력한 단순성과 작은 설치 공간으로 인해 대규모의 열정적 인 커뮤니티에서 주목을 받았습니다.

더 완벽한 솔루션이 있지만 모두 웹 구성 요소 개념 위에서 작동합니다. W3C에서 현재 진행중인 사양과 Polymer, Stencil 및 X-Tag와 같은 흥미로운 구현이 있습니다.

이 시리즈의 세 번째 비디오에서는 프레임 워크에 대해 많은 시간을 소비하지 않고 웹 구성 요소 라이브러리에 대해 설명합니다.

모바일 앱과 웹 앱

눈치 채 셨는지 모르겠지만 여기서 제시하는 계층 순서는 모든 접근 방식을 배우는 가장 쉬운 방법이라고 생각합니다. 가장 진정한 모바일 개발 인 Native Tier에서 시작했습니다. 그런 다음 첫 번째 스마트 폰 이후 사용 가능한 계층 인 웹 계층을 제시하기 위해 다른 극단으로 직접 비행하기로 결정했습니다.

이제는 다이어그램의 두 가장자리를 비교 한 후 모바일 앱을 구축하기위한 여러 플랫폼 간 접근 방법에 대해 이야기 할 것입니다.

모바일 앱과 웹 앱 간에는 오랜 논쟁이있었습니다. 모바일 앱에 대해 내가 말하는 모든 것은 기본 계층에만 국한되지 않습니다. 또한 나중에 제시 할 모든 크로스 플랫폼 계층에도 적용됩니다.

사용자 행동 딜레마

사용자는 모바일 웹 사이트 (13 %)보다 모바일 앱 (87 %)에 더 많은 시간을 보냅니다

2017 년 Comscore 설문 조사에 따르면, 모바일 앱에 대한 사용자의 충실도는 모바일 웹 사이트보다 훨씬 관련성이 높습니다. Forbes의 정렬 된 기사에 따르면, 이는 일반적으로 편의성 (예 : 홈 화면 버튼, 위젯, 상단 알림), 속도 (예 : 더 부드러운 인터페이스, 거의 즉각적인 시작) 및 저장된 설정 (예 : 오프라인) 때문입니다. 함유량).

모바일 웹 사이트가 더 많은 사람들에게 도달 (3.3M의 모바일 앱에 대한 월간 순 방문자수 890 만 명)

반면, 동일한 Comscore 데이터에서 고객은 선호하는 소수의 앱과 관련이 없기 때문에 모바일 웹 사이트에서 고객에게 더 쉽게 도달 할 수 있음을 알게됩니다. 가장 인기있는 웹 사이트와 가장 많이 다운로드 한 앱을 비교하면 한 달에 평균 890 만 명의 순 웹 방문자가 상위 1000 개의 웹 사이트에 액세스하는 것으로 추정됩니다. 이는 가장 많이 다운로드 된 상위 1000 개 앱의 평균 순 사용자보다 거의 3 배나 많은 수치입니다.

배포 (웹앱) x 참여 (모바일 앱)

이것이 배포와 참여에 관한 것입니다. 사용자가 모바일 브라우저를 탐색 할 때 새로운 것을 시도 할 가능성이 높기 때문에 웹 앱에 액세스 할 가능성이 더 높습니다. 그러나 모바일 앱은 더 매력적인 것으로 판명되었으며 훨씬 더 오랫동안 사용자의 관심을 끌었습니다.

딜레마에 대해 이해 했으므로 Progressive Web Apps를 살펴 보겠습니다. 이것은 Web Apps 계층과 연결되어 Web Apps의 부록으로 분류되는 접근 방식입니다. 그러나 그것은 웹과 모바일 개발에서 가장 눈에 띄는 새롭고 멋진 것을위한 큰 혼란과 진지한 후보자입니다.

프로그레시브 웹 애플리케이션

PWA (Progressive Web Apps)는 웹 앱 사용자가 모바일 앱을 실행할 때와 같은 경험을 제공하는 데 사용되는 도구 세트입니다. 이는 Web Apps가보다 수준 높은 참여 수준으로 잠재적으로 더 높은 수준의 배포를 활용할 수 있음을 의미합니다.

Web Apps 계층에 대한 진보적 인 Web Apps 부록

Google은 PWA에 대해 3 가지 주요 자격을 정의했습니다. 신뢰할 수 있고 빠르며 참여해야합니다.

Service Workers 및 App Shell이라는 기능은 Progressive Web Apps의 기초입니다. 장치의 연결 상태에 관계없이 작동하도록 설계되었으므로 앱의 안정성을 높이기 위해 만들어졌습니다. 여기에는 오프라인 모드와 연결 불량이 포함됩니다. 또한 앱이 로컬로 캐시 된 데이터를 사용하여 시작함으로써 동기화 된 컨텐츠 다운로드 지연을 제거함으로써 상당한 성능 향상을 제공합니다.

신뢰도는 간접적 인 참여 벡터로 간주 할 수 있습니다. 예를 들어 기차로 통근하는 동안 사용자는 영향을받지 않습니다. 그들은 계속 참여할 수 있습니다.

속도에도 동일하게 적용됩니다. 구글에 따르면 :

로드하는 데 3 초 이상 걸리는 사용자의 53 %가 사이트를 포기합니다!

그러나 독점적으로 신뢰할 수 있고 빠른로드가 반드시 높은 참여를 보장하지는 않습니다. PWA는 "홈 화면에 추가"옵션 및 푸시 알림과 같은 모바일 앱에서만 사용되었던 모바일 관련 기능을 활용합니다.

“홈 화면에 추가”기능과 관련하여 Apple은 최초의 iPhone 이후 유사한 기능을 가지고 있음을 알 수 있습니다. 일부 사람들은 Progressive Web Apps가 Apple의 독창적 인 아이디어에 대한 Google의 새로운 이름이라고 주장하기도합니다.

그리고 당신은 정말 완전히 동의 할 수 없습니다. 어떤 아이디어는 실제로 순환하고 있습니다. 그들은 와서 떠나고 새로운 이름과 개선 사항 (예 : 서비스 워커)으로 돌아와서 마침내 고수 할 수 있습니다.

반면에 완전히 동의하기는 어렵습니다. Web 2.0 + AJAX에 대한 Steve Jobs의 연설과 WWDC 2007에서 기억에 남는 iPhone의 발표는 그를 PWA의 아버지 또는 선지자로 부르기에 충분히 설득력이 없습니다.

공평하게 말하면 iPhone의 홈 화면에 추가 기능은 웹 화면을 전체 화면 모드로 시작하는 데스크탑 아이콘을 생성하는 미묘하고 거의 숨겨진 기능에 지나지 않습니다. HTTP 요청-응답주기의 모든 부담이 있으며 캐시 주변에 명확한 경로가 없습니다.

PWA는 올바른 지점에서 시작합니다. 또한 모바일 앱의 클라이언트 쪽 부트 스트랩을 잃지 않고 이전에 Web Apps를 설치하지 않아도되는 방법을 살펴 봅니다. 즉, 시작 후 사용자가 첫 번째 상호 작용에 필요한 모든 것을 로컬에 캐시하고 (읽기 : App Shell) "홈 화면에 추가"를 누르는 즉시 사용 가능할 수 있습니다.

잘 알려진 PWA의 또 다른 특징으로 넘어 가서 모바일 앱 세계의 강력한 참여 (또는 재 참여) 기능인 푸시 알림에 대해 이야기하겠습니다. 상단 알림 표시 줄 / 영역과 잠금 화면에 표시되는 경고 스타일 메시지입니다. 알림을 받으면 사용자를 앱으로 다시 끌어 올 수 있습니다.

PWA의 호소력을 강화하기 위해 Google은 모든 최신 웹 API를 PWA 우산 아래로 가져 왔습니다. 따라서 Progressive Web Apps와 관련하여 지불 요청, 자격 증명 관리, WebVR, 센서, WebAssembly 및 WebRTC와 같은 항목을 볼 수 있습니다. 그러나 이러한 기능은 반드시 PWA와 관련이있는 것은 아니며 PWA라는 용어가 만들어지기 전에 탄생 한 것도 있습니다.

PWA와 애플

반면 애플은 2018 년 3 월에만 PWA를 향한 첫 번째 이정표를 발표했다. 여전히 몇 가지 제한 사항이 있지만 진전이 인정된다. 일부 제한 사항은 Safari가 경쟁사보다 뒤떨어져 있다는 사실과 관련이있을 수 있습니다. 다른 사람들은 애플의 엄격한 통제 철학에 기인 할 수있다.

여전히 애플은 구글보다 더 수익성있는 앱 스토어를 가지고있다. 애플은 앱 출판에 대한 더 많은 기준이 전반적인 신뢰성을 높이고 PWA가 앱 스토어의 수익을 떨어 뜨릴 것이라고 주장한다. 이는 의도적으로 부과 된 일부 제한 (예 : PWA 최대 캐시 크기의 50MB)이 취소하는 데 비용이 더 많이 든다는 것을 나타냅니다.

불행히도 PWA는 완벽하지 않습니다

웹 솔루션과 다양한 수준의 모든 플랫폼 간 솔루션은 Native Apps의 우수성과 포괄적 성을 달성하기 위해 노력하고 있습니다. 모든 새로운 기능과 Android 또는 iOS에 대한 모든 세부 사항은 앱을 기본 계층에서 멀어 질수록 해당 기본 기능에 대한 액세스를 어렵고 어렵게 만듭니다.

전체적으로 PWA는 웹 애플리케이션 계층의 일부 문제를 해결합니다. 그러나 브라우저 위에서 작동하는 솔루션으로 해결할 수없는 다른 문제가 있습니다.

PWA 수정

  • 더“네이티브”경험
  • 빠른 로딩 시간
  • 인터넷 연결이 필요하지 않습니다
  • 웹 개발자가 연결이없고 연결이 잘못된 상황을 인식하도록합니다.
  • 푸시 알림, 지리적 위치 또는 음성 인식과 같은 모바일 앱의 기능 통합

그들이하지 않는 것

  • 고유의 속도 저하
  • 앱 스토어에서는 사용할 수 없습니다 (아직)
  • 여전히 모든 브라우저에서 완벽하게 지원되지는 않습니다
  • NFC, 주변 광, 지오 펜싱과 같은 모바일 기능이 여전히 부족합니다.
  • PiP, 스마트 앱 배너, 시작 화면 위젯 및 3D 터치와 같은 Android 또는 iOS의 특성에 대한 지원도 부족합니다.

아래 비디오에서는 PWA에 대해 간략하게 설명합니다.

하이브리드 앱

이 수준에서 우리는 모바일 앱 세계로 뛰어 들기 시작합니다. 가장 먼 계층 인 하이브리드 앱부터 시작하겠습니다.

하이브리드라는 용어는 일반적으로 모든 크로스 플랫폼 솔루션에도 적용됩니다. 그러나 여기서는 WebViews라는 모바일 구성 요소 내에서 작동하는 앱으로 제한하고 있습니다.

하이브리드 앱 계층. 브라우저 줄 아래이지만 WebViews 위에

두 번째 비디오의 데모에서 Hello World 예제로 WebView를 추가하려는 목적은 실제 브라우저처럼 수행 할 수있는 각 플랫폼마다 고유 한 구성 요소가 있음을 분명히하는 것이 었습니다.

코르도바 / 폰갭

Cordova / PhoneGap과 같은 솔루션은 웹과 모바일 앱 사이의 격차를 좁 힙니다. 개발자의 HTML, JavaScript 및 CSS 코드 (이미지 또는 비디오와 같은 추가 자산)를 패키지화하고이를 모바일 앱 (예, 실제 Android 또는 iOS 앱)으로 변환하는 도구를 제공합니다. 이러한 앱에는 앱의 기본 폴더 (일반적으로 "www")의 "index.html"파일부터 시작하여 원래 웹 코드를 해석하고 실행할 수있는 WebView가 있습니다. 또한 JavaScript로 부분적으로 구현되고 일부는 모국어로 플러그인을 통해 JavaScript 코드를 기본 API에 연결합니다.

자, 더 명확하게합시다. 하이브리드 앱은 웹 API 대신 기본 API에 액세스 할 수 있지만 WebView로 묶여 있습니다. Cordova가있는 버튼은 모바일 기본 버튼 대신 WebView로 렌더링 된 HTML 버튼이어야합니다.

이것은 회사가 웹 스토어를 모바일 앱으로 이식하여 앱 스토어에서 배송 할 수있게하는 마법의 계층입니다. 따라서 모든 웹 프레임 워크가 허용됩니다.

이오니아

Ionic과 같은 프레임 워크는 Cordova를 자체 솔루션으로 래핑합니다. Ionic을 사용하면 모든 명령이 Ionic CLI로 래핑되므로 Cordova의 CLI (명령 줄 인터페이스)를 사용할 필요가 없습니다.

최근에 Ionic 팀은 전체 하이브리드 앱 스택을 고치기로 결정했습니다. 그래서 그들은 Capacitor라는 Cordova를 대체 할 것을 제안했습니다. 커패시터는 Cordova 플러그인을 지원하며 비 이온 프로젝트에서도 사용할 수 있습니다.

시리즈의 다섯 번째 비디오에서 Cordova Hello World 샘플을 통과하는 것을 볼 수 있습니다.

하이브리드 앱의 장점

  • 그들은 본질적으로 공식 앱 스토어로 배송 가능한 웹 앱입니다
  • 모든 JavaScript 프레임 워크 / 라이브러리와 함께 사용할 수 있습니다
  • 코드는 여전히 여러 플랫폼에서 공유 가능합니다
  • 기본 기능 (예 : 카메라, 가속도계, 연락처 목록)에 액세스

하이브리드 앱의 단점

  • 웹보기가 모든 것을 화면에 렌더링하는 책임이 있기 때문에 성능 문제 및 메모리 소비로 어려움을 겪습니다.
  • 단일 웹보기 위에서 모든 기본 UI 구성 요소를 모방해야 함
  • App Store에서 승인 및 게시하기가 더 어렵습니다.
  • 일반적으로 이러한 환경에서 기본 기능을 사용하려면 시간이 더 걸립니다.

웹 네이티브

Web Native는 비교적 새롭고 종종 잘못 이해되는 계층입니다. Web Apps가 기본 구성 요소를 만나는 곳입니다. Appcelerator (Axway) Titanium은 오랫동안 사용되어 왔지만, 완전히 다른 카테고리의 모바일 앱으로 만드는 것을 정당화하는 비교적 새로운 경쟁자가 있습니다.

Web Native Apps는 다른 기본 구성 요소와 직접 통신하므로 WebView가 필요하지 않습니다.

위에서 볼 수 있듯이 응용 프로그램을 렌더링하고 실행할 웹 뷰가 없습니다. 그렇다면 JavaScript는 어떻게 실행됩니까? 컴파일 되었습니까? 음, 하나의 언어에서 다른 언어로의 컴파일 (예 : TypeScript에서 JavaScript 로의 컴파일), 번들링, 축소, 맹 글링 및 난독 화를 모두 컴파일로 고려하면 JavaScript가 컴파일됩니다.

그러나 문제는 이것이 Android 또는 iOS 운영 체제에서 JavaScript를 직접 이해하는 것이 아니라는 것입니다. 이론 상으로는 HTML 레이아웃 엔진의 부풀림없이 JavaScript 엔진으로 만 작동하는 기본 구성 요소는 없습니다.

전략은 코드와 함께 JavaScript 엔진 (일반적으로 Android의 경우 V8, iOS의 경우 JavaScriptCore)을 제공하는 것입니다. 크기가 작고 매우 빠르지 만 앱에서 제공해야하는 외부 항목입니다.

반면에이 접근 방식은 모든 구성 요소가 Native Apps에서 사용되는 구성 요소와 동일하거나 React Native와 동일한 것을 기반으로하므로 UI ​​성능이 향상되는 경향이 있습니다.

웹 네이티브 앱의 장점

  • 하나의 단일 코드베이스로 두 플랫폼 모두에 도달
  • 기본 UI 구성 요소도 처리하므로 기본 앱과 거의 동일한 성능
  • 조정이 필요하지만 코드는 여전히 웹 개발과 공유 가능

웹 네이티브 앱의 단점

  • 하나의 단일 코드베이스로도 개발자는 기본 구성 요소를 알고 있어야합니다
  • 웹 개발자를위한 하이브리드 / 웹 애플리케이션보다 급격한 학습 곡선, 특히 레이아웃에있어

네이티브 반응

시리즈의 6 부에서는 React Native에서 빠른 Hello World를 수행합니다. Android Studio의 Layout Inspector에서 에뮬레이터에서 렌더링 된 구성 요소를 보여줍니다. 이전 예제와 비교하여 WebView가 전혀 없음을 확인합니다.

원고

지난 2 년 동안 특히 관심을 보인 또 다른 놀라운 프레임 워크 (포르투갈어로 Udemy에 대한 과정을 가지고 있음)는 Nativescript입니다. React Native와 비슷하지만 React 세계와 관련이 없습니다 (비공식 통합 인 Nativescript-Preact가 있습니다).

Nativescript를 사용하면 바닐라 JavaScript, TypeScript, Angular 및 더 최근에는 Vue를 사용하여 개발할 수 있습니다. 물론 다른 프레임 워크를 사용할 수 있지만 공식적으로 지원되는 프레임 워크입니다. 그건 그렇고 상당히 문서화되어 있습니다.

Nativescript에는 Nativescript Sidekick 및 Nativescript Playground와 같은 도구와 커뮤니티에서 제공 할 수있는 템플릿을 기반으로하는 프로젝트 구조가 있습니다. 이를 통해 프로젝트 생성에 도움이되므로 Mac을 사용하여 개발하지 않더라도 클라우드 및 iPhone 장치에서 시뮬레이터를 시작, 배포, 테스트 및 실행할 수 있습니다.

시리즈의 일곱 번째 부분에서는 CLI에서 시작한 다른 프로젝트와 학습 목적으로 만든 WhatsApp 복제 템플릿과 함께 Sidekick을 사용하는 Hello World를 수행합니다.

앱이 Android 에뮬레이터에서 실행될 때 Layout Inspector를 살펴 보는 것이 중요합니다. Nativescript를 사용하면 기본 구성 요소 (다시 WebView 없음) 및 TextView와 같은 일반적인 Android 클래스의 직접 인스턴스가 표시됩니다. 이것은 고유 컴포넌트를 랩핑하는 자체 클래스가있는 React Native와 다릅니다.

그렇기 때문에 Nativescript가 iOS와 Android에서 새로운 기능을 사용할 수있는 시점과 Nativescript 프로젝트에서 사용할 수있는 시점 사이에 지연이 없다고 주장하는 이유 일 수 있습니다. 예를 들어, iOS 11이 새로운 ARKit API와 함께 공식적으로 출시 된 날에 AR 프로젝트를 블로그에 게시했습니다.

ex

이 범주에서 언급 할만한 또 다른 프레임 워크는 Weex입니다. Alibaba가 개발 한 프로젝트이며 현재 Apache Sofware Foundation (ASF)에서 인큐 베이트됩니다.

와 같은 일반적인 HTML 태그와