[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！