Android 性能优化方案大全

一： Android 内存角度优化

对于一些Android项目，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说RAM对性能的影响十分敏感，除了 优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:

 

 
 
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ; 

 

 
 
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); 

//设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理


bitmap 设置图片尺寸，避免 内存溢出 OutOfMemoryError的优化方法
★android 中用bitmap 时很容易内存溢出，报如下错误：Java.lang.OutOfMemoryError : bitmap size exceeds VM budget

● 主要是加上这段：
 

 
 
BitmapFactory.Options options = new BitmapFactory.Options(); 
                options.inSampleSize = 2; 

● eg1：(通过Uri取图片)
 

 
 
private ImageView preview; 
BitmapFactory.Options options = new BitmapFactory.Options(); 
                    options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一 
                    Bitmap bitmap = BitmapFactory.decodeStream(cr 
                            .openInputStream(uri), null, options); 
                    preview.setImageBitmap(bitmap); 

以上代码可以优化内存溢出，但它只是改变图片大小，并不能彻底解决内存溢出。
● eg2:（通过路径去图片）
 

 
 
private ImageView preview; 
private String fileName= "/sdcard/DCIM/Camera/2010-05-14 16.01.44.jpg"; 
BitmapFactory.Options options = new BitmapFactory.Options(); 
                options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一 
                        Bitmap b = BitmapFactory.decodeFile(fileName, options); 
                        preview.setImageBitmap(b); 
                        filePath.setText(fileName); 

★Android 还有一些性能优化的方法：
●  首先内存方面，可以参考 Android堆内存也可自己定义大小 和 优化Dalvik虚拟机的堆内存分配

●  基础类型上，因为Java没有实际的指针，在敏感运算方面还是要借助NDK来完成。这点比较有意思的是Google 推出NDK可能是帮助游戏开发人员，比如OpenGL ES的支持有明显的改观，本地代码操作图形界面是很必要的。

●  图形对象优化，这里要说的是Android上的Bitmap对象销毁，可以借助recycle()方法显示让GC回收一个Bitmap对象，通常对一个不用的Bitmap可以使用下面的方式，如

 

 
 
if(bitmapObject.isRecycled()==false) //如果没有回收   
         bitmapObject.recycle();    

●  目前系统对动画支持比较弱智对于常规应用的补间过渡效果可以，但是对于游戏而言一般的美工可能习惯了GIF方式的统一处理，目前Android系统仅能预览GIF的第一帧，可以借助J2ME中通过线程和自己写解析器的方式来读取GIF89格式的资源。

● 对于大多数Android手机没有过多的物理按键可能我们需要想象下了做好手势识别 GestureDetector 和重力感应来实现操控。通常我们还要考虑误操作问题的降噪处理。

Android堆内存也可自己定义大小

   对于一些大型Android项目或游戏来说在算法处理上没有问题外，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说RAM对性能的影响十分敏感，除了上次Android开发网提到的优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:

 

 
 
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ; 

 

 
 
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);  

//设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理，我们将在下次提到具体应用。

优化Dalvik虚拟机的堆内存分配

对于Android平台来说，其托管层使用的Dalvik JavaVM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用 dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法:   private final static floatTARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate时就可以调用 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。

二：Android布局的优化方案汇总

层级观察器(Hierarchy Viewer)：

Android SDK tools目录下提供一个观察布局的工具，层级观察器(Hierarchy Viewer)。Hierarchy Viewer工具是一个非常好的布局优化工具，同时，你也可以通过它学习他人的布局。应该说是一个非常实用的工具。

 

上面写有控件名称和id等信息，下方的圆形表示这个节点的渲染速度，从左至右分别为测量大小，布局和绘制。绿色最快，红色最慢。右下角的数字为子节点在父节点中的索引，如果没有子节点则为0。点击可以查看对应控件预览图、该节点的子节点数（为6则有5个子节点）以及具体渲染时间。双击可以打开控件图。右侧是树形结构的预览、控件属性和应用界面的结构预览。点击相应的树形图中的控件可以在右侧看到他在布局中的位置和属性。工具栏有一系列的工具，保存为png或者psd等工具。（http://www.linuxidc.com/Linux/2012-01/52263.htm ）

layoutopt使用：

创建好看的Android布局是个不小的挑战，当你花了数小时调整好它们适应多种设备后，你通常不想再重新调整，但笨重的嵌套布局效率往往非常低下，幸运的是，在Android SDK中有一个工具可以帮助你优化布局，以减少内存消耗，提高应用程序运行性能。

layoutoptimization

优化是需要一定技巧的，性能良好的代码固然重要，但写出优秀代码的成本往往也很高，你可能不会过早地贸然为那些只运行一次或临时功能代码实施优化，如果你的应用程序反应迟钝，并且卖得很贵，或使系统中的其它应用程序变慢，用户一定会有所响应，你的应用程序下载量将很可能受到影响。

在开发期间尽早优化你的布局是节省成本，提高性能的简单方法，Android SDK带来了一个工具，它可以自动分析你的布局，发现可能并不需要的布局元素，以降低布局复杂度。

第一步：准备工作

如果想使用Android SDK中提供的优化工具，你需要在开发系统的命令行中工作，如果你不熟悉使用命令行工具，那么你得多下功夫学习了。

我们强烈建议你将Android工具所在的路径添加到操作系统的环境变量中，这样就可以直接敲名字运行相关的工具了，否则每次都要在命令提示符后面输入完整的文件路径，现在在Android SDK中有两个工具目录：/tools和/platform-tools，本文主要使用位于/tools目录中的layoutopt工具，另外我想说的是，ADB工具位于/platform-tools目录下。

运行layoutopt

运行layoutopt工具是相当简单的，只需要跟上一个布局文件或布局文件所在目录作为参数，需要注意的是，这里你必须包括布局文件或目录的完整路径，即使你当前就位于这个目录。我们来看一个简单的例子：

D:\d\tools\eclipse\article_ws\Nothing\res\layout>layoutopt 

D:\d\tools\eclipse\article_ws\Nothing\res\layout\main.xml  

D:\d\tools\eclipse\article_ws\Nothing\res\layout\main.xml  

D:\d\tools\eclipse\article_ws\Nothing\res\layout>

注意，在上面的示例中，包含了文件的完整路径，如果不指定完整路径，不会输出任何内容，例如：

D:\d\tools\eclipse\article_ws\Nothing\res\layout>layoutopt main.xml  D:\d\tools\eclipse\article_ws\Nothing\res\layout> 

因此，如果你看不任何东西，则很可能是文件未被解析，也就是说文件可能未被找到。

使用layoutopt输出

Layoutopt的输出结果只是建议，你可以有选择地在你的应用程序中采纳这些建议，下面来看几个使用layoutopt输出建议的例子。

无用的布局

在布局设计期间，我们会频繁地移动各种组件，有些组件最终可能会不再使用，如：

 
 
 <?xml version="1.0" encoding="utf-8"?>  
 
<LinearLayout     xmlns:android="http://schemas.android.com/apk/res/android"      
 
 android:layout_width="match_parent"     
 
 android:layout_height="match_parent"      
 
android:orientation="horizontal">      
 
<LinearLayout         android:id="@+id/linearLayout1"         
 
 android:layout_height="wrap_content"         
 
 android:layout_width="wrap_content"         
 
 android:orientation="vertical">         
 
 <TextView             android:id="@+id/textView1"             
 
 android:layout_width="wrap_content"             
 
 android:text="TextView"              
 
android:layout_height="wrap_content"></TextView>  
 
</LinearLayout> </LinearLayout>  

 

工具将会很快告诉我们LinearLayout内的LinearLayout是多余的：
 

11:17 This LinearLayout layout or its LinearLayout parent is useless  

输出结果每一行最前面的两个数字表示建议的行号。

根可以替换

Layoutopt的输出有时是矛盾的，例如：
 

 
 
<?xml version="1.0" encoding="utf-8"?>  
 
<FrameLayout     xmlns:android="http://schemas.android.com/apk/res/android"    
 
android:layout_width="match_parent"      
 
android:layout_height="match_parent">      
 
<LinearLayout         android:id="@+id/linearLayout1"          
 
android:layout_height="wrap_content"          
 
android:layout_width="wrap_content"          
 
android:orientation="vertical">          
 
<TextView             android:id="@+id/textView1"              
 
android:layout_width="wrap_content"              
 
android:text="TextView"              
 
android:layout_height="wrap_content"></TextView>          
 
<TextView             android:text="TextView"              
 
android:id="@+id/textView2"              
 
android:layout_width="wrap_content"              
 
android:layout_height="wrap_content"></TextView>      
 
</LinearLayout> </FrameLayout>  

这个布局将返回下面的输出：
 

5:22 The root-level <FrameLayout/> can be replaced with <merge/> 10:21 This LinearLayout layout or its FrameLayout parent is useless  

第一行的建议虽然可行，但不是必需的，我们希望两个TextView垂直放置，因此LinearLayout应该保留，而第二行的建议则可以采纳，可以删除无用的FrameLayout。

有趣的是，这个工具不是全能的，例如，在上面的例子中，如果我们给FrameLayout添加一个背景属性，然后再运行这个工具，第一个建议当然会消失，但第二个建议仍然会显示，工具知道我们不能通过合并控制背景，但检查了LinearLayout后，它似乎就忘了我们还给FrameLayout添加了一个LinearLayout不能提供的属性。

太多的视图

每个视图都会消耗内存，在一个布局中布置太多的视图，布局会占用过多的内存，假设一个布局包含超过80个视图，layoutopt可能会给出下面这样的建议：
 

-1:-1 This layout has too many views: 83 views, it should have <= 80!  -1:-1 This layout has too many views: 82 views, it should have <= 80!  -1:-1 This layout has too many views: 81 views, it should have <= 80!  

上面给出的建议是视图数量不能超过80，当然最新的设备有可能能够支持这么多视图，但如果真的出现性能不佳的情况，最好采纳这个建议。

嵌套太多

布局不应该有太多的嵌套，layoutopt（和Android团队）建议布局保持在10级以内，即使是最大的平板电脑屏幕，布局也不应该超过10级，RelativeLayout可能是一个解决办法，但它的用法更复杂，好在Eclipse中的Graphical Layout资源工具更新后，使得这一切变得更简单。

下面是布局嵌套太多时，layoutopt的输出内容：
 

-1:-1 This layout has too many nested layouts: 12 levels, it should have <= 10!  305:318 This LinearLayout layout or its RelativeLayout parent is possibly useless  307:314 This LinearLayout layout or its FrameLayout parent is possibly useless  310:312 This LinearLayout layout or its LinearLayout parent is possibly useless  

嵌套布局警告通常伴随有一些无用布局的警告，有助于找出哪些布局可以移除，避免屏幕布局全部重新设计。

小结

Layoutopt是一个快速易用的布局分析工具，找出低效和无用的布局，你要做的是判断是否采纳layoutopt给出的优化建议，虽然采纳建议作出修改不会立即大幅改善性能，但没有理由需要复杂的布局拖慢整个应用程序的速度，并且后期的维护难度也很大。简单布局不仅简化了开发周期，还可以减少测试和维护工作量，因此，在应用程序开发期间，应尽早优化你的布局，不要等到最后用户反馈回来再做修改。

 三：Android性能优化之数据库优化

1、索引
简单的说，索引就像书本的目录，目录可以快速找到所在页数，数据库中索引可以帮助快速找到数据，而不用全表扫描，合适的索引可以大大提高数据库查询的效率。
(1). 优点
大大加快了数据库检索的速度，包括对单表查询、连表查询、分组查询、排序查询。经常是一到两个数量级的性能提升，且随着数据数量级增长。

(2). 缺点
索引的创建和维护存在消耗，索引会占用物理空间，且随着数据量的增加而增加。
在对数据库进行增删改时需要维护索引，所以会对增删改的性能存在影响。

(3). 分类
a. 直接创建索引和间接创建索引
直接创建: 使用sql语句创建，Android中可以在SQLiteOpenHelper的onCreate或是onUpgrade中直接excuSql创建语句，语句如

 
 
CREATE INDEX mycolumn_index ON mytable (myclumn) 

间接创建: 定义主键约束或者唯一性键约束，可以间接创建索引，主键默认为唯一索引。

b. 普通索引和唯一性索引
普通索引：

 
 
CREATE INDEX mycolumn_index ON mytable (myclumn) 

唯一性索引：保证在索引列中的全部数据是唯一的，对聚簇索引和非聚簇索引都可以使用，语句为

 
 
CREATE UNIQUE COUSTERED INDEX myclumn_cindex ON mytable(mycolumn) 

c. 单个索引和复合索引

单个索引：索引建立语句中仅包含单个字段，如上面的普通索引和唯一性索引创建示例。
复合索引：又叫组合索引，在索引建立语句中同时包含多个字段，语句如：

CREATE INDEX name_index ON username(firstname, lastname)

 
 
CREATE INDEX name_index ON username(firstname, lastname) 

其中firstname为前导列。

d. 聚簇索引和非聚簇索引(聚集索引，群集索引)
聚簇索引：物理索引，与基表的物理顺序相同，数据值的顺序总是按照顺序排列，语句为：

 
 
CREATE CLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn) WITH ALLOW_DUP_ROW 

其中WITH ALLOW_DUP_ROW表示允许有重复记录的聚簇索引

非聚簇索引：

 
 
CREATE UNCLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn) 

索引默认为非聚簇索引

(4). 使用场景
在上面讲到了优缺点，那么肯定会对何时使用索引既有点明白又有点糊涂吧，那么下面总结下：
a.  当某字段数据更新频率较低，查询频率较高，经常有范围查询(>, <, =, >=, <=)或order by、group by发生时建议使用索引。并且选择度越大，建索引越有优势，这里选择度指一个字段中唯一值的数量/总的数量。
b.  经常同时存取多列，且每列都含有重复值可考虑建立复合索引

(5). 索引使用规则
a.  对于复合索引，把使用最频繁的列做为前导列(索引中第一个字段)。如果查询时前导列不在查询条件中则该复合索引不会被使用。
如

 
 
create unique index PK_GRADE_CLASS on student (grade, class) 

 

 
 
select * from student where class = 2未使用到索引 
select * from dept where grade = 3使用到了索引 

b.  避免对索引列进行计算，对where子句列的任何计算如果不能被编译优化，都会导致查询时索引失效
 

 
 
select * from student where tochar(grade)=’2′ 

c.  比较值避免使用NULL
d.  多表查询时要注意是选择合适的表做为内表。连接条件要充份考虑带有索引的表、行数多的表，内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。实际多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。

e.  查询列与索引列次序一致
f.  用多表连接代替EXISTS子句
g.  把过滤记录数最多的条件放在最前面
h.  善于使用存储过程，它使sql变得更加灵活和高效(Sqlite不支持存储过程::>_<:: )

(6)索引检验

建立了索引，对于某条sql语句是否使用到了索引可以通过执行计划查看是否用到了索引。

2、使用事务
使用事务的两大好处是原子提交和更优性能。
(1) 原子提交
原则提交意味着同一事务内的所有修改要么都完成要么都不做，如果某个修改失败，会自动回滚使得所有修改不生效。

(2) 更优性能
Sqlite默认会为每个插入、更新操作创建一个事务，并且在每次插入、更新后立即提交。

这样如果连续插入100次数据实际是创建事务->执行语句->提交这个过程被重复执行了100次。如果我们显示的创建事务->执行100条语句->提交会使得这个创建事务和提交这个过程只做一次，通过这种一次性事务可以使得性能大幅提升。尤其当数据库位于sd卡时，时间上能节省两个数量级左右。

Sqlte显示使用事务，示例代码如下：

 
 
public void insertWithOneTransaction() { 
    SQLiteDatabase db = sqliteOpenHelper.getWritableDatabase(); // Begins a transaction  db.beginTransaction(); 
try { // your sqls for (int i = 0; i < 100; i++) { 
            db.insert(yourTableName, null, value); 
        } // marks the current transaction as successful  db.setTransactionSuccessful(); 
    } catch (Exception e) { // process it  e.printStackTrace(); 
    } finally { // end a transaction  db.endTransaction(); 
    } 
} 

其中sqliteOpenHelper.getWritableDatabase()表示得到写表权限。

3、其他优化
(1) 语句的拼接使用StringBuilder代替String
这个就不多说了，简单的string相加会导致创建多个临时对象消耗性能。StringBuilder的空间预分配性能好得多。如果你对字符串的长度有大致了解，如100字符左右，可以直接new StringBuilder(128)指定初始大小，减少空间不够时的再次分配。

(2) 读写表

在写表时调用sqliteOpenHelper..getWritableDatabase()，在读表时候调用sqliteOpenHelper..getReadableDatabase()，getReadableDatabase性能更优。

(3) 查询时返回更少的结果集及更少的字段。
查询时只取需要的字段和结果集，更多的结果集会消耗更多的时间及内存，更多的字段会导致更多的内存消耗。

(4) 少用cursor.getColumnIndex

根据性能调优过程中的观察cursor.getColumnIndex的时间消耗跟cursor.getInt相差无几。可以在建表的时候用static变量记住某列的index，直接调用相应index而不是每次查询。

 
 
public static final String       HTTP_RESPONSE_TABLE_ID = android.provider.BaseColumns._ID;
public static final String       HTTP_RESPONSE_TABLE_RESPONSE = "response"; public List<Object> getData() { 
    …… 
    cursor.getString(cursor.getColumnIndex(HTTP_RESPONSE_TABLE_RESPONSE)); 
    …… 
} 

优化为

public static final String HTTP_RESPONSE_TABLE_ID = android.provider.BaseColumns._ID; 
 public static final String HTTP_RESPONSE_TABLE_RESPONSE  = "response"; 
 public static final int HTTP_RESPONSE_TABLE_ID_INDEX  = 0; 
 public static final int HTTP_RESPONSE_TABLE_URL_INDEX = 1; 
 public List<Object> getData() {     ……     cursor.getString(HTTP_RESPONSE_TABLE_RESPONSE_INDEX);     …… }

 

4、异步线程
Sqlite是常用于嵌入式开发中的关系型数据库，完全开源。
与Web常用的数据库Mysql、Oracle db、sql server不同，Sqlite是一个内嵌式的数据库，数据库服务器就在你的程序中，无需网络配置和管理，数据库服务器端和客户端运行在同一进程内，减少了网络访问的消耗，简化了数据库管理。不过Sqlite在并发、数据库大小、网络方面存在局限性，并且为表级锁，所以也没必要多线程操作。

Android中数据不多时表查询可能耗时不多，不会导致anr，不过大于100ms时同样会让用户感觉到延时和卡顿，可以放在线程中运行，但sqlite在并发方面存在局限，多线程控制较麻烦，这时候可使用单线程池，在任务中执行db操作，通过handler返回结果和ui线程交互，既不会影响UI线程，同时也能防止并发带来的异常。实例代码如下：

ExecutorService singleThreadExecutor = Executors.newSingleThreadExecutor();
 singleThreadExecutor.execute(new Runnable() {      
           @Override public void run() {  
         // db operetions, u can use handler to send message after db.insert(yourTableName, null, value);
           handler.sendEmptyMessage(xx);    
       }
 });

四：Android开发优化之——对界面UI的优化（1）

在Android应用开发过程中，屏幕上控件的布局代码和程序的逻辑代码通常是分开的。界面的布局代码是放在一个独立的xml文件中的，这个文件里面是树型组织的，控制着页面的布局。通常，在这个页面中会用到很多控件，控件会用到很多的资源。

在Android应用开发过程中，屏幕上控件的布局代码和程序的逻辑代码通常是分开的。界面的布局代码是放在一个独立的xml文件中的，这个文件里面是树型组织的，控制着页面的布局。通常，在这个页面中会用到很多控件，控件会用到很多的资源。Android系统本身有很多的资源，包括各种各样的字符串、图片、动画、样式和布局等等，这些都可以在应用程序中直接使用。这样做的好处很多，既可以减少内存的使用，又可以减少部分工作量，也可以缩减程序安装包的大小。

下面从几个方面来介绍如何利用系统资源。

1）利用系统定义的id

比如我们有一个定义ListView的xml文件，一般的，我们会写类似下面的代码片段。

 
 
<ListView 
 
    android:id="@+id/mylist" 
 
    android:layout_width="fill_parent" 
 
    android:layout_height="fill_parent"/> 
  

这里我们定义了一个ListView，定义它的id是"@+id/mylist"。实际上，如果没有特别的需求，就可以利用系统定义的id，类似下面的样子。

 
 
<ListView 
 
    android:id="@android:id/list" 
 
    android:layout_width="fill_parent" 
 
    android:layout_height="fill_parent"/> 
  

在xml文件中引用系统的id，只需要加上“@android:”前缀即可。如果是在Java代码中使用系统资源，和使用自己的资源基本上是一样的。不同的是，需要使用android.R类来使用系统的资源，而不是使用应用程序指定的R类。这里如果要获取ListView可以使用android.R.id.list来获取。

2）利用系统的图片资源

假设我们在应用程序中定义了一个menu，xml文件如下。

 
 
<?xml version="1.0" encoding="utf-8"?> 
 
<menu xmlns:android="http://schemas.android.com/apk/res/android"> 
 
    <item 
 
        android:id="@+id/menu_attachment" 
 
        android:title="附件" 
 
        android:icon="@android:drawable/ic_menu_attachment" /> 
 
</menu> 
  

其中代码片段android:icon="@android:drawable/ic_menu_attachment"本来是想引用系统中已有的Menu里的“附件”的图标。但是在Build工程以后，发现出现了错误。提示信息如下：

 
 
error: Error: Resource is not public. (at 'icon' with value '@android:drawable/ic_menu_attachment'). 
  

从错误的提示信息大概可以看出，由于该资源没有被公开，所以无法在我们的应用中直接引用。既然这样的话，我们就可以在Android SDK中找到相应的图片资源，直接拷贝到我们的工程目录中，然后使用类似android:icon="@drawable/ic_menu_attachment"的代码片段进行引用。

这样做的好处，一个是美工不需要重复的做一份已有的图片了，可以节约不少工时；另一个是能保证我们的应用程序的风格与系统一致。

经验分享： Android中没有公开的资源，在xml中直接引用会报错。除了去找到对应资源并拷贝到我们自己的应用目录下使用以外，我们还可以将引用“@android”改成“@*android”解决。比如上面引用的附件图标，可以修改成下面的代码。 android:icon="@*android:drawable/ic_menu_attachment" 修改后，再次Build工程，就不会报错了。

3）利用系统的字符串资源

假设我们要实现一个Dialog，Dialog上面有“确定”和“取消”按钮。就可以使用下面的代码直接使用Android系统自带的字符串。

 
 
<LinearLayout 
 
       android:orientation="horizontal" 
 
       android:layout_width="fill_parent"  
 
       android:layout_height="wrap_content"> 
 
       <Button 
 
           android:id="@+id/yes"  
 
           android:layout_width="fill_parent" 
 
           android:layout_height="wrap_content" 
 
           android:layout_weight="1.0" 
 
           android:text="@android:string/yes"/> 
 
       <Button 
 
           android:id="@+id/no"  
 
           android:layout_width="fill_parent" 
 
           android:layout_height="wrap_content" 
 
           android:layout_weight="1.0" 
 
           android:text="@android:string/no"/> 
 
   </LinearLayout> 

如果使用系统的字符串，默认就已经支持多语言环境了。如上述代码，直接使用了@android:string/yes和@android:string/no，在简体中文环境下会显示“确定”和“取消”，在英文环境下会显示“OK”和“Cancel”。

4）利用系统的Style

假设布局文件中有一个TextView，用来显示窗口的标题，使用中等大小字体。可以使用下面的代码片段来定义TextView的Style。

 
 
<TextView 
 
        android:id="@+id/title" 
 
        android:layout_width="wrap_content" 
 
        android:layout_height="wrap_content" 
 
        android:textAppearance="?android:attr/textAppearanceMedium" /> 
  
 
  

其中android:textAppearance="?android:attr/textAppearanceMedium"就是使用系统的style。需要注意的是，使用系统的style，需要在想要使用的资源前面加“?android:”作为前缀，而不是“@android:”。

5）利用系统的颜色定义

除了上述的各种系统资源以外，还可以使用系统定义好的颜色。在项目中最常用的，就是透明色的使用。代码片段如下。

 
 
android:background ="@android:color/transparent" 
  

经验分享： Android系统本身有很多资源在应用中都可以直接使用，具体的，可以进入android-sdk的相应文件夹中去查看。例如：可以进入$android-sdk$\platforms\android-8\data\res，里面的系统资源就一览无余了。 开发者需要花一些时间去熟悉这些资源，特别是图片资源和各种Style资源，这样在开发过程中，能够想到有相关资源并且直接拿来使用。

五：Android开发优化之——对界面UI的优化（2）

在一个应用程序中，一般都会存在多个Activity，每个Activity对应着一个UI布局文件。一般来说，为了保持不同窗口之间的风格统一，在这些UI布局文件中，几乎肯定会用到很多相同的布局。如果我们在每个xml文件中都把相同的布局都重写一遍，一个是代码冗余，可读性很差；另一个是修改起来比较麻烦，对后期的修改和维护非常不利。

在一个应用程序中，一般都会存在多个Activity，每个Activity对应着一个UI布局文件。一般来说，为了保持不同窗口之间的风格统一，在这些UI布局文件中，几乎肯定会用到很多相同的布局。如果我们在每个xml文件中都把相同的布局都重写一遍，一个是代码冗余，可读性很差；另一个是修改起来比较麻烦，对后期的修改和维护非常不利。所以，一般情况下，我们需要把相同布局的代码单独写成一个模块，然后在用到的时候，可以通过<include /> 标签来重用layout的代码。

常见的，有的应用在最上方会有一个标题栏。类似下图所示。

图 标题栏的示例

 

如果项目中大部分Activity的布局都包含这样的标题栏，就可以把标题栏的布局单独写成一个xml文件。

 
 
<RelativeLayout 
 
    android:layout_width="fill_parent" 
 
    android:layout_height="wrap_content" 
 
    android:gravity="center" 
 
    android:background="@drawable/navigator_bar_bg" 
 
    xmlns:android="http://schemas.android.com/apk/res/android"> 
 
    <TextView 
 
        android:id="@android:id/title" 
 
        android:layout_width="fill_parent" 
 
        android:layout_height="wrap_content" 
 
        android:layout_centerVertical="true" 
 
        android:gravity="center" 
 
        android:hint="title" 
 
        android:textAppearance="?android:attr/textAppearanceMedium" /> 
 
    <ImageView 
 
        android:id="@android:id/closeButton" 
 
        android:layout_width="wrap_content" 
 
        android:layout_height="wrap_content" 
 
        android:layout_alignParentRight="true" 
 
        android:src="@drawable/close" /> 
 
</RelativeLayout> 
  

我们将上面的xml文件命名为“navigator_bar.xml”，其它需要标题栏的Activity的xml布局文件就可以直接引用此文件了。

 
 
<include layout="@layout/navigator_bar" /> 
  

 

经验分享： 一般情况下，在项目的初期就能够大致确定整体UI的风格。所以早期的时候就可以做一些规划，将通用的模块先写出来。 下面是可能可以抽出的共用的布局： 1）背景。有的应用在不同的界面里会用到统一的背景。后期可能会经常修改默认背景，所以可以将背景做成一个通用模块。 2）头部的标题栏。如果应用有统一的头部标题栏，就可以抽取出来。 3）底部的导航栏。如果应用有导航栏，而且大部分的Activity的底部导航栏是相同的，就可以将导航栏写成一个通用模块。 4）ListView。大部分应用都会用到ListView展示多条数据。项目后期可能会经常调整ListView的风格，所以将ListView作为一个通用的模块比较好。

 六：Android开发优化之——对界面UI的优化（3）

有时候，我们的页面中可能会包含一些布局，这些布局默认是隐藏的，当用户触发了一定的操作之后，隐藏的布局才会显示出来。比如，我们有一个Activity用来显示好友的列表，当用户点击Menu中的“导入”以后，在当前的Activity中才会显示出一个导入好友的布局界面。从需求的角度来说，这个导入功能，一般情况下用户是不使用的。即大部分时候，导入好友的布局都不会显示出来。这个时候，就可以使用延迟加载的功能。

有时候，我们的页面中可能会包含一些布局，这些布局默认是隐藏的，当用户触发了一定的操作之后，隐藏的布局才会显示出来。比如，我们有一个Activity用来显示好友的列表，当用户点击Menu中的“导入”以后，在当前的Activity中才会显示出一个导入好友的布局界面。从需求的角度来说，这个导入功能，一般情况下用户是不使用的。即大部分时候，导入好友的布局都不会显示出来。这个时候，就可以使用延迟加载的功能。

ViewStub是一个隐藏的，不占用内存空间的视图对象，它可以在运行时延迟加载布局资源文件。当ViewStub被设置为可见，或者调用inflate()函数时，才会真的去加载这个布局资源文件。该ViewStub在加载视图时会在父容器中替换它本身。因此，ViewStub会一直存在于视图中，直到调用setVisibility(int)或者inflate()为止。ViewStub的布局参数会随着加载的视图数一同被添加到ViewStub父容器。同样，也可以通过使用inflated Id属性来定义或重命名要加载的视图对象的Id值。

请参考下面的代码片段。

 
 
<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" /> 
  

通过“stub_import”这个id可以找到被定义的ViewStub对象。加载布局资源文件“progress_overlay”后，ViewStub对象从其父容器中移除。可以通过“panel_import”这个id找到由布局资源“progress_overlay”创建的View。

执行加载布局资源文件的推荐方式如下：

 
 
((ViewStub) findViewById(R.id.stub_import)).setVisibility(View.VISIBLE); 
 
// 或者 
 
View importPanel = ((ViewStub) findViewById(R.id.stub_import)).inflate(); 
  

当inflate()被调用, 这个ViewStub被加载的视图所替代，并且返回这个视图对象。这使得应用程序不需要额外执行findViewById()来获取加载视图的引用。

经验分享： 利用ViewStub可以与xml文件里面指定的布局资源文件关联起来，让布局资源文件在需要使用的时候再加载上去。什么时候用什么时候才加载，不用在开始启动的时候一次加载。这样做既可以加快应用的启动速度，又可以节省内存资源。

 

七：Android开发优化之——从代码角度进行优化

通常我们写程序，都是在项目计划的压力下完成的，此时完成的代码可以完成具体业务逻辑，但是性能不一定是最优化的。一般来说，优秀的程序员在写完代码之后都会不断的对代码进行重构。重构的好处有很多，其中一点，就是对代码进行优化，提高软件的性能。下面我们就从几个方面来了解Android开发过程中的代码优化。

通常我们写程序，都是在项目计划的压力下完成的，此时完成的代码可以完成具体业务逻辑，但是性能不一定是最优化的。一般来说，优秀的程序员在写完代码之后都会不断的对代码进行重构。重构的好处有很多，其中一点，就是对代码进行优化，提高软件的性能。下面我们就从几个方面来了解Android开发过程中的代码优化。

1）静态变量引起内存泄露

在代码优化的过程中，我们需要对代码中的静态变量特别留意。静态变量是类相关的变量，它的生命周期是从这个类被声明，到这个类彻底被垃圾回收器回收才会被销毁。所以，一般情况下，静态变量从所在的类被使用开始就要一直占用着内存空间，直到程序退出。如果不注意，静态变量引用了占用大量内存的资源，造成垃圾回收器无法对内存进行回收，就可能造成内存的浪费。

先来看一段代码，这段代码定义了一个Activity。

  
  
private static Resources mResources;   
 
@Override 
 
protected void onCreate(Bundle state) { 
 
super.onCreate(state); 
 
if (mResources == null) { 
 
    mResources = this.getResources(); 
 
    } 
 
} 
  

这段代码中有一个静态的Resources对象。代码片段mResources = this.getResources()对Resources对象进行了初始化。这时Resources对象拥有了当前Activity对象的引用，Activity又引用了整个页面中所有的对象。

如果当前的Activity被重新创建（比如横竖屏切换，默认情况下整个Activity会被重新创建），由于Resources引用了第一次创建的Activity，就会导致第一次创建的Activity不能被垃圾回收器回收，从而导致第一次创建的Activity中的所有对象都不能被回收。这个时候，一部分内存就浪费掉了。

经验分享： 在实际项目中，我们经常会把一些对象的引用加入到集合中，如果这个集合是静态的话，就需要特别注意了。当不需要某对象时，务必及时把它的引用从集合中清理掉。或者可以为集合提供一种更新策略，及时更新整个集合，这样可以保证集合的大小不超过某值，避免内存空间的浪费。

2）使用Application的Context

在Android中，Application Context的生命周期和应用的生命周期一样长，而不是取决于某个Activity的生命周期。如果想保持一个长期生命的对象，并且这个对象需要一个Context，就可以使用Application对象。可以通过调用Context.getApplicationContext()方法或者Activity.getApplication()方法来获得Application对象。

依然拿上面的代码作为例子。可以将代码修改成下面的样子。

  
  
private static Resources mResources;   
 
@Override 
 
protected void onCreate(Bundle state) { 
 
super.onCreate(state); 
 
if (mResources == null) { 
 
    // mResources = this.getResources(); 
 
    mResources = this.getApplication().getResources(); 
 
    } 
 
} 
  

在这里将this.getResources()修改为this.getApplication().getResources()。修改以后，Resources对象拥有的是Application对象的引用。如果Activity被重新创建，第一次创建的Activity就可以被回收了。

3）及时关闭资源

Cursor是Android查询数据后得到的一个管理数据集合的类。正常情况下，如果我们没有关闭它，系统会在回收它时进行关闭，但是这样的效率特别低。如果查询得到的数据量较小时还好，如果Cursor的数据量非常大，特别是如果里面有Blob信息时，就可能出现内存问题。所以一定要及时关闭Cursor。

下面给出一个通用的使用Cursor的代码片段。

  
  
Cursor cursor = null; 
 
try{ 
 
    cursor = mContext.getContentResolver().query(uri,null,null,null,null); 
 
    if (cursor != null) { 
 
        cursor.moveToFirst(); 
 
        // 处理数据 
 
    } 
 
} catch (Exception e){ 
 
    e.printStatckTrace(); 
 
} finally { 
 
    if (cursor != null){ 
 
        cursor.close(); 
 
    } 
 
} 
  

即对异常进行捕获，并且在finally中将cursor关闭。

同样的，在使用文件的时候，也要及时关闭。

4）使用Bitmap及时调用recycle()

前面的章节讲过，在不使用Bitmap对象时，需要调用recycle()释放内存，然后将它设置为null。虽然调用recycle()并不能保证立即释放占用的内存，但是可以加速Bitmap的内存的释放。

在代码优化的过程中，如果发现某个Activity用到了Bitmap对象，却没有显式的调用recycle()释放内存，则需要分析代码逻辑，增加相关代码，在不再使用Bitmap以后调用recycle()释放内存。

5）对Adapter进行优化

下面以构造ListView的BaseAdapter为例说明如何对Adapter进行优化。

在BaseAdapter类中提供了如下方法：

  
  
public View getView(int position, View convertView, ViewGroup parent) 
 

当ListView列表里的每一项显示时，都会调用Adapter的getView方法返回一个View，

来向ListView提供所需要的View对象。

下面是一个完整的getView()方法的代码示例。

  
  
public View getView(int position, View convertView, ViewGroup parent) { 
 
ViewHolder holder; 
 
if (convertView == null) { 
 
    convertView = mInflater.inflate(R.layout.list_item, null); 
 
    holder = new ViewHolder(); 
 
    holder.text = (TextView) convertView.findViewById(R.id.text); 
 
    convertView.setTag(holder); 
 
} else { 
 
    holder = (ViewHolder) convertView.getTag(); 
 
} 
 
holder.text.setText("line" + position); 
 
return convertView; 
 
} 
 
  
 
private class ViewHolder { 
 
TextView text; 
 
} 
  

当向上滚动ListView时，getView()方法会被反复调用。getView()的第二个参数convertView是被缓存起来的List条目中的View对象。当ListView滑动的时候，getView可能会直接返回旧的convertView。这里使用了convertView和ViewHolder，可以充分利用缓存，避免反复创建View对象和TextView对象。

如果ListView的条目只有几个，这种技巧并不能带来多少性能的提升。但是如果条目有几百甚至几千个，使用这种技巧只会创建几个convertView和ViewHolder（取决于当前界面能够显示的条目数），性能的差别就非常非常大了。

6）代码“微优化”

当今时代已经进入了“微时代”。这里的“微优化”指的是代码层面的细节优化，即不改动代码整体结构，不改变程序原有的逻辑。尽管Android使用的是Dalvik虚拟机，但是传统的Java方面的代码优化技巧在Android开发中也都是适用的。

下面简要列举一部分。因为一般Java开发者都能够理解，就不再做具体的代码说明。

创建新的对象都需要额外的内存空间，要尽量减少创建新的对象。

将类、变量、方法等等的可见性修改为最小。

针对字符串的拼接，使用StringBuffer替代String。

不要在循环当中声明临时变量，不要在循环中捕获异常。

如果对于线程安全没有要求，尽量使用线程不安全的集合对象。

使用集合对象，如果事先知道其大小，则可以在构造方法中设置初始大小。

文件读取操作需要使用缓存类，及时关闭文件。

慎用异常，使用异常会导致性能降低。

如果程序会频繁创建线程，则可以考虑使用线程池。

经验分享： 代码的微优化有很多很多东西可以讲，小到一个变量的声明，大到一段算法。尤其在代码Review的过程中，可能会反复审查代码是否可以优化。不过我认为，代码的微优化是非常耗费时间的，没有必要从头到尾将所有代码都优化一遍。开发者应该根据具体的业务逻辑去专门针对某部分代码做优化。比如应用中可能有一些方法会被反复调用，那么这部分代码就值得专门做优化。其它的代码，需要开发者在写代码过程中去注意。

八：Android之ListView原理学习与优化总结

利用ViewHolder来优化ListView数据加载，仅仅就此一条吗？其实不是的，首先，想要优化ListView就得先了解ListView加载数据原理，这是前提，但是小马在这个地方先做一些简单的补充,大家一定仔细看下，保证会有收获的。

AD：51CTO 网+ 第十二期沙龙：大话数据之美_如何用数据驱动用户体验

在整理前几篇文章的时候有朋友提出写一下ListView的性能优化方面的东西，这个问题也是小马在面试过程中被别人问到的…..今天小马就借此机会来整理下，网上类似的资料蛮多的，倒不如自己写一篇，记录在这个地方，供自己以后使用，不用再翻来翻去的找了，用自己写的…呵呵，不多讲其它了，说起优化我想大家第一反应跟小马一样吧？想到利用ViewHolder来优化ListView数据加载，仅仅就此一条吗？其实不是的，首先，想要优化ListView就得先了解ListView加载数据原理，这是前提，但是小马在这个地方先做一些简单的补充,大家一定仔细看下，保证会有收获的：

列表的显示需要三个元素：

1. ListVeiw:  用来展示列表的View。

2. 适配器 : 用来把数据映射到ListView上

3. 数据:    具体的将被映射的字符串，图片，或者基本组件。 

根据列表的适配器类型，列表分为三种，ArrayAdapter，SimpleAdapter和SimpleCursorAdapter，这三种适配器的使用大家可学习下官网上面的使用或者自行百度谷歌，一堆DEMO！！！其中以ArrayAdapter最为简单，只能展示一行字。SimpleAdapter有最好的扩充性，可以自定义出各种效果。SimpleCursorAdapter可以认为是SimpleAdapter对数据库的简单结合，可以方便的把数据库的内容以列表的形式展示出来。

系统要绘制ListView了，他首先用getCount（）函数得到要绘制的这个列表的长度，然后开始绘制第一行，怎么绘制呢？调用getView()函数。在这个函数里面首先获得一个View（这个看实际情况，如果是一个简单的显示则是View，如果是一个自定义的里面包含很多控件的时候它其实是一个ViewGroup），然后再实例化并设置各个组件及其数据内容并显示它。好了，绘制完这一行了。那 再绘制下一行，直到绘完为止，前面这些东西做下铺垫，继续…….

现在我们再来了解ListView加载数据的原理，有了这方面的了解后再说优化才行，下面先跟大家一起来看下ListView加载数据的基本原理小马就直接写了：

ListView的工作原理如下：

ListView 针对每个item，要求 adapter “返回一个视图” (getView)，也就是说ListView在开始绘制的时候，系统首先调用getCount（）函数，根据他的返回值得到ListView的长度，然后根据这个长度，调用getView（）一行一行的绘制ListView的每一项。如果你的getCount（）返回值是0的话，列表一行都不会显示，如果返回1，就只显示一行。返回几则显示几行。如果我们有几千几万甚至更多的item要显示怎么办？为每个Item创建一个新的View？不可能！！！实际上Android早已经缓存了这些视图，大家可以看下下面这个截图来理解下，这个图是解释ListView工作原理的最经典的图了大家可以收藏下，不懂的时候拿来看看，加深理解，其实Android中有个叫做Recycler的构件，顺带列举下与Recycler相关的已经由Google做过N多优化过的东东比如：AbsListView.RecyclerListener、ViewDebug.RecyclerTraceType等等，要了解的朋友自己查下，不难理解，下图是ListView加载数据的工作原理（原理图看不清楚的点击后看大图）：

下面简单说下上图的原理：

1. 如果你有几千几万甚至更多的选项(item)时，其中只有可见的项目存在内存（内存内存哦，说的优化就是说在内存中的优化！！！）中，其他的在Recycler中
2. ListView先请求一个type1视图(getView)然后请求其他可见的项目。convertView在getView中是空(null)的
3. 当item1滚出屏幕，并且一个新的项目从屏幕低端上来时，ListView再请求一个type1视图。convertView此时不是空值了，它的值是item1。你只需设定新的数据然后返回convertView，不必重新创建一个视图
4. 下面来看下小马从网上找来的示例代码,网址搞丢了，只有一个word文档，只能 copy过来，不然直接贴网址，结合上面的原理图一起加深理解，如下：

  
  
public class MultipleItemsList extends ListActivity {    
 private MyCustomAdapter mAdapter;     
@Override     
public void onCreate(Bundle savedInstanceState) {         
super.onCreate(savedInstanceState);        
 mAdapter = new MyCustomAdapter();         
for (int i = 0; i < 50; i++) {            
 mAdapter.addItem("item " + i);         
}         
setListAdapter(mAdapter);     
}     
private class MyCustomAdapter extends BaseAdapter {        
private ArrayList mData = new ArrayList();        
 private LayoutInflater mInflater;          
public MyCustomAdapter() {             
mInflater = (LayoutInflater)getSystemService(Context.LAYOUT_INFLATER_SERVICE);        
 }        
public void addItem(final String item) {             
mData.add(item);            
notifyDataSetChanged();        
 }         
 
@Override        
public int getCount() {             
return mData.size();        
 }        
 @Override        
 public String getItem(int position) {            
 return mData.get(position);         
}          
@Override       
 public long getItemId(int position) {           
 return position;        
}          
@Override        
public View getView(int position, View convertView, ViewGroup parent) {            
 System.out.println("getView " + position + " " + convertView);            
ViewHolder holder = null;             
if (convertView == null) {                 
convertView = mInflater.inflate(R.layout.item1, null);                 
holder = new ViewHolder();                
holder.textView = (TextView)convertView.findViewById(R.id.text);                
 convertView.setTag(holder);             
} else {                
 holder = (ViewHolder)convertView.getTag();         
   }            
 holder.textView.setText(mData.get(position));            
 return convertView;       
 }    }    
 public static class ViewHolder {        
 public TextView textView;    
 } }  

执行程序，查看日志:

getView 被调用 9 次 ，convertView 对于所有的可见项目是空值（如下）:

然后稍微向下滚动List，直到item10出现：

      convertView仍然是空值，因为recycler中没有视图（item1的边缘仍然可见，在顶端）再滚动列表，继续滚动：

     convertView不是空值了！item1离开屏幕到Recycler中去了，然后item11被创建，再滚动下：

此时的convertView非空了，在item11离开屏幕之后，它的视图(…0f8)作为convertView容纳item12了,好啦，结合以上原理，下面来看看今天最主要的话题，主角ListView的优化：

            首先，这个地方先记两个ListView优化的一个小点：

                      1. ExpandableListView 与 ListActivity 由官方提供的，里面要使用到的ListView是已经经过优化的ListView，如果大家的需求可以用Google自带的ListView满足的的话尽量用官方的，绝对没错！

                      2.其次，像小马前面讲的，说ListView优化，其实并不是指其它的优化，就是内存是的优化，提到内存…（想到OOM，折腾了我不少时间），很多很多，先来写下，如果我们的ListView中的选项仅仅是一些简单的TextView的话，就好办啦，消耗不了多少的，但如果你的Item是自定义的Item的话，例如你的自定义Item布局ViewGroup中包含：按钮、图片、flash、CheckBox、RadioButton等一系列你能想到的控件的话， 你要在getView中单单使用文章开头提到的ViewHolder是远远不够的，如果数据过多，加载的图片过多过大，你BitmapFactory.decode的猛多的话，OOM搞死你，这个地方再警告下大家，是警告……….也提醒下自己：

                        小马碰到的问题大家应该也都碰到过的，自定义的ListView项乱序问题，我很天真的在getView()中强制清除了下ListView的缓存数据convertView，也就是convertView = null了，虽然当时是解决了这个问题让其它每次重绘，但是犯了大错了，如果数据太多的话，出现最最恶心的错，手机卡死或强制关机，关机啊哥哥们……O_O，客户杀了我都有可能，但大家以后别犯这样的错了，单单使用清除缓存convertView是解决不了实际问题的，继续……

下面是小记：图片用完了正确的释放… 

  
  
if(!bmp.isRecycle() ){        
bmp.recycle()   //回收图片所占的内存 
 system.gc()  //提醒系统及时回收 
}  

下面来列举下真正意义上的优化吧：

1.  ViewHolder   Tag 必不可少，这个不多说！
2. 如果自定义Item中有涉及到图片等等的，一定要狠狠的处理图片，图片占的内存是ListView项中最恶心的，处理图片的方法大致有以下几种：
   2.1：不要直接拿个路径就去循环decodeFile();这是找死….用Option保存图片大小、不要加载图片到内存去;
   2.2:  拿到的图片一定要经过边界压缩
   2.3:在ListView中取图片时也不要直接拿个路径去取图片，而是以WeakReference（使用WeakReference代替强引用。比如可以使        用WeakReference mContextRef）、SoftReference、WeakHashMap等的来存储图片信息，是图片信息不是图片哦！
   2.4:在getView中做图片转换时，产生的中间变量一定及时释放，用以下形式：
3. 尽量避免在BaseAdapter中使用static 来定义全局静态变量，我以为这个没影响 ，这个影响很大，static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（比如Context的情况最多），这时就要尽量避免使用了..
4. 如果为了满足需求下必须使用Context的话：Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题
5. 尽量避免在ListView适配器中使用线程，因为线程产生内存泄露的主要原因在于线程生命周期的不可控制
6.  记下小马自己的错误：
7. 之前使用的自定义ListView中适配数据时使用AsyncTask自行开启线程的，这个比用Thread更危险，因为Thread只有在run函数不 结束时才出现这种内存泄露问题，然而AsyncTask内部的实现机制是运用了线程执行池（ThreadPoolExcutor，要想了解这个类的话大家加下我们的Android开发群五号，因为其它群的存储空间快满了，所以只上传到五群里了，看下小马上传的Gallery源码，你会对线程执行池、软、弱、强引用有个更深入的认识）,这个类产生的Thread对象的生命周期是不确定的，是应用程序无法控制的，因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。这个问题的解决办法小马当时网上查到了记在txt里了，如下： 
   6.1：将线程的内部类，改为静态内部类。
   6.2：在线程内部采用弱引用保存Context引用
   示例代码如下：
    

       
       
   public abstract class WeakAsyncTask extends  AsyncTask {        
    protected WeakReference mTarget;            
   public WeakAsyncTask(WeakTarget target) {             
   mTarget = new WeakReference(target);         
   }                  
   @Override        
   protected final void onPreExecute() {            
   final WeakTarget target = mTarget.get();             
   if (target != null) {                 
   this.onPreExecute(target);             
   }        
    
   }                   
    @Override         
   protected final Result doInBackground(Params... params) {             
   final WeakTarget target = mTarget.get();            
   if (target != null) {                 
   return this.doInBackground(target, params);             
   } else {                
   return null;             
   }         
   }                    
   @Override        
   protected final void onPostExecute(Result result) {            
    final WeakTarget target = mTarget.get();             
   if (target != null) {                 
   this.onPostExecute(target, result);           
   }        
   }         
    protected void onPreExecute(WeakTarget target) {            
   // No default action         }           
    protected abstract Result doInBackground(WeakTarget target, Params... params);           
   protected void onPostExecute(WeakTarget target, Result result) {           
    // No default action         }     }  

好啦，ListVIew的优化问题，小马就暂时先理解记录这么多了，如果朋友们有什么更好的优化建议什么的，留言指点下小马，一定会及时添加到进来的，先谢谢啦，其实在ListView适配器的getView（）方法中可以做很多的优化，我记得还有可以优化findViewById()这个方法来寻址资源信息效率的方法，资料太多了，小马发现了会及时更新的哦，天太晚了，先休息了，吼吼，大家加油，一起努力学习！！！O_O

九：Android开发优化之——对Bitmap的内存优化

在Android应用里，最耗费内存的就是图片资源。而且在Android系统中，读取位图Bitmap时，分给虚拟机中的图片的堆栈大小只有8M，如果超出了，就会出现OutOfMemory异常。所以，对于图片的内存优化，是Android应用开发中比较重要的内容。

在Android应用里，最耗费内存的就是图片资源。而且在Android系统中，读取位图Bitmap时，分给虚拟机中的图片的堆栈大小只有8M，如果超出了，就会出现OutOfMemory异常。所以，对于图片的内存优化，是Android应用开发中比较重要的内容。

1) 要及时回收Bitmap的内存

Bitmap类有一个方法recycle()，从方法名可以看出意思是回收。这里就有疑问了，Android系统有自己的垃圾回收机制，可以不定期的回收掉不使用的内存空间，当然也包括Bitmap的空间。那为什么还需要这个方法呢？

Bitmap类的构造方法都是私有的，所以开发者不能直接new出一个Bitmap对象，只能通过BitmapFactory类的各种静态方法来实例化一个Bitmap。仔细查看BitmapFactory的源代码可以看到，生成Bitmap对象最终都是通过JNI调用方式实现的。所以，加载Bitmap到内存里以后，是包含两部分内存区域的。简单的说，一部分是Java部分的，一部分是C部分的。这个Bitmap对象是由Java部分分配的，不用的时候系统就会自动回收了，但是那个对应的C可用的内存区域，虚拟机是不能直接回收的，这个只能调用底层的功能释放。所以需要调用recycle()方法来释放C部分的内存。从Bitmap类的源代码也可以看到，recycle()方法里也的确是调用了JNI方法了的。

那如果不调用recycle()，是否就一定存在内存泄露呢？也不是的。Android的每个应用都运行在独立的进程里，有着独立的内存，如果整个进程被应用本身或者系统杀死了，内存也就都被释放掉了，当然也包括C部分的内存。

Android对于进程的管理是非常复杂的。简单的说，Android系统的进程分为几个级别，系统会在内存不足的情况下杀死一些低优先级的进程，以提供给其它进程充足的内存空间。在实际项目开发过程中，有的开发者会在退出程序的时候使用Process.killProcess(Process.myPid())的方式将自己的进程杀死，但是有的应用仅仅会使用调用Activity.finish()方法的方式关闭掉所有的Activity。

经验分享： Android手机的用户，根据习惯不同，可能会有两种方式退出整个应用程序：一种是按Home键直接退到桌面；另一种是从应用程序的退出按钮或者按Back键退出程序。那么从系统的角度来说，这两种方式有什么区别呢？按Home键，应用程序并没有被关闭，而是成为了后台应用程序。按Back键，一般来说，应用程序关闭了，但是进程并没有被杀死，而是成为了空进程（程序本身对退出做了特殊处理的不考虑在内）。 Android系统已经做了大量进程管理的工作，这些已经可以满足用户的需求。个人建议，应用程序在退出应用的时候不需要手动杀死自己所在的进程。对于应用程序本身的进程管理，交给Android系统来处理就可以了。应用程序需要做的，是尽量做好程序本身的内存管理工作。

一般来说，如果能够获得Bitmap对象的引用，就需要及时的调用Bitmap的recycle()方法来释放Bitmap占用的内存空间，而不要等Android系统来进行释放。

下面是释放Bitmap的示例代码片段。

  
  
// 先判断是否已经回收 
 
if(bitmap != null && !bitmap.isRecycled()){   
 
        // 回收并且置为null 
 
        bitmap.recycle();   
 
        bitmap = null;   
 
}   
 
System.gc(); 
  

从上面的代码可以看到，bitmap.recycle()方法用于回收该Bitmap所占用的内存，接着将bitmap置空，最后使用System.gc()调用一下系统的垃圾回收器进行回收，可以通知垃圾回收器尽快进行回收。这里需要注意的是，调用System.gc()并不能保证立即开始进行回收过程，而只是为了加快回收的到来。

如何调用recycle()方法进行回收已经了解了，那什么时候释放Bitmap的内存比较合适呢？一般来说，如果代码已经不再需要使用Bitmap对象了，就可以释放了。释放内存以后，就不能再使用该Bitmap对象了，如果再次使用，就会抛出异常。所以一定要保证不再使用的时候释放。比如，如果是在某个Activity中使用Bitmap，就可以在Activity的onStop()或者onDestroy()方法中进行回收。

2) 捕获异常

因为Bitmap是吃内存大户，为了避免应用在分配Bitmap内存的时候出现OutOfMemory异常以后Crash掉，需要特别注意实例化Bitmap部分的代码。通常，在实例化Bitmap的代码中，一定要对OutOfMemory异常进行捕获。

以下是代码示例。

  
  
Bitmap bitmap = null; 
 
try { 
 
    // 实例化Bitmap 
 
    bitmap = BitmapFactory.decodeFile(path); 
 
} catch (OutOfMemoryError e) { 
 
    // 
 
} 
 
if (bitmap == null) { 
 
    // 如果实例化失败 返回默认的Bitmap对象 
 
    return defaultBitmapMap; 
 
} 
  

这里对初始化Bitmap对象过程中可能发生的OutOfMemory异常进行了捕获。如果发生了OutOfMemory异常，应用不会崩溃，而是得到了一个默认的Bitmap图。

经验分享： 很多开发者会习惯性的在代码中直接捕获Exception。但是对于OutOfMemoryError来说，这样做是捕获不到的。因为OutOfMemoryError是一种Error，而不是Exception。在此仅仅做一下提醒，避免写错代码而捕获不到OutOfMemoryError。

3) 缓存通用的Bitmap对象

有时候，可能需要在一个Activity里多次用到同一张图片。比如一个Activity会展示一些用户的头像列表，而如果用户没有设置头像的话，则会显示一个默认头像，而这个头像是位于应用程序本身的资源文件中的。

如果有类似上面的场景，就可以对同一Bitmap进行缓存。如果不进行缓存，尽管看到的是同一张图片文件，但是使用BitmapFactory类的方法来实例化出来的Bitmap，是不同的Bitmap对象。缓存可以避免新建多个Bitmap对象，避免内存的浪费。

经验分享： Web开发者对于缓存技术是很熟悉的。其实在Android应用开发过程中，也会经常使用缓存的技术。这里所说的缓存有两个级别，一个是硬盘缓存，一个是内存缓存。比如说，在开发网络应用过程中，可以将一些从网络上获取的数据保存到SD卡中，下次直接从SD卡读取，而不从网络中读取，从而节省网络流量。这种方式就是硬盘缓存。再比如，应用程序经常会使用同一对象，也可以放到内存中缓存起来，需要的时候直接从内存中读取。这种方式就是内存缓存。

4) 压缩图片

如果图片像素过大，使用BitmapFactory类的方法实例化Bitmap的过程中，需要大于8M的内存空间，就必定会发生OutOfMemory异常。这个时候该如何处理呢？如果有这种情况，则可以将图片缩小，以减少载入图片过程中的内存的使用，避免异常发生。

使用BitmapFactory.Options设置inSampleSize就可以缩小图片。属性值inSampleSize表示缩略图大小为原始图片大小的几分之一。即如果这个值为2，则取出的缩略图的宽和高都是原始图片的1/2，图片的大小就为原始大小的1/4。

如果知道图片的像素过大，就可以对其进行缩小。那么如何才知道图片过大呢？

使用BitmapFactory.Options设置inJustDecodeBounds为true后，再使用decodeFile()等方法，并不会真正的分配空间，即解码出来的Bitmap为null，但是可计算出原始图片的宽度和高度，即options.outWidth和options.outHeight。通过这两个值，就可以知道图片是否过大了。

  
  
BitmapFactory.Options opts = new BitmapFactory.Options(); 
 
    // 设置inJustDecodeBounds为true 
 
    opts.inJustDecodeBounds = true; 
 
    // 使用decodeFile方法得到图片的宽和高 
 
    BitmapFactory.decodeFile(path, opts); 
 
    // 打印出图片的宽和高 
 
    Log.d("example", opts.outWidth + "," + opts.outHeight); 
  

在实际项目中，可以利用上面的代码，先获取图片真实的宽度和高度，然后判断是否需要跑缩小。如果不需要缩小，设置inSampleSize的值为1。如果需要缩小，则动态计算并设置inSampleSize的值，对图片进行缩小。需要注意的是，在下次使用BitmapFactory的decodeFile()等方法实例化Bitmap对象前，别忘记将opts.inJustDecodeBound设置回false。否则获取的bitmap对象还是null。

经验分享： 如果程序的图片的来源都是程序包中的资源，或者是自己服务器上的图片，图片的大小是开发者可以调整的，那么一般来说，就只需要注意使用的图片不要过大，并且注意代码的质量，及时回收Bitmap对象，就能避免OutOfMemory异常的发生。 如果程序的图片来自外界，这个时候就特别需要注意OutOfMemory的发生。一个是如果载入的图片比较大，就需要先缩小；另一个是一定要捕获异常，避免程序Crash。

十：Android开发优化之——使用软引用和弱引用

Java从JDK1.2版本开始，就把对象的引用分为四种级别，从而使程序能更加灵活的控制对象的生命周期。这四种级别由高到低依次为：强引用、软引用、弱引用和虚引用。

这里重点介绍一下软引用和弱引用。

如果一个对象只具有软引用，那么如果内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。

如果一个对象只具有弱引用，那么在垃圾回收器线程扫描的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。弱引用也可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

弱引用与软引用的根本区别在于：只具有弱引用的对象拥有更短暂的生命周期，可能随时被回收。而只具有软引用的对象只有当内存不够的时候才被回收，在内存足够的时候，通常不被回收。

在java.lang.ref包中提供了几个类：SoftReference类、WeakReference类和PhantomReference类，它们分别代表软引用、弱引用和虚引用。ReferenceQueue类表示引用队列，它可以和这三种引用类联合使用，以便跟踪Java虚拟机回收所引用的对象的活动。

在Android应用的开发中，为了防止内存溢出，在处理一些占用内存大而且声明周期较长的对象时候，可以尽量应用软引用和弱引用技术。

下面以使用软引用为例来详细说明。弱引用的使用方式与软引用是类似的。

假设我们的应用会用到大量的默认图片，比如应用中有默认的头像，默认游戏图标等等，这些图片很多地方会用到。如果每次都去读取图片，由于读取文件需要硬件操作，速度较慢，会导致性能较低。所以我们考虑将图片缓存起来，需要的时候直接从内存中读取。但是，由于图片占用内存空间比较大，缓存很多图片需要很多的内存，就可能比较容易发生OutOfMemory异常。这时，我们可以考虑使用软引用技术来避免这个问题发生。

首先定义一个HashMap，保存软引用对象。

  
  
private Map<String, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>(); 
 

再来定义一个方法，保存Bitmap的软引用到HashMap。

  
  
public void addBitmapToCache(String path) { 
 
        // 强引用的Bitmap对象 
 
        Bitmap bitmap = BitmapFactory.decodeFile(path); 
 
        // 软引用的Bitmap对象 
 
        SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap); 
 
        // 添加该对象到Map中使其缓存 
 
        imageCache.put(path, softBitmap); 
 
    } 

获取的时候，可以通过SoftReference的get()方法得到Bitmap对象。

  
  
public Bitmap getBitmapByPath(String path) { 
 
        // 从缓存中取软引用的Bitmap对象 
 
        SoftReference<Bitmap> softBitmap = imageCache.get(path); 
 
        // 判断是否存在软引用 
 
        if (softBitmap == null) { 
 
            return null; 
 
        } 
 
        // 取出Bitmap对象，如果由于内存不足Bitmap被回收，将取得空 
 
        Bitmap bitmap = softBitmap.get(); 
 
        return bitmap; 
 
    } 
  

使用软引用以后，在OutOfMemory异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。

需要注意的是，在垃圾回收器对这个Java对象回收前，SoftReference类所提供的get方法会返回Java对象的强引用，一旦垃圾线程回收该Java对象之后，get方法将返回null。所以在获取软引用对象的代码中，一定要判断是否为null，以免出现NullPointerException异常导致应用崩溃。

经验分享： 到底什么时候使用软引用，什么时候使用弱引用呢？ 个人认为，如果只是想避免OutOfMemory异常的发生，则可以使用软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用弱引用。 还有就是可以根据对象是否经常使用来判断。如果该对象可能会经常使用的，就尽量用软引用。如果该对象不被使用的可能性更大些，就可以用弱引用。 另外，和弱引用功能类似的是WeakHashMap。WeakHashMap对于一个给定的键，其映射的存在并不阻止垃圾回收器对该键的回收，回收以后，其条目从映射中有效地移除。WeakHashMap使用ReferenceQueue实现的这种机制。