Android性能优化

合 管 内存节制的使 Service

如果应 程序需要使 Service来执 后台任务的话,只有当任务正在执 的时候才应该让Service运 起来。当启动 个Service时,系统会倾向于将这个Service所依赖的进程进 保 ,系统可以在LRUcache当中缓存的进程数 也会减少,导致切换程序的时候耗费 多性能。我们可以使IntentService,当后台任务执 结束后会 动停 ,避免Service的内存泄 。

当界 可 时释放内存

当 户打开 另外 个程序,我们的程序界 已经 可 的时候,我们应当将所有和界 相关的资源进 释放。重写Activity的onTrimMemory() 法,然后在这个 法中监听TRIM_MEMORY_UI_HIDDEN这个级别, 旦触发说明 户离开 程序,此时就可以进 资源释放操作 。

当内存紧张时释放内存

onTrimMemory() 法还有很多种其他类型的回调,可以在 机内存降低的时候及时通知我们,我们应该根据回调中传 的级别来去决定如何释放应 程序的资源。

避免在Bitmap上浪费内存读取 个Bitmap图 的时候,千万 要去加载 需要的分辨率。可以压缩图 等操作。

是有优化过的数据集合

Android提供 系 优化过后的数据集合 具类,如SparseArray、SparseBooleanArray、LongSparseArray,使 这些API可以让我们的程序 加 效。HashMap 具类会相对 较低效,因为它需要为每 个键值对都提供 个对象 , SparseArray就避免掉 基本数据类型转换成对象数据类型的时间。

知晓内存的开 情况

使 枚举通常会 使 静态常 消耗两倍以上的内存,尽可能 使 枚举任何 个Java类,包括 名类、内部类,都要占 概500字节的内存空间任何 个类的实 要消耗12-16字节的内存开 ,因此频繁创建实 也是会在 定程序上影响内存的使 HashMap时,即使你只设置 个基本数据类型的键, 如说int,但是也会按照对象的 来分配内存, 概是32字节, 是4字节,因此最好使 优化后的数据集合

谨慎使 抽象编程

在Android使 抽象编程会带来额外的内存开 ,因为抽象的编程 法需要编写额外的代码,虽然这些代码根本执 到,但是也要映射到内存中, 仅占 多的内存,在执 效率上也会有所降低。所以需要合 的使 抽象编程。

尽 避免使 依赖注 框架

使 依赖注 框架貌似看上去把findViewById()这 类的繁琐操作去掉 ,但是这些框架为 要搜寻代码中的注解,通常都需要经历较 的初始化过程,并且将 些你 到的对象也 并加载到内存中。这些 到的对象会 直站 着内存空间,可能很久之后才会得到释放,所以可能多敲 代码是 好的选择。

使 多个进程

谨慎使 ,多数应 程序 该在多个进程中运 的, 旦使 当,它甚 会增加额外的内存 是帮我们节省内存。这个技巧 较适 于哪些需要在后台去完成 项独 的任务,和前台是完全可以区分开的场景。 如 乐播放,关闭软件,已经完全由Service来控制 乐播放 ,系统仍然会将许多UI 的内存进 保 。在这种场景下就 常适合使 两个进程, 个 于UI展示,另 个 于在后台持续的播放 乐。关于实现多进程,只需要在Manifast 件的应 程序组件声明 个android:process属性就可以 。进程名可以 定义,但是之前要加个冒号,表示该进程是 个当前应 程序的私有进程。

分析内存的使 情况

系统 可能将所有的内存都分配给我们的应 程序,每个程序都会有可使 的内存上限,被称为堆  。 同的 机堆   同,如下代码可以获得堆  :

ActivityManager manager = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);int heapSize = manager.getMemoryClass();

结果以MB为单位进 返回,我们开发时应 程序的内存 能超过这个限制,否则会出现OOM。Android的GC操作

Android系统会在适当的时机触发GC操作, 旦进 GC操作,就会将 些 再使 的对象进 回收。GC操作会从 个叫做Roots的对象开始检查,所有它可以访问到的对象就说明还在使 当中,应该进 保 , 其他的对系那个就表示已经 再被使 。

Android中内存泄

Android中的垃圾回收机制并 能防 内存泄 的出现导致内存泄 最主要的原因就是某些 存对象持有 些其它应该被回收的对象的引 ,导致垃圾回收 法去回收掉这些对象,也就是出现内存泄 。 如说像Activity这样的系统组件,它 会包含很多的控件甚 是图 ,如果它 法被垃圾回收 回收掉的话,那就算是 较严重的内存泄 情况 。 举个 ,在MainActivity中定义 个内部类,实 化内部类对象,在内部类新建 个线程执 死循环,会导致内部类资源 法释放,MainActivity的控件和资源 法释放,导致OOM,可借助 系 具, 如LeakCanary。

性能编码优化

都是 些微优化,在性能  看 出有 么显著的提升的。使 合适的算法和数据结构是优化程序性能的最主要 段。

避免创建 必要的对象

 必要的对象我们应该避免创建:

如果有需要拼接的字符 ,那么可以优先考虑使StringBuffer或者StringBuilder来进 拼接, 是加号连接符,因为使 加号连接符会创建多余的对象,拼接的字符 越 ,加号连接符的性能越低。在没有特殊原因的情况下,尽 使 基本数据类型来代替封装数据类型,intInteger要 加有效,其它数据类型也是 样。当 个 法的返回值是String的时候,通常需要去判断 下这个String的作 是 么,如果明确知道调 会将返回的String再进 拼接操作的话,可以考虑返回 个StringBuffer对象来代替,因为这样可以将 个对象的引 进 返回, 返回String的话就是创建 个短 命周期的临时对象。基本数据类型的数组也要优于对象数据类型的数组。另外两个平 的数组要 个封装好的对象数组 加 效,举个 ,Foo[]和Bar[]这样的数组,使 起来要 Custom(Foo,Bar)[]这样的 个数组 效的多。

尽可能地少创建临时对象,越少的对象意味着越少的GC操作。

静态优于抽象

如果你并 需要访问 个对系那个中的某些字段,只是想调 它的某些 法来去完成 项通 的功能,那么可以将这个 法设置成静态 法,调 速度提升15%-20%,同时也 为 调 这个 法去专 创建对象 ,也 担 调 这个 法后是否会改变对象的状态(静态 法 法访问 静态字段)。

对常 使 static final修饰符

static int intVal = 42;
static String strVal = "Hello, world!";

编译 会为上 的代码 成 个初始 法,称为 法,该 法会在定义类第 次被使 的时候调 。这个 法会将42的值赋值到intVal当中,从字符 常 表中提取 个引 赋值到strVal上。当赋值完成后,我们就可以通过字段搜寻的 式去访问具体的值 。

final进 优化:
static final int intVal = 42;

static final String strVal = "Hello, world!";这样,定义类就 需要 法 ,因为所有的常 都会在dex 件的初始化 当中进 初始化。当我们调 intVal时可以直接指向42的值, 调 strVal会 种相对轻 级的字符 常 式, 是字段搜寻的 式。

这种优化 式只对基本数据类型以及String类型的常 有效,对于其他数据类型的常 是 效的。使 增强型for循环语法

static class Counter {int mCount;

}

Counter[] mArray = ...

public void zero() {
int sum = 0;
for (int i = 0; i < mArray.length; ++i) {

sum += mArray[i].mCount;}

}

public void one() {
int sum = 0;
Counter[] localArray = mArray;int len = localArray.length;
for (int i = 0; i < len; ++i) {

sum += localArray[i].mCount;}

}

public void two() {
int sum = 0;
for (Counter a : mArray) {

sum += a.mCount;}

}
zero()最慢,每次都要计算mArray的 度,one()相对快得多,two()fangfa在没有JIT(Just In TimeCompiler)的设备上是运 最快的, 在有JIT的设备上运 效率和one() 法 相上下,需要注意这种写法需要JDK1.5之后才 持。

Tips:ArrayList 写的循环 增强型for循环 快,其他的集合没有这种情况。因此默认情况下使 增强型for循环, 遍历ArrayList使 传统的循环 式。

多使 系统封装好的API

系统提供 的Api完成 我们需要的功能才应该 去写,因为使 系统的Api很多时候 我们 写的代码要快得多,它们的很多功能都是通过底层的汇编模式执 的。 举个 ,实现数组拷 的功能,使 循环的 式来对数组中的每 个元素 进 赋值当然可 ,但是直接使 系统中提供的System.arraycopy() 法会让执 效率快9倍以上。

避免在内部调 Getters/Setters 法

向对象中封装的思想是 要把类内部的字段 给外部, 是提供特定的 法来允许外部操作相应类的内部字段。但在Android中,字段搜寻 法调 效率 得多,我们直接访问某个字段可能要 通过getters 法来去访问这个字段快3到7倍。但是编写代码还是要按照 向对象思维的,我们应该在能优化的地 进 优化, 如避免在内部调 getters/setters 法。

布局优化技巧重 布局 件

标签可以允许在 个布局当中引 另 个布局,那么 如说我们程序的所有界 都有 个公共的部分,这个时候最好的做法就是将这个公共的部分提取到 个独 的布局中,然后每个界 的布局 件当中来引 这个公共的布局。

Tips:如果我们要在标签中覆写layout属性,必须要将layout_width和layout_height这两个属性也进 覆写,否则覆写xiaoguo将 会 效。

标签是作为标签的 种辅助扩展来使 的,它的主要作 是为 防 在引 布局 件时引  件时产 多余的布局嵌套。布局嵌套越多,解析起来就越耗时,性能就越差。因此编写布局 件时应该让嵌套的层数越少越好。

举 : 如在LinearLayout 边使 个布局。 边 有 个LinearLayout,那么其实就存在 多余的布局嵌套,使 merge可以解决这个问题。

仅在需要时才加载布局

某个布局当中的元素 是 起显示出来的,普通情况下只显示部分常 的元素, 那些 常 的元素只有在 户进 特定操作时才会显示出来。

举 :填信息时 是需要全部填的,有 个添加 多字段的选项,当 户需要添加其他信息的时候,才将另外的元素显示到界 上。VISIBLE性能表现 般,可以ViewStub。ViewStub也是View的 种,但是没有 ,没有绘制功能,也 参与布局,资源消耗 常低,可以认为完全 影响性能。

<ViewStub
android:id="@+id/view_stub"android:layout="@layout/profile_extra"android:layout_width="match_parent"android:layout_height="wrap_content"/>

public void onMoreClick() {
ViewStub viewStub = (ViewStub) findViewById(R.id.view_stub);if (viewStub != null) {

View inflatedView = viewStub.inflate();
editExtra1 = (EditText) inflatedView.findViewById(R.id.edit_extra1);editExtra2 = (EditText) inflatedView.findViewById(R.id.edit_extra2);editExtra3 = (EditText) inflatedView.findViewById(R.id.edit_extra3);

}}

tips:ViewStub所加载的布局是 可以使 标签的,因此这有可能导致加载出来出来的布局存在着多余的嵌套结构。

Android性能优化

根据Android的层次结构,性能优化也是分层次进 的,本 会分别对Application、Framework、Native、Kernel各层做总结,每层主要会从性能优化的基本思想、优化技巧、优化 具 个 进 说明。
第 章Android应 性能优化(概述)

应 程序的性能问题是最明显、最容 体现的 类,表现形式也五花 ,举 个:应 程序第 次启动速度慢,或者进 某 界 速度慢;启动某 有动画效果的界 ,动画执 过程 流畅,或者动画执 前卡顿时间 ;ListView 表滑动过程中卡顿, 流畅;应 程序 定义的某特定界 执 速度慢, 如Launcher应 桌 左右滑动效果 平滑;响应某 户事件时 时间 响应(ANR);操作数据库时,执 数据的增删改查操作,执 速度慢;应 时间运 后,随机出现卡顿现象;

除 表现形式复杂,原因也很复杂。以上的问题的原因可能 只 个,并且很多情况下并 是应 本身的问题,也有可能是系统其他层次有问题,只 过体现在应 层。所以说应 层总是 当其冲,开发 员在处 性能问题时,需要做的第 件事情就是判断是否是应 身引起的性能问题,然后再对症下药;但有些时候应 本身逻辑正常,明显是系统的硬件配置 引起,此时就要根据产品或项 需求,采取 些 加激进的 式优化性能,以弥补硬件配置的 。

  以下从 个 同的 度总结 下应 程序性能优化的 些 法。 、基本思想

应 层的性能优化通常可以从以下 个 考虑:
1. 解编程语 的编译原 ,使 效编码 式从语法上提 程序性能;
2. 采 合 的数据结构和算法提 程序性能,这往往是决定程序性能的关键;
3. 重视界 布局优化;
4. 采 多线程、缓存数据、延迟加载、提前加载等 段,解决严重的性能瓶颈;
5. 合 配置虚拟机堆内存使 上限和使 率,减少垃圾回收频率;
6. 合 使native代码;
7. 合 配置数据库缓存类型和优化SQL语 加快读取速度,使 事务加快写 速度;7.使 具分析性能问题,找出性能瓶颈;

当然肯定还有很多其他的性能优化 法,此处仅 出 些经常会 到的 法。限于篇幅,以下会对其中 部分内容做介绍,希望能够对 家做性能优化 作有所帮助。
、编程技巧
( )Performance Tips (For Java)

Google官 上有 些关于应 程序性能提升的技巧,之前公司内也有很多总结提到过,在此简单罗 下,详细内容可以从官 获取。

http://developer.android.com/training/articles/perf-tips.html

需要说明的是, 章 出的优化技巧主要是 些微 的性能提升,决定程序整体性能的仍然取决于程序的业务逻辑设计、代码的数据结构和算法。研发 员需要将这些优化技巧应 到平时的编码过程中,积少成多,也会对性能有很 的影响。写出 效的代码需要遵循两条原则:

 执  必要的操作; 分配 必要的内存;

两条原则分别针对CPU和内存,完成必要操作的前提下尽可能的节省CPU和内存资源, 然执 效率要 。单纯这样说听起来很虚,毕竟没有 个统 的标准判断 么是必要和 必要的,需要结合具体情况具体分析 。

1. 避免创建 必要的对象创建太多的对象会造成性能低下,这谁都知道,可是为 么呢? 先分配内存本身需要时间,

其次虚拟机运 时堆内存使  是有上限的,当使  到达 定程度时会触发垃圾回收,垃圾回收会使得线程甚 是整个进程暂停运 。可想 知,如果有对象频繁的创建和销毁,或者内存使 率很 ,就会造成应 程序严重卡顿。

2.合 使static成员

主要有三点需要掌握:如果 个 法 需要操作运 时的动态变 和 法,那么可以将 法设置为static的。常 字段要声明为“static final”,因为这样常 会被存放在dex 件的静态字段初始化 中被直接访问,否则在运 时需要通过编译时 动 成的 些函数来初始化。此规则只对基本类型和String类型有效。 要将视图控件声明为static,因为View对象会引Activity对象,当Activity退出时其对象本身 法被销毁,会造成内存溢出。

3. 避免内部的Getters/Setters

向对象设计中,字段访问使 Getters/Setters通常是 个好的原则,但是在Android开发中限于硬件条件,除 字段需要被公开访问,否则如果只是有限范围内的内部访问( 如包内访问)则 建议使 Getters/Setters。在开启JIT时,直接访问的速度 间接访问要快7倍。

4. 使for-each循环

优先使 for-each循环通常情况下会获得 的效率;除 种情况,即对ArrayList进 遍历时,使 动的计数循环效率要 。

5. 使package代替private以 私有内部类 效访问外部类成员

  私有内部类的 法访问外部类的私有成员变 和 法,在语法上是正确的,但是虚拟机在运 时并 是直接访问的, 是在编译时会在外部类中 动 成 些包级别的静态 法,执 时内部类会调 这些静态 法来访问外部类的私有成员。这样的话就多  层 法调 ,性能有所损耗。 种解决这个问题的 法就是将外部类的私有成员改为包级别的,这样内部类就可以直接访问,当然前提是设计上可接受。

6. 避免使 浮点类型

经验之谈,在Android设备中浮点型 概 整型数据处 速度慢两倍,所以如果整型可以解决的问题就 要 浮点型。

另外, 些处 有硬件乘法但是没有除法,这种情况下除法和取模运算是 软件实现的。为 提 效率,在写运算式时可以考虑将 些除法操作直接改写为乘法实现, 如将“x / 2”改写为“x *0.5”。

7. 解并使 库函数

Java标准库和Android Framework中包含 效且健壮的库函数,很多函数还采 native实现,通常情况下 我们Java实现同样功能的代码的效率要 很多。所以善于使 系统库函数可以节省开发时间,并且也 容 出错。
( )布局性能优化

布局直接影响到界 的显示时间。关于界 布局的性能优化在技术上并没有难点,个 认为最重要的是是否认识到布局优化的重要性。起初我也会觉得布局本身 会是性能瓶颈,并且也很难优化,好 容 写 复杂的布局 件,或者原 代码就是那样, 且也log查看setContentView的时间,似乎没 么问题,实在是 想去研究。但实际上布局问题没有想象的那么简单。布局的性能优化之所以重要,因为以下两个 :

· 布局 件是 个xml 件,inflate布局 件其实就是解析xml,根据标签信息创建相应的布局对象并做关联。xml中的标签和属性设置越多,节点树的深度越深,在解析时要执 的判断逻辑、函数的嵌套和递归就越多,所以时间消耗越多;
· inflate操作只是布局影响的第 个环节, 个界 要显示出来,在requestLayout后还要执 系 的measure、layout、draw的操作,每 步的执 时间都会受到布局本身的影响。 界 的最终显示是所有这些操作完成后才实现的,所以如果布局质 差,会增加每 步操作的时间成本,最终显示时间就会 较 。

那么布局如何优化?总结如下 点:1.遵循 条规则:布局层次尽 少

也就是说,在达到同样布局效果的前提下,xml 件中树的深度尽 的潜。要做到这 点需要合 的使 布局控件:典型的情况是你可以使RelativeLayout来代替LinearLayout实现相同的布局效果;还有 种是如果布局树的A节点只有 个 节点B,B只有 个 节点C,那么B通常是可以去掉的;合 的使 <merge>标签,如果布局X可以被include到Y中,那么需要考虑X的根节点是否可以设置为<merge>,这样在解析时会将<merge>的 节点添加到Y中,<merge>本身 会添加。

2. 使Lint分析布局Lint是SDK中tools 录下的 具,ADT中集成Lint的可视化控制界 。Lint扫描应 程序,

它会从很多 对应 进 分析,并提示那些可能有缺陷的地 ,其中就包含与性能相关的内容。你可以在Google官 上 解详细信息。

http://developer.android.com/tools/debugging/improving-w-lint.htmlhttp://developer.android.com/tools/help/lint.html

3. 使HierarchyViewer分析布局HierarchyViewer(以下简称HV)也是SDK中tools 录下的 具,ADT中也集成HV的可视化

控制界 。可以使 HV查看当前界 的布局,它能提供很多信息,其中有两个可以帮助我们分析性能问题:
· HV的树视图展现 视图控件的相互关系,可以 来检查是否有第1点中提到的情况。
· 树视图中可以显示每个节点measure、layout、draw的时间,并且每 项 个圆点表示其耗时是否正常,每个圆点分别 绿 、 、红 表示耗时正常、警告、危险,这样就可以很 的找到有性能瓶颈 。如果树视图中没有显示这些时间,你可以点击“Obtain layout times for treerooted at selected node”按钮刷新界 显示。http://developer.android.com/tools/debugging/debugging-ui.html

4. 使ViewStub延迟加载视图

ViewStub是 个没有尺 并且 会在布局中嵌套或渲染任何东 的轻 级的视图。如果界 中有 部分视图控件 需要 即显示,则可以将其写到 个单独的layout 件中, ViewStub标

签代替,当要真正显示这部分内容时再通过ViewStub将视图加载进来。http://developer.android.com/training/improving-layouts/loading-ondemand.html

三、 具使  遵循好的编码习惯可以让程序执  有效率,但是实际运 时仍然会遇到各种各样的性能问题。

幸好有很多强 的 具能帮助我们分析性能瓶颈,找到问题所在。以下介绍的 具想必 家已经很熟悉 , 上有很多相关 章写的都很 错,在此 再赘述,仅对这些 具在使 时的 些关键点做 些说明。关于这些 具的详细使 法请 上的 篇 章:http://blog.csdn.net/innost/article/details/9008691。

( )Traceview做性能优化的最直接的 法,就是复现有性能问题的场景,并监控此过程中程序的执 流程,

如果能够 的分析程序中函数的调 关系和执 时间, 然也就很容 找出性能瓶颈 。Traceview就是 来分析函数调 过程的 具, 它可以 的分析性能问题。它的使 式需要以下 步:
使 Android的Debug API,或者DDMS监控程序运 过程;复现有性能问题的场景, 第1步的 法获取程序过程中的函数调 志 件,即trace 件;使 Traceview导trace 件即可;

Traceview的界 很直观,但是在分析过程中需要特别注意以下 点:1. Profile Panel中的各 的含义:

• ·  Incl – 指函数本身和内部嵌套的其他函数的执 时间;

• ·  Excl - 指函数本身, 包含内部嵌套的其他函数的执 时间;

• ·  Cpu Time – 指函数执 时所占 的CPU时间 的总和, 包含等待调度的时间;

• ·  Real Time – 指函数执 过程的真实时间,包含等待调度的时间;

• ·  Cpu Time/Call –指函数平均每次调 的CPU时间;

• ·  Real Time/Call –指函数平均每次调 的真实时间;

• ·  Calls+Recur Calls/Total –指函数调 的总次数+递归调 次数百分 ;

• ·  % - 带有%的 是指函数的执 时间占总采样时间的百分 ;

  2. 如何分析性能瓶颈 先通常需要关 的是CPU时间,可以找出程序 身的问题,真实时间会受到系统其他因素的

  影响。然后可以从四个 进 分析:1)分析有哪些函数单次执 时间

  可以点击“Cpu Time/Call” ,按照降序排 ,并找出那些执 时间相对较 同时也是我们关 的函数,然后再查看其函数内部的详细执 过程;
  2)分析有哪些函数调 次数过多

  可以点击“Calls+RecurCalls/Total” ,按照降序排 ,并找出哪些执 次数相对较多同时也是我们关 的函数,然后再查看其函数内部的详细执 过程;
  3)分析有哪些函数总执 时间

  有些函数的单次执 时间 是特别 ,总调 次数也 是特别多,但是 者相乘得出的总的执 时间较 ,可以点击“Incl Cpu Time”,按照降序排 ,找出这些函数;4)有时我们很明确需要查看 些特定类的特定 法,可以在 最下 的搜索条中搜索, 过好像只 持全 写输 。

  3. 提示 点:API或 具采样trace信息时,会禁JIT功能,同时因为采样本身也需要占 系统资源,所以Traceview查看函数的执 时间都要 正常运 时慢 少,我们只要关 相对的时间消耗即可。
  ( )dmtracedump

  trace 件除 可以TraceView分析外,还可以 另外 个 具dmtracedump,它的功能也很强 。如果你觉得在Traceview中查找类和函数很痛苦, 妨试试这个 具。

dmtracedump是SDK的tools 录下的可执 件,你可以查看它的帮助信息,并执 类似如下的命令:

dmtracedump -h -g tracemap.png path-to-your-trace-file > path-to-a-html-file.html

然后就可以得到两样东 , 个是各函数调 的树状图,可以 然的查看函数关系;另 个是可操作的html的 件, 浏览 打开就可以 的查找你关 的类或函数。
(三)systrace

Systrace是从4.1引 的 个强 的性能分析 具,依赖于Kernel的ftrace功能,可以对系统中很多重要模块,特别是图形显示模块做性能分析。它功能包括跟踪系统的I/O操作、内核 作队 、CPU负载以及Android各个 系统的运 状况等。

Systrace的使 法也是需要先通过Android提供的API或者DDMS开启跟踪监控模式,然后运 程序 成 志 件,最后分析 志 件即可。Systrace输出的是 个html 件,直接 浏览 查看即可。如果你使 最新版本的ADT,可以很 的通过界 操作, 再 命令 。 详细的内容可以在 上搜索。

四、关于性能优化的思考  性能优化是 个很 的话题,除 讨论如何优化外,还有 个 重要的就是是否需要优化。早

在   前,就有很多关于性能优化的讨论,然后得出 个深刻的真 :优化 容 带来伤害,  是好处,特别是 成熟的优化。在优化过程中,你产 的软件可能既 快速,也 正确, 且还 容 被修正。 要因为性能 牺牲合 的结构。努 编写好的程序  是快的程序。

但是,这并 意味着,在完成程序之前你就可以忽 性能问题。实现上的问题可以通过后期的优化 被改正,但遍布全局并且限制性能的结构缺陷 乎是 可能被改正的,除 重新编写程序。在系统完成之后再改变你的设计的某个基本 ,会导致你的系统结构病态,从 难以维护和改进。因此你应该在设计过程中考虑性能问题。

  努 避免那些限制性能的设计。考虑你的代码设计的性能后果。为获得好的性能 对代码进 曲改,是 个 常 好的想法。在每次做优化之前和之后,需要对性能进 测 。