微信的研究

下面是個人研究微信android 4.2版本的一些結果，不一定正確。

1. 微信android使用的是amr編碼；iphone未知，估計是aac，轉碼會在微信服務器上完成。android上使用了speex這個庫，估計是爲了達到邊錄邊發。在服務器做格式轉換確實比客戶端方便多了，用ffmpeg就可以搞定了，也是瘦客戶端的一種思路，而且可以依此延伸很多擴展業務。

2. 微信android最新版的數據庫依然是sqlite，但文件做了加密，用的是http://sqlcipher.net/

3. 微信發送地理位置用的是google地圖，網頁地址在assets\map\map_cn.html

4. 微信的視頻通信不是在QQ的基礎上做的，而是自己實現的一套，基於speex，webrtc, voip等庫。微信和QQ的視頻通信和skype相差太遠了，特別是網絡好的情況下。看來視頻通信還是有技術壁壘的，現在只能希望Google將webrtc做成熟一點了。

5. 微信使用了一些jni：
    libImgProcess.so 用於gif處理，特別是摳背景。這個微信在一個講座裏面還專門提過。
    libvprotocal.so 用於視頻錄製，不過這個庫效率也不高。錄製一分鐘的視頻，等待壓縮要半分鐘。幹嘛不像Instagram放在後頭偷偷去做，或者邊做邊錄。
    libMMProtocalJni.so  用於pcm轉amr，不用android系統自帶的是因爲可以邊錄邊發，這個庫也做了插件相關的一些處理
    libvoipMain.so 視頻通話
    libvoice.so 視頻通話語音處理，用了speex
    libSync.so 用於通訊錄同步
    libImgFilter.so 用於圖片處理的濾鏡
    libmmcrypto.so 數據庫加密，其實就是sqlcipher

6.  我原先以爲微信會在QQ的基礎上做視頻通話，但實際上它沒有，可能是因爲這樣可以比較獨立，不用遵循QQ的協議。不過QQ的協議爲了兼容，有了很重的歷史包袱，已不太適合新潮流了。微信的視頻通話用了兩個服務器：punch.weixin.qq.com和voip.weixin.qq.com。這兩個服務器主要是爲了打洞和握手。

7. 從http://timyang.net/architecture/notes-weixin/和騰訊大講堂的一些資料，談的比較多的是類Sync協議。從張小龍做郵箱的背景來看，我原本以爲會是這樣一種協議：每個消息相當於一條郵件，而微信的各個界面相當於郵箱的各個文件夾，例如收件箱，發件箱，垃圾郵件，自定義文件夾等，客戶端和服務器端要做的就是做這些文件夾同步，就像rsync一樣。但從後面的瞭解來看，實際上並沒有這樣做。我覺得用郵件來理解IM系統是最直觀的方式，發一條消息相當於發一封郵件，郵件體系裏面已經很好地做到了轉發，分佈式，郵件組，郵件狀態等功能，客戶端要做的就是同步郵件和聯繫人等。

8. 從微信的發展來看，微信後面應該是朝着平臺方向發展，也就是它提供推送和消息發送平臺，讓其他廠商依此開發應用，發佈信息，做活動等。現實中的一句話：要致富，先修路。互聯網的路就是互通，就是交流。QQ就是站住了這個先機，所以後面可以做很多其他的事情來賺錢。

9. 從現在互聯網的發展而言，IM和視頻（包括IM裏面視頻通話）是一個方向，這些都應該成爲互聯網的基礎設施，就像瀏覽器一樣。現在IM還沒有一個很好的解決方案，XMPP並不能很好地做到業務邏輯獨立開來。從IM的本質來看，IM其實就是將一條消息從一個地方傳輸到另外一個地方，這個和TCP很像，爲什麼不實現一個高級點的TCP協議了，只是將TCP/IP裏面的IP地址換成了一個類似XMPP的唯一ID而已，其他的很多細節都可以照搬TCP協議。有了這個協議之後，將業務邏輯在現有HTTP server的基礎上做，例如發送語音和圖片就相當於上傳一個文件，服務器在處理完這個文件後就發一條特殊的IM消息。客戶端收到這個IM消息後，按照IM消息裏面url去HTTP server取語音文件和圖片文件。將HTTP server和IM server打通之後，可以做很多事情。但將這個兩個server合併在一塊並不是一個好事，不然騰訊也不會有2005年的戰略轉型了。從現在的情況來看，應用除了遊戲，都沒怎麼賺錢，現在能夠承載賺錢業務的還是以web爲主。IM不可以賺錢，但沒有卻是不行的，就像一個地方要致富，不修路是不行的道理一樣。

幫人推廣一下:  地推Wifi熱點