app页面布局优化建议

大家好！今天让创意岭的小编来大家介绍下关于app页面布局优化建议的问题，以下是小编对此问题的归纳整理，让我们一起来看看吧。

开始之前先推荐一个非常厉害的Ai人工智能工具，一键生成原创文章、方案、文案、工作计划、工作报告、论文、代码、作文、做题和对话答疑等等

只需要输入关键词，就能返回你想要的内容，越精准，写出的就越详细，有微信小程序端、在线网页版、PC客户端

官网：https://ai.de1919.com。

创意岭作为行业内优秀的企业，服务客户遍布全球各地，如需了解SEO相关业务请拨打电话175-8598-2043，或添加微信：1454722008

本文目录:

• 1、页面布局方案

• 2、9种常见的移动端产品信息布局方式

• 3、App中列表、卡片和双栏卡片的布局思考

• 4、Android性能优化总结

一、页面布局方案

例如：对于DPR=2的Retina屏幕而言1个位图像素对应于4个物理像素，由于单一位图像素不可再分割，所以只能就近取色，从而导致图片模糊。所以对于图片清晰度问题，较好的方案是提供两倍图 @x2 。

像素密度表示设备屏幕能够显示的设备独立像素DIP的数量，屏幕显示的像素数量越多画面也就越精细，同时同样屏幕区域能够显示的信息也就越多。

屏幕由像素点组成，每个像素点发出不同颜色的光，进而构成界面。而屏幕的物理尺寸与像素尺寸是不成比例的。不同尺寸的手机屏幕拥有不同的分辨率，分辨率实际上是手机像素的宽高尺寸。

像素密度（pixels per inch,PPI或DPI）表示每英寸长度上排列的设备独立像素点DIP的个数，1英寸等于2.53厘米。像素密度PPI越高则表示屏幕分辨率越高进而屏幕显示越精细。Retine屏幕比普通屏幕清晰的原因，是因为它的像素密度是普通屏幕的数倍。

例如：3.5英寸的iPhone手机屏幕

日常所说的屏幕尺寸，实际是指屏幕对角线的长度。计算像素密度首先需要计算设备屏幕对角线等效像素，然后除以对角线长度。例如HTC G7分辨率为480x800，3.7英寸，计算出像素密度为252PPI。

像素密度PPI = 平方像素宽加平方像素高之和开平方的结果，再除以屏幕对角线的英寸数。

密度决定比例

通过计算像素密度PPI可以得知设备屏幕属于哪个密度区间，因为不同密度区间对应着不同的默认缩放比例。

通俗来说视区 Viewport 就是浏览器上用来显示页面的区域，也就是说，浏览器的实际宽度和手机宽度不一样，无论手机宽度是320px或640px，在手机浏览器内部宽度始终会是浏览器本身的视区。

现代浏览器都会给自身的视区提供一个默认值，大多会以980px或1024px为主。在移动端视区默认一般来说是会大于手机屏幕的，所以当在桌面浏览器正常显示的页面，会以960px设计主区域。放到移动端就会出现横向滚动条，因此会专门会给浏览器设计移动端的页面。

移动端浏览器会将页面放在一个虚拟的窗口 viewport 中，通常这个虚拟的窗口会比屏幕宽，这样就不用将每个页面挤到很小的窗口中，以防止破坏没有针对手机浏览器优化的网页布局，用户可以通过平移或缩放来查看页面中的不同部分。

页面中视区 viewport 是可绘制的区域，虽然视区的可视面积和屏幕尺寸相匹配，但视区页由自己的尺寸，用来确定页面中的像素数量。

在 iPhone 和 Android 平台中 WebKit 内核的历览器使用980像素宽的视见区或逻辑尺寸，相当于viewport中的width=980px。当页面加载后，页面内容通常被完全缩放以便整个页面都可见，尽管内容会被缩放的非常小且不可读。

在Web页面中，可通过JS动态获取相关参数。

根据目前市场主流移动终端，统计设备独立像素后，移动端H5设计稿推荐尺寸为640 x 1136、750 x 1334。

除去浏览器全屏显示，几乎所有情况下均会存在顶部状态栏和导航栏。根据iPhone标准，状态栏和导航栏的独立像素高度分别为40px和88px。Android平台可以更改状态和导航栏高度可取默认值48px和100px为准。在网页中就会将页面内容向下挤入盲区，根据不同的布局方式可能会挤出视口，也就是可视区域之下。因此取两个平台的最大值148。因此设计稿要尽量保证单页下没有重要内容。如果要在所有屏幕上将重要内容显示完全，需要注意市面上存在的小尺寸屏幕，绝对部分智能机分辨率在640 x 960之上，因此只要重要内容放在盲区之上即可。计算出的最安全高度为812 = 960 - 148。

简单来说视区 Viewport 是严格等于浏览器的窗口，在桌面浏览器中视区就是浏览器窗口的宽高，但在移动设备上由于视区太窄，为了更好的为 CSS 布局服务，所以提供了两个视区，分别是可见视区 Visual Viewport 和布局视区 Layout Viewport 。

如果将移动设备浏览器的可视区域设置为Viewport，某些网站会因为Viewport太窄而显示错乱，所以浏览器会默认将Viewport设置为一个较宽的值，比如980px，使得为桌面浏览器设计的网站也能在移动设备浏览器上正常显示。这个浏览器默认的Viewport也就是Layout Viewport布局视区。布局视区的宽度可以使用JavaScript的 document.documentElement.clientWidth 获取。移动设备中默认的视区就是Layout Viewport。

布局视区的宽度是大于浏览器可视区域的宽度的，因此需要一个Viewport来表示浏览器可视区域大小，这个Viewport也就是可见视区Visual Viewport，可见视区可使用JavaScript的 document.documentElement.innerWidth 获取。

Ideal Viewport是一个能完美适配移动设备的Viewport，首先无需缩放和横向滚动条就能正常查看页面所有内容，其次显示的文字、图片大小合适。比如14px的文本不会因为一个高密度像素的屏幕而显示的太小或无法看清。无论在何种密度屏幕、何种分辨率下，显示出来的大小都差不多，这个Viewport也就是Ideal Viewport。

Ideal Viewport并没有一个固定的尺寸，不同的设备拥有不同的尺寸。比如在IPhone设备中Ideal Viewport宽度是320px，无论屏幕宽度是320还是640的。Ideal Viewport的意义在于，无论在何种分辨率下，针对Ideal Viewport而设计的页面无需缩放和横向滚动条都可以完美地呈现给用户。

移动设备中默认的视区是Layout Viewport，在进行移动设备页面开发时则需要Ideal Viewport。要得到完美视区，需设置 meta 标签。

该 meta 标签的作用是让当前视区宽度等于设备宽度，同时不允许用户手动缩放。 minimum-scale=1.0 与 maximum-scale=1.0 并不是必需的。但 width = device-width 则是必须的，以保证不会出现横向滚动条。

width 能够控制默认布局视区Layout Viewport的宽度，若不指定则默认会是980px或1024px，这个值会由设备自身所决定。当把布局视区宽度设置为移动设备宽度 width = device-width 时，此时布局视区将会变成完美视区。

其实要将当前视区宽度设置为完美视区宽度，既可以设置 width = device-width 也可以设置 initial-scale = 1.0 ，但是单单设置 width = device-width 会导致iPhone、iPad设备中横竖屏不分，单单设置 initial-scale = 1.0 则会导致IE中横竖屏不分。所以都以竖屏的完美视口宽度为标准，最完美的写法时两则都写上去， width = device-width 解决iPhone、iPad缺陷， initial-scale = 1.0 则解决IE的缺陷。

CSS3新增视区单位vm和vh，在移动端iOS8+和Android4.4+获得支持。

设备像素比定义了物理像素与设备独立像素之间的对应关系，计算公式为：设备像素比 = 物理像素 / 设备独立像素。

在CSS中可通过以下方式进行媒体查询，针对不同DPR设备做出样式适配。

在JavaScript中可通过 window.devicePixelRatio 获取当前设备的DPR。

在Ratina高清设备屏幕中一个CSS像素对应4个物理像素

Web页面设置视口后，页面与屏幕是1:1显示，移动设备都具有设备像素比 DPR ，当DPR=2时移动设备上的一个CSS像素由4个物理像素点组成。

安卓客户端限制了 viewport 设置的缩放属性，让客户端放开限制就行，但是由于市场上的app版本还是不支持，所以需要做兼容性处理。

iPhone6 上有1px 的滚动条，最后处理方案是通过 viewport 中的 maximum-scale 的值加了0.1，由于设置了user-scalable=no，maximum-scale 的值加0.1并不会有什么影响。

通过JS动态获取移动设备的设备像素比，通过设备像素比来计算并设备Web页面中 html 标签的字体大小 font-size 以及缩放比例。

例如：动态设置 html 的font-size, 同时根据设备DPR调整页面的缩放值，进而达到高清效果。

rem 全称 font size of the root element 是指相对于根元素的字体大小的相对单位，计算规则依赖于根元素。

rem 是通过根元素进行适配的，web中根元素是指 html ，所以通过设置 html 的字体大小即可控制 rem 的大小。

REM布局的核心是设置好根 html 元素的字体大小 font-size ，为了防止在高清屏下像素不够用而导致模糊，当拿到移动设计稿时，移动设计稿一般会以iPhone5设备宽320px或iPhone6设备宽375px为基准，制作出两倍宽的设计稿，即640px或750px。

例如：设置 html 标签的 font-size:10px ，6rem即6*10px。

rem 适用于WebApp，出于兼容性考虑，WebApp下使用 rem 更加能凸价值和功能。

使用CSS的媒体查询控制

移动UI设计稿会采用iPhone宽度作为标准

使用JS控制Web页面文字大小使其自适应屏幕

使用 rem 布局的本质是等比缩放，一般是基于宽度。

将屏幕宽度均分100份，每一份的宽度使用x表示，即x=屏幕宽度/100，如果将x作为单位，x前面的数值代表屏幕宽度的百分比。想要屏幕元素随着屏幕宽度等比缩放，只需要确定x单位，可通过CSS3中的 rem 来实现。可通过JS设置HTML字体大小等于屏幕宽度的百分之一。

若UE设计稿宽度尺寸为640px，设计稿中某元素宽度为100px，则可以计算出100 / 640px * 100px = 15.625。

最佳实践：px2rem移动端自适应方案 https://github.com/imochen/hotcss

字体大小不能使用 rem ，因为字体大小和字体宽度并不是线性关系，所以字体大小不能使用 rem 。由于设置根元素字体大小会影响所有没有设置字体大小的元素，因为字体大小是会继承的，可以在 body 上做字体修正。

如何实现字体的响应式，可通过修改 body 字体大小，同时设置字体大小使用 em 单位。

二、9种常见的移动端产品信息布局方式

某天，经理在工作讨论组发了2张App的界面截图，问：“你们喜欢哪一种布局方式？”这两个界面，一个是九宫格式，一个是普通列表式。

一时间，大家没法快速下定论。视觉设计师发言，“得看具体场景和需求来判定。”

有程序员同事打趣说，“哈哈，说了跟没说一样。”接着，陆续有人发表了自己看法，除了说到这2种方式各自的优劣，总结起来还是那句话——得看设计的目标是什么，综合多方面来考虑，没有绝对的好与坏，只有相对的合适与否。

在看过已有的关于App界面信息布局方式的一些资料后，我自己调整了一下，重新总结一下。从视觉和交互表现来说，常见的移动端产品界面信息布局方式，大致有以下 9 种。

一、列表式

列表式为竖向排列，每个信息单元有相同的结构。

优点：

符合人们从上往下阅读的习惯，顺畅快捷，浏览体验比较好。

因为有统一的信息单元格式，页面整体比较整洁、清晰。

每个信息单元根据需要可放置标题、摘要、图片、标签等元素，供用户预览并预测详细内容。

缺点：

当信息加载多了以后，容易让人出现审美疲劳，降低阅览兴趣。

信息排序越往后，受到的关注度自然会下降。一般采用颜色不同、字号大小、区块划分等来区分重要级别，增强层次感。

类似于列表式，有些演化出像卡片的排版，或者一个区块划分为左右2半（如下例子所示），成为2个入口，都是根据界面面积利用和设计目标等方面来考虑的。

二、横向排列式

与竖向排列相对应，信息单元也可以是横向排列。在交互操作上，这种方式需要左右滑动来切换信息单元，又称“旋转木马式”。

举例：下图中[新书抢鲜]模块的布局方式

优点：

缩小在高度上占据的空间，利于界面其他信息的展示。

当信息单元占据的幅度较大时（例如图片类应用），有利于用户目光聚焦。

缺点：

左右滑动的交互有时候不方便。

当信息单元面积较大时，无法跳跃性定位到想看的信息单元，只能一个一个左右切换，直到切换到想看的那个为止。

因为操作不方便，可能有些内容会被遗漏，或者用户没兴致去翻看。

三、九宫格式

严格意义上的九宫格是3行3列，如果列数或行数增加，我们暂且都泛称为九宫格式（也有人将它们区分开来，称之为“陈列馆式”或“网格式”）

优点：

节省空间，一行可以放置多个入口。

清晰明朗、简洁。一般会突出icon图标，便于记忆和查找。

缺点：

因为空间有限，不能放置太多次级预览内容。

当入口过多时，也不利于辨识和查找。

四、选项卡式

也称为“tab式”，通过对当前界面的信息属性进行划分归类，分为多个选项，用户切换即可。App的主导航一般也是用tab的方式切换。

如下图：消息页面分为4个选项卡

优点：

不用来回跳转页面层级，只需要在当前页面一键切换即可看到不同内容，方便。

用户清楚地知道自己当前所在位置。

缺点：

选项卡数量超过5个就会显得笨重，如果一行放置不下，需要左右滑动才能显示完所有选项卡，会降低操作便捷性。

五、多面板式

对于分类比较多，每个类别囊括的内容也多的情况下，可用多个面板的形式来展示。

优点：

可以清楚地知道当前在哪个位置。

当前界面容纳多个入口，同级别之间切换，不需要在不同层级的页面来回切换，比较方便。

缺点：

面板独占一列空间，整个界面显得比较拥挤。

六、手风琴式

这种方式也有人称为“行为扩展式”。它是在当前界面点击一级信息，展开二级信息的方式，点击时再展开，再点击可缩回，有点类似手风琴缩展的动作。

优点：

只需要在当前页展开二级信息，不需要跳转页面，操作比较方便，也有利于用户认知信息的架构。

缺点：

当信息分类过多且需要手动再点击才能收回二级信息时，全部展开后，不利于跨分类跳转。

七、图表式

通过图表和内容的结合来展示。

优点：

图表比较直观，表现力更强。

缺点：

占据面积较大，整体界面能承载的信息不够多。

如果图形和交互动作结合，大多数用户可能发现不了这些交互。

八、抽屉式

抽屉式适用于隐藏次要功能，让产品突出核心功能。当用户需要查找某个功能入口时，通过点击抽屉，在“抽屉”里面进行查找。

优点：

可帮助隐藏一些功能入口，让产品更简约。

缺点：

用户第一次使用时，因为可见性被减弱，有些功能用户找不到，提高了他们的使用成本。

如果用户常用的功能被放置在抽屉里，则增加了用户操作的步骤。

九、标签式

标签式，顾名思义，就是通过标签设置的方法，把信息进行分类对应为一个个标签，或者标签直接作为功能入口（如“热门搜索”），便于用户操作。

优点：

清晰简洁，占据空间少。

便于切换查看对应的内容，用户清楚自己在哪个分类。

缺点：

标签不宜过多，不利于查找。

小结

移动端的产品形式越来越多样化，人们总是期望随时随地可以在移动端快速获取自己想要的信息，因为硬件规格的限制，如何在有限的空间和用户耐心中争夺用户的注意力，隐含了诸多产品设计的学问。

以上9种常见移动端信息布局方式，只是很浅层的总结，任何一种方式都没有绝对的优劣，不同方式可以互相组合、镶嵌使用，在具体设计时，需要根据实际情况来思考，在不断优化中找到最合适最有效的方案。

三、App中列表、卡片和双栏卡片的布局思考

各布局形式的特点

列表的布局常见于新闻类App。其布局形式的特点在于能够在较小的屏幕中显示多条信息，用户通过上下滑动的手势能获得大量的信息反馈。而列表也是一种非常容易理解的展示形式。

卡片式布局常见于微博、Facebook等社交类App，也出现于其他不同类的App中，形式非常灵活。其特点在于，每张卡片的内容和形式都可以相互独立，互不干扰，所以可以在同一个页面中出现不同的卡片承载不同的内容。而由于每张卡片都是独立存在的，其信息量可以相对列表更加丰富，而且可以让用户对其进行评论、点赞等等操作、省去了跳转到详情页面的步骤。但由于卡片的信息很多，在小屏幕上并不能显示多个卡片，一屏内卡片数很少会超过3个。

而双栏卡片的布局形式，比较常见于以图片信息为主导的App。例如Pinterest，一些商城的商品陈列页面。这种形式与卡片式类似，但它能在一屏里显示更多的内容，至少4张卡片。同时，由于分开左右两栏的显示，用户可以更加方便地对比左右两栏卡片的内容。

布局背后的行为逻辑

然而，为什么新闻类的多采用列表，社交类多采用卡片，图片类多采用双栏卡片？

我们回归到用户需求和行为模式来思考这个问题。

当我们在浏览新闻的时候，我们的需求是什么？大部分人的需求都是，一方面想要知道最近发生的一些事情，这是量的需求；另一方面，想要深入了解这一事情是什么，这是深度阅读的需求。而量的需求往往具有先行性，深度阅读是在其后的。基于这样的需求，用户在浏览新闻时候的行为模式大概如下：快速大量浏览→筛选→判断→快速大量浏览，如下：

由上图看出，用户在浏览新闻时，需要快速地处理大量的信息，而且高频地在极短时间内进行决策。因此，高效性就极为重要，假如在一屏中只显示一两条信息显然是不合适的。除此之外，展示形式的高度一致性和对展示内容的信息量进行严格控制也及其重要。高度一致性可以让用户快速理解展示形式，从而能自主选择自己想要的内容，便于筛选和判断。控制信息量能减少信息干扰，从而提高效率。由于这样的限制，列表就成为了新闻展示的合理形式。

同理，在用Pinterest时，我们究竟是想要什么？是找到最适合的图片。最适合，就会存在唯一性，就会有对比，取舍，选择。这也意味着，用户不是一张张按顺序浏览，而是反复地对比浏览，如下图：

基于这样的行为模式，要求布局形式：1.在一屏能内能展示足够多的内容；2.能让用户方便地对比内容。同时，对内容本身也有要求：1.内容本身是能被快速理解。2.内容本身具有可比性。

以厨房故事为例，这是一个款学习西餐的App，跟Pinterest毫无关联，却用着同样的布局。除了视觉美观这样感性的解释之外，我们可以从别的角度来理解。

假设这样一个场景，饭点到了，今天我想吃吃西餐，所以打开了每日厨房，挑其中一款来作为今晚的晚餐。因为，可能我这周就做这么一顿西餐，所以这次的选择必须精挑细选，既要好吃，还要颜值高，更要操作简单。在每日厨房的首屏中展示了各种成品的图片，这很好，我可以通过比较颜值来挑选我想要的。还有每款菜的收藏数，这大概能体现这款菜的综合评价，这也帮助我降低了选择的难度。很快，经过几番的对比，我最终选择了肉酱意面作为今晚的晚餐...

由以上场景可以说明，用户在使用这款App时，由于只能选择一次，所以他不得不对比内容。同时，易于理解的图片和数据促成了对比这一行为。所以，双栏卡片这样的布局是一个很好的承载方式。

以同样的思路，当我们在刷微博的时候，我们的需求又是什么？更加便捷地跟好友或者是关注的人进行互动。而进行互动的前提是，要对内容进行理解性地阅读，而不是快速地跳读。所以在浏览好友动态时的行为模型应该如下：

上图说明，在展示形式至少要满足2个条件。第一，需要承载致少两个纬度的信息，一是让用户理解的内容信息，二是让用户互动的操作信息；第二，在当前页用户可以对内容进行操作，甚至能在当前页把操作完成。然而，这还不能完全说明卡片式的布局是最合理的。这需要把微博内容的易理解性，信息的复杂度等因素综合考虑，卡片式的布局是一个比较好的解决方案。

由于卡片式的设计形式非常多样和灵活，适用范围也极为广泛。且不在这里作深入的探讨。

总结

结合各布局形式的特点和背后的行为逻辑，我们可以得出以下结论:

当用户的行为模式更倾向于高效，迅速地筛选信息，列表是一个非常好的选择。

当用户的行为需要反复对比信息，或者需要在单屏内获得更多信息，可以尝试用双栏卡片式布局。

当用户不仅仅需要消费所展示的内容，更愿意地对其内容进行互动，那么卡片式的布局可以优先考虑。

最后反思

本文仅仅是通过个布局形式的特点和背后的行为逻辑去思考布局的适用范围，显然，这种单一维度的思考，在实际案例中是不合适的。除了用户的行为模式意外，需要考虑到的因素可以有：

1.各布局形式视觉流特点（列表是自上而下的"I"型视觉流，双栏卡片是上下左右跳动的"z"型视觉流）

2.信息传达的优先性（列表更适用于文字传达，卡片式更适合图片传达）

3.布局的可延展性

4.对品牌的塑造性

5.等等

而针对每个场景，每个App，每个页面，每个考虑因素的比重也是不一样的，这需要具体问题问题具体分析。但无论怎样，设计的结果可以千变万化，但设计背后的逻辑必须是可以追本溯源的。

四、Android性能优化总结

常用的Android性能优化方法：

一、布局优化：

1）尽量减少布局文件的层级。

层级少了，绘制的工作量也就少了，性能自然提高。

2）布局重用 <include标签>

3）按需加载：使用ViewStub,它继承自View,一种轻量级控件，本身不参与任何的布局和绘制过程。他的layout参数里添加一个替换的布局文件，当它通过setVisibility或者inflate方法加载后，它就会被内部布局替换掉。

二、绘制优化：

基于onDraw会被调用多次，该方法内要避免两类操作：

1）创建新的局部对象，导致大量垃圾对象的产生，从而导致频繁的gc，降低程序的执行效率。

2）不要做耗时操作，抢CPU时间片，造成绘制很卡不流畅。

三、内存泄漏优化：

1）静态变量导致内存泄漏   比较明显

2）单例模式导致的内存泄漏 单例无法被垃圾回收，它持有的任何对象的引用都会导致该对象不会被gc。

3）属性动画导致内存泄漏  无限循环动画，在activity中播放，但是onDestroy时没有停止的话，动画会一直播放下去，view被动画持有，activity又被view持有，导致activity无法被回收。

四、响应速度优化：

1）避免在主线程做耗时操作 包括四大组件，因为四大组件都是运行在主线程的。

2）把一些创建大量对象等的初始化工作放在页面回到前台之后，而不应该放到创建的时候。

五、ListView的优化：

1）使用convertView，走listView子View回收的一套：RecycleBin 机制

主要是维护了两个数组，一个是mActiveViews,当前可见的view,一个是mScrapViews，当前不可见的view。当触摸ListView并向上滑动时，ListView上部的一些OnScreen的View位置上移，并移除了ListView的屏幕范围，此时这些OnScreen的View就变得不可见了，不可见的View叫做OffScreen的View，即这些View已经不在屏幕可见范围内了，也可以叫做ScrapView，Scrap表示废弃的意思，ScrapView的意思是这些OffScreen的View不再处于可以交互的Active状态了。ListView会把那些ScrapView（即OffScreen的View）删除，这样就不用绘制这些本来就不可见的View了，同时，ListView会把这些删除的ScrapView放入到RecycleBin中存起来，就像把暂时无用的资源放到回收站一样。

当ListView的底部需要显示新的View的时候，会从RecycleBin中取出一个ScrapView，将其作为convertView参数传递给Adapter的getView方法，从而达到View复用的目的，这样就不必在Adapter的getView方法中执行LayoutInflater.inflate()方法了。

RecycleBin中有两个重要的View数组，分别是mActiveViews和mScrapViews。这两个数组中所存储的View都是用来复用的，只不过mActiveViews中存储的是OnScreen的View，这些View很有可能被直接复用；而mScrapViews中存储的是OffScreen的View，这些View主要是用来间接复用的。

2）使用ViewHolder避免重复地findViewById

3)快速滑动不适合做大量异步任务，结合滑动监听，等滑动结束之后加载当前显示在屏幕范围的内容。

4）getView中避免做耗时操作，主要针对图片：ImageLoader来处理(原理：三级缓存)

5）对于一个列表，如果刷新数据只是某一个item的数据，可以使用局部刷新，在列表数据量比较大的情况下，节省不少性能开销。

六、Bitmap优化：

1）减少内存开支：图片过大，超过控件需要的大小的情况下，不要直接加载原图，而是对图片进行尺寸压缩，方式是BitmapFactroy.Options 采样，inSampleSize 转成需要的尺寸的图片。

2）减少流量开销：对图片进行质量压缩，再上传服务器。图片有三种存在形式：硬盘上时是file，网络传输时是stream，内存中是stream或bitmap，所谓的质量压缩，它其实只能实现对file的影响，你可以把一个file转成bitmap再转成file，或者直接将一个bitmap转成file时，这个最终的file是被压缩过的，但是中间的bitmap并没有被压缩。bitmap.compress(Bitmap.CompressFormat.PNG,100,bos);

七、线程优化：

使用线程池。为什么要用线程池？

1、从“为每个任务分配一个线程”转换到“在线程池中执行任务”

2、通过重用现有的线程而不是创建新线程，可以处理多个请求在创建销毁过程中产生的巨大开销

3、当使用线程池时，在请求到来时间 ，不用等待系统重新创建新的线程，而是直接复用线程池中的线程，这样可以提高响应性。

4、通过和适当调整线程池的大小 ，可以创建足够多的线程以使处理器能够保持忙碌状态，同时还可以防止过多线程相互竞争资源而使应用程序耗尽内存或者失败。

5、一个App里面所有的任务都放在线程池中执行后，可以统一管理 ，当应用退出时，可以把程序中所有的线程统一关闭，避免了内存和CPU的消耗。

6、如果这个任务是一个循环调度任务，你则必须在这个界面onDetach方法把这个任务给cancel掉，如果是一个普通任务则可cancel，可不cancel，但是最好cancel

7、整个APP的总开关会在应用退出的时间把整个线程池全部关闭。

八、一些性能优化建议：

1）避免创建过多对象，造成频繁的gc

2)不要过多使用枚举，枚举占用的空间比整型大很多

3）字符串的拼接使用StringBuffer、StringBuilder来替代直接使用String,因为使用String会创建多个String对象，参考第一条。

4）适当使用软引用，（弱引用就不太推荐了）

5）使用内存缓存和磁盘缓存。

以上就是关于app页面布局优化建议相关问题的回答。希望能帮到你，如有更多相关问题，您也可以联系我们的客服进行咨询，客服也会为您讲解更多精彩的知识和内容。

推荐阅读：

okpay官网app下载（okpay支付平台下载）

免费提取视频工具（免费提取视频工具app）

全网拓客app下载

小红书怎么付费推广（小红书推广费用一般多少）

杭州70岁以上老人100元补贴（杭州70岁以上老人100元补贴怎么领）