本文共 1134 字，大约阅读时间需要 3 分钟。

客户反馈菜单出来太慢，最近就做了一些关于代码的优化。

看到这个问题，首先就是得到菜单出现大概用了多长时间。得到时间后，发现加载布局文件就花了大几百毫秒。于是第一件事就是检查布局文件了。看是否有不需要加载的控件，可以优化的图片，可以延迟加载的控件等。不看不知道，一看吓一跳啊~

首先，检查是否有多余的不需要加载的控件。

由于项目的code经过了项目组的好几个项目以及很多同事（好多已经离职）的修改，每个人修改的思路都不相同。所以存在好多不需要加载的控件。例如已经不需要使用或是显示的控件好多visibility属性都被设置成了invisible或是gone，虽然是可以很简单的达到隐藏不显示的目的，且不需要修改代码，但是这样做的缺点是：这些控件在仍然会被inflate，会创建对象，被实例化，设置属性等，依旧会占用内存资源等。对于这些确定不再使用的控件，最好注释掉或是删除，这样inflate的时候就不会创建这些控件的实例，节省时间和空间。而且整个代码看上去整洁不冗余，看着心情就好~

接着，看是否有很大的背景或是可以使用代码绘制的背景等。纯色背景、渐变背景等简单单一的背景最好是用代码来绘制，而不是使用图片，这样会很节省时间。在优化的时候，有一张背景图，渐变色，708*500，去掉后，使用shape画的，简单，而且节省了差不多100ms左右的时间。

接着看嵌套的布局是否有必要，要尽量避免多层嵌套布局，嵌套布局对性能的消耗是很大的。去掉不需要的嵌套布局，如有时候可以看到好几个LinearLayout，但是其实只需要一个或是两个就够用了。主要是使用hierarchyviewer.bat工具来查看布局。

然后看是否可以延迟加载。可以延迟加载图片或是数据。

一种比较好用的延迟加载（）：

getWindow().getDecorView().post(new Runnable() {			    @Override				    public void run() {			    	epgHandler.post(mLoadingRunnable);		}

private Runnable mLoadingRunnable = new Runnable() {	    @Override	    public void run() {                ......   //加载数据或是更新UI	  }	};

还有一些：比如使用<include>重用布局文件，<merge>防止在使用<include>时产生多余的布局嵌套，<ViewStub>动态显示布局等，由于在优化中没有具体使用到，就不再详细说了~