Software Developer USB

원문 링크 :  http://androidjavapoint.blogspot.kr/2017/03/android-performance-avoid-using-enum-on.html Android Performance: Avoid using ENUM on Android 라는 글을 보면서부터 알게된 점이 있다. Enum의 사용이 성능에 문제가 될 수 있다는 점.  (자세한 내용은 위의 본문을 확인) Enum의 문제점이라고 나열된 내용은 아래와 같다. - Enum을 추가하면 dex파일의 크기가 커질 수 있다.    (Enum이 int 대비 13배정도 크다.) - 앱이 실행될 때, dex파일이 Application Heap Memory에 Load 되므로   dex파일의 크기가 커지는 것은 Memory이슈로도 연결된다.   (이미지 출처 :  The price of ENUMs (100 Days of Google Dev) ) 그래서 dex파일에 얼마나 많은 영향을 주는지 직접 확인해봤다. 1. 기본 Enum의 구조   Android Developer Page에서 확인 할 수 있는 enum의 구조는 아래와 같다.      Enum은 기본 Object를 상속받아서 Comparable, Serializable을 implement하고 있다.   (이러니 int 대비 13배가 클 수 밖에...) 2. Enum -> @IntDef, @StringDef 로 변경 시 Dex파일 크기 변경   작업중이었던 실제 Project를 대상으로 Enum을 @IntDef와 @StringDef로 변경을 해보았다.   7개의 Enum을 변경하였고 @IntDef로 변경한 것은 2개 나머지는 @StringDef로 변경하였다.   (총 27개의 Enum instance를 변경함)   (@IntDef와 @StringDef의 사용은 최 상단의 원문에서 확인할 수 있다.)   변경 전 dex의 크기 : 9,379,488 byte   변경 후 de

Launch-Time Performance In this document Launch Internals Cold start Warm start Lukewarm start Profiling Launch Performance Time to initial display Time to full display Common Issues Heavy app initialization Heavy activity initialization Themed launch screens 사용자는 앱이 반응과 로드가 빠른것을 기대한다. 시작 시간이 느린 앱은 이 기대를 충족시켜주지 못하며, 사용자를 실망시킬 수 있다. 이것류의 경험으로 인해 사용자는 Play Store에서 앱을 나쁘게 평가하거나, 앱을 완전히 버리게 될 수 있다. 이 문서는 앱의 실행시간을 최적화 하는데 도움을 주는 정보를 제공한다. 우선 Launch process의 내부구조부터 설명한다. 다음은 어떻게 시작성능을 프로파일 하는지에 대해 이야기 하고, 마지막으로 보편적인 startup-time issue들에 대해 설명하고, 해결방법에 대한 몇가지 힌트를 제공한다. 참고 : https://www.youtube.com/watch?v=Vw1G1s73DsY Launch Internals 앱 실행은 3가지 상태중 하나에서 시작될 수 있다. 각 상태(콜드 start, 웜 start, 미지근한 start[lukewarm start])는 사용자가 앱을 볼 수 있는데 걸리는 시간에 영향을 준다. 콜드 Start에서는 앱은 처음부터 시작한다. 다른 상태에서는, 시스템은 앱을 백그라운드에서 foreground로 가져와야 한다. 추천하는 바는 항상 콜드 스타트라는 가정에서 최적화를 해야한다는 것이다. 이렇게 하면 웜 Start/Lukewarm Start의 성능도 향상시킬 수 있다.  앱의 빠른 시작을 위한 최적화를 위해 시스템레벨과 앱 레벨에서 무슨일이 일어나고 있는

Background Optimizations In this document Restrictions on CONNECTIVITY_ACTION Scheduling Network Jobs on Unmetered Connections Monitoring Network Connectivity While the App is Running Restrictions on NEW_PICTURE and NEW_VIDEO New JobInfo methods New JobParameter Methods Further Optimizing Your App 백그라운드 프로세스는 메모리 혹은 배터리를 많이 소모할 수 있다. 예를들어 Implicit Broadcast는 해당 브로드캐스트를 확인하기 위해 등록된 많은 백그라운드 프로세스를 시작하게 될 것이다. 비록 그 프로세스들이 많은 작업을 수행하지 않을지라도... 이것은 디바이스의 성능과 사용자 경험에 상당한 충격을 줄 수 있다.  이 이슈를 완화하기 위해 Android 7.0에서는 아래 제약사항들이 적용되었다. Android 7.0을 Target으로 하는 앱들 혹은 그 이상의 앱들은 manifest에 브로드캐스트 리시버를 등록하더라도  CONNECTIVITY_ACTION  를 받을 수 없다. 하지만 앱들은 브로드캐스트 리시버를 context가 유효한 상태에서  Context.registerReceiver()  를 사용할 경우  CONNECTIVITY_ACTION  를 받을 수 있다. Apps cannot send or receive  ACTION_NEW_PICTURE  or  ACTION_NEW_VIDEO  broadcasts. 앱들은  ACTION_NEW_PICTURE  또는  ACTION_NEW_VIDEO  브로드캐스트를 보내거나 받을 수 없다. 이 최적화는 모든 앱들에 적용된다.(Android 7.0 target인 앱들에만 적용되는 것이 아니다) 만약 앱이 사용한다 이 인텐트