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