应用的性能不仅仅在乎于速度,也要让用户真正感觉到快才行。例如,显得更快的方法有,应用可以延迟创建对象,直到需要时才创建,称为推迟初始化的技术。
下面的类是大多数Android 应用的基石:
在这些类中要特别注意的是所有的onSomething()方法,它们由主线程调用,比如onStart()和onFocusChanged()。主线程也称为UI线程,可以说应用就在其中运行。在主线程中运行所有代码是可以做到的,但不推荐这样做。主线程里包括如下要处理的事情:
在一般情况下,无论事件从系统本身还是从用户处发生,主线程都在不断接受正在发生的事件的通知。应用只有一个主线程,因此,所有的事件都按顺序处理。很显然,这样一来响应能力会受到负面影响;在队列中的第一个事件处理完之前,后面的事件都是挂起的,一次只能处理一个。如果前面事件的处理需要很长时间才能完成,那么后续其他事件需要等很长时间才轮到处理。
一个简单的例子是从主线程调用computeRecursivelyWithCache。虽然当n很小时还算快,但随着n的增长调用会变得越来越慢。当n值非常大时,你肯定会碰到Android上的ANR。如果Android检测到应用没有响应,也就是说当Android检测到输入事件在5秒钟内没有被处理,或者BroadcastReceiver在10秒内没有执行完毕,这个对话框就会跳出来。
为所有的Activity优化启动序列是非常重要的,包括以下调用:
当然,这个序列发生在创建Activity时,实际上它发生的可能比你想象的更频繁。当配置发生变化时,当前Activity被销毁,并创建一个新实例,会调用以下序列:
这个序列完成得很快,用户也会很快再次使用你的应用。最常见的配置变化之一是,设备的方向发生旋转。
Activity的onCreate()方法一般会包含调用setContentView或任何其他负责展开资源的方法。因为展开资源是一个开销相对较大的操作,所以你可以通过降低布局复杂性来使资源展开加快。几个降低布局复杂性的步骤如下:
在组件的oncreate()方法中执行所以初始化,需要较长的时间才能结束,onCreate完成后调用onStart(),onStart() 完成后调用onResume(),任何延迟都会导致应用需要较长时间启动,用户体验不好。
例如,Android使用 android.view.ViewStub 来推迟初始化,它可以在运行时展开资源。当View-Stub 需要展现是,它被相应的资源展开替换,自己就成为等到垃圾回收的对象。
由于内存分配需要花时间,等到对象真正需要时才进行分配。
当某个对象并不是立即就要使用时,推迟创建对象有着明显的好处。