모바일 크로스플랫폼 기술之下的 변과 불변

一.크로스플랫폼, 어떤 플랫폼을 크로스하고 싶은가?

현재 (2020/7/18)来看，모바일 크로스플랫폼 수요는 주로 다음에 집중되어 있습니다:

• PC 단과 모바일 단의 크로스:PC 에서 무선으로의 전환 초기,PC Web 과 모바일 Web 이 동일한 코드를 재사용하기를 원함

• Native 와 Web 의 크로스:상품 상세 페이지 등은 단외에서 액세스할 수 있는 기능이 거의 비슷한 Web 페이지가 필요하며,Native App 과 Web 을 크로스할 필요가 있음

• Native 쌍단의 크로스:개발 효율 등의 이유로,Android,iOS 쌍단에서 한 세트의 업무 코드를 재사용하기를 원함

• App 의 크로스:일부 제품 기능은 여러 채널에서 투입上线되기를 기대하며,도구 류 수요가 주로,예를 들어 택시 배차,표 구매,주문 등

예측 가능한 미래에는,이러한 크로스플랫폼 수요도 있을 수 있습니다:

• 경량 애플리케이션의 크로스:시스템 급 즉시 사용 즉시 퇴장의 경량 애플리케이션,예를 들어 Android 快应用、iOS App Clips

• IoT 기기의 크로스:각종 디스플레이가 있는 기기가 새로운 "단"이 될 수 있음,예를 들어 차량 장비,스마트 홈

• 일체의 클라이언트의 크로스:가짜 수요일 수 있음,동일 제품은 다른 플랫폼에서 중점이 다르며,아마도 모든 기능을 완전히 다양한 클라이언트 기기/플랫폼 채널에 옮길 필요는 없을 수 있음,예를 들어 快应用 과 Native App 의 위치付け는 분명히 다름

이러한 시대 배경 하에서, 리소스 비용, 개발 효율, 제품 이터레이션, 기술 진화의 어떤 각도에서 보더라도, 크로스플랫폼 개발은 강한 수요이므로, 그래서 계속적으로 다양한 크로스플랫폼 방안 탐색이 생겨나고 있습니다

二.계속적으로 생겨나는 크로스플랫폼 기술

최근 몇 년 업계 주류의 모바일 크로스플랫폼 방안을 세세히 세어보면, 대체로 3 류로 나눌 수 있습니다:

• Web 은 태어날 때부터 크로스플랫폼:브라우저 또는 WebView 만 있으면,Web 기술에 의지하여 쉽게 크로스플랫폼 가능,예를 들어 Web App、PWA(Progressive Web Apps)、Hybrid App、PHA(Progress Hybrid App)

• 컨테이너화 Native 크로스 단:Native App 을 표준화된 컨테이너로 개조하여,한 세트의 코드가 여러 단의 표준 컨테이너에서 실행 가능하도록 함,예를 들어 React Native/Weex、Flutter

• 小程序一碼多投 크로스 App:국내 시장에서,점점 더 많은 슈퍼 App 이 小程序를 지원하고 있지만,각자의 小程序 프레임워크에는 통일 표준이 없으며,그래서 Taro、kbone、uni-app 등 일련의 크로스 小程序 프레임워크 방안이 크로스 App 투입 제품 기능 수요를 만족시키기 위해 생겨남

크로스플랫폼:Web 은 与生俱来

크로스플랫폼은 Web 이 与生俱来인 우위로,브라우저와 WebView 는 모두 W3C 규범 하의 표준화 Web 컨테이너이므로,Web 페이지는 단외 브라우저,단내 WebView,및 기타 App 이 제공하는 WebView 에 쉽게 투입될 수 있습니다

단순히 비용 각도에서만 보더라도,Web 방안은 크로스플랫폼의 不二의 선택입니다:

• 추가 학습 비용 없음:한 세트의 기초 기술로 단내,단외,심지어 PC 브라우저,TV 셋톱박스까지 모두 커버 가능

• 특수한配套设施에 의존하지 않음:개발,디버그,구축,릴리스,모니터링,운용 보수 등 모든 공산화環節은 공통적

• 방대한 기존 생태를 보유:npm 백만 모듈,무엇이나 있음

• Web 은 개방 표준에 기반:走出去引进来도 어려운 일이 아님

게다가,Web 자체가 하나의 플랫폼이며,退可守,기술 리스크도 더 낮음

하지만,다른 몇 가지 측면에서는,Web 기술에 의지한 크로스 단에는 그한계성도 존재합니다:

• 플랫폼 능력:Web 표준 컨테이너에 제한받아,플랫폼 능력 관련 수요를 만족시킬 수 없음,예를 들어 카메라,블루투스,멀티미디어 등

• 체험:모바일 단 Web 체험은 Native 에 훨씬 미치지 못하며,주로 첫 화면 로딩 느림,애니메이션卡顿,긴 페이지 스크롤 閃光 등 장면에 구현

• 성능:메모리 소비 큼,GPU 활용률 낮음

게다가 Web 표준 更迭은 느리고,새 특성의 호환성은 나쁨 (예를 들어 Push API 는 과거 여러 해가 지났어도,여전히 안심하고 사용할 수 없음),Web 기초 능력은 Native 단의 수요를 만족시키기 어려움.따라서,전통적인 Web App 의基础上에서,더 많은 탐색이 전개됨:

• PWA(Progressive Web Apps):오프라인 캐시,시스템 알림,메인 화면 아이콘 등 類 Native App 능력加持之下的 Web App,하지만 호환성은 낙관적이지 않음

• Hybrid App:Web 과 Native 혼합의 방안,Native 가 구현하는 플랫폼 능력 (예를 들어 QR 코드 스캔) 을 WebView 환경에 주입하여 Web App 이 사용하도록 하여,Web 의 플랫폼 능력을 확장

• PHA(Progressive Hybrid App):PWA 와 Hybrid 사상의 결합,Hybrid 수단을 통해 Web 의 성능과 체험을 Native 에 가깝게 함

PWA 표준화는 似乎 통하지 않으며,비록 통한다 해도 진정으로 안심하고 사용할 수 있게 되려면 아마도 수년 후일 것임.Hybrid App 은 일부 문제를 해결했지만 (플랫폼 능력 확장),아직 충분하지 않음.PHA 는 이 두 가지思路의 연속으로,Native 기술을 통해 PWA 의 꿈을 실현함

하지만 PHA 든 HA 든,Native 의존을 도입하는 것은 Web 개방성의 손실을 의미하며,이어서 크로스 단,크로스 App 측면의 문제를 가져옴

크로스 단:컨테이너화 Native

Web 의 천연 크로스 단之外,또 다른 다단을 통일하는思路는Native 를 표준 컨테이너로定制하여,동일한 코드를一个个의 표준 컨테이너에서 실행하는 것으로,예를 들어:

• Android 컨테이너:Native 껍질 App

• iOS 컨테이너:Native 껍질 App

• Web 컨테이너:Web Runtime

React Native 는 Android,iOS,Web,Windows 4 단을 크로스하며,Weex 는 Android,iOS,Web 3 단을 크로스하며,Flutter 는 유사한 방식으로 Android,iOS,Web,Linux 4 단을 크로스함

기술의 각도에서 보면,RN 과 Weex 는 Native 컨테이너 중에서 JavaScript 실행 환경,및 레이아웃 엔진을 제공하며,렌더링 층은 모두 Native 控件을 채택하므로,UI 상호작용上에서 여전히 시스템 차이가 존재함.한편 Flutter 방안은 더 철저하며,렌더링 층도 그래픽 엔진 기반의 自绘 UI 控件으로 바꿔,이를 통해 UI 상호작용의 크로스 단 일관성을 보증함

하지만, 컨테이너화 Native 의 방안은 Native 에서 출발하여,크로스 단의 天赋이 없음으로,Web 를 지원하는 방법을 생각하는之外,더 어려운 문제를 직면함——크로스 App

크로스 App:小程序一碼多投

기술의 视角下에서,小程序 크로스 Native App 은 여전히 Web 방안에 의지하는데,那么,왜 직접 Web App 을 사용하지 않는가?

상업 경쟁 등의 因素로,남의 영토에 闯入하는 Web App 은 일반적으로 몇 가지 제한에 직면함,예를 들어 안전 경고,권한 제어,심지어 액세스 금지까지 (그래서 口令 공유 등의弯弯绕绕 방식이 생겨남)

小程序는 다르며,그 初衷은 개방적이며,모두의 입주를 환영함 (물론,룰을 지켜야 함),게다가 국내의 많은 대형 App 도相继 小程序 능력을 개방하여, 小程序는 점차 크로스 App 의 정규적인 방식이 되고 있음.하지만 小程序 플랫폼이 많아진 후,프레임워크 표준이 통일되지 않은 문제도 노출되었으며,모두 小程序라고 부르지만,모두 大同小異하여,그래서,어떻게 빠르게多种의 小程序를 産出할지는 탐색할 만한 기술 과제가 됨

구현 원리上에서는 두 가지로 나뉘며,컴파일 변환과 런타임 적응으로,전자는 原生小程序와 동등한 성능을 달성할 수 있지만诸多의 제한을 가져옴 (컴파일기에 식별하기 어려운 쓰기는 모두 지원하지 않음),기존의 Web App 은 그렇게 쉽게 크로스 App 小程序로 迁移하기 어려움,예를 들어 Taro,uni-app 등.후자는 성능을 희생하여 더 많은 가능성을 换取하며,기존의 Web App 은 비교적 쉽게 迁移할 수 있음,예를 들어 Taro Next,kbone 등

P.S.물론,动静 결합의思路도 있을 수 있음,이상적인情况下,대부분의 기초 업무는 런타임 平迁을 수행하고,개별의 고성능 요구 부분은 컴파일 변환을 수행함

三.重重变化之中，무엇이 불변량인가?

채널/단/플랫폼,업무 코드,공산화配套设施는 모두 빠르게 변화하는ようで,어느 것이 穩定不變한 것은 없음

既然모두가 변화한다면,각도를 바꿔서 보면, 어느 부분이 반드시 변화하는가?

• 컨테이너:새로운 채널/단/플랫폼은 모두 새로운 컨테이너

• 크로스 컨테이너 기술:새 컨테이너의 출현은,새로운 크로스 컨테이너 기술 요구를 의미함

어느 부분은跟着변화할 필요가 없는가?

• 업무 코드:기술 방안의 更迭,새로운 채널/단/플랫폼의 출현은,일반적으로 업무 코드의 迁移를 동반함,Native 에서 React Native 에서 Flutter 로……乐此不疲,하지만 비용에서 보면,업무 코드는 반드시 跟着변화할 필요는 없고,또한 应该でもない

• 공산화配套设施:대부분은 기술 스택과 강관련,예를 들어 Web App 의 개발,디버그,구축,릴리스,모니터링,운용 보수는 Native App 과 诸多의 차이가 존재함,하지만 그 중에서 더 기초적인 부분은 기술 무관이며,프로세스 관련의,예를 들어 구축 - 릴리스 프로세스,모니터링 운용 보수 서비스 등은跟着변화할 필요는 없음

• 컨테이너 중의 플랫폼 능력:어떠한 크로스 컨테이너 방안이라도,플랫폼 능력 확장 수요는 일관하며,대응하는 Native 모듈 封裝은跟着변화해서는 안 됨

업무 코드 迁移의 비용은 매우 높으며 (기술 스택 변화를 涉及할 때는 더 아픔),配套设施의 推倒重建도 절대 대工程임,那么, 이러한跟着변화해서는 안 되는 부분을 고정할 방법이 있는가?

有, 변화하는 부분을 추상화하여 제거함.구체에 의존하지 않고 추상에 의존하면,상층은跟着변화할 필요는 없음:

표준 프레임   \
---------  |  配套设施
표준 컨테이너   /

이러한 추상 모델 하에서,상층 업무 코드는 표준 업무 프레임에 의존하고,직접 컨테이너 능력에 의존하지 않음으로써,이를 통해 업무 프레임 이하의 부분이 교체 가능해짐.업무 프레임은 추상적인 표준 컨테이너에 의존하고,구체적인 특정 컨테이너에 綁定되지 않으며,컨테이너 표준에 준수하는 기타 컨테이너로 교체 가능

표준 프레임에 기반하여,配套의 발판,컴포넌트 庫,가시화搭建 등의配套 개발 도구를 제공할 수 있음.표준 컨테이너에 기반하여,성능 진단,이벤트 추적 등의配套 디버그 능력을 확립할 수 있으며,이를 통해 공산화의 전체 링크를 커버하고,配套设施도 거의跟着변화할 필요는 없음

플랫폼 능력 확장至于,표준 컨테이너 중의 중요 부분으로서,표준 API 를 추상해야 함 (브라우저가 제공하는 BOM 系 API 에 类比),상층 업무가 사용함

四.크로스플랫폼 기술의 미래

미래는 예측할 수 없음,그래서 여기에 몇 가지 가능성을 던짐:

• 모바일 크로스 단은 Native 양단만 크로스:많은 모바일 제품而言,체험이 섬세하고 성능이 우수한 Native App 은 여전히 현재 가장 중요한应用 형태이며,게다가쌍단 기능이 완전히 일관하며,동등하게 중요하므로,Native Android,iOS 양단만 크로스하고,모바일 단 Native 개발을 통일하는 것은 비교적 합리적인 방안

• 小程序 크로스 App 은 自成一体:만약 小程序가 진정으로 표준화할 수 없다면,크로스 App 투입 수요가 催生하는 크로스 小程序 프레임워크 방안은 존재할 필요가 있음

• Web 은 여전히 Web,Hybrid 은 여전히 지속:Web 특성 更迭 주기는 너무 길고,모바일 기기의 更迭은 너무 느려,Web 의 년 단위의 진화 속도를 기다릴 수 없으며,Native 에 의지하여 Web 을 증강하는 Hybrid 과도 방안은 장기적으로 "과도"し続ける 가능성이 높음

P.S.小程序는 이미 표준화 프로세스 중에 있으며,小程序 프레임워크가 표준화된 컨테이너가 되는 것도 불가능하지는 않음,毕竟 小程序 프레임워크는 WebView,브라우저 같은 느린 주기 저항이 존재하지 않음

한 방으로 천하를 먹어치우는 크로스 전단 방안은看好하지 않음,왜냐하면 universal 컴포넌트든 universal API 든 최소 교집합이며,실제 수요를 만족시킬 수 없기 때문.게다가, 진정으로 한 세트의 코드를 모든 채널,단,플랫폼에서 실행시킬 필요가 있는가?

동일 제품은 다른 플랫폼에서 중점이 다르며,아마도 모든 기능을 완전히 다양한 클라이언트 기기/플랫폼 채널에 옮길 필요는 없을 수 있음,예를 들어 快应用 과 Native App 의 위치付け는 분명히 다름

참고 자료

• Why Rax?