你的APP内存还在暴增吗？试着用Bitmap管理下内存~

news2025/1/22 16:05:40

作者：layz4android

相信伙伴们在日常的开发中，一定对图片加载有所涉猎，而且对于图片加载现有的第三方库也很多，例如Glide、coil等，使用这些三方库我们好像就没有啥担忧的，他们内部的内存管理和缓存策略做的很好，但是一旦在某些场景中无法使用图片加载库，或者项目中没有使用图片加载库而且重构难度大的情况下，对于Bitmap内存的管理就显得尤为重要了，一旦使用出现问题，那么OOM是常有的事。

在Android 8.0之后，Bitmap的内存分配从Java堆转移到了Native堆中，所以我们可以通过Android profiler性能检测工具查看内存使用情况。

未经过内存管理，列表滑动前内存状态：

列表滑动时，内存状态：

通过上面两张图我们可以发现，Java堆区的内存没有变化，但是Native的内存发生了剧烈的抖动，而且伴随着频繁的GC，如果有了解JVM的伙伴，这种情况下必定伴随着应用的卡顿，所以对于Bitmap加载，就要避免频繁地创建和回收，因此本章将会着重介绍Bitmap的内存管理。

1 Bitmap“整容”

首先我们需要明确一点，既然是内存管理，难道只是对图片压缩保证不会OOM吗？其实不是的，内存管理一定是多面多点的，压缩是一方面，为什么起标题为“整容”，是因为最终加载到内存的Bitmap一定不是单纯地通过decodeFile就能完成的。

1.1 Bitmap内存复用

上图内存状态对应的列表代码如下：

override fun onBindViewHolder(holder: ViewHolder, position: Int) {
    bindBitmap(holder)
}

///sdcard/img.png
private fun bindBitmap(holder: ViewHolder) {
    val bitmap = BitmapFactory.decodeFile("/sdcard/img.png")
    holder.binding.ivImg.setImageBitmap(bitmap)
}

如果熟悉RecyclerView的缓存机制应该了解，当RecyclerView的Item移出页面之后，会放在缓存池当中；当下面的item显示的时候，首先会从缓存池中取出缓存，直接调用onBindViewHolder方法，所以依然会重新创建一个Bitmap，因此针对列表的缓存特性可以选择Bitmap内存复用机制。

看上面这张图，因为顶部的Item在新建的时候，已经在native堆区中分配了一块内存，所以当这块区域被移出屏幕的时候，下面显示的Item不需要再次分配内存空间，而是复用移出屏幕的Item的内存区域，从而避免了频繁地创建Bitmap导致内存抖动。

override fun onBindViewHolder(holder: ViewHolder, position: Int) {
    bindBitmap(holder)
}

///sdcard/img.png
private fun bindBitmap(holder: ViewHolder) {

    if (option == null) {
        option = BitmapFactory.Options()
        //开启内存复用
        option?.inMutable = true
    }
    val bitmap = BitmapFactory.decodeFile("/sdcard/img.png", option)
    option?.inBitmap = bitmap
    holder.binding.ivImg.setImageBitmap(bitmap)
}
复制代码

那么如何实现内存复用，在BitmapFactory中提供了Options选项，当设置inMutable属性为true之后，就代表开启了内存复用，此时如果新建了一个Bitmap，并将其添加到inBitmap中，那么后续所有Bitmap的创建，只要比这块内存小，那么都会放在这块内存中，避免重复创建。

滑动前：

滑动时：

通过上图我们发现，即便是在滑动的时候，Native内存都没有明显的变化。

1.2 Bitmap压缩

像1.1中这种加载形式，其实都是会直接将Bitmap加载到native内存中，例如我们设置的ImageView只有100*100，那么图片的大小为1000 * 800，其实是不需要将这么大体量的图片直接加载到内存中，那么有没有一种方式，在图片加载到内存之前就能拿到这些基础信息呢？

当然有了，这里还是要搬出BitmapFactory.Option这个类，其中inJustDecodeBounds这个属性的含义，从字面意思上就可以看出，只解码边界，也就是意味着在加载内存之前，是会拿到Bitmap的宽高的，注意需要成对出现，开启后也需要关闭。

private fun bindBitmap(holder: ViewHolder) {

    if (option == null) {
        option = BitmapFactory.Options()
        //开启内存复用
        option?.inMutable = true
    }

    //在加载到内存之前，获取图片的基础信息
    option?.inJustDecodeBounds = true
    BitmapFactory.decodeFile("/sdcard/img.png",option)
    //获取宽高
    val outWidth = option?.outWidth ?: 100
    val outHeight = option?.outHeight ?: 100
    //计算缩放系数
    option?.inSampleSize = calculateSampleSize(outWidth, outHeight, 100, 100)
    option?.inJustDecodeBounds = false
    val bitmap = BitmapFactory.decodeFile("/sdcard/img.png", option)
    option?.inBitmap = bitmap
    holder.binding.ivImg.setImageBitmap(bitmap)
}

private fun calculateSampleSize(
    outWidth: Int,
    outHeight: Int,
    maxWidth: Int,
    maxHeight: Int
): Int? {
    var sampleSize = 1
    Log.e("TAG","outWidth $outWidth outHeight $outHeight")
    if (outWidth > maxWidth && outHeight > maxHeight) {
        sampleSize = 2
        while (outWidth / sampleSize > maxWidth && outHeight / sampleSize > maxHeight) {
            sampleSize *= 2
        }
    }
    return sampleSize
}

然后会需要计算一个压缩的系数，给BitmapFactory.Option类的inSampleSize赋值，这样Bitmap就完成了缩放，我们再次看运行时的内存状态。

Native内存几乎下降了一半。

2 手写图片缓存框架

在第一节中，我们对于Bitmap自身做了一些处理，例如压缩、内存复用。虽然做了这些处理，但是不足以作为一个优秀的框架对外输出。

为什么呢？像1.2节中，我们虽然做了内存复用以及压缩，但是每次加载图片都需要重新调用decodeFile拿到一个bitmap对象，其实这都是同一张图片，即便是在项目中，肯定也存在相同的图片，那么我们肯定不能重复加载，因此对于加载过的图片我们想缓存起来，等到下次加载的时候，直接拿缓存中的Bitmap，其实也是加速了响应时间。

2.1 内存缓存

首先一个成熟的图片加载框架，三级缓存是必须的，像Glide、coil的缓存策略，如果能把这篇文章搞懂了，那么就全通了。

在Android中，提供了LruCache这个类，也是内存缓存的首选，如果熟悉LruCache的伙伴，应该明白其中的原理。它其实是一个双向链表，以最近少用原则，当缓存中的数据长时间不用，而且有新的成员加入进来之后，就会移除尾部的成员，那么我们首先搞定内存缓存。

class BitmapImageCache {

    private var context: Context? = null

    //默认关闭
    private var isEnableMemoryCache: Boolean = false
    private var isEnableDiskCache: Boolean = false

    constructor(builder: Builder) {
        this.context = context
        this.isEnableMemoryCache = builder.isEnableMemoryCache
        this.isEnableDiskCache = builder.isEnableDiskCache
    }

    class Builder {

        var context: Context? = null

        //是否开启内存缓存
        var isEnableMemoryCache: Boolean = false

        //是否开启磁盘缓存
        var isEnableDiskCache: Boolean = false

        fun with(context: Context): Builder {
            this.context = context
            return this
        }

        fun enableMemoryCache(isEnable: Boolean): Builder {
            this.isEnableMemoryCache = isEnable
            return this
        }

        fun enableDiskCache(isEnable: Boolean): Builder {
            this.isEnableDiskCache = isEnable
            return this
        }

        fun build(): BitmapImageCache {
            return BitmapImageCache(this)
        }
    }
}

基础框架采用建造者设计模式，基本都是一些开关，控制是否开启内存缓存，或者磁盘缓存，接下来进行一些初始化操作。

首先对于内存缓存，我们使用LruCache，其中有两个核心的方法：sizeOf和entryRemoved，方法的作用已经在注释里了。

class BitmapLruCache(
    val size: Int
) : LruCache<String, Bitmap>(size) {

    /**
     * 告诉系统Bitmap内存的大小
     */
    override fun sizeOf(key: String, value: Bitmap): Int {
        return value.allocationByteCount
    }

    /**
     * 当Lru中的成员被移除之后，会走到这个回调
     * @param oldValue 被移除的Bitmap
     */
    override fun entryRemoved(evicted: Boolean, key: String, oldValue: Bitmap, newValue: Bitmap?) {
        super.entryRemoved(evicted, key, oldValue, newValue)

    }
}

当LruCache中元素被移除之后，我们想是不是就需要回收了，那这样的话其实就错了。记不记得我们前面做的内存复用策略，如果当前Bitmap内存是可以被复用的，直接回收掉，那内存复用就没有意义了，所以针对可复用的Bitmap，可以放到一个复用池中，保证其在内存中。

/**
 * 当Lru中的成员被移除之后，会走到这个回调
 * @param oldValue 被移除的Bitmap
 */
override fun entryRemoved(evicted: Boolean, key: String, oldValue: Bitmap, newValue: Bitmap?) {

    if (oldValue.isMutable) {
        //放入复用池
        reusePool?.add(WeakReference(oldValue))
    } else {
        //回收即可
        oldValue.recycle()
    }
}

所以这里加了一个判断，当这个Bitmap是支持内存复用的话，就加到复用池中，保证其他Item在复用内存的时候不至于找不到内存地址，前提是还没有被回收；那么这里就有一个问题，当复用池中的对象（弱引用）被释放之后，Bitmap如何回收呢？与弱引用配套的有一个引用队列，当弱引用被GC回收之后，会被加到引用队列中。

class BitmapLruCache(
    val size: Int,
    val reusePool: MutableSet<WeakReference<Bitmap>>?,
    val referenceQueue: ReferenceQueue<Bitmap>?
) : LruCache<String, Bitmap>(size) {

    /**
     * 告诉系统Bitmap内存的大小
     */
    override fun sizeOf(key: String, value: Bitmap): Int {
        return value.allocationByteCount
    }

    /**
     * 当Lru中的成员被移除之后，会走到这个回调
     * @param oldValue 被移除的Bitmap
     */
    override fun entryRemoved(evicted: Boolean, key: String, oldValue: Bitmap, newValue: Bitmap?) {

        if (oldValue.isMutable) {
            //放入复用池
            reusePool?.add(WeakReference(oldValue, referenceQueue))
        } else {
            //回收即可
            oldValue.recycle()
        }
    }
}

这里需要公开一个方法，开启一个线程一直检测引用队列中是否有复用池回收的对象，如果拿到了那么就主动销毁即可。

/**
 * 开启弱引用回收检测，目的为了回收Bitmap
 */
fun startWeakReferenceCheck() {
    //开启一个线程
    Thread {
        try {
            while (!shotDown) {
                val reference = referenceQueue?.remove()
                val bitmap = reference?.get()
                if (bitmap != null && !bitmap.isRecycled) {
                    bitmap.recycle()
                }
            }
        } catch (e: Exception) {

        }

    }.start()
}

另外再加几个方法，主要就是往缓存中加数据。

fun putCache(key: String, bitmap: Bitmap) {
    lruCache?.put(key, bitmap)
}

fun getCache(key: String): Bitmap? {
    return lruCache?.get(key)
}

fun clearCache() {
    lruCache?.evictAll()
}

初始化的操作，我们把它放在Application中进行初始化操作

class MyApp : Application() {

    override fun onCreate() {
        super.onCreate()
        bitmapImageCache = BitmapImageCache.Builder()
            .enableMemoryCache(true)
            .with(this)
            .build()
        //开启内存检测
        bitmapImageCache?.startWeakReferenceCheck()
    }

    companion object {
        @SuppressLint("StaticFieldLeak")
        @JvmStatic
        var bitmapImageCache: BitmapImageCache? = null
    }
}

从实际的效果中，我们可以看到：

2023-02-18 17:54:10.154 32517-32517/com.lay.nowinandroid E/TAG: outWidth 800 outHeight 560
2023-02-18 17:54:10.154 32517-32517/com.lay.nowinandroid E/TAG: 没有从缓存中获取
2023-02-18 17:54:10.169 32517-32517/com.lay.nowinandroid E/TAG: 从缓存中获取 Bitmap
2023-02-18 17:54:10.187 32517-32517/com.lay.nowinandroid E/TAG: 从缓存中获取 Bitmap
2023-02-18 17:54:16.740 32517-32517/com.lay.nowinandroid E/TAG: 从缓存中获取 Bitmap
2023-02-18 17:54:16.756 32517-32517/com.lay.nowinandroid E/TAG: 从缓存中获取 Bitmap
2023-02-18 17:54:16.926 32517-32517/com.lay.nowinandroid E/TAG: 从缓存中获取 Bitmap
2023-02-18 17:54:17.102 32517-32517/com.lay.nowinandroid E/TAG: 从缓存中获取 Bitmap

其实加了内存缓存之后，跟inBitmap的价值基本就是等价的了，也是为了避免频繁地申请内存，可以认为是一个双保险，加上对图片压缩以及LruCache的缓存策略，真正内存打满的场景还是比较少的。

2.2 复用池的处理

在前面我们提到了，为了保证可复用的Bitmap不被回收，从而加到了一个复用池中，那么当从缓存中没有取到数据的时候，就会从复用池中取，相当于是在内存缓存中加了一个二级缓存。

针对上述图中的流程，可以对复用池进行处理。

/**
 * 从复用池中取数据
 */
fun getBitmapFromReusePool(width: Int, height: Int, sampleSize: Int): Bitmap? {

    var bitmap: Bitmap? = null
    //遍历缓存池
    val iterator = reusePool?.iterator() ?: return null
    while (iterator.hasNext()) {
        val checkedBitmap = iterator.next().get()
        if (checkBitmapIsAvailable(width, height, sampleSize, bitmap)) {
            bitmap = checkedBitmap
            iterator.remove()
            //放在
            break
        }
    }

    return bitmap

}

/**
 * 检查当前Bitmap内存是否可复用
 */
private fun checkBitmapIsAvailable(
    width: Int,
    height: Int,
    sampleSize: Int,
    bitmap: Bitmap?
): Boolean {
    if (bitmap == null) {
        return false
    }
    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.KITKAT) {
        return width < bitmap.width && height < bitmap.height && sampleSize == 1
    }
    var realWidth = 0
    var realHeight = 0
    //支持缩放
    if (sampleSize > 1) {
        realWidth = width / sampleSize
        realHeight = height / sampleSize
    }
    val allocationSize = realHeight * realWidth * getBitmapPixel(bitmap.config)
    return allocationSize <= bitmap.allocationByteCount
}

/**
 * 获取Bitmap的像素点位数
 */
private fun getBitmapPixel(config: Bitmap.Config): Int {
    return if (config == Bitmap.Config.ARGB_8888) {
        4
    } else {
        2
    }
}

这里需要注意一点就是，如果想要复用内存，那么申请的内存一定要比复用的这块内存小，否则就不能匹配上。

所以最终的一个流程就是（这里没考虑磁盘缓存，如果用过Glide就会知道，磁盘缓存会有问题），首先从内存中取，如果取到了，那么就直接渲染展示；如果没有取到，那么就从复用池中取出一块内存，然后让新创建的Bitmap复用这块内存。

//从内存中取
var bitmap = BitmapImageCache.getCache(position.toString())
if (bitmap == null) {
    //从复用池池中取
    val reuse = BitmapImageCache.getBitmapFromReusePool(100, 100, 1)
    Log.e("TAG", "从网络加载了数据")
    bitmap = ImageUtils.load(imagePath, reuse)
    //放入内存缓存
    BitmapImageCache.putCache(position.toString(), bitmap)
} else {
    Log.e("TAG", "从内存加载了数据")
}

最终的一个呈现就是：

2023-02-18 21:31:57.805 29198-29198/com.lay.nowinandroid E/TAG: 从网络加载了数据
2023-02-18 21:31:57.819 29198-29198/com.lay.nowinandroid E/TAG: outWidth 800 outHeight 560
2023-02-18 21:31:57.830 29198-29198/com.lay.nowinandroid E/TAG: 加入复用池 android.graphics.Bitmap@6c19c7b
2023-02-18 21:31:57.830 29198-29198/com.lay.nowinandroid E/TAG: setImageBitmap android.graphics.Bitmap@473ed07
2023-02-18 21:31:57.849 29198-29198/com.lay.nowinandroid E/TAG: 从网络加载了数据
2023-02-18 21:31:57.857 29198-29198/com.lay.nowinandroid E/TAG: outWidth 788 outHeight 514
2023-02-18 21:31:57.871 29198-29198/com.lay.nowinandroid E/TAG: 加入复用池 android.graphics.Bitmap@2a7844
2023-02-18 21:31:57.872 29198-29198/com.lay.nowinandroid E/TAG: setImageBitmap android.graphics.Bitmap@4d852a3
2023-02-18 21:31:57.917 29198-29198/com.lay.nowinandroid E/TAG: 从网络加载了数据
2023-02-18 21:31:57.943 29198-29198/com.lay.nowinandroid E/TAG: outWidth 34 outHeight 8
2023-02-18 21:31:57.958 29198-29198/com.lay.nowinandroid E/TAG: setImageBitmap android.graphics.Bitmap@a3d491e
2023-02-18 21:31:58.651 29198-29198/com.lay.nowinandroid E/TAG: 从内存加载了数据
2023-02-18 21:31:58.651 29198-29198/com.lay.nowinandroid E/TAG: setImageBitmap android.graphics.Bitmap@62fcf27
2023-02-18 21:31:58.706 29198-29198/com.lay.nowinandroid E/TAG: 从内存加载了数据
2023-02-18 21:31:58.707 29198-29198/com.lay.nowinandroid E/TAG: setImageBitmap android.graphics.Bitmap@e2f8a1a
2023-02-18 21:31:58.766 29198-29198/com.lay.nowinandroid E/TAG: 从内存加载了数据

其实真正要保证我们的内存稳定，就是尽量避免重复创建对象，尤其是大图片，在加载的时候尤其需要注意，在项目中出现内存始终不降的主要原因也是对Bitmap的内存管理不当，所以掌握了上面的内容，就可以针对这些问题进行优化。总之万变不离其宗，内存是App的生命线，如果在面试的时候问你如何设计一个图片加载框架，内存管理是核心，当出现文章一开头那样的内存曲线的时候，就需要重点关注你的Bitmap是不是又“乱飙”了。

附录 - ImageUtils

object ImageUtils {

    private val MAX_WIDTH = 100
    private val MAX_HEIGHT = 100

    /**
     * 加载本地图片
     * @param reuse 可以复用的Bitmap内存
     */
    fun load(imagePath: String, reuse: Bitmap?): Bitmap {

        val option = BitmapFactory.Options()
        option.inMutable = true
        option.inJustDecodeBounds = true

        BitmapFactory.decodeFile(imagePath, option)
        val outHeight = option.outHeight
        val outWidth = option.outWidth
        option.inSampleSize = calculateSampleSize(outWidth, outHeight, MAX_WIDTH, MAX_HEIGHT)

        option.inJustDecodeBounds = false
        option.inBitmap = reuse
        //新创建的Bitmap复用这块内存
        return BitmapFactory.decodeFile(imagePath, option)
    }

    private fun calculateSampleSize(
        outWidth: Int,
        outHeight: Int,
        maxWidth: Int,
        maxHeight: Int
    ): Int {
        var sampleSize = 1
        Log.e("TAG", "outWidth $outWidth outHeight $outHeight")
        if (outWidth > maxWidth && outHeight > maxHeight) {
            sampleSize = 2
            while (outWidth / sampleSize > maxWidth && outHeight / sampleSize > maxHeight) {
                sampleSize *= 2
            }
        }
        return sampleSize
    }
}

根据性能问题出现的情况不同，我们需要采用不同的性能优化手段，而目前还是有些人群对于性能优化中间的一些优化手段掌握的不是很熟练，因此针对性能优化中间的所有不同类型的优化手段进行了归类整理，有启动优化、内存优化、网络优化、卡顿优化、存储优化……等，整合成名为《Android 性能优化核心知识点手册》，大家可以参考下：

《APP 性能调优进阶手册》：https://qr18.cn/FVlo89

启动优化

内存优化

UI优化

网络优化

Bitmap优化与图片压缩优化

多线程并发优化与数据传输效率优化

体积包优化

《Android 性能调优核心笔记汇总》：https://qr18.cn/FVlo89

《Android 性能监控框架》：https://qr18.cn/FVlo89

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/414127.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

Java垃圾回收机制GC完全指南，让你彻底理解JVM运行原理

Java垃圾回收机制GC完全指南，让你彻底理解JVM运行原理

1、GC过程 1&#xff09;先判断对象是否存活(是否是垃圾) 可以通过引用计数算法和可达性分析算法来判断&#xff0c;由于引用计数算法无法解决循环引用的问题&#xff0c;所以目前使用的都是可达性分析算法 2&#xff09;再遍历并回收对象(回收垃圾) 可以通过垃圾收集器&…
阅读更多...
使用Schrödinger Python API系列教程 -- 介绍 (一)

使用Schrödinger Python API系列教程 -- 介绍 (一)

使用Schrdinger Python API系列教程 – 介绍 (一) 本文档可从Schrdinger网站www.schrodinger.com/pythonapi访问。 从Python文档字符串生成的完整API文档可以在这里访问 介绍 在最高级别上&#xff0c;Schrdinger Python API提供了一个基本的分子结构类&#xff0c;并允许与…
阅读更多...
redis总结之-jedis

redis总结之-jedis

redis总结之-jedis4. Jedis4.1 Jedis简介4.1.1 编程语言与redis4.1.2 准备工作4.1.3 代码实现4.2 Jedis简易工具类开发4.2.1 基于连接池获取连接4.2.2 封装连接参数4.2.3 加载配置信息4.2.4 获取连接4.3 可视化客户端总结计划 1. Redis 入 门&#xff08;了解&#xff09;&…
阅读更多...
LNMP网站框架搭建（编译安装的方式）

LNMP网站框架搭建（编译安装的方式）

1. Nginx的工作原理 php-fpm.conf 是控制php-fpm守护进程的 php.ini是php解析器 工作进程&#xff1a; 1.客户端通过域名进行请求访问时&#xff0c;会找Nginx对应的虚拟主机 2. Nginx对该请求进行判断&#xff0c;如果是静态请求,Nginx会自行处理&#xff0c;并将处理结果…
阅读更多...
因果推断14--DRNet论文和代码学习

因果推断14--DRNet论文和代码学习

目录 论文介绍 代码实现 DRNet ReadMe 因果森林 论文介绍 因果推断3--DRNet&#xff08;个人笔记&#xff09;_万三豹的博客-CSDN博客 摘要&#xff1a;估计个体在不同程度的治疗暴露下的潜在反应&#xff0c;对于医疗保健、经济学和公共政策等几个重要领域具有很高的实…
阅读更多...
ERP系统有什么用？主要是这三方面

ERP系统有什么用？主要是这三方面

ERP 是Enterprise Resource Planning 的缩写&#xff0c;即企业资源计划系统,是建立在信息技术基础上,以系统化的管理思想,为企业决策层及员工提供决策运行手段的管理平台。它实现了企业内部资源和企业相关的外部资源的整合。通过软件把企业的人、财、物、产、供、销及相应的物…
阅读更多...
socket 到底是个啥

socket 到底是个啥

哈喽大家好&#xff0c;我是咸鱼 我相信大家在面试过程中或多或少都会被问到这样一个问题&#xff1a;你能解释一下什么是 socket 吗 我记得我当初的回答很是浅显&#xff1a;socket 也叫套接字&#xff0c;用来负责不同主机程序之间的网络通信连接&#xff0c;socket 的表现…
阅读更多...
整柜海运到美国的规格和收费标准是什么

整柜海运到美国的规格和收费标准是什么

整柜海运是指将所有货物安装在一个整箱内&#xff0c;由发货人和收货人共同操作&#xff0c;而目的港的收货人一般只有一个&#xff0c;方便操作。整柜海运到美国的主要流程有以下几个步骤&#xff1a;订舱、装柜、报关、海运、清关、提柜和送货。实际上&#xff0c;国际物流出…
阅读更多...
IDEA 2023.1 最新变化

IDEA 2023.1 最新变化

IntelliJ IDEA 2023.1 最新变化 在 IntelliJ IDEA 2023.1 中&#xff0c;我们根据用户的宝贵反馈对新 UI 做出了大量改进。 我们还实现了性能增强&#xff0c;从而更快导入 Maven&#xff0c;以及在打开项目时更早提供 IDE 功能。 新版本通过后台提交检查提供了简化的提交流程…
阅读更多...
写博客8年与人生第一个502万

写博客8年与人生第一个502万

题记&#xff1a;我们并非生来强大&#xff0c;但依然可以不负青春。 原本想好好写一下如何制定一个目标并通过一点一滴的努力去实现&#xff0c;这三年反思发现其实写自己的经历并不重要。 很多人都听过一句话&#xff1a;榜样的力量是无穷的。 更现实和实际的情况是&#x…
阅读更多...
【LeetCode】每日一题：移除元素

【LeetCode】每日一题：移除元素

目录 题目&#xff1a; 思想1&#xff1a;暴力解法 思想2&#xff1a;创建一个temp数组 思想3&#xff1a;双指针 &#x1f47b;内容专栏&#xff1a;《LeetCode刷题专栏》 &#x1f428;本文概括&#xff1a;27.移除元素 &#x1f43c;本文作者&#xff1a;花 碟 &#x1…
阅读更多...
电商评论数据爬取--R语言

电商评论数据爬取--R语言

1.网络爬虫 1.1 什么是网络爬虫 网络爬虫&#xff08;web crawler&#xff09;&#xff0c;也被称为网络蜘蛛&#xff08;web spider&#xff09;&#xff0c;是在万维网浏览网页并按照一定规则提取信息的脚本或者程序。 浏览网页时&#xff0c;一般流程如下&#xff1a; 利…
阅读更多...
C++语法（17）---- 二叉搜索树

C++语法（17）---- 二叉搜索树

1.概念 1.父节点的左子树全小于本身 2.父节点的右子树全大于本身 3.左右子树也是二叉搜索树 时间复杂度&#xff1a;O(N)&#xff0c;有可能只有左数&#xff0c;这样就遍历了所有&#xff0c;所有复杂度为N 平衡二叉树的时间复杂度才是&#xff1a;O(logN) 2.模拟 1.数据元素…
阅读更多...
Postman抓包教程

Postman抓包教程

目录 什么是抓包&#xff1f; 如何使用 Postman 进行抓包 查看历史抓包数据 使用抓包数据进行接口测试和开发 抓包技巧和注意事项 什么是抓包&#xff1f; 在计算机网络中&#xff0c;抓包是指捕获网络流量的过程。抓包工具可以截获进出计算机网络的数据流&#xff0c;并将…
阅读更多...
反向传播推导+numpy实现

反向传播推导+numpy实现

很久没有看深度学习了&#xff0c;忘了好多东西。本来想着推导一下&#xff0c;后来发现自己不会了。 再看看以前写的代码&#xff0c;又避开了最终的东西&#xff0c;于是决定重新推导一下。 数据的说明 首先&#xff0c;我们要做一个回归的任务&#xff0c;我们使用numpy随…
阅读更多...
5.Java循环控制语句

5.Java循环控制语句

Java循环控制语句 循环是Java中应用最为广泛的一个知识点&#xff0c;所以也是很需要掌握的。所谓循环&#xff0c;即通过判断条件&#xff0c;重复执行一段代码&#xff0c;根据条件的变化&#xff0c;来确定代码是否执行&#xff0c;执行次数。 一、循环结构 1、while循环…
阅读更多...
Java IO常用操作详解（代码示例）

Java IO常用操作详解（代码示例）

概览 Java I/O操作指的是数据的输入/输出操作。 Java的I/O操作类在java.io包中&#xff0c;主要分以下几种&#xff1a; 基于字节操作的I/O接口&#xff1a; InputStream和OutputStream基于字符操作的I/O接口&#xff1a; Writer和Reader基于磁盘操作的I/O接口&#xff1a; …
阅读更多...
5个令人惊艳的AI项目，开源了。。

5个令人惊艳的AI项目，开源了。。

大家好&#xff0c;我是 Jack。 今天清明&#xff0c;小伙伴们都去哪里玩了&#xff1f; 上个月我已经出去浪过了&#xff0c;清明就老实在家歇着了。 翻看了一些最近热点的开源项目&#xff0c;发现还是 AIGC 的天下。 今天&#xff0c;我将继续着重挑选几个近期的优质开源…
阅读更多...
2023第十四届蓝桥杯C++B组菜鸡的落幕

2023第十四届蓝桥杯C++B组菜鸡的落幕

时隔几天&#xff0c;终于还是忍不住来复盘一下蓝桥杯了&#xff0c;还记得去年参加做下填空&#xff0c;再做对个把编程&#xff0c;后面不会的大题打打表混混分&#xff0c;最后就能混个省奖&#xff0c; 这回估计凉透了,填空没对似乎&#xff0c;编程也没对几个&#xff0c;…
阅读更多...
Kettle8.2.0连接Hive3.1.2(踩坑，亲测有效)

Kettle8.2.0连接Hive3.1.2(踩坑，亲测有效)

这是目前遇到的最简单但最头疼的安装&#xff0c;因为是在公司之前用过的服务器上进行安装测试&#xff0c;加上又使用比较新的版本&#xff0c;结果踩了不少坑。Kettle连接Hive这个坑&#xff0c;从2023年4月11日下午开始&#xff0c;一致到2023年4月12日中午才弄好&#xff0…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023