Android进阶知识——Android性能优化

Posted 2022-11-03 ABded

文章目录

• 1.Android的性能优化方法
• • 1.1布局优化
  • 1.2绘制优化
  • 1.3内存泄漏优化
  • 1.4响应速度优化
  • 1.5ListView和Bitmap优化
  • 1.6线程优化
  • 1.7一些性能优化建议
• 2.提高程序的可维护性

通过本章的内容，我们可以掌握常见的性能优化方法，这将有助于提高android程序的性能；另一方面，本章还将讲解Android程序的设计思想，这将有助于提高程序的可维护性和可扩展性。

Android设备作为一种移动设备，不管是内存还是CPU的性能都受到了一定的限制，无法做到像PC设备那样具有超大的内存和高性能的CPU。鉴于这一点，这也意味着Android程序不可能无限制地使用内存和CPU资源，过多地使用内存会导致程序内存泄漏，即OOM。而过多的使用CPU资源，一般是指做大量的耗时任务，会导致手机变得卡顿甚至出现程序无法响应的情况，即ANR。由此来看，Android程序的性能问题就变得异常突出了，这对开发人员也提出了更高的要求。为了提高应用程序的性能，本章第一节介绍了一些有效的性能优化方法。

性能优化中一个很重要的问题就是内存泄露，内存泄漏并不会导致程序功能异常，但是它会导致Android程序的内存占用过大，这将提高内存溢出的发生几率。如何避免写出内存泄露的代码，这和开发人员的水平和意识有很大关系。本章我们也会对内存泄漏的常见场景进行介绍。

在做程序设计时，除了要完成功能开发、提高程序的性能以外，开有一个问题也是不容忽视的，那就是代码的可维护性和可扩展性。如果一个程序的可维护性和可扩展性很差，那就意味着后续的代码维护代价是相当高的，比如需要对一个功能做一些调整，这可能会出现牵一发而动全身的局面。另外添加新功能时也觉得无从下手，整个代码看起来可读性很差，这的确是一份很糟糕的代码。关于代码的可维护性和可扩展性，看起来是一个很抽象的问题，其实也并不抽象，它是可以通过一些合理的设计原则去完成的，比如良好的代码风格、清晰的代码层级、代码的可扩展性和合理的设计模式，在本章的第三节对这些设计原则进行介绍，这将在一定程度上提高程序的可维护性和可扩展性。

1.Android的性能优化方法

本节介绍了一些有效的性能优化方法，主要内容包括布局优化、绘制优化、内存泄漏优化、ListView优化、Bitmap优化、线程优化以及一些性能优化建议。

1.1布局优化

布局优化的思想很简单，就是尽量减少布局文件的层级，这个道理是很浅显的，布局中的层级少了，这就意味着Android绘制时的工作量少了，那么程序的性能自然就提高了。

如何进行布局优化呢？首先删除布局中无用的控件和层级，其次有选择地使用性能较低的ViewGroup，比如RelativeLayout。如果布局中既可以用LinearLayout也可以使用RelativeLayout，那么就采用LinearLayout，这是因为RelativeLayout的功能比较复杂，它的布局过程需要花费更多的CPU时间。FrameLayout和LinearLayout一样都是一种简单高效的ViewGroup，因此可以优先考虑使用它们，但是很多时候单纯通过一个LinearLayout或者FrameLayout无法实现产品效果，需要通过嵌套的方式来完成。这种情况下还是建议采用RelativeLayout，因为ViewGroup的嵌套就相当于增加了布局的层级，同样会降低程序的性能。

布局优化的另外一种手段是采用< include >标签、< merage >标签和VeiwStub。< include >标签主要用于布局重用，< merge >标签一般和< include >配合使用，它可以降低减少布局的层级，而ViewStub则提供了按需加载的功能，当需要时才会将ViewStub中的布局加载到内存，这提高了程序的初始化效率，下面分别介绍它们的使用方法。

< include >标签

< include >标签可以将一个指定的布局文件加载到当前的布局文件中，如下所示：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
	android:orientation="vertical"
	android:layout_width="match_parent"
	android:layout_height="match parent"
	android:background="@color/app_bg"
	android:gravity="center_horizontal">
	
	<include layout="@layout/titlebar"/>
	
	<TextView android:layout_width="match_parent"
		android:layout_height="wrap_content"
		android:text="@string/text"
		android:padding="5dp" />
		
</LinearLayout>

上面的代码中，@layout/titlebar指定了另外一个布局文件，通过这种方式就比用把titlebar这个布局文件的内容再重复写一遍了，这就是< include >的好处。< include >标签只支持以android:layout_开头的属性，比如android:layout_width、android:layout_height，其他属性是不支持的，比如android:background。当然，android:id这个属性是个特例，如果< include >指定了这个id属性，同时被包含的布局文件的根元素也指定了id属性，那么以< include >指定的id属性为准。需要注意的是，如果< incldue >标签指定了android:layout_*这种属性，那么要求android:layout_width和android:layout_height必须存在，否则其他android:layout_*形式的属性无法生效，下面是一个指定了android:layout_*属性的示例：

<include android:id="@+id/new_title"
	android:layout_width="match parent"
	android:layout_height="match parent"
	layout="@layout/title"/>

< merge >标签

< merge >标签一般和< include >标签一起使用从而减少布局的层级。在上面的示例中，由于当前文件是一个竖直方向的LinearLayout，这个时候如果被包含的布局文件中也采用了竖直方向的LinearLayout，那么显然被包含的布局文件中的LinearLayout是多余的，通过< merge >标签就可以去掉多余的那一层LinearLayout，如下所示：

<merge xmlns:android="http://schemas.android.com/apk/res/android">

	<Button
		android:layout_width="wrap_content"
		android:layout_height="wrap_content"
		android:text="@string/one"/>
	
	<Button
		android:layout_width="wrap_content"
		android:layout_height="wrap_content"
		android:text="@string/two"/>
		
</merge>

ViewStub

ViewStub继承了View，它非常轻量级且宽/高都是0，因此它本身不参与任何的布局和绘制过程。ViewStub的意义在于按需加载所需的布局文件，在实际开发中，有很多布局文件在正常情况下不会显示，比如网络异常时的界面，这个时候就没有必要在整个界面初始化的时候将其加载进来，通过ViewStub就可以做到在使用的时候再加载，提高了程序初始化时的性能。下面是一个ViewStub的示例：

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

其中stub_import是ViewStub的id，而panel_import是layout/layout_network_error这个布局的根元素的id。如何做到按需加载呢？在需要加载ViewStub中的布局时，可以按照如下两种方式进行：

((ViewStub) findViewById(R.id.stub_import)).setVisibility(View.VISIBLE);

或者：

View importPanel = ((ViewStub) findViewById(R.id.stub_import)).inflate();

当ViewStub通过setVisibility或者inflate方法加载后，ViewStub就会被它内部的布局替换掉，这个时候ViewStub就不再是整个布局结构中的一部分了。另外，目前ViewStub还不支持< merge >标签。

1.2绘制优化

绘制优化是指View的onDraw方法要避免进行大量的操作，这主要体现在两个方面。

首先，onDraw中不要创建新的布局对象，这是因为onDraw方法可能会被频繁调用，这样就会在一瞬间产生大量的临时对象，这不仅占用了过多的内存而且还会导致系统更加频繁gc，降低了程序的执行效率。

另外一方面，onDraw方法中不要做耗时的任务，也不能执行成千上万次的循环操作，尽管每次循环都很轻量级，但是大量的循环仍然十分抢占CPU的时间片，这会造成View的绘制过程不流畅。按照Google官方给出的性能优化典范中的标准，View的绘制帧率保证60fps是最佳的，这就要求每帧的绘制时间不超过16ms(16ms = 1000/60)，虽然程序很难保证16ms这个时间，但是尽量降低onDraw方法的复杂度总是切实有效的。

1.3内存泄漏优化

内存泄漏在开发过程中是一个需要重视的问题，但是由于内存泄漏问题对开发人员的经验和开发意识有较高的要求，因此这也是开发人员最容易犯的错误之一。内存泄漏的优化分为两个方面，一方面是在开发过程中避免写出有内存泄漏的代码，另一方面是通过一些分析工具来找出潜在的内存泄漏继而解决。本节主要介绍一些常见的内存泄漏的例子，通过这些例子读者可以很好地理解内存泄漏的发生场景并积累规避内存泄漏的经验。

场景1：静态变量导致的内存泄漏

下面这种情形是一种最简单的内存泄漏，下面的代码将导致Activity无法正常销毁，因为静态变量sContext引用了它。

public class MainActivity extends Activity 
	private static final String TAG = "MainActivity";
	
	private static Context sContext;
	
	@Override
	protected void onCreate(Bundle savedInstanceState) 
		super.onCreate(savedInstanceState);
		setContentView(R.layout.activity_main);
		sContext = this;
	

上面的代码也可以改造一下，如下所示。sView是一个静态变量，它内部持有了当前Activity，所以Activity仍然无法释放。

public class MainActivity extends Activity (
	private static final String TAG = "MainActivity";
	
	private static View sView;
	
	@Override
	protected void onCreate(Bundle savedInstanceState) 
		super.onCreate(savedInstanceState);
		setContentView(R.layout.activity_main);
		sView = new View(this);
	

场景2：单例模式导致的内存泄漏

静态变量导致的内存泄漏都太过于明显，而单例模式所带来的内存泄漏是我们容易忽视的，如下所示。首先提供一个单例模式的TestManager，TestManager可以接收外部的注册并将外部的监听器存储起来。

public class TestManager (
	private List<OnDataArrivedListener> mOnDataArrivedListeners = new ArrayList<OnDataArrivedListener>();
	
	private static class SingletonHolder 
		public static final TestManager INSTANCE = new TestManager();
	
	
	private TestManager() 
	
	
	public static TestManager getInstance() 
		return SingletonHolder.INSTANCE;
	
	
	public synchronized void registerListener(OnDataArrivedListener listener) 
		if (!mOnDataArrivedListeners.contains(listener)) 
			mOnDataArrivedListeners.add(listener);
		
	

	public synchronized void unregisterListener (OnDataArrivedListener listener) 
		mOnDataArrivedListeners.remove(listener);
	
	
	public interface OnDataArrivedListener 
		public void onDataArrived(object data);
	

接着再让Activity实现OnDataArrivedListener接口并向TestManager注册监听，如下所示。下面的代码由于缺少解注册操作所以会引起内存泄漏，泄露的原因是Activity的对象被单例模式的TestManager所持有，而单例模式的特点是其生命周期和Application保持一致，因此Activity对象无法被及时释放。

protected void onCreate(Bundle savedInstanceState) 
	super.onCreate(savedInstanceState);
	setContentView(R.layout.activity_main);
	TestManager.getInstance().registerListener(this);

场景3：属性动画导致的内存泄漏

从Android3.0开始，Google提供了属性动画，属性动画中有一类无限循环的动画，如果在Activity中播放此类动画且没有在onDestory中去停止动画，那么动画会一直播放下去，尽管已经无法在界面上看到动画效果了，并且这个时候Activity的View被动画持有，而View又持有Activity，最终Activity无法释放。下面的动画是无限动画，会泄漏当前Activity，解决方法是在Activity的onDestory中调用animator.cancel()来停止动画。

protected void onCreate(Bundle savedInstanceState) 
	super.onCreate(savedInstanceState);
	setContentView(R.layout.activity_main);
	mButton = (Button) findViewById(R.id.button1);
	ObjectAnimator animator = objectAnimator.ofFloat(mButton, "rotation", 0, 360).setDuration(2000);
	animator.setRepeatCount(ValueAnimator.INFINITE);
	animator.start();
	//animator.cancel();

1.4响应速度优化

响应速度优化的核心思想是避免在主线程中做耗时操作，但是有时候的确有很多耗时操作，怎么办呢？可以将这些耗时操作放在线程中去执行，即采取异步的方式执行耗时操作。响应速度过慢更多地体现在Activity的启动速度上面，如果在主线程中做太多事情，会导致Activity启动时出现黑屏现象，甚至出现ANR。Android规定，Activity如果5秒种之内无法响应屏幕触摸事件或者键盘输入事件就会出现ANR，而BroadcastReceiver如果10秒钟之内还未执行完操作也会出现ANR。

1.5ListView和Bitmap优化

ListView的优化主要分为三个方面：首先要采取ViewHolder并避免在getView中执行耗时操作；其次要根据列表的滑动状态来控制任务的执行频率，比如当列表快速滑动时显然是不太适合开启大量的异步任务的；最后可以尝试开启硬件加速来使ListView的滑动更加流畅。注意ListView的优化策略完全适用于GridView。

Bitmap的优化主要是通过BitmapFactory.Options来根据需要对图片进行采样，采样过程中主要用到了BitmapFactory.Options的inSampleSize参数。

1.6线程优化

线程优化的思想是采用线程池，避免程序中存在大量的Thread。线程池可以重用内部的线程，从而避免了线程的创建和销毁所带来的性能开销，同时线程池还能有效地控制线程池的最大并发数，避免大量的线程因互相抢占系统资源从而导致阻塞现象的发生。因此在实际开发中，我们要尽量采用线程池，而不是每次都要创建一个Thread对象。

1.7一些性能优化建议

本节介绍的是一些性能优化的小建议，通过它们可以在一定程度上提高性能。

• 避免创建过多的对象；

• 不要过多的使用枚举，枚举占用的内存空间要比整型大；

• 常量请使用static final来修饰；

• 使用一些Android特有的数据结构，比如SparseArray和Pair等，它们都具有更好的性能；

• 适当使用软引用和弱引用；

• 采用内存缓存和磁盘缓存；

• 尽量采用静态内部类，这样可以避免潜在的由于内部类而导致的内存泄漏。

2.提高程序的可维护性

本节所讲述的内容是Android的程序设计思想，主旨是如何提高代码的可维护性和可扩展性，而程序的可维护性本质上也包含可扩展性。本节的切入点为：代码风格、代码的层次性和单一职责原则、面向扩展编程以及设计模式，下面围绕着它们分别展开。

可读性是代码可维护的前提，一段别人很难读懂的代码的可维护性显然是极差的。而良好的代码风格在一定程度上可以提高程序的可读性。代码风格包含很多方面，比如命名规范、代码的排版以及是否写注释等。到底什么样的代码风格是良好的呢？下面是给大家的一些建议。

• 命名要规范，要能正确地传达出变量或方法的含义，少用缩写，关于变量的前缀可以参考Android源码的命名方式，比如私有成员以m开头，静态成员以s开头，常量则全部用大写字母表示。

• 代码的排版上需要留出合理的空白来区分不同的代码块，其中同类变量的声明要放在一组，两类变量之间要留出一行空白作为区分。

• 仅为非常关键的代码添加注释。其他地方不写注释，这就对变量和方法的命名风格提出了很高的要求，一个合理的命名风格可以让读者阅读源码就像在阅读注释一样，因此根本不需要为代码额外写注释。

代码的层次性是指代码要有分层的概念，对于一段业务逻辑，不要试图在一个方法或者一个类中去全部实现，而要将它分成几个子逻辑，然后每个自逻辑做自己的事情，这样既显得代码层次分明，又可以分解任务从而实现简化逻辑的效果。单一职责是和层次性相关联的，代码分层以后，每一层仅仅关注少量的逻辑，这样就做到了单一职责。

程序的可扩展性标志着开发人员是否有足够的经验，很多时候在开发过程中我们无法保证已经做好的需求不在后面的版本发生变更，因此在写程序的过程中要时刻考虑到扩展，考虑着如果这个逻辑后面发生了改变那么需要做哪些修改，以及怎么样才能降低修改的工作量，面向扩展编程会使程序具有很好的可扩展性。

恰当地使用设计模式可以提高代码的可维护性和可扩展性，但是Android程序容易有性能瓶颈，因此要控制设计的度，设计不能太牵强，否则就是过度设计了。常见的设计模式有很多，比如单例模式、工厂模式以及观察者模式等。