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

最新のもので ロリポップ 更新、Androidプログラミングは改善を続けています。プラットフォームは最初からかなり成熟しています AOSP リリースし、ユーザーの期待バーをかなり高く設定します。新しいものがどれほど良いか見てください 材料 デザインパターンが見えます！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

恒久的な給与計算機との契約

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

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

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

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

オプション1：

• SEND_SMS権限を要求します。

  SmsManager
• Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse('sms:' + telephoneNumber)); sendIntent.putExtra('sms_body', x); startActivity(sendIntent); を使用してSMSを送信するための独自のコードを記述します。
• ギャラリーアプリが費用がかかる可能性のあるサービスにアクセスする必要がある理由と、アプリを使用するためにこの権限を付与する必要がある理由をユーザーに説明します。

オプション2：

• SMSインテントを開始し、SMS用に設計されたアプリに作業を任せます

  AndroidManifest.xml

疑問がある場合は、オプション2が最善の解決策です。

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

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

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

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

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

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

勘定科目表のベストプラクティス

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

メインスレッドには、ユーザーインターフェイスの応答性を維持するという1つの目的があります。

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

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

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

これはAndroid2.xで非常に一般的だったため、新しいバージョンではシステムで作成できません ネットワーク通話 メインスレッドで。

不和ボットc ++

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

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

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

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

1. 使用する gradle ビルドシステムとして。
2. 使用する 後付け / ボレー ネットワーク通話用。
3. 使用する ピカソ 画像の読み込み用。
4. 使用する グソン / ジャクソン JSON解析用。
5. 使用する 一般的な実装 ソーシャルログイン用。

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

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

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

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

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

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

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

画像を画面に表示する前に、画像をメモリにロードする必要があります。これを行うにはビットマップが最も一般的な方法であるため、プロセス全体のAndroidプログラミングガイドを提供します。

カメラで撮ったばかりの画像を画面に表示したいとします。これに必要な合計メモリは、次の式で計算されます。ARGB_8888

なぜ4？さて、最も一般的/推奨されるビットマップ構成はRGB_565です。つまり、適切に表示するには、描画するピクセルごとに、アルファ、赤、貪欲、青のチャネル用に8ビット（1バイト）をメモリに保持する必要があります。 ARGB_8888のような代替手段があります4 bytes * 4000 * 3000 = 48 MBの半分のメモリを必要とする構成ですが、透明度と色の精度が失われます（おそらく緑の色合いが追加されます）。

フルHDスクリーンと12MPカメラを備えた新しいデバイスがあるとしましょう。撮影した写真のサイズは4000x3000ピクセルで、表示に必要な合計メモリは次のとおりです。4 * 1920 * 1080 = 8.3 MB

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

それでは、画面の解像度を考慮に入れましょう。 1920x1080ピクセルの画面に4000x3000の画像を表示しようとしていますが、最悪のシナリオ（画像を全画面で表示）では、LinearLayoutを超えて割り当てることはできません。記憶の。

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

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

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

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

これがどのように リストビュー （そして最近では RecyclerView ）動作します。

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

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

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

Androidプログラミングの世界では、私が作り上げたばかりのことわざがあります。 「少しの努力ですべての階層をフラット化できます」 。

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

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

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

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

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

CFOの役割は何ですか

これは、古いデバイス（インドなど）があり、

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

要約

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

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