android优化方案

A. 手机太卡了,怎么办

如果您使用的是华为手机，手机升级系统后短时间内出现卡顿，属于正常现象，如果并非刚升级完出现，请按照以下方案排查：
温馨提醒：升级系统后卡顿原因：由于系统升级后刚开始使用时，系统会对手机中的应用程序进行优化，此时手机负载较高，使用时可能会出现卡顿情况。建议升级完成后将手机灭屏充电2小时以上，然后重启手机以保证手机内已安装的应用优化完成。
1. 检查手机是否正在下载、复制、传输等操作
如果手机正在执行上传下载（文件、图片、视频、应用等）、复制（文件管理拷贝数据等）、传输（手机克隆、Huawei Share等）等操作时感觉到卡顿，建议您等待任务结束或停止此操作。
提示：您可以下拉状态栏查看上传、下载、传输文件的进度。
2. 重启手机
请您重启手机后尝试。建议您2~3天重启一次手机，重启能有效的清理缓存，缓解卡顿现象。
3. 检查手机是否发热或者充电时使用
手机发热严重时性能下降出现卡顿。建议您尽量避免充电时使用手机，适当降低屏幕亮度，关闭不使用或异常耗电应用与功能，如“蓝牙”，NFC等。
4. 检查存储卡
（1）可能是存储卡存储的文件过多（建议预留10%以上空间），导致读写速度慢，建议您清理存储卡空间，或备份重要数据(QQ、微信等第三方应用需单独备份)后格式化存储卡。
（2）可能是存储卡硬件异常，是否曾提示“存储卡异常”，若是，建议您尽快更换存储卡。
（3）若手机的默认存储位置为存储卡，建议您将默认存储位置更改为“内部存储”后尝试。
5. 关闭省电模式、保持电量充足
如果您开启了省电模式，建议您关闭（设置 > 电池 > 省电模式和 超级省电），并保持电量充足（20%以上）。省电模式和低电量情况下，手机会降低性能以节省电量。
6. 清理存储空间
手机运行内存和存储空间不足时会导致应用卡顿，建议您进入手机管家进行清理：
（1）进入手机管家点击一键优化/立即优化，优化完毕后，手机管家会显示优化结果以及设置建议。根据提示，完成相应的设置。
（2）进入手机管家点击清理加速，待扫描完毕后，点击清理项后的立即清理，根据提示删除多余的文件，并卸载不常用的应用，保持存储空间充足（建议预留20%以上）。
7. 卸载第三方手机管家类软件
如果您的手机装有第三方手机管理类型的软件，请卸载此类应用后尝试。通常此类软件与手机自带的手机管家存在冲突，会导致运行卡顿。
8. 升级系统版本
（1）如果手机已经 Root，请恢复成官方稳定版本使用，详情请致电华为客服咨询。
（2）建议您及时进行手机系统更新，并将应用升级到最新版本。新版本会对系统性能进行优化提升。更新方法：进入手机设置，搜索进入软件更新，点击检查更新。
提示：恢复版本和升级系统版本会造成数据丢失，请您提前备份好数据(QQ、微信等第三方应用需单独备份)。
9. 恢复出厂设置
请您备份重要数据(QQ、微信等第三方应用需单独备份)，将手机恢复出厂设置后重试。
如果问题仍然存在，请您备份好数据后(QQ、微信等第三方应用需单独备份)携带购机凭证前往华为客户服务中心进行检测处理。
温馨提醒：您可以选择夜间充电（或灭屏充电40min以上），可以一定程度上整理手机内存碎片，缓解卡顿现象。

B. 在Android开发中，有哪些好的内存优化方式

1. 使用更加轻量的数据结构

例如，我们可以考虑使用ArrayMap/SparseArray而不是HashMap等传统数据结构。通常的HashMap的实现方式更加消耗内存，因为它需要一个额外的实例对象来记录Mapping操作。另外，SparseArray更加高效，在于他们避免了对key与value的自动装箱（autoboxing），并且避免了装箱后的解箱。
2. 避免在Android里面使用Enum
Android官方培训课程提到过“Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.”，具体原理请参考《Android性能优化典范（三）》，所以请避免在Android里面使用到枚举。
3. 减小Bitmap对象的内存占用
Bitmap是一个极容易消耗内存的大胖子，减小创建出来的Bitmap的内存占用可谓是重中之重，，通常来说有以下2个措施：
inSampleSize：缩放比例，在把图片载入内存之前，我们需要先计算出一个合适的缩放比例，避免不必要的大图载入。
decode format：解码格式，选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异
4.Bitmap对象的复用
缩小Bitmap的同时，也需要提高BitMap对象的复用率，避免频繁创建BitMap对象，复用的方法有以下2个措施
LRUCache : “最近最少使用算法”在Android中有极其普遍的应用。ListView与GridView等显示大量图片的控件里，就是使用LRU的机制来缓存处理好的Bitmap，把近期最少使用的数据从缓存中移除，保留使用最频繁的数据，
inBitMap高级特性:利用inBitmap的高级特性提高Android系统在Bitmap分配与释放执行效率。使用inBitmap属性可以告知Bitmap解码器去尝试使用已经存在的内存区域，新解码的Bitmap会尝试去使用之前那张Bitmap在Heap中所占据的pixel data内存区域，而不是去问内存重新申请一块区域来存放Bitmap。利用这种特性，即使是上千张的图片，也只会仅仅只需要占用屏幕所能够显示的图片数量的内存大小
4. 使用更小的图片
在涉及给到资源图片时，我们需要特别留意这张图片是否存在可以压缩的空间，是否可以使用更小的图片。尽量使用更小的图片不仅可以减少内存的使用，还能避免出现大量的InflationException。假设有一张很大的图片被XML文件直接引用，很有可能在初始化视图时会因为内存不足而发生InflationException，这个问题的根本原因其实是发生了OOM。

5.StringBuilder
在有些时候，代码中会需要使用到大量的字符串拼接的操作，这种时候有必要考虑使用StringBuilder来替代频繁的“+”。
6.避免在onDraw方法里面执行对象的创建
类似onDraw等频繁调用的方法，一定需要注意避免在这里做创建对象的操作，因为他会迅速增加内存的使用，而且很容易引起频繁的gc，甚至是内存抖动。
7. 避免对象的内存泄露
类的静态变量持有大数据对象
静态变量长期维持到大数据对象的引用，阻止垃圾回收。
非静态内部类存在静态实例
非静态内部类会维持一个到外部类实例的引用，如果非静态内部类的实例是静态的，就会间接长期维持着外部类的引用，阻止被回收掉。
资源对象未关闭
资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们， 以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内，还存在于java虚拟机外。 如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。
解决办法： 比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，它自己会调close()关闭）， 如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。 因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null. 在我们的程序退出时一定要确保我们的资源性对象已经关闭。 程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小， 对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险，记得try catch后，在finally方法中关闭连接
Handler内存泄漏
Handler作为内部类存在于Activity中，但是Handler生命周期与Activity生命周期往往并不是相同的，比如当Handler对象有Message在排队，则无法释放，进而导致本该释放的Acitivity也没有办法进行回收。

C. android 大量多线程怎么优化

在程序开发的实践当中，为了让程序表现得更加流畅，我们肯定会需要使用到多线程来提升程序的并发执行性能。但是编写多线程并发的代码一直以来都是一个相对棘手的问题，所以想要获得更佳的程序性能，我们非常有必要掌握多线程并发编程的基础技能。
众所周知，Android 程序的大多数代码操作都必须执行在主线程，例如系统事件(例如设备屏幕发生旋转)，输入事件(例如用户点击滑动等)，程序回调服务，UI 绘制以及闹钟事件等等。那么我们在上述事件或者方法中插入的代码也将执行在主线程。

一旦我们在主线程里面添加了操作复杂的代码，这些代码就很可能阻碍主线程去响应点击/滑动事件，阻碍主线程的 UI 绘制等等。我们知道，为了让屏幕的刷新帧率达到 60fps，我们需要确保 16ms 内完成单次刷新的操作。一旦我们在主线程里面执行的任务过于繁重就可能导致接收到刷新信号的时候因为资源被占用而无法完成这次刷新操作，这样就会产生掉帧的现象，刷新帧率自然也就跟着下降了(一旦刷新帧率降到 20fps 左右，用户就可以明显感知到卡顿不流畅了)。

为了避免上面提到的掉帧问题，我们需要使用多线程的技术方案，把那些操作复杂的任务移动到其他线程当中执行，这样就不容易阻塞主线程的操作，也就减小了出现掉帧的可能性。

那么问题来了，为主线程减轻负的多线程方案有哪些呢？这些方案分别适合在什么场景下使用？Android 系统为我们提供了若干组工具类来帮助解决这个问题。
AsyncTask: 为 UI 线程与工作线程之间进行快速的切换提供一种简单便捷的机制。适用于当下立即需要启动，但是异步执行的生命周期短暂的使用场景。
HandlerThread: 为某些回调方法或者等待某些任务的执行设置一个专属的线程，并提供线程任务的调度机制。
ThreadPool: 把任务分解成不同的单元，分发到各个不同的线程上，进行同时并发处理。
IntentService: 适合于执行由 UI 触发的后台 Service 任务，并可以把后台任务执行的情况通过一定的机制反馈给 UI。
了解这些系统提供的多线程工具类分别适合在什么场景下，可以帮助我们选择合适的解决方案，避免出现不可预期的麻烦。虽然使用多线程可以提高程序的并发量，但是我们需要特别注意因为引入多线程而可能伴随而来的内存问题。举个例子，在 Activity 内部定义的一个 AsyncTask，它属于一个内部类，该类本身和外面的 Activity 是有引用关系的，如果 Activity 要销毁的时候，AsyncTask 还仍然在运行，这会导致 Activity 没有办法完全释放，从而引发内存泄漏。所以说，多线程是提升程序性能的有效手段之一，但是使用多线程却需要十分谨慎小心，如果不了解背后的执行机制以及使用的注意事项，很可能引起严重的问题。

D. 安卓软件对于硬件的优化是如何进行的

首先，通过题主给的例子是无法证明Android上的游戏对硬件优化有问题的。

i9500的GPU是SGX544MP3；iPhone 5的GPU是SGX543MP3。
这两者的差别据我所知仅在与对DirectX的支持。
i9500上GPU的实际运行频率为480MHz（跑分或运行一部分自带应用时会“超频”到533MHz）；iPhone 5上则大概在333MHz左右。从这一点上来看GS4确实还是有明显的优势。

最重要的一点在于，GS4的有着一块分辨率为1920*1080的屏幕，一共有2073600个像素，iPhone 5的分辨率仅为1136*640，像素数目是727040，只比GS4像素数目的1/3多那么一点。

在理想的极端条件下，同样的3D渲染对GS4的GPU施加的压力三倍于对iPhone 5的压力；在现实中，更高的像素数目对内存带宽比对GPU本身相更为敏感。

Exynos 5410的内存带宽高达12.8GB/s，确实相当高，但iPhone 5虽然只有1/3于GS的像素数目也有不低的8.5GB/s带宽。

事实上，即使是iPad 4，配备了明显更为强大的SGX554MP4 GPU，并具备其他移动设备难望其项背的17GB/s内存带宽，在2048*1536=3145728个像素的重压下，以原生分辨率运行大型3D游戏的时候表现也只能说差强人意。

然后，我就谈谈Android上的游戏对硬件优化到底有什么问题。

我觉得可能是唯一也是最大的问题，碎片化——所有iOS设备使用的都是PowerVR系列的GPU，但是Android上的GPU，光是常见的就有:PowerVR，Adreno，Mail和GeForce四家，游戏很难全面地优化。

比如说，去年年底之前Android市场上最强大的GPU是Exynos 4上的Mail 400MP4，不论是Tegra 3还是Adreno 225在性能上都要弱很多。于是乎当时的游戏几乎都只给Exynos 4优化，反正因为性能问题在其他的GPU上跑高画质也不可能流畅。到了年底APQ8064上市，Adreno 320成为了新的王者，但是不少游戏在Adreno 320上的画质却还不如Mail 400。到现在，用Adreno 320的设备越来越多，也有越来越多的游戏为其优化，尴尬的一方变成了i9500上的PowerVR——Android市场上的上一款流行的PowerVR GPU是性能连SGX544MP3的零头都赶不上的SGX540。

Android 4.3率先支持OpenGL ES 3.0标准可以看做是Google对GPU碎片化所提出的解决方案。OpenGL ES 3.0使得不同系列的GPU都可以使用统一的ETC2贴图格式，降低了分裂的程度。但是Android 4.3离普及还非常遥远，另一方面硬件对OpenGL ES 3.0的支持也比较少，比如说PowerVR 5系列就只支持OpenGL ES 2.0，6系列才能支持3.0。而且就算API统一了，想要“完美”地优化每一款GPU也是不可能的任务，不同的设计会有不同的专长。比如说Adreno系列GPU的Shader性能特别的强，如果一个游戏特别注重运用Shader的话在Adreno系列上的表现会明显比在同档次其他GPU上好。现实是，多数游戏还是优先为iOS设备上的PowerVR设计的，并不会运用那么多的Shader特效。

E. 如何对Android客户端性能优化

为什么我们的App需要优化，最显而易见的时刻：用户say，什么狗屎，刷这么久都没反应，取关卸载算了。
这跟什么有关，我们先苍白的反驳下，尼玛用户设备老旧网又烂，关我屁事，根本不用优化。可是，老板拍板了，施压给CTO，然后CTO又来找你：Y的今天必须给我想办法优化了，不然不准回家。
好吧，为什么从UI的表象上看，App又卡又慢而且还错乱。我们试着来剖析下吧。
题外话：把minSDK改到4.0＋，去特么的low用户，连手机都不愿意换，还能指望它能给你带来多少营收么，直接pass掉吧。4.0前的系统bug不少，不能为了弥补这些bug而降低了整体的高性能。
好了，让我们先从UI说起：
首先要明白的是UI的绘制流程：measure-layout-draw，measure与layout都需要for loop所有的子控件，汇集起来才能完成绘制，布局。所以子控件越多，所消耗的时间越长(inflate，layout_weight，relative，多层嵌套等)，减少不必要的子控件或层级，是相当有必要的。你可以通过merge,viewstub这些标签来减少层级嵌套。如果你的空间观念没那么好，可以用HierarchyViewer工具来检查。
对于Listview或者GridView这种多item的组件来说，复用item可以减少inflate次数，通过setTag，getTag的ViewHolder方式实现复用，这里要注意的是，holder中的控件最好reset后再赋值，避免图片，文字错乱。
对于ViewPager第一次显示时卡顿以及左右滑动卡顿，有以下几种优化方式：

ViewPager同时缓存page数最好为最小值3，如果过多，那么第一次显示时，ViewPager所初始化的pager就会很多，这样pager累积渲染耗时就会增多，看起来就卡。
每个pager应该只在显示时才加载网络或数据库(UserVisibleHint=true)，最好不要预加载数据，以免造成浪费
图片显示不出来或者加载时间太长，怎么办？分两部分，下载速度，加载速度。

对于下载，要控制好同时下载的最大任务数(平均速度慢)，同时给InputStream再包一层缓冲流会更快(如BufferedInputStream)。
对于加载速度，我们要知道一点，虽然下载的图片可能只有几百K，但是decode成bitmap所占用的内存可是成倍的，尽可能的减小图片size是根本因素，让服务端提供不同分辨率的图片才是最好的解决方案，内存总有耗尽的时刻，别老想着大分辨率会更清晰，实际就只有150*150的空间，非给弄张1000*1000的图片是不恰当的。另外论加载速度：内存>硬盘>网络，合理的使用内存缓存也是关键。假如自己写不好，没关系，有那么多开源的图片缓存框架，不用自己操心。
再说缓存
有很多种缓存方式，也不用Stay列举了，我们要说的是搭配使用。

比方说，以前我们一直在用强引用，HashMap，后来我们发现占内存，我们就用软引用，弱引用来及时回收，再后来因为回收机制不可控，所以又有了lrucache，disklrucache通过算法来平衡内存与硬盘缓存。随着android版本的推进与演化，我们也应该拥抱变化。如果你的App里还有软引用，弱引用的地方，不妨再check下。
比方说网络＋数据库。网络我们一般都是去主动获取，而非被动接受。那如果说数据是重复的或者未更改的呢？那我们去取一次网络数据有什么意义呢？我的解决方案是给每个activity或fragment或每个组件设置一个最大请求间隔，比如一个listview，第一次请求数据时，保存一份到数据库，并记下时间戳，当下次重新初始化时，判断是否超过最大时间间隔(如5分钟)，如果没有，只加载数据库数据，不需要再做网络请求。当然，还有一些隐式的http请求框架会缓存服务器数据，在一定时间内不再请求网络，或者当服务器返回304时将之前缓存的数据直接返回。
反正也说到网络了，那我们也来说说

现在有很多现成HTTP框架供我们使用，我们几乎只用写配置就可以搞定一个url请求，但是这里有很多需要服务端配合的，比如：json数据格式，WebP代替jpg，支持断点续传，多个请求合并成一个，尽量不做重定向，服务器缓存以及负载均衡等。
对客户端本身，除了上述的实现，我们还需要合理的缓存，控制最大请求并发量，及时取消已失效的请求，过滤重复请求，timeout时间设置，请求优先级设置等。
优化可不是一个人的事，实现一个功能简单，但是想优化重构，那是很不容易的事。需要多方面的预判与联调。合理的假设与实践是优化最重要的手段。
说完这些具体的点，我们再来说说一些常识，或者称之为代码规范。

你要知道for loop中不要声明临时变量，不到万不得已不要在里面写try catch。
明白垃圾回收机制，避免频繁GC，内存泄漏，OOM(有机会专门说)
合理使用数据类型，比如StringBuilder代替String，(笔试题最常见的是str+="str"中有几个对象) ，少用枚举enum，少用父类声明(List,Map)
如果你有频繁的new线程，那最好通过线程池去execute它们，减少线程创建开销。
你要知道单例的好处，并正确的使用它。
多用常量，少用显式的"action_key"，并维护一个常量类，别重复声明这些常量。
如果可以，至少要弄懂设计模式中的策略模式，组合模式，装饰模式，工厂模式，观察者模式，这些能帮助你合理的解耦，即使需求频繁变更，你也不用害怕牵一发而动全身。需求变更不可怕，可怕的是没有在写代码之前做合理的设计。
当然还有很多很多，Stay所说的也只是一个大的轮廓，还是需要自己不断的尝试。会开发写代码跟会做产品的区别还是蛮大的，仅仅是态度就能刷死80%的码农了。当你碰到一些需要优化的地方，耐心的去分析，时间的累积会让你成为真正的工程师。
另外优化也没有绝对的完美，每一次优化都是基于当前的环境来做的，要明白沟通是最好的优化，不盲从，不随便，三思而后行。
Android上如何做性能优化的？大概写三年代码就能差不多知道了。

F. Android应用性能优化的内容简介

今天的Android应用开发者经常要想尽办法来提升程序性能。由于应用越来越复杂，这个问题也变得越来越棘手。本书主要介绍如何快速高效地优化应用，让应用变得稳定高效。你将学会利用Android SDK和NDK来混合或单独使用Java、C/C++来开发应用。书中还特别讲解了如下内容：
· 一些OpenGL的优化技术以及RenderScript（Android的新特性）的基础知识；
· 利用SDK来优化应用的Java代码的技巧；
· 通过高效使用内存来提升性能的技巧；
· 延长电池使用时间的技巧；
· 使用多线程的时机及技巧；
· 评测剖析代码的技巧。
把本书的内容学以致用，你的编程技术就会得到关键性的提升，写出的应用就会更为健壮高效，从而广受用户好评，并最终获得成功。
目录
第1章Java代码优化1.1Android如何执行代码1.2优化斐波纳契数列1.2.1从递归到迭代1.2.2BigInteger1.3缓存结果1.4API等级1.5数据结构1.6响应能力1.6.1推迟初始化1.6.2StrictMode1.7SQLite1.7.1SQLite语句1.7.2事务1.7.3查询
第1章Java代码优化1.1Android如何执行代码1.2优化斐波纳契数列1.2.1从递归到迭代1.2.2BigInteger1.3缓存结果1.4API等级1.5数据结构1.6响应能力1.6.1推迟初始化1.6.2StrictMode1.7SQLite1.7.1SQLite语句1.7.2事务1.7.3查询1.8总结
第2章NDK入门2.1NDK里有什么2.2混合使用Java和C/C++代码2.2.1声明本地方法2.2.2实现JNI粘合层2.2.3创建Makefile2.2.4实现本地函数2.2.5编译本地库2.2.6加载本地库2.3Application.mk2.3.1为(几乎)所有设备优化2.3.2支持所有设备2.4Android.mk2.5使用C/C++改进性能2.6本地Acitivity2.6.1构建缺失的库2.6.2替代方案2.7总结
第3章NDK进阶3.1汇编3.1.1最大公约数3.1.2色彩转换3.1.3并行计算平均值3.1.4ARM指令3.1.5ARM NEON3.1.6CPU特性3.2C扩展3.2.1内置函数3.2.2向量指令3.3技巧3.3.1内联函数3.3.2循环展开3.3.3内存预读取3.3.4用LDM/STM替换LDR/STD3.4总结
第4章高效使用内存4.1说说内存4.2数据类型4.2.1值的比较4.2.2其他算法4.2.3数组排序4.2.4定义自己的类4.3访问内存4.4排布数据4.5垃圾收集4.5.1内存泄漏4.5.2引用4.6API4.7内存少的时候4.8总结
第5章多线程和同步5.1线程5.2AsyncTask5.3Handler和Looper5.3.1Handler5.3.2Looper5.4数据类型5.5并发5.6多核5.6.1为多核修改算法5.6.2使用并发缓存5.7Activity生命周期5.7.1传递信息5.7.2记住状态5.8总结
第6章性能评测和剖析6.1时间测量6.1.1System.nanoTime()6.1.2Debug.threadCpuTimeNanos()6.2方法调用跟踪6.2.1Debug.startMethodTracing()6.2.2使用Traceview工具6.2.3DDMS中的Traceview6.2.4本地方法跟踪6.3日志6.4总结
第7章延长电池续航时间7.1电池7.2禁用广播接收器7.3网络7.3.1后台数据7.3.2数据传输7.4位置7.4.1注销监听器7.4.2更新频率7.4.3多种位置服务7.4.4筛选定位服务7.4.5最后已知位置7.5传感器7.6图形7.7提醒7.8WakeLock7.9总结
第8章图形8.1布局优化8.1.1相对布局8.1.2合并布局8.1.3重用布局8.1.4ViewStub8.2布局工具8.2.1层级视图8.2.2layoutopt8.3OpenGL ES8.3.1扩展8.3.2纹理压缩8.3.3Mipmap8.3.4多APK8.3.5着色8.3.6场景复杂性8.3.7消隐8.3.8渲染模式8.3.9功耗管理8.4总结
第9章RenderScript9.1概览9.2Hello World9.3Hello Rendering9.3.1创建渲染脚本9.3.2创建RenderScriptGL Context9.3.3展开RSSurfaceView9.3.4设置内容视图9.4在脚本中添加变量9.5HelloCompute9.5.1Allocation9.5.2rsForEach9.5.3性能9.6自带的RenderScript API9.6.1rs_types.rsh9.6.2rs_core.rsh9.6.3rs_cl.rsh9.6.4rs_math.rsh9.6.5rs_graphics.rsh9.6.6rs_time.rsh9.6.7rs_atomic.rsh9.7RenderScript与NDK对比9.8总结

G. 针对Android的性能优化集中哪些方面

一、概要：

本文主要以Android的渲染机制、UI优化、多线程的处理、缓存处理、电量优化以及代码规范等几方面来简述Android的性能优化

二、渲染机制的优化：

大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能。

Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染， 如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps，为了能够实现60fps，这意味着程序的大多数操作都必须在16ms内完成。

*关于JobScheler的更多知识可以参考http://hukai.me/android-training-course-in-chinese/background-jobs/scheling/index.html

七、代码规范

1）for loop中不要声明临时变量，不到万不得已不要在里面写try catch。

2）明白垃圾回收机制，避免频繁GC，内存泄漏，OOM(有机会专门说)

3）合理使用数据类型，StringBuilder代替String，少用枚举enum，少用父类声明(List,Map)

4）如果你有频繁的new线程，那最好通过线程池去execute它们，减少线程创建开销。

5）你要知道单例的好处，并正确的使用它。

6）多用常量，少用显式的"action_key"，并维护一个常量类，别重复声明这些常量。

7）如果可以，至少要弄懂设计模式中的策略模式，组合模式，装饰模式，工厂模式，观察者模式，这些能帮助你合理的解耦，即使需求频繁变更，你也不用害怕牵一发而动全身。需求变更不可怕，可怕的是没有在写代码之前做合理的设计。

8）View中设置缓存属性.setDrawingCache为true.

9）cursor的使用。不过要注意管理好cursor,不要每次打开关闭cursor.因为打开关闭Cursor非常耗时。Cursor.require用于刷cursor.

10）采用SurfaceView在子线程刷新UI,避免手势的处理和绘制在同一UI线程（普通View都这样做）

11）采用JNI，将耗时间的处理放到c/c++层来处理

12）有些能用文件操作的，尽量采用文件操作，文件操作的速度比数据库的操作要快10倍左右

13）懒加载和缓存机制。访问网络的耗时操作启动一个新线程来做，而不要再UI线程来做

14）如果方法用不到成员变量，可以把方法申明为static，性能会提高到15%到20%

15）避免使用getter/setter存取field，可以把field申明为public，直接访问

16）私有内部类要访问外部类的field或方法时,其成员变量不要用private，因为在编译时会生成setter/getter,影响性能。可以把外部类的field或方法声明为包访问权限

17）合理利用浮点数，浮点数比整型慢两倍

18）针对ListView的性能优化，ListView的背景色与cacheColorHint设置相同颜色，可以提高滑动时的渲染性能。ListView中getView是性能是关键，这里要尽可能的优化。

getView方法中要重用view；getView方法中不能做复杂的逻辑计算，特别是数据库操作，否则会严重影响滑动时的性能

19）不用new关键词创建类的实例，用new关键词创建类的实例时，构造函数链中的所有构造函数都会被自动调用。但如果一个对象实现了Cloneable接口，我们可以调用它的clone()方法。

clone()方法不会调用任何类构造函数。在使用设计模式（Design Pattern）的场合，如果用Factory模式创建对象，则改用clone()方法创建新的对象实例非常简单。例如，下面是Factory模式的一个典型实现：

20）public static Credit getNewCredit() {
return new Credit();
}
改进后的代码使用clone()方法，如下所示：
private static Credit BaseCredit = new Credit();
public static Credit getNewCredit() {
return (Credit) BaseCredit.clone();
}
上面的思路对于数组处理同样很有用。

21）乘法和除法

考虑下面的代码：

22）ViewPager同时缓存page数最好为最小值3，如果过多，那么第一次显示时，ViewPager所初始化的pager就会很多，这样pager累积渲染耗时就会增多，看起来就卡。

23）每个pager应该只在显示时才加载网络或数据库(UserVisibleHint=true)，最好不要预加载数据，以免造成浪费

24）提高下载速度：要控制好同时下载的最大任务数，同时给InputStream再包一层缓冲流会更快(如BufferedInputStream)

25）提供加载速度：让服务端提供不同分辨率的图片才是最好的解决方案。还有合理使用内存缓存，使用开源的框架

引用：Android性能优化的浅谈

H. Android 性能优化的方法是什么请从开发者的角度回答！

常我们写程序，都是在项目计划的压力下完成的，此时完成的代码可以完成具体业务逻辑，但是性能不一定是最优化的。一般来说，优秀的程序员在写完代码
之后都会不断的对代码进行重构。重构的好处有很多，其中一点，就是对代码进行优化，提高软件的性能。下面我们就从几个方面来了解Android开发过程中
的代码优化。
1）静态变量引起内存泄露

在代码优化的过程中，我们需要对代码中的静态变量特别留意。静态变量是类相关的变量，它的生命周期是从这个类被声明，到这个类彻底被垃圾回收器回收
才会被销毁。所以，一般情况下，静态变量从所在的类被使用开始就要一直占用着内存空间，直到程序退出。如果不注意，静态变量引用了占用大量内存的资源，造
成垃圾回收器无法对内存进行回收，就可能造成内存的浪费。

先来看一段代码，这段代码定义了一个Activity。

复制代码 代码如下:

private static Resources mResources;
@Override

protected void onCreate(Bundle state) {

super.onCreate(state);

if (mResources == null) {

mResources = this.getResources();

}

}

这段代码中有一个静态的Resources对象。代码片段mResources =
this.getResources()对Resources对象进行了初始化。这时Resources对象拥有了当前Activity对象的引
用，Activity又引用了整个页面中所有的对象。
如果当前的Activity被重新创建（比如横竖屏切换，默认情况下整个Activity会被重新创建），由于Resources引用了第一次创建
的Activity，就会导致第一次创建的Activity不能被垃圾回收器回收，从而导致第一次创建的Activity中的所有对象都不能被回收。这个
时候，一部分内存就浪费掉了。

经验分享：

在实际项目中，我们经常会把一些对象的引用加入到集合中，如果这个集合是静态的话，就需要特别注意了。当不需要某对象时，务必及时把它的引用从集合中清理掉。或者可以为集合提供一种更新策略，及时更新整个集合，这样可以保证集合的大小不超过某值，避免内存空间的浪费。

2）使用Application的Context

在Android中，Application
Context的生命周期和应用的生命周期一样长，而不是取决于某个Activity的生命周期。如果想保持一个长期生命的对象，并且这个对象需要一个
Context，就可以使用Application对象。可以通过调用Context.getApplicationContext()方法或者
Activity.getApplication()方法来获得Application对象。

依然拿上面的代码作为例子。可以将代码修改成下面的样子。

复制代码 代码如下:

private static Resources mResources;
@Override

protected void onCreate(Bundle state) {

super.onCreate(state);

if (mResources == null) {

// mResources = this.getResources();

mResources = this.getApplication().getResources();

}

}

在这里将this.getResources()修改为
this.getApplication().getResources()。修改以后，Resources对象拥有的是Application对象的引
用。如果Activity被重新创建，第一次创建的Activity就可以被回收了。

I. 安卓手机性能差怎么办 优化方法都有哪些

安卓手机优化可以借助一些优化软件来对手机进行优化，可以通过腾讯手机管家上面的手机优化功能来对手机进行优化，进入主页面，点击一键优化，就可以关闭后台运行程序，清理手机内存，和检测开机自启软件等，优化手机的额性能。