risechen

1、根据java的内存模型会出现内存溢出的内存有堆内存、方法区内存、虚拟机栈内存、native方法区内存； 2、一般说的OOM基本都是针对堆内存； 3、对于堆内存溢出主的根本原因有两种 （1）app进程内存达到上限 （2）手机可用内存不足，这种情况并不是我们app消耗了很多内存，而是整个手机内存不足 4、而我们需要解决的主要是app的内存达到上限 5、对于app内存达到上限只有两种情况 （1）申请内存的速度超出gc释放内存的速度 （2）内存出现泄漏，gc无法回收泄漏的内存，导致可用内存越来越少 6、对于申请内存速度超出gc释放内存的速度主要有2种情况 （1）往内存中加载超大文件 （2）循环创建大量对象 7、一般申请内存的速度超出gc释放内存基本不会出现，内存泄漏才是出现问题的关键所在 8、内存泄漏常见场景 （1）资源对象没关闭造成的内存泄漏（如： Cursor、File等） （2）全局集合类强引用没清理造成的内存泄漏（特别是 static 修饰的集合） （3）接收器、监听器注册没取消造成的内存泄漏，如广播，eventsbus （4）Activity 的 Context 造成的泄漏，可以使用 ApplicationContext （5）单例中的static成员间接或直接持有了activity的引用 （6）非静态内部类持有父类的引用，如非静态handler持有activity的引用 9、怎么对内存进行优化呢 三个方向 （1）为应用申请更大内存，把manifest上的largdgeheap设置为true...

（1）简单概括： Android应用程序把经过测量、布局、绘制后的surface缓存数据，通过SurfaceFlinger把数据渲染到屏幕上，通过Android的刷新机制来刷新数据。即应用层负责绘制，系统层负责渲染，通过进程间通信把应用层需要绘制的数据传递到系统层服务，系统层服务通过显示刷新机制把数据更新到屏幕 (2)应用层：相当于client，把计算好的图层数据通过共享内存shareclient传递给系统层 通过查看Activity的启动流程可以看出每个activity其实都attach了一个PhoneWindow，而PhoneWindow视图树的根节点是一个ViewRootImpl。而整体绘制其实就是在ViewRootImpl的 performTraversals方法调用后，采用深度优先挨个遍历视图中的子view，通过调用子view的onMesure,onLayout和draw方法，计算出它们的大小、位置。至于为何采用深度优先遍历，是因为子view的位置和大小依赖父view，就像我们使用match_parent属性就是依赖父view的宽高。 这里需要注意的是，draw绘制分为cpu和gpu绘制，cpuz绘制又叫软件绘制，gpu又叫硬件绘制。cpu绘制速度慢，兼容性好，gpu绘制速度快，但是兼容性差，占用内存高（8m以上），在android3.0之后才引入了gpu绘制，但是目前还是有很多Opengl接口不支持硬件加速 （3）系统层：service Android是通过系统层进程SurfaceFlinger服务来把收到的应用层图层数据渲染到屏幕上 主要工作有： ①响应客户端事件，创建Layer与客户端的surface进行连接 ②接收客户端数据及属性，修改layer属性，如颜色、尺寸、透明度 ③将创建的layer内容刷新到屏幕上 ④维护layer的序列（缓冲），并对layer的最终输出做裁剪计算 （4）应用层和系统层通信:简单说就是应用层绘制到缓冲区，SurfaceFlinger把缓存数据渲染到屏幕，两个进程使用安卓匿名共享内存SharedClient缓存需要显示的数据。 由于应用层和系统层分别是两个不同的进程，需要使用跨进程通信来实现数据传输，在Android显示系统中，使用了内部匿名共享内存ShareClient。每一个应用和SurfaceFlinger都会创建一个SharedClient。每个SharedClient中最多可以创建31个SharedBufferStack(window)，也就是是说每个应用理论上最多支持31个window，同时每个SharedBufferStack包含2个（=4.1）缓冲区 （5）显示刷新机制：简单说4.1以前无vsync同步机制，绘制时间分散，很可能绘制任务在，vsync信号后16ms末尾才开始，这样就导致帧率很低，4.0以后采用vsync机制，Choreographer强制vsync执行绘制任务，绘制时间得到保证 Android绘制UI采用双缓冲机制，就是SharedBufferStack中的缓冲区，UI总是先在Back Buffer计算完毕后，再交换到Front Buffer渲染到屏幕上。理想情况下一个刷新在16ms内完成(60fps). 4.1之前是双缓冲，4.1之后是3缓冲Tripple Buffer。并不是缓冲区越多越好，只有绘制占用的cpu和gpu时间片都小的时候3缓冲的性能大概率高于双缓冲。 （6）总结 ①影响绘制的根本原因： 绘制任务太重，绘制一帧内容耗时太长； 主线程太忙了，导致vsync信号来的时候还没计算好数据导致丢帧； （7）开发中优化建议： ①主线程不要做耗时操作，如大量的cursor操作和ams操作，执行复杂算法； ②降低gc几率，图片加载优化，避免创建大量对象； ③io密集型任务放在子线程执行 ④cpu密集型任务在子线程中串行执行

1、内存泄漏的根本原因在于生命周期长的对象持有了生命周期短的对象的引用 2、常见场景 （1）资源对象没关闭造成的内存泄漏（如： Cursor、File等） （2）全局集合类强引用没清理造成的内存泄漏（特别是 static 修饰的集合） （3）接收器、监听器注册没取消造成的内存泄漏，如广播，eventsbus （4）Activity 的 Context 造成的泄漏，可以使用 ApplicationContext （5）单例中的static成员间接或直接持有了activity的引用 （6）非静态内部类持有父类的引用，如非静态handler持有activity的引用 3、如何避免内存泄漏 （1）编码规范上： ①资源对象用完一定要关闭，最好加finally ②静态集合对象用完要清理 ③接收器、监听器使用时候注册和取消成对出现 ④context使用注意生命周期，如果是静态类引用直接用ApplicationContext ⑤使用静态内部类 ⑥结合业务场景，设置软引用，弱引用，确保对象可以在合适的时机回收 （2）建设内存监控体系 线下监控： ①使用ArtHook检测图片尺寸是否超出imageview自身宽高的2倍 ②编码阶段Memery Profile看app的内存使用情况，是否存在内存抖动，内存泄漏，结合Mat分析内存泄漏 线上监控： ①上报app使用期间待机内存、重点模块内存、OOM率...

same issue

作者啥时候能把拖动及拖动后转换成矩形的逻辑给实现了，很期待

优点：使用方便，既可以执行串行任务，也可以执行并行任务 缺点：默认使用串行任务执行效率低，不能充分利用多线程加快执行速度；如果使用并行任务执行，在任务特别多的时候会阻塞UI线程获得CPU时间片，后续做线程收敛需要自定义AsynTask，将其设置为全局统一的线程池，改动量比较大