你该知道的东西 <Android优化>

前言

本篇文章为Android优化的布局部分,该部分应该是Android中很重要的,无论是在自定义控件中,还是在简单的书写布局时,都应该尽量遵循一些优化原则,这样布局的绘制效率才会更高,体验才能更好。

一 优化layout的层级

Layout结构如果太复杂,Android的绘制过程就会很复杂,measure过程就会很复杂,我分析的View绘制机制中详细介绍了整个测量、布局和绘制过程,过于复杂、嵌套的布局会造成性能问题。

1.1 避免嵌套

嵌套的 LinearLayout 可能会使得 View 的层级结构很深。使用LinearLayout时,通常我们喜欢用嵌套的布局来动态设置一个View的Visibility ,由于LinearLayout是线性的,因此即使隐藏一个View也不会影响到其它View的排列。而在RelativeLayout中,View的位 置都是相对于其它View的,因此,隐藏之后,会导致之前的View没有参考对象了,导致的相对位置改变,这时你可以使用 alignWithParentIfMissing=”true”来处理这种情况。

此外,嵌套使用了 layout_weight 参数的 LinearLayout 的计算量会尤其大,因为每个子元素都需要被测量两次。这对需要多次重复 inflate 的 Layout 尤其需要注意,比如使用 ListView 或 GridView 时。

1.2 使用merge标签优化层级

在使用了include后可能导致布局嵌套过多,出现不必要的layout节点,从而导致解析变慢。

merge标签可用于两种典型情况:

  • 布局顶结点是FrameLayout且不需要设置background或padding等属性,可以用merge代替,因为Activity内容试图的parent view就是个FrameLayout,所以可以用merge消除只剩一个。
  • 某布局作为子布局被其他布局include时,使用merge当作该布局的顶节点,这样在被引入时顶结点会自动被忽略,而将其子节点全部合并到主布局中。

比如,如果你有一个 Layout 是一个竖直方向的 LinearLayout,其中包含两个连续的 View 可以在别的 Layout 中重用,那么你会做一个 LinearLayout 来包含这两个 View ,以便重用。不过,当使用另一个 LinearLayout 来嵌套这个可重用的 LinearLayout 时,这种嵌套 LinearLayout 的方式除了减慢你的 UI 性能外没有任何意义。

为了避免这种情况,你可以用  元素来替代可重用 Layout 的根节点。例如:

<merge xmlns:android="http://schemas.android.com/apk/res/android">
    <Button
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:text="@string/add"/>
    <Button
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:text="@string/delete"/>
</merge>

现在,当你要将这个 Layout 包含到另一个 Layout 中时(并且使用了  标签),系统会直接把两个 Button 放到 Layout 中,而不会有多余的 Layout 被嵌套。

二 使用标签重用Layout

如果你的程序 UI 在不同地方重复使用某个 Layout,那本节教你如何创建高效的,可重用的 Layout 部件,并把它们“包含”到 UI Layout 中。

为了高效重用整个的 Layout,你可以使用  和  标签把其他 Layout 嵌入当前 Layout。

三 按需载入视图

除了简单的把一个 Layout 包含到另一个中,你可能还想在程序开始后,仅当你的 Layout 对用户可见时才开始载入。

3.1 不需要立即加载的布局,设置为GONE,系统会跳过,不加载

3.2 使用ViewStub 实现按需加载

ViewStub 是一个轻量的视图,不需要大小信息,也不会在被加入的 Layout 中绘制任何东西。每个 ViewStub 只需要设置 android:layout 属性来指定需要被 inflate 的 Layout 类型。viewstub常用来引入那些默认不会显示,只在特殊情况下显示的布局,如进度布局、网络失败显示的刷新布局、信息出错出现的提示布局等。

以下 ViewStub 是一个半透明的进度条覆盖层。功能上讲,它应该只在新的数据项被导入到应用程序时可见。

<ViewStub
    android:id="@+id/stub_import"
    android:inflatedId="@+id/panel_import"
    android:layout="@layout/progress_overlay"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:layout_gravity="bottom" />

载入 ViewStub

当你要载入用 ViewStub 声明的 Layout 时,要么用 setVisibility(View.VISIBLE) 设置它的可见性,要么调用其 inflate() 方法。

下面以在一个布局main.xml中加入网络错误时的提示页面network_error.xml为例。main.mxl代码如下:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
    ……
    <ViewStub
        android:id="@+id/network_error_layout"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout="@layout/network_error" />
</RelativeLayout>

其中network_error.xml为只有在网络错误时才需要显示的布局

setVisibility(View.VISIBLE)方式

View viewStub = ((ViewStub)findViewById(R.id.stub_import));
viewStub.setVisibility(View.VISIBLE);
netErrorLayout = findViewById(R.id.net_error_layout))

inflate方式

View netErrorLayout = ((ViewStub) findViewById(R.id.net_error_layout)).inflate();

注意:

inflate() 方法会在渲染完成后返回给被 inflate 的视图,所以你不需要再调用 findViewById() 去查找这个元素。减少inflate的次数,也会对效率有一点提升。

而setVisible方式还需要再次findViewById找到ViewStub中的元素。

一旦 ViewStub 可见或是被 inflate 了,ViewStub 元素就不存在了。取而代之的是被 inflate 的 Layout,其 id 是 ViewStub 上的 android:inflatedId 属性。(ViewStub 的 android:id 属性仅在 ViewStub 可见以前可用)

注意:ViewStub 的一个缺陷是,它目前不支持使用  标签的 Layout

四 ListView的优化

如果你有一个包含复杂或者每个项 (item) 包含很多数据的 ListView ,那么上下滚动的性能可能会降低。本节给你一些关于如何把滚动变得更流畅的提示。

保持程序流畅的关键,是让主线程(UI 线程)不要进行大量运算。你要确保在其他线程执行磁盘读写、网络读写或是 SQL 操作等。为了测试你的应用的状态,你可以启用 StrictMode。

4.1 使用后台线程

你应该把主线程中的耗时间的操作,提取到一个后台线程中,使得主线程只关注 UI 绘画。

4.2 在 View Holder 中填入视图对象

使用convertView、

你的代码可能在 ListView 滑动时经常使用 findViewById(),这样会降低性能。即使是 Adapter 返回一个用于回收的 convertView,你仍然需要查找这个元素并更新它。避免频繁调用 findViewById() 的方法之一,就是使用 View Holder(视图占位符)设计模式。

ViewHolder 存储了标签下的每个视图。这样你不用频繁查找这个元素:

static class ViewHolder {
    TextView text;
    TextView timestamp;
    ImageView icon;
    ProgressBar progress;
    int position;
}

然后,在 Layout 的类中生成一个 ViewHolder 对象:

ViewHolder holder = new ViewHolder();
holder.icon = (ImageView) convertView.findViewById(R.id.listitem_image);
...
convertView.setTag(holder);

这样你就可以轻松获取每个视图,而不是用 findViewById() 来不断查找视图,节省了宝贵的运算时间。

4.3 getView不要做复杂的操作

因为每一条Item移入屏幕的时候,都会调用getView,不要在getView中做复杂的操作,不要频繁的创建对象。Item点击的处理不要提前做。特别是在快速滑动的时候,会导致频繁的调用getView。

五 优化提示

尽量使用RelativeLayout,可以减少层级的嵌套。

慎用LinearLayout的layout_weight属性,可以使用RelativeLayout的centerHorizontal=”true”、toLeft、toRight代替

六 书写规范上的优化

6.1 Id的命名

为了便于识别,你可以根据自己的业务来对当前界面的资源进行命名,比如当前是登陆界面,那么你可以这样命名:

login_edit_username

login_edit_password

login_btn_submit

login_txv_forgot_pass

6.2 资源的命名

ic_action_add, ic_action_location (ActionBar Icons)

ic_play, ic_save (General Icons)

ic_tab_music, ic_tab_more (Tab Icons)

6.3 通用的资源命名

对style.xml和dimens.xml的命名可以通用的尽量通用,因为一个项目的基本视图很多都是通用的,比如ActionBar、ListView等,规范通用的命名可以很方便的移植到其它项目中。

<color name="list_item_large">#FCA558</color>
<color name="list_item_small">#FBA228</color>
<dimen name="list_item_large">24dp</dimen>
<dimen name="list_item_small">18dp</dimen>
<!-- 简单ListView样式 -->
<style name="list_view_style_default">
<item name="android:layout_width">fill_parent</item>
<item name="android:layout_height">wrap_content</item>
...
</style>

时间: 2024-10-04 23:59:27

你该知道的东西 <Android优化>的相关文章

Android 优化篇

http://my.oschina.net/u/586684/blog/207844 1. 使用保守的Service 2. 当视图变为隐藏状态后释放内存: 当用户跳转到不同的应用并且你的视图不再显示时, 你应该释放应用视图所占的资源. 这时释放所占用的资源能显著的提高系统的缓存处理容量, 并且对用户的体验质量有直接的影响. 使用优化后的数据容器: 比如 SparseArray, SparseBooleanArray 和 LongSparseArray. 传统的 HashMap 在内存上的实现十分

Android优化-与Java有关-内存

内存优化 Android系统对每个软件所能使用的RAM空间进行了限制(如:Nexus one 对每个软件的内存限制是24M),同时Java语言本身比较消耗内存,dalvik虚拟机也要占用一定的内存空间,所以合理使用内存,彰显出一个程序员的素质和技能. 1) 了解JIT 即时编译(Just-in-time Compilation,JIT),又称动态转译(Dynamic Translation),是一种通过在运行时将字节码翻译为机器码,从而改善字节码编译语言性能的技术.即时编译前期的两个运行时理论是

Android优化系列之ListView优化详解

本文内容:adapter,listview的优化,RecycleBi,n优化情况对比,google大会推荐优化, 实现ListView的过程,Adapter起到了至关重要的作用,不仅仅因为getview()方法.那么,先从Adapter说起~ Adapter: 它在ListView和数据源之间起到桥梁的作用,避免listview和数据源直接接触,而导致因为数据源的复杂性使listview显得臃肿. Adapter,适配器,把复杂的数据源适配给listview,很容易联想到适配器模式.   下面是

unity3d android 优化

最近项目进入收尾阶段,之前对项目做了很多优化,mesh合并 ,减少DrawCall和模型骨骼以及物理计算,合并材质球,优化代码等等,在IOS上还好,但是android上,试过几款手机,从低端到高端,发现性能还是很差,所以又花了几天来研究摸索,终于把游戏性能搞定.记录下来,留作以后参考. 1. 更新不透明贴图的压缩格式为ETC 4bit,因为android市场的手机中的GPU有多种,每家的GPU支持不同的压缩格式,但他们都兼容ETC格式, 2. 对于透明贴图,我们只能选择RGBA 16bit 或者

Android 优化 篇

Android应用程序窗口(Activity)的运行上下文环境(Context)的创建过程分析 1. 能用 Application  的 上下文 就用. 因为如果用 Activity 的 Context ,如果用太多的 Activity, 如果 有些资源 还在引用 Activity的context的资源,会导致 这个 Activity 没有被回收,有可能导致 oom. 2. bitmap 回收 3. Dialog 用完之后, dismiss 之后,设为 null. 4. 图片不要做内存缓存,可以

Android优化App启动时间

原文地址:https://developer.android.com/topic/performance/vitals/launch-time 用户希望App能够快速相应和加载,应用启动缓慢会带来糟糕的用户体验,导致用户恶评,甚至会卸载你的应用. 这篇文章提供的信息能够帮助你优化应用的启动时间.首先,我们先来了解应用启动的内部原理,接下来,我们会讨论如何分析启动性能.最后,最后我们会介绍一些影响启动性能的常见问题,并会给出相应的解决办法. 应用启动原理 应用启动可以分为三种类型,冷启动,暖启动,

Android开发经验分享(5)Android优化小结

项目中何时不会用到优化呢,现把一些优化的小经验总结下 1.万恶的static static是个好东西,声明赋值调用就是那么的简单方便,但是伴随而来的还有性能问题.由于static声明变量的生命周期其实是和APP的生命周期一样的,有点类似与Application.如果大量的使用的话,就会占据内存空间不释放,积少成多也会造成内存的不断开销,直至挂掉.static的合理使用一般用来修饰基本数据类型或者轻量级对象,尽量避免修复集合或者大对象,常用作修饰全局配置项.工具类方法.内部类. 2.无关引用 很多

Android优化指南

ListView的优化 复用convertview , 历史的view对象 减少子孩子查询的次数 viewholder 异步加载数据(把图片缓存) 条目多时分页加载数据 加载时显示进度条让用户等待 Item的布局层次结构尽量简单,避免布局太深或者不必要的重绘 避免在 getView 方法中做耗时的操作:例如加载本地 Image 需要载入内存以及解析 Bitmap ,都是比较耗时的操作,如果用户快速滑动listview,会因为getview逻辑过于复杂耗时而造成滑动卡顿现象.用户滑动时候不要加载图

Glow Android 优化实践

了解 Glow 的朋友应该知道,我们主营四款 App,分别是Eve.Glow.Nuture和Baby.作为创业公司,我们的四款 App 都处于高速开发中,平均每个 Android App 由两人负责开发,包括 Android 和 Server 开发,在满足 PM 各种需求的同时,我们的 session crash free 率保持不低于 99.8%,其中两款 App 接近 100%. 本文将对 Glow 当前 Android App 中对现有工具的探索及优化进行讲解,希望对读者有所启发. 整体结