Erstellen von Ressourcen für unterschiedliche Bildschirme
Android selbst wird auf vielen verschiedenen Geräten ausgeführt, wobei jede eine Vielzahl von Auflösungen, Bildschirmgrößen und Bildschirmdichten hat. Android führt Skalierung und Größenänderung durch, damit Ihre Anwendung auf diesen Geräten funktioniert, dies kann jedoch zu einer suboptimalen Benutzererfahrung führen. Beispielsweise können Bilder verschwommen angezeigt werden oder in einer Ansicht wie erwartet positioniert werden.
Konzepte
Einige Begriffe und Konzepte sind wichtig, um mehrere Bildschirme zu unterstützen.
Bildschirmgröße – Die Menge des physischen Platzes für die Anzeige Ihrer Anwendung
Bildschirmdichte – Die Anzahl der Pixel in einem bestimmten Bereich auf dem Bildschirm. Die typische Maßeinheit ist Punkte pro Zoll (dpi).
Auflösung – Die Gesamtanzahl der Pixel auf dem Bildschirm. Bei der Entwicklung von Anwendungen ist die Auflösung nicht so wichtig wie die Bildschirmgröße und -dichte.
Dichteunabhängiges Pixel (dp) – Eine virtuelle Maßeinheit, mit der Layouts unabhängig von der Dichte entworfen werden können. Diese Formel wird verwendet, um dp in Bildschirmpixel zu konvertieren:
px = dp × dpi ÷ 160
Ausrichtung – Die Bildschirmausrichtung wird als Querformat betrachtet, wenn sie breiter ist als hoch. Im Gegensatz dazu ist hoch, wenn der Bildschirm höher ist als breit. Die Ausrichtung kann sich während der Lebensdauer einer Anwendung ändern, während der Benutzer das Gerät dreht.
Beachten Sie, dass die ersten drei dieser Konzepte miteinander verbunden sind – die Auflösung zu erhöhen, ohne die Dichte zu erhöhen, erhöht die Bildschirmgröße. Wenn jedoch sowohl die Dichte als auch die Auflösung erhöht werden, kann die Bildschirmgröße unverändert bleiben. Diese Beziehung zwischen Bildschirmgröße, Dichte und Auflösung erschwert die Bildschirmunterstützung schnell.
Um diese Komplexität zu bewältigen, bevorzugt das Android-Framework die Verwendung von dichteunabhängigen Pixeln (dp) für Bildschirmlayouts. Durch die Verwendung von unabhängigen Pixeln mit dichteunabhängigen Pixeln wird dem Benutzer die gleiche physische Größe auf Bildschirmen mit unterschiedlichen Dichten angezeigt.
Unterstützen verschiedener Bildschirmgrößen und Dichten
Android behandelt die meiste Arbeit, um die Layouts für jede Bildschirmkonfiguration ordnungsgemäß zu rendern. Es gibt jedoch einige Aktionen, die ausgeführt werden können, um das System zu unterstützen.
Die Verwendung von dichteunabhängigen Pixeln anstelle der tatsächlichen Pixel in Layouts reicht in den meisten Fällen aus, um die Dichteunabhängigkeit zu gewährleisten. Android skaliert die Drawables zur Laufzeit auf die entsprechende Größe. Es ist jedoch möglich, dass die Skalierung dazu führt, dass Bitmaps unscharf erscheinen. Um dieses Problem zu umgehen, stellen Sie alternative Ressourcen für die verschiedenen Dichten bereit. Beim Entwerfen von Geräten für mehrere Auflösungen und Bildschirmdichten wird es einfacher sein, mit den Bildern mit höherer Auflösung oder Dichte zu beginnen und dann nach unten zu skalieren.
Deklarieren der unterstützten Bildschirmgröße
Durch das Deklarieren der Bildschirmgröße wird sichergestellt, dass nur unterstützte Geräte die Anwendung herunterladen können. Dies erfolgt durch Festlegen des Supports-Screens-Elements in der AndroidManifest.xml Datei. Dieses Element wird verwendet, um anzugeben, welche Bildschirmgrößen von der Anwendung unterstützt werden. Ein gegebener Bildschirm wird als unterstützt betrachtet, wenn die Anwendung ihre Layouts ordnungsgemäß platzieren kann, um den Bildschirm auszufüllen. Durch die Verwendung dieses Manifestelements wird die Anwendung nicht in Google Play für Geräte angezeigt, die die Bildschirmspezifikationen nicht erfüllen. Die Anwendung wird jedoch weiterhin auf Geräten mit nicht unterstützten Bildschirmen ausgeführt, aber die Layouts werden möglicherweise verschwommen und pixeliert angezeigt.
Unterstützte Bildschirmsechsen werden in der Datei "Properites/AndroidManifest.xml " der Lösung deklariert:
Bearbeiten Sie AndroidManifest.xml, um Unterstützungsbildschirme einzuschließen:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1"
android:versionName="1.0"
package="HelloWorld.HelloWorld">
<uses-sdk android:minSdkVersion="21" android:targetSdkVersion="27" />
<supports-screens android:resizable="true"
android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true" />
<application android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true" android:theme="@style/AppTheme">
</application>
</manifest>
Bereitstellen alternativer Layouts für unterschiedliche Bildschirmgrößen
Alternative Layouts ermöglichen es, eine Ansicht für eine bestimmte Bildschirmgröße anzupassen, die Positionierung oder Größe der Ui-Elemente der Komponente zu ändern.
Ab API-Ebene 13 (Android 3.2) sind die Bildschirmgrößen zugunsten der Verwendung des SwNdp-Qualifizierers veraltet. Dieser neue Qualifizierer deklariert den Speicherplatz, den ein bestimmtes Layout benötigt. Es wird empfohlen, dass Anwendungen, die unter Android 3.2 oder höher ausgeführt werden sollen, diese neueren Qualifizierer verwenden sollten.
Wenn z. B. ein Layout mindestens 700 DP Bildschirmbreite benötigt, würde das alternative Layout in ein Ordnerlayout -sw700dp gehen:
Als Richtlinie finden Sie hier einige Nummern für verschiedene Geräte:
Typisches Telefon – 320 dp: ein typisches Telefon
Ein 5"-Tablet / "Tweener"-Gerät – 480 dp: wie die Samsung Note
Eine 7"-Tablette – 600 dp: wie die Barnes & Noble Nook
Eine 10"-Tablette – 720 dp: wie das Htc Xoom
Für Anwendungen, die AUF API-Ebenen bis zu 12 (Android 3.1) abzielen, sollten sich die Layouts in Verzeichnissen befinden, in denen die Qualifizierer kleine/normale große//xlarge als Generalisierungen der verschiedenen Bildschirmgrößen verwendet werden, die auf den meisten Geräten verfügbar sind. In der abbildung unten gibt es beispielsweise alternative Ressourcen für die vier verschiedenen Bildschirmgrößen:
Im Folgenden wird verglichen, wie die älteren Qualifizierer der Vor-API-Ebene 13 mit dichteunabhängigen Pixeln vergleichen:
426 dp x 320 dp ist klein
470 dp x 320 dp ist normal
640 dp x 480 dp ist groß
960 dp x 720 dp ist xlarge
Die neueren Bildschirmgrößenqualifizierer in API-Ebene 13 und höher haben eine höhere Priorität als die älteren Bildschirmqualifizierer der API-Ebenen 12 und niedriger. Für Anwendungen, die die alten und die neuen API-Ebenen umfassen, kann es erforderlich sein, alternative Ressourcen mithilfe beider Qualifizierergruppen zu erstellen, wie im folgenden Screenshot gezeigt:
Bereitstellen unterschiedlicher Bitmaps für unterschiedliche Bildschirmdichten
Obwohl Android Bitmaps nach Bedarf für ein Gerät skaliert, werden die Bitmaps selbst möglicherweise nicht elegant nach oben oder unten skaliert: Sie werden möglicherweise fuzzy oder verschwommen. Die Bereitstellung von Bitmaps, die für die Bildschirmdichte geeignet sind, mindert dieses Problem.
Die abbildung unten ist z. B. ein Beispiel für Layout- und Darstellungsprobleme, die auftreten können, wenn keine Ressourcen für die Dichte angegeben werden.
Vergleichen Sie dies mit einem Layout, das mit dichtespezifischen Ressourcen entworfen wurde:
Erstellen unterschiedlicher Dichteressourcen mit Android Asset Studio
Die Erstellung dieser Bitmaps verschiedener Dichten kann etwas mühsam sein. Google hat daher ein Online-Dienstprogramm erstellt, das einige der tedium-Elemente reduzieren kann, die mit der Erstellung dieser Bitmaps als Android Asset Studio bezeichnet werden.
Diese Website hilft bei der Erstellung von Bitmaps, die auf die vier allgemeinen Bildschirmdichten abzielen, indem ein Bild bereitgestellt wird. Android Asset Studio erstellt dann die Bitmaps mit einigen Anpassungen und lässt sie dann als ZIP-Datei herunterladen.
Tipps für mehrere Bildschirme
Android wird auf einer verwirrenden Anzahl von Geräten ausgeführt, und die Kombination aus Bildschirmgrößen und Bildschirmdichten kann überwältigend erscheinen. Die folgenden Tipps können dazu beitragen, den erforderlichen Aufwand für die Unterstützung verschiedener Geräte zu minimieren:
Nur Design und Entwicklung für das, was Sie benötigen – Es gibt viele verschiedene Geräte dort, aber einige existieren in seltenen Formfaktoren, die erhebliche Anstrengungen unternehmen können, um designen und entwickeln für. Das Dashboard "Bildschirmgröße" und "Dichte " ist eine Seite von Google, die Daten zur Aufschlüsselung der Bildschirmgröße/Bildschirmdichtematrix bereitstellt. Diese Aufschlüsselung bietet Einblicke in die Entwicklung von Entwicklungsanstrengungen auf unterstützenden Bildschirmen.
Verwenden Sie DPs anstelle von Pixeln – Pixel werden problematisch, wenn sich die Bildschirmdichte ändert. Pixelwerte nicht hartcodieren. Vermeiden Sie Pixel zugunsten von DP (dichteunabhängige Pixel).
Vermeiden Sie AbsoluteLayoutwo immer möglich – sie ist in API-Ebene 3 (Android 1.5) veraltet und führt zu spröden Layouts. Es sollte nicht verwendet werden. Versuchen Sie stattdessen, flexiblere Layout-Widgets wie LinearLayout, RelativeLayout oder das neue GridLayout zu verwenden.
Wählen Sie eine Layoutausrichtung als Standard aus– Anstatt beispielsweise die alternativen Ressourcen layoutland und layoutport bereitzustellen, platzieren Sie die Ressourcen für das Querformat im Layout und die Ressourcen für das Hochformat in layoutport.
Verwenden Sie LayoutParams für Höhe und Breite – Beim Definieren von UI-Elementen in einer XML-Layoutdatei wird eine Android-Anwendung, die die wrap_content verwendet, und fill_parent Werte haben mehr Erfolg, um ein ordnungsgemäßes Aussehen auf verschiedenen Geräten zu gewährleisten, als pixel- oder dichteunabhängige Einheiten zu verwenden. Diese Dimensionswerte führen dazu, dass Android Bitmapressourcen entsprechend skaliert. Aus diesem Grund sind dichteunabhängige Einheiten am besten für die Angabe der Seitenränder und des Abstands von UI-Elementen reserviert.
Testen mehrerer Bildschirme
Eine Android-Anwendung muss auf alle Konfigurationen getestet werden, die unterstützt werden. Idealerweise sollten Geräte auf den eigentlichen Geräten selbst getestet werden, aber in vielen Fällen ist dies nicht möglich oder praktisch. In diesem Fall ist die Verwendung des Emulators und der Android Virtual Devices-Einrichtung für jede Gerätekonfiguration hilfreich.
Das Android SDK bietet einige Emulator-Skins, die zum Erstellen von AVDs verwendet werden können, replizieren die Größe, Dichte und Auflösung vieler Geräte. Viele der Hardwareanbieter bieten ebenfalls Skins für ihre Geräte.
Eine weitere Möglichkeit besteht darin, die Dienste eines Drittanbieter-Testdiensts zu verwenden. Diese Dienste nehmen ein APK, führen sie auf vielen verschiedenen Geräten aus und geben dann Feedback, wie die Anwendung funktioniert hat.