android系統比例
① 中國android和ios系統應用人群比例
市場調查機構Kantar今天(2015.06.03)發布最新智能手機份額報告顯示,Windows Phone用戶在中國確實只佔據了1%的份額。
具體來說,在中國份額最高的是Android,達到了74%,iOS位居次席,占據了24.4%的份額,而Windows Phone則排行第三,佔了1%。
相對來說,Windows Phone在歐洲的表現還算不錯,義大利的份額甚至達到了13.3%。而在美國,其比例為3.8%。
另外,其實WP在中國的份額不算很低了,要知道在日本市場,其份額僅為0.2%,顯得有些微不足道。
② android 系統中如何原比例的顯示圖片
這裡面的參數你都試一下,應該有一個可以。x0dx0aImageView的ScaleType屬性x0dx0aImageView的屬性android:scaleType,即 ImageView.setScaleType(ImageView.ScaleType)屬性如下:CENTER /center 按圖片的原來size居中顯示,當圖片長/寬超過View的長/寬,則截 取圖片的居中部分顯示x0dx0aCENTER_CROP / centerCrop 按比例擴大圖片的size居中顯示,使得圖片長 (寬)等於或大於View的長(寬)x0dx0aCENTER_INSIDE / centerInside 將圖片的內容完整居中顯示,通過按比例縮小 或原來的size使得圖片長/寬等於或小於View的長/寬x0dx0aFIT_CENTER / fitCenter 把圖片按比例擴大/縮小到View的寬度,居中顯示x0dx0aFIT_END / fitEnd 把 圖片按比例擴大/縮小到View的寬度,顯示在View的下部分位置x0dx0aFIT_START / fitStart 把 圖片按比例擴大/縮小到View的寬度,顯示在View的上部分位置x0dx0aFIT_XY / fitXY 把圖片 不按比例 擴大/縮小到View的大小顯示
③ 中國安卓和ios用戶比例
您是想問中國安卓和ios用戶比例是多少嗎?中國安卓和ios用戶比例是安卓用戶佔75%,ios用戶佔25%。手機行業數據分析報告顯示,中國手機瀏覽器用戶在2022年8月份達到了1.7億,在所有用戶中,安卓用戶佔75%,ios用戶佔25%。
④ 安卓有沒有比例16:9平板2022
有。根據查詢安卓消息顯示,有比例16:9平板。安卓系統英文簡稱為Android,是全球手機用戶使用最多的操作系統,由美國知名的谷歌公司開發,其系統都要應用在智能手機、平板電腦等領域。
⑤ Android顯示解析度和比例不正常時解決方法
系統說明:
usage: wm [subcommand] [options]
wm size [reset|WxH|WdpxHdp]
wm density [reset|DENSITY]
wm overscan [reset|LEFT,TOP,RIGHT,BOTTOM]
wm scaling [off|auto]
wm screen-capture [userId] [true|false]
wm size: return or override display size.
width and height in pixels unless suffixed with 'dp'.
wm density: override display density.
wm overscan: set overscan area for display.
wm scaling: set display scaling mode.
wm screen-capture: enable/disable screen capture.
wm dismiss-keyguard: dismiss the keyguard, prompting the user for auth if necessary.
[]中是可選項。直接輸入wm size命令會輸出當前顯示器設置的顯示解析度。
[]帶參數則會將原有解析度覆蓋,如果顯示器解析度顯示不正確,可以使用這個方法。
該命令的用法類似於wm size命令,作用是讀取、設置或者重置LCD的density值。density值即LCD的ppi.
該命令用來設置、重置LCD的顯示區域。四個參數分別是顯示邊緣距離LCD左、上、右、下的像素數。
但是這些設置都是臨時的,適合於調試來確定問題和解決辦法。永久性的修改可以參照以下兩個辦法(均在高通平台下):
2> adb root //提示read only filysystem時執行此命令獲取root許可權,
adb remount
adb pull /system/build.prop D:\
在build.prop末尾添加一行ro.sf.lcd_density=240
adb push D:\build.prop /system/
adb shell
cd /system/
chmod 644 build.prop沒有修改許可權將導致手機起不來
(項目路徑)/device/rockchip/rk3399/system.prop
註:這個路徑是rk3399開發板Android7.1.1路徑,不知道自己路徑在哪的直接搜索這個文件即可
ro.sf.lcd_density=240改這個值,然後重新編譯system.img
⑥ 全面屏之前安卓的比例
全面屏之前安卓的比例是16:9,全面屏後安卓的縱橫比例是19:9
⑦ 安卓爆改平板比例
首先需要的是安卓手機沒有辦法直接改平板比例,只能通過下載軟體,首先打開手機瀏覽器。
屏幕比例有16:9,16:10,還有4:3。其中4:3的比例看起來平板比較方正,方方正正的,16:9就比較修長像手機的比例,應用都可以,這個哪個比例好看,要看你的個人愛好了。
超強的操作系統:
谷歌安卓Andriod 2.2官方系統,支持升級到Android 3.0系統,近十萬的免費應用程序支持,最重要的是支持多任務並行處理運行快:由於系統結構的優化,使得Google ipad有著更快的運行和載入速度。
更多桌面Widget,個性桌面功能隨時支配;新的瀏覽器版本,加強了穩定性和網頁渲染能力;全局搜索功能加強;同時具備高清播放和智能系統。10月份發布的聯想S5000平板電腦採用Android4.2的操作系統,這也意味著安卓系統已升級到了Android4.2版本。
⑧ 中國的手機市場上Android手機所佔比例是多少呢
數據顯示,2014年上半年,中國智能手機市場上android手機所佔比例達到89.9%,銷量達到18556.3萬部。
全球智能手機市場整體增長趨於平穩。在各操作系統銷量方面,Android手機佔89.9%,已然形成在中國智能手機市場上的主導地位。
⑨ Android 屏幕解析度適配
Android屏幕解析度千奇百怪,怎麼讓app在不同的解析度的設備上「看起來一樣」呢?
你也許還有以下疑惑:
這篇文章將會針對以上問題一一解答。
Pixels 我們看到屏幕上的圖像由一個個像素組成,像素里包含色彩信息。
如常說的手機解析度:1080 x 1920 指的是手機寬度可展示1080像素,高度可展示1920像素。
Pixels Per Inch 每英寸長度所具有的像素個數,單位面積內像素越多,圖像顯示越清晰。
ppi一般用在顯示器、手機、平板等描述屏幕精細度。
Dots Per Inch 每英寸長度所具有的點數。
dpi一般用來描述列印(書本、雜志、電報)的精細度
density-independent pixels (device-independent pixels 我查了一下,官網更多時候使用前者,有的時候也顯示後者),dip是縮寫,也可以更簡單些稱作dp。該單位的目的是屏蔽不同設備密度差異,後面細說。
Scalable pixels 用於設置字體,在用戶更改字體大小時候會適配。
澄清了基本概念,我們現在從一個例子開始說明以上單位之間的區別與聯系。
布局文件里有個View,長寬都是200px,分別在解析度為480(寬)x800(高)簡稱A設備、1080(寬)x1920(高)簡稱B設備,效果如下:
左邊是A設備,右邊是B設備。問題出來了,同樣長寬都是200px,為啥A設備顯示很大,B設備顯示很小呢?你可能會說B設備的橫向解析度1080比A設備的480大,所以在B設備上看起來比較小。來看看A、B設備橫向到底是多少英寸,怎麼來計算呢?這時候就需要用到ppi了,既然知道橫向的像素點個數,也知道每英寸能容納的像素點,當然可以得知橫向的尺寸了。
其中一種方式獲取DisplayMetrics對象:
A設備寬度尺寸:480(px)/240(ppi)=2inch
B設備寬度尺寸:1080(px)/420(ppi)=2.5inch
可以看出,A、B設備尺寸差別不大。A設備ppi=240 B設備ppi=420,明顯地看出B設備單位長度上比A設備能夠容納更多的像素,因此同樣的200px,B設備只需要較小的尺寸就能夠顯示,因此在B設備上的view看起來比A設備小很多。
知道了問題的原因,然而顯示的效果卻不能接受。
我們總不能自己判斷每個設備的ppi,然後計算實際需要多少像素,再動態設置view的大小吧,那layout里的靜態布局大小就無法動態更改適應了。想當然的能有一個統一的地方替我們轉換,沒錯!Android系統已經幫我們實現了轉換。接下來就是dpi、dp出場了。
Android系統使用dpi來描述屏幕的密度,使用dp來描述密度與像素的關系。
A設備dpi=240
B設備dpi=420
Android系統最終識別的單位是px,怎麼將dpi和px關聯起來呢?,答案是dp。
Android規定當dpi=160時,1dp=1px,當dpi=240時,1dp=1.5px,依此類推,並且給各個范圍的dpi取了簡易的名字加以直觀的識別,如120<dpi<=160,稱作為mdpi,120<dpi<=240 稱作hdpi,最終形成如下規則:
現在知道了dp能夠在不同dpi設備上對應不同px,相當於中間轉換層,我們只需要將view長寬單位設置為合適的dp,就無需關注設備之間密度差異,系統會幫我們完成dp-px轉換。將我們之前的例子稍微更改,再看看效果驗證一下:
通過上面對dp的了解,我們知道在設定view大小、間距時使用dp能最大限度地屏蔽設備密度之間的差異。可能你就會問了,那bitmap展示的時候如何適配不同密度的設備呢?
自定義view從磁碟上載入一張圖片,並將之顯示在view上,view的大小決定於bitmap大小。依舊以上述A、B設備為例,展示結果如下:
左邊是A設備,右邊是B設備。
明顯地看出,在A設備顯示比B設備大很多,實際上和我們之前用px來描述view的大小原理是一樣的,bitmap的寬、高都是px在描述,而bitmap決定了view的寬、高,最終導致A設備和B設備上的view大小(寬、高像素)是一樣的,而它們屏幕密度又不相同,因此產生了差異。
那不會每次都需要我們自己根據屏幕密度來轉換bitmap大小吧?幸運的是,Android已經為我們考慮到了。
生成不同密度的目錄有什麼作用?
A設備dpi=240,根據dpi范圍,屬於hdpi
B設備dpi=420,根據dpi范圍,屬於xxhdpi
圖片原始尺寸:photo1.jpg(寬高 172px-172px)
當我們想要在不同密度設備上顯示同一張圖片並且想要「看起來一樣大時」。假設設計的時候以hdpi為准,放置photo1.jpg為172*172,那麼根據計算規則在xxhdpi上需要設置photo1.jpg為:
現在hdpi和xxhdpi目錄下分別存放了同名圖片:photo1.jpg,只是大小不同。當程序運行的時候:
來看看效果:
左邊A設備,右邊B設備
針對不同的密度設計不同的圖片大小,最大限度保證了同一圖片在不同密度設備上表現「看起來差不多大」。
來看看A、B設備上圖片占內存大小:
說明在B設備上顯示photo1.jpg需要更多的內存。
上邊只是列舉了hdpi、xxhdipi,同理對於mdpi、xhdpi、xxxhdpi根據規則放入相應大小的圖片,程序會根據不同的設備密度從對應的mipmap文件夾下載入資源。如此一來,我們無需關注bitmap在不同密度設備上顯示問題了。
在mipmap各個文件夾下都放置同一套資源的不同尺寸文件似乎有點太佔apk大小,能否只放某個密度下圖片,其餘的靠系統自己適配呢?
現在只保留hdpi下的photo1.jpg圖片,看看在A、B設備上運行情況如何:
看起來和上張圖差不多,說明系統會幫我們適配B設備上的圖片。
再來看看A、B設備上圖片占內存大小:
先看A設備:
對比photo1.jpg 分別放在hdpi、xxhdpi和只放在hdpi下可以看出:B設備上圖片所佔內存變小了。為什麼呢?接下來從源碼里尋找答案。
A、B設備同樣載入hdpi/photo1.jpg,返回的bitmap大小不相同,我們從這方法開始一探究竟。
上面涉及到的關鍵點是density,分別是TypedValue的density和Options的density。
先來看看TypedValue density:
再來看看Options density
現在分析B設備載入hdpi/photo1.jpg如何做的:
和我們之前調試的結果一致。
B設備是怎麼決定使用hdpi下的圖片資源呢?
根據實驗(嘗試找了源碼,沒怎麼看懂,因此只是做了實驗,可能在不同密度設備上找尋規則不一樣):B設備先找屬於自己密度范圍文件夾下的圖片,B設備屬於xxhdpi,先查看xxhdpi有沒有photo1.jpg,如果沒有則往更高的密度找,比它高的密度是xxxhdpi,還是沒有,則往低密度找,找xhdpi,沒有再找hdpi,找到了則返回構造好的TypedValue,剩下的就是我們前面分析的。
既然我們只想放某個密度下的一份切圖,該放哪個密度下呢?從系統尋找規則看,更推薦放置在更高密度下的,因為如果放在低密度下,那麼當運行在高密度設備上時,圖片會進行放大,可能導致不清晰。我一般習慣放在xxhdpi下。
Android Studio默認創建了不同密度的mipmap文件夾,默認放置了ic_launcher.png。我們普通的切圖該放drawable還是mipmap下呢?對於這個問題網上也是眾說紛紜,實際上對於我們來說,關注的重點是圖片放在drawable或者mipmap,載入出來bitmap是否有差異,如果沒有差異放在哪就看習慣了。通過實踐,普通的切圖放drawable和mipmap下載入出來的bitmap是沒有差異的,只不過用drawable的話需要自己創建不同密度的文件夾。我習慣於放在drawable下(啟動圖標logo還是放在mipmap下)。
前邊 [注1] 留了個問題,我們使用dp來表示view的大小了,為啥兩個看起來還是有些差距?下面我們更加直觀地看一個例子。
A設備dpi=240 密度1.5 解析度(寬高px):480 * 800
B設備dpi=420 密度2.625 解析度(寬高px):1080 * 1794
換算成dp
A設備解析度:320dp * 533dp
B設備解析度:411dp * 683dp
依舊是上邊的例子:
將view寬高分別設置為320dp,看看效果:
左邊A設備,右邊B設備
可以看出同樣的320dp大小,A設備鋪滿了屏幕,而B設備沒有。這效果顯然是不能接受的,Android考慮到不同設備寬高不同,推出了"寬高限定符"。以A、B設備為例:
在res文件夾下創建文件夾:
假設設計師出圖是按照800x480,那麼我們創建dimen文件的時候
該文件放在values-800x480文件夾下。
根據解析度比例算出1794x1080的dimen值
這樣子,A、B設備載入資源的時候使用對應解析度限定符下的px,如果找不到再找默認值,可以在一定程度上解決屏幕寬高碎片化適配問題。
但是這樣子的限定比較嚴格,需要測試各種解析度,後來Android又推出了"smallest-width"簡稱最小寬度限制。
A設備寬320dp
B設備寬411dp
假設設計師切圖標准屏幕寬是320dp(A設備),那麼可以定義如下dimen.xml文件
該文件放在values-sw320dp文件夾下
根據規則,計算B設備dimen.xml
現在我們繼續來看之前的view
通過對dimen引用,A設備尋找和自己寬度一樣的dimen文件,找到values-sw320dp,dp320=320dp。B設備尋找和自己寬度一樣的dimen文件,找到values-sw411dp,dp320=410dp。這樣子同樣的dp320,得出不同的值,就適配了屏幕寬度不同的問題。
看看效果:
這次B設備也鋪滿了屏寬。
綜上,為了適配不同屏幕大小,推薦使用dp+smallest-width。
獲取設備dpi最終都是從這方法獲取的,實際上就是讀取系統的配置文件。因此我們也可以通過adb shell 獲取:
可以看出dpi是系統配置好的,當然有些手機是可以設置解析度的,設置之後我們查看解析度:
解析度變低了,dpi也變小了。