Google定义：界面呈现是指从应用生成帧并将其显示在屏幕上的动作。要确保用户能够流畅地与应用互动，应用呈现每帧的时间不应超过16ms，以达到每秒60帧的呈现速度（为什么是60fps？）。
成都创新互联长期为上1000+客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为新源企业提供专业的成都网站建设、网站建设，新源网站改版等技术服务。拥有十余年丰富建站经验和众多成功案例,为您定制开发。
如果应用存在界面呈现缓慢的问题，系统会不得不跳过一些帧，这会导致用户感觉应用不流畅，我们将这种情况称为卡顿。
来源于： Google Android的为什么是60fps？
16ms意味着1000/60hz，相当于60fps。这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新。12fps大概类似手动快速翻动书籍的帧率， 这明显是可以感知到不够顺滑的。24fps使得人眼感知的是连续线性的运动，这其实是归功于运动模糊的效果。 24fps是电影胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。 但是低于30fps是 无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，超过60fps就没有必要了。如果我们的应用没有在16ms内完成屏幕刷新的全部逻辑操作，就会发生卡顿。
首先要了解Android显示1帧图像，所经历的完整过程。
如图所示，屏幕显示1帧图像需要经历5个步骤：
常见的丢帧情况： 渲染期间可能出现的情况，渲染大于16ms和小于16ms的情况：
上图中应该绘制 4 帧数据 , 但是实际上只绘制了 3 帧 , 实际帧率少了一帧
判断APP是否出现卡顿，我们从通用应用和游戏两个纬度的代表公司标准来看，即Google的Android vitals性能指标和地球第一游戏大厂腾讯的PrefDog性能指标。
以Google Vitals的卡顿描述为准，即呈现速度缓慢和帧冻结两个维度判断：
PerfDog Jank计算方法：
帧率FPS高并不能反映流畅或不卡顿。比如：FPS为50帧，前200ms渲染一帧，后800ms渲染49帧，虽然帧率50，但依然觉得非常卡顿。同时帧率FPS低，并不代表卡顿，比如无卡顿时均匀FPS为15帧。所以平均帧率FPS与卡顿无任何直接关系)
当了解卡顿的标准以及渲染原理之后，可以得出结论，只有丢帧情况才能准确判断是否卡顿。
dumpsys 是一种在设备上运行并转储需要关注的系统服务状态信息的 Android 工具。通过向 dumpsys 传递 gfxinfo 命令，可以提供 logcat 格式的输出，其中包含与录制阶段发生的动画帧相关的性能信息。
借助 Android 6.0（API 级别 23），该命令可将在整个进程生命周期中收集的帧数据的聚合分析输出到 logcat。例如：
这些总体统计信息可以得到期间的FPS、Jank比例、各类渲染异常数量统计。
命令 adb shell dumpsys gfxinfo PACKAGE_NAME framestats 可提供最近120个帧中，渲染各阶段带有纳秒时间戳的帧时间信息。
关键参数说明：
通过gfxinfo输出的帧信息，通过定时reset和打印帧信息，可以得到FPS(帧数/打印间隔时间)、丢帧比例（(janky_frames / total_frames_rendered)*100 %）、是否有帧冻结(帧耗时700ms)。
根据第2部分的通用应用卡顿标准，可以通过丢帧比例和帧冻结数量，准确判断当前场景是否卡顿。并且通过定时截图，还可以根据截图定位卡顿的具体场景。
如上图所示，利用gfxinfo开发的检查卡顿的小工具，图中参数和卡顿说明如下：
根据上面对gfxinfo的帧信息解析，可以准确计算出每一帧的耗时。从而可以开发出满足腾讯PerfDog中关于普通卡顿和严重卡顿的判断。
依赖定时截图，即可准确定位卡顿场景。如下图所示（此处以PerfDog截图示例）：
通过第3部分的卡顿评估方法，我们可以定位到卡顿场景，但是如何定位到具体卡顿原因呢。
首先了解卡顿问题定位工具，然后再了解常见的卡顿原因，即可通过复现卡顿场景的同时，用工具去定位具体卡顿问题。
重点就是，充分利用gfxinfo输出的帧信息，对卡顿问题进行分类。
了解了高效定位卡顿的方法和卡顿问题定位工具，再熟悉一下常见的卡顿原因，可以更熟练的定位和优化卡顿。
SurfaceFlinger 负责 Surface 的合成，一旦 SurfaceFlinger 主线程调用超时，就会产生掉帧。
SurfaceFlinger 主线程耗时会也会导致 hwc service 和 crtc 不能及时完成，也会阻塞应用的 binder 调用，如 dequeueBuffer、queueBuffer 等。
后台进程活动太多，会导致系统非常繁忙，cpu \ io \ memory 等资源都会被占用，这时候很容易出现卡顿问题，这也是系统这边经常会碰到的问题。
dumpsys cpuinfo 可以查看一段时间内 cpu 的使用情况：
当线程为 Runnable 状态的时候，调度器如果迟迟不能对齐进行调度，那么就会产生长时间的 Runnable 线程状态，导致错过 Vsync 而产生流畅性问题。
system_server 的 AMS 锁和 WMS 锁 , 在系统异常的情况下 , 会变得非常严重 , 如下图所示 , 许多系统的关键任务都被阻塞 , 等待锁的释放 , 这时候如果有 App 发来的 Binder 请求带锁 , 那么也会进入等待状态 , 这时候 App 就会产生性能问题 ; 如果此时做 Window 动画 , 那么 system_server 的这些锁也会导致窗口动画卡顿。
Android P 修改了 Layer 的计算方法 , 把这部分放到了 SurfaceFlinger 主线程去执行, 如果后台 Layer 过多，就会导致 SurfaceFlinger 在执行 rebuildLayerStacks 的时候耗时 , 导致 SurfaceFlinger 主线程执行时间过长。
主线程执行 Input \ Animation \ Measure \ Layout \ Draw \ decodeBitmap 等操作超时都会导致卡顿 。
Activity resume 的时候, 与 AMS 通信要持有 AMS 锁, 这时候如果碰到后台比较繁忙的时候, 等锁操作就会比较耗时, 导致部分场景因为这个卡顿, 比如多任务手势操作。
应用里面涉及到 WebView 的时候, 如果页面比较复杂, WebView 的性能就会比较差, 从而造成卡顿。
如果屏幕帧率和系统的 fps 不相符 , 那么有可能会导致画面不是那么顺畅. 比如使用 90 Hz 的屏幕搭配 60 fps 的动画。
由上面的分析可知对象分配、垃圾回收(GC)、线程调度以及Binder调用 是Android系统中常见的卡顿原因，因此卡顿优化主要以下几种方法，更多的要结合具体的应用来进行：
在计算机和通信领域，帧是一个包括“帧同步串行”的数字数据传输单元或数字数据包。
在视频领域，电影、电视、数字视频等可视为随时间连续变换的许多张画面，其中帧是指每一张画面。
内存优化就是对内存问题的一个预防和解决，做内存优化能让应用挂得少、活得好和活得久。
挂的少：
“挂”指的是 Crash，内存问题导致 Crash 的具体表现就是内存溢出异常 OOM。
活得好：
活得好指的是使用流畅，Android 中造成界面卡顿的原因有很多种，其中一种就是由内存问题引起的。内存问题之所以会影响到界面流畅度，是因为垃圾回收（GC，Garbage Collection），在 GC 时，所有线程都要停止，包括主线程，当 GC 和绘制界面的操作同时触发时，绘制的执行就会被搁置，导致掉帧，也就是界面卡顿。
活得久：
活得久指的是我们的应用在后台运行时不会被干掉。Android 会按照特定的机制清理进程，清理进程时优先会考虑清理后台进程。清理进程的机制就是LowMemoryKiller。在 Android 中不同的进程有着不同的优先级，当两个进程的优先级相同时，低杀会优先考虑干掉消耗内存更多的进程。也就是如果我们应用占用的内存比其他应用少，并且处于后台时，我们的应用能在后台活下来，这也是内存优化为我们应用带来竞争力的一个直接体现。
内存占用是否越少越好？
当系统 内存充足 的时候，我们可以多用 一些获得更好的性能。当系统 内存不足 的时候，我们希望可以做到 ”用时分配，及时释放“。内存优化并不能一刀切。
我们都知道，应用程序的内存分配和垃圾回收都是由Android虚拟机完成的，在Android 5.0以下，使用的是Dalvik虚拟机，5.0及以上，则使用的是ART虚拟机。
Android虚拟机Dalvik和ART
1、内存区域划分
详细请看以下两篇文章（建议全看）：
java内存四大区_JVM内存区域划分
Android 内存机制
2、内存回收
垃圾收集的标记算法（找到垃圾）：
垃圾收集算法（回收垃圾）：
引用类型：强引用、软引用、弱引用、虚引用
对象的有效性=可达性+引用类型
JAVA垃圾回收机制-史上最容易理解看这一篇就够了
Android：玩转垃圾回收机制与分代回收策略
android中还存在低杀机制，这种情况属于系统整机内存不足，直接把应用进程杀掉的情况。
Android后台杀死系列：LowMemoryKiller原理
1、内存溢出
系统会给每个App分配内存空间也就是heap size值，当app占用的内存加上申请的内存超过这个系统分配的内存限额，最终导致OOM(OutOfMemory)使程序崩溃。
通过命令 getprop |grep dalvik.vm.heapsize 可以获取系统允许的最大
注意：在设置了heapgrowthlimit的状况下，单个进程可用最大内存为heapgrowthlimit值。在android开发中，若是要使用大堆，须要在manifest中指定android:largeHeap为true，这样dvm heap最大可达heapsize。
关于heapsize heapgrowthlimit
2、内存泄漏
Android系统虚拟机的垃圾回收是通过虚拟机GC机制来实现的。GC会选择一些还存活的对象作为内存遍历的根节点GC Roots，通过对GC Roots的可达性来判断是否需要回收。内存泄漏就是 在当前应用周期内不再使用的对象被GC Roots引用，造成该对象无法被系统回收，以致该对象在堆中所占用的内存单元无法被释放而造成内存空间浪费，使实际可使用内存变小。简言之，就是 对象被持有导致无法释放或不能按照对象正常的生命周期进行释放。
Android常见内存泄漏汇总
3、内存抖动
指的是在短时间内大量的新对象被实例化，运行时可能无法承载这样的内存分配，在这种情况下就会导致垃圾回收事件被大量调用，影响到应用程序的UI和整体性能，最终可能导致卡顿和OOM。
常见情况：在一些被频繁调用的方法内不断地创建对象。例如在View 的onDraw方法内new 一些新的对象。
注意内存抖动也会导致 OOM，主要原因有如下两点：
1、Android Studio Profiler
作用
优点
内存抖动问题处理实战
理解内存抖动的概念的话，我们就能明白只要能找到抖动过程中所产生的对象及其调用栈，我们就能解决问题，刚好Android Studio 的Porfiler里面的Memory工具就能帮我们记录下我们操作过程中或静止界面所产生的新对象，并且能清晰看到这些对象的调用栈。
选择Profile 中 的Memory ，选择 Record Java/Kotlin allocations，再点击Record开始记录， Record Java/Kotlin allocations 选项会记录下新增的对象。
操作完成之后，点击如图所示的红脑按钮，停止记录。
停止记录后，我们就可以排序（点击 Allocations可以排序）看看哪些对象或基本类型在短时间被频繁创建多个，点击这些新增的对象就可以看到它的完成的调用链了，进而就找找到导致内存抖动的地方在哪里了。
2、利用DDMS 和 MAT(Memory Analyzer tool)来分析内存泄漏
我们利用工具进行内存泄漏分析主要是用对比法：
a.先打开正常界面，不做任何操作，先抓取一开始的堆文件。
b.一顿胡乱操作，回到原来操作前的界面。主动触发一两次GC,过10秒再抓取第二次堆文件。
c.通过工具对比，获取胡乱操作后新增的对象，然后分析这些新增的对象。
DDMS作用:抓取堆文件，主动触发GC。（其实也是可以用Android Studio 的Profile里面的Memory工具来抓取堆文件的，但是我这边在利用Profile 主动触发gc 的时候会导致程序奔溃，也不知道是不是手机的问题，所以没用Android Studio的Profiler）
MAT作用：对堆文件进行对比，找到多出的对象，找到对象的强引用调用链。
以下是详细的过程：
步骤1.打开DDMS,选择需要调试的应用，打开初始界面，点击下图的图标（Dump Hprof File）先获取一次堆文件。
步骤2.对应用随便操作后，回到一开始的界面，先多触发几次GC ，点击下图的图标(Cause Gc)来主动触发GC,然后再次点击 Dump Hprof File 图标来获取堆文件。
步骤3.通过Android Studio Profile 或者 DDMS dump 的堆文件无法在MAT 打开，需要借助android sdk包下的一个工具hprof-conv.exe来转换。
格式为 hprof-conv 旧文件路径名 要转换的名称；
例如：hprof-conv 2022-04-13_17-54-40_827.hprof change.hprof
步骤4.把两份堆文件导入MAT,然后选择其中第二次获取的堆文件，点击 如图所示的 Histogram查看。
步骤5.点击下图图标，Compare To Another Heap Dump ,选择另一份堆文件。
6.会得出下图所示的 Hitogram 展示，我们主要看Objects 这一列。 如下图所示 “+ 2” 则代表前面两份堆文件对比，这个对象多了两个，我们主要就是要分析这些多了出来，没有被回收的对象。
7.加入我们从增加的对象中，看到了MainActivity ，则需要从一开始打开的Hitogram 展示里面找到这个对象的调用栈。如下图所示，搜索MainActivity
8.看到下图所示解雇，然后鼠标右键点击下图红色圈圈着的MainActivity ,选择 Merger Shortest Paths to Gc Roots ，再选择 exclude all phantom/weak/soft etc.references ,就可以看到这个MainActivity 对象的强引用链，至此我们就可以找到MainActivity对象是被什么引用导致无法回收了。
3、内存泄露检测神器之LeakCanary（线下集成）
自行学习了解，接入简单，使用简单，基本可以解决大部分内存泄漏问题。
github地址 ：
学习地址 ：
针对内存抖动的建议：
针对内存泄漏问题的建议：
针对内存溢出问题的建议（主要就是要减少内存占用）：
建议参考：
深入探索 Android 内存优化（炼狱级别）
对于 优化的大方向，我们应该优先去做见效快的地方，主要有以下三部分：内存泄漏、内存抖动、Bitmap。完善监控机制也是我们的重点，能帮助我们对内存问题快速分析和处理。
参考：
深入探索 Android 内存优化（炼狱级别）
通过上图先把用户-电量这一流程抽象出来，设备的耗电根本原因在于对硬件的使用，耗电越严重说明对硬件使用的越频繁。用户对app频繁使用说明了你用户黏性做的好，我们不能左右，所以我们要在app对硬件调用上做优化来达到节省电量的目的。
先看下移动设备元件耗电大户有哪些：
屏幕是耗电最大元件之一，但是用户要和app交互就要点亮屏幕，有人可能会觉得屏幕的明暗是用户自己根据喜好设定的，我们无可奈何。其实不然，在有些时候是可以通过UI的设计来减少屏幕电能消耗的。
在这之前我们先来看下目前常用手机屏幕材质：LCD和LED(OLED)。
无线网络主要是WIFI和移动运营商网络，通常情况下使用移动网络要比WIFI耗电要多一些。
这三种状态有一个转换流程：
通过上面了解网络连接过程，应该心里有了大概的优化建议。
精简后
①请求一个图片时，客户端提供一个分辨率大小，服务器根据分辨率把裁剪缩放后的图片给客户端返回。也可以使用Android端使用Bitmap.Option自行获取缩放的图片
②使用webp图片。
后面的章节会写一些关于电量检测分析工具的使用。
为了耗电优化干的这些活用户感知不到，但是如果不去优化，肆意使用，那用户就很容易感知到了。
常用的Android性能优化方法：
一、布局优化：
1）尽量减少布局文件的层级。
层级少了，绘制的工作量也就少了，性能自然提高。
2）布局重用 include标签
3）按需加载：使用ViewStub,它继承自View,一种轻量级控件，本身不参与任何的布局和绘制过程。他的layout参数里添加一个替换的布局文件，当它通过setVisibility或者inflate方法加载后，它就会被内部布局替换掉。
二、绘制优化：
基于onDraw会被调用多次，该方法内要避免两类操作：
1）创建新的局部对象，导致大量垃圾对象的产生，从而导致频繁的gc，降低程序的执行效率。
2）不要做耗时操作，抢CPU时间片，造成绘制很卡不流畅。
三、内存泄漏优化：
1）静态变量导致内存泄漏 比较明显
2）单例模式导致的内存泄漏 单例无法被垃圾回收，它持有的任何对象的引用都会导致该对象不会被gc。
3）属性动画导致内存泄漏 无限循环动画，在activity中播放，但是onDestroy时没有停止的话，动画会一直播放下去，view被动画持有，activity又被view持有，导致activity无法被回收。
四、响应速度优化：
1）避免在主线程做耗时操作 包括四大组件，因为四大组件都是运行在主线程的。
2）把一些创建大量对象等的初始化工作放在页面回到前台之后，而不应该放到创建的时候。
五、ListView的优化：
1）使用convertView，走listView子View回收的一套：RecycleBin 机制
主要是维护了两个数组，一个是mActiveViews,当前可见的view,一个是mScrapViews，当前不可见的view。当触摸ListView并向上滑动时，ListView上部的一些OnScreen的View位置上移，并移除了ListView的屏幕范围，此时这些OnScreen的View就变得不可见了，不可见的View叫做OffScreen的View，即这些View已经不在屏幕可见范围内了，也可以叫做ScrapView，Scrap表示废弃的意思，ScrapView的意思是这些OffScreen的View不再处于可以交互的Active状态了。ListView会把那些ScrapView（即OffScreen的View）删除，这样就不用绘制这些本来就不可见的View了，同时，ListView会把这些删除的ScrapView放入到RecycleBin中存起来，就像把暂时无用的资源放到回收站一样。
当ListView的底部需要显示新的View的时候，会从RecycleBin中取出一个ScrapView，将其作为convertView参数传递给Adapter的getView方法，从而达到View复用的目的，这样就不必在Adapter的getView方法中执行LayoutInflater.inflate()方法了。
RecycleBin中有两个重要的View数组，分别是mActiveViews和mScrapViews。这两个数组中所存储的View都是用来复用的，只不过mActiveViews中存储的是OnScreen的View，这些View很有可能被直接复用；而mScrapViews中存储的是OffScreen的View，这些View主要是用来间接复用的。
2）使用ViewHolder避免重复地findViewById
3)快速滑动不适合做大量异步任务，结合滑动监听，等滑动结束之后加载当前显示在屏幕范围的内容。
4）getView中避免做耗时操作，主要针对图片：ImageLoader来处理(原理：三级缓存)
5）对于一个列表，如果刷新数据只是某一个item的数据，可以使用局部刷新，在列表数据量比较大的情况下，节省不少性能开销。
六、Bitmap优化：
1）减少内存开支：图片过大，超过控件需要的大小的情况下，不要直接加载原图，而是对图片进行尺寸压缩，方式是BitmapFactroy.Options 采样，inSampleSize 转成需要的尺寸的图片。
2）减少流量开销：对图片进行质量压缩，再上传服务器。图片有三种存在形式：硬盘上时是file，网络传输时是stream，内存中是stream或bitmap，所谓的质量压缩，它其实只能实现对file的影响，你可以把一个file转成bitmap再转成file，或者直接将一个bitmap转成file时，这个最终的file是被压缩过的，但是中间的bitmap并没有被压缩。bitmap.compress(Bitmap.CompressFormat.PNG,100,bos);
七、线程优化：
使用线程池。为什么要用线程池？
1、从“为每个任务分配一个线程”转换到“在线程池中执行任务”
2、通过重用现有的线程而不是创建新线程，可以处理多个请求在创建销毁过程中产生的巨大开销
3、当使用线程池时，在请求到来时间 ，不用等待系统重新创建新的线程，而是直接复用线程池中的线程，这样可以提高响应性。
4、通过和适当调整线程池的大小 ，可以创建足够多的线程以使处理器能够保持忙碌状态，同时还可以防止过多线程相互竞争资源而使应用程序耗尽内存或者失败。
5、一个App里面所有的任务都放在线程池中执行后，可以统一管理 ，当应用退出时，可以把程序中所有的线程统一关闭，避免了内存和CPU的消耗。
6、如果这个任务是一个循环调度任务，你则必须在这个界面onDetach方法把这个任务给cancel掉，如果是一个普通任务则可cancel，可不cancel，但是最好cancel
7、整个APP的总开关会在应用退出的时间把整个线程池全部关闭。
八、一些性能优化建议：
1）避免创建过多对象，造成频繁的gc
2)不要过多使用枚举，枚举占用的空间比整型大很多
3）字符串的拼接使用StringBuffer、StringBuilder来替代直接使用String,因为使用String会创建多个String对象，参考第一条。
4）适当使用软引用，（弱引用就不太推荐了）
5）使用内存缓存和磁盘缓存。
Android启动应用, 按 官方说法 分为冷启动, 温启动和热启动.
具体的定义可以看官方文档, 简单地说
一般我们只需要关注冷启动即可.
要想启动快, 硬件性能必然有影响, 在硬件一定的前提下, 我们要尽量 降低启动应用时CPU的负载 , 让CPU有更多的算力投入到启动流程中:
在做好一些基本原则后, 接着看具体的流程优化点
在应用进程创建后, 首先必然是加载类, 此时一些静态变量就会初始化了, 因此我们应该
类加载完毕后就是创建 Application 实例了, 因此我们应该
之后会先创建 ContentProvider 和执行 ContentProvider.onCreate() , 因此我们应该
跟接着就会执行 Application.onCreate() 等方法, 因此我们应该
接着就进入 Activity 环节.
同样第一步会是创建实例, 因此我们应该
在 Activity 进程生命周期后, 第一步就是渲染(inflate)布局, 我们应该
在应用启动的瞬间, 系统服务会先展示一个空白窗口, 等待应用第一帧绘制完毕后, 再从该窗口切换到应用, 如果启动耗时较长, 就会明显看到白屏, 对于这一点, 常见的操作有
可以使用IdleHandler, 在主线程空闲时再执行某些不重要的操作
实际上异步初始化只是不阻塞主线程, 但是子线程一样会占用CPU资源, 让主线程的执行时间变少, 所以不应该盲目地将所有工作放到子线程.
优化做到最后, 就是在系统流程上做文章了
原理是将启动时加载的类放到主dex，提升了这些类的内聚，让更多的类满足pre-verify的条件，在安装时就做了校验和优化，以减少首次加载的耗时，从而优化冷启动耗时。
Redex 初探与 Interdex：Andorid 冷启动优化
应用启动过程中会从apk压缩包中读取文件, 该优化的原理是利用Linux中的Pagecache机制, 让启动过程会用到的文件尽可能进入缓存中, 减少磁盘IO次数
支付宝 App 构建优化解析：通过安装包重排布优化 Android 端启动性能
在Dalvik VM(Android5.0以前)加载类的时候会有一个类校验过程, 它需要校验方法的每一个指令, 是一个比较耗时的过程, 可以通过Hook去掉类加载过程中的类验证过程. 不过对于ART(Android5.0之后)来说, 这个过程在安装时已经做了, 所以用处不大.
不进入冷启动, 就不用优化了~
这个Android Studio自带的工具, 可以看到启动过程中详细的方法执行流程, 但是采集数据本身会影响方法执行, 所以不能准确判断每个方法的耗时, 但是仍可以判断哪个方法相对来说耗时.
这个工具的好处是可以自定义事件, 可以指定需要采集的数据集, 可以看到线程间的状态等.
启动优化的一个关键点在于定义启动结束的点, 以及如何测量启动时间.
在Android4.4以上, 系统进程会提供一个类似 ActivityManager: Displayed ***: +3s534ms 的日志, 表示从启动进程到首次绘制完毕所用的时间.
应用可以在任何时候调用该方法, 触发系统打印类似 system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms 的日志
应用可以通过 ViewTreeObserver 来监听绘制前回调来判断第一帧的绘制时机, 或者直接在控件树的末尾加一个简单的View, 它 onDraw 调用时即表示页面(差不多)绘制完毕.
应用启动过程可以参考 Android Vitals Series' Articles 系列文章
1. 手机一键优化 ：包含内存占用、手机存储、系统内存优化、垃圾文件清理四个选择，点击“一键优化”即可。不仅可以显著的提高手机运行速度，还可以节省存储卡空间、降低手机CPU使用率，不再纠结于智能手机的卡吧-死机- -!
使用窍门:手机开机一段时间后或者玩大型游戏前点一下，最简单最快速提升系统性能和速度。
2. 清理网络缓存 ：网络程序占用的缓存管理，可以节省手机内存空间和提高上网速度。很常遇到的'一个现象，APK安装包体积很少，但运行一段时间后缺累积了上M的缓存，导致整体在手机内存空间占用率高，内存空间越少，系统所能装的软件就会越少了，经常性的清理网络缓存能使您的手机能装更多的软件。
单个操作：点击程序图标进入，点击“清除缓存”即可清理该程序缓存，点击手机“返回”按键，即可返回系统优化界面。
批量操作：点击“清理网络缓存”按钮进入，点击“清除缓存”即可清理当前程序缓存，点击手机“返回”按键，即可进入下一个程序操作界面，所有程序清理完成后，点击手机“返回”按键，返回系统优化界面。
3. 默认程序管理 ：管理手机系统默认的执行程序，比如上网默认打开的浏览器(ucweb,QQ浏览器等)、音乐默认播放程序(酷狗，天天动听)等。目前暂时只支持单个设置。
单个操作：点击程序图标进入，点击“清除默认设置”即可，点击手机“返回”按键，即可返回系统优化界面。
批量操作：点击“重置以上默认打开程序”进入，点击“清除默认设置”即可清除当前程序设置，点击手机“返回”按键，即可进入下一个程序操作界面，所有程序清理完成后，点击手机“返回”按键，返回系统优化界面。
4. 手机节电优化 ：可以进行节电优化和查看电视状态、使用详情。
点击“节点优化(21项)”进入，可以看到21条android手机节点秘籍，根据文字操作即可，让你的手机拥有超长的待机时间。
