APP 성능 요약을 개선하는 방법에 대한 심층적인 이해

요약: 이 글은 모바일 앱의 크기 최적화, 앱 API 디자인, 아키텍처 디자인, 적응형 디스플레이, 빠른 시작 등의 측면에서 모바일 앱의 성능을 향상시키는 방법을 포괄적으로 소개합니다. 번역은 다음과 같습니다.

작년 런던에서 돌아오는 비행기에서 휴대폰 업계에 종사하는 분을 만났습니다. 지난 20년간 선도기업이라 할 수 있는 대기업에서 신기술 도입을 담당해 왔다.

8시간 동안 함께 비행하는 동안 나는 그가 언급한 몇 가지 사항에 대해 생각해 보았습니다. 그는 모바일 애플리케이션과 그 성능이 계속해서 제공되고 있다고 믿습니다. 실제로 모바일 애플리케이션의 성능을 감사하여 얼마나 개선되었는지 확인할 수도 없습니다.

샌프란시스코에 도착한 후 저는 이 문제에 대해 알아보기 위해 더 많은 휴대폰 업계 사람들과 접촉했고, 그들 모두 비슷한 견해를 가지고 있다는 것을 알게 되었습니다. 코드 품질과 기본 프레임워크는 모두가 논의하는 유일한 사항입니다.

저는 Simform에서 앱을 구축하고, 몇 가지 좋은 사례를 탐색하고, 이러한 사례를 따르고, 벤치마크를 설정하고, 규모가 수십억 달러에 달할 수 있는 기존 애플리케이션을 돌파하는 방법에 대해 즉시 생각했습니다.

다음 요소는 모바일 애플리케이션의 품질에 큰 영향을 미칩니다.

• 앱 크기

• 앱 성능

• 지정된 플랫폼에 대한 지침

• 건축 디자인

이제 모바일 앱을 더 빠르게 만들기 위해 채택하기 쉬운 단계를 통해 간단한 방법으로 최적화하는 방법을 살펴보겠습니다.

애플리케이션 크기 최소화

휴대폰에는 강력한 GPU가 없지만 저가형 구성 휴대폰이 Android 시장 점유율의 대부분을 차지합니다. 2G나 3G도 지원하지 않으며 즉시 필요한 대규모 애플리케이션을 다운로드하는 것은 사용자에게 악몽이 될 것입니다. 이런 저가형 휴대폰에서는 앱이 차지하는 공간이 적을수록 좋습니다.

네트워크 최적화

텍스트 먼저, 이미지 두 번째

네트워크 최적화, 텍스트 데이터 먼저 로드를 시도해보세요. 그런 다음 애플리케이션 내의 이미지 기반 콘텐츠 표시를 비동기식으로 로드할 수 있습니다.

중복 네트워크 요청 방지

Android의 친숙한 Volley 앱은 이 요청에 대해 더 많이 알게 될 것입니다. 애플리케이션 성능이 저하되면 Android 애플리케이션은 Volley를 사용하여 동시에 두 개의 요청을 서버에 보낼 수 있습니다. 하나의 요청을 삭제하면 해당 요청은 삭제되지만 애플리케이션에서는 그러한 요청이 없다는 응답을 받게 됩니다. 기능 문제뿐만 아니라 중복 요청은 특히 수백만 명의 애플리케이션 사용자가 있는 경우 시스템 정체를 증가시키고 애플리케이션 성능을 저하시킵니다. 요청수가 2배로 늘어나면 서버수도 2배로 늘어난다고 상상해보세요. 그러다가 비용을 절감하고 싶을 때는 매우 절박해질 것입니다.

연결 품질을 이해하고 조정하세요

애플리케이션이 네트워크 상태에 따라 사용 가능한지 여부를 결정해야 한다고 가정해 보세요. 애플리케이션은 사용자가 현재 있는 네트워크 조건에 따라 전달되는 콘텐츠의 품질을 변경할 수 있으므로 애플리케이션 사용에 실패하지 않습니다.

효과적인 API 디자인

API가 디자인되는 방식은 애플리케이션 성능에 큰 영향을 미칩니다. 불완전하거나 게으른 API 설계는 애플리케이션의 부담을 증가시킵니다. API에 대한 해결 방법은 네트워크 제한에 너무 많은 부담을 주는 경우가 많습니다.

애플리케이션이 다음과 같은 특성을 갖도록 모바일 애플리케이션의 API 로드를 설계하세요.

• 일관성: 개발자는 기대치를 알아야 하며 API 일관성을 설계하는 데 있어서 흔들림의 여지가 없습니다.

• 완전성: 단순화된 해결 방법이 있습니다.

UI에서 시작하여 데이터에 이르기까지 API 로드를 일관성과 완전성으로 설계하여 애플리케이션 성능을 향상시키는 좋은 방법입니다. 휴대전화에서 모든 요청을 API로 보내지 말고 실제로 필요한 요청만 보내세요.

앱에서 이미지 최적화

앱에서 이미지를 최적화하려면 다음을 수행할 수 있습니다.

• 벡터 이미지 사용

• 동적으로 크기가 지정된 이미지 제공

• 다른 색상 이미지 세트를 사용하는 대신 색상 필터 사용

• 이미지 캐싱 사용

• Picasso 및 Fresco와 같은 라이브러리 사용

오프라인 최적화를 위한 캐시 데이터

네트워크 상태가 좋지 않으면 데이터를 얻는 동안 얻은 모든 데이터가 표시됩니다. 이렇게 하면 다음과 같은 효과가 있습니다.

• 서버 부하 감소

• 휴대폰 무선 사용량 감소 및 모바일 앱의 전력 소비 감소

테스트 팀이 없는 경우 다음을 수행할 수 있습니다. 애플리케이션의 오프라인 성능을 테스트하려면 휴대폰을 비행기 모드로 전환해 보세요.

앱이 휴대폰 화면 크기에 맞는지 확인하세요.

화면 크기에 관해 많은 논의가 있었고 Android는 문자 그대로 수천 개의 기기가 있고 각각 고유한 해상도와 화면 크기가 있기 때문에 큰 관심을 받았습니다. .

최고의 전략:

• Build

• 중소형 화면에 맞게 MDPI 및 HDPI 최적화

• 적응형 UI 흐름 달성

해상도와 화면 크기를 테스트할 수 있는 장치가 수백 대가 없나요? 에뮬레이터 구성으로 테스트합니다.

Android의 메모리 사용량

휴대전화 사용자에게 멀티태스킹 기능을 제공하기 위해 Android는 각 애플리케이션이 사용하는 메모리 양에 대한 제한을 설정합니다. 이러한 제한은 고정되지 않으며 모바일 애플리케이션 수가 증가함에 따라 증가하거나 감소합니다. .그리고 변화합니다.

애플리케이션 개발 프로세스 전반에 걸쳐 RAM 제한 사항과 백그라운드에서 실행되는 애플리케이션이 불필요한 리소스를 차지한다는 사실을 고려하세요.

그러나 다음 방법으로 애플리케이션을 최적화할 수 있습니다.

• 서비스 유효 기간을 제한하고 서비스 수명을 제한하기 위해 인텐트 서비스 사용을 고려하세요.

• 사용자가 다른 인터페이스로 전환하면, UI 리소스 출시

• 메모리 효율적인 코드 아키텍처 사용

• 외부 라이브러리 사용 최소화

앱이 얼마나 빨리 실행되나요?

실행 시간이 800ms~4.5초인 PlayStore의 평균 상위 25개 앱입니다. 이제 4.5S는 대부분의 사용 사례에 너무 많습니다.

결론은 앱이 빨리 실행되어야 한다는 것입니다!

iOS 애플리케이션의 시작 시간을 최적화하려면 다음을 고려해야 합니다.

• 적은 수의 dylib 포함

• Objective-C 클래스 병합

• 정적 초기화 소프트웨어 제거

• Swift의 경우 더 많이 사용하세요.

• DYLD_PRINT_STATISTICS로 결과를 측정하세요

• dlopen() 사용을 피하세요

Android에서는 일반적으로 다음 상황이 앱 시작 시간에 영향을 미칩니다.

• 인스턴스화

• 비트맵 디코딩 등 리소스 소모가 많은 콘텐츠

• 실행중인 레이아웃

Android에서 앱 실행 속도 향상:

• 처음 실행 시 필요하지 않은 UI 부분을 표시하지 말고 나중에 표시할 수 있는 계층 구조 자리 표시자를 사용하세요.

• 메모리 할당 및 가능한 한 많은 가비지 수집 수행

• Apteligent와 같은 도구를 사용하여 애플리케이션 시작 시간을 모니터링하고 최적화

• 애플리케이션 개체에서 초기화 코드 방지

• 최근 출시된 앱인 Note Live가 처음 출시되었습니다. 앱이 다르게 동작합니다.

장치 깨우기 감소

휴대폰을 자주 깨우면 시스템 성능이 크게 저하됩니다. 이로 인해 시스템 리소스가 소모됩니다. 애플리케이션이 응답할 깨우기 의도를 제한할 수 있습니다.

저사양 Android 휴대폰을 고려하세요

모든 Android 사용자가 최신 2G+ 메모리 휴대폰을 사용하는 것은 아닙니다. 사용 가능한 Android 기기를 살펴보면 기기 기능 측면에서 높은 분석을 볼 수 있습니다.

대부분의 개발자는 성능 향상을 위해 애플리케이션을 개발하고 최적화할 때 큰 실수를 범합니다. 그들은 종종 테스트에 사용할 수 있는 고급 장치를 사용하여 잘못된 장치에 맞게 앱을 최적화합니다.

가장 좋은 경험 법칙은 앱 성능을 최적화하는 데 사용되는 다양한 장치가 있어야 한다는 것입니다. 이런 방식으로 개발자는 교차 테스트를 수행할 수 있습니다.

• 다양한 속도

• 인터페이스 및 해상도

• 낮은 메모리

부드러운 프레임 속도

iOS 및 Android에서 애니메이션과 제스처를 표시하는 최대 프레임 속도는 60fps입니다.

프레임 속도가 60fps보다 낮으면 사용자는 일반적으로 멈춘 듯한 느낌을 받게 됩니다.

16ms(60fps에 해당)의 프레임 속도를 달성하려면 애플리케이션에서 표시하는 데 사용되는 코드가 16ms 이내에 실행되어야 합니다. 여기서 Android에서 5ms의 가비지 수집 시간이 얼마나 비싼지 알 수 있습니다.

이것이 최종 사용자에게 어떤 영향을 미칠지 평가해 보겠습니다. 16ms 제한을 놓치면 약 59fps의 약간 낮은 프레임 속도를 얻게 되는 경우가 많습니다. 별거 아니죠?

틀렸어!

현실은 애플리케이션이 16ms 제한을 한 번 놓치면 동일한 프레임에 대해 창을 사용할 수 없으며 다음 프레임을 기다려야 한다는 것입니다.

애플리케이션이 표시되는 데 19ms밖에 걸리지 않았지만 표시 창을 놓치고 사용자에게 표시되는 시간이 두 배나 길어졌습니다. 이런 식으로 사용자는 응용 프로그램이 매우 나쁘다고 생각할 것입니다.

새 기기에서 사용자 데이터 복구

사용자는 원하는 방식으로 작동하기 위해 휴대폰에 앱을 설정하는 데 많은 시간을 소비하는 경우가 많습니다. 응용 프로그램을 다시 설치할 때 대부분의 사용자는 원래 설정이 그대로 유지되기를 기대합니다.

구성 데이터를 저장하면 애플리케이션 품질이 향상됩니다.

• 사용자가 수정한 모든 구성

• 푸시 설정 알림

• 사용자가 새 화면에서 환영 화면과 소개를 본 경우

잠재적 소비 발견

애플리케이션에서 이동 잠재적인 문제를 제거하는 것이 중요합니다. 잠재적인 문제로 인해 애플리케이션 오류가 발생하고 종종 전체 애플리케이션이 중단될 수 있습니다. 통계에 따르면 애플리케이션이 느리게 실행되면 50% 이상의 사용자가 24시간 이내에 애플리케이션을 제거합니다.

잠재적인 관련 문제를 효과적으로 처리:

네트워크 상태가 좋지 않으면 잠재적인 문제 요인의 제3자 소스를 제한할 수 있습니다.

휴대폰에서 잠재적으로 API를 소비할 필요성을 줄입니다.

iOS 애플리케이션 최적화 멀티태스킹을 처리하는 프로그램

귀하의 애플리케이션을 사용하는 사용자가 있다고 가정해 보겠습니다. 애플리케이션은 60fps로 잘 표시되고 9ms 안에 모든 작업이 완료됩니다. 아래 그림과 같이:

이제 사용자가 휴대폰에서 두 번째 애플리케이션을 열면 모든 작업을 완료하는 데에도 약 7ms가 걸립니다. 이제 다음 그림과 같습니다.

60fps의 프레임 속도로 표시하려면 두 응용 프로그램을 결합하는 데 16ms가 걸렸다는 것을 알 수 있습니다.

사용자가 60fps의 프레임 속도로 다른 애플리케이션을 열고 작업이 10ms 안에 완료된다고 가정해 보겠습니다. 현재 시간은 9+7+10=26ms입니다. 이는 애플리케이션의 데모 프레임 속도가 60fps가 아닌 40fps임을 의미합니다.

앱 사용자는 프로그램의 지연을 느끼기 시작했으며 GPU와 메모리에서도 거의 동일한 현상이 발생했습니다.

앱이 계속 충돌했던 것을 기억하시나요?

자, 기기에서 실행되는 애플리케이션의 시나리오를 살펴보겠습니다.

이제 또 다른 애플리케이션을 현장에 도입했지만 여전히 잘 지내고 있으며 아직 메모리가 남아 있습니다.

현장에 다른 애플리케이션을 도입하면 시스템에 할당할 메모리가 없습니다. 시스템은 리소스를 확보하기 위해 프로세스를 종료합니다.

이것이 앱 개발이 그토록 어려운 이유입니다(정말 관심이 있는 사람들에게)

이러한 문제를 해결하려면 iOS 생태계에 대한 약간의 이해가 필요합니다. 멀티태스킹을 위해 애플리케이션을 최적화하는 방법을 살펴보겠습니다.

• 도구를 사용하여 버그를 식별하고 수정할 수 있습니다.

• 작업 우선 순위를 적절하게 지정하고 메인 스레드를 차단하지 마세요.

• 도구 세트 식별 및 관리

• 캐싱 사용 및 메모리 경고에 응답

• 가상 메모리 시스템을 사용하여 메모리 회수 증가

• 절충하기

누구나 이 중 50%를 따라갈 수 있다면 성능이 응용 프로그램이 개선되었습니다. 큰 개선이 있었습니다.

위 내용은 APP 성능 요약을 개선하는 방법에 대한 심층적인 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!