미니 프로그램의 작동 메커니즘에 대한 간략한 분석

작성 배경

저는 한동안 작은 프로그램을 접해왔습니다. 일반적으로 작은 프로그램을 개발하기 위한 문턱은 상대적으로 낮지만, 여전히 기본적인 작동 메커니즘과 원리를 이해해야 합니다. "예를 들어 인터뷰에서 미니 프로그램에 대한 질문을 받았는데요, 미니 프로그램에 윈도우 객체가 있나요? 그렇다고 하더군요"라고 했는데 실제로는 그렇지 않습니다. 그는 미니 프로그램의 기본 사항 중 일부를 이해하지 못하는 것 같습니다. 최종 분석에서 그는 이 도구만 사용할 수 있지만 그 이유를 이해하지 못합니다.

Mini 프로그램은 일반 웹 개발과 매우 다릅니다. 이는 기술 아키텍처의 바닥부터 분석해야 합니다. 예를 들어 Vue와 React 개발에 익숙한 개발자라면 미니 프로그램을 위한 새 페이지를 만드는 것이 번거롭다고 불평할 것입니다. 페이지는 여러 파일로 구성되어야 하고, 구성 요소 지원은 불완전하며, 데이터의 데이터가 매번 업데이트됩니다. 변경되면 setData를 설정해야 합니다.Vue.Watch 모니터만큼 편리하지 않으며 Dom을 작동할 수 없어 이전에는 npm, sass 및 덜 사전 컴파일된 처리 언어를 지원하지 않았습니다.

"어떤 사람들은 미니 프로그램이 거세된 Vue와 같다고 합니다", ㅎㅎ 물론, 디자인의 출발점은 다릅니다. 우리는 또한 미니 프로그램 디자인의 원래 의도를 사용 시나리오를 통해 이해해야 하며, 왜 채택했는지도 알아야 합니다. 이 방법의 기술 아키텍처, 이 기술 아키텍처의 이점은 무엇인지 이해하고 나면 이해하게 될 것이라고 믿습니다. 다음으로 미니 프로그램의 작동 메커니즘과 전반적인 기술 아키텍처를 다음과 같은 관점에서 분석해 보겠습니다.

미니 프로그램의 기원 이해하기

미니 프로그램이 출시되기 전에 WeChat WebView는 점차적으로 모든 웹 개발자를 위한 JS-SDK라는 완전한 웹 개발 툴킷 세트를 출시했습니다. 모든 개발자가 WeChat의 기본 기능을 사용하여 이전에는 불가능했거나 어려웠던 작업을 수행할 수 있도록 새 창을 엽니다.

그러나 JS-SDK 모델은 제한된 장치 성능 및 네트워크 속도로 인해 흰색 화면이 나타날 수 있는 등 모바일 웹 페이지 사용 시 경험이 좋지 않은 문제를 해결하지 못합니다. 그래서 JS-SDK의 향상된 버전인 "WeChat 웹 리소스 오프라인 저장소"를 설계했지만, 페이지 전환의 뻣뻣함과 클릭 지연으로 인해 여전히 복잡한 페이지에서 흰색 화면이 나타나는 문제가 발생합니다. 이때 사용자 경험을 더 좋게 만들기 위해 JS-SDK에서 처리할 수 없는 시스템이 필요하게 되었고, 작은 프로그램이 탄생하게 되었습니다.

빠른 로딩

더 강력한 기능

네이티브 경험

사용하기 쉽고 안전한 WeChat 데이터 열기

효율적이고 간단한 개발

미니 프로그램과 일반 웹페이지 개발의 차이점

미니 프로그램 개발은 매우 유사합니다. 일반적인 웹 개발의 경우 소규모 프로그램의 주요 개발 언어는 JavaScript이지만 둘 사이에는 여전히 몇 가지 차이점이 있습니다.

일반 웹 개발에서는 다양한 브라우저에서 제공하는 DOM API를 사용하여 DOM 작업을 수행할 수 있습니다. 애플릿의 논리 계층과 렌더링 계층은 JSCore에서 실행되며 완전한 브라우저 개체가 없으므로 관련성이 부족합니다. DOM API 및 BOM API.

일반적인 웹 개발 렌더링 스레드와 스크립트 스레드는 상호 배타적이므로 장기간 스크립트를 실행하면 페이지가 응답하지 않을 수 있습니다. 그러나 소규모 프로그램에서는 두 스레드가 분리되어 서로 다른 스레드에서 실행됩니다.

웹 개발자가 웹 페이지를 개발할 때 브라우저와 일부 보조 도구나 편집기만 사용하면 됩니다. 미니 프로그램 개발은 미니 프로그램 계정 신청, 미니 프로그램 개발자 도구 설치, 프로젝트 구성 등의 과정을 거쳐야 합니다.

미니 프로그램 실행 환경

미니 프로그램 아키텍처

1. 기술 선택

일반적으로 렌더링 인터페이스에는 세 가지 기술이 있습니다.

렌더링에는 순수 클라이언트 측 네이티브 기술을 사용합니다

순수 사용 렌더링에는 웹 기술이 사용됩니다

클라이언트 네이티브 기술과 웹 기술(하이브리드 기술이라고 함)을 결합한 하이브리드 기술을 사용하여 렌더링합니다

다음 측면 분석을 통해 미니 프로그램에 어떤 기술 솔루션이 사용되는지

개발 임계값 : 웹 임계값이 낮고, Native는 RN과 같은 프레임워크 지원도 있습니다

Experience: 네이티브 경험은 웹보다 훨씬 낫고, 하이브리드는 어느 정도 웹보다 네이티브 경험에 더 가깝습니다

버전 업데이트: 웹은 온라인 업데이트를 지원하며, 네이티브는 필요합니다. 검토 및 출시를 위해 WeChat에 패키징하세요

제어 및 보안: 웹은 페이지 내용을 점프하거나 변경할 수 있으며, 통제할 수 없는 요소와 보안 위험이 있습니다

미니 프로그램의 호스트 환경이 WeChat이므로, 미니 프로그램이 순수 클라이언트 측 네이티브 기술을 사용하여 작성한 다음 미니 프로그램 코드를 매번 WeChat 코드와 함께 출시해야 합니다. 이 방법은 절대 불가능합니다.

그래서 웹 기술과 마찬가지로 클라우드에서 언제든지 업데이트할 수 있는 리소스 패키지가 필요합니다. 이를 로컬에 다운로드하여 동적 실행 후 인터페이스를 렌더링할 수 있습니다. 순수한 웹 기술을 사용하여 작은 프로그램을 렌더링하는 경우 일부 복잡한 상호 작용에서 일부 성능 문제에 직면할 수 있습니다. 이는 웹 기술에서는 UI 렌더링 및 JavaScript 스크립트 실행이 단일 스레드에서 실행되어 일부 논리적 작업이 쉽게 발생할 수 있기 때문입니다. UI 렌더링 리소스를 점유합니다.

그래서 우리는 이 두 가지를 결합한 하이브리드 기술을 사용하여 작은 프로그램을 웹과 유사한 방식으로 개발할 수 있으며, 동시에 구성 요소를 도입하면 다음과 같은 이점도 있습니다. :

웹 기능을 확장하세요. 예를 들어 입력 상자 구성 요소(입력, 텍스트 영역)에는 키보드를 더 잘 제어할 수 있는 기능이 있습니다

경험이 더 좋고 WebView의 렌더링 작업도 줄어듭니다

setData, 데이터 통신 및 다시 렌더링 프로세스를 우회하여 렌더링 성능이 더 좋습니다

클라이언트 측 기본 렌더링을 사용하여 일부 복잡한 구성 요소를 구축하면 더 나은 성능을 제공할 수 있습니다

2. 듀얼 스레드 모델

애플릿의 렌더링 계층과 논리 계층은 각각 2개의 스레드로 관리됩니다. 뷰 계층의 인터페이스는 WebView를 사용합니다. 렌더링을 위해 논리 계층은 JsCore 스레드를 사용하여 JS 스크립트를 실행합니다.

그러면 왜 이렇게 설계되었을까요? 앞서 제어와 보안에 대해서도 언급했는데, 이러한 문제를 해결하려면 브라우저의 창 개체, 페이지 점프의 개방성, 운영 방식 등을 개발자가 사용하지 못하도록 해야 합니다. DOM 및 동적으로 실행되는 스크립트 인터페이스.

클라이언트 시스템의 JavaScript 엔진, iOS의 JavaScriptCore 프레임워크, Android의 Tencent x5 커널에서 제공하는 JsCore 환경을 사용할 수 있습니다.

이 샌드박스 환경은 브라우저 관련 인터페이스 없이 순수한 JavaScript 해석 및 실행 환경만을 제공합니다.

미니 프로그램의 듀얼 스레드 모델의 기원은 다음과 같습니다.

로직 레이어: JavaScript를 실행하기 위해 별도의 스레드를 만듭니다. 여기서 실행되는 것은 미니 프로그램의 비즈니스 로직과 관련된 코드이며 로직 처리를 담당합니다. , 데이터 요청, 인터페이스 호출 등

View 레이어: 인터페이스 렌더링과 관련된 모든 작업은 WebView 스레드에서 실행되며 논리 레이어 코드는 렌더링되는 인터페이스를 제어하는 ​​데 사용됩니다. 작은 프로그램에는 여러 인터페이스가 있으므로 뷰 레이어에 여러 WebView 스레드가 있습니다

JSBridge는 상위 개발과 네이티브(시스템 레이어) 사이의 브리지 역할을 하여 작은 프로그램이 API를 통해 네이티브 기능을 사용할 수 있도록 하며 일부 컴포넌트는 네이티브 컴포넌트 구현이므로 좋은 경험을 할 수 있습니다

3. 듀얼 스레드 통신

개발자의 JS 로직 코드를 별도의 스레드에 넣어 실행하지만 Webview 스레드에서는 개발자가 직접 작업할 수 없습니다. DOM.

그렇다면 인터페이스를 동적으로 변경하는 방법은 무엇일까요?

위 그림과 같이 논리 계층과 뷰 계층 간의 통신은 Native(WeChat 클라이언트)에 의해 중계되고, 논리 계층에서 보낸 네트워크 요청도 Native에 의해 전달됩니다.

간단한 데이터 통신을 통해 DOM을 업데이트할 수 있다는 의미입니다.

가상 DOM 모두가 이미 알고 있다고 생각합니다. 대략적인 프로세스입니다. JS 객체를 사용하여 DOM 트리를 시뮬레이션합니다. -> 두 가상 DOM 트리의 차이점을 비교합니다. -> 차이점을 실제 DOM 트리에 적용합니다.

그림에 표시된 대로:

WXML을 렌더링 레이어의 해당 JS 객체로 변환합니다.

논리 계층에서 데이터 변경이 발생하면 호스트 환경에서 제공하는 setData 메서드를 통해 논리 계층에서 Native로 데이터가 전송된 후 렌더링 계층으로 전달됩니다.

전후 차이점을 비교한 후 원본 DOM 트리에 차이점을 적용하고 인터페이스를 업데이트합니다.

WXML을 데이터로 변환하고 Native를 통해 전달함으로써 로직 레이어와 렌더링 레이어 간의 상호 작용과 통신을 구현합니다.

이러한 완전한 프레임워크는 미니 프로그램의 기본 라이브러리와 분리될 수 없습니다.

4. 미니 프로그램의 기본 라이브러리

미니 프로그램의 기본 라이브러리는 뷰 레이어와 로직 레이어에 주입하여 실행할 수 있으며 주로 다음과 같은 측면에서 사용됩니다.

뷰 레이어에서 , 인터페이스 구축을 위한 다양한 컴포넌트가 제공됩니다. Elements

로직 레이어에서는 다양한 로직을 처리하기 위한 다양한 API가 제공됩니다

데이터 바인딩, 컴포넌트 시스템, 이벤트 시스템, 통신 시스템 등 일련의 프레임워크 로직을 처리합니다.

미니 프로그램의 렌더링 레이어와 로직 레이어는 두 개의 스레드 관리이므로 두 스레드는 각각 기본 라이브러리를 주입합니다.

미니 프로그램의 기본 라이브러리는 특정 미니 프로그램의 코드 패키지에 포함되지 않으며 사전에 WeChat 클라이언트에 내장됩니다.

이렇게 하면 다음이 가능합니다.

비즈니스 애플릿의 코드 패키지 크기를 줄입니다.

비즈니스 애플릿의 코드 패키지를 수정하지 않고도 기본 라이브러리에서만 버그를 수정할 수 있습니다.

5 Exparser 프레임워크

Exparser는 WeChat 애플릿 구성 요소 구성 프레임워크는 미니 프로그램 기본 라이브러리에 내장되어 있으며 미니 프로그램의 다양한 구성 요소에 대한 기본 지원을 제공합니다. 기본 제공 구성 요소와 사용자 정의 구성 요소를 포함하여 미니 프로그램 내의 모든 구성 요소는 Exparser에 의해 구성되고 관리됩니다.

Exparser의 주요 기능은 다음과 같습니다.

Shadow DOM 모델 기반: 이 모델은 WebComponents의 ShadowDOM과 매우 유사하지만 브라우저의 기본 지원에 의존하지 않으며 다른 기능이 없습니다. 종속 라이브러리, 구현 시에도 대상이 됩니다. 애플릿 구성 요소 프로그래밍을 지원하기 위해 추가 API가 추가되었습니다.

순수한 JS 환경에서 실행 가능: 이는 논리 계층에도 특정 구성 요소 트리 구성 기능이 있음을 의미합니다.

효율성과 경량성: 특히 구성 요소 인스턴스가 많은 환경에서 성능이 좋으며 코드 크기도 작습니다.

미니 프로그램에서 페이지의 최종 노드 트리에 대한 WXML 구성, createSelectorQuery 호출 및 사용자 정의 구성 요소 특성 등을 포함하여 모든 노드 트리 관련 작업은 Exparser에 의존합니다.

내장 컴포넌트

Exparser 프레임워크를 기반으로 하는 미니 프로그램에는 뷰 컨테이너 클래스, 폼 클래스, 탐색 클래스, 미디어 클래스, 오픈 클래스 등 수십 가지 컴포넌트를 제공하는 내장 컴포넌트 세트가 있습니다. . WXSS와 결합된 풍부한 구성 요소 세트를 사용하면 어떤 효과를 내는 인터페이스를 구축할 수 있습니다. 기능적 수준에서도 대부분의 요구 사항을 충족합니다.

6. 작동 메커니즘

애플릿이 시작될 때 두 가지 상황이 있습니다. 하나는 "콜드 스타트"이고 다른 하나는 "핫 스타트"입니다. 사용자가 이미 작은 프로그램을 열었다가 일정 시간 내에 다시 열었다면 이번에는 다시 시작할 필요가 없습니다. 단지 백그라운드에 있는 작은 프로그램을 포그라운드로 전환하기만 하면 됩니다. 콜드 스타트는 사용자의 미니 프로그램을 처음 열거나 WeChat에 의해 적극적으로 삭제된 후 다시 열 때 미니 프로그램을 다시 로드하고 시작해야 함을 의미합니다.

미니 프로그램을 다시 시작한다는 개념은 없습니다

미니 프로그램이 백그라운드로 진입하면 클라이언트는 일정 시간(현재 5분) 이후 실행 상태를 유지합니다. 위챗에 의해 적극적으로 파기될 경우

짧은 시간(5초) 내에 시스템 메모리 알람이 2회 이상 연속으로 수신되면 미니프로그램이 파기됩니다

7. 업데이트 메커니즘

새로 업데이트할 경우 미니 프로그램의 콜드 스타트 ​​중에 버전이 발견되면 코드 패키지의 새 버전이 비동기적으로 다운로드되고 클라이언트의 로컬 패키지를 사용하여 동시에 시작됩니다. 즉, 애플릿의 새 버전은 다음 콜드 스타트를 적용하기 전에. 최신 버전을 즉시 적용해야 하는 경우 wx.getUpdateManager API를 사용하여 처리할 수 있습니다.

8. 성능 최적화

주요 최적화 전략은 세 가지로 요약할 수 있습니다.

코드를 간소화하고 WXML 구조 및 JS 코드의 복잡성을 줄입니다.

setData 호출을 합리적으로 사용하여 setData 횟수를 줄입니다.

필요한 경우 하도급 최적화를 사용하세요.

1. setData 작동 방식

애플릿의 뷰 계층은 현재 WebView를 렌더링 캐리어로 사용하는 반면 논리 계층은 독립적인 JavascriptCore를 실행 환경으로 사용합니다. 구조적으로 WebView와 JavascriptCore는 독립적인 모듈이며 직접적인 데이터 공유를 위한 채널이 없습니다. 현재 뷰 레이어와 로직 레이어 간의 데이터 전송은 실제로 양 당사자가 제공하는 평가Javascript를 통해 구현됩니다. 즉, 사용자가 전송한 데이터를 문자열로 변환하여 전달해야 함과 동시에 변환된 데이터 내용을 JS 스크립트로 엮은 후 실행을 통해 양쪽의 독립된 환경에 전달해야 합니다. JS 스크립트.

evaluateJavascript의 실행은 여러 측면의 영향을 받으며 뷰 레이어에 도달하는 데이터는 실시간이 아닙니다.

2. 일반적인 setData 작업 오류

빈번한 setData 우리가 분석한 경우에 따라 일부 작은 프로그램은 setData를 매우 자주(밀리초) 수행하며 이는 두 가지 결과로 이어집니다. 피드백 지연이 심각합니다. JS 스레드가 렌더링을 컴파일하고 실행했기 때문에 사용자 작업 이벤트를 논리 계층에 적시에 전송할 수 없고 논리 계층에서 연산 처리 결과를 적시에 뷰 계층에 전송할 수 없습니다. WebView의 JS 스레드는 항상 사용 중이므로 로직 계층에서 페이지 계층까지의 통신 ​​시간이 늘어납니다. 데이터 메시지를 수신하면 전송 시간 이후 수백 밀리초가 경과되고 렌더링 결과가

모든 setData는 대량의 새로운 데이터를 전송합니다. setData의 기본 구현에서 데이터 전송이 실제로 평가Javascript

스크립트 프로세스라는 것을 알 수 있습니다. 스크립트의 컴파일 및 실행 시간이 늘어나고 WebView JS 스레드를 차지하게 됩니다. 페이지가 백그라운드 상태(사용자에게 표시되지 않음)로 전환되면 사용자는 계속해서 setData를 수행해서는 안 됩니다. 또한 배경 상태 페이지의 렌더링을 느낄 수 없습니다. 또한 배경 상태 페이지에 데이터를 설정하면 전경 페이지의 실행도 선점됩니다.

Summary

미니 프로그램의 기원부터 듀얼 스레드의 출현, 디자인, 커뮤니케이션, 기본 라이브러리, Exparser 프레임워크, 실행 메커니즘과 성능 최적화 등은 모두 서로 연관되어 있으며 선택에 상호 영향을 미칩니다. 소규모 프로그램의 기본 프레임워크 디자인에 대해 더 많은 내용이 있어야 합니다. 각 프레임워크의 탄생에는 고유한 의미가 있습니다. 개발자로서 우리가 할 수 있는 일은 이 도구를 사용할 뿐만 아니라 해당 디자인 패턴도 이해하는 것입니다. 그래야만 도구의 영향을 받지 않고 더 나아갈 수 있습니다!

위 내용은 미니 프로그램의 작동 메커니즘에 대한 간략한 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!