性能优化

Android应用的性能问题其实可以划分为几个大的模块的，而且都具有相对不错的优化调试技巧，下面我们就会依据一个项目常规开发的大类型来进行一些分析讲解。

PS：之前呆过一家初创医疗互联网公司，别提性能优化了，老板立完新项目后一个月就要求见到上线成品，这种压迫下谈何性能优化，纯属扯蛋，所以不到三个月时间我主动选择撤了，这种现象后来我一打听发现在很多初创公司都很严重，都想速成却忽略了体验。

PPPS：本文只是达到抛砖引玉的作用，很多东西细究下去都是值得深入研究的，再加上性能优化本来就是一个需要综合考量的任务，不是说会了本文哪一点就能做性能分析了，需要面面俱到才可高效定位问题原因。

2 应用UI性能问题分析

UI可谓是一个应用的脸，所以每一款应用在开发阶段我们的交互、视觉、动画工程师都拼命的想让它变得自然大方美丽，可是现实总是不尽人意，动画和交互总会觉得开发做出来的应用用上去感觉不自然，没有达到他们心目中的自然流畅细节；这种情况之下就更别提发布给终端用户使用了，用户要是能够感觉出来，少则影响心情，多则卸载应用；所以一个应用的UI显示性能问题就不得不被开发人员重视。

2-1 应用UI卡顿原理

人类大脑与眼睛对一个画面的连贯性感知其实是有一个界限的，譬如我们看电影会觉得画面很自然连贯（帧率为24fps），用手机当然也需要感知屏幕操作的连贯性（尤其是动画过度），所以Android索性就把达到这种流畅的帧率规定为60fps。

有了上面的背景，我们开发App的帧率性能目标就是保持在60fps，也就是说我们在进行App性能优化时心中要有如下准则：

换算关系：60帧/秒-----------16ms/帧；

准则：尽量保证每次在16ms内处理完所有的CPU与GPU计算、绘制、渲染等操作，否则会造成丢帧卡顿问题。

从上面可以看出来，所谓的卡顿其实是可以量化的，每次是否能够成功渲染是非常重要的问题，16ms能否完整的做完一次操作直接决定了卡顿性能问题。

当然了，针对Android系统的设计我们还需要知道另一个常识；虚拟机在执行GC垃圾回收操作时所有线程（包括UI线程）都需要暂停，当GC垃圾回收完成之后所有线程才能够继续执行（这个细节下面小节会有详细介绍）。也就是说当在16ms内进行渲染等操作时如果刚好遇上大量GC操作则会导致渲染时间明显不足，也就从而导致了丢帧卡顿问题。

有了上面这两个简单的理论基础之后我们下面就会探讨一些UI卡顿的原因分析及解决方案。

2-2 应用UI卡顿常见原因

我们在使用App时会发现有些界面启动卡顿、动画不流畅、列表等滑动时也会卡顿，究其原因，很多都是丢帧导致的；通过上面卡顿原理的简单说明我们从应用开发的角度往回推理可以得出常见卡顿原因，如下：

1. 人为在UI线程中做轻微耗时操作，导致UI线程卡顿；
   
   
2. 布局Layout过于复杂，无法在16ms内完成渲染；
   
   
3. 同一时间动画执行的次数过多，导致CPU或GPU负载过重；
   
   
4. View过度绘制，导致某些像素在同一帧时间内被绘制多次，从而使CPU或GPU负载过重；
   
   
5. View频繁的触发measure、layout，导致measure、layout累计耗时过多及整个View频繁的重新渲染；
   
   
6. 内存频繁触发GC过多（同一帧中频繁创建内存），导致暂时阻塞渲染操作；
   
   
7. 冗余资源及逻辑等导致加载和执行缓慢；
   
   
8. 臭名昭著的ANR；

可以看见，上面这些导致卡顿的原因都是我们平时开发中非常常见的。有些人可能会觉得自己的应用用着还蛮OK的，其实那是因为你没进行一些瞬时测试和压力测试，一旦在这种环境下运行你的App你就会发现很多性能问题。

2-3 应用UI卡顿分析解决方法

分析UI卡顿我们一般都借助工具，通过工具一般都可以直观的分析出问题原因，从而反推寻求优化方案，具体如下细说各种强大的工具。

2-3-1 使用HierarchyViewer分析UI性能

我们可以通过SDK提供的工具HierarchyViewer来进行UI布局复杂程度及冗余等分析，如下：

xxx@ThinkPad:~$ hierarchyviewer   //通过命令启动HierarchyViewer

选中一个Window界面item，然后点击右上方Hierarchy window或者Pixel Perfect window（这里不介绍，主要用来检查像素属性的）即可操作。

先看下Hierarchy window，如下：

一个Activity的View树，通过这个树可以分析出View嵌套的冗余层级，左下角可以输入View的id直接自动跳转到中间显示；Save as PNG用来把左侧树保存为一张图片；Capture Layers用来保存psd的PhotoShop分层素材；右侧剧中显示选中View的当前属性状态；右下角显示当前View在Activity中的位置等；左下角三个进行切换；Load View Hierarchy用来手动刷新变化（不会自动刷新的）。当我们选择一个View后会如下图所示：

类似上图可以很方便的查看到当前View的许多信息；上图最底那三个彩色原点代表了当前View的性能指标，从左到右依次代表测量、布局、绘制的渲染时间，红色和黄色的点代表速度渲染较慢的View（当然了，有些时候较慢不代表有问题，譬如ViewGroup子节点越多、结构越复杂，性能就越差）。

当然了，在自定义View的性能调试时，HierarchyViewer上面的invalidate Layout和requestLayout按钮的功能更加强大，它可以帮助我们debug自定义View执行invalidate()和requestLayout()过程，我们只需要在代码的相关地方打上断点就行了，接下来通过它观察绘制即可。

可以发现，有了HierarchyViewer调试工具，我们的UI性能分析变得十分容易，这个工具也是我们开发中调试UI的利器，在平时写代码时会时常伴随我们左右。

2-3-2 使用GPU过度绘制分析UI性能

我们对于UI性能的优化还可以通过开发者选项中的GPU过度绘制工具来进行分析。在设置->开发者选项->调试GPU过度绘制（不同设备可能位置或者叫法不同）中打开调试后可以看见如下图（对settings当前界面过度绘制进行分析）：

可以发现，开启后在我们想要调试的应用界面中可以看到各种颜色的区域，具体含义如下：

颜色 含义

无色 WebView等的渲染区域

蓝色 1x过度绘制

绿色 2x过度绘制

淡红色 3x过度绘制

红色 4x(+)过度绘制

由于过度绘制指在屏幕的一个像素上绘制多次（譬如一个设置了背景色的TextView就会被绘制两次，一次背景一次文本；这里需要强调的是Activity设置的Theme主题的背景不被算在过度绘制层级中），所以最理想的就是绘制一次，也就是蓝色（当然这在很多绚丽的界面是不现实的，所以大家有个度即可，我们的开发性能优化标准要求最极端界面下红色区域不能长期持续超过屏幕三分之一，可见还是比较宽松的规定），因此我们需要依据此颜色分布进行代码优化，譬如优化布局层级、减少没必要的背景、暂时不显示的View设置为GONE而不是INVISIBLE、自定义View的onDraw方法设置canvas.clipRect()指定绘制区域或通过canvas.quickreject()减少绘制区域等。

2-3-3 使用GPU呈现模式图及FPS考核UI性能

Android界面流畅度除过视觉感知以外是可以考核的（测试妹子专用），常见的方法就是通过GPU呈现模式图或者实时FPS显示进行考核，这里我们主要针对GPU呈现模式图进行下说明，因为FPS考核测试方法有很多（譬如自己写代码实现、第三方App测试、固件支持等），所以不做统一说明。

通过开发者选项中GPU呈现模式图工具来进行流畅度考量的流程是（注意：如果是在开启应用后才开启此功能，记得先把应用结束后重新启动）在设置->开发者选项->GPU呈现模式（不同设备可能位置或者叫法不同）中打开调试后可以看见如下图（对settings当前界面上下滑动列表后的图表）：

当然，也可以在执行完UI滑动操作后在命令行输入如下命令查看命令行打印的GPU渲染数据（分析依据：Draw + Process + Execute = 完整的显示一帧时间 < 16ms）：

adb shell dumpsys gfxinfo [应用包名]

打开上图可视化工具后，我们可以在手机画面上看到丰富的GPU绘制图形信息，分别展示了StatusBar、NavgationBar、Activity区域等的GPU渲染时间信息，随着界面的刷新，界面上会以实时柱状图来显示每帧的渲染时间，柱状图越高表示渲染时间越长，每个柱状图偏上都有一根代表16ms基准的绿色横线，每一条竖着的柱状线都包含三部分（蓝色代表测量绘制Display List的时间，红色代表OpenGL渲染Display List所需要的时间，黄色代表CPU等待GPU处理的时间），只要我们每一帧的总时间低于基准线就不会发生UI卡顿问题（个别超出基准线其实也不算啥问题的）。

可以发现，这个工具是有局限性的，他虽然能够看出来有帧耗时超过基准线导致了丢帧卡顿，但却分析不到造成丢帧的具体原因。所以说为了配合解决分析UI丢帧卡顿问题我们还需要借助traceview和systrace来进行原因追踪，下面我们会介绍这两种工具的。

2-3-4 使用Lint进行资源及冗余UI布局等优化

上面说了，冗余资源及逻辑等也可能会导致加载和执行缓慢，所以我们就来看看Lint这个工具是如何发现优化这些问题的（当然了，Lint实际的功能是非常强大的，我们开发中也是经常使用它来发现一些问题的，这里主要有点针对UI性能的说明了，其他的雷同）。

在Android Studio 1.4版本中使用Lint最简单的办法就是将鼠标放在代码区点击右键->Analyze->Inspect Code–>界面选择你要检测的模块->点击确认开始检测，等待一下后会发现如下结果：

可以看见，Lint检测完后给了我们很多建议的，我们重点看一个关于UI性能的检测结果；上图中高亮的那一行明确说明了存在冗余的UI层级嵌套，所以我们是可以点击跳进去进行优化处理掉的。

当然了，Lint还有很多功能，大家可以自行探索发挥，这里只是达到抛砖引玉的作用。

2-3-5 使用Memory监测及GC打印与Allocation Tracker进行UI卡顿分析

关于Android的内存管理机制下面的一节会详细介绍，这里我们主要针对GC导致的UI卡顿问题进行详细说明。

Android系统会依据内存中不同的内存数据类型分别执行不同的GC操作，常见应用开发中导致GC频繁执行的原因主要可能是因为短时间内有大量频繁的对象创建与释放操作，也就是俗称的内存抖动现象，或者短时间内已经存在大量内存暂用介于阈值边缘，接着每当有新对象创建时都会导致超越阈值触发GC操作。

如下是我工作中一个项目的一次经历（我将代码回退特意抓取的），出现这个问题的场景是一次压力测试导致整个系统卡顿，瞬间杀掉应用就OK了，究其原因最终查到是一个API的调运位置写错了方式，导致一直被狂调，当普通使用时不会有问题，压力测试必现卡顿。具体内存参考图如下：

与此抖动图对应的LogCat抓取如下：

//截取其中比较密集一段LogCat，与上图Memory检测到的抖动图对应，其中xxx为应用包名

......

10-06 00:59:45.619 xxx I/art: Explicit concurrent mark sweep GC freed 72515(3MB) AllocSpace objects, 65(2028KB) LOS objects, 80% free, 17MB/89MB, paused 3.505ms total 60.958ms

10-06 00:59:45.749 xxx I/art: Explicit concurrent mark sweep GC freed 5396(193KB) AllocSpace objects, 0(0B) LOS objects, 75% free, 23MB/95MB, paused 2.079ms total 100.522ms

......

10-06 00:59:48.059 xxx I/art: Explicit concurrent mark sweep GC freed 4693(172KB) AllocSpace objects, 0(0B) LOS objects, 75% free, 23MB/95MB, paused 2.227ms total 101.692ms

......

我们知道，类似上面logcat打印一样，触发垃圾回收的主要原因有以下几种：

1. GC_MALLOC——内存分配失败时触发；
   
   
2. GC_CONCURRENT——当分配的对象大小超过384K时触发；
   
   
3. GC_EXPLICIT——对垃圾收集的显式调用(System.gc()) ；
   
   
4. GC_EXTERNAL_ALLOC——外部内存分配失败时触发；

可以看见，这种不停的大面积打印GC导致所有线程暂停的操作必定会导致UI视觉的卡顿，所以我们要避免此类问题的出现，具体的常见优化方式如下：

• 检查代码，尽量避免有些频繁触发的逻辑方法中存在大量对象分配；
  
  
• 尽量避免在多次for循环中频繁分配对象；
  
  
• 避免在自定义View的onDraw()方法中执行复杂的操作及创建对象（譬如Paint的实例化操作不要写在onDraw()方法中等）；
  
  
• 对于并发下载等类似逻辑的实现尽量避免多次创建线程对象，而是交给线程池处理。

当然了，有了上面说明GC导致的性能后我们就该定位分析问题了，可以通过运行DDMS->Allocation Tracker标签打开一个新窗口，然后点击Start Tracing按钮，接着运行你想分析的代码，运行完毕后点击Get Allocations按钮就能够看见一个已分配对象的列表，如下：

点击上面第一个表格中的任何一项就能够在第二个表格中看见导致该内存分配的栈信息，通过这个工具我们可以很方便的知道代码分配了哪类对象、在哪个线程、哪个类、哪个文件的哪一行。譬如我们可以通过Allocation Tracker分别做一次Paint对象实例化在onDraw与构造方法的一个自定义View的内存跟踪，然后你就明白这个工具的强大了。

PS一句，Android Studio新版本除过DDMS以外在Memory视图的左侧已经集成了Allocation Tracker功能，只是用起来还是没有DDMS的方便实用，如下图：

2-3-6 使用Traceview和dmtracedump进行分析优化

关于UI卡顿问题我们还可以通过运行Traceview工具进行分析，他是一个分析器，记录了应用程序中每个函数的执行时间；我们可以打开DDMS然后选择一个进程，接着点击上面的“Start Method Profiling”按钮（红色小点变为黑色即开始运行），然后操作我们的卡顿UI（小范围测试，所以操作最好不要超过5s），完事再点一下刚才按的那个按钮，稍等片刻即可出现下图，如下：

花花绿绿的一幅图我们怎么分析呢？下面我们解释下如何通过该工具定位问题：

整个界面包括上下两部分，上面是你测试的进程中每个线程运行的时间线，下面是每个方法（包含parent及child）执行的各个指标的值。通过上图的时间面板可以直观发现，整个trace时间段main线程做的事情特别多，其他的做的相对较少。当我们选择上面的一个线程后可以发现下面的性能面板很复杂，其实这才是TraceView的核心图表，它主要展示了线程中各个方法的调用信息（CPU使用时间、调用次数等），这些信息就是我们分析UI性能卡顿的核心关注点，所以我们先看几个重要的属性说明，如下：

属性名 含义

name 线程中调运的方法名；

Incl CPU Time 当前方法（包含内部调运的子方法）执行占用的CPU时间；

Excl CPU Time 当前方法（不包含内部调运的子方法）执行占用的CPU时间；

Incl Real Time 当前方法（包含内部调运的子方法）执行的真实时间，ms单位；

Excl Real Time 当前方法（不包含内部调运的子方法）执行的真实时间，ms单位；

Calls+Recur Calls/Total 当前方法被调运的次数及递归调运占总调运次数百分比；

CPU Time/Call 当前方法调运CPU时间与调运次数比，即当前方法平均执行CPU耗时时间；

Real Time/Call 当前方法调运真实时间与调运次数比，即当前方法平均执行真实耗时时间；（重点关注）

有了对上面Traceview图表的一个认识之后我们就来看看具体导致UI性能后该如何切入分析，一般Traceview可以定位两类性能问题：

• 方法调运一次需要耗费很长时间导致卡顿；
  
  
• 方法调运一次耗时不长，但被频繁调运导致累计时长卡顿。

譬如我们来举个实例，有时候我们写完App在使用时不觉得有啥大的影响，但是当我们启动完App后静止在那却十分费电或者导致设备发热，这种情况我们就可以打开Traceview然后按照Cpu Time/Call或者Real Time/Call进行降序排列，然后打开可疑的方法及其child进行分析查看，然后再回到代码定位检查逻辑优化即可；当然了，我们也可以通过该工具来trace我们自定义View的一些方法来权衡性能问题，这里不再一一列举喽。

可以看见，Traceview能够帮助我们分析程序性能，已经很方便了，然而Traceview家族还有一个更加直观强大的小工具，那就是可以通过dmtracedump生成方法调用图。具体做法如下：

dmtracedump -g result.png target.trace  //结果png文件  目标trace文件

通过这个生成的方法调运图我们可以更加直观的发现一些方法的调运异常现象。不过本人优化到现在还没怎么用到它，每次用到Traceview分析就已经搞定问题了，所以说dmtracedump自己酌情使用吧。

PS一句，Android Studio新版本除过DDMS以外在CPU视图的左侧已经集成了Traceview（start Method Tracing）功能，只是用起来还是没有DDMS的方便实用（这里有一篇AS MT个人觉得不错的分析文章（引用自网络，链接属于原作者功劳）），如下图：

2-3-7 使用Systrace进行分析优化

Systrace其实有些类似Traceview，它是对整个系统进行分析（同一时间轴包含应用及SurfaceFlinger、WindowManagerService等模块、服务运行信息），不过这个工具需要你的设备内核支持trace（命令行检查/sys/kernel/debug/tracing）且设备是eng或userdebug版本才可以，所以使用前麻烦自己确认一下。

我们在分析UI性能时一般只关注图形性能（所以必须选择Graphics和View，其他随意），同时一般对于卡顿的抓取都是5s，最多10s。启动Systrace进行数据抓取可以通过两种方式，命令行方式如下：

python systrace.py --time=10 -o mynewtrace.html sched gfx view wm

图形模式：

打开DDMS->Capture system wide trace using Android systrace->设置时间与选项点击OK就开始了抓取，接着操作APP，完事生成一个trace.html文件，用Chrome打开即可如下图：

在Chrome中浏览分析该文件我们可以通过键盘的W-A-S-D键来搞定，由于上面我们在进行trace时选择了一些选项，所以上图生成了左上方相关的CPU频率、负载、状态等信息，其中的CPU N代表了CPU核数，每个CPU行的柱状图表代表了当前时间段当前核上的运行信息；下面我们再来看看SurfaceFlinger的解释，如下：

可以看见上面左边栏的SurfaceFlinger其实就是负责绘制Android程序UI的服务，所以SurfaceFlinger能反应出整体绘制情况，可以关注上图VSYNC-app一行可以发现前5s多基本都能够达到16ms刷新间隔，5s多开始到7s多大于了15ms，说明此时存在绘制丢帧卡顿；同时可以发现surfaceflinger一行明显存在类似不规律间隔，这是因为有的地方是不需要重新渲染UI，所以有大范围不规律，有的是因为阻塞导致不规律，明显可以发现0到4s间大多是不需要渲染，而5s以后大多是阻塞导致；对应这个时间点我们放大可以看到每个部分所使用的时间和正在执行的任务，具体如下：

可以发现具体的执行明显存在超时性能卡顿（原点不是绿色的基本都代表存在一定问题，下面和右侧都会提示你选择的帧相关详细信息或者alert信息），但是遗憾的是通过Systrace只能大体上发现是否存在性能问题，具体问题还需要通过Traceview或者代码中嵌入Trace工具类等去继续详细分析，总之很蛋疼。

PS：如果你想使用Systrace很轻松的分析定位所有问题，看明白所有的行含义，你还需要具备非常扎实的Android系统框架的原理才可以将该工具使用的得心应手。

2-3-8 使用traces.txt文件进行ANR分析优化

ANR（Application Not Responding）是Android中AMS与WMS监测应用响应超时的表现；之所以把臭名昭著的ANR单独作为UI性能卡顿的分析来说明是因为ANR是直接卡死UI不动且必须要解掉的Bug，我们必须尽量在开发时避免他的出现，当然了，万一出现了那就用下面介绍的方法来分析吧。

我们应用开发中常见的ANR主要有如下几类：

• 按键触摸事件派发超时ANR，一般阈值为5s（设置中开启ANR弹窗，默认有事件派发才会触发弹框ANR）；
  
  
• 广播阻塞ANR，一般阈值为10s（设置中开启ANR弹窗，默认不弹框，只有log提示）；
  
  
• 服务超时ANR，一般阈值为20s（设置中开启ANR弹窗，默认不弹框，只有log提示）；
  
  

当ANR发生时除过logcat可以看见的log以外我们还可以在系统指定目录下找到traces文件或dropbox文件进行分析，发生ANR后我们可以通过如下命令得到ANR trace文件：

adb pull /data/anr/traces.txt ./

然后我们用txt编辑器打开可以发现如下结构分析：

//显示进程id、ANR发生时间点、ANR发生进程包名

----- pid 19073 at 2015-10-08 17:24:38 -----

Cmd line: com.example.yanbo.myapplication

//一些GC等object信息，通常可以忽略

......

//ANR方法堆栈打印信息！重点！

DALVIK THREADS (18):

"main" prio=5 tid=1 Sleeping

  | group="main" sCount=1 dsCount=0 obj=0x7497dfb8 self=0x7f9d09a000

  | sysTid=19073 nice=0 cgrp=default sched=0/0 handle=0x7fa106c0a8

  | state=S schedstat=( 125271779 68162762 280 ) utm=11 stm=1 core=0 HZ=100

  | stack=0x7fe90d3000-0x7fe90d5000 stackSize=8MB

  | held mutexes=

  at java.lang.Thread.sleep!(Native method)

  - sleeping on <0x0a2ae345> (a java.lang.Object)

  at java.lang.Thread.sleep(Thread.java:1031)

  - locked <0x0a2ae345> (a java.lang.Object)

//真正导致ANR的问题点，可以发现是onClick中有sleep导致。我们平时可以类比分析即可，这里不详细说明。

  at java.lang.Thread.sleep(Thread.java:985)

  at com.example.yanbo.myapplication.MainActivity$1.onClick(MainActivity.java:21)

  at android.view.View.performClick(View.java:4908)

  at android.view.View$PerformClick.run(View.java:20389)

  at android.os.Handler.handleCallback(Handler.java:815)

  at android.os.Handler.dispatchMessage(Handler.java:104)

  at android.os.Looper.loop(Looper.java:194)

  at android.app.ActivityThread.main(ActivityThread.java:5743)

  at java.lang.reflect.Method.invoke!(Native method)

  at java.lang.reflect.Method.invoke(Method.java:372)

  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:988)

  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:783)

......

//省略一些不常关注堆栈打印

......

至此常见的应用开发中ANR分析定位就可以解决了。

2-4 应用UI性能分析解决总结

可以看见，关于Android UI卡顿的性能分析还是有很多工具的，上面只是介绍了应用开发中我们经常使用的一些而已，还有一些其他的，譬如Oprofile等工具不怎么常用，这里就不再详细介绍。

通过上面UI性能的原理、原因、工具分析总结可以发现，我们在开发应用时一定要时刻重视性能问题，如若真的没留意出现了性能问题，不妨使用上面的一些案例方式进行分析。但是那终归是补救措施，在我们知道上面UI卡顿原理之后我们应该尽量从项目代码架构搭建及编写时就避免一些UI性能问题，具体项目中常见的注意事项如下：

• 布局优化；尽量使用include、merge、ViewStub标签，尽量不存在冗余嵌套及过于复杂布局（譬如10层就会直接异常），尽量使用GONE替换INVISIBLE，使用weight后尽量将width和heigh设置为0dp减少运算，Item存在非常复杂的嵌套时考虑使用自定义Item View来取代，减少measure与layout次数等。
  
  
• 列表及Adapter优化；尽量复用getView方法中的相关View，不重复获取实例导致卡顿，列表尽量在滑动过程中不进行UI元素刷新等。
  
  
• 背景和图片等内存分配优化；尽量减少不必要的背景设置，图片尽量压缩处理显示，尽量避免频繁内存抖动等问题出现。
  
  
• 自定义View等绘图与布局优化；尽量避免在draw、measure、layout中做过于耗时及耗内存操作，尤其是draw方法中，尽量减少draw、measure、layout等执行次数。
  
  
• 避免ANR，不要在UI线程中做耗时操作，遵守ANR规避守则，譬如多次数据库操作等。

当然了，上面只是列出了我们项目中常见的一些UI性能注意事项而已，相信还有很多其他的情况这里没有说到，欢迎补充。还有一点就是我们上面所谓的UI性能优化分析总结等都是建议性的，因为性能这个问题是一个涉及面很广很泛的问题，有些优化不是必需的，有些优化是必需的，有些优化掉以后又是得不偿失的，所以我们一般着手解决那些必须的就可以了。