Android 개발자가 저지르는 가장 일반적인 10가지 실수: 프로그래밍 자습서

기계적 인조 인간. 이 플랫폼에서 마음에 들지 않는 것은 무엇입니까? 무료이며 사용자 정의가 가능하며 빠르게 성장하고 있으며 휴대전화나 태블릿뿐만 아니라 스마트워치, TV 및 자동차에서도 사용할 수 있습니다.

최신 Lollipop 업데이트를 통해 Android 프로그래밍이 계속 개선됩니다. 플랫폼은 초기 AOSP 릴리스 이후 상당히 성숙했으며 사용자 기대치를 상당히 높게 설정했습니다. 새로운 머티리얼 디자인 패턴이 얼마나 멋진지 보세요!

화면 크기, 칩 아키텍처, 하드웨어 구성 및 소프트웨어 버전이 서로 다른 수천 가지 장치가 있습니다. 불행히도 세분화는 개방성을 위해 치러야 하는 대가이며, 고급 Android 프로그래머라도 다양한 기기에서 앱이 실패할 수 있는 방법은 수천 가지가 있습니다.

이러한 거대한 세분화에도 불구하고 대부분의 버그는 실제로 논리 오류로 인해 도입됩니다. 이러한 버그는 기본 사항만 올바르게 유지하면 쉽게 예방할 수 있습니다!

다음은 Android 개발자가 저지르는 가장 일반적인 10가지 실수를 해결하기 위한 Android 프로그래밍 자습서입니다.

일반적인 실수 #1: iOS용 개발

다행스럽게도 이 Android 실수는 오늘날 훨씬 덜 일반적입니다(부분적으로는 Apple이 모든 디자인 표준을 설정하던 시절이 지났다는 것을 클라이언트가 깨닫기 시작했기 때문입니다). 그러나 때때로 우리는 iOS 클론인 앱을 봅니다.

오해하지 마세요. 저는 Android 프로그래밍 전도사가 아닙니다! 저는 모바일 세상을 한 단계 더 발전시키는 모든 플랫폼을 존중합니다. 하지만 지금은 2014년이고 사용자들은 꽤 오랫동안 안드로이드를 사용해왔고 플랫폼에 익숙해졌습니다. iOS 디자인 표준을 그들에게 강요하는 것은 끔찍한 전략입니다!

지침을 어기는 매우 타당한 이유가 없는 한 그렇게 하지 마십시오. (Google은 항상 이 작업을 수행하지만 복사하여 붙여넣는 것은 아닙니다.)

다음은 이 Android 실수의 가장 일반적인 몇 가지 예입니다.

1. 정적 탭을 만들어서는 안 되며 하단에 속하지도 않습니다(인스타그램을 가리키고 있습니다).
2. 시스템 알림 아이콘에는 색상이 없어야 합니다.
3. 앱 아이콘은 둥근 사각형 안에 배치되어서는 안 됩니다(실제 로고가 아닌 경우(예: Facebook)).
4. 스플래시 화면은 초기 설정/소개 이상으로 중복됩니다. 다른 시나리오에서는 사용하지 마십시오.
5. 목록에는 캐럿이 없어야 합니다.

이것들은 사용자 경험을 망칠 수 있는 다른 많은 작은 것들 중 일부일 뿐입니다.

일반적인 실수 #2: Android 기기용 개발

단일 태블릿용 키오스크/프로모션 앱을 구축하지 않는 한 Android 앱이 모든 기기에서 좋아 보이지 않을 가능성이 있습니다. 다음은 기억해야 할 몇 가지 Android 프로그래밍 팁입니다.

• 밀도 독립 픽셀(dp)은 일반 픽셀(px)과 다릅니다.
• 다양한 밀도와 방향을 설명하기 위해 리소스가 여러 번 포함됩니다.
• 9-패치 드로어블은 화면에 맞게 늘어납니다.

문자 그대로 수천 개의 가능한 시나리오가 있지만 잠시 후 소수의 사례로 모든 시나리오를 다룰 수 있는 감각이 생깁니다.

수천 개의 장치를 소유하고 있지 않습니까? 문제가 아니다. Android Emulator는 물리적 장치를 복제하는 데 매우 뛰어납니다. 더 나아가 Genymotion을 사용해 보십시오. 번개처럼 빠르며 널리 사용되는 다양한 사전 설정 장치가 함께 제공됩니다.

또한 장치를 회전해 보셨습니까? 모든 지옥이 풀릴 수 있습니다 ...

일반적인 실수 #3: 인텐트를 사용하지 않음

인텐트는 Android의 핵심 구성 요소 중 하나입니다. 이는 앱의 다른 부분 또는 시스템의 다른 앱 간에 데이터를 전달하는 방법입니다.

SMS를 통해 일부 이미지에 대한 다운로드 링크를 공유할 수 있는 갤러리 앱이 있다고 가정해 보겠습니다. 두 가지 옵션 중 어느 것이 더 논리적으로 보이나요?

옵션 1:

• SEND_SMS 권한을 요청하세요.

   <uses-permission android:name="android.permission.SEND_SMS" />

• SmsManager 를 사용하여 SMS를 보내기 위한 고유한 코드를 작성하십시오.
• 갤러리 앱에서 비용이 많이 들 수 있는 서비스에 액세스해야 하는 이유와 앱 사용을 위해 이 권한을 부여해야 하는 이유를 사용자에게 설명합니다.

옵션 2:

• SMS 인텐트를 시작하고 SMS용으로 설계된 앱이 작업을 수행하도록 합니다.

   Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse("sms:" + telephoneNumber)); sendIntent.putExtra("sms_body", x); startActivity(sendIntent);

의심이 가는 경우 최상의 솔루션은 옵션 2입니다!

이 접근 방식은 거의 모든 것에 적용될 수 있습니다. 콘텐츠 공유, 사진 촬영, 비디오 녹화, 연락처 선택, 이벤트 추가, 기본 앱과의 링크 열기 등

사용자 정의 구현(예: 필터를 적용하는 카메라)을 수행해야 하는 합당한 이유가 없는 한 항상 이러한 시나리오에 Intents를 사용하십시오. 많은 프로그래밍 시간을 절약하고 AndroidManifest.xml 에서 불필요한 권한을 제거합니다.

일반적인 실수 #4: 프래그먼트를 사용하지 않음

얼마 전 Honeycomb에서 Android는 fragments 개념을 도입했습니다. 활동 내부에 존재하는 고유한(다소 복잡한) 수명 주기가 있는 별도의 빌딩 블록으로 생각하십시오. 다양한 화면에 최적화하는 데 많은 도움이 되며, 부모 활동에 의해 쉽게 관리되고, 재사용, 결합 및 마음대로 배치할 수 있습니다.

각 앱 화면에 대해 별도의 활동을 시작하는 것은 시스템이 가능한 한 오랫동안 활동을 메모리에 유지하려고 하기 때문에 매우 비효율적입니다. 하나를 죽이면 다른 사람들이 사용하는 리소스가 해제되지 않습니다.

Android 코어를 깊이 파고들고 프래그먼트 사용에 반대하는 이 기사를 읽고 싶지 않다면 가능한 한 프래그먼트를 사용해야 합니다. 기본적으로 프래그먼트와 커서 로더는 의도된 목적은 좋지만 구현이 좋지 않다고 말합니다.

일반적인 실수 #5: 메인 스레드 차단

메인 스레드는 사용자 인터페이스의 응답성을 유지하는 단 하나의 목적을 가지고 있습니다.

우리의 눈/뇌가 인식할 수 있는 프레임 속도를 측정하는 과학은 복잡하고 많은 요인의 영향을 받지만 일반적으로 100ms보다 큰 지연이 있는 24fps 미만의 모든 항목은 매끄럽게 인식되지 않습니다.

즉, 사용자의 작업에 피드백이 지연되고 프로그래밍한 Android 앱이 응답을 중지합니다. 앱에 대한 사용자의 제어 권한을 박탈하면 좌절감을 느끼게 되고, 좌절한 사용자는 매우 부정적인 피드백을 제공하는 경향이 있습니다.

설상가상으로 메인 스레드가 잠시 동안(Activity 5초, Broadcast Receivers 10초) 차단되면 ANR이 발생합니다.

이것은 Android 2.x에서 매우 일반적이어서 최신 버전에서는 시스템에서 기본 스레드에서 네트워크 호출을 할 수 없습니다.

메인 스레드를 차단하지 않으려면 항상 작업자/백그라운드 스레드를 사용하십시오. 1. 네트워크 호출 2. 비트맵 로드 3. 이미지 처리 4. 데이터베이스 쿼리 5. SD 읽기/쓰기

일반적인 실수 #6: 바퀴의 재발명

"알겠습니다. 메인 스레드를 사용하지 않겠습니다. 백그라운드 스레드에서 내 서버와 통신하는 나만의 코드를 작성할 것입니다.”

아니요! 그러지 마세요! 네트워크 호출, 이미지 로드, 데이터베이스 액세스, JSON 구문 분석 및 소셜 로그인은 앱에서 수행하는 가장 일반적인 작업입니다. 귀하뿐만 아니라 모든 앱이 있습니다. 더 나은 방법이 있습니다. Android가 플랫폼으로 어떻게 성숙하고 성장했는지 기억하십니까? 다음은 간단한 예 목록입니다.

1. gradle을 빌드 시스템으로 사용하십시오.
2. 네트워크 통화에 Retrofit / Volley를 사용합니다.
3. 이미지 로드에 Picasso를 사용합니다.
4. JSON 구문 분석에 Gson/Jackson을 사용합니다.
5. 소셜 로그인에 공통 구현을 사용합니다.

구현해야 할 것이 있다면 이미 작성, 테스트 및 널리 사용되었을 가능성이 있습니다. 코드를 작성하기 전에 기본적인 조사를 하고 Android 프로그래밍 튜토리얼을 읽어보세요!

일반적인 실수 #7: 성공을 가정하지 않음

엄청난. 우리는 장기 실행 작업을 처리하는 더 좋은 방법이 있다는 것을 배웠고 이를 위해 잘 문서화된 라이브러리를 사용하고 있습니다. 그러나 사용자는 여전히 기다려야 합니다. 불가피하다. 패키지는 즉시 전송, 처리 및 수신되지 않습니다. 왕복 지연이 있고, 네트워크 장애가 있고, 소포가 분실되고, 꿈이 파괴됩니다.

그러나 이 모든 것은 측정 가능합니다. 성공적인 네트워크 호출은 실패한 호출보다 훨씬 가능성이 높습니다. 그렇다면 성공적인 요청을 처리하기 전에 서버 응답을 기다리는 이유는 무엇입니까? 성공을 가정하고 실패를 처리하는 것이 훨씬 낫습니다. 따라서 사용자가 게시물을 좋아하면 좋아요 수가 즉시 증가하고, 만일의 경우 호출이 실패할 경우 사용자에게 알림이 전송됩니다.

이 현대 세계에서 즉각적인 피드백이 기대됩니다. 사람들은 기다리는 것을 좋아하지 않습니다. 아이들은 불확실한 미래 수익이 있는 지식을 얻기 위해 교실에 앉아 있는 것을 원하지 않습니다. 앱은 사용자의 심리를 수용해야 합니다.

일반적인 실수 #8: 비트맵을 이해하지 못함

사용자는 콘텐츠를 좋아합니다! 특히 콘텐츠의 형식이 좋고 보기에 좋습니다. 예를 들어, 이미지는 주로 이미지당 천 단어를 전달하는 속성 때문에 매우 좋은 콘텐츠입니다. 그들은 또한 많은 메모리를 소비합니다. 많은 메모리!

이미지가 화면에 표시되기 전에 메모리에 로드되어야 합니다. 비트맵은 이를 수행하는 가장 일반적인 방법이므로 전체 프로세스에 대한 Android 프로그래밍 가이드를 제공합니다.

방금 카메라로 찍은 이미지를 화면에 표시하고 싶다고 가정해 봅시다. 이에 필요한 총 메모리는 다음 공식으로 계산됩니다. memory_needed_in_bytes = 4 * image_width * image_height;

왜 4? 음, 가장 일반적/권장되는 비트맵 구성은 ARGB_8888 입니다. 즉, 우리가 그리는 각 픽셀에 대해 적절하게 표시하려면 메모리에 알파, 빨강, 탐욕 및 파랑 채널에 대해 8비트(1바이트)를 유지해야 합니다. ARGB_8888 보다 절반의 메모리가 필요하지만 투명도와 색상 정밀도를 잃는 RGB_565 구성과 같은 대안이 있습니다(녹색 색조를 추가하는 동안).

풀 HD 화면과 12MP 카메라를 갖춘 새로운 장치가 있다고 가정해 보겠습니다. 방금 찍은 사진의 크기는 4000x3000픽셀이고 이를 표시하는 데 필요한 총 메모리는 4 bytes * 4000 * 3000 = 48 MB 입니다.

단일 이미지를 위한 48MB의 RAM!? 많은데요!

이제 화면 해상도를 고려해 보겠습니다. 1920x1080 픽셀이 있는 화면에 4000x3000 이미지를 표시하려고 합니다. 최악의 시나리오(이미지 전체 화면 표시)에서는 4 * 1920 * 1080 = 8.3 MB 이상의 메모리를 할당해서는 안 됩니다.

비트맵을 효율적으로 표시하려면 항상 Android 프로그래밍 팁을 따르세요.

1. 이미지를 보여주는 뷰를 측정합니다.
2. 그에 따라 큰 이미지의 크기를 조정/자릅니다.
3. 표시할 수 있는 것만 표시합니다.

일반적인 실수 #9: Deep View Hierarchy 사용

레이아웃에는 Android의 XML 프레젠테이션이 있습니다. 콘텐츠를 그리기 위해서는 XML을 파싱하고, 화면을 측정하고, 그에 따라 모든 요소를 ​​배치해야 합니다. 최적화해야 하는 리소스와 시간이 많이 소요되는 프로세스입니다.

이것이 ListView(그리고 최근에는 RecyclerView)가 작동하는 방식입니다.

레이아웃이 한 번 부풀려지면 시스템에서 이를 재사용합니다. 그러나 여전히 레이아웃을 팽창시키는 것은 어느 시점에서 발생해야 합니다.

이미지로 3x3 격자를 만들고 싶다고 가정해 봅시다. 이를 수행하는 한 가지 방법은 동일한 가중치를 가진 3개의 LinearLayout 을 포함하는 수직 LinearLayout 이며, 각각은 동일한 가중치를 가진 3개의 ImageViews 를 포함합니다.

이 접근 방식으로 무엇을 얻을 수 있습니까? "중첩된 가중치는 성능에 좋지 않습니다"라는 경고입니다.

Android 프로그래밍 세계에 내가 방금 만들어낸 말이 있습니다. "적은 노력으로 모든 계층 구조를 평평하게 만들 수 있습니다." .

이 경우 RelativeLayout 또는 GridLayout 은 중첩된 LinearLayouts 를 효율적으로 대체합니다.

일반적인 실수 #10: minSdkVersion을 14로 설정하지 않음

글쎄, 이것은 실수가 아니지만 나쁜 습관입니다.

Android 2.x는 이 플랫폼을 개발하는 데 있어 큰 이정표였지만 몇 가지를 남겨 두어야 합니다. 구형 장치를 지원하면 코드 유지 관리가 더 복잡해지고 개발 프로세스가 제한됩니다.

숫자는 분명하고 사용자는 계속 이동했으며 개발자는 뒤에 있어서는 안 됩니다.

나는 이것이 오래된 기기(예: 인도)를 사용하는 일부 큰 시장에는 적용되지 않는다는 것을 알고 있으며 Facebook 앱에서 minSdkVersion 을 14로 설정하면 좋아하는 소셜 네트워크 없이 수백만 명의 사용자를 남겨두는 것을 의미합니다. 그러나 새로 시작하고 사용자를 위한 아름다운 경험을 제공하려는 경우 과거를 제거하는 것을 고려하십시오. 리소스가 없거나 기기/OS를 업그레이드해야 할 필요성을 느끼는 사용자는 더 우수한 버전의 Android 앱을 사용해 보고 궁극적으로 그것에 돈을 쓸 인센티브가 없습니다.

마무리

Android는 빠르게 발전하는 강력한 플랫폼입니다. 사용자가 속도를 따라잡을 것으로 기대하는 것은 합리적이지 않을 수 있지만 Android 개발자는 그렇게 하는 것이 중요합니다.

Android가 휴대폰이나 태블릿에만 있는 것이 아니라는 사실을 아는 것이 훨씬 더 중요합니다. 우리의 손목, 거실, 주방, 자동차에 있습니다. 확장을 시작하기 전에 기본을 올바르게 하는 것이 가장 중요합니다.