크로스 플랫폼 솔루션의 3 대 곤경

서론

2018 년, Airbnb 는 React Native 의 계속 사용을 포기했습니다. 그중 주요 원인은 2 방면이 있습니다:

기술: 성숙도,配套设施/ 라이브러리 건설 비용, 첫 화면 퍼포먼스 고질적 문제 등이很好地에 해결되지 못함
팀 조직: 엔지니어 요구가 높고, 크로스 기술 스택/크로스 팀 디버그/테스트 등도 새로운 문제를 발생시킴

실제로, 크로스 플랫폼 솔루션이 조우하는 문제는 이들 뿐만 않으며, 어떤 때는 Write Once, Run Everywhere 는 단지 아름다운 소망일 뿐입니다

一.기술 곤경

한마디로 말하면, 능력 경계에 닿기 전에는, 크로스 플랫폼 솔루션 안의 모든 것은 아름답습니다

React Native 를 예로 들면:

Bridge 층은 메시지 통신을 통해 JavaScript 세계와 Native 세계를联系합니다

Shadow Tree 는 UI 효과 및 인터랙션 기능을 정의하는 데 사용되며, Native Modules 는 Native 기능 (예를 들어 블루투스) 을 제공하고, 이자間は JSON 메시지를 통해 상호 통신합니다

P.S. 그림은 다소 오래되었지만, 원리 이해에는 영향이 없습니다. 업데이트된 React Native 구조도는 React Native 구조 진화 참조

이러한 기술 구조에서는, 쓰는 것도 실제로 실행되는 것도 JavaScript 로, Native 가 제공하는 뷰 렌더링 능력 및 플랫폼 특정 능력을 호출합니다. Facebook 은 이를 Scripting native 솔루션 이라 부르고, 일단 컨테이너화 Native 크로스 플랫폼 솔루션이라 부릅니다:

Native App 을 표준화된 컨테이너로 개조하여, 그에 의해一套의 코드가 크로스 다단 표준 컨테이너에서 실행하는 것을 허용합니다. 예를 들어 React Native/Weex, Flutter

([모바일 단말 크로스 플랫폼 기술 아래의 변과 불변](/articles/모바일 단말 크로스 플랫폼 기술 아래의 변과 불변/) 에서 인용)

컨테이너 능력은很大程度上로 개발 효율을 결정합니다. 컨테이너가 일관된 표준 지원 범위를 제공한 경우, 한 사람이 다단을搞定할 수 있습니다. 그러나, 일단 능력 경계에 닿으면, 고비용의 다층 연합 개발 (Native 층, JavaScript 엔진 층, 특정 업무 영역 층, 업무 층……) 에 직면하게 되고, 인효 상에서는 우위가 없습니다. 다른 한편으로, 어떻게 다단 일관성을 유지할 것인가는, 극히 복잡하고 기술적 도전으로 가득 찬 문제입니다

게다가, 관련된配套设施도 직접 개발 효율과 관계가 있습니다:

디버그: 크로스 기술 스택 디버그는 항상 난제로, 문제排查비용은越来越高
퍼포먼스: 크로스 스레드, 크로스 페이지耗时분석이 어렵고, 퍼포먼스 툴체인이缺失
엔지니어링 링크: 기술 솔루션의 특수성으로 인해, 많은配套设施 (IDE, 디버그, 퍼포먼스, CI/CD, 모니터링 등을 포함하지만 이에 한정되지 않음) 를 맞춤형으로 제작해야 하며, 각環節의 비용을 낮출 수 있습니다

총체적으로 말하면, 기술상의 최대의 곤경은:

메울 수 없는 다단 차이

-掀을 수 없는 JavaScript 엔진 뚜껑

따라가지 못하는配套设施

다단 일관성은 기술 투입 상에서 거의 끝없는 구렁텅이로,底层의 플랫폼 구조 차이 (UI 렌더링 방식, 이벤트機制, 시스템 API) 는根深固하며, 각류 크로스 플랫폼 솔루션의 현재 성숙도로는 극히 제한된 일부만 커버할 수 있고, 매우 큰 공백이 남아 컨테이너 능력을 확장하여 메울 필요가 있습니다.通用的인 기초 능력 (UI, 인터랙션 등) 및 업무 영역面向의 특정 능력 (멀티미디어, 위치 정보 등) 을 포함합니다

JavaScript 엔진을 도입함으로써 동적으로 코드를 실행하는 능력을 획득했지만, 기술상의 불확실성도 가져왔고, JavaScript 엔진 내부의 붕괴 또는 이상 행위를 추적 해결하는 것은 거의 불가능합니다

通用的인 기초設施의大多는 직접 크로스 플랫폼 시나리오에 사용할 수 없고, 변변각각의配套设施는 모두 힘을 들여 건설할 필요가 있으며, 업무의快速生長을 만족시키기 위해, 항상 핵심关键 능력을 우선적으로 건설하고,配套サポート는 일반적으로滞後しており,同样으로 효율에 영향을 미칩니다

Flutter 는 어떤 차이를 가져올 수 있을까요?

사실, Flutter(현재看起来) 도同样으로 이러한 기술 곤경에 직면하고 있으며, 기술 실현의 변화는 국면을彻底하게 바꾸지 못했습니다

2020 Q1 조사 결과에 따르면, Flutter 개발자가 가장 중요하다고 생각하는 6 가지 문제는:

디버그 에러와 붕괴
App 이 크로스 다 플랫폼에서 실행할 수 있음을 테스트 확보
상태 관리 솔루션의選用
레이아웃 문제 (텍스트 溢出 등) 의 이해와 처리
설계도에 기반하여 UI 를 생성
특정 플랫폼 문제의排查

동시에, 가장 어렵다고 생각하는 6 가지 문제는:

특정 플랫폼 문제의排查
메모리 문제의 진단과 복구
CPU 사용률 문제의 진단과 복구
기존 Native API 의接入
UI卡顿 문제의 진단과 복구
특정 플랫폼의 Flutter 플러그인 개발

따라서, 크로스 플랫폼 솔루션의 디버그, 퍼포먼스의 아픔은 여전히 Flutter 에서 지속되며, 다단 차이 및配套设施의 곤경은 변하지 않았습니다

二.팀 조직 곤경

단단 개발 모드와 비교하여, 크로스 플랫폼 솔루션의 협업 비용은 더 높으며, 다음과 같이 체현��니다:

크로스 팀
링크가 김
컨테이너 팀의 압력이 큼
직책 경계가清晰하지 않음

크로스 플랫폼 솔루션의 아래, 크로스 팀 협업이 가장 주요한 협업 방식이 되었고, 요구사항串講, 개발, 연調, 문제排查등의 여러環節都需要크로스 팀 커뮤니케이션/협업으로, 커뮤니케이션 비용은 무시할 수 없습니다

긴 링크는기술 상세가 다층에 흩어져, 각자가一小部分의 지식만 소유함을 의미합니다:

表層業務ロジック
-----------------------------
特定業務領域フレーム워크
-----------------------------
通用フロントエンドフレーム워크/라이브러리
-----------------------------
JavaScript 엔진 (확장)
-----------------------------
Native Module | 특정 업무 영역 능력
-----------------------------
Native通用프레임워크
-----------------------------
Native View
-----------------------------
플랫폼 오퍼레이팅 시스템

각 팀이 전경을 볼 수 없기 때문에,每一个원인이 그다지 분명하지 않은 문제는 모두 한층층 아래로排查할 필요가 있으며,甚至특정 업무 영역 능력과 관련된 부분은 또 많은 층으로 나뉩니다……

다른 한편으로, 이ほど繁多한 층도복잡도의堆積을 일으키며, 아래층으로 갈수록 복잡도는 높아집니다. 불확실한 가변 입력이 많을수록, 來龍去脈을弄明白하기 어렵고, 문제排查의 비용도 높아집니다

이상적인 경우, 깔때기 모델에 따라逐層필터링하고,每一層은 자신의 입력 출력만 체크하면 되지만,滞後한配套设施로 인해表層業務가 문제所在의 범위를 식별하는 것이 어려워지고,于是컨테이너 팀이 문제流转의 필터阀가 되어, 위는紛繁한 JavaScript 업무를 받고, 아래는 복잡한 특정 영역 능력에连接합니다. 대량의 시간이來龍去脈을弄明白하는 데 소비되고, 컨테이너 능력 확장은被迫降速하며, 기知문제를反復排查합니다……

업무 시점의 아래, 업무의 아래 층의 직책划分은 그다지清晰하지 않습니다. 따라서很容易에 층/사람을 잘못 찾아, 무효한 "리다이렉트"를 발생시킵니다. 컨테이너 층도同样으로 전경 뷰를具備하고 있지 않으며, 문제流转궤적은 매우曲折해지고, 커뮤니케이션 비용은各環節에充斥하며, 개발 효율을制約합니다

三.개인 곤경

개인에게 있어서, 직면하는 최대의 어려움은크로스 플랫폼 솔루션과 Web 표준에些许의 차이가 존재하는 것이며, 이러한些许의 차이는 W3C 표준처럼清清楚楚에 쓸 수 있는 것이 아닙니다:

Weex enables developers to use modern web development skills to build Android, iOS, and Web apps with a single codebase.

즉, 通用의 Web 경험은 완전히 적용되지 않으며, 학습 곡선은 그다지友好하지 않습니다. 예를 들어:

[rem, 미디어 쿼리, scale/zoom](/articles/모바일 페이지适配方案/#articleHeader10) 등의适配경험은 반드시しも 적용되지 않습니다
DOM 조작을 줄이는, JavaScript 파일을合併하는, 하드웨어 가속을开启하는 등의常規최적화 조치도 반드시しも 명확한 퍼포먼스 최적화 효과를 낼 수 있는 것은 아닙니다
(Web 를 학습하는ように) 브라우저之上의 표준 능력만 이해하는 것만으로는 불충분하며,真로高效的에 업무 개발 일을 완성하고 싶다면, 컨테이너 원리甚至部分実装詳細도 이해할 필요가 있습니다

Native 배경을 가진 개발자가 [TypeScript](/articles/typescript 简介-typescript 笔记 1/) 를 학습하는 것과 같아서, 첫 접촉은无師自通으로, 익숙한 [Class](/articles/类-typescript 笔记 4/), Interface, [静的타입](/articles/基本类型-typescript 笔记 2/) 은游刃有余에 사용할 수 있습니다……그러나, TypeScript 를熟知하는 개발자는 반드시個中의 상세에多少의奇怪한 장소가 존재하는 것을 알고 있습니다

四.크로스 플랫폼의真의 의미란 무엇인가?

React Native 의 최초의 출발점은:

Native 개발도 Web 처럼 Move fast 할 수 있기를 희망

-快速이테레이션 (Rapid iteration cycle): Web 은 하루二版, 제품이테레이션 주기가 더 짧음 -快速피드백 (Immediate testing feedback): Web发布는즉시사용자에게届고, A/B test 등의실험결과는立等可取로, 제품진화가더빠름 -快速개발 (Rapid development velocity): 브라우저를리프레시하면生效하고, App 을再컴파일하는것을기다릴필요가없음

(React Native 簡史 에서 인용)

따라서, 요구사항의 각도에서 보면, 개발 효율은次要적이고,動態化의유연성,快速이테레이션이업무를먼저赢는것이그크로스플랫폼의주요한의미입니다.或者说생산 효율을추구しており, 개발 효율뿐만아니라, 더짧은이테레이션주기, 더快速한사용자에게届이는直接의생산 효율진보입니다

그러나, 3 대곤경의아래, 개발 효율은실제로는생산 효율에도严重影响하고있지만,快速이테레이션, 動態发布의중대한진보를抵消하기에는아직모자라며, 此消彼長도一種의밸런스, 一種의受容가능한妥協이라고할수있습니다

五.곤경중에서生門을찾다

이상적인경우, 컨테이너는標準化에趨해야하며, 다단일관, 풍부하고安定한능력サポート를제공해야합니다. 위의업무스택은극히적게컨테이너능력경계에닿아, 그에의해컨테이너층이不断优化探索하고,更好地에업무발전의需要를만족시킬수있습니다

다른한편으로, 크로스플랫폼솔루션은다단불일치성이가져오는복잡さを컨테이너층에沈澱시킨뿐이며, 플랫폼으로부터獨立한언어환경 (JavaScript 엔진, Dart 가상머신등) 은上層業務로직의일관성을보증할수있지만, 컨테이너층은여전히다단에서각자一套를実装할필요가있으며, 어떻게컨테이너능력의다단일관성을보증할것인가는여전히큰문제이며, 비크로스플랫폼솔루션의아래보다쉬운것은아닙니다

따라서, 首先要解決컨테이너능력豊富度의문제로, 경계를拓宽하고, 근본에서문제를줄입니다.转而集中火力을眞의난제에향해, 가장가치있는难点부분을攻下합니다. 동시에가상구조등의방식을통해全職能的인업무サポート팀을建立하고, 커뮤니케이션비용을低減합니다:

업무는自研能力을가질필요가있음:下層資源병목현상을化解하고, 공동으로컨테이너능력을豊富하게함
必須에大力을投入하는점에专注: 디버그능력, 표준화, 퍼포먼스분석및継続跟踪, 엔지니어링配套设施
全職能的인업무サポート팀을가질필요가있음: 모든문제를抱え込む能力이있고, 眞로一揽子解決方案을제공하며, 무의미한커뮤니케이션리다이렉트를消除함

그중에서, 업무自研能力은먼저標準的な확장방식이필요하며, 컨테이너実装上에확장하기쉽고, 업무개발자는過多의상세를了解하지않아도快速에개발에들어갈수있습니다. 디버그능력은긴링크의기술스택의아래에서극히중요하며, 문제식별비용이越低고, 准确率이越高고, 효율이越高고, 释放할수있는자원도越多해집니다

업무개발의각도에서보면, 더필요한것은一層의게이트웨이로, 리퀘스트가과거에레스폰스가��아오는것이며, 一連의루트表가아니라,一跳一跳에跟踪할필요가있습니다. 全職能的인업무サポート팀은局域網을組成하여, 게이트웨이之後의트래픽이快速에流转하는것을가능하게하고,高效的으로협업하는동시에업무개발의행복감을向上시킵니다

서론