ios壓縮演算法

⑴ 【iOS】FFMpeg SDK 開發手冊

FFmpeg是一套可以用來記錄、轉換數字音頻、視頻，並能將其轉化為流的開源計算機程序。採用LGPL或GPL許可證。它提供了錄制、轉換以及流化音視頻的完整解決方案。它包含了非常先進的音頻/視頻編解碼庫libavcodec，為了保證高可移植性和編解碼質量，libavcodec里很多codec都是從頭開發的。

FFmpeg在Linux平台下開發，但它同樣也可以在其它操作系統環境中編譯運行，包括Windows、Mac OS X等。這個項目最早由Fabrice Bellard發起，現在由Michael Niedermayer維護。許多FFmpeg的開發人員都來自MPlayer項目，而且當前FFmpeg也是放在MPlayer項目組的伺服器上。項目的名稱來自MPEG視頻編碼標准，前面的"FF"代表"Fast Forward"。

libavformat：用於各種音視頻封裝格式的生成和解析，包括獲取解碼所需信息以生成解碼上下文結構和讀取音視頻幀等功能；
libavcodec：用於各種類型聲音/圖像編解碼；
libavutil：包含一些公共的工具函數；
libswscale：用於視頻場景比例縮放、色彩映射轉換；
libpostproc：用於後期效果處理；
ffmpeg：該項目提供的一個工具，可用於格式轉換、解碼或電視卡即時編碼等；
ffsever：一個 HTTP 多媒體即時廣播串流伺服器；
ffplay：是一個簡單的播放器，使用ffmpeg 庫解析和解碼，通過SDL顯示；

三種幀的說明
I幀:幀內編碼幀 ，I幀表示關鍵幀，你可以理解為這一幀畫面的完整保留；解碼時只需要本幀數據就可以完成（因為包含完整畫面）
I幀特點:
1.它是一個全幀壓縮編碼幀。它將全幀圖像信息進行JPEG壓縮編碼及傳輸;
2.解碼時僅用I幀的數據就可重構完整圖像;
3.I幀描述了圖像背景和運動主體的詳情;
4.I幀不需要參考其他畫面而生成;
5.I幀是P幀和B幀的參考幀(其質量直接影響到同組中以後各幀的質量);
6.I幀是幀組GOP的基礎幀(第一幀),在一組中只有一個I幀;
7.I幀不需要考慮運動矢量;
8.I幀所佔數據的信息量比較大。

P幀:前向預測編碼幀。P幀表示的是這一幀跟之前的一個關鍵幀（或P幀）的差別，解碼時需要用之前緩存的畫面疊加上本幀定義的差別，生成最終畫面。（也就是差別幀，P幀沒有完整畫面數據，只有與前一幀的畫面差別的數據）

P幀的預測與重構:P幀是以I幀為參考幀,在I幀中找出P幀「某點」的預測值和運動矢量,取預測差值和運動矢量一起傳送。在接收端根據運動矢量從I幀中找出P幀「某點」的預測值並與差值相加以得到P幀「某點」樣值,從而可得到完整的P幀。
P幀特點:
1.P幀是I幀後面相隔1~2幀的編碼幀;
2.P幀採用運動補償的方法傳送它與前面的I或P幀的差值及運動矢量(預測誤差);
3.解碼時必須將I幀中的預測值與預測誤差求和後才能重構完整的P幀圖像;
4.P幀屬於前向預測的幀間編碼。它只參考前面最靠近它的I幀或P幀;
5.P幀可以是其後面P幀的參考幀,也可以是其前後的B幀的參考幀;
6.由於P幀是參考幀,它可能造成解碼錯誤的擴散;
7.由於是差值傳送,P幀的壓縮比較高。

B幀:雙向預測內插編碼幀。B幀是雙向差別幀，也就是B幀記錄的是本幀與前後幀的差別（具體比較復雜，有4種情況，但我這樣說簡單些），換言之，要解碼B幀，不僅要取得之前的緩存畫面，還要解碼之後的畫面，通過前後畫面的與本幀數據的疊加取得最終的畫面。B幀壓縮率高，但是解碼時CPU會比較累。

B幀的預測與重構
B幀以前面的I或P幀和後面的P幀為參考幀,「找出」B幀「某點」的預測值和兩個運動矢量,並取預測差值和運動矢量傳送。接收端根據運動矢量在兩個參考幀中「找出(算出)」預測值並與差值求和,得到B幀「某點」樣值,從而可得到完整的B幀。
B幀特點
1.B幀是由前面的I或P幀和後面的P幀來進行預測的;
2.B幀傳送的是它與前面的I或P幀和後面的P幀之間的預測誤差及運動矢量;
3.B幀是雙向預測編碼幀;
4.B幀壓縮比最高,因為它只反映丙參考幀間運動主體的變化情況,預測比較准確;
5.B幀不是參考幀,不會造成解碼錯誤的擴散。

注:I、B、P各幀是根據壓縮演算法的需要，是人為定義的,它們都是實實在在的物理幀。一般來說，I幀的壓縮率是7（跟JPG差不多），P幀是20，B幀可以達到50。可見使用B幀能節省大量空間，節省出來的空間可以用來保存多一些I幀，這樣在相同碼率下，可以提供更好的畫質。

1.分組:把幾幀圖像分為一組(GOP，也就是一個序列),為防止運動變化,幀數不宜取多。
2.定義幀:將每組內各幀圖像定義為三種類型,即I幀、B幀和P幀;
3.預測幀:以I幀做為基礎幀,以I幀預測P幀,再由I幀和P幀預測B幀;
4.數據傳輸:最後將I幀數據與預測的差值信息進行存儲和傳輸。幀內（Intraframe）壓縮也稱為空間壓縮（Spatial compression）。當壓縮一幀圖像時，僅考慮本幀的數據而不考慮相鄰幀之間的冗餘信息，這實際上與靜態圖像壓縮類似。幀內一般採用有損壓縮演算法，由於幀內壓縮是編碼一個完整的圖像，所以可以獨立的解碼、顯示。幀內壓縮一般達不到很高的壓縮，跟編碼jpeg差不多。
幀間（Interframe）壓縮的原理是：相鄰幾幀的數據有很大的相關性，或者說前後兩幀信息變化很小的特點。也即連續的視頻其相鄰幀之間具有冗餘信息,根據這一特性，壓縮相鄰幀之間的冗餘量就可以進一步提高壓縮量，減小壓縮比。幀間壓縮也稱為時間壓縮（Temporal compression），它通過比較時間軸上不同幀之間的數據進行壓縮。幀間壓縮一般是無損的。幀差值（Frame differencing）演算法是一種典型的時間壓縮法，它通過比較本幀與相鄰幀之間的差異，僅記錄本幀與其相鄰幀的差值，這樣可以大大減少數據量。
順便說下有損（Lossy ）壓縮和無損（Lossy less）壓縮。無損壓縮也即壓縮前和解壓縮後的數據完全一致。多數的無損壓縮都採用RLE行程編碼演算法。有損壓縮意味著解壓縮後的數據與壓縮前的數據不一致。在壓縮的過程中要丟失一些人眼和人耳所不敏感的圖像或音頻信息,而且丟失的信息不可恢復。幾乎所有高壓縮的演算法都採用有損壓縮,這樣才能達到低數據率的目標。丟失的數據率與壓縮比有關,壓縮比越小，丟失的數據越多,解壓縮後的效果一般越差。此外,某些有損壓縮演算法採用多次重復壓縮的方式,這樣還會引起額外的數據丟失。

如果NALU對應的Slice為一幀的開始，則用4位元組表示，即0x00000001；否則用3位元組表示，0x000001。
NAL Header：forbidden_bit，nal_reference_bit（優先順序）2bit，nal_unit_type（類型）5bit。 標識NAL單元中的RBSP數據類型，其中，nal_unit_type為1， 2， 3， 4， 5的NAL單元稱為VCL的NAL單元，其他類型的NAL單元為非VCL的NAL單元。
0：未規定
1：非IDR圖像中不採用數據劃分的片段
2：非IDR圖像中A類數據劃分片段
3：非IDR圖像中B類數據劃分片段
4：非IDR圖像中C類數據劃分片段
5：IDR圖像的片段
6：補充增強信息（SEI）
7：序列參數集（SPS）
8：圖像參數集（PPS）
9：分割符
10：序列結束符
11：流結束符
12：填充數據
13：序列參數集擴展
14：帶前綴的NAL單元
15：子序列參數集
16 – 18：保留
19：不採用數據劃分的輔助編碼圖像片段
20：編碼片段擴展
21 – 23：保留
24 – 31：未規定

H.264的SPS和PPS串，包含了初始化H.264解碼器所需要的信息參數，包括編碼所用的profile，level，圖像的寬和高，deblock濾波器等。

碼率：256～512 kb/s
幀率：15～20fps
解析度：1280x720(HD) 640x368(VGA) 1920x1080(UHD)

中文名：高級音頻編碼，出現於1997年，基於MPEG-2的音頻編碼技術。由Fraunhofer IIS、杜比實驗室、AT&T、Sony等公司共同開發，目的是取代MP3格式。2000年，MPEG-4標准出現後，AAC重新集成了其特性，加入了SBR技術和PS技術，為了區別於傳統的MPEG-2 AAC又稱為MPEG-4 AAC。

優點：相對於mp3，AAC格式的音質更佳，文件更小。
不足：AAC屬於有損壓縮的格式，與時下流行的APE、FLAC等無損格式相比音質存在「本質上」的差距。加之，傳輸速度更快的USB3.0和16G以上大容量MP3正在加速普及，也使得AAC頭上「小巧」的光環不復存在了。

音頻采樣率是指錄音設備在一秒鍾內對聲音信號的采樣次數，采樣頻率越高聲音的還原就越真實越自然。在當今的主流採集卡上，采樣頻率一般共分為22.05KHz、44.1KHz、48KHz三個等級，22.05KHz只能達到FM廣播的聲音品質，44.1KHz則是理論上的CD音質界限，48KHz則更加精確一些。

比特率是指每秒傳送的比特(bit)數。單位為 bps(Bit Per Second)，比特率越高，傳送數據速度越快。聲音中的比特率是指將模擬聲音信號轉換成數字聲音信號後，單位時間內的二進制數據量，是間接衡量音頻質量的一個指標。 視頻中的比特率（碼率）原理與聲音中的相同，都是指由模擬信號轉換為數字信號後，單位時間內的二進制數據量。
信道編碼中，K符號大小的信源數據塊通過編碼映射為N符號大小的碼字，則K/N成為碼率，其中假設編碼前後的符號表沒有變化。

FFMPEG中結構體很多。最關鍵的結構體可以分成以下幾類：
解協議（http,rtsp,rtmp,mms）
AVIOContext，URLProtocol，URLContext主要存儲視音頻使用的協議的類型以及狀態。URLProtocol存儲輸入視音頻使用的封裝格式。每種協議都對應一個URLProtocol結構。（注意：FFMPEG中文件也被當做一種協議「file」）
解封裝（flv,avi,rmvb,mp4）
AVFormatContext主要存儲視音頻封裝格式中包含的信息；AVInputFormat存儲輸入視音頻使用的封裝格式。每種視音頻封裝格式都對應一個AVInputFormat 結構。
解碼（h264,mpeg2,aac,mp3）
每個AVStream存儲一個視頻/音頻流的相關數據；每個AVStream對應一個AVCodecContext，存儲該視頻/音頻流使用解碼方式的相關數據；每個AVCodecContext中對應一個AVCodec，包含該視頻/音頻對應的解碼器。每種解碼器都對應一個AVCodec結構。
存數據
視頻的話，每個結構一般是存一幀；音頻可能有好幾幀
解碼前數據：AVPacket
解碼後數據：AVFrame

AVCodec是存儲編解碼器信息的結構體
const char *name：編解碼器的名字，比較短
const char *long_name：編解碼器的名字，全稱，比較長
enum AVMediaType type：指明了類型，是視頻，音頻，還是字幕
enum AVCodecID id：ID，不重復
const AVRational *supported_framerates：支持的幀率（僅視頻）
const enum AVPixelFormat *pix_fmts：支持的像素格式（僅視頻）
const int *supported_samplerates：支持的采樣率（僅音頻）
const enum AVSampleFormat *sample_fmts：支持的采樣格式（僅音頻）
const uint64_t channel_layouts：支持的聲道數（僅音頻）
int priv_data_size：私有數據的大小
1.注冊所有編解碼器：av_register_all();
2.聲明一個AVCodec類型的指針，比如說AVCodec first_c;
3.調用av_codec_next()函數，即可獲得指向鏈表下一個解碼器的指針，循環往復可以獲得所有解碼器的信息。注意，如果想要獲得指向第一個解碼器的指針，則需要將該函數的參數設置為NULL。

這是一個描述編解碼器上下文的數據結構，包含了眾多編解碼器需要的參數信息
如果是單純使用libavcodec，這部分信息需要調用者進行初始化；如果是使用整個FFMPEG庫，這部分信息在調用 av_open_input_file和av_find_stream_info的過程中根據文件的頭信息及媒體流內的頭部信息完成初始化。其中幾個主要 域的釋義如下：
extradata/extradata_size： 這個buffer中存放了解碼器可能會用到的額外信息，在av_read_frame中填充。一般來說，首先，某種具體格式的demuxer在讀取格式頭 信息的時候會填充extradata，其次，如果demuxer沒有做這個事情，比如可能在頭部壓根兒就沒有相關的編解碼信息，則相應的parser會繼 續從已經解復用出來的媒體流中繼續尋找。在沒有找到任何額外信息的情況下，這個buffer指針為空。
time_base：
width/height：視頻的寬和高。
sample_rate/channels：音頻的采樣率和信道數目。
sample_fmt： 音頻的原始采樣格式。
codec_name/codec_type/codec_id/codec_tag：編解碼器的信息。

該結構體描述一個媒體流
主要域的釋義如下，其中大部分域的值可以由av_open_input_file根據文件頭的信息確定，缺少的信息需要通過調用av_find_stream_info讀幀及軟解碼進一步獲取：
index/id：index對應流的索引，這個數字是自動生成的，根據index可以從AVFormatContext::streams表中索引到該流；而id則是流的標識，依賴於具體的容器格式。比如對於MPEG TS格式，id就是pid。
time_base：流的時間基準，是一個實數，該流中媒體數據的pts和dts都將以這個時間基準為粒度。通常，使用av_rescale/av_rescale_q可以實現不同時間基準的轉換。
start_time：流的起始時間，以流的時間基準為單位，通常是該流中第一個幀的pts。
ration：流的總時間，以流的時間基準為單位。
need_parsing：對該流parsing過程的控制域。
nb_frames：流內的幀數目。
r_frame_rate/framerate/avg_frame_rate：幀率相關。
codec：指向該流對應的AVCodecContext結構，調用av_open_input_file時生成。
parser：指向該流對應的AVCodecParserContext結構，調用av_find_stream_info時生成。

這個結構體描述了一個媒體文件或媒體流的構成和基本信息
這是FFMpeg中最為基本的一個結構，是其他所有結構的根，是一個多媒體文件或流的根本抽象。其中:nb_streams和streams所表示的AVStream結構指針數組包含了所有內嵌媒體流的描述；iformat和oformat指向對應的demuxer和muxer指針；pb則指向一個控制底層數據讀寫的ByteIOContext結構。
start_time和ration是從streams數組的各個AVStream中推斷出的多媒體文件的起始時間和長度，以微妙為單位。
通常，這個結構由av_open_input_file在內部創建並以預設值初始化部分成員。但是，如果調用者希望自己創建該結構，則需要顯式為該結構的一些成員置預設值——如果沒有預設值的話，會導致之後的動作產生異常。以下成員需要被關註：
probesize
mux_rate
packet_size
flags
max_analyze_ration
key
max_index_size
max_picture_buffer
max_delay

AVPacket定義在avcodec.h中
FFMPEG使用AVPacket來暫存解復用之後、解碼之前的媒體數據（一個音/視頻幀、一個字幕包等）及附加信息（解碼時間戳、顯示時間戳、時長等）。其中：
dts 表示解碼時間戳，pts表示顯示時間戳，它們的單位是所屬媒體流的時間基準。
stream_index 給出所屬媒體流的索引；
data 為數據緩沖區指針，size為長度；
ration 為數據的時長，也是以所屬媒體流的時間基準為單位；
pos 表示該數據在媒體流中的位元組偏移量；
destruct 為用於釋放數據緩沖區的函數指針；
flags 為標志域，其中，最低為置1表示該數據是一個關鍵幀。
AVPacket 結構本身只是個容器，它使用data成員指向實際的數據緩沖區，這個緩沖區可以通過av_new_packet創建，可以通過 av_p_packet 拷貝，也可以由FFMPEG的API產生（如av_read_frame），使用之後需要通過調用av_free_packet釋放。
av_free_packet調用的是結構體本身的destruct函數，它的值有兩種情況：(1)av_destruct_packet_nofree或 0；(2)av_destruct_packet，其中，前者僅僅是將data和size的值清0而已，後者才會真正地釋放緩沖區。FFMPEG內部使用 AVPacket結構建立緩沖區裝載數據，同時提供destruct函數，如果FFMPEG打算自己維護緩沖區，則將destruct設為 av_destruct_packet_nofree，用戶調用av_free_packet清理緩沖區時並不能夠將其釋放；如果FFMPEG不會再使用 該緩沖區，則將destruct設為av_destruct_packet，表示它能夠被釋放。對於緩沖區不能夠被釋放的AVPackt，用戶在使用之前 最好調用av_p_packet進行緩沖區的克隆，將其轉化為緩沖區能夠被釋放的AVPacket，以免對緩沖區的不當佔用造成異常錯誤。而 av_p_packet會為destruct指針為av_destruct_packet_nofree的AVPacket新建一個緩沖區，然後將原 緩沖區的數據拷貝至新緩沖區，置data的值為新緩沖區的地址，同時設destruct指針為av_destruct_packet。

構體保存的是解碼後和原始的音視頻信息。AVFrame通過函數av_frame_alloc()初始化，該函數僅僅分配AVFrame實例本身，而沒有分配其內部的緩存。AVFrame實例由av_frame_free()釋放；AVFrame實例通常分配一次，重復使用，如分配一個AVFrame實例來保留解碼器中輸出的視頻幀（此時應在恰當的時候使用av_frame_unref()清理參考幀並將AVFrame歸零）。該類所描述的數據通常由AVBuffer的API來保存一個引用計數，並保存於AVFrame.buf
/AVFrame.extended_buf，在至少存在一個參考的時候（如AVFrame.buf[0] != NULL），則該對象被標記為「被引用」。在此情況下，AVFrame所包含的每一組數據必須包含於AVFrame的緩存中。

ADTS流 跟Raw流，
1.ADTS是個啥
ADTS全稱是(Audio Data Transport Stream)，是AAC的一種十分常見的傳輸格式。

AAC解碼器都需要把AAC的ES流打包成ADTS的格式，一般是在AAC ES流前添加7個位元組的ADTS header。也就是說你可以吧ADTS這個頭看作是AAC的frameheader。

ffmpeg寫 mp4+aac時呢，音頻有兩個值得注意的地方。
1 寫aac音頻時，要添加兩個位元組的信息到AVCodecContext.
2 ffmpeg 寫AAC音頻數據不能含有ADTS頭

在AAC ES流前添加7個位元組的ADTS header。也就是說你可以吧ADTS這個頭看作是AAC的frameheader。

tvOS必須要支持 bitcode. (iOS bitcode項可選的) 所以在編譯的時候Makefile要加上 CFLAGS= -fembed-bitcode 。 如果用xcode編譯lib，要在Build Settings—>custom compiler flags —>cflags 加上OTHER_CFLAGS="-fembed-bitcode" 。

1 內存優化。內存往上漲。沒能及時回收。最好能夠使用手動管理內存。
解碼優化，看ffmpeg文檔，最新的解碼庫，解碼效率，穩定性，綜合性考慮。
YUV->RGB OpenGLES shader來顯示。

1.分離視頻音頻流
ffmpeg -i input_file -vcodec -an output_file_video//分離視頻流
ffmpeg -i input_file -acodec -vn output_file_audio//分離音頻流
2.視頻解復用
ffmpeg –i test.mp4 –vcodec –an –f m4v test.264
ffmpeg –i test.avi –vcodec –an –f m4v test.264
3.視頻轉碼
ffmpeg –i test.mp4 –vcodec h264 –s 352 278 –an –f m4v test.264 //轉碼為碼流原始文件
ffmpeg –i test.mp4 –vcodec h264 –bf 0 –g 25 –s 352 278 –an –f m4v test.264 //轉碼為碼流原始文件
ffmpeg –i test.avi -vcodec mpeg4 –vtag xvid –qsame test_xvid.avi //轉碼為封裝文件
//-bf B幀數目控制，-g 關鍵幀間隔控制，-s 解析度控制
4.視頻封裝
ffmpeg –i video_file –i audio_file –vcodec –acodec output_file
5.視頻剪切
ffmpeg –i test.avi –r 1 –f image2 image-%3d.jpeg //提取圖片
ffmpeg -ss 0:1:30 -t 0:0:20 -i input.avi -vcodec -acodec output.avi //剪切視頻
//-r 提取圖像的頻率，-ss 開始時間，-t 持續時間
6.視頻錄制
ffmpeg –i rtsp://192.168.3.205:5555/test –vcodec out.avi
7.YUV序列播放
ffplay -f rawvideo -video_size 1920x1080 input.yuv
8.YUV序列轉AVI
ffmpeg –s w*h –pix_fmt yuv420p –i input.yuv –vcodec mpeg4 output.avi

⑵ 蘋果手機zip文件怎麼打開

接收到zip文件後，打開zip文件。點擊「其他方式打開」。在彈出的選項中選擇「QQ瀏覽器」即可。Zip是常用的英文簡稱，有多重指向，一種是指高儲存密度的磁碟驅動器與磁碟，一種是指由菲爾-卡茨於1989年1月發明的一種計算機文件壓縮演算法，也指美國的郵政編碼等。

Zip是常用的英文簡稱，有多重指向，一種是指高儲存密度的磁碟驅動器與磁碟，一種是指由菲爾-卡茨於1989年1月發明的一種計算機文件壓縮演算法，也指美國的郵政編碼等。

⑶ IOS 解決問題：相似、截屏照片清理和圖片壓縮

用來提供相冊的清理相似圖片、清理截屏圖片、壓縮圖片三個功能。

額外需要引入的框架：

Photos 引用了系統的 AssetsLibrary 框架，需要額外導入，否則會報錯：

引入方式：

作用是無需創建實例，通過類方法直接調用。

在這個方法中載入的圖片包括相似圖、截屏圖以及可瘦身的圖片，所以是公共部分。

第一步： 載入照片之前首先要清除舊數據。

第二步： 判斷相冊授權狀態。如果相冊授權狀態為沒決定，則開啟許可權提示，在 info.plist 中添加上 Privacy - Photo Library Usage Description ，提示語句可為：獲取相冊許可權。

如果相冊授權狀態為拒絕，則彈出提示框，點擊前往設置則跳轉到設置APP開啟許可權。

第三步： 如果已經授權則直接獲取相冊中的數據。

第四步： requestImageWithIndex: 方法通過圖片索引位置來獲取 assetArray 中對應的圖片。這個方法在 index+1 後不斷遞歸調用自己，直到遍歷完整個 assetArray 。傳入縮略圖和原圖後，即進入了本文章的關鍵部分，即圖片的處理流程了。

第五步： 圖片的處理方法 dealImageWithIndex: 對傳入的縮略圖和原圖進行三步處理，分別判斷其是否為相似圖片、截屏圖片、可以瘦身的圖片，如果是則將其加入到對應數組中保存作為數據源。處理完一張圖片後將 index+1 ，再調用 requestImageWithIndex: 處理下一張圖片，這是個遞歸過程，直到全部圖片處理完成。

因為圖片資源數組 assetArray 是按照創建時間排序的，所以可以通過和上一個圖片的創建時間相比較來對圖片按照是否為同一天創建的標准來分組顯示。如果是同一天創建的圖片，則將其分為一組。是否為同一天的比較方法如下：

第六步： 圖片載入完成，計算相似、截屏、可瘦身的圖片的數量和可節省內存的大小，最後將各類可節省內存的大小加起來得到總的可節省內存的大小。

其中獲取圖片數量及可以節省的內存空間大小的 getInfoWithDataArray: 方法的實現如下：

在 ClearPhotoManager 中定義：

當我們在相冊新增加了一張圖片的時候，控制台輸出如下：

在 ClearPhotoViewController 中使用：頁面顯示前或者相冊發生變動了則更新數據源

在 中使用：刪除後通知更新相冊和數據源

在 ThinPhotoViewController 中使用：壓縮後通知更新相冊和數據源

刪除一張圖片後的內存變化：

注意：這里進行了個小實驗，可以看到即使照片相同，但是如果創建日期不同的話，APP也對它進行了單獨分組，因為我們是按照日期的標准來劃分組的。實際使用過程中，這種情況很少，因為會產生相似圖片的原因大都是復制和連拍，而復制的圖片、連拍的圖片日期都是相同的。

屬性的懶載入方法實現如下：

這里用到了圖片相似度演算法，其原理包括五步：
1、縮小尺寸
2、簡化色彩
3、計算平均值
4、比較像素的灰度
5、計算哈希值

該演算法的具體實現我們不用去關心，只需要導入 ImageCompare.h 這個文件即可。在該文件內部用到了：

所以還需要導入這個框架： opencv2.framework 。這兩份文件在我的 demo 里都已經提供了。

如果上一張圖片存在並且是現在的圖片的創建時間是同一天，而且還滿足相似度演算法，則更新相似圖片數據源，否則說明和上一張圖片並不相似。

其中以創建日期作為字典的 key ，其方法 stringWithDate: 的實現如下：

這是最關鍵的一步，也是非常繞腦袋的一步，理解的關鍵是分清楚下面的數組和字典的作用和區別：

similarArray的內容列印結果如下：

similarArray中每一個lastDictionary列印結果如下：

lastDictionary的allValues：

⑷ ios 怎麼用deflate 壓縮演算法壓縮nsstring

namespace NExtractZip
{
void ExtractionExampleL(const TDesC& aCompressedFile, const TDesC& aPath, const TDesC& aFileName)
{
if(!IteratorExampleL(aCompressedFile, aFileName)) { return; }

// Connect to the file server.
RFs fileSession;
User::LeaveIfError(fileSession.Connect());

// Create an instance of CZipFile.
CZipFile* zipFile = CZipFile::NewL(fileSession, aCompressedFile);
CleanupStack::PushL(zipFile);

// Get the input stream of aFileName.
CZipFileMember* member = zipFile->CaseInsensitiveMemberL(aFileName);
CleanupStack::PushL(member);
RZipFileMemberReaderStream* stream;
zipFile->GetInputStreamL(member, stream);
CleanupStack::PushL(stream);

// Extracts aFileName to a buffer.
// If the file is quite huge, then read the file in streaming mode.
// For example, use 4KB buffer and read it in an active object.
HBufC8* buffer = HBufC8::NewLC(member->UncompressedSize());
TPtr8 bufferPtr(buffer->Des());
User::LeaveIfError(stream->Read(bufferPtr, member->UncompressedSize()));

// Store the buffer to a file.
// It saves the file to KExtractedPath directory, the file name is the same
// as the one in the .zip file.

⑸ 相比安卓 蘋果照片占的空間更大嗎

照片大小和是不是安卓IOS沒有太大的關系
照片大小取決於手機像素以及成像的壓縮演算法
就拿小米10來說，用的一億模組的攝像頭，拍出來的東西都是10+MB以上
望採納謝謝

⑹ 蘋果11可以更新成ios11.11嗎

這種情況是非常影響用戶體驗,作者使用蘋果輸入,當您需要輸入文本,能明顯感覺系統卡,輸入字幕經常上演,但系統分開幾秒鍾顯示所有你想輸入文本,經驗很不舒服。這段經歷將會崩潰,與10 iOS系統相比,最明顯的感覺後,iPhone升級iOS 6,11日系統升級後,打開應用程序載入速度慢,盡管蘋果官方強調舊體制進行了特別優化,但是這個等待時間太長,我們經常使用微信,例如,如果你沒有打開很長一段時間,我收到了很多DMS(特別是群消息傳遞),你進入很長時間,在輸入微信後一分鍾等待消息，用7 Plus比較iPhone，顯然要快得多，都是幾秒鍾。

由於iOS 11添加許多新的動畫效果,升級後的新系統最明顯的感覺,而iPhone 6 + 10%,前十可以扭轉iOS的舊設備,生活是相當重要的,特別是電池有明顯的損失。16GB的iPhone6最大的問題是什麼?不用說,99%的用戶「記憶」首先,雖然它能通過某些技術手段增加內存,但不想,額外的錢或安全問題的用戶,如何盡可能的節省空間在手機上是當務之急。我們之前說過，舊設備不建議升級iOS11，老設備如iPhone6保持iOS10.3.3比較好，但是看了iOS11後，這幾個新功能，16gb iPhone6可以考慮升級。

列表中的占內存,除了大游戲和視頻,照片,,喜歡拍照,特別是對於用戶手機數以百計的照片是一個兒科醫生,雖然單照片占據內存空間不是太大,但數以百計的照片更多國家加在一起共占據記憶是壓倒性的。在iOS11升級之前，我們只能通過定期重新載入/刪除圖像來維護內存空間。然而，蘋果在iOS11新照片存儲格式——HEIF圖像格式，採用了更先進的壓縮演算法，可以在提高圖像質量的前提下進一步節省圖像的佔用內存容量，方便16 gb用戶多拍照片。需要注意的是，在升級iOS11的beta版本後，一些用戶發現新的圖像格式不能在計算機上看到。目前還不清楚這是一個系統問題還是一個功能問題。

根據調查數據(2013),根據Gartner報告數據高達44%的手機用戶安裝超過20個,應用程序的數量,另一個機構應用安妮發布的數據顯示,在中國,美國,日本和其他10個國家,普通用戶使用30多個應用,每人每天使用應用程序在10左右,這也意味著,絕大多數的用戶應用程序安裝在手機的一半以上屬於「沉默」,這是很少使用。大多數這些不常用的應用程序也是內存佔用。為了解決不常用應用程序佔用內存的問題,蘋果將增加iOS11自動刪除沒有功能的應

⑺ iOS微信聊天，朋友圈圖片壓縮演算法

圖片作為App中重要的一個元素，非常具有表現力，圖片既要讓用戶能看清楚，又能讓發布圖片的用戶能快速的上傳。所以開發者要對圖片進行裁切和質量壓縮。但是裁切尺寸質量壓縮比設置成多少卻很難控制好，如果設置不當會導致圖片顯示效果很差。

微信是一個很好的參照物，被大家廣為使用並接受。這個擴展就是通過發送微信朋友圈和聊天會話發送了大量圖片，對比原圖與微信壓縮後的圖片逆向推算出來的壓縮演算法。

經過大量的測試，微信的圖片壓縮質量值 ≈0.5

⑻ 二進制壓縮演算法有哪些

二進制數據壓縮演算法二進制是計算技術中廣泛採用的一種數制。二進制數據是用0和1兩個數碼來表示的數。它的基數為2，進位規則是「逢二進一」，借位規則是「借一當二」，由18世紀德國數理哲學大師萊布尼茲發現。當前的計算機系統使用的基本上是二進制系統，數據在計算機中主要是以補碼的形式存儲的。計算機中的二進制則是一個非常微小的開關，用「開」來表示1，「關」來表示0。

20世紀被稱作第三次科技革命的重要標志之一的計算機的發明與應用，因為數字計算機只能識別和處理由『0』。『1』符號串組成的代碼。其運算模式正是二進制。19世紀愛爾蘭邏輯學家喬治布爾對邏輯命題的思考過程轉化為對符號「0『』。『』1『』的某種代數演算，二進制是逢2進位的進位制。0、1是基本算符。因為它只使用0、1兩個數字元號，非常簡單方便，易於用電子方式實現。

二進制壓縮 - 演算法

二進制壓縮

在編程時遇到每個數據只有兩種狀態，且 dfs 或者 bfs 時遍歷時間復雜度高時，可以採用二進制壓縮數據，尤其是二維數組。LZFSE

1，zlib和gzip都對deflate進行了封裝，比deflate多了數據頭和尾

1，蘋果開源了新的無損壓縮演算法 LZFSE ，該演算法是去年在iOS 9和OS X 10.10中 引入 的。按照蘋果公司的說法，LZFE的壓縮增益和ZLib level 5相同，但速度要快2~3倍，能源效率也更高。

LZFSE基於Lempel-Ziv，並使用了 有限狀態熵編碼，後者基於Jarek Duda在

非對稱數字系統（ANS）方面所做的熵編碼工作。簡單地講，ANS旨在「終結速度和比率的平衡」，既可以用於精確編碼，又可以用於快速編碼，並且具有數據加密功能。使用ANS代替更為傳統的

Huffman和 算術編碼方法的壓縮庫 越來越多，LZFSE就位列其中。

顯然，LZFSE的目標不是成為最好或最快的演算法。事實上，蘋果公司指出，

LZ4的壓縮速度比LZFSE快，而 LZMA提供了更高的壓縮率，但代價是比Apple

SDK提供的其他選項要慢一個數量級。當壓縮率和速度幾乎同等重要，而你又希望降低能源效率時，LZFSE是蘋果推薦的選項。

GitHub上提供了LZFSE的參考實現。在MacOS上構建和運行一樣簡單：

$ xcodebuild install DSTROOT=/tmp/lzfse.dst

如果希望針對當前的iOS設備構建LZFSE，可以執行：

xcodebuild -configuration 「Release」 -arch armv7 install DSTROOT=/tmp/lzfse.dst

除了 API文檔之外，蘋果去年還提供了一個 示例項目，展示如何使用LZFSE 進行塊和流壓縮，這是一個實用的LZFSE入門資源。

LZFSE是在谷歌 brotli之後發布的，後者在去年開源。與LZFSE相比，brotli 似乎是針對一個不同的應用場景進行了優化，比如壓縮靜態Web資產和Android APK，在這些情況下，壓縮率是最重要的。