Android şu anda en kararlı ve verimli UI adaptasyon şeması
On yıldan fazla bir süredir Android sisteminin piyasaya sürülmesinden bu yana, Android kullanıcı arayüzünün uyarlanması her zaman geliştirme sürecinde en önemli konu olmuştur, ancak hala Android adaptasyon şemasını anlamayan çok sayıda küçük ortak olduğunu görüyorum. Utanç'ın Android istemcisi için bir dizi UI boyut uyarlama şeması tasarlamayı planlıyorum.
Android uyarlamasının iki temel sorunu vardır: Birincisi, uyarlamanın verimliliği, yani tasarım çizimini Uygulama arayüzüne dönüştürme sürecinin verimli olup olmadığı, diğeri ise UI arayüzünün farklı boyut ve çözünürlükteki cep telefonlarında uygulanmasının nasıl sağlanacağıdır. Tutarlılık. Bu iki konu çok önemlidir: Biri geliştirmemizin verimliliğini sağlamak, diğeri ise adaptasyonumuzun etkinliğini sağlamak; bugün bu iki temel konu üzerine Android adaptasyon şemasından bahsedeceğiz.
Öncelikle herkes bilir ki boyutu belirlerken Android bize gerçek piksel birimini kullanmamızı önermiyor çünkü çözünürlük farklı cep telefonları arasında farklıdır.Örneğin 96 * 96 piksellik bir kontrolün çözünürlüğü artıyor. Daha uzun telefonlar genel kullanıcı arayüzünde daha küçük ve daha küçük görünecektir.
Yukarıdaki resme benzer görünmektedir, genel düzen efekti deforme olabilir, bu nedenle düzen dosyasında px birimi önerilmez.
dp doğrudan uyarlama
Bu duruma yanıt olarak Android, kullanıcı arayüzüne uyum sağlamak için boyut birimi olarak dp'nin kullanılmasını önerir.
Peki dp nedir? dp, cihazdan bağımsız pikselleri ifade eder. Boyut birimi olarak dp ile kontrol, farklı çözünürlük ve boyutlardaki cep telefonlarında farklı gerçek pikselleri temsil eder. Örneğin, daha düşük çözünürlüklü bir cep telefonunda 1dp = 1px olabilir. Daha yüksek oranlı telefonlarda 1dp = 2px Bu durumda 96 * 96dp kontrol farklı telefonlarda aynı boyutu gösterebilir. Peki bu dp nasıl hesaplanır? Hepimiz bir formül biliyoruz: px = dp (dpi / 160) Sistem bunu px ve dp arasındaki matematiksel ilişkiyi yargılamak için kullanır.
O zaman başka bir soru daha var, dpi nedir?
dpi, sistem yazılımında belirtilen birim boyutu başına piksel sayısını ifade eden piksel yoğunluğudur ve genellikle sistem fabrikası yapılandırma dosyasında yazılı sabit bir değerdir.
Bunun bir yazılım sistemi üzerine bir kavram olduğunu neden vurgulamalıyım? Çünkü cep telefonu aldığınızda sıklıkla ppi denilen başka bir parametre duyarsınız.Bu aynı zamanda cep telefonu ekranındaki piksel yoğunluğunu da ifade eder ama bu fiziksel bir kavramdır ve nesnel olarak değişmez. dpi, fiziksel piksel yoğunluğuna atıfta bulunulduktan sonra yazılım tarafından manuel olarak belirtilen bir değerdir ve bu, belirli bir aralıktaki fiziksel piksel yoğunluğunun yazılımda aynı değeri kullanmasını sağlar. Bu, kullanıcı arayüzü adaptasyonumuzu kolaylaştıracaktır.
Örneğin, aynı çözünürlüğe ve farklı boyutlara sahip birkaç cep telefonunun ppi'si sırasıyla 430,440,450 olabilir. Daha sonra Android sisteminde, dpi'nin tümü 480 olarak belirlenebilir. Bu durumda, dpi / 160 nispeten sabit bir değer olacaktır, bu nedenle Aynı çözünürlük altında farklı boyutlardaki cep telefonlarının aynı performansını sağlayabilmektedir.
Farklı çözünürlüklerde, dpi aşağıdakiler gibi farklı olacaktır:
Yukarıdaki tabloya göre 720P ve 1080P cep telefonlarının farklı dpi değerlerine sahip olduğunu bulabiliriz, bu da farklı çözünürlüklerde 1dp'nin farklı bir piksel sayısına karşılık geldiği anlamına gelir (720P'de, 1dp = 2px ve 1080P'de 1dp) = 3px), bu elde edilir.Bir kontrolün boyutunu tanımlamak için dp kullandığımızda, farklı cep telefonlarında karşılık gelen piksel değerini gösterecektir.
Dp plus uyarlanabilir düzen ve ağırlık orantılı düzeni sayesinde temelde farklı telefonlarda uyum sorununu çözebileceğini söyleyebiliriz ki bu temelde en ilkel Android uyarlama çözümüdür.
Bu yöntemde iki küçük sorun var: Birincisi, yazdığımız arayüzün çoğu cep telefonuyla uyumlu olmasını sağlayabilir.Bazı cep telefonlarının yine de ayrı olarak uyarlanması gerekir.Dp neden adaptasyon problemlerinin sadece% 90'ını çözüyor? 1080P cep telefonlarının hepsinde 480 dpi yoktur. Örneğin, Google'ın Pixel2 (1920 x 1080) bir 420 dpi değerine sahiptir. Yani Pixel2'de 1dp = 2.625px Bu, aynı çözünürlüğe sahip bir cep telefonuyla sonuçlanacaktır. Bir 100dp * 100dp kontrol, genel bir 1080P cep telefonunda 300px olabilir, ancak Pixel 2'de yalnızca 262.5px olabilir, bu nedenle kontrolün gerçek boyutu farklı olacaktır.
Daha canlı göstermek için, bir ImageView genişliğini layout dosyasında 360dp olarak ayarladığımızı ve ardından aşağıdaki iki şekilde performansın farklı olduğunu varsayalım:
Resim 11080P, 480dpi cep telefonu, Resim 21080P, 420dpi cep telefonu
Yukarıdaki düzende de görebileceğiniz gibi, aynı 1080P cep telefonu için fark ortada. Bu durumda, kullanıcı arayüzümüzün ince ayarlanması veya hatta ayrı ayrı uyarlanması gerekebilir.
İkinci sorun, bu yöntemin tasarımcının tasarım taslağını yerleşim koduna hızlı ve verimli bir şekilde uygulayamamasıdır. Dp'nin doğrudan uyarlanmasıyla, kullanıcı arayüzünü yalnızca temelde farklı cep telefonlarına uyarlayabiliriz, ancak tasarım çiziminde ve kullanıcı arayüzü kodunda Dp arasındaki boşluk çözülemez çünkü dp gerçek bir piksel değildir. Dahası, tasarım taslağının genişliği ve yüksekliği genellikle Android telefonun gerçek genişliğinden ve yüksekliğinden çok farklıdır.Örnek olarak tasarım taslağımızı alın. Tasarım taslağının genişliği ve yüksekliği 375px * 750px iken gerçek cep telefonu genellikle 1080 * 1920 olabilir.
Peki günlük gelişimde bu boşluğu nasıl aşarız? Temel olarak, yüzdeyle veya tahmin yoluyla veya standart bir değer belirleyerek vb. Kısacası tasarım taslağını aldığımızda tasarım taslağının ImageView'ı 128px * 128px, layout dosyasını yazarken direkt olarak 128dp * 128dp olarak yazamayız. Tasarım taslağını UI koduna dönüştürme sürecinde, boyutu dönüştürmek için önemli ölçüde enerji harcamamız gerekiyor, bu da üretkenliğimizi büyük ölçüde azaltacak ve geliştirme verimliliğini düşürecektir.
Genişlik ve yükseklik niteleyici uyarlaması
UI geliştirmeyi verimli bir şekilde uygulamak için yeni bir adaptasyon şeması ortaya çıktı Genişlik ve yükseklik niteleyici uyarlaması . Basitçe söylemek gerekirse, piyasadaki tüm Android telefonların genişlik ve yükseklik piksel değerlerinin kapsamlı bir listesidir:
Bir referans çözünürlüğü ayarlayın ve diğer çözünürlükler bu referans çözünürlüğüne göre hesaplanır.Farklı boyuttaki klasörlerde, ilgili boyut dosyalarını boyuta göre yazın.
Örneğin, temel çözünürlük olarak 480x320 alın
Genişlik 320, herhangi bir çözünürlüğün genişliği 320 parçaya bölünmüş, değer x1-x320
Yükseklik 480, herhangi bir çözünürlüğün yüksekliğini 480 parçaya bölün, değer y1-y480'dir
Dolayısıyla, 800 * 480 çözünürlüklü dimens dosyası için,
x1 = (480/320) * 1 = 1,5 piksel
x2 = (480/320) * 2 = 3 piksel
Şu anda, UI tasarım arayüzümüz referans çözünürlüğü kullanıyorsa, tasarım taslağındaki boyuta göre karşılık gelen boyut referansını doldurabiliriz ve uygulama farklı çözünürlükteki cep telefonlarında çalıştığında bu sistemler Bu boyut referanslarına göre, çözünürlük klasörü altında karşılık gelen değeri arayın. Bu, temelde adaptasyon sorunumuzu çözdü ve kullanıcı arayüzü geliştirmemizin verimliliğini büyük ölçüde artırdı.
Bununla birlikte, bu çözümün ölümcül bir kusuru vardır, yani uyum sağlamak için hassas isabetler gerektirir.Örneğin, 1920x1080 cep telefonunun bir 1920x1080 niteleyici bulması gerekir, aksi takdirde birleşik varsayılan boyut dosyası yalnızca kullanılabilir. Varsayılan boyut kullanılırsa, kullanıcı arayüzünün deforme olması muhtemeldir Basitçe söylemek gerekirse, hata tolerans mekanizması çok zayıftır.
Ancak bu program bazı ekipler tarafından kullanıldı ve daha olgun ve etkili bir program olarak değerlendirebiliriz.
UI uyarlama çerçevesi (bakım durduruldu)
Hongyang Big Brother'ın adaptasyon şeması projesi de genişlik ve yükseklik niteleyici şemasından esinlenmiştir.
Kullanım yöntemi de çok basittir:
Adım 1: Projenizin AndroidManifest'inde tasarım taslağınızın boyutunu belirtin.
< meta-veri android: name = "design_width" android: value = "768" > < / meta-data > < meta-data android: name = "design_height" android: value = "1280" > < / meta-data >Adım 2: Etkinliğinizin AutoLayoutActivity'den devralmasına izin verin.
Daha sonra belirli piksel değerini doğrudan düzen dosyasında kullanabiliriz.Örneğin, tasarım taslağı 96 * 96 ise, doğrudan 96px yazabiliriz.APP çalışırken, çerçeve farklı cep telefonlarının belirli boyutlarına göre ölçeklendirmemize ve ölçeklendirmemize yardımcı olacaktır. .
Bunun mükemmel bir çözüm olduğu söylenebilir, çünkü genişlik ve yükseklik niteleyicilerinin adaptasyonu temelinde bir adım daha ileri gidip hata toleranslı mekanizma sorununu çözer.Etkili geliştirme ve doğru adaptasyonun iki gerekliliğinin mükemmel bir şekilde gerçekleştirildiği söylenebilir.
Ancak, çerçevenin çalışma zamanında onMeasure'a dönüşmesi gerektiğinden, özel kontrollerimizin etkilenebileceğini veya kısıtlanabileceğini düşünebiliriz.Bireysel olarak uyarlanması gereken bazı özel kontroller olabilir ve içinde karanlık delikler olabilir. Öngördüğümüzde daha önemli bir sorun daha var, yani adaptasyon çalışmasının tamamı sistem tarafından değil, çerçeve tarafından tamamlanıyor.Bu çerçeve kullanıldığında, ileride çözülmesi zor problemlerle karşılaşılırsa değişim çok zahmetli oluyor. , Ve proje bakımı sona erdiğinde, yalnızca sonraki yükseltmeler için size güvenebilirsiniz.Ekip bu fiyatı karşılayabilir mi? Tabii ki bakımı durdurdu.
Ancak teknik çözümler açısından bunun iyi bir açık kaynak projesi olduğu yadsınamaz.
özet
Yukarıda tartışılan çeşitli uyarlama şemaları, aslında geliştirmede kullanılabilen nispeten olgun şemalardır ve birçok geliştirici aslında bunları kullanıyor. Bununla birlikte, her birinin bazı kusurları olduğundan, yukarıdaki şemayı kullandıktan sonra bu olası kusurları çözmek için fazladan enerji harcamamız gerekir.
Öyleyse, bariz kusurları olmayan nispeten mükemmel bir çözüm var mı?
smallestWidth adaptasyonu
SmallestWidth uyarlaması veya sw niteleyici uyarlaması. Bu, Android'in ekranın mevcut yükseklik ve genişliğinin minimum boyutunun dp değerini (aslında, telefonun genişliği) tanıyacağı ve ardından tanınan sonuca göre kaynak dosyasındaki niteleyiciye karşılık gelen klasördeki kaynak dosyasını arayacağı anlamına gelir.
Bu mekanizma prensip olarak yukarıda bahsedilen genişlik ve yükseklik niteleyici uyarlaması ile aynıdır ve sistem ilgili dosyayı belirli kurallar aracılığıyla seçer.
Örneğin Mi 5'in dpi'si 480, yatay piksel ise 1080px'dir. Px = dp (dpi / 160) değerine göre yatay dp değeri 360dp olan 1080 / (480/160) 'dır ve sistem onu arayacaktır. Value-sw360dp klasörü ve ilgili kaynak dosyası.
SmallestWidth niteleyici uyarlaması ile genişlik-yükseklik niteleyicisi uyarlaması arasındaki en büyük fark, birincisinin iyi bir hata tolerans mekanizmasına sahip olmasıdır. Değer-sw360dp klasörü yoksa, sistem aşağı bakacaktır. Örneğin, 360dp'ye en yakın olan yalnızca değer-sw350dp'dir, o zaman Android, value-sw350dp klasörü altındaki kaynak dosyasını seçecektir. Bu özellik, yukarıda bahsedilen genişlik ve yükseklik niteleyicisinin hata toleransı problemini mükemmel bir şekilde çözer.
Bu şema, yukarıdaki birkaç şema arasında mükemmele en yakın şemadır.
Her şeyden önce, geliştirme verimliliğinden, yukarıdaki çözümlerin hiçbirinden daha düşük değildir. . Sabit ölçekleme oranına göre, temelde ilgili boyut referansını UI tasarımının boyutuna göre düşünmeden doldurabiliriz.
Örnek olarak 375 piksel genişliğinde bir tasarım taslağı alıyoruz .. values-sw360dp klasöründeki diemns dosyası nasıl yazılmalı? Bu klasörün altında, telefonun minimum genişliğinin dp değerinin 360 olduğu anlamına gelir. 360 dp'yi 375 eşit parçaya böleriz.Her tasarım taslağındaki pikseller, telefonda en küçük 360 dp en küçük genişlik değeriyle kabaca 0.96 dp'yi temsil eder. Konu çok basit, eğer tasarım taslağında 10px * 10px ImageView belirirse, o zaman ilgili boyutu düşünmeden layout dosyasına yazabiliriz.
Ve bu tür diemns referansı, farklı değerler-swdp klasörlerindeki değer, sw360dp ve değerler-sw400dp gibi farklıdır,
Sistem, cep telefonunun en küçük Genişlik değerini tanıdığında, hedef veriye en yakın kaynak dosyasının boyutunu otomatik olarak bulacaktır.
İkincisi, istikrar açısından yukarıdaki şemadan da daha iyidir. Yerel dp uyarlaması, Pixel 2 gibi ayrı ayrı uyarlanması gereken bazı özel cep telefonlarıyla karşılaşabilir, ancak en küçük Genişlik uyarlamasında, Pixel 2 cep telefonunun en küçük Genişliğinin değerini 411 olarak hesaplayarak, yalnızca bir değerler-sw411dp oluşturmamız gerekir. (Veya değerleri oluşturmak için yuvarlama-sw410dp sorun değildir) sorunu çözebilir.
SmallestWidth uyarlama mekanizması sistem tarafından garanti edilir. Bu kurallar dizisi için yalnızca karşılık gelen kaynak dosyalarını oluşturmamız gerekir. Çözülmesi zor hiçbir sorun olmayacak ve iş mantığı kodumuzu hiç etkilemeyecek ve kaynak ürettiğimiz sürece Dosya dağıtımı makuldür, karşılık gelen smallestWidth değeri tam olarak karşılık gelen kaynak dosyasını bulmasa bile, en yakın kaynak dosyasını bulmak için geriye dönük olarak uyumlu olabilir.
Elbette, en küçük genişlik adaptasyon şemasında küçük bir sorun var, yani Android 3.2'den sonra tanıtıldı. Google, başlangıçta onu tabletin mizanpaj dosyalarını uyarlamak için kullanmayı amaçladı (ama aslında, diemns adaptasyonu için açıkça daha iyi) , Ancak mevcut tüm projelerin desteklenen minimum sürümü 4.0 olmalıdır (utanç verici ansiklopedi tarafından desteklenen minimum sürüm 4.0'dır), bu nedenle bu konu aslında önemli değil.
Yorumda ayrıca bahsetmeyi unuttuğum bir kusurdan da bahsedildi, yani birden fazla boyut dosyası apk'nin daha büyük olmasına neden olabilir.Bu bir gerçektir.Üretilen dimens dosyasının kapsamına ve boyut aralığına bağlı olarak apk yaklaşık 300kb-800kb artabilir. Mevcut boyut dosya boyutu 406kb, kabul edilebilir olduğunu düşünüyorum.
Toutiao adaptasyon planı (güncelleme)
Yazının linkine daha önce dokunmadım kısaca okudum bunun da görece mükemmel bir çözüm olduğu söylenebilir bu çözüm fikrinden kısaca bahsedeyim, yoğunluk değerini değiştirerek tüm farklı boyutların çözünürlüğünü zorlamaktır. Cep telefonunun genişlik dp değeri, tüm adaptasyon sorunlarını çözen tek tip bir değere değiştirilir.
Örneğin, tasarım taslağının genişliği 360px ise, geliştirme tarafı hedef dp değerini 360dp olarak ayarlayacaktır. Farklı cihazlarda, (telefon piksel genişliği) piksel / yoğunluk değerinin her zaman 360dp olmasını sağlamak için yoğunluk değerini dinamik olarak değiştirin. Öyleyse, kullanıcı arayüzünün farklı cihazlarda tutarlı bir şekilde çalışmasını sağlayabilir.
Bu çözüm çok müdahaleci ve özel API'leri içermiyor. Çok iyi bir çözüm olmalı. Şimdilik yoğunluğu zorla değiştirmenin başka etkileri olup olmayacağını düşünemiyorum. Günümüzün manşetlerini kullanan büyük üreticiler olduğu için istikrar garanti edilmelidir. nın-nin.
Ancak gözlemime göre bu şema eski projeye pek uygun değil çünkü sistemin yoğunluk değerini değiştirdikten sonra tüm paftanın gerçek boyutu değişecek.Eski proje dosyasında kullanmak isterseniz korkarım tüm pafta dosyası Tasarım taslağına göre içindeki boyutların yeniden revize edilmesi gerekebilir. Bu nedenle, eski bir projeyi sürdürüyor veya yeniden modelliyorsanız, bu çözümü kullanmayı iki kez düşünmelisiniz.
Bazı sorular hakkında
S: Bu adaptasyon şeması nasıl kullanılır?
C: Yukarıdaki github projesini girmek için tıklayın, onu yerel olarak indirin ve Java projesini çalıştırın.İlgili dosya yerel kök dizininde oluşturulacaktır. Daha fazla boyut oluşturmanız gerekiyorsa, DimenTypes dosyasına ihtiyacınız olan boyutu girin.
S: Önerilen bir boyut var mı?
A: 300, 320, 360, 411, 450, bu boyutlar daha gerekli, sonra bunlara başka boyutlar ekleyin, emin değilseniz, 10 adımda 300-450 arasında bir düzineden fazla dosya üretebilirsiniz.
S: Tablet uyarlamasında sorun mu yaşıyorsunuz?
C: Bu iki soruya bölünebilir: Birincisi, ekip özellikle tabletler için kullanıcı arayüzü tasarlıyor mu? İkincisi, tabletlere nasıl uyum sağlanmalı? Ekip, tablet için kullanıcı arayüzünü tasarlamazsa, herkesin Uygulamanın tablette çalışması için gereksinimleri genellikle çok çirkin değildir. Bu durum için adaptasyon yöntemi pasif adaptasyondur, yani 480'in üzerinde adaptasyon dosyaları oluşturmayın, böylece tablette sistem 480 boyutlu dimens dosyalarını kullanır ki bu aktif adaptasyondan daha iyidir; ve Ekip, tabletin kullanıcı arayüzünü aktif olarak tasarladı, bu nedenle tabletin 600-800 arası ve anahtar boyutu 640.768 olan adaptasyon dosyasını aktif olarak oluşturmamız gerekiyor. Ardından UI tasarım şemasına göre yazın.
S: Bu çözümü kullandıktan sonra, düzen için wrap_content kullanmam gerekir mi?
C: Bu kesinlikle yanlış! UI tasarımı açıkça kullanım için daha uygunsa
Wrap_content, match_parent, layout_weight vb. Kullanmakta tereddüt etmiyoruz ve yüksek boyutta duruma göre kayan bir yol veya match_parent tasarlamalı ve çok fazla yazmamaya çalışmalıyız. Kısacası, tüm adaptasyon şemaları match_parent ve wrap_content'in yerini almak için değil, onları geliştirmek için kullanılır.
[Ekli] İlgili çerçeve ve bilgiler
Bilgi koleksiyonu
Takip edin + özel mesajı ücretsiz olarak "Android bilgileri" yanıtlayın!
Önceki Android gelişmiş mimari malzemelerine, kaynak koduna, notlarına ve videolarına erişim sağlayın. Gelişmiş UI, performans optimizasyonu, mimarlık kursu, NDK, hibrit geliştirme (ReactNative + Weex) WeChat uygulaması, Flutter çok yönlü Android gelişmiş uygulama teknolojisi
