Android 성능 최적화의 APP 성능 최적화 원칙 요약
안드로이드 응용의 성능 최적화는 모든 안드로이드 개발자가 반드시 겪게 되는 것이고 이직 면접에서 기본적으로 반드시 물어봐야 할 문제이다.다음은 필자가 정리한 일부 앱의 성능 최적화 원칙이다. 만약에 아래의 최적화 원칙을 따를 수 있다면 개발한 앱은 더욱 원활하고 사용자 체험이 더욱 좋고 안정적일 것이다.
1. 배치 최적화
사상 개술: 레이아웃 파일의 차원(android를 그릴 때 작업량이 줄어들고 성능이 향상됨)을 최대한 줄이고 과도하게 그리는 것을 피한다. 레이아웃에서 사용하지 않는 컨트롤과 레벨을 먼저 삭제하고, LinearLayout과 같은 성능이 낮은 ViewGroup을 선택적으로 사용합니다.만약에 레이아웃에 있는 레이아웃이 LinearLayout도 사용할 수 있고 RelativeLayout도 사용할 수 있다면 LinearLayout을 사용합니다. 이것은 RelativeLayout이 비교적 복잡하고 그의 레이아웃 과정에 CPU 시간이 더 많이 걸리기 때문입니다.FrameLayout은 LinearLayout과 마찬가지로 간단하고 효율적인 ViewGroup이기 때문에 그들을 고려할 수 있다. 그러나 단순히 하나의 LinearLayout이나 FrameLayout을 통해 제품의 효과를 실현할 수 없기 때문에 끼워넣는 방식으로 완성해야 하는 경우가 많다. 이런 상황은 RelativeLayout을 사용하는 것을 권장한다. ViewGroup의 끼워넣는 것은 레이아웃의 등급을 높이는 것과 같기 때문이다.프로그램의 성능을 떨어뜨릴 수도 있다.레이아웃 최적화의 또 다른 수단은 라벨, 라벨, ViewStub을 사용하는 것이다. (1), 라벨: 현재 레이아웃과 포함된 레이아웃이 모두 세로 방향이라면 라벨을 사용하면 여분의 LinearLayout을 제거하고 라벨과 함께 사용하면 레이아웃의 등급을 줄일 수 있다. (2), 탭: 레이아웃을 다시 사용합니다. 이미 쓴 레이아웃을 다시 쓰지 않아도 됩니다. 코드의 복원. (3), ViewStub: 뷰를 계승합니다. 매우 가볍고 넓이가 0입니다. 레이아웃을 그리는 과정에 참여하지 않고 필요에 따라 불러오는 기능을 제공합니다. 필요할 때 ViewStub의 레이아웃을 메모리에 불러옵니다. 이것은 프로그램의 초기화 효율을 높입니다.
2. 드로잉 최적화
사상 개술:View의 onDraw 방법은 대량의 조작을 피하고 onDraw 방법에서 새로운 국부 대상을 만들지 마라(onDraw 방법은 빈번하게 호출될 수 있고 대량의 임시 대상이 생겨서 시스템이 더욱 빈번하게 gc를 만들고 프로그램의 집행 효율을 떨어뜨릴 수 있다). onDraw 방법에서 시간을 소모하는 작업을 하지 마라.수천 수만 번의 순환 작업을 수행할 수 없습니다. (cpu를 점령한 타임슬립은 View 그리는 과정이 원활하지 않고 프레임마다 16ms를 넘지 않습니다.)
3. 메모리 유출 최적화
메모리 유출의 최적화는 주로 두 가지 측면으로 나뉜다. 하나는 개발 과정에서 메모리 유출 코드를 쓰는 것을 피하는 것이고, 다른 하나는 MAT, LeakCanry 또는 안드로이드 프로필러 등 분석 도구를 통해 잠재적인 메모리 유출을 찾아내 해결하는 것이다. 흔히 볼 수 있는 메모리 유출 예: (1)、Context의 사용이 부적절하여 메모리 유출을 초래한다. 하나의Activity,Context에 대해 긴 수명 주기를 인용하지 말고 가능한 한 모든 응용 프로그램Context를 사용하여 Context를 대체할 수 있다. (2) 정적 변수는 메모리 유출을 초래합니다. 만약에activity의context 대상을activity의 전역 정적 변수에 값을 부여합니다.정적 변수가 그것을 인용하기 때문에 액티브를 정상적으로 제거할 수 없습니다. (3), 단일 모드로 인한 메모리 유출: 만약에 우리가 단일 모드에서 관찰자 모드를 실현했고 감청은 인터페이스의 대상을 실현했다. 우리가Activity에 감청 방법을 등록한 후에 해제 등록을 하지 않으면 메모리 유출을 일으킬 수 있다.단일 모드에서 초기화는Activity나Context 실례를 전송하면 메모리 유출을 일으킬 수 있습니다. (4), 속성 애니메이션으로 인한 메모리 유출: 속성 애니메이션에는 무한 순환 애니메이션이 있다. 만약에 Activity에서 이런 애니메이션을 재생하고 onDestory에서 애니메이션을 멈추지 않으면 애니메이션은 계속 재생된다. 인터페이스에서 애니메이션 효과를 볼 수 없지만 이때 Activity의 View는 애니메이션이 가지고 있고 View는 Activity를 가지고 있다.결국Activity를 풀 수 없게 됩니다. (5), 스레드가 종료되지 않아 발생하는 메모리 유출을 경계한다. 예를 들어Activity에서 생명주기가Activity를 초과하는 Thread와 연결되어 있으면Activity를 종료할 때 스레드를 끝내야 한다는 것을 명심해라.하나의 전형적인 예는HandlerThread의run 방법은 사순환이다. 이것은 스스로 끝나지 않는다. 라인의 생명주기는Activity의 생명주기를 초과한다. 우리는 수동으로Activity의 소각 방법에서handlerThread를 호출해야 한다.quit () 는 누설되지 않습니다. (6) 대상의 등록과 반등록은 쌍으로 발생하는 메모리 유출이 없다.예를 들어 등록 방송 수신기, 등록 관찰자(예를 들어 데이터베이스의 감청) 등; (7), 창설과 폐쇄는 쌍으로 발생하는 유출이 없다.예를 들어Cursor 자원은 수동으로 닫아야 하고 WebView는 수동으로 폐기해야 하며 흐름 등 대상은 수동으로 닫아야 한다. (8), 비정상적 내부류의 정적 실례는 메모리 유출을 초래하기 쉽다.즉, 하나의 클래스에서 내부 클래스의 생명주기(예를 들어Activity의 특수한Handler 등)를 제어할 수 없다면 정적 클래스와 약한 인덱스를 사용하여 처리하도록 한다(예를 들어ViewRoot의 실현). (9), 실행 빈도가 높은 방법이나 순환에서 대상을 만들지 말고,hashTable 등 대상 용기를 만들어서 용기에서 그 대상을 찾을 수 있으며, 매번 new와 방출을 사용하지 않아도 된다. (10), 웹뷰의 누설에 주의: 안드로이드의 웹뷰는 호환성 문제가 매우 크다. 해결 방법은 onDetached From Window를 먼저 보내고 destroy()를 주동적으로 호출하기 전에 웹뷰를parent에서 제거하는 것이다. 구체적인 코드는 다음과 같다.
@Override
protected void onDestroy() {
if( mWebView!=null) {
// destroy() ， if (isDestroyed()) return; ， onDetachedFromWindow()，
// destory()
ViewParent parent = mWebView.getParent();
if (parent != null) {
((ViewGroup) parent).removeView(mWebView);
}
mWebView.stopLoading();
// ， ，
mWebView.getSettings().setJavaScriptEnabled(false);
mWebView.clearHistory();
mWebView.clearView();
mWebView.removeAllViews();
mWebView.destroy();
}
super.on Destroy();
}
PS: 메모리 유출과 메모리 넘침 OOM의 관계: 메모리 유출이 작은 범위에서 누적되어 방출되지 않으면 카드가 끊기고 메모리 유출이 장기적으로 방출되지 않으며 누적이 한도값을 초과하면 OOM이 발생한다.만약에 순간적으로 신청한 메모리가 응용 프로그램이 허용하는 한도값을 초과하면 OOM(예를 들어 응용의 일부 논리적 조작이 대량의 메모리를 미친 듯이 소모하게 된다(예를 들어 처리되지 않은 초대형 초고화질 사진 등을 불러오는 것)는 한도값을 초과하여 OOM을 초래하게 된다는 것을 알 수 있다. 이를 통해 알 수 있듯이 둘은 교차 관계이다.메모리 오버플로우(OutOfMemory Error)의 핵심 원인은 응용된 메모리가 한도값을 초과했기 때문이다.
4. 응답 속도 최적화
응답 속도 최적화의 핵심은 주 라인에서 시간 소모 조작을 피하는 것이 아니라 이런 시간 소모 조작을 하위 라인에 놓고 실행하는 것이다. 즉, 비동기적인 방식으로 실행하는 것이다.응답 속도가 너무 느린 것은 액티비티의 시동 화면에 나타난다. 메인 라인에서 너무 많은 일을 하면 액티비티가 시동을 걸 때 블랙스크린이 생기고 ANR까지 나타날 수 있다.ANR이 생기면/data/anr 디렉토리에 파일traces가 생성됩니다.txt(PS: 서로 다른 휴대전화의 저장 경로가 다를 수 있음)trace 파일을 분석함으로써 ANR의 원인을 더욱 포지셔닝할 수 있다.
5.ListView 최적화
ListView의 최적화는 매우 간단하다. 그의 사상 개술은 다음과 같다. 먼저 ViewHolder를 사용하고 getView에서 시간 소모 조작을 피한다.그 다음에 목록의 미끄럼 상태에 따라 임무의 집행 빈도를 조절해야 한다. 예를 들어 목록이 빠르게 미끄럼을 탈 때 대량의 비동기 임무를 열기에 적합하지 않다.마지막으로 ListView의 슬라이딩을 원활하게 하기 위해 하드웨어 가속을 켜볼 수 있습니다.
ListView의 최적화 현재 가장 유행하는 방식은 RecyclerView로 대체하는 것입니다. 만약에 RecyclerView로 ListView 표시 목록 데이터를 대체하면 이 원칙을 무시할 수 있습니다.
6.Bitmap 최적화
Bitmap 최적화 역시 비교적 간단하다. 그의 사상 개요: 1. BitMapFactory를 통해.Options는 필요에 따라 그림을 샘플링하는데 샘플링 과정은 주로 BitmapFactory를 사용한다.Options의 inSampleSize 매개변수,2. inBitmap의 고급 특성을 이용하여 안드로이드 시스템이 Bitmap의 분배와 방출 집행 효율을 향상시킨다. 이 변수를 사용하면 낡은 Bitmap의 메모리를 재분배하거나 폐기하지 않고 복용할 수 있어 운행 효율을 개선할 수 있다.즉 메모리를 복용하여 메모리 사용량을 줄였다(새 비트맵의 메모리가 낡은 비트맵의 메모리 크기보다 작으면 복용 작업을 할 수 있고, Glide 내부에서도 inBitmap을 캐시 복용의 한 방식으로 사용했다).
7. 스레드 최적화
사상 개술: 스레드 탱크를 사용하여 프로그램에 대량의 Thread가 존재하지 않도록 한다.스레드 탱크는 내부의 스레드를 다시 사용할 수 있어 스레드의 생성과 소각이 가져오는 성능 비용을 피할 수 있다.이 동시에 스레드 탱크는 스레드 탱크의 최대 병발수를 효과적으로 제어하여 대량의 스레드가 서로 시스템 자원을 점유하여 막히는 현상을 초래하는 것을 피할 수 있다.
8. 기타 성능 최적화 원칙
내 글이 당신에게 도움이 될 것 같으면 주목해 주십시오.질문이 있으시면 아래 댓글도 환영합니다. 감사합니다!!!
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
안드로이드 개발의 사용자 정의 View Drawable을 통해 아이콘 그리기텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
