内存优化

1，handler机制 在android中的一个异步回调，一个handler允许发送和处理message和runable对象，这些对象和一个线程的MessageQueue相关联。每一个线程实例和一个单独的线程以及线程messageQueue相关联。每一个消息都要制定一个handler，通过Handler创建消息便可以完成此功能，将引入到消息队列中。UI主线程创建一个handler是通过threadlocal创建一个looper，这个looper和主线程一一对应，使用threadlocal是保证每一个线程唯一个looper，可以直接使用，初始化looper的时候创建一个messageQueue，主线程，消息循环，消息队列。Hander持有对UI主线程消息队列MessageQueue和消息循环Looper的引用，子线程可以通过Handler将消息发送到UI线程的消息队列MessageQueue中。 2，AIDL android interface define language 是进程间的通信，activity和service之间和在不同service之间的通信。 IPC机制是面向接口的，它是使用代理类在客户端和实现端传递数据，使用AIDL实现IPC服务的步骤是：1. 创建.aidl文件-该文件（YourInterface.aidl）定义了客户端可用的方法和数据的接口。2.

一、前言 这篇文章其实是上篇文章的内存优化部分。博主的php程序在执行的时候，报错： Out of memory (allocated 364904448) (tried to allocate 262144 bytes) 也就是传统的内存不足报错，问题是我本地设置的内存已经是1280M了，简直不能忍。因此这里一步步的看一篇代码，记录一下需要优化的地方，主要是针对数组的 二、优化前准备 1、首先是查看php的当前内存设置 windows: 打开php.ini，搜索：memory_limit ，一般设置为128M够用 linux: 执行“php -i | grep Loaded Configuration File”来找到对应的配置文件。 注： 这个命令是搜索php程序的配置文件所在位置,打开phpinfo，可以看到有个Loaded Configuration File 选项，对应 的就是php.ini文件的位置 2、一个php数组能占用多大内存 参考：https://blog.csdn.net/hguisu/article/details/7376705 通过大佬的分析，我们可以知道： （1）php对于数组的利用效率很低，一个在C语言里面100M 内存的数组，在PHP里面就要1G； （2）php空数组都要14(zval) + 39(HashTable) + 33(arBuckets

1.概述 如果使用MAT来分析内存问题，会有一些难度，并且效率也不是很高，对于一个内存泄漏问题，可能要进行多次排查和对比。 为了能够简单迅速的发现内存泄漏，Square公司基于MAT开源了 LeakCanary 。 2.使用LeakCanary 首先配置build.gradle： dependencies { debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.2' releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.2' } 1 2 3 4 接下来在Application加入如下代码。 public class LeakApplication extends Application { @Override public void onCreate () { super .onCreate(); if (LeakCanary.isInAnalyzerProcess( this )) { //1 // This process is dedicated to LeakCanary for heap analysis. // You should not init your app in this process. return ;

转 载 声明： Ryan的博客文章欢迎您的转载，但在转载的同时，请注明文章的来源出处，不胜感激！ :-) http://my.oschina.net/ryanhoo/blog/93432 上 节课 我们学习了缓存模块的实现， 缓存分做两份： Memory Cache 和 File Cache 。方法也很简单，分别是： 存储文件 按唯一key值索引文件 清空缓存 区别在于内存缓存读取优先，因为它读写的速度更快。但是考虑到内存限制，退而选用文件存储，分担内存缓存的压力。 原理非常简单，在第一课中已经详细分析了。那么要怎么才能将这个缓存模块与UI模块的显示关联起来呢？在这里我们需要一个控制器，掌管数据流向和读写，同时控制UI的显示。 那么这个控制器需要以下的元素： 内存缓存 硬盘缓存 异步任务处理 控制UI显示 //caches private MemoryCache memoryCache; private FileCache fileCache; //Asynchronous task private static AsyncImageLoader imageLoader; Memory Cache 和 File Cache 在上一课中有具体的实现，这里有一个异步的任务处理器—— AsyncImageDownloader ，它用来在后台下载数据，完成下载后存储数据到缓存中

什么是缓存？ 缓存技术原理就是把用户访问的所有对象看作一个全集，经过算法标记哪些是用户经常访问的对象，把这些对象放到一个集合里，这个集合是全集一个子集，下一次用户再访问的时候会先从这个子集集合中查找用户要访问的对象如果找到就直接返回这个对象，如果没有找到则再去全集中查找。当然了我这里说的只是原理性的东西，缓存是有很多算法的，并且有的不止一级缓存，这里就不过多讲了。 为什么要用到缓存？ 有缓存的话可以不必每次从源地址读取文件，既节省了时间也节省了流量。尤其是手机设备，频繁的访问网络资源会消耗很多用户的流量和电量，这是用户不能忍受的，所以无论从哪个方面考虑应用程序都必须加上缓存。 Android 中的图片缓存有哪些？各有什么特点？ Android 设备的图片缓存分两种，一种是内存缓存，图片缓存在设备的内存中，一种是外部缓存，图片缓存在磁盘上，磁盘可以是内部的存储空间也可以是外部的 sd 卡。这两种缓存各有各的优点，内存缓存优点是快，缺点是因为也是读取到内存中所以也会消耗内存，所以不能太大，用的时候要考虑分配的空间，还有一个缺点是应用重启后就会消失。外部缓存的优点是可以长久保存大量的数据 ( 相比较内存缓存而言 ) ，缺点就是慢。 内存缓存： 在 Android 中官网推荐使用 LruCache 作为内存缓存， LruCache 实际上就是一个 LinkedHashMap( 补充知识：

一. 引言 Hadoop生态中的NoSQL数据分析三剑客Hive、HBase、Impala分别在海量批处理分析、大数据列式存储、实时交互式分析各有所长。尤其是Impala，自从加入Hadoop大家庭以来，凭借其各个特点鲜明的优点博取了广大大数据分析人员的欢心。 Impala 通过主节点生成执行计划树并分发执行计划至各节点并行执行的拉式获取数据的工作方式，替代了Hadoop中传统的MapReduce推式获取数据的工作方 式，计算的中间结果不写入磁盘，及时通过网络以stream的方式传递，交互性和实时性更强；Impala不花费额外的精力管理元数据，而是使用Hive 的Metastore进行元数据管理，能够直接访问存储在Hadoop的HDFS和HBase中的PB级大数据；Impala采用块的方式将元数据加载到 内存进行运算，相比Hive、HBase而言运算性能有了较大的提升；Impala提供SQL语义，相比HBase对于用户而言使用方便快捷并且简单实 用，无需其他编程语言，只需使用SQL语句即可完成复杂的数据分析任务；Impala还继承了Hadoop的灵活性、伸缩性和经济性，具有分布式本地化处 理的特性以避免网络瓶颈。 说了Impala这么多优点，难道它真是一点缺点没有的一款“完美”的分析工具吗？ 非也！在一年以上的Impala海量数据分析、web应用开发实战经验中

在Android应用里，最耗费内存的就是图片资源。而且在Android系统中，读取位图Bitmap时，分给虚拟机中的图片的堆栈大小只有8M，如果超出了，就会出现OutOfMemory异常。所以，对于图片的内存优化，是Android应用开发中比较重要的内容。 1) 要及时回收Bitmap的内存 Bitmap类有一个方法recycle()，从方法名可以看出意思是回收。这里就有疑问了，Android系统有自己的垃圾回收机制，可以不定期的回收掉不使用的内存空间，当然也包括Bitmap的空间。那为什么还需要这个方法呢？ Bitmap类的构造方法都是私有的，所以开发者不能直接new出一个Bitmap对象，只能通过BitmapFactory类的各种静态方法来实例化一个Bitmap。仔细查看BitmapFactory的源代码可以看到，生成Bitmap对象最终都是通过JNI调用方式实现的。所以，加载Bitmap到内存里以后，是包含两部分内存区域的。简单的说，一部分是Java部分的，一部分是C部分的。这个Bitmap对象是由Java部分分配的，不用的时候系统就会自动回收了，但是那个对应的C可用的内存区域，虚拟机是不能直接回收的，这个只能调用底层的功能释放。所以需要调用recycle()方法来释放C部分的内存。从Bitmap类的源代码也可以看到，recycle()方法里也的确是调用了JNI方法了的。

转 载 声明： Ryan的博客文章欢迎您的转载，但在转载的同时，请注明文章的来源出处，不胜感激！ :-) http://my.oschina.net/ryanhoo/blog/93406 上 节课 我们讲到普通应用缓存Bitmap的实现分析，根据MVC的实现原理，我将这个简单的缓存实现单独写成一个模块，这样可以方便以后的使用，对于任意的需求，都属于一个可插拔式的功能。 之前提到，这个缓存模块主要有两个子部件： Memory Cache ：内存缓存的存取速度非常惊人，远远快于文件读取，如果没有内存限制，当然首选这种方式。遗憾的是我们有着 16M 的限制（当然大多数设备限制要高于Android官方说的这个数字），这也正是大Bitmap容易引起OOM的原因。 Memory Cache 将使用 WeakHashMap 作为缓存的中枢，当程序内存告急时，它会主动清理部分弱引用（因此，当引用指向为null，我们必须转向硬盘缓存读取数据，如果硬盘也没有，那还是重新下载吧）。 能力越大，责任越大？人家只是跑得快了点儿，总得让人家休息，我们一定不希望让内存成为第一位跑完马拉松的 Pheidippides ，一次以后就挂了吧？作为精打细算的猿媛，我们只能将有限的内存分配给 Memory Cache ， 将更繁重的任务托付给任劳任怨的 SDCard 。 File Cache ：硬盘读取速度当然不如内存

Android中，应用的性能优化是一个比较重要的问题，应用性能直接影响到用户的体验，应用的流畅度，崩溃率，流量使用量，耗电量,以及启动的快慢，内存使用等，都会严重影响用户的使用。 而内存优化更是Android应用性能优化中的重要部分，这篇文章就来记录总结一下Android应用的内存优化 首先先来了解一下两个概念： 内存泄漏 ：由于某种原因，导致程序中动态分配的堆内存，无法被释放,导致系统内存的浪费。 主要表现为长生命周期对象持有短生命周期对象引用，从而导致短生命周期对象无 法被回收。 内存抖动 ：程序运行过程中，频繁的创建和销毁对象，导致频繁GC, 从而引起应用卡顿。 主要表现为在循环中创建对象,导致短时间内有大量的对象创建和回收， 如果严重的话，就会导致应用卡顿。 下面来总结一下Android中内存泄漏的场景以及对应的解决方案： 1.单例引起的内存泄漏 由于单例的静态特性，导致单例的生命周期和整个应用的生命周期一样长，如果对象不再被使用,但是被单例持有引用的话，那么这个对象就没有办法被系统回收，导致内存泄漏。 public class SingleInstance { private static SingleInstance mInstance; private Context mContext; private SingleInstance(Context context)

【编者按】本文作者在和同事的一次讨论中发现，对 IntelliJ IDEA 内存采用不同的设置方案，会对 IDE 的速度和响应能力产生不同的影响。 Don’t be a Scrooge and give your IDE some more memory 不要做守财奴，给IDE多留点内存吧。 昨天，大家就是否自定义 IntelliJ IDEA 的内存设置进行了讨论，有些人选择默认设置，有些人会对默认的设置进行简单的变更，还有一些开发者会基于他们的需求进行全面复杂的设置。笔者目前的工作是处理几个微服务项目和一个老项目，而客户的核心业务需求非常大。对 IntelliJ IDEA 内存进行简单设置以后，笔者明显感受到了该 IDE 在速度和响应方面的改善。但当时笔者并未进行具体的测量，所以这只是主观感受而已。 不过，参与讨论的一位开发者给笔者发了一份他的设置，虽然是针对同个项目，该设置却极其复杂。笔者对自己的设置并无不满，但非常好奇，这些完全不同的设置对比 JetBrains 提供的默认设置，会有怎样的不同。 目标 笔者的计划是，在一个接近日常开发项目的场景下（加载一个大项目、加载2、3个微服务、git pull 后刷新大项目），测试各个设置带来的效果，并选出内存消耗和速度都达到最优时的最佳设置。 测试机器和项目 笔记本电脑：MacBook Pro Retina, 2.3GHz Intel