あなたがインタビューの質問の多くを共有する前に、Manduoは、私たちが神に目を覚ますエラーが発生しやすいのいくつかのシリーズに正しい答えが付属しています。

今日でシンプルな前菜。

この知識は、私はインタビューの中で**余分なポイントとして定義されに応答しない、**、間違ったトピックポイントそれを得たが、以前のインタビューで、私の経験では、それはあまりの学生を完了することができました。

我々はそれについての知識のすべて習得を見てみましょう。

初期のブログの中では、多くの時間は、次の説明を参照してください。

あなたの場合はViewセットがmatch_parentであるonMeasure測定モードでは、以下のようにしましたEXACTLY。
設定した場合wrap_conent、対応する測定モードは、次のとおりAT_MOST。
Aは左UNSPECIFIED、私たちが管理していない使用されていません。

すべての単語の上記の説明は、間違って考えることができます。

だから、今日、私はいくつかの質問をクリアします：

match_parent / wrap_conent必ずしもに対応しEXACTLY/ AT_MOST、それ？
最後に、測定モードは、要因によって決定されますか？
UNSPECIFIED それは本当に珍しいですか？

1. match_parent和wrap_contentそれは対応していなければならないMeasureSpec.EXACTLYとMeasureSpec.AT_MOSTいますか？

確かではありません。

なぜ？

のでViewでmeasure時間、その幅と高さは、MeasureSpec親コンテナに完全に依存し、説教親コンテナは、それが受信するものは何かということです。

親コンテナの場合はonMeasure死亡したそれぞれの子の内側に書かれた方法Viewであり、そして、あなたがしているかどうかのレイアウトや幅と高さを設定する方法で良い、最終児童あるの受信されました。MeasureSpecModeUNSPECIFIEDxmlLayoutParamsViewonMeasureUNSPECIFIED

まあ、意図的に手動で指定されていません。

視野の通常の角度を取ります：

私たちは皆、知っているカスタムそのViewGroupプロセス、必要としているonMeasureサブたView措置。

測定サブView時、しばしばによってmeasureChild、measureChildWithMargins方法が行われている（例えばFrameLayout、LinearLayout、CoordinatorLayout、ViewPager2）。

あるいは呼び出しViewGroup静的メソッドをgetChildMeasureSpec直接標的子得るためViewのをMeasureSpec手動次いで、及びmeasure（例えばScrollView、NestedScrollView、DrawerLayout、TabLayout、ConstraintLayout）。

実際に、measureChildそしてmeasureChildWithMarginsまた、通過したgetChildMeasureSpec取得する方法MeasureSpec、すなわち、これらの容器は、子供の測定では、上述したView、第一貫通される前にgetChildMeasureSpec取得するためのサブ方法にView幅と高さをMeasureSpec、その後子に渡さViewでmeasureプロセス。

さて、私たちは今、見とるgetChildMeasureSpecん方法を：

  public static int getChildMeasureSpec(int spec, int padding, int childDimension) {
      int specMode = MeasureSpec.getMode(spec);
      ......
      switch (specMode) {
          case MeasureSpec.EXACTLY:
              if (childDimension >= 0) {
                  ......
                  resultMode = MeasureSpec.EXACTLY;
              } else if (childDimension == ViewGroup.LayoutParams.MATCH_PARENT) {
                  ......
                  resultMode = MeasureSpec.EXACTLY;
              } else if (childDimension == ViewGroup.LayoutParams.WRAP_CONTENT) {
                  ......
                  resultMode = MeasureSpec.AT_MOST;
              }
              break;

          case MeasureSpec.AT_MOST:
              if (childDimension >= 0) {
                  ......
                  resultMode = MeasureSpec.EXACTLY;
              } else if (childDimension == ViewGroup.LayoutParams.MATCH_PARENT) {
                  ......
                  resultMode = MeasureSpec.AT_MOST;
              } else if (childDimension == ViewGroup.LayoutParams.WRAP_CONTENT) {
                  ......
                  resultMode = MeasureSpec.AT_MOST;
              }
              break;

          case MeasureSpec.UNSPECIFIED:
              if (childDimension >= 0) {
                  ......
                  resultMode = MeasureSpec.EXACTLY;
              } else if (childDimension == ViewGroup.LayoutParams.MATCH_PARENT) {
                  ......
                  resultMode = MeasureSpec.UNSPECIFIED;
              } else if (childDimension == ViewGroup.LayoutParams.WRAP_CONTENT) {
                  ......
                  resultMode = MeasureSpec.UNSPECIFIED;
              }
              break;
      }
      return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
  }

あなたは見ることができます：

親コンテナ** specMode为EXACTLY**すべての通常の（子のViewサイズが指定されているmatch_parentか、正確なdimen値、Mode = EXACTLYサイズが指定されてwrap_contentいますMode = AT_MOST）。

ときに親コンテナ** specMode为AT_MOST**時、ああ、指定に加えて、見ることができるdimenかどうかを設定し、値の外にmatch_parentかwrap_content、Mode最終的になりますAT_MOST。

親コンテナ**が場合specModeであるUNSPECIFIEDので、**、上記ロジックと、それらは類似しているとなりUNSPECIFIED、正確な指定がない限り、dimen値。

したがって、この方法は、幅と高さを受け、によって完全でないレイアウトの幅と高さまたは設定された幅と高さの値を決定します。ViewonMeasureMeasureSpecxmlLayoutParams

2.モードのMeasureSpecに影響を与える要因は何ですか？

ちょうどgetChildMeasureSpec方法を見ることができるように、測定モードに影響を与える要因は、測定容器の表示モードは、主表示属します。

すなわち、（意図的に設定されていない任意）、ビュー測定モードによる通常の状況下で、です。

**独自のLayoutParams価値** +セット測定モードの親コンテナが決定しました。

なぜ誰もが言うMeasureSpec.UNSPECIFIEDことは一般的ではないでしょうか？

我々このモデルはおそらく、レイアウト、書き込み時には、一般的ではないことを、すべての感触Viewだけ選択することができ、幅と高さをmatch_parent、wrap_content相対的に言って、正確なサイズを直接指定し、MeasureSpec.UNSPECIFIEDそれはのようなので、日々の開発では、非常に明確ではありませんカスタマイズせずView、基本的にはそれが直接に接触しません。

3. MeasureSpec.UNSPECIFIEDは本当に珍しいことではないでしょうか？

日々の習慣ではView、私は特別な治療をしなければならないことはまれ特にこのモデルのために、ほとんどの場合、としてそれを考えるだろうかMeasureSpec.AT_MOST、最も一般的に使用されるのと同様に、同じ外観TextView、それはまた、測定を区別しませんUNSPECIFIED和AT_MOSTが。

このパターンはあまり直接的な接触があるものの、多くの場面で、私たちのような、無意識のうちに費やす必要があれば、幅/高さがあり、その後、およびスクロール可能なリストの幅/高さ測定モードそれは次のようになります。RecyclerViewItemItemwrap_contentItemUNSPECIFIED

あるNestedScrollViewとScrollView彼らは自己拡張しているので、FrameLayout自分の子供がので、View二回最初の測定を測定する際に、子供ViewのheightMeasureSpecパターンは、死者のために書くことですUNSPECIFIEDの。

私たちは、カスタムViewGroupサブに許可された場合、処理するViewよりも、寸法ViewGroup子を測定する、大規模なViewあなたを置くことができたときにMode指定されましたUNSPECIFIED。

まあ、私はあなたが徹底的に知識のカスタム測定モードを理解してほしいです。

誰かが私にチャートを送信し、この数字は実際には、この数字は少し小さな問題だった、ということを理解することができるようになりますともあります。

私は、この値は、場所を丸で囲ん必ずしも0ではありませんが、ほとんどの場合、UNSPECIFIEDこのモードでは、この気にしないかもしれませんsize。

遂に

します。https：//github.com/Meng997998/AndroidJXすべての今日のために、私はAndroidのコア技術の学習、私のGitHubでのプレーに関連するコンテンツへのアクセスを概説します

この方法を進めたために、学習が報われる！

あなたが学習に投資するあなたの時間を取る、それはあなたが、スキルを獲得し、収益を増加させる機会を持つことができることを意味します。

私の共有Daquanのを学ぶためにAndroidのPDFを

AndroidのPDF Daquanのは、本当にすべての側面を含んで学習し、基本的なJavaの知識、アンドロイド、Androidの高度な拡張の基礎、およびそのコレクションアルゴリズム上が含まれています

私は個人的に紹介しDaquanの懸念を学習AndroidのPDF、またはプライベートの手紙I GET

マイコレクション本研究では、効果的にあなたが知識ポイントを把握するのに役立つことができます。

要するに、私たちは、高度な学習強化ここで助けにもありますが、またあなたは、オンライン検索データを学習する時間を節約するにも一緒に勉強親しい友人と共有することができます

アルファ789

公開された168元の記事・ウォン称賛71 ・ビュー20000 +

プライベートの手紙の懸念

学習アンドロイド「エラーが発生しやすい」シリーズ：ピットのうち古いドライバ、あなたはまだに行きますか？

遂に

おすすめ