[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 buffer
pImagePool->setAutoFree(0);//拍照后release image buffer
【重要提醒】如果使用此优化，务必保证YUVNode.cpp中有如下修改，如无，请申请patch ALPS04338041.
mtkcam3\feature\core\featurePipe\capture\nodes\YUVNode.cpp
1090: pPlgRequest->mIBufferFull = (iBufferFullHandle == NULL) ? PluginHelper::CreateBuffer(pNodeReq, TID_MAN_FULL_YUV, INPUT) : std::move(iBufferFullHandle);
1091: pPlgRequest->mIBufferClean = PluginHelper::CreateBuffer(pNodeReq, TID_MAN_FULL_PURE_YUV, INPUT);
1092: pPlgRequest->mIBufferDepth = PluginHelper::CreateBuffer(pNodeReq, TID_MAN_DEPTH, INPUT);
1093: pPlgRequest->mOBufferFull = (oBufferFullHandle == NULL) ? PluginHelper::CreateBuffer(pNodeReq, TID_MAN_FULL_YUV, OUTPUT) : std::move(oBufferFullHandle);
2.减少ZSL buffer number
优点：优化整个camera使用期间的内存用量
缺点：如果设定值过小，重载时会影响preview帧率.
优化量：实际减少的buffer数据有关，也与sensor大小有关.
/vendor/mediatek/proprietary/hardware/mtkcam3/pipeline/model/zsl/hbc/HistoryBufferContainerImp.cpp
mMaxBufNum = (pInfo->getMaxBufNum()>mMaxBufNum)? pInfo->getMaxBufNum() : mMaxBufNum;//此值即是
基于MAX_HISTORY_DEPTH 和app设定的streaminfo信息
3.修改P1Node buffer格式（需满足条件）
使用条件：Raw格式在一次configure后不会发生改变. 举例，4-cell功能以及Raw HDR功能均会在使用期间切换Raw格式.则不可使用此优化;
优点：P1Node输出buffer格式由BloB改为Bayer10;
缺点:无法实时做格式转换;
优化量：与sensor实际大小有关.
/vendor/mediatek/proprietary/hardware/mtkcam3/pipeline/policy/config/P1HwSettingPolicy.cpp
bool isLowMem = ::property_get_bool("ro.config.low_ram", false); //强制将isLowMem置为True.
如果平台支持UFO，也可使用UFO格式，P1输出可以有多种格式，格式选择的逻辑判断均在P1HwSettingPolicy.cpp中，而各值的对应列表可查阅：
/vendor/mediatek/proprietary/hardware/mtkcam/include/mtkcam/def/ImageFormat.h
4.提高MFNR的门限，尽量避免使用MFNR，减少mfnr张数
优点：极大的改善内存以及cpu 资源的消耗，提升拍照速度，提升系统流畅度；
缺点：高光感下的图像噪点略高，影响图片质量，有些可以通过tuning 其他nr参数弥补回来;
/vendor/mediatek/proprietary/custom/mtXXXX/hal/inc/camera_custom_nvram.h
MUINT16 mfll_iso_th // tunning 参数 各家不同 ，默认800;
MUINT8 capture_frame_number; //mfnr张数，最低3张，默认4张;
对应的参数tunning的同事会较清楚，或者在/vendor/mediatek/proprietary/custom/mtxxxx/hal/imgsensor/ver1/sensorname 下全搜mfll_iso_th即可.
5.关闭ZSL
优点：拍照的buffer不再受preview处理效率的影响，同时节省buffer;
缺点：与Hal1上关闭zsd不同的是，关闭zsl仅拍照瞬间画面略有停顿.而Hal1上关闭zsd是整个拍照未完成期间均停顿.
优化量：节省zsl buffer pool的大小，一般会达到100M以上.
Control.capture.default.zsl.mode 设为off
Control.capture.zsl.mode configure和request时，均需设定为off，否则会出现re-configuresesion的问题，影响启动时间;
6.拍照相关限制
原理：限制同时在hal层处理的capture 数目，变相的优化内存峰峰值.
缺点：对内存存量要求高，则容易影响shot2shot的实际效果.
Shot2shot：
/vendor/mediatek/proprietary/hardware/mtkcam3/pipeline/model/capture/
#define MIN_FREE_MEM (300000000) // 300M，只有内存可用量大于300M时，才会告知app可以拍下一张.
最大request size：
maxAppJpegStreamNum //变相限制max request size
以上是通用法则.还有些可能会用得上的优化点：
8.streaming场景的优化
a)确认P1Node输出的size，等于preview size值. 如若不是，请查看P1Node输出的size来源.逻辑判断来源
/vendor/mediatek/proprietary/hardware/mtkcam3/pipeline/policy/config/P1HwSettingPolicy.cpp
需要注意的是：P1Node输出size大于preview size有助于减轻锯齿问题，客户需自行斟酌是否优化此项;
b )确认streaming的三方算法要求的size<=preview size. 三方算法所需size可通过下述API设定：
if( mUseSize ) sel.mIBufferMain1.setSpecifiedSize(mSize)
此修改，除了可优化内存外，同样可提升三方算法处理效率，但是需要看三方是否都支持；
总的来说，内存相关的优化，与手机状态强相关，所有的参数均需实验后方可得出，即使同一个hw，但不同的OS系统，不同的feature，都无法使用同一套优化参数，以上仅仅是提供优化思路与相关参数，具体的数值，请大家多多实验，在性能与内存之前找到项目的平衡点，做到最优.
Good Luck！
来源：CSDN
作者：koson_L
链接：https://blog.csdn.net/liaokesen168/article/details/104768367