1、一键加油的数据缓存操作
添加缓存
原因： 开发过程，由于测试服务器的网络带宽，客户端请求数据超级慢，用户的体验非常不好。 工具： sharedPreference： 流程： 1、将一键加油的数据，在进入到主页的时候，进行请求完成，将JSON,时间，当前请求的位置等数据缓存到本地 2、在进入到一键加油的流程时候，先拿到本地缓存的数据，对时间和位置进行对比，时间超过5分钟，位置移动超过20m，都会重新向服务器请求数据。 3、在首页生命周期走到onStop()方法时候，将缓存数据进行致空（json="";）操作。 4、3的操作，保证每次打开首页进入到一键加油流程都是最新的数据，同样也保证再次回到首页的时候，在网络情况差，请求不到数据的情况，不会使用上一次缓存的数据 优点： 优化用户体验，节省流量 缺点：暂未发现
来源 http://hukai.me/android-performance-memory/
Google近期在Udacity上发布了Android性能优化的在线课程，分别从渲染，运算与内存，电量几个方面介绍了如何去优化性能，这些课程是Google之前在Youtube上发布的Android性能优化典范专题课程的细化与补充。
下面是内存篇章的学习笔记，部分内容与前面的性能优化典范有重合，欢迎大家一起学习交流！
1)Memory, GC, and Performance
众所周知，与C/C++需要通过手动编码来申请以及释放内存有所不同，Java拥有GC的机制。Android系统里面有一个Generational Heap Memory的 模型，系统会根据内存中不同的内存数据类型分别执行不同的GC操作。例如，最近刚分配的对象会放在Young Generation区域，这个区域的对象通常都是会快速被创建并且很快被销毁回收的，同时这个区域的GC操作速度也是比Old Generation区域的GC操作速度更快的。
除了速度差异之外，执行GC操作的时候，所有线程的任何操作都会需要暂停，等待GC操作完成之后，其他操作才能够继续运行。
通常来说，单个的GC并不会占用太多时间，但是大量不停的GC操作则会显著占用帧间隔时间(16ms)。如果在帧间隔时间里面做了过多的GC操作，那么自然其他类似计算，渲染等操作的可用时间就变得少了。
2)Memory Monitor Walkthrough
发表于 2015-04-16 22:34 1043
来源 http://hukai.me/android-performance-render/
Google近期在Udacity上发布了Android性能优化的在线课程，目前有三个篇章，分别从渲染，运算与内存，电量三个方面介绍了如何去优化性能，这些课程是Google之前在Youtube上发布的Android性能优化典范专题课程的细化与补充。
下面是渲染篇章的学习笔记，部分内容和前面的性能优化典范有重合，欢迎大家一起学习交流！
1)Why Rendering Performance Matters
现在有不少App为了达到很华丽的视觉效果，会需要在界面上层叠很多的视图组件，但是这会很容易引起性能问题。如何平衡Design与Performance就很需要智慧了。
2)Defining ‘Jank’
大多数手机的屏幕刷新频率是60hz，如果在1000/60=16.67ms内没有办法把这一帧的任务执行完毕，就会发生丢帧的现象。丢帧越多，用户感受到的卡顿情况就越严重。
3)Rendering Pipeline: Common Problems
发表于 2015-04-20 00:52 632
来源 http://hukai.me/android-performance-battery/
Google近期在Udacity上发布了Android性能优化的在线课程，分别从渲染，运算与内存，电量几个方面介绍了如何去优化性能，这些课程是Google之前在Youtube上发布的Android性能优化典范专题课程的细化与补充。
下面是电量篇章的学习笔记，部分内容与前面的性能优化典范有重合，欢迎大家一起学习交流！
1)Understanding Battery Drain
手机各个硬件模块的耗电量是不一样的，有些模块非常耗电，而有些模块则相对显得耗电量小很多。
电量消耗的计算与统计是一件麻烦而且矛盾的事情，记录电量消耗本身也是一个费电量的事情。唯一可行的方案是使用第三方监测电量的设备，这样才能够获取到真实的电量消耗。
当设备处于待机状态时消耗的电量是极少的，以N5为例，打开飞行模式，可以待机接近1个月。可是点亮屏幕，硬件各个模块就需要开始工作，这会需要消耗很多电量。
使用WakeLock或者JobScheduler唤醒设备处理定时的任务之后，一定要及时让设备回到初始状态。每次唤醒蜂窝信号进行数据传递，都会消耗很多电量，它比WiFi等操作更加的耗电。
2)Battery Historian
Android性能优化典范的课程最近更新到第三季了，这次一共12个短视频课程，包括的内容大致有：更高效的ArrayMap容器，使用Android系统提供的特殊容器来避免自动装箱，避免使用枚举类型，注意onLowMemory与onTrimMemory的回调，避免内存泄漏，高效的位置更新操作，重复layout操作的性能影响，以及使用Batching，Prefetching优化网络请求，压缩传输数据等等使用技巧。下面是对这些课程的总结摘要，认知有限，理解偏差的地方请多多交流指正！
1) Fun with ArrayMaps
发表于 2015-04-17 10:22 719
Google近期在Udacity上发布了Android性能优化的在线课程，分别从渲染，运算与内存，电量几个方面介绍了如何去优化性能，这些课程是Google之前在Youtube上发布的Android性能优化典范专题课程的细化与补充。
下面是运算篇章的学习笔记，部分内容与前面的性能优化典范有重合，欢迎大家一起学习交流！
1)Intro to Compute and Memory Problems
Android中的Java代码会需要经过编译优化再执行的过程。代码的不同写法会影响到Java编译器的优化效率。例如for循环的不同写法就会 对编译器优化这段代码产生不同的效率，当程序中包含大量这种可优化的代码的时候，运算性能就会出现问题。想要知道如何优化代码的运算性能就需要知道代码在 硬件层的执行差异。
2)Slow Function Performance
如果你写了一段代码，它的执行效率比想象中的要差很多。我们需要知道有哪些因素有可能影响到这段代码的执行效率。例如：比较两个float数值大小的执行时间是int数值的4倍左右。这是因为CPU的运算架构导致的，如下图所示：
虽然现代的CPU架构得到了很大的提升，也许并不存在上面所示的那么大的差异，但是这个例子说明了代码写法上的差异会对运算性能产生很大的影响。
通常来说有两类运行效率差的情况：第1种是相对执行时间长的方法，我们可以很轻松的找到这些方法并做一定的优化。第2种是执行时间短，但是执行频次很高的方法，因为执行次数多，累积效应下就会对性能产生很大的影响。
修复这些细节效率问题，需要使用Android SDK提供的工具，进行仔细的测量，然后再进行微调修复。
3)Traceview Walkthrough
来源 http://www.csdn.net/article/2015-04-29/2824583-android-performance-patterns-season-2/4
Google前几天刚发布了Android性能优化典范第2季的 课程，一共20个短视频，包括的内容大致有：电量优化、网络优化、Android Wear上如何做优化、使用对象池来提高效率、LRU Cache、Bitmap的缩放、缓存、重用、PNG压缩、自定义View的性能、提升设置alpha之后View的渲染性能，以及Lint、 StictMode等工具的使用技巧。 下面是对这些课程的总结摘要，认知有限，理解偏差的地方请多多指教！
1) Battery Drain and Networking
对 于手机程序，网络操作相对来说是比较耗电的行为。优化网络操作能够显著节约电量的消耗。在性能优化第1季里面有提到过，手机硬件的各个模块的耗电量是不一 样的，其中移动蜂窝模块对电量消耗是比较大的，另外蜂窝模块在不同工作强度下，对电量的消耗也是有差异的。当程序想要执行某个网络请求之前，需要先唤醒设 备，然后发送数据请求，之后等待返回数据，最后才慢慢进入休眠状态。这个流程如下图所示：
转载自胡凯的博客 Android性能优化典范
2015年伊始，Google发布了关于Android性能优化典范的专题， 一共16个短视频，每个3-5分钟，帮助开发者创建更快更优秀的Android App。课程专题不仅仅介绍了Android系统中有关性能问题的底层工作原理，同时也介绍了如何通过工具来找出性能问题以及提升性能的建议。主要从三个 方面展开，Android的渲染机制，内存与GC，电量优化。下面是对这些问题和建议的总结梳理。
0)Render Performance
大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能。从设计师的角度，他们希望App能够有更多的动画，图片等时尚元素来实现流畅的用 户体验。但是Android系统很有可能无法及时完成那些复杂的界面渲染操作。Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染， 如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps，为了能够实现60fps，这意味着程序的大多数操作都必须在16ms内完成。
要深入学习注解，我们就必须能定义自己的注解，并使用注解，在定义自己的注解之前，我们就必须要了解Java为我们提供的元注解和相关定义注解的语法。
元注解：
元注解的作用就是负责注解其他注解。Java5.0定义了4个标准的meta-annotation类型，它们被用来提供对其它 annotation类型作说明。Java5.0定义的元注解：
Android系统提供了两种HTTP通信类，HttpURLConnection和HttpClient。
尽管Google在大部分安卓版本中推荐使用HttpURLConnection，但是这个类相比HttpClient实在是太难用，太弱爆了。
OkHttp是一个相对成熟的解决方案，据说Android4.4的源码中可以看到HttpURLConnection已经替换成OkHttp实现了。所以我们更有理由相信OkHttp的强大。
前一篇文章简单介绍了EventBus 3.0的用法，现在是时候详解其用法了。首先声明，EventBus 3.0的改动针对2.4的改动并不是特别大，但是对于其性能的提升是另外一个说法了，所以建议学习EventBus 3.0。
看到大家提出的关于Android的问题，有一部分可以用EventBus解决，而也有相当多的人推荐使用EventsBus,因为其和GreenDAO出自一家公司，并且使用它非常的简单，所以现在很多的互联网app都会使用EventsBus来进行消息传递。
基于此，有很多EventBus的文章，写的非常的好，但是由于EventBus已经出了3.0版本，而国内的大多数翻译只是停留在了2.4版本左右，对于那些刚刚接触EventBus的人，从最新版接触学习，是最理想的学习路线。
所以，在这儿，我总结下EventBus3.0的用法。
代码:
package angel.devil;
import android.app.Activity;
import android.app.Dialog;
import android.os.Bundle;
import android.view.Gravity;
import android.view.Window;
import android.view.WindowManager;
public class DialogDemoActivity extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
Dialog dialog = new Dialog(this);
// setContentView可以设置为一个View也可以简单地指定资源ID
// LayoutInflater
// li=(LayoutInflater)getSystemService(LAYOUT_INFLATER_SERVICE);
// View v=li.inflate(R.layout.dialog_layout, null);
// dialog.setContentView(v);
dialog.setContentView(R.layout.dialog_layout);
dialog.setTitle("Custom Dialog");
原文： Developing for Android IX Tools
安卓中有许多帮助调试与分析app所存在问题的工具，从内存分析工具Allocation Tracker（ddms和Android Studio中都有）到设备端的性能分析工具。
重要的不是你知道这些工具的存在，而是你实际使用了它们，用它们验证app是否和你期望的表现一致（是否达到60 fps，是否避免了garbage churn，等等），让安卓成为一个更好的平台。
常用的性能分析工具有两类：主机端的和设备端的。主机端的工具是指那些在电脑上运行的（通过命令行，DDMS，Android Studio等等）。设备端工具是指实时显示当前设备所发生事情的信息的工具，主要是与性能有关的指标。
主机端工具
Systrace
原文：Developing for Android VIII The Rules: User Interface
这节主要涉及UI开发最佳范例的一些重要细节，着重围绕性能和用户体验进行讲解。
避免过度绘制
正如我们在第一章（理解移动应用上下文 ）的GPU一节中所讨论的，很多设备的GPU填充率都是受限的，因此，那些具有严重过度绘制问题的应用都将面临的渲染性能问题。要避免不透明view完全遮住其它view的情况，这种情况下不可见的UI也在做绘制的操作，就会导致某个像素在同一帧的时间内被绘制了多次。检测你的应用是否过渡绘制的办法是在系统设置的开发者选项中开启“调试GPU过度绘制”选项，然后根据情况修复问题。
注：1.GPU的填充率分为像素填充率和纹理填充率。2.关于过度绘制这一点，其实在 这篇文章 的GPU Problem: Overdraw一节中说的最详细。
不要设置窗口背景为空
避免过度绘制的技巧之一就是在所有View都不透明的情况下去除窗口的背景。反正如果有一个或者多个不透明的View完全挡住了窗口，用户怎么也看不到，还不如干脆不要背景。
去除窗口背景是一个有效的方法，但也往往是一个解决过度绘制问题的复杂办法，而且它经常在某些情况下导致渲染的artifacts（不知道artifacts啥意思）。虽然可以在app的manifest中设置一个空的窗口背景，但是因为系统无法正确绘制启动窗口，这会导致图形绘制artifacts。更正确的做法是保留manifest中启动窗口的背景，转而在activity的onCreate()方法中通过调用getWindow().setBackground(null)设置成null。但即便是这种方法也会导致artifacts。比如，如果keyboard/IME设置成了adjustResize，然后动画进入一个背景为null的activity，在键盘后面可能存在artifacts，因为window manager没有要绘制的背景。还有，全屏且带有overscroll bounce gaps的ListView也可能会有artifacts。
。。。。受不了了 artifacts artifacts artifacts不停。