android 性能优化相关整理

十大技巧快速提升原生App开发性能

---

移动应用市场用户争夺战日益激烈，原来做App拼想法拼创意拼是否抓住用户痛点。现在，精细化用户体验成为了一个App能否留存用户的关键问题，一旦用户觉得体验不畅，马上就有竞品App后补，如何开发高性能的移动应用，小编总结了以下十大技巧：

1. 规划好应用功能，做好应用架构评估

用户体验开始于App开发初始规划阶段，当你梦想开发一个App改变世界之前，先想好App主要解决用户的哪些真实需求，提炼出App的核心功能，一个App并不是功能越丰富越好，核心功能才能为用户带来不可替代的价值。

想清楚核心功能，才能做好应用架构评估。应用程序性能不佳可能是因为可扩展性限制、不匹配的技术选择、低效的网络配置以及UI设计不符合移动端使用习惯等因素，清晰完整的App架构规划有利于构建用户所需的系统功能构建。

2. 良好的编程习惯

良好的编程习惯不仅可以使程序代码易于读懂和修改，还可以使程序结构合理、清晰。开发人员可以从程序结构模块化、命名规则清晰易懂、注释方法简洁明了，文本格式易读等方面开始养成良好习惯，让应用开发事半功倍，提高程序的执行效率。

3. 改善程序启动和响应的时间

为了加快App响应速度，我们可以在UI线程上创建足够的对象，以便完善公共API功能。然后将功夫用到后台线程上，将费时的操作从主线移动到一个单独线程中，缓存从磁盘存储打开和阅读，客户端证书在后台加载。Cookies反序列化和解码在后台。通过这些改变，UI将更快地出现在屏幕上。

4. 使用最新版本的软件开发SDK、API

随着Android、ios平台的不断发展，平台提供的功能也在不断更新，一些功能可能被新功能完全替代。核心API得到修正版(bug fix)和性能改进。帮助开发者编写出运行更稳定、响应更迅速的应用程序。

5. 使用SuperWebView，让App支持动态更新

已经上线的App在需要更新新功能时，可以使用APICloud平台的SuperWebView功能，基于SuperWebView开发的功能支持动态更新，可以绕过应用商店的审核，用户无需重新下载App，就能让新功能悄无声息的更新到用户手机上，让原生App的新功能开发变得更高效。

6. 使用Android性能调优利器StrictMode

StrictMode意思为严格模式，是用来检测程序中违例情况的开发者工具。最常用的场景就是检测主线程中本地磁盘和网络读写等耗时的操作。使用严格模式，系统检测出主线程违例的情况会做出相应的反应，如日志打印，弹出对话框亦或者崩溃等。换言之，严格模式会将应用的违例细节暴露给开发者方便优化与改善。

7. 使用Hierarchy Viewer 工具

Hierarchy Viewer可以帮助调试应用布局，它会让你选择设备或者模拟器上正在运行的进程，然后显示其 Layout 的树型结构。每个块上的交通灯分别代表了它在测量、布置和绘画时的性能，帮你找出瓶颈部分。

8. 优化应用布局

简单的屏幕可以让应用使用轻松流畅，使用Lint工具可以查看View层级哪些地方可以优化。它可以帮助你找到不必要的控件嵌套以及缩减布局资源的其他方法，以尽量减少资源的使用。它让你可以了解哪些布局控件可能是多余的或不必要的。控件越少、布局层次越浅，性能就越好。

9. 优化应用的耗电量

如果让用户发现你的应用很耗电，那就不怪用户马上卸载应用了。应用之所以耗电，是因为使用了手机的某种资源，根据谷歌官方统计，典型的耗电场景有调用GPS定位、网络传输、屏幕亮度、CPU频率、内存调度频度、wake_locker时间和次数，如果你的应用能优化以上几点，就能降低耗电风险。

10. 规划应用的离线体验

当用户无法连接WiFi或其它网络信号时，用户使用App时仍然能够有极佳的可用性，那一定能给你的App加不少印象分，如印象笔记。在规划App应用时，应该将这一设计方法考虑其中，提前规划好App在离线状态下的运营模式。

以上十个小技巧，希望可以帮助你开发出更流畅更快速的移动应用。

---

性能问题一般归结为三类：

1.UI卡顿和稳定性:这类问题用户可直接感知，最为重要；

2.内存问题：内存问题主要表现为内存泄露，或者内存使用不当导致的内存抖动。如果存在内存泄露，应用会不断消耗内存，易导致频繁gc使系统出现卡顿，或者出现OOM报错；内存抖动也会导致UI卡顿。

3. 耗电问题：会影响续航，表现为不必要的自启动，不恰当持锁导致系统无法正常休眠，系统休眠后频繁唤醒系统等；

---

性能分析工具：最为主要的还是要细心观察，找规律复现，分析+排查

1、 测量函数耗时：TraceView:

    两个重要指标：

    Calls + Recur Calls / Total       函数调用的次数

    Cpu Time / Call                   CPU占用的时间

2、 UI布局的分析： Hierarchy Viewer 可以看到View的布局层次，以及每个View刷新加载的时间

3、 内存监测：DDMS Heap Viewer

      a) 不断的操作当前应用，同时注意观察data object的Total Size值；

      b) 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，

          内存占用量会会落到一个稳定的水平；

      c) 反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大， 直到到达一个上限后导致进程被kill掉，这就是我们不希望的！

4、静态代码分析工具， lint， 用来对Android工程的源文件进行检查，找出在正确性、安全、性能、可使用性、可访问性及国际化等方面可能的bugs和可优化提升的地方。

5、 内存分析工具：Android MAT

---

内存泄漏场景

1、 数据库操作，关闭游标

2、 文件操作，关闭输入输出流

3、 网络连接，关闭连接与输入输出流

4、 注册广播，需要注销广播

5、Bitmap对象的及时回收

6、优化布局层次，减少内存消耗

---

listview的优化

1、convertView重用

2、ViewHolder优化

3、图片加载优化

4、onClickListener处理

5、减少Item View的布局层级

6、adapter中的getView方法尽量少使用逻辑

7、adapter中的getView方法尽量少做耗时操作

8、adapter中的getView方法避免创建大量对象

9、将ListView的scrollingCache和animateCache设置为false

7、使用 RecycleView 代替。

---

功耗

1）灭屏待机最省电：

a)任何App包括后台Service应该尽可能减少唤醒CPU的次数，比如IM类业务的长连接心跳、QQ提醒待机闹钟类业务的alarm硬时钟唤醒要严格控制；

b)每次唤醒CPU执行的代码应该尽可能少，从而让CPU迅速恢复休眠，比如申请wake lock的数量和持有时间要好好斟酌；

从kernel_log中分析，
如果log中可以查找到
wake up by RTC
请在相应的main_log中查找关键字

Alarm triggering, 其后面对应的type 0, type 2所对应的APk就是唤醒系统的唤醒源，

---

内存分配

====================================================================================

关于build.prop原始Dalvik虚拟机设定与调整

原厂S3 台版 1GB Ram
system/build.prop原始Dalvik虚拟机设定是这样子的

1.dalvik.vm.heapstartsize=8m(表示应用程序启动后为其分配的初始大小为8m)
这里分配的内存容量会影响到整个系统对RAM的使用程度，和第一次使用应用程序时的流畅程序。
这个值越大，系统消耗RAM则越快，但是应用程序打开后的反应也越快。
值越小，系统的RAM剩余则越多，但是程序在启动后会比较慢。

2.dalvik.vm.heapgrowthlimit=64m(每个应用程序最大内存可分配到64m)
超过就会崩溃，退出该app...我猜没错的话

3.dalvik.vm.heapsize=256m(单个虚拟机可分配的最大内存256m)
这里分配的内存容量会影响到整个系统对RAM的使用程序，和程序在运行一段时间后的反应速度。这个值越大，系统消耗RAM则越快，但是程序会运行的非常稳 定，尤其是游戏和视频程序的内容加载速度可以大幅度提升。值越小，系统的RAM剩余则越多，但是程序会很卡，尤其是游戏在切换场景Loading的时候会 花费很多的时间。若应用程序需要使用超过这个值的内存时，将会触发系统的垃圾收集器，系统和程序就会卡顿。

用上面设定的话
每开启一只app，系统就会划出8m的动态内存给该程式使用，超过的部分会再+8m
共可以+7次8m，包含一开始划出的8m，总共64m，这是单一只程式的最大动态内存使用量
超过的话，该程式就会崩溃(自动结束掉)
单个虚拟机可分配的最大内存256m，意思是可以装满64m内存的程式X4
超过的部分就会对虚拟机内的程式强制回收内存，一方面要先强制关掉一些程式，一方面要加载程式划分新的内存，这时候就会出现卡卡卡、顿顿顿

因为每个人使用习惯不同，有时爱装一堆widget(小工具)在桌面上，单单摆在桌面上也不常使用他
也许单一widget只要3-5m，如果今天一开始就划分8m内存给他，对于一个常驻不到5M的程式
，就多浪费3M的内存，一般原厂rom闲置程序+后台程序就约30个，每个都浪费约3M内存
就将近浪费90M
所以我们可以将 
1.dalvik.vm.heapstartsize=8m，改为=4M后重开机
光待机其况下你就会发现使用中内存变少了，可用内存变多了，虽然你在使用桌面小工具时候
可能不会比当初还要顺，因为系统还在帮该程式划分新的内存空间，但也不至于顿

2.dalvik.vm.heapgrowthlimit=64m不用改，现在的app在前景中都吃很大内存
若改小成32m，那假设程序内存要吃到40m才会够用，该程式可能就当给你看

3..dalvik.vm.heapsize=256m(单个虚拟机可分配的最大内存256m)，虽然是写单个虚拟机，但系统到底会产生多少个虚拟机...我不确定，但唯一确定是不超过实际ram的可用量
记得S3虽然是配1G RAM，但实际上看到好像是780M吧(其他好像是GPU用掉了)
780/256=3...，大概就是3个虚拟机左右(应该是这样)
想要看到更多ram的人可以将256改为128m，重开机后...你会发现可用内存又变多了...
但一样，开启新程式时候要再+128划分新的虚拟机，速度可能慢一些，但不会顿，又可节省内存的不必要浪费

以上是牺牲一些开启速度，但可以减缓被系统强制回收内存的顿挫感
---------------------------------------------------------------------------
小弟我第一次打这么大篇瞎掰文，各位当作参考就好不要完全相信
关于root后修改build.prop当掉、死机、变砖，请不要晚上来找我~谢谢
---------------------------------------------------------------------------
懒人总结 S3 台版
1.想要装很多widget小工具到桌面的，推荐
dalvik.vm.heapstartsize=5m
dalvik.vm.heapgrowthlimit=40m
dalvik.vm.heapsize=160m
也许开启程式没那么快，但比较不卡顿，且可用内存会比较多
--------------
2.只要玩游戏、桌面很干净很无聊的、不安装其他widget小工具
dalvik.vm.heapstartsize=16m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=384m
加载大型程式或游戏比较快，缺点是可用内存会比较小

-----------------------------------------
S3 LTE (I9305)默认dalvik也是跟S3一样
但是可以改成(我也是这样设定)
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=576m(1750/576=3...)可以做出3个虚拟机。
(576/8)在8M以下的程式可以有72只闲置程式

(576/64)一个虚拟机可以容纳9只多工

====================================================================================

ActivityThread.java

public static void main(String[] args) {

//通过zygote进程，创建应用进程，执行main 方法，这也是我们平时所说的UI主进程

   Looper.prepareMainLooper();

   ActivityThread thread = new ActivityThread();

}

Zygote进程在启动的过程中，除了会创建一个Dalvik虚拟机实例之外，还会将Java运行时库加载到进程中来，以及注册一些Android核心类的JNI方法来前面创建的Dalvik虚拟机实例中去。注意，一个应用程序进程被Zygote进程孵化出来的时候，不仅会获得Zygote进程中的Dalvik虚拟机实例拷贝，还会与Zygote一起共享Java运行时库，这完全得益于Linux内核的进程创建机制（fork）。这种Zygote孵化机制的优点是不仅可以快速地启动一个应用程序进程，还可以节省整体的内存消耗，缺点是会影响开机速度，毕竟Zygote是在开机过程中启动的。不过，总体来说，是利大于弊的，毕竟整个系统只有一个Zygote进程，而可能有无数个应用程序进程，而且我们不会经常去关闭手机，大多数情况下只是让它进入休眠状态。

Dalvik虚拟机在启动的时候，就是通过读取系统属性dalvik.vm.heapsize的值来获得Java Object Heap的最大值的，而ActivityManager类的成员函数getMemoryClass最终也通过读取这个系统属性的值来获得Java Object Heap的最大值。

这个Java Object Heap的最大值也就是我们平时所说的Android应用程序进程能够使用的最大内存。这里必须要注意的是，Android应用程序进程能够使用的最大内存指的是能够用来分配Java Object的堆。

---