Android 性能优化

APP性能优化系列- http://blog.csdn.net/a910626/article/category/3147827

Android性能优化- http://blog.csdn.net/u010687392/article/category/3197917
优化工作的冰山一角，app瘦身- http://mp.weixin.qq.com/s?__biz=MzI2OTQxMTM4OQ==&mid=2247484570&idx=1&sn=56eea8a80c79b25a2e192e0017091cc3&chksm=eae1f1c8dd9678debb68ffc78ec3b1a9fbb8f8b70107164a77e85fc16c81157cabcb384c213c#rd

Android高级之十二讲之如何降低应用内存消耗-http://blog.csdn.net/reboot123/article/details/53542349

Android冷启动实现APP秒开- http://mp.weixin.qq.com/s/XQYgYP-OkEEtHsprmaMF_w

Android 应用瘦身实践，从 18MB 到 12.5MB- http://www.codeceo.com/article/android-18mb-to-12mb.html

优化的金科玉律不外乎以下内容：
  良好的设计将会使优化变得更加容易。
  过早的优化并不能解决多有的性能问题，但是不良的设计将会导致优化难度的增加。

Android性能优化总结--http://blog.csdn.net/woyaowenzi/article/details/9273839

    虽然静态类与非静态类之间的区别并不大，但是对于Android开发者而言却是必须理解的。至少我们要清楚，如果一个内部类实例的生命周期比Activity更长，那么我们千万不要使用非静态的内部类。最好的做法是，使用静态内部类，然后在该类里使用弱引用来指向所在的Activity。

> 单元测试框架：Juint ,Roboletric ，Instrumentation test，Espresso，UiAtyomator，appium，calabash，RoboGuice，Dagger，Dagger2(DI), 

> 测试用到的几个基本技术：Juint+mockito+Dagger2+Roboletric（如网易的Emm测试）

> Android官方开发文档Training系列课程中文版：APP的内存管理-- http://blog.csdn.net/sahadev_/article/details/52317525

> Android 性能优化的一些建议: http://blog.csdn.net/a56573016613/article/details/48291191

> 给 App 提速：Android 性能优化总结: http://android.jobbole.com/81944/
> 让 APP 更流畅的 5 个改进建议: http://android.jobbole.com/83111/
> Android界面性能调优手册: http://android.jobbole.com/82548/
> 如何给你的Android 安装文件（APK）瘦身: http://android.jobbole.com/80613/
> Android性能优化典范: http://android.jobbole.com/80611/
> Android最佳性能实践(2)：分析内存的使用情况: http://android.jobbole.com/81242/
> Android最佳性能实践(3)：高性能编码优化 http://android.jobbole.com/81245/
> Android最佳性能实践(4)：布局优化技巧 http://android.jobbole.com/81248/
> 通过Hardware Layer提升Android动画性能 http://android.jobbole.com/82294/
> 正确使用Android性能分析工具——TraceView http://android.jobbole.com/78995/

> Android的进程与线程 http://android.jobbole.com/80640/

>  如何通过技术优化让 Android 程序变得流畅？-- http://www.zhihu.com/question/30138734

> 关于APK瘦身值得分享的一些经验 http://zmywly8866.github.io/2015/04/06/decrease-apk-size.html
> [魅族Degao]Android客户端性能优化-- http://blog.csdn.net/yueqian_scut/article/details/50762649#comments

-----------------------------------------------------

  App运行卡顿，不流畅，问题的原因是在渲染的时候出现了丢帧。
先普及一点Android知识，Android系统每隔16ms(60fps)对屏幕进行一次渲染，如果App的绘制、计算等操作耗时超过16ms，则此次渲染
无法进行，要等到下一个16ms才会进行渲染，即此时Android出现了丢帧，也就是题主提到的不流畅的最终原因。
对于App来说，造成丢帧的原因有很多，
可能是布局过于复杂，过度绘制，内存抖动，性能瓶颈等。
  如果对丢帧情况进行优化，目前看最有效的方式就是降低布局层级，减少复杂程度，也就是在界面上少放点东西，我相信淘宝的团队在优化上必然也是做了很多工作.

  程序卡顿的主要因素就是当时太忙，CPU处理不过来了，或者IO瓶颈。所以如果频繁卡顿，主要原因就是程序结构有不合理的地方。有这样的几个建议，希望各位同仁可以参考: 
1 统一管理程序中涉及到大量资源的重处理部分。比如，多线程，网络请求，web view，多媒体，持久化等处理 
2 监控loop的运行时间，找到程序的运行瓶颈。监控读写，发现频繁的IO操作，监控流量，控制请求和返回的处理。
3 重新审视代码，用好队列。 
4 如果可能，酌情修改部分服务器端接口，避免一次性处理过多的内容。同时减少json的复杂度也会有帮助。
  先搞清楚 young GC 和 full GC 的区别及耗时差异，我就问一个问题，大部分图片会被 young GC 还是 full GC 回收？
另外大多数图片缓存对 GC 的影响几乎没有区别，只要不和明显有内存泄露的写法对比。对于目前的系统来说，young GC 的耗时对性能影响很小。

----------------------------------------------

Android性能优化之提高ListView性能的技巧-- http://blog.csdn.net/nugongahou110/article/details/47128125

Android内存优化大全(中)：http://blog.csdn.net/hewence1/article/details/39004301
Android内存优化大全（上）：http://blog.csdn.net/hewence1/article/details/39004231

> Android应用开发性能优化完全分析-http://blog.csdn.net/u014651216/article/details/50787674
 HierarchyViewer分析UI性能；GPU过度绘制分析UI性能；使用Memory监测及GC打印与Allocation Tracker进行UI卡顿分析；运行DDMS->Allocation Tracker；使用Traceview和dmtracedump进行分析优化；使用Systrace进行分析优化；使用traces.txt文件进行ANR分析优化

Android 系统的屏幕刷新频率为 60 fps, 也就是每隔 16 ms 刷新一次。如果在某次绘制过程中，我们的操作不能在 16 ms 内完成，那它则不能赶上这次的绘制公交车，只能等下一轮，这种现象叫做 “掉帧”，用户看到的就是界面绘制不连续、卡顿。
 
 生产者-消费者 模型：生产者线程、消费者线程、任务队列.MessageQueue , Looper , Handler
  每个 View 都持有当前 Context, Activity 的引用，如果子线程持有某个 View 的引用，继而持有了对应 Activity 引用，那么在线程返回之前，即使该 Activity 不可用，也无法回收，这就造成了 内存泄漏。
  除了持有 View，线程隐式持有 Activity 也可能导致内存泄漏，只要子线程没有结束，引用关系就一直存在。
  内部线程工具类持有外部类引用，可能会导致 内存泄漏。

Android 系统为我们提供了以下几种工具类：
 AsyncTask ,主线程、子线程间任务的切换
 HandlerThread ,为某个任务/回调单独开一个线程
 ThreadPool ,管理多个线程，并发执行任务
 IntentService ,在子线程中获取 Intent，用于执行由 UI 出发的后台 Service

> ListView优化方案-http://blog.csdn.net/fenghai22/article/details/44173057
一、复用convertView，减少findViewById的次数 
1、优化一：复用convertView
2、优化二：缓存item条目的引用——ViewHolder
二、ListView中数据的分批及分页加载：
三、ListView中图片的优化：详看OOM异常中图片的优化 ，压缩及三级缓存
四、ListView的其他优化：
1、尽量避免在BaseAdapter中使用static 来定义全局静态变量： 
2、尽量使用getApplicationContext： 
3、尽量避免在ListView适配器中使用线程： 

> android anr traces日志分析方法-http://blog.csdn.net/qwiwuqo/article/details/40111721
ANR：Log分析
Android Not Response ： 通常是UI线程做耗时操作会导致ANR。
 A。界面操作按钮的点击等待响应时间超过5秒
 B。HandleMessage回调函数执行超过10秒，BroadcasterReciver里的onRecive（）方法处理超过10秒
常见问题原因：
1. 数据库操作I/O被阻塞
  iowait、ContentResolver.query、onPostExecute
2. 在UI线程进行网络数据的读写
3. 内存不足导致block在创建bitmap上
  atdalvik.system.VMRuntime.trackExternalAllocation(NativeMethod)
  atandroid.graphics.Bitmap.createBitmap(Bitmap.java:468)
4. 程序异常退出，uncausedexception      （Fatal）
5. 程序强制关闭，ForceClosed (简称FC)       （Fatal）      
6. 通过搜索ANR定位问题

ANR的类型
ANR一般有三种类型：
1：KeyDispatchTimeout(5 seconds) --主要类型
  按键或触摸事件在特定时间内无响应
2：BroadcastTimeout(10 seconds)
  BroadcastReceiver在特定时间内无法处理完成
3：ServiceTimeout(20 seconds) --小概率类型
  Service在特定的时间内无法处理完成

超时时间的计数一般是从按键分发给app开始。超时的原因一般有两种：
(1)当前的事件没有机会得到处理（即UI线程正在处理前一个事件，没有及时的完成或者looper被某种原因阻塞住了）
(2)当前的事件正在处理，但没有及时完成

从LOG可以看出ANR的类型，CPU的使用情况，如果CPU使用量接近100%，说明当前设备很忙，有可能是CPU饥饿导致了ANR：
 如果CPU使用量很少，说明主线程被BLOCK了
 如果IOwait很高，说明ANR有可能是主线程在进行I/O操作造成的
 除了看LOG，解决ANR还得需要trace.txt文件，

> OOM： 一,压缩图片，主动释放Bitmap的内存(大对象)；二，设计Cache。Runtime.getMaxMemory()
Android性能优化——如何避免OOM总结-http://blog.csdn.net/sinat_15877283/article/details/50776228
  首先是减小对象的内存占用，其次是内存对象的重复利用，然后是避免对象的内存泄露，最后是内存使用策略优化。
  原因：一、加载对象过大 ； 二、相应资源过多，没有来不及释放。
解决这样的问题：
 一：在内存引用上做些处理，常用的有软引用、强化引用、弱引用
 二：在内存中加载图片时直接在内存中做处理，如：边界压缩.
 三：动态回收内存
 四：优化Dalvik虚拟机的堆内存分配
 五：自定义堆内存大小
 第一，应该尽量避免static成员变量引用资源耗费过多的实例，比如Context。
 第二、Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。
 第三、使用WeakReference代替强引用。比如可以使用WeakReference<Context> mContextRef;

android中常见的原因：
1.数据库的cursor没有关闭。
2.构造adapter没有使用缓存contentview。
3.调用registerReceiver()后未调用unregisterReceiver().
4.未关闭InputStream/OutputStream。
5.Bitmap使用后未调用recycle()。
6.Context泄漏。
7.static关键字等。

  垃圾回收器有三种基本的经典算法：
1）Reference counting（引用计数）
基本思想是：当对象创建并赋值时该对象的引用计数器置1，每当对象给任意变量赋值时，引用记数＋1；一旦退出作用域则引用记数－1。一旦引用记数变为0，则该对象可以被垃圾回收。
引用记数有其相应的优势：对程序的执行来说，每次操作只需要花费很小块的时间。这对于不能被过长中断的实时系统来说有着天然的优势。
但也有其不足：不能够检测到环（两个对象的互相引用）；同时在每次增加或者减少引用记数的时候比较费时间。在现代的垃圾回收算法中，引用记数已经不再使用。
2）Mark-sweep（标记清理）
基本思想是：每次从根集出发寻找所有的引用（称为活对象），每找到一个，则对其做出标记，当追踪完成之后，所有的未标记对象便是需要回收的垃圾。
也叫追踪算法，基于标记并清除。这个垃圾回收步骤分为两个阶段：在标记阶段，垃圾回收器遍历整棵引用树并标记每一个遇到的对象。在清除阶段，未标记的对象被释放，并使其在内存中可用。
3）Copying collection（复制收集）
基本思想是：将内存划分为两块，一块是当前正在使用；另一块是当前未用。每次分配时使用当前正在使用内存，当无可用内存时，对该区域内存进行标记，并将标记的对象全部拷贝到当前未用内存区，这是反转两区域，即当前可用区域变为当前未用，而当前未用变为当前可用，继续执行该算法。
拷贝算法需要停止所有的程序活动，然后开始冗长而繁忙的copy工作。这点是其不利的地方。
  近年来还有两种算法：
4）Generational garbage collection（分代）
其思想依据是：
  (1) 被大多数程序创建的大多数对象有着非常短的生存期。
  (2) 被大多数程序创建的部分对象有着非常长的生存期。
简单拷贝算法的主要不足是它们花费了更多的时间去拷贝了一些长期生存的对象。
而分代算法的基本思想是：将内存区域分两块（或更多），其中一块代表年轻代，另一块代表老的一代。针对不同的特点，对年轻一代的垃圾收集更为频繁，对老代的收集则较少，每次经过年轻一代的垃圾回收总会有未被收集的活对象，这些活对象经过收集之后会增加成熟度，当成熟度到达一定程度，则将其放进老代内存块中。
分代算法很好的实现了垃圾回收的动态性，同时避免了内存碎片，是目前许多JVM使用的垃圾回收算法。
5）Conservative garbage collection（保守）

> RecyclerView:
 1.LinearLayoutManager 现行管理器，支持横向、纵向。
 2.GridLayoutManager 网格布局管理器
 3.StaggeredGridLayoutManager 瀑布就式布局管理器
RecyclerView整体总结它的几点如下：
 Adapter：包装数据集合并且为每个条目创建视图。
 ViewHolder：保存用于显示每个数据条目的子View。
 LayoutManager：将每个条目的视图放置于适当的位置。
 ItemDecoration：在每个条目的视图的周围或上面绘制一些装饰视图。
 ItemAnimator：在条目被添加、移除或者重排序时添加动画效果。

------------------------------------------

携程移动端性能优化-- http://geek.csdn.net/news/detail/132313
  原先的心跳机制是 TCP 长连接池中的空闲 TCP 连接每 60 秒发送一个心跳包到 Gateway，Gateway 返回一个心跳响应包，从而让双方确认 TCP 连接有效。
  衡量一个 App 性能和质量，首先需要了解 App 性能的现状，即 App 端性能的采集。常规的技术方案有两种：
1.使用第三方性能采集 SDK，例如 OneAPM、听云等；
2.自主研发：携程为了完整掌握用户数据采用了自己研发的方式：App 通过日志 SDK 采集日志包括行为埋点和性能埋点，上传至日志服务端，日志消息经 Kafka 消息队列存入 HDFS（RCFile 格式）分布式文件存储系统，后期的数据查询均基于 Hive 系统来实现。
  App 端的性能数据会在多种纬度（操作系统、App 版本、网络状况、位置）下采集网络（网络服务成功率、平均耗时、耗时分布等）、定位（经纬度成功率、城市定位成功率等，见图 12）、启动时间、内存流量等各类指标。其中像网络服务性能是对于用户体验至关重要的端到端性能，也是优化的核心依据。
  让整个打包流程自动化，同时这个平台还提供了 HotFix 发布平台、App 应用性能管理、App Crash 数据采集等工具，同时可以实现 Daily/Hourly Build，无缝集成自动化测试，集成了 Sonar 代码扫描去检测重复代码等和 infer null pointer，然后能生成一个代码健康度扫描报告，并能帮助分析和解决问题。
  携程 App Size 优化相关
1.通过脚本或第三方工具检测删除无用的资源、类、函数；
2.通过 Sonar 检测整个 App 中的重复代码，将重复代码合并或 App 删除；
3.清理第三方引入的库，删除不用的多套库，比如百度和高德地图 SDK 等，多套图片库等；
4.不轻易引进第三方的库，比如注解框架等，慎重使用第三方定义的控件，自己自定义控件去实现；
5.关于资源图片统一经过 tinpng 压缩；
6.资源图片统一整理，功能和资源统一，不重复造轮子，删除原来的多套资源；
7.资源图片使用 SVG 或者 WebP 格式图片去替换；
8.清理高清资源大图片，特别是超过 10K 以上的图片；
9.能用代码去实现的 UI，尽量不用去图片代替；
10.Native 转 H5；
11.Native 或者 H5 转 React Native；
12.Hybrid 页面离线的 JS 资源，直接转换成 RN，减少包大小比较明显。

  App 性能优化成为各大公司重点关注的问题，目的就是为了提升用户的使用体验。性能优化是一个持续发展的实践课题，可以持续贯穿于我们日常的开发工作中，即随着手机机型的日益碎片化，程序功能的复杂化多样化，总之移动端技术的性能优化是没有尽头的，我们会继续持续关注移动端的性能优化，并融入新的技术进行迭代更新。