内存优化

柔光的暖阳◎ 2022-04-03 06:09 239阅读 0赞

# **1、Java的四种引用，强弱软虚，及其适用的场景。** #

\- 强引用：  
   - 强引用可以直接访问目标对象。  
   - 强引用所指向的对象在任何时候都不会被系统回收。JVM宁愿抛出OOM异常，也不会回收强引用所指向的对象。  
   - 强引用可能导致内存泄露。

\- 软引用：  
  - 在OutOfMemory异常发生之前，被占用的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。  
  - 需要注意的是，在垃圾回收器对这个Java对象回收前，SoftReference类所提供的get方法会返回Java对象的强引用，一旦垃圾线程回收该Java对象之后，get方法将返回null。所以在获取软引用对象的代码中，一定要判断是否为null，以免出现NullPointerException异常导致应用崩溃。       
    
  - 如果只是想避免OutOfMemory异常的发生，则可以使用软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用弱引用。  
  - 还有就是可以根据对象是否经常使用来判断。如果该对象可能会经常使用的，就尽量用软引用。如果该对象不被使用的可能性更大些，就可以用弱引用。

\- 弱引用：在系统GC时，只要发现弱引用，不管系统堆空间是否足够，都会将对象进行回收。但是，由于垃圾回收器的线程通常优先级很低，因此，并一不定能很快的发现持有弱引用的对象。这种情况下，弱引用对象可以存在较长的一段时间。一旦一个弱引用对象被垃圾回收器回收，便会加入到一个注册引用队列中。

实际应用：播放器的播放Panel，是一个View，就是在视频播放时，可以show、hide, 也可以拖拽进度条之类，还有上面的音量，亮度调节等。这样一个view，我们用弱引用，因为在视频播放过程中，不论硬解还是软解，都将占用大量内存。

\-  虚引用：  
   - 虚引用是所有引用类型中最弱的一个。一个持有虚引用的对象，和没有引用几乎是一样的，随时都可能被垃圾回收器回收。当试图通过虚引用的get()方法取得强引用时，总是会失败。并且，虚引用必须和引用队列一起使用，它的作用在于跟踪垃圾回收过程。  
   - 当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在垃圾回收后，销毁这个对象，奖这个虚引用加入引用队列。

# **2、内存泄漏如何产生，常见的Android内存泄漏的场景，怎么解决。** #

\- 单例造成的内存泄露。  
\- 匿名内部类/非静态内部类和异步线程。

public class MainActivity extends AppCompatActivity {
    
            private static TestResource mResource = null;
    
            @Override
            protected void onCreate(Bundle savedInstanceState) {
                super.onCreate(savedInstanceState);
                setContentView(R.layout.activity_main);
                if (mManager == null) {
                    mManager = new TestResource();
                }
            }
    
           class TestResource {
                
            }
        }

每次启动Activity时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法却会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收。

正确的做法为：将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例。

\- 匿名内部类：android开发经常会继承实现Activity/Fragment/View，此时如果你使用了匿名类，并被异步线程持有了，那要小心了，如果没有任何措施这样一定会导致泄露。  
\- Handler 造成的内存泄漏。  
\- 集合类泄漏。

# **3、怎么发现和分析内存泄漏。** #

## **发现内存泄漏：** ##

一、[内存泄漏][Link 1]的检查方法：  
    1.ccmalloc－Linux和Solaris下对C和[C++程序][C]的简单的使用[内存泄漏][Link 1]和malloc调试库。  
    2.Dmalloc－Debug Malloc Library.  
    3.Electric Fence－Linux分发版中由Bruce Perens编写的malloc()调试库。  
    4.Leaky－Linux下检测内存泄漏的程序。  
    5.LeakTracer－Linux、Solaris和HP-UX下跟踪和分析C++程序中的内存泄漏。  
    6.MEMWATCH－由Johan Lindh编写，是一个[开放源代码][Link 2]C语言内存错误检测工具，主要是通过gcc的precessor来进行。  
    7.Valgrind－Debugging and profiling Linux programs, aiming at programs written in C and C++.  
    8.KCachegrind－A visualization tool for the profiling data generated by Cachegrind and Calltree.  
    9.IBM Rational PurifyPlus－帮助开发人员查明C/C++、托管.NET、Java和VB6代码中的性能和可靠性错误。PurifyPlus 将内存错误和[泄漏检测][Link 3]、应用程序性能描述、代码覆盖分析等功能组合在一个单一、完整的[工具包][Link 4]中。

二、[内存泄漏][Link 1]的简单介绍：  
    内存泄漏也称作“存储渗漏”，用[动态存储分配][Link 5]函数动态开辟的空间，在使用完毕后未释放，结果导致一直占据该[内存单元][Link 6]。直到程序结束。（其实说白了就是该内存空间使用完毕之后未回收）即所谓内存泄漏。  
    内存泄漏形象的比喻是“操作系统可提供给所有进程的存储空间正在被某个进程榨干”，最终结果是程序运行时间越长，占用存储空间越来越多，最终用尽全部存储空间，整个[系统崩溃][Link 7]。所以“[内存泄漏][Link 1]”是从操作系统的角度来看的。这里的存储空间并不是指[物理内存][Link 8]，而是指[虚拟内存][Link 9]大小，这个虚拟内存大小取决于磁盘交换区设定的大小。由程序申请的一块内存，如果没有任何一个指针指向它，那么这块内存就泄漏了。

## **分析内存泄漏：** ##

### 为什么会产生内存泄漏？ ###

当一个对象已经不需要再使用本该被回收时，另外一个正在使用的对象持有它的引用从而导致它不能被回收，这导致本该被回收的对象不能被回收而停留在堆内存中，这就产生了内存泄漏。

### 内存泄漏对程序的影响？ ###

内存泄漏是造成应用程序OOM的主要原因之一。我们知道Android系统为每个应用程序分配的内存是有限的，而当一个应用中产生的内存泄漏比较多时，这就难免会导致应用所需要的内存超过系统分配的内存限额，这就造成了内存溢出从而导致应用Crash。

### **如何检查和分析内存泄漏？** ###

因为内存泄漏是在堆内存中，所以对我们来说并不是可见的。通常我们可以借助MAT、LeakCanary等工具来检测应用程序是否存在内存泄漏。  
1、MAT是一款强大的内存分析工具，功能繁多而复杂。  
2、LeakCanary则是由Square开源的一款轻量级的第三方内存泄漏检测工具，当检测到程序中产生内存泄漏时，它将以最直观的方式告诉我们哪里产生了内存泄漏和导致谁泄漏了而不能被回收。

### 常见的内存泄漏及解决方法 ###

1、单例造成的内存泄漏

由于单例的静态特性使得其生命周期和应用的生命周期一样长，如果一个对象已经不再需要使用了，而单例对象还持有该对象的引用，就会使得该对象不能被正常回收，从而导致了内存泄漏。  
示例：防止单例导致内存泄漏的实例

// 使用了单例模式
    public class AppManager {
        private static AppManager instance;
        private Context context;
        private AppManager(Context context) {
            this.context = context;
        }
        public static AppManager getInstance(Context context) {
            if (instance != null) {
                instance = new AppManager(context);
            }
            return instance;
        }
    }

这样不管传入什么Context最终将使用Application的Context，而单例的生命周期和应用的一样长，这样就防止了内存泄漏。？？？

### **2、非静态内部类创建静态实例造成的内存泄漏** ###

例如，有时候我们可能会在启动频繁的Activity中，为了避免重复创建相同的数据资源，可能会出现如下写法：

public class MainActivity extends AppCompatActivity {
    
        private static TestResource mResource = null;
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
            if(mResource == null){
                mResource = new TestResource();
            }
        }
        
        class TestResource {
        }
    }

这样在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据。虽然这样避免了资源的重复创建，但是这种写法却会造成内存泄漏。因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，从而导致Activity的内存资源不能被正常回收。  
**解决方法**：将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，就使用Application的Context。

### **3、Handler造成的内存泄漏** ###

示例：创建匿名内部类的静态对象

public class MainActivity extends AppCompatActivity {
    
        private final Handler handler = new Handler() {
            @Override
            public void handleMessage(Message msg) {
            }
        };
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
    
            new Thread(new Runnable() {
                @Override
                public void run() {
                    handler.sendEmptyMessage(0x123);
                }
            });
        }
    }

**1、从Android的角度**

当Android应用程序启动时，该应用程序的主线程会自动创建一个Looper对象和与之关联的MessageQueue。当主线程中实例化一个Handler对象后，它就会自动与主线程Looper的MessageQueue关联起来。所有发送到MessageQueue的Messag都会持有Handler的引用，所以Looper会据此回调Handle的handleMessage()方法来处理消息。只要MessageQueue中有未处理的Message，Looper就会不断的从中取出并交给Handler处理。另外，主线程的Looper对象会伴随该应用程序的整个生命周期。

**2、 Java角度**

在Java中，非静态内部类和匿名类内部类都会潜在持有它们所属的外部类的引用，但是静态内部类却不会。

对上述的示例进行分析，当MainActivity结束时，未处理的消息持有handler的引用，而handler又持有它所属的外部类也就是MainActivity的引用。这条引用关系会一直保持直到消息得到处理，这样阻止了MainActivity被垃圾回收器回收，从而造成了内存泄漏。  
**解决方法**：将Handler类独立出来或者使用静态内部类，这样便可以避免内存泄漏。

**4、线程造成的内存泄漏**

示例：AsyncTask和Runnable

public class MainActivity extends AppCompatActivity {
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
    
            new Thread(new MyRunnable()).start();
            new MyAsyncTask(this).execute();
        }
    
        class MyAsyncTask extends AsyncTask<Void, Void, Void> {
    
    
            public MyAsyncTask(Context context) {
            }
    
            @Override
            protected Void doInBackground(Void... params) {
                return null;
            }
    
            @Override
            protected void onPostExecute(Void aVoid) {
            }
        }
    
        class MyRunnable implements Runnable {
            @Override
            public void run() {
            }
        }
    }

AsyncTask和Runnable都使用了匿名内部类，那么它们将持有其所在Activity的隐式引用。如果任务在Activity销毁之前还未完成，那么将导致Activity的内存资源无法被回收，从而造成内存泄漏。  
**解决方法**：将AsyncTask和Runnable类独立出来或者使用静态内部类，这样便可以避免内存泄漏。

**5、资源未关闭造成的内存泄漏**

对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，从而造成内存泄漏。

①  比如在Activity中register了一个BraodcastReceiver，但在Activity结束后没有unregister该BraodcastReceiver。  
②  资源性对象比如Cursor，Stream、File文件等往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null，而不关闭它们，往往会造成内存泄漏。  
③  对于资源性对象在不使用的时候，应该调用它的close()函数将其关闭掉，然后再设置为null。在我们的程序退出时一定要确保我们的资源性对象已经关闭。  
④  Bitmap对象不在使用时调用recycle()释放内存。2.3以后的bitmap应该是不需要手动recycle了，内存已经在java层了。

**6、使用ListView时造成的内存泄漏**

初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的View对象，同时ListView会将这些View对象缓存起来。当向上滚动ListView时，原先位于最上面的Item的View对象会被回收，然后被用来构造新出现在下面的Item。这个构造过程就是由getView()方法完成的，getView()的第二个形参convertView就是被缓存起来的Item的View对象（初始化时缓存中没有View对象则convertView是null）。

构造Adapter时，没有使用缓存的convertView。  
**解决方法**：在构造Adapter时，使用缓存的convertView。

**7、集合容器中的内存泄露**

我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。  
**解决方法**：在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。

**8、WebView造成的泄露**

当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其长期占用的内存也不能被回收，从而造成内存泄露。  
**解决方法**：为WebView另外开启一个进程，通过AIDL与主线程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。

**如何避免内存泄漏？**

1、在涉及使用Context时，对于生命周期比Activity长的对象应该使用Application的Context。凡是使用Context优先考虑Application的Context，当然它并不是万能的，对于有些地方则必须使用Activity的Context。对于Application，Service，Activity三者的Context的应用场景如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDc4MzMxNQ_size_16_color_FFFFFF_t_70][]

其中，NO1表示Application和Service可以启动一个Activity，不过需要创建一个新的task任务队列。而对于Dialog而言，只有在Activity中才能创建。除此之外三者都可以使用。

2、对于需要在静态内部类中使用非静态外部成员变量（如：Context、View )，可以在静态内部类中使用弱引用来引用外部类的变量来避免内存泄漏。  
3、对于不再需要使用的对象，显示的将其赋值为null，比如使用完Bitmap后先调用recycle()，再赋为null。  
4、保持对对象生命周期的敏感，特别注意单例、静态对象、全局性集合等的生命周期。  
5、对于生命周期比Activity长的内部类对象，并且内部类中使用了外部类的成员变量，可以这样做避免内存泄漏：  
①  将内部类改为静态内部类  
②  静态内部类中使用弱引用来引用外部类的成员变量

### **4、OOM能不能用try catch捕获。** ###

OOM(OutOfMemeryError)属于Error，只有在一种情况下可以捕获OOM，只有在确认并OOM是由try语句中的对象声明导致的，那么在catch语句中，可以释放掉这些对象，解决OOM的问题，继续执行剩余语句。

### **5、OOM遇到过哪些情况，如何解决的。** ###

OOM类型：  
 - Java堆溢出(java.lang.OutOfMemoryError: Java heap space)：一般通过内存映像分析工具MAT(Eclipse Memory Analyzer)对dump出来的HPROF文件进行分析，确认是内存泄漏(Memory Leak)还是内存溢出(Memory Overflow)。  
   
   - 内存泄漏(Memory Leak)：分析GC Roots引用链，定位出内存泄漏的代码。  
   - 内存溢出(Memory Overflow)：从代码上检查某些对象的生命周期过长、持有状态时间过长。

- 虚拟机栈和本地方法栈溢出  
   
 - 方法区和运行时常量池溢出  
   
 - 本机直接内存溢出  
   
 常见的OOM场景：  
\- Adapter没使用缓存的convertView。  
\- Bitmap没有及时回收，调用recycle()函数并不能立即释放Bitmap，读取Bitmap到内存的时候没有做采样率的设置。  
\- 线程数超限，proc/pid/status中记录的线程数超过proc/sys/kernel/threads-max中规定的最大线程数，场景如随意创建线程，没有使用线程池来管理。  
\- 广播注册之后没有进行注销。  
\- WebView没有销毁，应该调用destroy()函数去销毁。  
\- Handler使用不当导致。

### **6、Bitmap使用的时候注意什么（Bitmap优化）。** ###

\*\*基础知识：\*\*  
\- Options.inPreferredConfig修改图片编码格式：  
   
  Bitmap.Config ALPHA\_8          每个像素占用1 bit (8位)内存    
  Bitmap.Config ARGB\_4444        每个像素占用2 bit (16位)内存         
  Bitmap.Config ARGB\_8888        每个像素占用4 bit (32位)内存         
  Bitmap.Config RGB\_565          每个像素占用2 bit (16位)内存

\- 获取Bitmap大小：

\*\*加载一张本地资源图片，那么它占用的内存 = width \* height \* nTargetDensity/inDensity \* nTargetDensity/inDensity \* 一个像素所占的内存。\*\*

以1024 \* 594的图片为例：  
       // 不做处理，默认缩放。  
        BitmapFactory.Options options = new BitmapFactory.Options();  
        Bitmap bmp01 = BitmapFactory.decodeResource(getResources(), R.mipmap.bmp, options);  
          
        int size01Allocation = bmp01.getAllocationByteCount();  
        int size01 = bmp01.getByteCount();

// 手动设置inDensity与inTargetDensity，影响缩放比例。  
        BitmapFactory.Options options\_setParams = new BitmapFactory.Options();  
        options\_setParams.inDensity = 320;  
        options\_setParams.inTargetDensity = 320;

Bitmap bmp02 = BitmapFactory.decodeResource(getResources(), R.mipmap.bmp, options\_setParams);

int size02Allocation = bmp02.getAllocationByteCount();  
        int size02 = bmp02.getByteCount();  
   
 xhdpi的文件夹下，inDensity为320，inTargetDensity为440，内存大小为4601344；而4601344 = 1024 \* 594 \* （440 / 320）\* （440 / 320）\* 4

手动设置inDensity与inTargetDensity，使其比例为1，内存大小为2433024；2433024 = 1024 \* 594 \* 1 \* 1 \* 4。

\*\*除了加载本地资源文件的解码方法会默认使用资源所处文件夹对应密度和手机系统密度进行缩放之外，别的解码方法默认都不会。此时Bitmap默认占用的内存 = width \* height \* 一个像素所占的内存。\*\*  
   
优化策略：\*\*  
 - 使用setImageBitmap、setImageResource、BitmapFactory.decodeResource这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存，而BitmapFactory.decodeStream方法则是通过JNI来创建Bitmap，更节约内存。  
\`\`\`  
InputStream is = getResources().openRawResource(R.drawable.pic);    
Bitmap bitmap = BitmapFactory.decodeStream(is);  
\`\`\`  
   
\- 对图片进行压缩显示，按需分配内内存。  
   
   - 对图片进行质量压缩。bitmap.compress  
   - 对图片进行尺寸缩放。Bitmap.Options.inSampleSize  
   - 使用三方库对图片进行压缩。libjpeg

\- 使用LruCache和DiskLruCache做内存和磁盘缓存。

\- Bitmap进行复用：Android 3.0之前Bitmap.recycle，3.0之后进行复用。

\- 使用WeakReference，保证资源能够被及时回收。

### **7、Bitmap recycler相关（Bitmap复用）。** ###

Google 官方教程 \[Managing Bitmap Memory\](https://developer.android.com/topic/performance/graphics/manage-memory)  
\[Glide Bitmap复用\](https://www.jianshu.com/p/d6cae68175f2)

Android2.2（API 8）一下的时候，当 GC 工作时，应用的线程会暂停工作，同步的 GC 会影响性能。而 Android2.3 之后，GC 变成了并发的，意味着 Bitmap 没有引用的时候其占有的内存会很快被回收。

在Android2.3.3（API10）之前，Bitmap 的像素数据存放在 Native 内存，而 Bitmap 对象本身则存放在 Dalvik Heap 中。Native 内存中的像素数据以不可预测的方式进行同步回收，有可能会导致内存升高甚至 OOM Crash。而在 Android3.0 之后，Bitmap 的像素数据也被放在了 Dalvik Heap 中。

Android2.3.3 及以下：推荐使用Bitmap\#recycle方法进行内存回收。

Android3.0 及以上：推荐使用Bitmap复用。

Bitmap复用：\*\*  
\- 被复用的 Bitmap 必须设置inMutable为true（通过 BitmapFactory.Options 设置。  
\- Android4.4(API 19)之前只有格式为jpg、png，同等宽高（要求苛刻），inSampleSize为1的Bitmap才可以复用。  
\- Android4.4(API 19)之前被复用的Bitmap的inPreferredConfig会覆盖待分配内存的Bitmap设置的inPreferredConfig。  
\- Android4.4(API 19)之前待加载Bitmap的Options.inSampleSize必须明确指定为1。  
\- Android4.4(API 19)之后被复用的Bitmap的内存必须大于需要申请内存的Bitmap的内存。

BitmapFactory.Options options = new BitmapFactory.Options();  
// 图片复用，这个属性必须设置；  
options.inMutable = true;  
// 手动设置缩放比例，使其取整数，方便计算、观察数据；  
options.inDensity = 320;  
options.inTargetDensity = 320;  
Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.resbitmap, options);  
// 对象内存地址；  
Log.i(TAG, "bitmap = " + bitmap);  
Log.i(TAG, "bitmap：ByteCount = " + bitmap.getByteCount() + ":::bitmap：AllocationByteCount = " + bitmap.getAllocationByteCount());

// 使用inBitmap属性，这个属性必须设置；  
options.inBitmap = bitmap;  
options.inDensity = 320;  
// 设置缩放宽高为原始宽高一半；  
options.inTargetDensity = 160;  
options.inMutable = true;  
Bitmap bitmapReuse = BitmapFactory.decodeResource(getResources(), R.drawable.resbitmap\_reuse, options);  
// 复用对象的内存地址；  
Log.i(TAG, "bitmapReuse = " + bitmapReuse);  
Log.i(TAG, "bitmap：ByteCount = " + bitmap.getByteCount() + ":::bitmap：AllocationByteCount = " + bitmap.getAllocationByteCount());  
Log.i(TAG, "bitmapReuse：ByteCount = " + bitmapReuse.getByteCount() + ":::bitmapReuse：AllocationByteCount = " + bitmapReuse.getAllocationByteCount());

输出：  
I/lz: bitmap = android.graphics.Bitmap@35ac9dd4  
I/lz: width:1024:::height:594  
I/lz: bitmap：ByteCount = 2433024:::bitmap：AllocationByteCount = 2433024  
I/lz: bitmapReuse = android.graphics.Bitmap@35ac9dd4 // 两个对象的内存地址一致  
I/lz: width:512:::height:297  
I/lz: bitmap：ByteCount = 608256:::bitmap：AllocationByteCount = 2433024  
I/lz: bitmapReuse：ByteCount = 608256:::bitmapReuse：AllocationByteCount = 2433024 // ByteCount比AllocationByteCount小

[Link 1]: https://baike.sogou.com/v8154921.htm?ch=ww.wap.chain.baike
[C]: https://baike.sogou.com/v10872657.htm?ch=ww.wap.chain.baike
[Link 2]: https://baike.sogou.com/v269184.htm?ch=ww.wap.chain.baike
[Link 3]: https://baike.sogou.com/v68803087.htm?ch=ww.wap.chain.baike
[Link 4]: https://baike.sogou.com/v57704855.htm?ch=ww.wap.chain.baike
[Link 5]: https://baike.sogou.com/v168341342.htm?ch=ww.wap.chain.baike
[Link 6]: https://baike.sogou.com/v70270116.htm?ch=ww.wap.chain.baike
[Link 7]: https://baike.sogou.com/v64527710.htm?ch=ww.wap.chain.baike
[Link 8]: https://baike.sogou.com/v1168027.htm?ch=ww.wap.chain.baike
[Link 9]: https://baike.sogou.com/v45439.htm?ch=ww.wap.chain.baike
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDc4MzMxNQ_size_16_color_FFFFFF_t_70]: /images/20220403/beddc11659c0440c985e956f0213426f.png