android知识回顾-----适配不同分辨率的机型

本文介绍了Android开发中实现多屏适配的方法,包括使用dp和sp单位、选择合适的布局方式、提供不同密度的图片资源等,以确保应用在各种屏幕尺寸和密度的设备上都能良好显示。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 1.尽量使用dp设置控件的大小距离,文字使用sp,dp是和分辨率无关的

 2.少用绝对布局,尽量使用相对布局

 3.图片使用多路径 drawable_small drawable_large

 4.不同大小和布局的情况下,布局差异大可以考虑使用  layout_large  layout_small 多种布局





仔细看了一下android开发文档,基本了解android对多屏的开发支持。

    首 先,我们先看看android设备的屏幕状况:下表是google play 市场最新的统计数据,应该具有相当的代表性。

 

Ldpi (120)

Mdpi(160)

Hdpi(240)

Xhdpi(320)

small

1.90%

 

2.50%

QVGA(240*320)

480x640

normal

0.70%

19.60%

64.60%

2.40%

WQVGA400 (240x400)

HVGA(320x480)

WVGA800(480x800)

640x960

WQVGA432 (240x432)

 

WVGA854(480x854)

 
   

600x1024

 

large

0.20%

2.30%

WVGA800** (480x800)

WVGA800* (480x800)

WVGA854** (480x854)

WVGA854* (480x854)

 

600x1024

xlarge

1024x600

5.80%

1536x1152

2048x1536

WXGA (1280x800)

1920x1152

2560x1536

1024x768

1920x1200

2560x1600

1280x768

   

什么是DPI:Dot Per Inch。 1英寸=2.54厘米  这个需要重点了解。

     上表可看出,对于size,实际上是个范围值。大致情况如下:



   我们看看 Android提供的策略:

       1:明确指定支持的屏幕大小,在安装时检查,不符合不允许安装。这比较粗暴,可能对一些对设备大小依赖度比较高的软件才会采用。

       2:不同大小和密度的情况下,提供不同的布局方案。 

      实现方式: Layout-small/

                     Layout-normal/

                      Layout-large/

                    layout-xlarge/

       3:不同密度提供不同的图片。

              默认情况,系统可以帮忙进行伸缩处理,但这样的图片质量是有问题的。如果要得到更好的效果,需要专门制作图片,放置到相应的图片目录下。

              drawable-hdpi

              drawable-ldpi

              drawable-mdpi

              drawable-xhdpi

              对于多语言,可以添加语种,用 – 分隔

              可组合。比如:drawable-en-rUS-xhdpi

       4:系统的匹配优先级

       4.1:查找最精确的配置

       4.2:使用默认资源,然后进行拉伸处理

       5:可用的配置项

Screen characteristic

Qualifier

Description

Size

small

Resources for small size screens.

normal

Resources for normal size screens. (This is the baseline size.)

large

Resources for large size screens.

xlarge

Resources for extra large size screens.

Density

ldpi

Resources for low-density (ldpi) screens (~120dpi).

mdpi

Resources for medium-density (mdpi) screens (~160dpi). (This is the baseline density.)

hdpi

Resources for high-density (hdpi) screens (~240dpi).

xhdpi

Resources for extra high-density (xhdpi) screens (~320dpi).

nodpi

Resources for all densities. These are density-independent resources. The system does not scale resources tagged with this qualifier, regardless of the current screen's density.

tvdpi

Resources for screens somewhere between mdpi and hdpi; approximately 213dpi. This is not considered a "primary" density group. It is mostly intended for televisions and most apps shouldn't need it—providing mdpi and hdpi resources is sufficient for most apps and the system will scale them as appropriate. If you find it necessary to provide tvdpi resources, you should size them at a factor of 1.33*mdpi. For example, a 100px x 100px image for mdpi screens should be 133px x 133px for tvdpi.

Orientation

land

Resources for screens in the landscape orientation (wide aspect ratio).

port

Resources for screens in the portrait orientation (tall aspect ratio).

Aspect ratio

long

Resources for screens that have a significantly taller or wider aspect ratio (when in portrait or landscape orientation, respectively) than the baseline screen configuration.

notlong

Resources for use screens that have an aspect ratio that is similar to the baseline screen configuration.

 实际上:语种也可以做为属性项,这可以做为图片多语言的方式。

举例:

res/layout/my_layout.xml     // layout fornormal screen size ("default")
res/layout-small/my_layout.xml       // layout for small screensize
res/layout-large/my_layout.xml       // layout for large screensize
res/layout-xlarge/my_layout.xml   // layout for extra large screensize
res/layout-xlarge-land/my_layout.xml // layout for extra large in landscapeorientation

res/drawable-mdpi/my_icon.png        // bitmap for mediumdensity
res/drawable-hdpi/my_icon.png        // bitmap for highdensity
res/drawable-xhdpi/my_icon.png       // bitmap for extra highdensity

其它:

:适当使用 Nine-Patchbitmap files,可以减少不同密度图片的工作量。

:res/drawable-nodpi/icon.png nodpi指的是不进行缩放。这个可能在某些特殊场景会用到。
:aspect 是否宽屏


根据上面的原理,可以确定简单的策略:

       1:使用 dp 来定义大小。

              使得布局与密度无关,使用Warp_content,fill_parent。

              硬编码中也不要使用pix。

              不要使用AbsoluteLayout。        

              同样:文字大小使用 sp。

        为什么要用dp,道理很简单,如果有两个用户使用 相同size的手机,他们希望不管是不是密度不同,但都可以正常使用

同一个软件,要达到此目的,显然不能使用px,因为他会导致效果不同,如果使用dp,因为它是按设备的dpi进行了运算,刚

好将dpi的不同体现到了点阵上,因而达到相同效果的目的。


        2:在如下场景,提供变化的布局:(只针对size,因为使用了dp)

        2.1:在小屏上,发现按纽找不到了,或者不正确的换行了,导致无法正常操作或界面太丑。

        2.2:在大屏上,发现空间的利用率太低,不利于用户的操作和使用。

        注意:用户使用了更为昂贵的设备,当然希望得到更佳的体验,这个同样的重要。尽管在大屏上应用可以正常使用,但这是不够的。

        2.3:当从横屏切纵屏时,发现按纽的位置不合理,应该将底端按纽放到右侧。这种情况下,也需要提供两种不同的布局。

         一般情况下,我们不需要使用不同的layout,这个意味着要重新设计,工作量较大。

        3:对于图片,在不同密度下提供不同的图片。

             drawable中的XML files 定义文件,必须放到drawable/ 下。

              分辨率的比例是:              3:4:6:8

              drawable-nodpi 暂不考虑

              Nine-Patchbitmap files,这是通过锚定的方式,确定某些区域不缩放,如果要节省空间,可以部分情况采纳。

      

             4:调试时,使用AVD虚拟设备如下:


        除了设置正确的 dpi和分辨率外,还可设置Screen Size,得到更真实的效果。

高校点餐系统需求分析文档 一、引言 1.1 项目背景 为提升高校食堂服务效率,优化学生就餐体验,设计一套支持多角色协作、覆盖线上线下全流程的智能化点餐管理系统,实现食堂数字化转型。 1.2 目标用户 - 在校学生(核心用户群) - 食堂管理人员(含菜品管理员、订单管理员等) - 系统维护人员 - 未注册游客(受限访问) 二、系统总体架构 2.1 角色权限体系 | 角色类型 | 权限层级 | 主要功能范围 | |---------- |----------|------------------------------| | 超级管理员 | Level 4 | 系统配置、权限分配、数据审计 | | 内容管理员 | Level 3 | 资讯发布、公告管理、反馈处理 | | 运营管理员 | Level 2 | 菜品管理、订单处理、数据统计 | | 普通用户 | Level 1 | 完整消费功能 | | 游客 | Level 0 | 只读浏览功能 | 三、详细功能需求 3.1 管理员子系统 3.1.1 智能看板 实时数据监测: 当前在线用户数 待处理订单量 实时销售额统计 可视化分析: 热力图展示各时段订单密度 菜品销量TOP10排行榜 用户偏好分析雷达图 3.1.2 内容管理 轮播图管理: 支持上传1080P高清图片 设置展示优先级(1-5级) 定时上下线功能 资讯发布: 富文本编辑器(支持Markdown) 多图文混排模板 定时发布/撤回功能 3.1.3 运营管理 菜品生命周期管理: 基础信息(营养成分、过敏原标注) 动态库存预警(设置库存阈值) 季节性菜品上下架 订单处理: 异常订单标记系统 批量导出CSV功能 智能退单处理流程 3.2 用户子系统 3.2.1 智能点餐 个性化推荐: 基于历史订单的协同过滤推荐 实时热门菜品推送 健康饮食建议(卡路里计算) 多维度搜索: 语音搜索支持 拍照识菜功能 智能纠错建议 3.2.2 订单管理 支付集成: 校园一卡通对接 主流第三方支付(微信/支付宝) 余额充值系统 订单追踪: 制作进度可视化 取餐倒计时提醒 电子取餐码生成 3.2.3 社交化功能 UGC内容管理: 带图评价系统(自动审核机制) 点赞排行榜 优质点评打赏功能 社交分享: 生成带菜品海报 跨平台分享接口 好友推荐奖励机制 3.3 游客模式 受限功能: 菜品浏览(隐藏价格信息) 模拟点餐体验(需登录后完成支付) 只读查看部分评价内容 转化机制: 每日三次体验机会 新用户优惠弹窗 手机快速注册通道 四、非功能性需求 4.2 安全要求 金融级加密:支付环节采用国密SM4算法 隐私保护:敏感数据脱敏处理(如手机号中间四位*代替) 操作审计:关键操作留痕(保留180天日志) 4.3 兼容性要求 移动端:适配iOS/Android主流机型 浏览器:支持Chrome 80+、Safari 14+ 分辨率:完美适配720p-4K显示 五、创新实现方案 5.1 智能预警系统 库存预测模型:基于LSTM神经网络进行销量预测 动态定价策略:根据供需关系调整特价菜品 排队时长预估:结合后厨产能实时计算 5.2 沉浸式体验 AR菜单展示:通过手机摄像头查看3D菜品模型 虚拟营养师:扫描菜品获取健康建议 智能语音助手:全流程语音交互支持 5.3 环保设计 数字小票系统:减少纸张消耗 低碳饮食统计:计算每单碳足迹 光盘奖励计划:拍照认证获取积分 六、部署方案 6.1 技术栈选型 | 层级 | 技术方案 | |------|-----------------------------------------| | 前端 | Vue3 + TypeScript + Vite | | 后端 | Spring Cloud Alibaba微服务架构 | | 数据库 | MySQL集群 + Redis缓存 + ElasticSearch | | 运维 | Kubernetes + Prometheus监控 | 6.2 硬件配置 服务器集群:3台4C8G云主机(负载均衡) 基于这些文字,生成一份
最新发布
04-01
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值