先上效果圖
實現(xiàn)的功能，
發(fā)送文字，發(fā)送系統(tǒng)的emoji,發(fā)送圖片，發(fā)送語音，消息的重發(fā)。
控件封裝思路
整體采用MVVM框架封裝。
UI相關(guān)：UI布局上現(xiàn)階段需求，只使用一個Cell，然后給不同類型消息（例如文字和圖片）寫2個不同View，Model，和ViewModel。
網(wǎng)絡(luò)相關(guān)：環(huán)信完全獨立封裝起來，提供一個封裝好后的一個文件，只有這個文件能訪問環(huán)信的方法和監(jiān)聽環(huán)信的回調(diào)。然后對外暴露發(fā)送消息方法和接受消息的方法。
鍵盤相關(guān)：鍵盤中包含文字，emoji，錄音頻，更多功能（先包括相機和相冊）4個模塊。
緩存相關(guān)：采用FMDB把接受到的消息和發(fā)送的消息存入數(shù)據(jù)庫中來保存。每一個對話組創(chuàng)建一個表。
涉及到的技術(shù)難點：
1.當(dāng)一個cell中顯示過多的emoji表情，界面會卡頓。
2.每條消息都需要點擊，長按，雙擊等手勢。所以需要很好的，靈活的劃分各自的點擊區(qū)域，
3.鍵盤高度需要根據(jù)數(shù)據(jù)的內(nèi)容去改變高度，粘貼時需要額外的處理。
4.錄音頻時如果實現(xiàn)代理方法audioRecorderDidFinishRecording會自動切換到主線程，造成UI卡頓的情況。
5.緩存數(shù)據(jù)的寫入和讀取的數(shù)據(jù)問題。
6.發(fā)送消息后需要刷新UI來改變當(dāng)前消息的狀態(tài)，如果直接reload會造成浪費和卡頓。所以需要獲取當(dāng)前UI上已經(jīng)顯示的數(shù)組，遍歷這個數(shù)組，獲取到這些數(shù)組中處于loading狀態(tài)的數(shù)據(jù)的行數(shù)，按照這個行數(shù)刷新UI。
7.在氣泡中的文字需要實現(xiàn)手機號，網(wǎng)頁地址的辨認(rèn)。AppleSDK識別文本中URL不太精確，需要自己提供正則式。
