배경
인터넷 기술의 지속적인 혁신과 TV 산업의 급속한 발전으로 인해 TV를 통해 온라인 비디오를 시청하는 것이 점차 대중의 중요한 엔터테인먼트 방법이 되었습니다. TV 기기에서 사용자 활동이 가장 많은 애플리케이션 중 하나인 Kiwi 앱은 사용자에게 풍부한 콘텐츠 재생 서비스를 제공합니다. 또한 회원 운영, 특별 이벤트 및 매우 높은 온라인 사용자 효율성을 요구하는 기타 서비스도 제공합니다. 후자의 요구를 충족시키기 위해 현재 주류인 동적 및 크로스엔드 기술인 H5, Flutter 및 React Native를 조사했으며 최종적으로 개발 효율성, 인건비, 동적 기능 및 성능 측면에서 H5 솔루션을 선택했습니다. H5 페이지는 Kiwi 앱에서 수많은 계산원, 운영 활동, 특별 주제 및 기타 비즈니스를 처리합니다. 그러나 우리가 직면한 가장 큰 어려움은 H5 페이지가 TV 장치에 로드되는 데 너무 오랜 시간이 걸린다는 점입니다. TV 장치에서 H5 페이지의 사용자 경험을 어떻게 개선할 것인가는 우리가 시급히 해결해야 할 문제입니다.
직면한 과제
과제 1: TV 장비의 교체 주기가 길고 시스템 단편화 문제가 심각합니다. 현재 TV 시스템이 5.0 이하인 장비가 약 30%를 차지하여 매우 높은 비율을 차지하고 있습니다. 최적화에서 가장 먼저 직면하는 것은 버전의 범위이며, 하위 버전과의 호환성이 주요 고려 사항입니다. 다음 그림은 TV 시스템 버전의 비율을 보여줍니다.
과제 2: TV 장비의 성능이 낮습니다. TV 장비는 주로 TV, 박스, 프로젝터의 세 가지 유형으로 구분됩니다. 위 장비의 구성은 같은 기간의 주류 휴대폰 구성보다 심각하게 낮습니다. 분류에 따르면 CPU는 코어 A53 아키텍처를 탑재한 4A 기기이며, 1.5G 이상의 메모리는 고성능 기기로 분류할 수 있다. 저성능 기기 중에는 아직 A7 아키텍처 프로세서나 512M 메모리를 탑재한 기기가 많다.
과제 3: 현재 TV 산업의 협력 상황이 복잡하기 때문에 앱 버전이 심각하게 세분화되어 있습니다. 기존 TV 제조업체는 안정성을 추구하고 있으며 저렴한 기기를 많이 판매하고 있습니다. 판매 후 유지 관리가 거의 필요하지 않습니다. 협력 모델의 복잡성으로 인해 많은 사용자 정의가 필요하고 업그레이드가 어려워 SDK 수준에서 최적화 및 출시에 큰 어려움을 겪습니다.
최적화 과정
1. 준비
최적화에 앞서 가장 중요한 작업은 성능 수준을 통일하고 통계 지표를 공식화하는 것입니다. 수준에서는 기존의 프런트엔드 페이지 로딩 시간을 취하지 않고, 사용자가 버튼을 클릭하는 시점부터 실제 화면에 표시되는 시점까지 사용자의 실제 경험에 더 부합하는 시나리오를 채택했습니다. 사용자. 이로 인해 통계 지표의 전체 시간 소비가 증가하지만 평가 후 이 지표는 후속 최적화 작업 방향에 더 도움이 됩니다. 표시기 구경은 다음과 같이 설명됩니다.
1) 페이지가 표시되는 데 걸리는 시간: 클라이언트에서 시작하여 클릭 -> 클라이언트 페이지 점프 -> 웹 컨테이너 초기화 -> 프런트 엔드 DOM 렌더링이 완료되어 표시됩니다.
2 ) 총 상호 작용 시간: 페이지 표시 시간 + 사용자의 리모컨 버튼에 응답할 수 있는 총 시간입니다.
3) 기본 페이지 시간 소모적: 클라이언트 페이지 이동 시간 소모적입니다.
4) Webview 초기화: 웹 컨테이너 초기화에는 시간이 많이 걸립니다.
5) h5를 호출하는 데 시간이 걸립니다. loadUrl부터 h5까지 코드의 첫 번째 줄을 실행하는 데 시간이 걸립니다.
6) h5를 로드하는 데 걸리는 시간: h5가 코드의 첫 번째 줄을 실행하기 시작하여 페이지에 표시될 때까지 걸리는 시간입니다.
7) h5가 상호작용하는 데 시간이 걸립니다. h5 페이지가 표시되고 페이지가 반응하는 데 시간이 걸립니다.
통계 기준이 통일된 후 webSDK 수준에서 위 시점을 전달하고 온라인 데이터를 수집하며 지표에서 피드백된 이슈를 기반으로 타겟 최적화를 수행할 예정입니다. 최적화가 없으면 H5의 로딩 속도는 평균 약 5.5초이며 사용자 경험은 매우 좋지 않습니다. 온라인 데이터 분석을 통해 H5 로딩 시간은 전체에서 큰 부분을 차지합니다. H5 로딩 시간 최적화 는 우리가 시급히 해결해야 할 문제입니다.
2. H5 로딩 시간 최적화
H5 로딩 시간은 주로 프런트 엔드 부분의 최적화에 따라 달라집니다. 기사의 길이가 제한되어 있기 때문에 기존의 H5 페이지 최적화 작업은 다음과 같이 자세히 설명하지 않습니다.
5) 동일한 주소에서 다른 모드로 비동기 라우팅 로딩
3. SSR 최적화
위의 최적화 외에도 SSR(Server-Side Pre-Rendering) 기술이 눈에 띕니다. SSR은 웹 애플리케이션 성능과 SEO를 최적화하는 기술로, 서버 측에서 초기 HTML을 생성하여 페이지 로딩 속도를 향상시킵니다. 검색 엔진 성능. 최적화 및 사용자 경험. 적절한 프레임워크를 선택하고, 경로를 생성하고, 구성 요소를 작성하고, 서버 구성 및 데이터 수집을 수행함으로써 개발자는 서버 측 렌더링을 구현할 수 있으므로 사용자에게 더 나은 웹 애플리케이션 경험을 제공하고 첫 화면의 더 빠른 렌더링을 보장할 수 있습니다.
최종 처리 압력을 줄이는 이 방법은 TV 최종 장비의 성능이 좋지 않은 시나리오에 매우 적합합니다. SSR에도 자체적인 단점이 있지만, 예를 들어 페이지의 전체 로딩 속도를 향상시킬 수는 있지만 페이지의 점진적인 로딩에는 도움이 되지 않습니다. 반복적인 실험과 온라인 데이터를 통해 우리는 여전히 SSR의 전반적인 이점이 긍정적이라고 믿고 연구 개발을 시작했습니다. 실험을 통해 SSR 솔루션이 H5 페이지의 로딩 속도를 크게 향상시키는 것으로 입증되었습니다.
SSR을 통해 최적화된 H5 페이지 로딩 프로세스는 아래 그림과 같습니다.
위에서 언급한 프런트엔드 솔루션을 최적화한 후 각 버전의 로딩 속도가 크게 향상되었습니다. H5 렌더링 부분에 소요되는 시간은 평균 4초에서 1.5초 미만으로 단축되었으며, 총 시간도 약 3.5초로 단축되었습니다. 이때 순수하게 프론트엔드 관점에서 최적화를 계속하다 보면 병목 현상이 발생하게 되고, 입출력 비율도 낮아지게 되어 클라이언트 전체의 관점에서 최적화 방법을 계속해서 고민할 필요가 있습니다.
4. 리소스 오프라인 캐싱
CDN은 일부 주요 H5 리소스(예: CSS, js, png, ttf 등)를 배포합니다. 이 리소스 중 다수는 프런트엔드 버전 주기 동안 변경되지 않고 크기가 크며, 클라이언트는 적절한 시간에 이를 사전 다운로드합니다. . 페이지를 렌더링할 때 WebView 커널의 shouldInterceptRequest 콜백을 사용하여 온라인 H5 URL의 로드 요청을 가로챌 수 있습니다. 리소스가 오프라인 캐시에 없으면 온라인 네트워크를 통해 로드됩니다. 오프라인 캐시에 있는 리소스는 로컬 디스크에서 직접 로드되어 WebView로 돌아갑니다. 이 방법을 사용하면 리소스 로딩 속도를 크게 향상시킬 수 있습니다.
오프라인 캐싱 솔루션의 일반적인 흐름도는 다음과 같습니다.
동시에, 이 과정에서 우리는 하위 버전의 안드로이드 네이티브 요청 라이브러리인 HttpUrlConnection이 여전히 http1.0 단계에 있고, 도중에 요청을 하는 http2.0의 최적화(예: 채널 재사용)를 즐길 수 없다는 것을 발견했습니다. 사전 로딩 시간이 더 많이 소요됩니다. 현재 TV측에는 5.0 이하 버전의 낮은 버전 장치가 많이 있으므로, 우리는 TV측에서 독자적으로 개발한 네트워크 라이브러리로 전환하기로 결정했습니다. 이 네트워크 라이브러리는 http2.0을 지원하여 요청 성능을 향상시켰습니다. 낮은 버전의 장치. 또한 사용자가 클릭한 시점부터 H5 페이지가 열릴 때까지 일정한 시스템 스케줄링 시간이 있음을 알 수 있습니다. 이 시간은 아래에서 언급하는 최적화, 즉 병렬 로딩에도 사용될 수 있습니다.
5. 병렬 로딩
위에서 언급한 JS/CSS 및 기타 리소스를 미리 캐싱하는 솔루션 외에도 HTML 페이지를 미리 캐싱하는 것도 페이지가 SSR이 되기 전에는 업계에서 일반적인 최적화 방법입니다. 성능 병목 현상은 페이지 SSR 이후에 다시 우리의 시야에 들어왔습니다. 렌더링 데이터가 생성된 후에는 이러한 캐싱 메커니즘이 이론적으로 더 큰 역할을 할 수 있습니다.
그러나 동시에 우리는 비즈니스에서 개인화된 알고리즘이 널리 사용되었기 때문에 페이지를 미리 캐싱하고 일정 기간 동안 콘텐츠를 변경하지 않고 유지하는 방법이 페이지를 유지해야 하는 비즈니스 요구 사항과 충돌을 일으켰습니다. 실시간으로 데이터가 새로 고쳐집니다. 이를 위해서는 비즈니스 시나리오에 더 적합한 최적화된 기술 솔루션을 찾아야 합니다.
Android 시스템은 활동 페이지 점프 전환을 수행할 때 시스템 시간을 소비합니다. 이 시간 소비는 장치 성능에 반비례합니다. 우리는 페이지 점프 전환 중에 사용자의 웹 페이지 클릭을 가로채서 작업을 미리 시작하고 SSR을 로드합니다. H5 페이지 병렬 데이터. 그런 다음 URL 및 쿠키 매개변수를 기반으로 고유한 토큰이 생성됩니다. WebView를 실제로 렌더링할 때가 되면 URL을 캐시로 리디렉션합니다. 동시에 다중 스레드 잠금 동기화 및 시간 초과 메커니즘을 사용하여 H5의 로딩 속도를 더욱 향상시킵니다.
병렬 로딩 솔루션의 일반적인 흐름도는 다음과 같습니다.
이러한 최적화를 완료한 후에도 로딩 속도는 3.5초에서 약 2.8초로 계속 최적화되어 약 23% 증가했습니다. 위에서 언급한 일련의 최적화 조치 후에 H5 로딩 시간이 초기 평균 5.5초에서 약 2.8초로 단축되었습니다. 하지만 순수 네이티브(Native) 페이지와 비교하면 여전히 로딩 속도에 큰 격차가 있어 보다 효과적인 최적화 방법을 계속해서 모색해야 합니다. 우리는 사용자 경험을 더욱 향상시키기 위해 다양한 기술적 시도를 해왔고, 다른 기술팀과의 활발한 소통과 협력을 통해 새로운 아이디어를 얻었습니다.
6. 용기 예열
APP가 시작되고 메인 스레드가 유휴 상태일 때 WebView 엔진을 예열하고 WebView 캐시 풀을 구축하여 예열된 컨테이너를 재사용하고 WebView 로딩 속도를 향상시킬 수 있습니다. 이 최적화 전략은 주로 중~고성능 기기와 대용량 메모리를 갖춘 저성능 기기를 대상으로 합니다. 장치가 유휴 상태일 때 WebView 컨테이너를 예열하고 예열된 컨테이너를 캐시 풀에 추가합니다.
후속 사용에서는 WebView 캐시 풀에서 직접 예열된 WebView 컨테이너를 얻습니다. 이렇게 하면 웹 컨테이너와 jscore를 만드는 시간이 절약됩니다.
7. 페이지 사전 렌더링
TV 측의 H5에는 실시간 비즈니스 시나리오 제한 사항, 특히 시간에 매우 민감한 운영 활동이 있어 최적화에 특정 제한 사항이 적용됩니다. 그러나 우리는 사용자 정의하고 최적화할 수 있는 몇 가지 시나리오를 찾았습니다. 예를 들어 비회원 사용자가 회원 전용 콘텐츠를 시청할 경우 일반적으로 무료 체험 시간이 6분 정도 지나면 체험 기간이 끝나면 자동으로 이동하게 됩니다. H5로. 이러한 유형의 시나리오는 사전 렌더링에 대한 자연스러운 이점을 제공합니다. 유사한 시나리오에서 사전 렌더링은 카운트다운이 시작될 때 자동으로 트리거되어 H5 콘텐츠를 미리 로드하고 H5의 즉각적인 오프닝 효과를 얻을 수 있습니다. 아래 GIF에서 볼 수 있듯이 위쪽 그림은 최적화되지 않은 로딩 과정이고, 아래쪽 그림은 사전 렌더링 최적화의 결과로, 진정한 초 단위 실행을 달성한 결과입니다.
위의 최적화 조치를 완료하고 작년 같은 기간의 데이터를 비교한 결과, 온라인 데이터를 통해 로딩 시간이 초기 평균 비SSR 시나리오에서는 5.5초, SSR에서는 3.5초에서 더욱 단축되었음을 알 수 있습니다. 현재 평균 2초로 사용자 경험이 크게 향상되었습니다.
업적
마지막으로 최적화에 대한 AB 실험을 진행했습니다. 분할 및 평균화한 테스트 데이터에 따르면 당사의 최적화 조치로 인해 주문 생성 페이지의 전환율이 평균 약 21% 증가했으며, 결제 성공률 전환율도 평균 2.4% 증가한 것으로 나타났습니다.
주요 비즈니스 페이지의 로딩 속도와 사용자 경험을 개선하는 것이 비즈니스에 매우 직접적이고 긍정적인 영향을 미친다는 것이 실험을 통해 입증되었으며, 이는 또한 향후 최적화를 계속 추진할 수 있는 충분한 자신감과 동기를 부여합니다.
향후 계획
앞으로는 성능 지표를 더욱 줄이고 평균 페이지 시간을 2초 미만으로 제어하며 성능 저하를 제어할 수 있는 더 많은 방법을 찾을 수 있기를 바랍니다.
또한, 우리는 평균 데이터가 실제 사용자 경험을 완전히 반영하지 않는다는 점을 인지했으며, 일부 테일 사용자는 여전히 열악한 사용자 경험을 겪고 있습니다. 동시에 우리는 체크아웃 카운터와 같은 중요한 비즈니스 시나리오에 대한 맞춤형 최적화를 지속적으로 수행하여 주요 비즈니스의 로딩 속도를 더욱 향상시켜 사용자 경험과 비즈니스 전환을 지속적으로 개선할 것입니다.
이 기사는 WeChat 공개 계정인 iQIYI 기술 제품 팀(iQIYI-TP)에서 공유되었습니다.
침해가 있는 경우 [email protected]에 연락하여 삭제를 요청하세요. 이 글은 " OSC 소스 생성 계획
" 에 참여하고 있습니다 . 이 글을 읽고 계신 여러분의 많은 참여와 공유 부탁드립니다.
