内存优化02

SAP-ABAP:S/4HANA 下的 ST02 深度解读:从缓冲区监控到内存架构优化 本文深入探讨了SAP S/4HANA系统中ST02事务码的性能监控与优化策略,重点分析了内存数据库环境下缓冲区的角色变化。文章指出,在HANA架构中,传统表缓冲带来的同步开销、数据延迟和内存浪费等问题已超过其性能收益,建议关闭绝大多数业务表的缓冲,仅保留极少数静态配置表的缓存。对于程序缓冲区,由于其编译加速作用不可替代,仍需保持高命中率(99.5%以上),并利用预加载机制优化系统启动性能。通过真实案例展示了不当的表缓冲配置如何导致财务过账阻塞,以及程序缓冲不足引发的Fiori应用响应延迟问题,为S/4HAN 阅读详情

1 内存优化—减少内存使用(Reduce)

如果减少某些不必要内存的使用,也可以达到内存优化的目的。

比如说Bitmap。它在使用时会花掉较多的内存。那我们就可以考虑在应用bitmap时减少某些不必要内存的使用。

  • 边界压缩:一张拍出来的图片分辨率可能会很大,如果不做压缩去展示的话,会消耗大量内存,可能造成OOM,通过BitmapFactory.Options去设置inSampleSize,可以对图片进行边界的压缩,减少内存开销。(做法:先设置BitmapFactory.inJustDecodeBounds为true,然后decodeFile,这样将会只去解析图片大小等信息,避免了将原图加载进内存。拿到原图尺寸信息后,根据业务逻辑换算比例,设置inSampleSize,接着设置BitmapFactory.inJustDecodeBounds为false,最后再去decodeFile,从而实现对图片边界大小进行了压缩再展示。)

    inSampleSize

  • 色彩压缩:除此之外,还可以通过设置Bitmap图片的Config配置来减少内存使用。配置有以下四种:

    ALPHA_8(Alpha由8位组成,代表8位Alpha位图)

    ARGB_4444(由4个4位组成即16位,代表16位ARGB位图)

    ARGB_8888(由4个8位组成即32位,代表32位ARGB位图,图片质量最佳)

    RGB_565(R为5位,G为6位,B为5位,共16位,它是没有透明度的)

    如果配置不一样,需要的内存也不同。比如ARGB4444、ARGB8888、RGB565。配置的位数越高,图片质量越佳,当然需要的内存就越多。如果图片不需要透明度,就采用RGB565的配置。通过Bitmap.Config配置,也可以起到压缩图片大小作用。

    在实际中,可以通过以下代码来进行图片转bitmap解码时的Config。

          BitmapFactory.Options options = new BitmapFactory.Options();
          options.inPreferredConfig = Bitmap.Config.RGB_565;
          Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.ic_menu_add, options);
  • 如果通过在列表中展示缩略图的形式来加载图片,如果需要查看高清图片,另启动一个页面(对话框)来加载高清图片,这样可以避免在列表中加载太多高清图片,减少内存开销。

2 内存优化—回收(Recycle)

一些资源时使用时记得回收,比如说BraodcastReceiver,ContentObserver,File,Cursor,Stream,Bitmap、TypeArray等资源的代码,应该在使用之后或者Activity销毁时及时关闭或者注销,否则这些资源可能将不会被回收,造成内存泄漏。

3 内存优化—重用(Reuse)

3.1 对象池

在程序里面经常会遇到的一个问题是短时间内创建大量的对象,导致内存紧张,从而触发GC导致性能问题。对于这个问题,我们可以使用对象池技术来解决它。通常对象池中的对象可能是bitmaps,views,messages等等。

比如说Message.obtain()方法。通过handler去发消息Message时,通过Message.obtain()来获得一个消息,就比直接通过new一个Message要更好。因为Message中内部就维护了一个对象池用来存放消息,通过obtain方法来取消息的话,会先从内部的对象池中去取,如果取不到,再去新创建一个消息进行使用。

再比如说线程池。开启新线程来执行任务可以用new Thread()来做,但这样做的弊端如下:

  • 每次new Thread新建对象性能差。
  • 线程缺乏统一管理,可能无限制新建线程,相互之间竞争,及可能占用过多系统资源导致死机或oom。
  • 缺乏更多功能,如定时执行、定期执行、线程中断。

相比new Thread,Java提供的四种线程池的好处在于:

  • 重用存在的线程,减少对象创建、消亡的开销,性能佳。
  • 可有效控制最大并发线程数,提高系统资源的使用率,同时避免过多资源竞争,避免堵塞。
  • 提供定时执行、定期执行、单线程、并发数控制等功能。

Java通过Executors提供四种线程池,分别为:

  • newSingleThreadExecutor 创建一个单线程化的Executor,它只会用唯一的工作线程来执行任务,保证所有任务按照指定顺序(比如FIFO)执行。最大特点是可以保证按照顺序执行各个任务,不会有多个线程是可活动的。
  • newScheduledThreadPool 创建一个定长线程池,可控制线程最大并发数,支持定时及周期性任务执行,类似于Timer。
  • newFixedThreadPool 创建一个定长线程池,可控制线程最大并发数,超出的线程会在队列中等待。
  • newCachedThreadPool 创建一个可缓存的线程池。可创建的最大线程数量没有限制,如果长时间(60秒)没有向线程池中提交新任务,则空闲线程会被终止。

关于对象池的操作原理,请看下面的图示:

![object pool](object pool.png)

使用对象池技术有很多好处,它可以避免内存抖动,提升性能,但是在使用的时候有一些内容是需要特别注意的。通常情况下,初始化的对象池里面都是空白的,当使用某个对象的时候先去对象池查询是否存在,如果不存在则创建这个对象然后加入对象池。

但是我们也可以在程序刚启动的时候就事先为对象池填充一些即将要使用到的数据,这样可以在需要使用到这些对象的时候提供更快的首次加载速度,这种行为就叫做预分配。

使用对象池也有不好的一面,我们需要手动管理这些对象的分配与释放,所以我们需要慎重地使用这项技术,避免发生对象的内存泄漏。为了确保所有的对象能够正确被释放,我们需要保证加入对象池的对象和其他外部对象没有互相引用的关系。

3.2 缓存

无论是为了提高CPU的计算速度还是提高数据的访问速度,在绝大多数的场景下,我们都会使用到缓存。

例如缓存到内存里面的图片资源,网络请求返回数据的缓存等等。凡是可能需要反复读取的数据,都建议使用合适的缓存策略。比如图片三级缓存、ListView中的Adapter使用contentView进行复用、使用holder避免重复的findViewById。再比如以下的代码,都是缓存的体现。

        //原代码
        for (int i = 0; i < 1024; i++) {
            if(i<getCount()){
                Log.d("TAG", "some log" + i);
            }
        }

        //有缓存体现的代码,避免重复调用1024次getCount方法
        int count = getCount();
        for (int i = 0; i < 1024; i++) {
            if(i<count){
                Log.d("TAG", "some log" + i);
            }
        }
3.2.1 缓存中的lru算法

lru算法(Least Recently Use),即最近最少使用算法,在Android中比较常用。当内存超过限定大小时,凡是近时间内最少使用的那一个对象,就会从缓存容器中被移除掉。

LRU Cache的基础构建用法如下:

        //往缓存中添加图片,PicUrl是图片的地址,将其作为key,bitmap位图则作为value
        bitmapLRUCache.put(picUrl,bitmap);
        //通过picUrl图片地址,从缓存中取bitmap
        bitmapLRUCache.get(picUrl);

为了给LRU Cache设置一个比较合理的缓存大小值,我们通常是用下面的方法来做界定的:

        //当前应用最大可用内存
        long maxMemory = Runtime.getRuntime().maxMemory();
        //创建一个LRUCache,设置缓存大小界限为最大可用内存的八分之一
        BitmapLRUCache bitmapLRUCache = new BitmapLRUCache((int)maxMemory / 8);

使用LRU Cache时为了能够让Cache知道每个加入的Item的具体大小,我们需要Override下面的方法:

public class BitmapLRUCache extends LruCache<String,Bitmap> {

    public BitmapLRUCache(int maxSize) {
        super(maxSize);
    }

    @Override
    protected int sizeOf(String key, Bitmap value) {
        int byteCount = value.getByteCount();//该bitmap位图所占用的内存字节数
        return byteCount;
    }
}
3.2.2 避免创建大量的临时对象

如果创建大量的临时对象,会导致内存上出现抖动。![memory shake](memory shake.png)

上图为Android Studio中Memory Monitor,图中的波浪线就表示,内存的开销忽上忽下,出现了抖动,此时应用容易出现卡屏掉帧。

为了避免创建大量临时对象,注意:

  • 在高频率执行的方法中注意尽量不要创建对象,像View的onTouch和onDraw方法
  • 在做较多的字符串拼接时,采用StringBuilder、StringBuffer。

4 内存优化—检查(Review)

代码写完了只是个开始。比较规范的编码,都需要Review的。代码检查时的注意点可参考上述内容。

接下来要提到的是UI检查。

4.1 查看UI布局是否过度绘制(overdraw)

查看的前提是:移动设备已经开启了开发者选项。

在开发者选项中,点击“调试GPU过度绘制”,将弹出对话框,然后选择“显示过度绘制区域”,如下图所示:

overdraw

屏幕这时候会变得花花绿绿的. 这些颜色是用来帮助你诊断应用程序的显示行为的。

overdraw02

这些颜色用于表示每个像素被重绘的次数, 含义如下:

真实颜色: 没有被重绘

蓝色: 重绘一次

绿色: 重绘两次

粉色: 重绘三次

红色: 重绘四次或更多次

overdraw03

通过这个工具,可以实现这些事情:

  • 展示一个APP在何处做了不必要的渲染绘制。

  • 帮助你查看在哪里可以减少渲染绘制。

有些重绘是不可避免的. 尽量调整APP的用户界面, 目标是让大部分的屏幕都是真实的颜色以及重绘一次的蓝色。

PS:Activity是有默认颜色的,如果你已经在Layout文件中给页面设置了颜色,那么Activity的默认颜色可以去掉,这样也能减少一层绘制。

        setContentView(R.layout.activity_overdraw_01);
        //设置取消Activity的默认背景色
        getWindow().setBackgroundDrawable(null);

4.2 查看UI布局的渲染速度

查看的前提是:移动设备已经开启了开发者选项。

在开发者选项中,点击“GPU呈现模式分析”,将弹出对话框,然后选择“在屏幕上显示为条形图”,如下图所示:

![GPU Monitor](GPU Monitor.jpg)

这时,将会在屏幕下方出现条形图,如下图所示:

![GPU Monitor2](GPU Monitor2.jpg)

该工具会为每个可见的APP显示一个图表,水平轴即时间流逝, 垂直轴表示每帧经过的时间,单位是毫秒。

在与APP的交互中, 垂直栏会显示在屏幕上, 从左到右移动, 随着时间推移,绘制帧的性能将会迅速体现出来。

绿色的线是用于标记16毫秒的分隔线(PS:人眼的原因, 1秒24帧的动画才能感到顺畅. 所以每帧的时间大概有41ms多一点点(1000ms/24). 但是但是, 注意了, 这41ms不是全都留给你Java代码, 而是所有java native 屏幕等等的, 最后留给我们用java级别代码发挥的时间, 只有16~17ms),只要有一帧超过了绿线, 你的APP就会丢失一帧。

4.3 查看UI布局的层级和实现方式

有的UI界面写的效率比较低,我们可以通过一些工具来进行UI方面的视图检查。Hierarchy Viewer工具可以展示当前手机界面的View层级。

使用该工具的前提是:只能在模拟器或开发版手机上才能用,普通的商业手机是无法连上的。主要是出于安全考虑,普通商业手机中view server这个服务是没有开启的. Hierarchy Viewer就无法连接到机器获取view层级信息。(PS:如果愿意花功夫捣鼓,也可以在真机上强行开启View Server,详情见[网上资料][http://blog.youkuaiyun.com/autumn_xl/article/details/40741835])

先打开模拟器运行要查看的页面,然后打开Hierarchy Viewer工具,它位于android的sdk所在目录中,具体位置为…\sdk\tools\hierarchyviewer.bat。打开后如图所示:

![hierarchy viewer](hierarchy viewer.jpg)

列表展示手机中已打开的页面(包括状态栏等)。这里以电话应用中的DialtactsActivity为例,双击DialtactsActivity,将会打开关于该页面的树状图。如下图所示:

![hierarchy viewer tree](hierarchy viewer tree.jpg)

图中标出了3个部分:

  • ① Tree View:

    树状图的形式展示该Activity中的View层级结构。可以放大缩小,每个节点代表一个View,点击可以弹出其属性的当前值,并且在LayoutView中会显示其在界面中相应位置。

  • ② Tree Overview

    它是Tree View的概览图。有一个选择框, 可以拖动选择查看。选中的部分会在Tree View中显示

  • ③ Layout View

    匹配手机屏幕的视图,如果在Tree View中点击了某个节点,呢么这个节点在手机中的真是位置将会在Layout View中以红框的形式被标出。

接下来介绍点击Tree View中某个节点时,它所展示的信息类似于下图:

![Tree View Args](Tree View Args.jpg)

下面的三个圆点,依次表示Measure、Layout、Draw,可以理解为对应View的onMeasure,onLayout,onDraw三个方法的执行速度。

  • 绿色:表示该View的此项性能比该View Tree中超过50%的View都要快。
  • 黄色:表示该View的此项性能比该View Tree中超过50%的View都要慢。
  • 红色:表示该View的此项性能是View Tree中最慢的。

如果界面中的Tree View中红点较多,那就需要注意了。一般的布局可能有以下几点:

  1. Measure红点,可能是布局中多次嵌套RelativeLayout,或是嵌套的LinearLayout都使用了weight属性。
  2. Layout红点,可能是布局层级太深。
  3. Draw红点,可能是自定义View的绘制有问题,复杂计算等。

5 UI布局优化

5.1 避免过度绘制(Overdraw)

5.2 减少布局层级

  • 尽量减少嵌套,去除不必要的父布局。
  • 尽量不要在RelativeLayout中嵌套使用RelativeLayout,相对布局它会有两次测量Measure两次layout。
  • LinearLayout使用Weight属性时,效率会降低至相对布局一样,出现多次测量Measure和布局Layout,所以尽量不要在LinearLayout嵌套LinearLayout时,两个都使用weight属性
  • 善用TextView、EditText等控件的Drawable属性来减少布局。

5.3 复用(id、style)

5.4 使用include、merge、viewStub标签

5.4.1 include标签

include标签常用于将布局中的公共部分提取出来供其他layout共用,以实现布局模块化,这在布局编写上提供了大大的便利。

下面以在一个布局main.xml中用include引入另一个布局foot.xml为例。main.mxl代码如下

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
    <ListView
        android:id="@+id/simple_list_view"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_marginBottom="@dimen/dp_80" />
    <include layout="@layout/foot.xml" />
</RelativeLayout>

其中include引入的foot.xml为公用的页面底部,foot.xml代码如下

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
    <Button
        android:id="@+id/button"
        android:layout_width="match_parent"
        android:layout_height="@dimen/dp_40"
        android:layout_above="@+id/text"/>
    <TextView
        android:id="@+id/text"
        android:layout_width="match_parent"
        android:layout_height="@dimen/dp_40"
        android:layout_alignParentBottom="true"
        android:text="@string/app_name" />
</RelativeLayout>

<include>标签唯一需要的属性是layout属性,指定需要包含的布局文件。在该标签中,还可以定义android:id和android:layout_*属性来覆盖被引入布局根节点的对应属性值。注意重新定义android:id后,子布局的顶结点i就变化了。

5.4.2 merge标签

在使用了include后可能导致布局嵌套过多,多余不必要的layout节点,从而导致解析变慢,不必要的节点和嵌套可通过上文中提到的hierarchy viewer来查看。而merge标签可以消除那些include时不必要的layout节点。

merge标签可用于两种典型情况:

  1. 布局顶结点是FrameLayout且不需要设置background或padding等属性,可以用merge代替,因为Activity内容试图的parent view就是个FrameLayout,所以可以用merge消除只剩一个。
  2. 某布局作为子布局被其他布局include时,使用merge当作该布局的顶节点,这样在被引入时顶结点会自动被忽略,而将其子节点全部合并到主布局中

以上一节中的<include>标签的示例为例,用hierarchy viewer查看main.xml布局如下图:

merge

可以发现多了一层没必要的RelativeLayout,将foot.xml中RelativeLayout改为merge,如下:

<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
    <Button
        android:id="@+id/button"
        android:layout_width="match_parent"
        android:layout_height="@dimen/dp_40"
        android:layout_above="@+id/text"/>
    <TextView
        android:id="@+id/text"
        android:layout_width="match_parent"
        android:layout_height="@dimen/dp_40"
        android:layout_alignParentBottom="true"
        android:text="@string/app_name" />
</merge>

运行后再次用hierarchy viewer查看main.xml布局如下图:

merge02

这样就不会有多余的RelativeLayout节点了。

5.4.3 viewStub标签

viewstub标签同include标签一样可以用来引入一个外部布局,不同的是,viewstub引入的布局默认不会扩张,即既不会占用显示也不会占用位置,从而在解析layout时节省cpu和内存。

viewstub常用来引入那些默认不会显示,只在特殊情况下显示的布局,如进度布局、网络失败显示的刷新布局、信息出错出现的提示布局等。

下面以在一个布局main.xml中加入网络错误时的提示页面network_error.xml为例。main.mxl代码如下:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
    ……
    <ViewStub
        android:id="@+id/network_error_layout"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout="@layout/network_error" />
</RelativeLayout>

其中network_error.xml为只有在网络错误时才需要显示的布局,默认不会被解析,示例代码如下:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
    <Button
        android:id="@+id/network_setting"
        android:layout_width="@dimen/dp_160"
        android:layout_height="wrap_content"
        android:layout_centerHorizontal="true"
        android:text="@string/network_setting" />
    <Button
        android:id="@+id/network_refresh"
        android:layout_width="@dimen/dp_160"
        android:layout_height="wrap_content"
        android:layout_below="@+id/network_setting"
        android:layout_centerHorizontal="true"
        android:layout_marginTop="@dimen/dp_10"
        android:text="@string/network_refresh" />
</RelativeLayout>

在java中通过(ViewStub)findViewById(id)找到ViewStub,通过stub.inflate()展开ViewStub,然后得到子View,如下

private View networkErrorView;
private void showNetError() {
    // not repeated infalte
    if (networkErrorView != null) {
        networkErrorView.setVisibility(View.VISIBLE);
        return;
    }
    ViewStub stub = (ViewStub)findViewById(R.id.network_error_layout);
    networkErrorView = stub.inflate();
    Button networkSetting = (Button)networkErrorView.findViewById(R.id.network_setting);
    Button refresh = (Button)findViewById(R.id.network_refresh);
}
private void showNormal() {
    if (networkErrorView != null) {
        networkErrorView.setVisibility(View.GONE);
    }
}

在上面showNetError()中展开了ViewStub,同时我们对networkErrorView进行了保存,这样下次不用继续inflate。

上面展开ViewStub部分代码

ViewStub stub = (ViewStub)findViewById(R.id.network_error_layout);
networkErrorView = stub.inflate();

也可以写成下面的形式

View viewStub = findViewById(R.id.network_error_layout);
viewStub.setVisibility(View.VISIBLE);   // ViewStub被展开后的布局所替换
networkErrorView =  findViewById(R.id.network_error_layout); // 获取展开后的布局

两者效果一致,只是不用显示的转换为ViewStub。通过viewstub的原理我们可以知道将一个view设置为GONE不会被解析,从而提高layout解析速度,而VISIBLE和INVISIBLE这两个可见性属性会被正常解析。

5.5 使用Spannable或Html.fromHtml

举例说明,比如下图中红框标出来的效果:

spannable

比较笨的方法就是使用多个TextView,然后设置不同的字体及颜色。

其实用一个TextVIew就可以实现,类似如下代码

 String text = String.format("¥%1$s  门市价:¥%2$s", 18.6, 22);
 int z = text.lastIndexOf("门");
 SpannableStringBuilder style = new SpannableStringBuilder(text);
 style.setSpan(new AbsoluteSizeSpan(DisplayUtil.dip2px(mContext,14)), 0, 1, Spannable.SPAN_EXCLUSIVE_INCLUSIVE); //设置第一个符号的字号
 style.setSpan(new ForegroundColorSpan(Color.parseColor("#afafaf")), z, text.length(), Spannable.SPAN_EXCLUSIVE_INCLUSIVE); //设置门市价那段文本的字体的颜色
 style.setSpan(new AbsoluteSizeSpan(DisplayUtil.dip2px(mContext,14)), z, text.length(), Spannable.SPAN_EXCLUSIVE_INCLUSIVE); //设置门市价那段文本的字体的字号

 tv.setText(style);
iOS进阶-02:iOS开发内存优化问题 一、类对象的内存优化 对于 iOS 开发的程序员来说,内存优化是自始至终都要考虑的一个关键问题,所以这一次咱们来说一下如何优化项目中的内存使用率。在针对内存优化开始前我们必须了解一点:内存在 iOS 开发中所占的位置和意义非常重要。 iOS 程序员对于内存的概念应该接触较深,在刚开始接触 iOS 开发时,我们应该对于iOS的内存处理机制有过一定的了解。iOS 的内存处理机制为引用计数管理,当我们针对一个类进行实例化时,就是对当前对象在内存空间中申请一个内存地址,用来以后的... 阅读详情

相关推荐

Linux SMP系统多核启动机制详解

对称多处理(SMP)是现代操作系统支持多核并行计算的基础架构。其核心原理是通过引导处理器(BSP)初始化系统环境后,通过处理器间中断(IPI)机制唤醒应用处理器(AP)。在x86架构中,AP启动时处于实模式,需要特殊的trampoline代码完成保护模式切换和分页设置。这种设计既保证了系统初始化的正确性,又实现了多核并行处理的性能优势。理解SMP启动流程对优化系统启动速度和调试多核问题至关重要,特别是在云计算和嵌入式系统中,高效的SMP初始化能显著提升系统响应能力。本文以Linux内核为例,深入解析了从BS

weixin_35006125的博客 290

PIC代码优化笔记(降低.bin文件尺寸)

一次代码优化实战

含光左卫的工作笔记集 486

产品经理-面试题目--持续更新

答:面试官,你好,我叫XXX,来自于XXXX,我系统的学习过软件开发,也主动的积累了不少产品方面的实战经验,在学习期间,我自己独立的完成了2个深度项目,一个是仿抖音的短视频APP全流程设计,另外一个是电商后台系统的模块,通过这些项目,我不仅熟练使用Axure等工具做出高保真原型图和清晰的产品框架,也形成了数据驱动和用户优先的思维习惯,另外,我也注重拓展自己的能力边界,拿到了CAIE人工智能证书,我希望能把AI能力融入到产品场景,提升体验和效率,我非常喜欢产品工作带来的创造性和逻辑性,希望有机会加入贵公司。

m0_63966958的博客 957

位置无关(PIC)代码原理剖析

共享库的一个关键目的是为了使多个进程能够共享内存中的同一份代码拷贝,已达到节约内存资源的目的。如何做到呢?一种方法是预先为每一个共享库指定好加载的地址范围,然后要求加载器总是将共享库加载至指定的位置。这种方法尽管很简单,但是会产生一些严重的问题。因为就算一个进程并没有用到某个库,相应的地址范围依然会被保留下来,这是一种效率很低的内存使用方式。另外,这种方法管理起来也很困难。我们必须保证预留的地址块

PacMan的专栏 1万+

阿里云习题多选部分459道

比如: UserA的用户在杭州有一台经典网络的ECS云服务器InstanceA (内网IP: A.A.A),InstanceA所属的默认安全组为GroupA, UserB的用户在杭州有一台经 典网络的ECS云服务器InstanceB(内网IP:B.B.B),InstanceB所属的默认安全组为GroupB。43.创建阿里云的云服务器ECS实例之前,需要对ECS实例的配置进行选型,阿里云为用户提供了推荐的配置组合方案来满足大部分用户的需求,这些推荐配置只是作为开始使用云服务器ECS实例的参考。

2501_91384465的博客 1310

深度强化学习在足式机器人中的应用 (一):基础原理与仿真环境

我们将首先深入探讨其背后的核心挑战与技术栈,然后详细推导机器人学和强化学习的基本数学原理,特别是剖析在机器人控制领域表现卓越的PPO算法。下面的独立Python脚本展示了Isaac Gym的基本API用法,加载一个Go1机器人(假设URDF已准备好),并让它执行一个简单的预设动作(正弦波运动),以此来熟悉仿真流程。:代码的核心是直接操作GPU上的PyTorch张量,避免了CPU和GPU之间的数据拷贝,这是实现高性能的关键。:所有计算(如伪策略中的正弦波计算)都应该是向量化的,一次性为所有。

VectorShift的博客 228

深入探索 Android 内存优化(炼狱级别)

前言 成为一名优秀的Android开发,需要一份完备的知识体系,在这里,让我们一起成长为自己所想的那样~。 本篇是 Android 内存优化的进阶篇,难度可以说达到了炼狱级别,建议对内存优化不是非常熟悉的仔细看看前篇文章:Android性能优化之内存优化,其中详细分析了以下几大模块: 1)、Android的内存管理机制 2)、优化内存的意义 3)、避免内存泄漏 4)、优化内存空间 5)、图片管理模块的设计与实现 如果你对以上基础内容都比较了解了,那么我们便开始 Android 内...

idaretobe的专栏 4148

8、多导睡眠图记录中基于级联自适应滤波器的脑电图信号噪声去除

本文提出了一种基于三级级联自适应滤波器的新型方法,用于去除多导睡眠图(PSG)记录中脑电图(EEG)信号的常见伪迹,包括50/60 Hz电源线干扰、心电图(ECG)和眼电图(EOG)伪迹。该方法采用最小均方(LMS)算法,通过分阶段滤波有效分离并衰减各类噪声,在保留EEG关键神经节律信息的同时显著提升信号质量。研究利用MIT-BIH数据库中的18份真实PSG记录进行验证,结果表明该方法具有无相位失真、实现简单、自适应能力强等优势,适用于睡眠研究及脑机接口等生物医学应用领域。

banana的博客 174

Android Span相关知识小记

Android Span相关内容的记录

Sindyue的博客 724

【从零开始学习 UVM】1.1、UVM 概述 —— Preface

【从零开始学习 UVM】1.1、UVM 概述 —— Preface

努力,加油每一天鸭~ 826

120、ISP 驱动架构解析:从 V4L2 请求到 ISP 硬件的配置下发流程

本文以实际案例解析ISP驱动架构的V4L2到硬件配置下发流程。作者通过一个因内存共享导致画面闪烁的bug案例,详细剖析了用户空间参数通过V4L2结构体传递、驱动层拆包与硬件寄存器映射、时序同步机制等关键环节。特别强调深拷贝、dirty flag增量更新、shadow register等实现要点,并给出多路并发隔离、寄存器写入失败等典型问题的排查方法。文章建议开发者深入理解参数到寄存器的转换过程,推荐通过debugfs实时监控寄存器状态,避免过度依赖自动调试工具。全文以实践为导向,对ISP驱动开发具有直接指导

sundong_81的博客 159

android内存优化之三内存分析工具的使用

这一章主要介绍利用工具进行android APP内存泄露分析

yibanbubadao123的博客 3276

17、扩展景深成像的瞳孔函数工程技术解析

本文详细解析了扩展景深成像的关键技术,包括基于焦距堆栈的数字处理方法、立方相位掩模的光学设计、对数非球面透镜的应用以及旋转点扩散函数的深度编码功能。通过实验验证和实际应用分析,展示了这些技术在显微镜成像、工业检测和医疗影像中的广泛用途及优势。同时探讨了未来发展方向,如智能算法优化、新型光学材料和多模态成像技术,为相关领域的技术创新提供了参考。

y2z3a4b5c的博客 168

STM32外扩SRAM实战:23AA02M/23LCV02M选型、SPI/SQI驱动与内存优化

在嵌入式系统开发中,微控制器(MCU)的内置SRAM容量常常成为处理复杂任务(如图形显示、网络通信或数据采集)的瓶颈。通过SPI(串行外设接口)总线扩展外部SRAM是一种常见且高效的解决方案,它能在不占用过多MCU引脚资源的前提下,显著提升系统的数据缓存能力和实时性。其技术价值在于,外部SRAM提供了接近片内RAM的访问速度,同时容量更大,是优化系统内存架构、实现高性能嵌入式应用的关键组件。典型的应用场景包括作为LCD的帧缓冲区、网络协议栈的数据缓存区或高速数据采集的临时存储仓库。本文以Microchip的

weixin_31785177的博客 239

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

WINCC7.3破解文件

WINCC7.3硬件够破解文件,有需要的下载!WINCC7.3硬件够破解文件,有需要的下载!

02JVM内存模型深度剖析与优化

02JVM内存模型深度剖析与优化

Joanna_or_zhouzhou的博客 340

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

Redis内存管理和优化02

好好整理了一下关于reids内存优化的知识,总算对redis内存管理有了一个初步的认识。 一.内存消耗分析 Redis进程内消耗主要包括:自身内存+对象内存+缓冲内存+内存碎片,其中Redis空进程自身内存消耗非常少,通常used_memory_rss在3MB左右,used_memory在800KB左右,一个空的Redis进程消耗内存可以忽略不计。 1...

pengcheng2013的博客 261

02-JVM内存模型深度剖析与优化

JVM内存模型深度剖析与优化

zengqingfa123的博客 2079

Ascend C算子性能优化实用技巧02——内存优化

算子实现中涉及多次vector计算,且前一次计算输出是后一次计算输入的情况下,可将前一次计算输出暂存在UB(Unified Buffer)上直接作为下一次计算的输入,不需要将前一次的计算输出从UB搬运到GM后再从GM搬运到UB。使用UB Buffer融合方式后,在UB上进行连续vector计算时,前一次的结果可直接作为后一次计算的输入,继续在UB上进行计算,不需要中间的搬进搬出,只需在开始计算时将源操作数搬运到UB,以及全部计算结束后将最终结果从UB搬运到GM,共2次搬进搬出。

m0_71340392的博客 1904

关于JVM优化02(内存篇)助你提高代码质量

  上篇讲到了JVM优化的CPU篇,下面讲一讲内存。   诗东本人下面也是通过一个例子来讲述一下我们平时开发中,写代码的过程要注意到的一些地方,可以提高你程序的运行速度,从而提高你的代码质量和薪水! -----------------------  细节一,基本数据类型和引用类型 ----------------------- ​ 要完成上面的操作一,要837毫秒!   要完成操作...

weixin_41866264的博客 237

sap 内存优化

sap 内存优化

wengyupeng 蜗牛一步一步向前。。。 3794

【Unity工程化】02_GC优化与内存池设计实战

本文深入探讨了Unity游戏开发中的GC(垃圾回收)优化与内存池设计实战。文章首先通过两个真实案例(战斗系统卡顿和UI内存风暴)展示了GC问题的严重性,量化分析了GC对性能、体验和电量的影响。随后解析了Unity三层GC架构和Boehm GC的工作流程,重点介绍了增量GC的原理及其配置方法。文章详细列举了四大GC分配来源:装箱操作、字符串拼接、闭包捕获和LINQ使用,并分别提供了优化方案。通过对象池设计、内存预分配等实战技巧,帮助开发者有效降低GC频率,消除游戏卡顿,提升用户体验。

Guangfox的博客 1126

《性能调优之JVM》❤️02JVM内存模型深度剖析与优化

❤️ 近期学习方向:性能调优 ❤️欢迎 点赞 ???? 收藏 ⭐ 留言 ???? 关注 ✌ 私聊我 前言 一、JDK体系结构与跨平台特性 JDK体系结构 JDK: JDK提供了编译、运行Java程序所需的各种资源和工具;包括Java编译器,Java运行时环境【JRE】;开发工具包括编译工具(javac.exe) 打包工具(jar.exe)等; JRE: 即JAVA运行时环境,JVM就是包括在JRE中,以及常用的JAVA类库等; JVM: Java虚拟机,负责运行java程序的机器; SDK: SDK是基于

weixin_46460843的博客 831
上一篇: 内存优化01
下一篇: Java中栈的简单操作
CDCK
博客等级 码龄9年 0粉丝 2原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值