老金痛恨Twitter。
老金是我在德國讀書時的好基友，在國內時就酷愛文學創(chuàng)作。但他卻從未開通個博客什么的，堅持使用新浪“長微博”功能寫文章。用他的話說，這代表新銳文學的姿態(tài)。到了德國之后，老金發(fā)現人家老外不用微博，人家用Twitter。新銳的他自然要入鄉(xiāng)隨俗，可正準備舞文弄墨，卻發(fā)現Twitter里并沒有個東西叫“Long Twitter”，140個字符啥也干不了。于是老金憤而卸載Twitter，逢人便感慨西方文學這下是要徹底完了。
看著老金整天悶悶不樂，我便安慰他說什么長微博，不就是文字變圖片嘛。Twitter沒這東西，看小爺我的本事啊。我給你寫個App，名字就叫“大Twitter”，圖標我都給你設計好了。
然后我用了兩個晚上搞了個小工具，把大段文字轉成圖片，然后直接發(fā)到Twitter上。
可沒曾想，老金剛用了半天就找到我，說自己寫的東西不知道為什么全被打上了馬賽克，并信誓旦旦對“秦老師”發(fā)誓說自己沒寫什么大尺度的東西。我問他秦老師是誰?他說是印度著名詩人秦戈爾老師??！善良的我并沒有當面給他指出那位老師不姓秦這件事，只想著好好的圖片怎么會被打碼了呢？
我拿來一看，原來是老金實在憋了太久，這一次足足寫了8400多個字，生成的圖片尺寸過大，被雞賊的Twitter給壓縮了，于是便模糊得像打了碼一樣。心灰意冷的老金決定與Twitter恩斷義絕，連賬戶都注銷了。
雖然我也不怎么用Twitter，但作為一個程序員我對它還是很有興趣的。作為同類產品中的佼佼者，Twitter自然是有它的優(yōu)勢。其中比較有特色的一點就是其懶加載的機制。今天我們就通過Debug的方式來對其探究一番。
一些你需要知道的概念
時間軸（Time Line），Twitter中最最重要的部分。一條條的推文組合在一起，就成了頁面上中間那條長長的時間軸。
位（Position），一條推文的標識符，說白了就是推文的ID。新推文的Position比老推文的要大，所以我覺得Position很有可能代表著“這是Twitter有史以來的第xxx條推文”?？晌译S便找到的一個Position卻著實大得讓我懷疑自己的猜測。
千里之行，始于Network
首先我們在開發(fā)者工具的Network工具中截取一條當用戶滾動加載時發(fā)出的請求。結果發(fā)現它長下面這個樣子。
在這里我們可以發(fā)現幾個有意義的信息：
- max_position：翻遍Header信息以及請求參數，這是唯一一個跟所要請求的內容相關的東西。具體含義后面再講。
- has_more_items：顧名思義，服務器通過這個字段告訴前端是否還有更早的內容。
- items_html：格式化之后發(fā)現，這個部分就是我們所請求到的推文內容。顯然Twitter使用到的是后端渲染的技術，將推文內容渲染好直接發(fā)給前端進行展示。
- min_position：恰好對應了請求當中的max_position。
- new_latent_count：這一次所請求到的推文的條數。
深入探究
為了搞清楚這些信息到底是怎么回事，我們通過尋找請求的發(fā)起者來深入到代碼當中。原來Twitter在這里發(fā)送了一個XMLHttpRequest。無論是什么請求，總歸要有一個處理的方法，我們在Call Stack中層層向上追溯，然后找到了請求的定義位置。
這里我們進入到請求成功的方法中繼續(xù)探索。最終到達終點，items_html被添加到了時間軸當中。
那min_position和max_position呢？我們回到剛才定義請求的位置繼續(xù)向上追溯，找到了getOldItems的方法。當用戶在時間軸上向下滾動鼠標到最后時，就會調用到這個方法，而在其中會把上一次響應當中的min_position賦值給這一次請求當中的max_postion。
至此我們可以將整個Twitter的懶加載流程串接起來：
- 用戶向下滾動時間軸，發(fā)出請求，通知服務器“我已經把第A條看完啦，快讓我看更之前的內容”。
- 服務器返回從A再往前的20條內容，并告訴用戶“喏，現在發(fā)給你直到第B條的所有內容了，慢慢看吧”。
- 用戶再次看完這些內容，向下滾動時間軸，告訴服務器“到第B條的我也看完啦，B之前的你再發(fā)給我吧”。
每次不一定20條？
在研究的過程中，我發(fā)現了一個有趣的現象，就是new_latent_count絕大多數都是20，而偶爾會略小于20。由于前端請求中并不存在所要請求的條數，所以這個決策是在后端完成的。
起初我以為后端會根據需要即將響應的內容大小決定發(fā)多少條，可分析了一些例子之后發(fā)現有的時候響應明明很小，卻還是發(fā)了不到20條。所以我的猜測是后端這個神奇的算法可能會判斷返回的內容用戶大概會瀏覽多久，如果比較耗時，則少返回一些。例如如果推文中有長視頻，則判斷為閱讀耗時較長，可以少返回幾條。但這只是我瞎猜的，有知道其中原理的朋友可以留言告訴我，非常感謝。
Debug之痛
坦率講整個Debug過程花費了我很多時間，一方面是對于其代碼結構的不熟悉，另一方面是minify過的js代碼實在是讓人頭疼啊。所有的變量都長成abcd不說，到處都是用邏輯運算符寫的條件判斷語句，看得人口吐白沫。不過從學習的角度講，整個過程跑下來無論是debug能力還是代碼閱讀能力都會有所提升，推薦大家也試一試。
