第 5 章的摘要。 因應大小
注意
這本書於2016年春季出版，此後一直沒有更新。 這本書中有很多仍然有價值，但一些材料已經過時，有些主題不再完全正確或完整。
到目前為止，已遇到數個 大小 Xamarin.Forms ：
- iOS 狀態列的高度為 20
BoxView的預設寬度和高度為 40- 中的
Frame預設值Padding為 20 - 的
StackLayout預設值Spacing為 6 - 方法
Device.GetNamedSize會傳回數值字型大小
這些大小不是圖元。 相反地，它們是每個平臺獨立辨識的裝置獨立單位。
圖元、點、dps、DIP 和 DIU
在 Apple Mac 和 Microsoft Windows 的歷程記錄中，程式設計人員以像素為單位工作。 不過，高解析度顯示器的出現需要更虛擬化和抽象的螢幕座標方法。 在 Mac 世界中，程式設計人員以點為單位工作，傳統上是 1/72 英吋，而 Windows 開發人員則使用以 1/96 英吋為基礎的裝置獨立單元 （DIU）。
然而，行動裝置通常與臉部更接近，解析度高於桌面螢幕，這表示可以容忍更大的圖元密度。
以 Apple iPhone 和 iPad 裝置為目標的程式設計人員會繼續以點為單位運作，但其中 160 個點指向英吋。 視裝置而定，點可能有 1、2 或 3 圖元。
Android 很類似。 程序設計人員會以密度無關圖元 （dps） 單位工作，dps 與像素之間的關聯性是以 160 dps 為基礎。
Windows 手機和行動裝置也建立了縮放比例，這意味著接近 160 個裝置獨立單位到英吋。
注意
Xamarin.Forms 不再支援任何以 Windows 為基礎的手機或行動裝置。
總而言之，以 Xamarin.Forms 手機和平板計算機為目標的程式設計人員可以假設所有度量單位都是以下列準則為基礎：
- 160 單位到英吋，相當於
- 64 單位到公分
所VisualElement定義的唯讀Width和Height屬性預設為 -1 的「模擬」值。 只有當元素已重設大小並容納於配置中時，這些屬性才會反映與裝置無關單位的項目實際大小。 這個大小包含 專案上的任何 Padding 集合，但不包含 Margin。
視覺專案會在 SizeChanged 事件 Width 或 Height 變更時引發事件。 WhatSize 範例會使用此事件來顯示程式畫面的大小。
計量大小
MetricalBoxView 會使用 WidthRequest 和 HeightRequest 來顯示一BoxView英吋高和一釐米寬。
估計字型大小
FontSizes 範例示範如何使用 160 英吋到英吋的規則，以點為單位指定字型大小。 使用這項技術的平台之間的視覺一致性優於 Device.GetNamedSize。
將文字調整為可用大小
您可以使用下列準則來計算 FontSize 的 Label ，以符合特定矩形內的文字區塊：
- 行距是字型大小的 120%（Windows 平臺上的 130%） 。
- 平均字元寬度是字型大小的50%。
EstimatedFontSize 範例示範這項技術。 這個程式是在屬性可供使用之前 Margin 撰寫的，因此它會使用 ContentView 搭配 Padding 設定來模擬邊界。
大小調整的時鐘
FitToSizeClock 範例示範如何使用 Device.StartTimer 來啟動定時器，以在更新時鐘時定期通知應用程式。 字型大小會設定為頁面寬度的六分之一，讓顯示盡可能大。
輔助功能問題
EstimatedFontSize 程式和 FitToSizeClock 程式都包含微妙的缺陷：如果使用者在 Android 或 Windows 10 行動裝置版 上變更手機的輔助功能設定，程式就無法再根據字型大小來估計文字轉譯的大小。 AccessibilityTest 範例示範此問題。
以經驗方式調整文字
將文字調整成矩形的另一種方式，就是以經驗方式計算轉譯的文字大小，並將其向上或向下調整。 書籍中的程式會呼叫 GetSizeRequest 視覺元素，以取得專案所需的大小。 該方法已被取代，而程式應該改為呼叫 Measure。
Label針對，第一個自變數應該是容器的寬度（以允許換行），而第二個自變數應設定Double.PositiveInfinity為 ，讓高度不受限制。 經驗FontSize 範例示範這項技術。