2024年最全浅聊Android性能优化~_android应用在低性能设备的优化，2024年最新2024最新百度、头条等公司Android社招面试题目-CSDN博客

本文链接：https://blog.csdn.net/2401_84563405/article/details/138988802

总结

首先是感觉自己的基础还是不够吧，大厂好像都喜欢问这些底层原理。

另外一部分原因在于资料也还没有看完，一面时凭借那份资料考前突击恶补个几天居然也能轻松应对（在这里还是要感谢那份资料，真的牛），于是自我感觉良好，资料就没有怎么深究下去了。

之前的准备只涉及了Java、Android、计网、数据结构与算法这些方面，面对面试官对其他基础课程的考察显得捉襟见肘。

下一步还是要查漏补缺，进行针对性复习。

最后的最后，那套资料这次一定要全部看完，是真的太全面了，各个知识点都涵盖了，几乎我面试遇到的所有问题的知识点这里面都有！希望大家不要犯和我一样的错误呀！！！一定要看完！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

现在来观察一下整体的处理流程：

业务层使用相机捕获数据帧，并将数据帧传递给Java接口层
Java接口层将数据帧，通过JNI调用，把数据传递到c++层
JNI接口层将数据封装后传递给c++接口层
最后，c++接口层将数据封装后传递给底层SDK。
处理完成之后则反过来走完上述流程

如下图：

大概了解到这个程度就可以了。接下来详细展开我所做的几个性能优化。

优化一

由于整个框架主要是对帧数据进行处理，因此我们需要关注帧数据的处理流程。我们从相机采集开始来分析：

相机采集数据，并将帧数据存放在缓冲区中，这是最原始的数据
我们不能直接使用缓冲区中的数据，因为缓冲区是复用的，因此需要拷贝出来。这里发生一次数据拷贝，以及一帧数据内存的分配。
业务方将数据封装到我们的java接口数据结构，并传递到我们的框架java接口层。伪代码如下面的代码：

// 相机数据帧回调
void onCameraFrameArrive(byte[] data,int width,int hight) {
    // 创建框架数据结构，Frame内部拷贝一次相机帧数据
    Frame frame = new Frame(data,width,hight);
    // 调用接口传递数据
    sendFrame(frame);
}

java接口通过jni，将数据传递给c++层。JNI层需要对java数据进行一次拷贝，c++不能直接持有并处理java内存数据。c++持有java内存会让内存管理变得复杂，且无法直接对java内存进行数据处理。JNI层再将数据封装后，传递给c++接口层。伪代码如下

// java代码
void sendFrame(Frame frame){
    sendFrameToNative(frame);
}

private native void sendFrameToNative(Object frame);

// c++代码
void copyByteArray(jbyteArray value) {
    jsize arraySize = jniEnv->GetArrayLength(value);
    // 创建c++数组，并拷贝一份新的数据
    auto* array = new int8_t[size];
    jniEnv->GetByteArrayRegion(value, 0, arraySize, array)；
}

好了，流程上先了解到这里。流程中一共发生了两次内存的分配与拷贝：

相机缓存不能直接使用，java业务层发生了一次拷贝；
c++不能直接使用java内存，发生了一次从java内存到c++内存的拷贝

这里的优化思路是：我们可以让JNI直接从相机缓存中进行拷贝，而没有必要拷贝一份中间数据，这样可以减少一次内存拷贝与内存分配。我们发生拷贝的地方在于Frame类的构造函数中，优化伪代码如下：

class Frame {
    private byte[] mData;
    
    // 优化前：
    public Frame(byte[] data,int width,int height) {
        mData = new byte[data.length];
        ...
    }
    
    // 优化后
    public Frame(byte[] data,int width,int height) {
        mData = data;
        ...
    }
}

通过持有内存的引用，来代替拷贝内存。那么可能有读者有疑问：那我们是不是以后都通过持有引用的方式就可以了？并不是的，还是得根据业务的内容来决定。我们这里直接持有了相机缓存的引用，那么我们必须将数据处理操作设置为同步操作，并在处理结束后解除引用，否则会造成数据错误。

在本流程中，Frame属于框架层接口。对于框架的设计，我们可以将业务层传递的byte数组，做一次拷贝，这是最安全的。不管上层传递的byte数组是否复用、是否释放等，都不会造成错误，但同时会带来一定的性能损耗。而设计为直接持有上层byte数组，意味着业务方必须了解接口参数的意义，懂得byte数组参数是被框架直接持有，如有必要，需要在外部做数据拷贝。这降低了一定的接口易用性，但也带来了更好地性能表现。另一种折中的解决方案，是创建两个不同的接口：拷贝与不拷贝，让用户决定使用哪个接口，但这也会为接口带来更高的复杂性。

最后我们来总结一下：

跟踪核心数据的处理流程，例子中是视频图像帧，记录数据发生拷贝、内存分配、运算等地方，重新思考是否有更好的解决方案，来减少计算和内存成本。
如果发生在接口层的优化，需要考虑优化的成本，是否符合场景需求。在易用性、复杂性、高性能等因素中找到平衡点。

接下来我们看第二个优化点。

优化二

android studio有一个非常好用的性能分析工具：android profile，他可以帮助我们分析运行中的cpu占用情况，以及内存的分配情况。从这些数据中我们可以去分析，我们的程序是否存在问题，是否有优化的空间。

继续案例一中的场景，在开发中，利用这个工具完成了许多性能优化，或者说是bug的排查。这里主要讲两个：内存抖动和内存泄露。具体工具的使用方式可以移步官方文档 Android Profiler ，这里我主要介绍使用这个工具解决问题的思路。

首先第一个：内存抖动。android profile可以在运行时，查看内存的占用情况，在开发过程中我使用工具查看了一下运行时内存情况，类似下图：（图源网络）

ps：下面相关的图像我均采用网络图片代替，嗯，，因为我懒得去重现一次场景再记录图像（手动狗头）

内存出现频繁增长与垃圾回收，图像呈现锯齿状。内存的频繁申请与释放，会损耗大量的性能，最终导致的结果就是我们的应用卡顿。android profile具有的另一个功能是记录函数的内存申请大小，如onCreate函数申请了多少内存，剩余多少内存等。通过这个功能，我查询了一下其在运行时内存分配所在的函数以及对象情况，如下：（图源网络）

工具详细记录了所创建的对象，如上面两个图：byte数组占大多数内存分配；createSubDecor函数占大多数的内存分配。那么我们拿到这些信息之后，就可以去到对应的方法进行排查。

在我的项目，我的原因主要是，在java层每帧都拷贝一次数据，导致不断开辟内存，但是却使用一次就丢弃。场景一的优化之后，减少了这次拷贝即解决了这个问题。

第二，内存泄露。检测内存泄露最好的方式就是：不断重进场景，观察内存增量。如果每次进入、退出之后，内存都有增量，则非常可能发生了内存泄露。在当时的检测中，发现运行时内存不断增长，即使手动垃圾回收也无济于事，最后导致OOM程序崩溃。这很明显就是发生了内存泄露。通过记录内存申请记录，发现是在jni，在c++线程中创建了java对象，使用完成后未删除局部引用，导致对象无法被虚拟机回收（在c++线程结束后，对象才会被回收）。

借助类似的类似的工具，可以查看程序对于资源的使用情况，也是非常方便帮助我们做性能优化的。