위 챗 애플 릿 의 응용 속 도 를 높이 는 작은 기술 에 대해 자세히 설명 하 다.

WeTest 안내
애플 릿 과학 보급 류 의 글 은 이미 매우 많 습 니 다.오늘 여기 서 말 하 는 것 은 애플 릿 에 대한 최적화 방법 으로 애플 릿 의 응답 속도 와 사용자 체험 을 효과적으로 향상 시 킬 수 있 습 니 다.물론 개발 체험 도 많이 늘 었 다.
1.페이지 로 딩 속도 향상
애플 릿 이라는 환경 에서 어떻게 페이지 로드 속 도 를 높 입 니까?이 문 제 는 매우 크다.나 는 문 제 를 구체 적 으로 살 펴 보 겠 다.어떻게 사용자 가 특정한 링크 를 클릭 할 때 부터 새로운 페이지 를 여 는 시간 까지 단축 시 킬 수 있 습 니까?여기에 핵심 관건 을 던 져 라.
페이지 에서 사용자 의 클릭 행위 에 응답 하고 점프 를 시작 합 니 다.새 페이지 onload 이벤트 가 발생 하면 지연 이 있 습 니 다.이 지연 은 100-300 ms 사이 입 니 다.(안 드 로 이 드 응답 은 ios 보다 느 립 니 다)
이 지연 은 짧 고 짧 지 않 습 니 다.우 리 는 이 시간 을 이용 하여 새 페이지 에 필요 한 네트워크 요청 을 미리 시작 할 수 있 습 니 다.이렇게 되면 100-300 ms(또는 네트워크 요청 시간)를 절약 할 수 있다.
이 gap 가 있 는 것 을 알 고 코드 는 어떻게 실현 합 니까?
말하자면 A 페이지 에 B 페이지 데 이 터 를 미리 불 러 오 는 기능 을 실현 하 는 것 이다.그러나 이러한 크로스 페이지 호출 은 논 리 를 복잡 하 게 만 들 고 서로 다른 페이지 의 논 리 를 결합 시 키 기 쉽다.따라서 우 리 는 미리 불 러 온 논 리 를 무 형 에 숨 기 고 그 어떠한 페이지 간 결합 도 증가 하지 않 으 며 복잡 도 를 개발 하고 자 합 니 다.
다음은 텐 센트 동 영상 애플 릿 을 예 로 들 어 기술 실현 에 대해 설명 한다.
애플 릿 첫 페이지:

사용자 가 포스터 그림 을 클릭 하면 다음 코드(한 줄 만)를 실행 합 니 다.

다음 프로그램 은 재생 페이지 를 불 러 옵 니 다:

재생 페이지 의 주요 코드:

외부 페이지 의 호출 이 든 실제 논리의 실현 이 든 매우 간결 하 다 는 것 을 알 수 있다.두 번 째 페이지 에서 우 리 는 Page 의 생명주기 함 수 를 확장 하고 onNavigate 방법 을 추가 했다.이 방법 은 페이지 가 곧 생 성 되 지만 아직 생 성 되 지 않 았 을 때 실 행 됩 니 다.
늙 은 기 사 는 이곳 이 좀 이상 하 다 는 것 을 알 게 될 것 이다.첫 페이지 를 클릭 할 때 재생 페이지 가 생 성 되 지 않 았 고 대상 이 존재 하지 않 았 습 니 다.어떻게 안에 접근 하 는 방법 입 니까?
위 챗 의 페이지 메커니즘 을 말씀 드 리 겠 습 니 다.
애플 릿 이 시 작 될 때 페이지()방법 을 호출 하 는 모든 object 를 하나의 대기 열 에 저장 합 니 다(아래 그림).페이지 에 접근 할 때마다 위 챗 은 새로운 대상 인 스 턴 스 를 다시 만 듭 니 다.
즉,A 페이지 에서 클릭 응답 이 벤트 를 실행 할 때 B 페이지 의 인 스 턴 스 가 생 성 되 지 않 았 고 이때 호출 된 onNavigate 방법 은 사실상 Page 대상 의 프로 토 타 입(애플 릿 시작 시 생 성 된 것)이다.
다음 에 곧 만 들 B 페이지 는 또 다른 object 입 니 다.따라서 onNavigate 와 onLoad 방법 에서 this 지침 은 같은 대상 이 아니 라 임시 데 이 터 를 현재 object 에 저장 할 수 없습니다.그래서 우 리 는 전역 캐 시 방법 인$put()와$take()를 패키지 했다.

유 니 버 설 을 위해 페이지 에 사용 되 는 공공 방법,예 를 들 어$route,$put,$take 는 모두 페이지 의 기본 클래스 에 정의 되 어 있 습 니 다.기본 클래스 는 모든 페이지 의 list 를 동시에 저장 하여 페이지 이름 에 따라 구체 적 인 페이지 의 onNavigate 방법 을 호출 할 수 있 습 니 다.물론 모든 페이지 가 onNavigate 방법 을 실현 해 야 하 는 것 은 아 닙 니 다.onNavigate 방법 이 정의 되 지 않 은 경우$route 함 수 는 미리 불 러 오 는 절 차 를 뛰 어 넘 고 페이지 를 직접 뛰 어 넘 습 니 다.그래서 개발 자 에 게 다른 페이지 가 무엇 을 실현 하 는 지 에 관심 을 가 질 필요 가 없고 대외 적 으로 보면 완전히 투명 하 다.
2.사용자 행동 예측
위의 예 에서 우 리 는 사용자 가 자발적으로 페이지 를 클릭 하여 다음 페이지 의 데 이 터 를 미리 불 러 오 는 방법 을 실현 했다.일부 장면 에서 사용자 의 행 위 는 사용자 가 클릭 하지 않 았 을 때 다음 페이지 의 데 이 터 를 미리 불 러 올 수 있 음 을 예측 할 수 있다.다음 페이지 를 초 단위 로 열 어 체험 의 유창 성 을 한층 더 향상 시 킵 니 다.
계속해서 텐 센트 동 영상 애플 릿 을 예 로 들 면 메 인 화면 은 3 개의 페이지 카드(대부분의 애플 릿 이 이렇게 설계 된다)로 나 뉘 는데 간단 한 데이터 분석 을 통 해 첫 페이지 에 들 어간 사용자 의 50%가 두 번 째 페이지 카드 를 방문 하 는 것 을 발견 했다.따라서 두 번 째 페이지 카드 의 데 이 터 를 미리 불 러 오 면 사용자 가 다음 페이지 를 클릭 하 는 속 도 를 어느 정도 높 일 수 있 습 니 다.
마찬가지 로 코드 실현 부터 살 펴 보 자.홈 페이지 에 채널 페이지 를 미리 불 러 오 는 자세:

채널 페이지 의 실현 방법:

첫 번 째 예 와 유사 합 니 다.$preLoad()방법 을 정의 하고 Page 에 onPreload 이 벤트 를 확장 합 니 다.페이지 에서$preLoad()를 호출 하면 기본 클래스 는 이 페이지 에 대응 하 는 onPreload 함 수 를 자동 으로 찾 아 페이지 에 사전 로드 작업 을 수행 하 라 고 알 립 니 다.첫 번 째 예 와 달리 미리 불 러 온 데 이 터 는 storage 에 저 장 됩 니 다.사용자 가 페이지 에 바로 접근 하지 않 고 전체 변 수 를 저장 하면 애플 릿 이 사용 하 는 메모리 가 증가 합 니 다.위 챗 은 메모리 가 너무 큰 프로그램 을 주저 하지 않 고 죽 일 것 이다.
아마도 대부분의 app 개발 경험 이 있 는 학생 들 에 게 더욱 보편적 인 방법 은 먼저 페이지 에 지난번 캐 시 된 데 이 터 를 보 여 준 다음 에 실시 간 으로 새로운 데 이 터 를 끌 어 올 린 다음 에 페이지 를 새로 고 치 는 것 이다.이 방법 은 애플 릿 에서 체험 이 좋 지 않 을 수도 있 습 니 다.애플 릿 의 성능 과 페이지 렌 더 링 속도 가 원생 app 보다 못 하기 때 문 입 니 다.큰 데 이 터 를 UI 층 에 전송 하 는 것 은 매우 무 거 운 작업 입 니 다.따라서 이런 방법 은 권장 하지 않 는 다.
3.기본 data 크기 줄 이기
방금 말 했 듯 이 페이지 가 새 페이지 를 열 때 위 챗 은 페이지 대상 을 깊이 복사 하기 때문에 기본 data 의 크기 를 최소 화하 고 대상 내 사용자 정의 속성 을 줄 여야 합 니 다.그림 도 있 고 진실 도 있다.

100 개의 속성 을 가 진 data 대상 을 테스트 사례 로 아이 폰 6 에 서 는 페이지 생 성 시간 이 150 ms 증가 합 니 다.
4.구성 요소 화 방안
위 챗 은 애플 릿 의 구성 요소 화 방안 을 제공 하지 않 았 습 니 다.그러나 구성 요 소 를 말 하지 않 고 아무리 많은 코드 를 써 도 소용없다.간단 한 구성 요소 화 실현 을 보 여 줍 니 다.
텐 센트 영상 재생 페이지 를 예 로 들 면 페이지 의 정 의 는 다음 과 같다.

그 중에서 P()함 수 는 사용자 정의 기본 클래스 입 니 다.이것 은 매우 유용 한 것 으로 모든 통용 되 는 논 리 를 기본 클래스 에 쓸 수 있 습 니 다.pv 통계,소스 통계,수명 주기 함수 확장,구성 요소 화 등 을 포함 합 니 다.
함수 의 첫 번 째 매개 변 수 는 페이지 이름 으로 페이지 의 key 입 니 다.두 번 째 는 page 대상 입 니 다.그 중에서 cops 배열 을 확 장 했 습 니 다.그 안에 불 러 올 모든 구성 요소 가 있 습 니 다.
재생 기 구성 요소/cops/player/index.js 를 예 로 들 면:

구성 요소 의 정 의 는 일반 Page 대상 과 똑 같 습 니 다.data 속성,onLoad,onShow 등 이벤트 도 있 고 페이지 응답 을 되 돌 리 는 방법 도 있 습 니 다.wxml 템 플 릿 에서 정 의 된 이벤트 와 js 이벤트 가 일일이 대응 합 니 다.
기본 클래스 에서 하 는 일 은 이 구성 요소 대상 의 속성 과 방법 을 Page 대상 에 복사 하 는 것 입 니 다(얕 은 복사).그 중에서 data 속성 은 merge 로 합 쳐 집 니 다.위 챗 이 미리 정의 한 생명주기 함수(자신 이 확장 한 것 포함)는 대기 열 로 봉 하여 순서대로 실행 합 니 다.예 를 들 어 시스템 이 onLoad 방법 을 호출 할 때 실제 적 으로 모든 구성 요소 의 onLoad 방법 을 실 행 했 고 마지막 으로 Page 의 onLoad 를 실 행 했 습 니 다.
이상 은 코드 부분 입 니 다.wxml 템 플 릿 과 wxss 부분 은 수 동 으로 import 해 야 합 니 다.
wxml：

wxss：

5.기타
작은 프로그램 은 충분히 작 지만 시작 속 도 는 2-3 초 로 초 를 켤 수 없다.건물 주 는 작은 프로그램의 시작 시간 을 최적화 하려 고 시 도 했 지만 가치 있 는 최적화 점 을 별로 찾 지 못 했다.단일 페이지 의 초기 화 는 1-2ms 만 필요 합 니 다.아마도 대부분의 시간 이 위 챗 과 서버 측 이 통신 하 는 과정 에서 소모 되 었 을 것 이다.
다행히 텐 센트 는 자체 적 으로 서버 성능 테스트 를 할 수 있 는 환경 을 제공 했다.사용 자 는 도 메 인 이름과 간단 한 몇 개의 매개 변수 만 작성 하면 자신의 서버 성능 상황 을 알 수 있 고 현재 텐 센트 위 테스트 플랫폼 에서 무료 로 사용 할 수 있다.
이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.