Android용 앱 시작 최적화

배경

시작 최적화를 다시 언급하는 이유는 무엇입니까? 우선, 사용자가 앱에 들어갈 수 있는 유일한 방법은 앱을 시작하는 것인데, 이는 핵심 링크를 경험할 수 있는 첫 번째 링크입니다. 스타트업은 콜드 스타트(Cold Start), 핫 스타트(Hot Start), 웜 스타트(Warm Start)로 구분되며, 별도로 지정하지 않는 한 본 문서에서 "스타트"는 콜드 스타트(Cold Start)를 의미합니다 . 시작 시간이 너무 길면 사용자 손실, 즉 콜드 스타트 ​​바운스가 발생합니다. APP 경험의 전반적인 관점에서 볼 때 스타트업은 핵심 체크포인트에 있으며 이는 매우 중요한 링크이자 APP의 핵심 지표 중 하나입니다. 비즈니스가 점점 더 복잡해짐에 따라 스타트업 과정에서 해야 할 일이 점점 더 많아지고 있으며, 많은 앱들이 원래의 스타트업 계획이 계속 악화되어 경험이 좋지 않은 문제에 직면하고 있는데 우리도 예외는 아닙니다. 스타트업 최적화는 흔한 문제입니다. 이 기사에서는 1688의 현재 상황에 초점을 맞추고 우리가 구체적으로 수행한 작업을 공유하여 여러분에게 약간의 이익을 가져다 줄 것입니다.

기술 개발 여정의 시작

스타트업 최적화에 앞서 스타트업 최적화 관련 기술의 개발 이력을 먼저 살펴보겠습니다. 처음에 windowBackground에 이미지를 추가하는 것부터 나중에 각종 작업까지, 간단하게 그림으로 표현해보겠습니다.

사진에는 ​​모두가 익히 알고 있는 몇 가지 솔루션을 간단히 나열해 보았는데, 모든 솔루션을 대표하는 것은 아니며 참고용일 뿐입니다. 스타트업 최적화를 자주 하는 친구들은 더 익숙할 수도 있습니다. 스타트업 측면에서는 많은 기업들이 노력을 아끼지 않고, 심지어 블랙 테크놀로지를 많이 사용해 성능을 짜내 최적화 결과를 달성하기도 합니다. 개발 비용이 제한된 개인이나 팀의 경우 수행하기에 적합하지 않은 작업도 있습니다. 아래에서는 제한된 비용으로 더 큰 혜택을 얻을 수 있는 아이디어에 대해 이야기하겠습니다.

참고: 이 문서의 내용은 모든 Android 개발 수강생에게 적용됩니다.

1688 시작 최적화는 무엇을 합니까?

최적화하기 전에 먼저 현재 상황을 분석해야 합니다. 1688 앱은 "알리바바(Alibaba)"라고 불리며 모든 주요 애플리케이션 스토어에서 다운로드할 수 있습니다. 이하 알리바바 앱(Alibaba APP)으로 통칭합니다 . 알리바바 앱의 현재 상황은 어떤가요?

• windowBackground를 사용하여 신체 느낌 향상

• 시간이 많이 걸리는 작업을 위해 단일 지점 최적화가 수행되었습니다.

• 다중 스레드 배치 스케줄링 작업 활용

배치 스케줄링 구현에 대한 간략한 설명: 시작 작업을 4개의 배치로 나누어 먼저 Application onCreate에서 첫 번째 배치를 실행한 다음 하위 스레드에서 두 번째 배치를 실행하고 HomeActivity onCreate의 하위 스레드에서 세 번째 배치를 실행합니다. , 홈 페이지를 렌더링한 후 하위 스레드는 네 번째 배치를 실행합니다. 동일한 배치에서는 설정된 매개변수에 따라 그룹화되어 동일한 그룹이 동시에 실행되고 나머지는 매개변수에 따라 순차적으로 실행됩니다. 이 스케줄링 방식에는 큰 단점이 있습니다: 결정론적으로 실행되는 애플리케이션의 작업을 제외하고 다른 하위 스레드의 작업은 완료될 정확한 타이밍을 알 수 없습니다. 가능한 한 빨리 실행을 시작한다고만 말할 수 있습니다. . 비즈니스가 복잡해짐에 따라 홈페이지 진입 전 반드시 완료해야 하는 일부 작업은 Application 단계에서만 추가할 수 있습니다. 시작 작업을 하나씩 적는게 좀 번거로워서 하나의 작업에 여러 작업이 이루어지고, 작업도 깨져버렸습니다.

시작 정의

우선, 먼저 "콜드 스타트"가 무엇인지 이해해야 합니다. Android의 시작에 대한 공식 정의는 https://developer.android.com/topic/performance/vitals/launch-time 문서에서 확인할 수 있습니다. Logcat에서 Displayed의 flitter를 통해 시작 시간을 필터링할 수 있습니다. 예를 들어:

그렇다면 Alibaba Group은 Android 애플리케이션 시작을 어떻게 정의할까요? 크게 다음의 4단계로 나누어집니다.

• 시스템 초기화
• 애플리케이션 초기화
• 스크롤 없이 볼 수 있는 부분 위
• 시작 완료(대화형)

이 글에서는 '애플리케이션 초기화'와 '첫 화면 표시' 두 단계의 최적화에 초점을 맞췄습니다. 애플리케이션 초기화는 애플리케이션 시작부터 홈 페이지 활동 재개까지의 시간을 의미하며, 첫 번째 화면 표시는 애플리케이션 시작부터 홈 페이지 렌더링이 80% 완료될 때까지의 시간을 의미합니다. 다음에서 애플리케이션 초기화 단계 최적화는 애플리케이션 시작부터 홈페이지 활동 onResume까지의 단계를 의미하며, 애플리케이션 단계에서 더 나은 작업 스케줄링을 위해 멀티 코어 기능을 사용하여 단일 작업의 CPU 유휴 시간을 줄이는 방법에 중점을 둡니다. 홈 페이지 디스플레이 최적화는 홈 페이지 활동 재개부터 홈 페이지 렌더링 80% 완료까지의 단계에 중점을 두며 홈 페이지 최적화 전략에 중점을 둡니다.

먼저 시작 최적화를 위한 전반적인 계획을 보여주기 위해 사진을 찍어 보겠습니다.

애플리케이션 초기화 단계 최적화

위에서는 기존 시작 프레임워크의 몇 가지 단점이 언급되었습니다.

• 결정론적으로 실행되는 애플리케이션의 작업을 제외하고 다른 작업은 언제 실행될지 알 수 없으며 후속 시나리오에서는 많은 수의 Check Init이 필요합니다.

• 업무는 점차 번거롭고 부패해집니다.

• 작업 간에는 잠금 경쟁이 있으며 다양한 모델에 대한 경험은 상당히 다릅니다. 단일 작업은 더 오래 걸리고 상위 계층에서는 이를 감지할 수 없습니다.

비즈니스가 지속적으로 발전함에 따라 특정 작업을 특정 시간에 예약해야 하는 경우가 점점 더 많아지고 있습니다. 이를 통해 모듈에 필요한 작업이 성공적으로 초기화되었는지, 사전 초기화 작업이 성공적으로 초기화되었는지 여부를 후속 프로세스의 어느 시점에서나 명확하게 알 수 있습니다. 홈페이지, 그에 따른 유연한 스케줄링 계획 결정성도 필요합니다. 이전에 하위 스레드 사이에 숨겨져 있던 문제를 이제 노출하고 처리해야 합니다. 둘째, 시작 작업을 재구성하고 배열하여 단일 책임을 결정해야 합니다. 이는 또한 향후 작업의 지속적인 손상을 방지할 수 있습니다. 동시에 이는 "잠금 없는" 작업 스케줄링의 기초이기도 하여 멀티 코어 기능 및 단일 작업 유휴 감소 전반적인 최적 상태를 달성하는 데 시간이 걸립니다. 클라이언트 호출, 웹 외부 링크 시작, 자동 로그인, 프런트엔드 및 백엔드 전환 등 다중 시나리오 상황에서는 시나리오 기반의 시작 작업에 대한 맞춤형 오케스트레이션을 지원해야 합니다.

이를 바탕으로 모든 온라인 작업의 실행 상태를 감지할 수 있는 보다 포괄적인 모니터링 기능도 필요합니다. 개발 기간 동안 테스트 플랫폼과 통합하여 총검 강제 제어 시작 작업을 수행하여 비정상적으로 시간이 많이 걸리는 작업이 있는지 감지할 수 있습니다. 작업 작업 등이 나타납니다. 그룹의 모든 Android 학생이 시작 작업이 어떻게 예약되는지, 자신이 담당하는 비즈니스 모듈과 관련된 시작 링크가 다양한 시작 시나리오에서 어떻게 실행되는지 매우 명확하게 확인할 수 있습니다.

위의 요구 사항을 바탕으로 우리는 스타트업 프레임워크를 재개발하고 이름을 Yasuo로 지정했습니다.

그리고 강한 바람을 타고 전진하면서 뒤에 있는 것도 주의 깊게 살펴야 합니다.

우리 모두 알고 있듯이 폭발에 맞서세요! 새로운 출시 프레임워크를 통해 APP 출시가 바람처럼 빠르게 이루어질 수 있기를 바라며 이름을 Yasuo로 지정했습니다.

그렇다면 야스오의 전체적인 구조는 어떤 모습일까요? Taobao의 DAG 스케줄링 프레임워크를 기반으로 중간 계층 기능을 추가로 사용자 정의 및 캡슐화하고 원래 시작 라이브러리와 연결했으며 상대적으로 저렴한 비용으로 전체 시작 링크를 변환했습니다.

위 그림은 야스오의 전체 아키텍처를 가장 단순한 계층 아키텍처로 보여줍니다. Taobao DAG 스케줄링 기능에 액세스할 수 있으며 1688의 이전 시작 프레임워크를 상속했습니다. 핵심 모듈은 다음과 같습니다.

• 코어(DAG 기반 상위 계층 캡슐화)

• 통계(통계 모니터링 모듈)

• 공통(공용 모듈)

• config(구성 모듈 시작)

• api(작업을 시작하여 호출되는 API 모듈)

• 부트스트랩(런처 항목)

우리는 주로 몇 가지 더 중요한 일을 했습니다:

• 분할된 작업을 시작하고, 세분화된 부분으로 다시 분할하고, 단일 책임을 따릅니다.

• 야스오 프레임워크 구축

• 작업을 재구성하고 다양한 수단을 통해 Lock-Free 스케줄링을 달성하려고 노력합니다.

외부 학생들의 경우 DAG 스케줄링 프레임워크를 위한 오픈 소스 솔루션이 이미 많이 있습니다. "Yasuo"와 유사한 런처에 액세스하고 구현하는 데 적합한 프레임워크를 선택할 수 있습니다. 대부분의 아이디어는 공통적입니다.

작업을 시작하고 해체하는 것은 말처럼 쉽지 않은 섬세한 작업입니다. 우선, 스타트업의 모든 업무에 대해 상대적으로 포괄적인 이해를 갖고 이를 '해체'하는 출발점을 찾아야 한다. 우리 APP는 수년간 개발되었기 때문에 기본적으로 작업을 시작할 때 무엇을 하는지 설명할 수 있는 사람이 없고, 조금씩 살펴보고 해체하는 데 많은 노력이 필요했습니다. 결국 원래 작업은 40개 미만이었습니다. , 해체되었습니다. 70 이상 도착했습니다 .

작업이 재구성되어 에너지 집약도가 높아집니다. 우리 모두 알고 있듯이, 대부분의 사람들은 특히 시작 링크에 문제가 발생할까 두려워 "조상 코드"를 감히 건드리지 않으며, 문제가 있으면 온라인 사고로 이어질 수 있습니다. 이번에는 조상 코드의 바다 깊숙이 들어가 호랑이처럼 맹렬하게 작전을 펼쳤습니다. 계획할 때 고려해야 할 가장 중요한 세 가지 사항은 다음과 같습니다.

• 잠금 해제됨

• 시퀀스(명시적 종속성 및 암시적 종속성)

• 여러 시나리오에서 솔루션 배열

먼저, 그룹의 제2자 라이브러리에 깊이 들어가 분할 및 잠금 없는 오케스트레이션을 수행하고 내부 코드를 기반으로 시퀀스 종속성을 결정합니다. 둘째, 우리는 스스로의 창업 과제를 세심하게 연구하고, 그룹 내 친구들과 함께 작업하고, 수많은 실험을 하고, 2~3가지 버전의 반복을 거쳐 최종 배치 계획을 최종적으로 결정했습니다(눈물). 시작 단계에서는 자체 작업 간의 잠금 경쟁 가능성 외에도 모든 사람이 직면할 수 있는 일반적인 문제는 다음과 같습니다.

• 데이터 읽기를 위한 SharedPreferences 잠금입니다. SharedPreferences가 처음으로 파일을 읽을 때 새 스레드에서 읽습니다.

• loadLibrary0 잠금(로드하므로)

• 캐시 읽기 파일 잠금

• 미리 뷰를 inflate 하신 경우, 동일한 Context를 사용하시면 inflate도 잠기게 되니 주의하시기 바랍니다.

이러한 문제에 대한 주요 해결책은 SharedPreferences와 Cache Prefetching이며, 부하를 각 단계로 분산시켜 최대한 많이 실행하도록 하는 것입니다. 분석을 위해서는 공식 안드로이드 분석 도구인 systrace를 사용하는 것이 좋습니다.Yasuo의 내부 모듈은 모든 시작 작업과 단계에서 추적을 갖고 있습니다.추적 스위치를 켜면 실제에 가장 가까운 릴리스 패키지에서 분석할 수 있습니다. 데이터. 또한 systrace의 html 파일을 표시할 수 있을 뿐만 아니라 고급 Android 시스템에서 추적을 기록할 수 있는 Google의 새로운 도구인 https://ui.perfetto.dev/를 사용하는 것이 좋습니다. 문서를 사용하여 사용자 정의하세요.

최신 버전의 Alibaba APP 온라인(9.10.3.0)은 작업 예약 부분을 시작합니다.

특히 프론트 링크는 기본적으로 언락이 되어 있는 것을 볼 수 있습니다. Lock-free는 잠금 경쟁이 없어야 한다는 의미는 아니지만 단계적 관점에서 볼 때 시간이 많이 걸리는 피크를 해결하고 시간이 많이 걸리는 단계를 보다 원활하게 만들어 전체적으로 최적을 달성합니다. 여러 모델의 문제를 고려해야 하며 ROI 에 주의를 기울이십시오. 동시에 단일 단계 작업 배열에서는 스레드 스케줄링 기능도 고려해야 하며 암시적 종속성(단계 간 종속성)을 사용하여 일부 어려운 잠금 경쟁 문제를 해결할 수도 있습니다. 문제를 전체적으로 살펴보고 균형을 유지하는 것을 잊지 마십시오.

마지막으로 기본 프로세스의 콜드 스타트 ​​단계에서 다음 단계(호출 포함)를 활성화했습니다.

• 신청서 첨부
• 애플리케이션 onCreate(3개의 작은 단계 포함)
• 첫 번째 활동의 onCreate
• 외부링크 통화 시작
• push Activity onCreate(오프라인 푸시 호출 시작)
• 대화형을 시작한 후 단계를 트리거합니다.
• 메인 스레드가 유휴 상태가 된 후
• 메인 스레드가 5초 동안 유휴 상태가 된 후

또한 소규모 프로그램 프로세스와 같은 다른 프로세스의 단계도 있습니다. 총 70개 이상의 작업이 예약되어 있으며 그 중 80% 는 상호작용이 시작되기 전에 실행됩니다. 즉, 이러한 작업은 초기화되어 사용자가 홈페이지에 진입하여 상호작용할 수 있기 전에 사용할 수 있습니다. 이전 시작 프레임워크에 비해 처리량은 4~5배 증가합니다 .

Alibaba APP(9.10.3.0)의 최신 온라인 버전 시작 단계 다이어그램(일반 콜드 스타트):

애플리케이션 초기화의 주요 단계에서는 새 솔루션의 전체 시간 소모를 이전 솔루션과 비교하여 최적화할 여지가 많지 않으며 전체 시장 평균에서 100-200ms의 시간 소모가 줄어들지만 이는 이전 솔루션과 비교했을 때 프레임워크는 애플리케이션 단계에서 10개의 작업만 예약합니다. 이는 후속 홈 페이지 표시 및 기타 단계를 위한 매우 넓은 운영 공간을 제공하고, R&D 기간 동안 완전한 시동 제어 가능성, 총검을 달성하고 온라인에 접속한 후에 인식될 수 있으며 후속 유연한 시동 솔루션을 위한 기반을 제공합니다.

작은 팁 하나 드리자면, 시작 이미지가 알리바바 APP와 유사할 경우, 큰 배경색 + 로고나 컨텐츠 형태로 레이어 리스트를 활용하여 구현하는 것을 권장합니다. 배경색을 지정하고 로고나 콘텐츠에 작은 이미지를 사용합니다. 이렇게 하면 windowBackground를 디코딩하는 데 소요되는 시간이 줄어들고 변경 사항이 작아지며 이점이 좋습니다.

홈페이지 디스플레이 최적화

먼저 홈페이지의 기본 구조를 소개하겠습니다.

홈페이지는 2층 컨테이너, 정적 메인 페이지(검색 구성 요소, 멀티 탭 구성 요소 포함), 동적으로 구축된 홈페이지 탭 및 산업 탭 페이지(CyberT 컨테이너로 구축)로 구성됩니다.

1688 홈페이지의 특징은 비즈니스 형태가 복잡하고, 반응형 작업이 많고, 중첩된 컨테이너가 많고, 동적 기능에 대한 요구 사항이 높다는 것입니다. 팝업 레이어/플로팅 창/플로팅 바 등이 서로 얽혀 있습니다. , 비즈니스 기능 및 상호 작용에 영향을 주지 않고 ROI를 고려하여 이전 기사의 Yasuo 스타트업 프레임워크가 우리를 위해 확보한 많은 공간을 빌려줍니다. , 가장 즉각적인 전략 정책은 시간 과 공간을 교환하는 것입니다 .

따라서 위의 맥락에서 Yasuo 프레임워크가 제공하는 결정론적 시작 단계 와 프로그래밍 가능한 작업 시스템에 의존하여 시작 시간을 크게 줄일 수는 없지만 홈페이지 최적화를 위한 많은 작업 공간을 제공합니다. 멀티코어 기능을 최대한 활용하여 홈페이지 최적화를 위한 시간을 벌 수 있다는 것입니다.

주요 최적화 아이디어는 다음 세 가지 사항으로 구분됩니다.

• 간섭 요인이 너무 많지 않은 시작 시 메인 스레드 환경 보장**(시간이 많이 걸리는 작업 전/후)**

• 렌더링 컨테이너 변환은 실행을 위해 홈페이지 렌더링 로직의 일부를 애플리케이션 초기화 단계에 넣습니다**(렌더링 시간 접기)**

• 시작 시 다수의 반복 작업이 메인 스레드를 점유하는 것을 방지하기 위한 렌더링 데이터 제어/새로 고침 제어 (컨텐츠 렌더링 보장)

1. 시작 시 메인 스레드 환경을 확인하세요.

우선, 애플리케이션이 막 시작되는 시점은 CPU가 가장 바쁜 시기로, 수많은 2차 라이브러리의 초기화로 인해 하위 스레드 수가 급격히 증가합니다. 이 단계에서는 경쟁이 치열해집니다. 메인 스레드와 타임 슬라이스 사이가 극도로 치열해집니다. 따라서 홈 페이지 표시 단계까지 실행 시에는 메인 스레드가 다른 작업에 의해 점유되지 않도록 해야 합니다. 예를 들어 WebView 초기화, Flutter 초기화와 같이 메인 스레드 작업이 필요한 작업을 적절하게 전환할 수 있으며 홈페이지가 렌더링되거나 유휴 상태인 후에 작업을 트리거할 수 있습니다.

WebView 초기화 작업을 미리 실행하는 문제:

홈페이지에 들어가면 빨간 봉투를 제공하거나 행사장으로 트래픽을 유도하는 마케팅 팝업 기능이 자주 팝업됩니다. 이 탄력적 레이어는 H5에 의해 구현되며 WebView 초기화 작업에 의존합니다. 조상 코드를 디버깅할 때 이전 시작의 설계 원칙은 모듈이 실행되기 전에 관련 초기화 모듈이 실행되도록 "최대한" 보장하는 것이지만 그 순서는 보장되지 않을 수 있음을 확인했습니다. init는 이전 코드가 실행되기 전에 호출됩니다. 즉, 해당 초기화 모듈이 아직 실행되지 않은 경우 초기화 작업이 강제로 활성화되어 실행됩니다. 이로 인해 홈페이지 Activity 진입 전 WebView가 초기화되는데, WebView 초기화 작업은 시간이 오래 걸려 홈페이지 표시 단계에서 CPU 자원을 낭비하게 된다.

따라서 우리는 이 현상을 해결하기 위해 몇 가지 개선 사항을 적용했습니다.

• WebView 초기화 작업을 분할하고 마케팅 탄력적 계층에 필요한 모듈을 분리하여 시간 소모를 줄이고 단계 병목 현상을 방지하고 Activity onCreate 단계에서 미리 실행합니다.

• 마케팅 팝업 레이어의 트리거 로직을 홈 페이지 뒤에 배치하고 80% 렌더링 후 콜백을 트리거합니다.

• 마케팅 레이어 팝업 로직의 사전 판단 ---- 초기화 후 페이지가 표시되지 않아 발생하는 리소스 낭비를 방지하기 위해 팝업 레이어 표시 여부에 대한 로직을 미리 실행하여 마케팅 팝업 레이어 각성률과 성과 소비 시간의 비즈니스 효과. (프로그램 출시 후 약 200ms의 성능 향상을 시장에 가져왔습니다.)

2. 홈페이지 사전 렌더링

홈페이지 렌더링 프레임워크는 1688년에 개발된 구성 요소화된 페이지 전달 시스템인 CyberT 컨테이너를 사용합니다. 페이지는 구성 요소 템플릿, 스타일 및 데이터를 동적으로 제공하여 구축 및 렌더링되며 전자 상거래 비즈니스의 강력한 역동성과 홈페이지의 기본 성능에 대한 경험 요구 사항도 충족합니다. 홈페이지 탭과 산업 탭 페이지는 CyberT 컨테이너를 사용하여 구축되었습니다.

Yasuo의 오케스트레이션 기능이 제공하는 공간을 최대한 활용하기 위해 우리는 CyberT에서 렌더링 최적화 로직을 변환 및 촉진하고 애플리케이션 초기화 단계에서 로직의 일부를 미리 수행하여 각각 다음을 구현했습니다.

• CyberT 프로토콜 분석, 사전 생성 보기

• 레이아웃 파일 사전 생성

• 홈페이지 구성 요소의 템플릿 사전 생성

CyberT 프로토콜 분석, 사전 생성 보기:

디버깅 과정에서 프로토콜 분석의 메인 스레드 콜백이 홈 페이지 표시 단계에 있는 것을 발견했는데, 바쁜 메인 스레드로 인해 오랫동안 유휴 상태였으며 CyberT 페이지를 생성할 수 없었습니다. CyberT 페이지는 CyberT 초기화 작업이 완료된 후에만 가능하며 시작하므로 시작 단계에서 병목 현상이 발생하지 않도록 애플리케이션 초기화 단계에서 캐시된 프로토콜과 컴포넌트 데이터를 활용하여 미리 프로토콜 파싱 및 뷰 생성을 수행하고 저장합니다. 메모리에 저장하고, 홈페이지 Fragment 생성 대기 시 직접 추가하고, View 트리에 진입하여 후속 렌더링 로직을 실행합니다. 전체 프로세스에서 애플리케이션 컨텍스트를 사용하여 컨텍스트를 노출하고 Use Once 논리를 구현하고 적시에 재활용하여 메모리 누수를 방지합니다. 또한 온라인 성공률을 모니터링하고, 모델 점수를 성공률과 연관시키고, 구성 스위치를 발행하고, 다양한 점수를 가진 모델에 대한 최적화 전략을 조정하여 프로그램 이점을 극대화합니다. (이 솔루션이 출시된 후 시장에 150ms에서 200ms의 개선을 가져올 수 있습니다)

레이아웃 파일 사전 생성:

Trace 파일을 분석한 결과 메인 스레드에서 xml을 파싱하는 데 일정 시간이 소요되는 것을 확인하였고, 따라서 홈페이지에서 반드시 실행해야 하는 Activity, Fragment, 2층 View의 레이아웃 파일에 대해서도 사전에 스레드 중단을 방지하기 위해 애플리케이션 단계에서 생성했으며, 과도한 생성 및 확장 시 애플리케이션 잠금 경쟁 문제를 해결하기 위해 순차적 실행을 위해 단일 스레드 풀에 배치했습니다. 우리는 또한 성공률을 모니터링하고 최적화 전략을 조정하는 데에도 능숙합니다.

템플릿 사전 생성:

CyberT는 페이지를 렌더링하고 구축할 때 먼저 구성 요소 템플릿을 요청하거나 읽어 해당 블록의 보기를 생성하는 경우가 많습니다. 템플릿 사전 생성을 위한 초기화 작업을 공식화하고, 템플릿 파일 및 컴포넌트의 캐시된 데이터를 미리 View에 생성하여 캐시 풀에 넣어 후속 IO 대기로 인한 새로 고침으로 인한 리소스 낭비를 줄이고 컴포넌트를 압축했습니다. 생성 시간을 마이크로초로 표시합니다.

3. 렌더링 데이터 제어/새로고침 제어

사용자가 가능한 한 빨리 상호 작용할 수 있도록 하기 위해 1688은 현재 캐시된 데이터 렌더링에 우선 순위를 부여한 다음 네트워크 데이터가 콜백된 후 diff 새로 고침을 수행하는 렌더링 전략을 채택하고 있습니다. 여기서 제어는 실제로 코드의 합리성을 확인하는 것입니다.코드 로직에 페이지가 자주 새로 고쳐지고 사용자가 상호 작용할 수 없게 만드는 불합리한 콜백이 있습니까? 아직 렌더링되지 않은 캐시 데이터가 있고 네트워크 데이터가 강제로 새로 고쳐져 사용자 상호 작용 시간이 지연되는 경우가 있나요? 우리는 위의 문제를 해결하고 렌더링 프로세스 중 논리적 비합리성으로 인한 리소스 낭비를 방지하기 위해 상호 작용 전후의 렌더링 논리를 강력하게 제어했습니다. 최적화의 초기 단계에서 조상 코드의 비합리적인 측면을 합리적인 것으로 바꾸는 것은 종종 예상치 못한 이점을 가져올 수 있습니다.

성능 확장 활성화

위에서 언급한 바와 같이 홈페이지 디스플레이 최적화 과정에서 일부 전략은 성공률에 문제가 있는 것으로 나타났으며, 오프라인 모델 관찰과 온라인 데이터 비교를 통해 CPU 성능이 약한 저가형 모델에 대해 사전 생성 및 사전 생성을 확인했습니다. 생성 시 캐시 오류가 발생할 가능성이 높아 시간 조각 리소스가 낭비되고 심지어 부정적인 최적화가 발생합니다. 따라서 롱테일 사용자를 위해 동적 성능 확장 솔루션을 설계했습니다. 전체 솔루션의 일반적인 프로세스는 사용자 모델 등급/인구 선택/네트워크 환경 등을 기반으로 원격 플랫폼에서 발행한 구성, 클라이언트의 의사 결정 엔진에 대한 입력 및 의사 결정 전략이 결합됩니다. 다음에 시작할 때 적용되도록 로컬에 저장됩니다. 그리고 온라인 뷰 캐시의 성공률, 저가형 머신의 시작 시간, 다양한 그룹의 시작 시간 및 기타 지표를 관찰하여 전략적 이점을 확인하세요.

예를 들어, 저사양 컴퓨터에서는 사전 로드 및 사전 생성 기능을 끄고, 동일한 화면에서 비디오 재생 횟수를 제어하고, gif 애니메이션을 제어하고, WebView Init/Flutter Init와 같이 시간이 많이 걸리는 작업을 연기하는 등의 전략을 채택했습니다. 5초 후 유휴 시나리오로 전환하여 저비용 시나리오를 우선적으로 단말에서 경험해 보세요. 하이엔드 모델에 관련 전략을 활성화하여 최적화 전략의 이점을 극대화할 뿐만 아니라, 사용자 입장에서는 마케팅 전략에 빠르게 대응할 수 있도록 단계에서 시간 소모적인 병목 현상 없이 마케팅 기능/마케팅 페이지를 미리 로드합니다. 경험과 비즈니스 혁신을 통해 균형점을 찾으세요.

예방하고 통제하는 방법

우리는 스타터 컨테이너인 야스오를 침전시켰습니다. 컨테이너 측면에서는 온라인 모니터링, R&D 총검, 테스트 플랫폼 통합 기능을 갖추고 있어 개발부터 출시까지 모든 단계를 제어하여 작업 손상을 방지할 수 있습니다. 홈페이지 측면에서는 최적화의 일부가 CyberT 컨테이너 개발을 기반으로 하고 있습니다. 컨테이너 측면 자체에는 총검이 있고, 일부는 홈페이지 자체의 최적화입니다. 우리가 개발하고 있는 풀링크 로그 시스템의 도움으로, 우리는 모니터링 기능을 통해 주요 위치에 교차점을 만들었습니다. 예외가 발생하면 적시에 통보를 받을 수 있습니다.

개발 기간 동안 git을 사용하여 코드 웨어하우스를 관리하고 스타트업 라이브러리 및 스타트업 풀과 관련된 웨어하우스 권한이 강화되어 온라인에 접속하면 변경 사항을 명확하게 인식할 수 있습니다. 코어 링크 문제가 감소됩니다. 동시에 해당 스크립트에 의해 시작 조정 클래스와 시작 풀 클래스가 생성되며 스크립트 내용은 간단하고 유지 관리가 쉽고 유지 관리 비용도 절감할 수 있습니다.

효과

이 글을 쓰는 시점에서 알리바바 APP 시작 시간은 8월과 9월 약 3초에서 현재 1.9초로 최적화되어 36.67 % 감소했다 .

8월과 9월의 데이터와 비교하면 콜드 스타트 ​​이탈률은 75% 감소했습니다 .

Type B 구매자 ​​사용자와 잠재 Type B 구매자 ​​사용자에 대한 드릴다운 분석을 통해 전반적인 데이터가 시장보다 나은 것으로 나타났으며 향후 크라우드 최적화 전략이 있을 것입니다.

탄력적 및 축소적 전략의 시작으로 기계 모델, 사람 그룹 및 환경을 기반으로 전략을 발표하면 더 나은 결과를 얻을 수 있습니다.

안드로이드 학습 노트

Android 성능 최적화 기사: https://qr18.cn/FVlo89
Android 프레임워크 기본 원칙 기사: https://qr18.cn/AQpN4J
Android 차량 기사: https://qr18.cn/F05ZCM
Android 역방향 보안 연구 참고 사항: https://qr18.cn/CQ5TcL
Android 오디오 및 비디오 기사: https://qr18.cn/Ei3VPD
Jetpack 제품군 버킷 기사(Compose 포함): https://qr18.cn/A0gajp
OkHttp 소스 코드 분석 참고 사항: https://qr18.cn/Cw0pBD
Kotlin 기사: https://qr18.cn/CdjtAF
Gradle 기사: https://qr18.cn/DzrmMB
Flutter 기사 : https://qr18.cn/DIvKma
Android의 8가지 지식 기관: https://qr18.cn/CyxarU
Android 핵심 노트: https://qr21.cn/CaZQLo
전년도 Android 면접 질문: https://qr18.cn/CKV8OZ
2023년 최신 Android 면접 질문: https://qr18.cn/CgxrRy
Android 차량 개발 직책 면접 연습: https://qr18.cn/FTlyCJ
오디오 및 비디오 인터뷰 질문:https://qr18.cn/AcV6Ap