内存优化

80C51在物理结构上有四个存储空间：片内程序存储器、片外程序存储器、片内数据存储器和片外数据存储器。但在逻辑上，即从用户使用的角度上，80C51有三个存储空间：片内外统一编址的64KB的程序存储器地址空间（用16位地址）、256B的片内数据存储器的地址空间（用8位地址，其中128B的专用寄存器地址空间仅有21个字节有实际意义）以及64KB片外存储器地址空间。 1、程序存储器 程序存储器用于存放编好的程序和表格常数。80C51片内有4KB ROM，片外16位地址线最多可扩展64KB ROM，两者是统一编址的。如果EA端保持高电平，80C51的程序计数器PC在0000H——0FFFH范围内（即前4KB地址）是执行片内ROM的程序。当寻址范围在1000H——FFFFH时，则从片外存储器取指令。当EA端保持低电平时，80C51的所有取指令操作均在片外程序存储器中进行，这时片外存储器可以从0000H开始编址。 程序存储器中，以下6个单元具有特殊功能。 0000H：80C51复位后，PC=0000H，即程序从0000H开始执行指令。 0003H：外部中断0入口。 000BH：定时器0溢出中断入口。 0013H：外部中断1入口。 001BH：定时器1溢出中断入口。 0023H：串行口中断入口。 2、数据存储器 数据存储器用于存放中间运算结果、数据暂存和缓冲、标志位等。80C51片内有256B

转载请注明本文出自大苞米的博客（ http://blog.csdn.net/a396901990 ），谢谢支持！ 写在最前： 本文的思路主要借鉴了2014年AnDevCon开发者大会的一个演讲PPT，加上把网上搜集的各种内存零散知识点进行汇总、挑选、简化后整理而成。 所以我将本文定义为一个工具类的文章，如果你在ANDROID开发中遇到关于内存问题，或者马上要参加面试，或者就是单纯的学习或复习一下内存相关知识，都欢迎阅读。（本文最后我会尽量列出所参考的文章）。 OOM： 内存泄露可以引发很多的问题： 1.程序卡顿，响应速度慢（内存占用高时JVM虚拟机会频繁触发GC） 2.莫名消失（当你的程序所占内存越大，它在后台的时候就越可能被干掉。反之内存占用越小，在后台存在的时间就越长） 3.直接崩溃（OutOfMemoryError） ANDROID内存面临的问题： 1.有限的堆内存，原始只有16M 2.内存大小消耗等根据设备，操作系统等级，屏幕尺寸的不同而不同 3.程序不能直接控制 4.支持后台多任务处理（multitasking） 5.运行在虚拟机之上 5R： 本文主要通过如下的5R方法来对ANDROID内存进行优化： 1.Reckon（计算） 首先需要知道你的app所消耗内存的情况，知己知彼才能百战不殆 2.Reduce（减少） 消耗更少的资源 3.Reuse（重用） 当第一次使用完以后

[DESCRIPTION] 总有些项目的内存优化落到Camera头上，从Hal1到Hal3，永不停歇...以下适用于HAL3（Android P）. 众所周知，内存与Performance在某些条件下，是无法调和的矛盾，请大家根据各项目状态酌情选用. [SOLUTION] 内存用量概要：adb shell dumpsys meminfo camerahalserver 内存用量大头（Graphics部分）分解：adb shell cat /sys/kernel/debug/ion/ion_mm_heap > ion_1 查看优化效果，对比优化前后meminfo中的total即可. 那么会有哪些省内存办法呢？请看下文. 1.拍照后buffer立即释放 优点：拍照过程中产生的buffer使用完毕后即释放，不影响拍照后的内存用量； 缺点：内存存量不高的情况下，拍照速度会受影响; 优化量：与拍照实际feature有关，拍照feature越多占用内存越大，优化量越大; /vendor/mediatek/proprietary/hardware/mtkcam3/feature/core/featurePipe/capture/buffer/CaptureBufferPool.cpp mpTuningBufferPool->setAutoFree(0); //拍照后release tuning

Android编程中一个共同的困难就是协调Activity的生命周期和长时间运行的任务(task)，并且要避免可能的内存泄露。思考下面Activity的代码，在它启动的时候开启一个线程并循环执行任务。 1 /** 2 * 一个展示线程如何在配置变化中存活下来的例子（配置变化会导致创 3 * 建线程的Activity被销毁）。代码中的Activity泄露了，因为线程被实 4 * 例为一个匿名类实例，它隐式地持有外部Activity实例，因此阻止Activity 5 * 被回收。 6 */ 7 public class MainActivity extends Activity { 8 9 @Override 10 protected void onCreate(Bundle savedInstanceState) { 11 super.onCreate(savedInstanceState); 12 exampleOne(); 13 } 1415 private void exampleOne() { 16 new Thread() { 17 @Override 18 public void run() { 19 while (true) { 20 SystemClock.sleep(1000); 21 } 22 } 23 }.start(); 24 } 25 } 当配置发生变化

本文章主要从软引用和弱引用的角度探讨Bitmap的内存优化。 Java从JDK1.2之后就将对象的引用分为4个级别：强引用、软引用、弱引用、虚引用。具体的概念不详述了。 软引用：当内存空间足够的时候，GC就不会回收它，内存空间不足了，就会回收。 弱引用：GC工作过程中，一旦发现了弱引用对象，不管内存足够与否，都会回收它的内存。 所以，从上述可以看出，软引用和弱引用的根本区别在于：只具有弱引用的对象拥有更短暂的生命周期，可能随时被回收。 当缓存大量的Bitmap时，比较容易造成OOM，所以可以考虑使用软引用技术来避免这个问题的发生。 //首先定义一个HashMap，保存软引用对象 private Map<string, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>(); //保存Bitmap的软引用到HashMap public void addBitmapToCache(String path) { //强引用的Bitmap对象 Bitmap bitmap = BitmapFactory.decodeFile(path); //软引用的Bitmap对象 SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>

android开发过程中，对于内存优化也是特别重要的，在面试当中也会问到这些问题，那么怎么样做内存优化呢，内存优化一般会从三个方面优化 1.内存抖动：锯齿状，GC导致卡顿 2.内存泄露：可用内存减少，频繁GC 3.内存溢出：OOM,程序异常 工具选择 1.Memory profiler 它是用实时图表的形式来展示应用内存使用量 2.Memory Analyzer 它是强大的Java Heap分析工具，查找内存泄露和内存占用情况 3.LeakCanary 它是自动内存泄露检测工具 github: https://github.com/square/leakcanary 来源： CSDN 作者： 爱码士_yan 链接： https://blog.csdn.net/baidu_41666295/article/details/104516884

内存抖动 public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); test(); } private void test(){ for (int i = 0; i < 100; i++) { testMemory(); } } private void testMemory() { String s = ""; for (int i = 0; i < 50000; i++) { s = s + i + ""; } } } 如上写的代码,会产生内存抖动。 内存抖动的profile效果如上图所示。内存抖动会频繁GC，GC的时候会停止其它线程，所以会造成UI线程卡顿。因此要避免内存抖动的情况。 解决方案 尽量避免在循环体内创建对象，应该把对象创建移到循环体外。 注意自定义View的onDraw()方法会被频繁调用，所以在这里面不应该频繁的创建对象。 当需要大量使用Bitmap的时候，试着把它们缓存在数组中实现复用。（Glide复用池） 对于能够复用的对象

Android内存优化是我们性能优化工作中比较重要的一环，这里其实主要包括两方面的工作： 优化RAM，即降低运行时内存。这里的目的是防止程序发生OOM异常，以及降低程序由于内存过大被LMK机制杀死的概率。另一方面，不合理的内存使用会使GC大大增多，从而导致程序变卡。 优化ROM，即降低程序占ROM的体积。这里主要是为了降低程序占用的空间，防止由于ROM空间不足导致程序无法安装。 本文的着重点为第一点，总结概述降低应用运行内存的技巧。在这里我们不再细述PSS、USS等概念与Android应用的内存管理，如对这部分内容感兴趣，可自行阅读文末的参考文章。 内存泄露的检测与修改 内存泄露：简单来说对象由于编码错误或系统原因，仍然存在着对其直接或间接的引用，导致系统无法进行回收。内存泄露，容易留下逻辑隐患,同时增加了应用内存峰值与发生OOM的概率。它属于bug issue,是我们一定要修改的。 下面是造成内存泄露的一些常见原因，但是如何建立一套发现内存泄露、解决内存泄露的闭环方案，才是我们工作的重点。 一. 内存泄露的监控方案 Square的开源库leakcanry是一个非常不错的选择,它通过弱引用方式侦查Activity或对象的生命周期，若发现内存泄露自动dump Hprof文件，通过HAHA库得到泄露的最短路径，最后通过notification展示。 内存泄露判断与处理的流程如下图

一：内存占用几大要点 1，Object Cache：Image cache，single instance obj（重量级别，例如数据库连接obj,bitmap ref），Thread过多， 2，View Ref过多：view 本身结构嵌套过多，过于复杂，background子元素image过多，使得单个view对象占有内存较多，如果View Container含有这实例对象过多，则会导致oom 3，组建Activity，service过多，也是会使app内存占用过高 4，leak Memmory：叠加效应导致内存异常占用 （简单叙述一下泄漏主因：全局成员变量引用(包括间接引用)components（Activity，Service，Broadcast，View及内部非static类），导致其无法回收资源）， 5,有必要在合适的时候进行Trim cache 开发中注意以下几个方面： (1)字符串拼接优化,减少字符串使用加号拼接，改为使用StringBuilder，初始化时设置capacity。 (2) 读文件优化 读文件使用ByteArrayPool，初始设置capacity，减少expand (3) 资源重用,建立缓存池，对频繁申请、释放的对象类型重用 (4) 减少不必要或不合理的对象,例如在ondraw、getview中应减少对象申请，尽量重用。例如循环中不断申请局部变量等

--卸载不用的资源所占内存 主要是img_bg_match 常驻内存占有大概10M 增加代码 --CS.UnityEngine.Resources.UnloadUnusedAssets(); --CS.System.GC.Collect(); --可以屏蔽所有这个代码即可在Profiler Memory观测到 --实测项目有用 参考： https://blog.csdn.net/qq_35080168/article/details/87933482 来源： CSDN 作者： 那个妹子留步 链接： https://blog.csdn.net/weixin_41995872/article/details/103787785