Android開発者が犯す最も一般的な間違いトップ10：プログラミングチュートリアル

公開: 2022-03-11

アンドロイド。 このプラットフォームの何が気に入らないのですか？ 無料で、カスタマイズ可能で、急速に成長しており、携帯電話やタブレットだけでなく、スマートウォッチ、テレビ、車でも利用できます。

最新のLollipopアップデートにより、Androidプログラミングは継続的に改善されています。 プラットフォームは、最初のAOSPリリースからかなり成熟しており、ユーザーの期待値をかなり高く設定しています。 新しいマテリアルデザインパターンの見栄えをよく見てください。

画面サイズ、チップアーキテクチャ、ハードウェア構成、ソフトウェアバージョンが異なる、何千もの異なるデバイスがあります。 残念ながら、セグメンテーションはオープン性の代償であり、高度なAndroidプログラマーであっても、さまざまなデバイスでアプリが失敗する可能性のある方法は数千あります。

このような巨大なセグメンテーションに関係なく、バグの大部分は実際には論理エラーのために発生します。 基本を正しく理解している限り、これらのバグは簡単に防ぐことができます。

これは、Android開発者が犯す最も一般的な10の間違いに対処するためのAndroidプログラミングチュートリアルです。

このチュートリアルでは、Androidプログラミングをより高度なレベルで学びます。

よくある間違い＃1：iOS向けの開発

嬉しいことに、このAndroidの間違いは、最近ではあまり一般的ではありません（Appleがすべての設計基準を設定していた時代が過ぎ去ったことにクライアントが気づき始めていることも一因です）。 しかし、それでも、iOSのクローンであるアプリが時々見られます。

誤解しないでください。私はAndroidプログラミングのエバンジェリストではありません。 私は、モバイルの世界を一歩前進させるすべてのプラットフォームを尊重します。 しかし、2014年になり、ユーザーはかなり長い間Androidを使用しており、プラットフォームに慣れてきました。 iOSの設計標準をそれらにプッシュすることはひどい戦略です！

ガイドラインに違反する非常に正当な理由がない限り、それを行わないでください。 （Googleはこれを常に行っていますが、コピーして貼り付けることはありません。）

このAndroidの間違いの最も一般的な例のいくつかを次に示します。

  1. あなたは静的なタブを作るべきではありません、そしてそれらは一番下に属していません（私はあなたにInstagramを指しています）。
  2. システム通知アイコンに色を付けないでください。
  3. アプリのアイコンは、丸みを帯びた長方形の中に配置しないでください（Facebookなどの実際のロゴでない限り）。
  4. スプラッシュ画面は、初期設定/導入を超えて冗長です。 他のシナリオでは使用しないでください。
  5. リストにはキャレットを付けないでください。

これらは、ユーザーエクスペリエンスを台無しにする可能性のある他の多くの小さなことのほんの一部です。

よくある間違い＃2：Androidデバイス用の開発

単一のタブレット用のキオスク/プロモーションアプリを作成していない限り、Androidアプリがすべてのデバイスで見栄えが良くない可能性があります。 覚えておくべきAndroidプログラミングのヒントをいくつか紹介します。

  • 密度に依存しないピクセル（dp）は、通常のピクセル（px）とは異なります。
  • さまざまな密度と方向を説明するために、リソースが複数回含まれています。
  • 9パッチのドローアブルは、画面に合わせて引き伸ばされます。

文字通り何千もの可能なシナリオがありますが、しばらくすると、それらすべてを少数のケースでカバーする感覚が身に付きます。

あなたは何千ものデバイスを所有していませんか？ 問題ない。 Androidエミュレーターは、物理デバイスの複製に非常に優れています。 さらに良いことに、Genymotionを試してみてください。非常に高速で、さまざまな人気のあるプリセットデバイスが付属しています。

また、デバイスを回転させてみましたか？ すべての地獄は解き放たれることができます…

よくある間違い＃3：インテントを使用しない

インテントはAndroidの重要なコンポーネントの1つです。 これは、アプリのさまざまな部分間、さらにはシステム上のさまざまなアプリ間でデータを渡す方法です。

SMSを介して一部の画像へのダウンロードリンクを共有できるギャラリーアプリがあるとします。 2つのオプションのどちらがより論理的だと思われますか？

オプション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が最善の解決策です。

このアプローチは、ほとんどすべてに適用できます。 コンテンツの共有、写真の撮影、ビデオの録画、連絡先の選択、イベントの追加、ネイティブアプリとのリンクの開設など。

カスタム実装（フィルターを適用するカメラなど）を作成する正当な理由がない限り、これらのシナリオでは常にインテントを使用してください。 プログラミング時間を大幅に節約し、 AndroidManifest.xmlから不要な権限を取り除きます。

よくある間違い＃4：フラグメントを使用しない

少し前にHoneycombで、Androidはフラグメントの概念を導入しました。 それらは、アクティビティ内に存在する独自の（かなり複雑な）ライフサイクルを持つ個別のビルディングブロックと考えてください。 これらはさまざまな画面の最適化に大いに役立ち、親アクティビティによって簡単に管理され、再利用、結合、および自由に配置できます。

アプリ画面ごとに個別のアクティビティを起動することは、システムが可能な限りそれらをメモリに保持しようとするため、非常に非効率的です。 1つを殺しても、他の人が使用していたリソースは解放されません。

このAndroidプログラミングチュートリアルでは、アプリをより効率的にするためにフラグメントを適切に使用することを推奨しています。

Androidコアを深く掘り下げてこの記事を読み、フラグメントの使用に反対することを提唱する場合を除いて、可能な限りフラグメントを使用する必要があります。 基本的に、フラグメントとカーソルローダーの目的は適切ですが、実装は不十分です。

よくある間違い＃5：メインスレッドのブロック

メインスレッドの目的は1つです。それは、ユーザーインターフェイスの応答性を維持することです。

私たちの目/脳が知覚できるフレームレートの測定の背後にある科学は複雑であり、多くの要因の影響を受けますが、一般的なルールは、100ミリ秒を超える遅延で24fps未満のものはスムーズとして知覚されないということです。

これは、ユーザーのアクションのフィードバックが遅れ、プログラムしたAndroidアプリが応答を停止することを意味します。 ユーザーのアプリに対する制御を剥奪すると、欲求不満につながります。欲求不満のユーザーは、非常に否定的なフィードバックを与える傾向があります。

さらに悪いことに、メインスレッドがしばらくブロックされると（アクティビティの場合は5秒、ブロードキャストレシーバーの場合は10秒）、ANRが発生します。

Androidプログラミングを学ぶと、このメッセージを知り、恐れるようになります。この発生を最小限に抑えるために、これらのAndroidプログラミングのヒントに従ってください。

これはAndroid2.xでは非常に一般的であったため、新しいバージョンでは、システムはメインスレッドでネットワーク呼び出しを行うことができません。

メインスレッドのブロックを回避するには、常に次の目的でワーカー/バックグラウンドスレッドを使用します。1。ネットワーク呼び出し2.ビットマップの読み込み3.画像処理4.データベースクエリ5.SDの読み取り/書き込み

よくある間違い＃6：車輪の再発明

「OK、メインスレッドは使用しません。 バックグラウンドスレッドでサーバーと通信する独自​​のコードを作成します。」

番号！ しないでください！ ネットワーク呼び出し、画像の読み込み、データベースアクセス、JSON解析、ソーシャルログインは、アプリで行う最も一般的な操作です。 あなただけでなく、そこにあるすべてのアプリ。 より良い方法があります。 Androidがプラットフォームとしてどのように成熟し、成長したかを覚えていますか？ 例の簡単なリストは次のとおりです。

  1. ビルドシステムとしてgradleを使用します。
  2. ネットワーク通話にはレトロフィット/ボレーを使用します。
  3. 画像の読み込みにはPicassoを使用します。
  4. JSON解析にはGson/Jacksonを使用します。
  5. ソーシャルログインには一般的な実装を使用します。

何かを実装する必要がある場合は、すでに作成され、テストされ、広く使用されている可能性があります。 独自のコードを作成する前に、いくつかの基礎研究を行い、Androidプログラミングチュートリアルを読んでください。

よくある間違い＃7：成功を想定していない

素晴らしい。 長時間実行されるタスクを処理するためのより良い方法があることを学び、その目的のために十分に文書化されたライブラリを使用しています。 ただし、ユーザーは引き続き待機する必要があります。 それは避けられない。 パッケージはすぐには送信、処理、受信されません。 ラウンドトリップ遅延があり、ネットワーク障害が発生し、パッケージが失われ、夢が破壊されます。

しかし、これはすべて測定可能です。 ネットワーク呼び出しが成功する可能性は、失敗する呼び出しよりもはるかに高くなります。 では、成功したリクエストを処理する前にサーバーの応答を待つのはなぜですか？ 成功を想定し、失敗を処理する方がはるかに優れています。 そのため、ユーザーが投稿を高く評価すると、いいねの数がすぐに増え、万が一通話が失敗した場合は、ユーザーに通知されます。

この現代の世界では、即時のフィードバックが期待されています。 人々は待つのが好きではありません。 子供たちは、将来の見返りが不確かな知識を得るために教室に座りたくありません。 アプリはユーザーの心理に対応する必要があります。

よくある間違い＃8：ビットマップを理解していない

ユーザーはコンテンツが大好きです！ 特に、コンテンツが適切にフォーマットされ、見栄えがよい場合。 たとえば、画像は、主に画像ごとに1,000語を伝えるという特性があるため、非常に優れたコンテンツです。 また、多くのメモリを消費します。 たくさんの思い出！

画像が画面に表示される前に、画像をメモリにロードする必要があります。 ビットマップはこれを行うための最も一般的な方法であるため、プロセス全体の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

1つの画像だけで48メガバイトのRAM！？ それは多いです！

次に、画面の解像度を考慮に入れましょう。 1920x1080ピクセルの画面に4000x3000の画像を表示しようとしていますが、最悪のシナリオ（画像をフルスクリーンで表示）では、 4 * 1920 * 1080 = 8.3 MBを超えるメモリを割り当てないでください。

ビットマップを効率的に表示するためのAndroidプログラミングのヒントに常に従ってください。

  1. 画像を表示しているビューを測定します。
  2. それに応じて大きな画像を拡大縮小/トリミングします。
  3. 表示できるものだけを表示します。

よくある間違い＃9：ディープビュー階層の使用

レイアウトにはAndroidでのXMLプレゼンテーションがあります。 コンテンツを描画するには、XMLを解析し、画面を測定し、それに応じてすべての要素を配置する必要があります。 これは、最適化する必要のあるリソースと時間のかかるプロセスです。

これが、ListView（および最近ではRecyclerView）の動作方法です。

レイアウトが一度膨らんだ場合、システムはそれを再利用します。 しかし、それでも、レイアウトの膨張はある時点で発生する必要があります。

画像で3x3グリッドを作成するとします。 これを行う1つの方法は、等しい重みを持つ3つのLinearLayoutを含む垂直LinearLayoutであり、それぞれに等しい重みを持つ3つのImageViewsが含まれます。

一部のAndroidプログラミング初心者は、LinearLayoutsを常に最大限に活用するとは限りません。

このアプローチで何が得られますか？ 「ネストされた重みはパフォーマンスに悪い」という警告。

Androidプログラミングの世界では、 「少しの努力ですべての階層をフラット化できる」ということわざがあります。

この場合、 RelativeLayoutまたはGridLayoutは、ネストされたLinearLayoutsを効率的に置き換えます。

よくある間違い＃10：minSdkVersionを14に設定しない

まあ、これは間違いではありませんが、悪い習慣です。

Android 2.xは、このプラットフォームの開発における大きなマイルストーンでしたが、いくつかのことが取り残されるべきです。 古いデバイスをサポートすると、コードメンテナンスがさらに複雑になり、開発プロセスが制限されます。

数字は明らかであり、ユーザーは先に進んでおり、開発者は遅れをとるべきではありません。

これは古いデバイスを使用する一部の大規模市場（インドなど）には当てはまらないことを認識しています。FacebookアプリでminSdkVersionを14に設定すると、数百万人のユーザーがお気に入りのソーシャルネットワークを利用できなくなります。 ただし、最初から始めてユーザーに美しいエクスペリエンスを提供しようとしている場合は、過去を排除することを検討してください。 リソースを持っていない、またはデバイス/ OSをアップグレードする必要があると感じているユーザーには、Androidアプリの優れたバージョンを試して、最終的にはそれにお金をかけるインセンティブがありません。

要約

Androidは、急速に進化する強力なプラットフォームです。 ユーザーがペースを維持することを期待するのは合理的ではないかもしれませんが、Android開発者がそうすることは非常に重要です。

Androidが私たちの携帯電話やタブレットだけにあるのではないことを知ることはさらに重要です。 それは私たちの手首、私たちの居間、私たちの台所、そして私たちの自動車にあります。 拡大を始める前に、基本を正しく理解することが最も重要です。