1. UIレイアウト開発について
1. 想像するインターフェースのアスペクト比
開発の際、デザイナーが与えたデザイン効果を復元するのはあくまで基本ですが、手元にあるデバイスの効果とデザインの効果を1:1で復元するだけでは合格ラインには達しないと思います。ユーザーの実デバイスを UI デザイナーが与えた設計図として想像しないでください。これは、より多くの解像度のデバイスに適応するのに適しています。
設計図では16:9となっていますが、実際には18:9や1:1の正方形のデバイスも存在する可能性があり、開発時にはアスペクト比の異なるデバイスに同じコントロールをどのように配置するかを考慮する必要があります。例：画面が広くなった場合、コントロールの横幅が大きくなるのか、コントロール間の横方向のスペースが広くなるのかを考慮する必要がありますが、横幅が大きくなるとコントロールの高さは変わりますか？等
要約すると、設計者が与えるエフェクトは多くのデバイス エフェクトのうちの 1 つにすぎず、開発したい結果は_動的_であり、デバイスごとに変化する可能性があります。
2.固定値、たまに毒～
私は開発プロセスで dp 単位の幅や高さを直接使用することはめったにありません。dp はさまざまなピクセル密度に応じて特定の計算や適応も行いますが、パーセンテージ、アスペクト比の制約、剰余の塗りつぶしなど、dp 単位の幅や高さよりも優れた実装方法があります。
wrap_content使う量も少ないし…結局どのくらいの大きさなのか分からないよ〜
3. 画像またはドローアブル?
簡単なエフェクトの場合、画像とドローアブルの両方を使用できる場合がありますが、どのように選択すればよいでしょうか?
写真を使用する利点は、最高の現像効率と最良の復元です。デメリットとしては、インストールパッケージの制御が増える、ネットワークマップを使用すると読み込み速度が遅くなる、サーバーのストレージコストが増加するなどがあります。
ドローアブルを使用する利点は、レイアウトの適応性が向上し、インストール パッケージのスペースが節約されることです。デメリットとしては、修復効果が低い場合があり、開発が難しいことです。
ことわざにあるように、魚と熊の手の両方を持つことはできません〜具体的な状況を詳細に分析してください。
2. リクエストインターフェースについて
1. すべてのインターフェースが均一に処理される
統合処理は、インターフェースの最も基本となる統合変更や統合状態判定に便利です。これは、呼び出しとデバッグ、またはリクエストと戻りデータの表示にも便利です。
通常、インターフェイスの暗号化と復号化、およびデータ検証も統一されたプロセスで実行されます。一部のインターフェイスには、統合処理で追加できるデフォルト フィールドがいくつかある場合があります。
2. インターフェースのフィールド名
同じ意味を持つフィールド名は統一する必要があります。もちろん、モバイル端末として開発する場合、インターフェイスのフィールド名に発言権がない場合は、私が言わなかったことにしてください。
3. インターフェースが 100% 利用可能であると完全に信じないでください。
クライアントはフォールトトレランスのために漢方薬を発行します。たとえば、インターフェイスのエラーにどう対処するか? フィールドが欠落している場合はどうすればよいですか? フィールドの戻り値が無効な場合はどうすればよいですか?
私の習慣では、デフォルトではすべてのフィールドの戻り値の型が String になります。タイプ不一致などの事故の発生を軽減します。フィールドが欠落している場合の事故を避けるために、キー フィールドにはデフォルト値が設定されています。
4. 時には数字の方が意味がある
スイッチや有無を表すいくつかの列挙型フィールドでは、意味を表すために数値を使用することに慣れています。例: 「1」はオンを意味し、「0」はオフを意味します。文字列を使用する場合、タイプミスや大文字小文字の違いが発生する可能性があります。
3. APPアーキテクチャについて
1. APPアーキテクチャの重要性
Android は長年にわたって開発され、MVC、MVP、MVVM などの多くの開発アーキテクチャが登場しました。
これほど多くの種類のアーキテクチャが登場することにはどのような意味があるのでしょうか?
開発効率を向上させ、チームの開発ルールを制限し、コードの読み取りを容易にします。
でもそれは全部デタラメだと思うよ～～～
2. APP アーキテクチャよりも意味のあるもの
コードを読みやすくするために、理解しやすい変数名またはメソッド名を選択してください。
メモを 1 ～ 2 つ追加すると、未来のあなたは現在のあなたに感謝するでしょう。
すべてのコミットで足跡を残し、自分が何をしたかについて話します。もちろん、送信ボタンを押す前に、送信されたすべての内容を再度確認し、自分でテストしたコードを送信しないでください。
サードパーティの SDK を使用する場合は、SDK を見つけた場所 (GitHub アドレスでもブログ アドレスでも) を示すメモを忘れずに残してください。そうすれば、何か問題が発生したときに見つけることができ、その後の SDK バージョン更新の反復にも便利です。
やっと
アーキテクトになりたい場合、または 20,000 ～ 30,000 の給与範囲を突破したい場合は、コーディングとビジネスに限定されず、モデルを選択し、拡張し、プログラミング的思考を向上させることができなければなりません。また、しっかりとしたキャリアプランも大切で、学ぶ習慣も大切ですが、一番大切なのは継続力であり、継続的に実行できないプランは絵にかいたもちです。
方向性がわからない場合は、Ali のシニア アーキテクトによって書かれた一連の「Android モジュール 8 つの上級ノート」を参照してください。これは、乱雑で散在し断片化した知識を体系的に整理し、Android 開発のさまざまな知識を体系的かつ効率的に習得できるようにするためのものです。
私たちが普段読んでいる断片的な内容と比べて、このノートの知識ポイントはより体系的で理解しやすく、覚えやすく、知識体系に従って厳密に配置されています。
ワンクリックと 3 つのリンクで皆さんのサポートを歓迎します。記事内の情報が必要な場合は、記事の最後にある CSDN 公式認定 WeChat カードを直接スキャンして無料で入手できます↓↓↓
PS: グループには ChatGPT ロボットもおり、仕事や技術的な質問に答えることができます。
