他本和牛頓雙宿雙飛,卻因羞澀錯失物理第二魔王威名

  來源:我是科學家 iScientist

  有這麼一個流傳甚廣的段子,說流行歌手林俊傑要是不努力,就只能回家繼承百億家產。

  但實際上歷史上還有比這更誇張的真實故事。

  他的父親是德文郡公爵家族小兒子,母親是肯特公爵的女兒,可謂富甲一方,真·“不好好科研,就只能繼承家產成為首富“。

  然而,他卻靠“牛頓之後英國最偉大的科學家”為人所知,如果他要和人攀比,根本輪不到要拼家產的地步。

卡文迪許

  但這僅僅是我們主角卡文迪許故事的冰山一角,他作為一名偉大科學家的完全體還要等到百年後麥克斯韋的意外發現才被世人所了解。

  歐姆定律、庫倫定律、電勢、電場,這些成就都悶在了他的手稿里,如果全都公開發表,那卡文迪許可能就是繼牛頓之後又一個大魔王級的人物。

  但如果終究是如果,現實就是卡文迪許錯失了與偶像牛頓在物理課本里“雙宿雙飛”的機會。而這一切緣起於他的羞澀。

卡文迪許

  一場 18 世紀的英國頂尖學術聚會上,卡文迪許身上穿着的都還是一套起皺的褪色西裝,外加一頂卷邊帽,靦腆地站在角落。

  不了解的人也許難以想象,眼前這個的衣着樸素的人竟是個百萬富翁,還是個跨越化學與物理兩界的科學奇才。

  要說是奇才,和他同時代的科學家可不覺得。因為在他們眼裡,卡文迪許並沒有那麼偉大。但在後人看來,他隱藏起來的科研成果才令人驚詫。

卡文迪許

  100 多年後,麥克斯韋發現他遺留下 20 多捆從未面世的物理、化學研究手稿。

  庫侖定律、歐姆定律、介電常數等後人才提出的概念,赫然出現在筆記本上。一些時隔幾百年才提出的定律也早在 18 世紀就被卡文迪許證明了出來。

  他甚至被懷疑是擁有現代先進物理知識穿越者。

詹姆斯·克拉克·麥克斯韋

  麥克斯韋用了 5 年的時間把這些資料整理成書。而這些疑似穿越的產物,才消除了人們對於卡文迪許的誤解。

  原來卡文迪許的古怪性格早已在科學界名聲昭著。他生性羞澀,幾乎不與人交談,甚至連自己的研究成果也羞於發表。科學怪人的一生只追求自己科研的爽快,也讓世人對他的景仰晚了 100 年。

  人們給他貼上不合群、內向、沉默寡言、古怪等標籤。童年的成長曆程在他身上刻下了這一個個深刻的烙印。

卡文迪許

  卡文迪許出生在一個英國貴族家庭,兩歲時母親就去世了。身為勛爵的科學家父親一手帶大了他和弟弟,卻很少有時間給予陪伴。

  作為彌補,父親實驗室里各種科學儀器成了卡文迪許的玩具。而忙碌的父親有時不得不帶上他出席倫敦皇家學會等科學家聚會的場合。

卡文迪許家裡的餐廳

  卡文迪許的科學啟蒙也就由此開始。童年的經歷開拓了他的科學視野,所以他從小就有了不錯的科學基礎。

  但硬邦邦的儀器取代了親情的關懷,卡文迪許幾乎沒有機會能夠與人交流。這讓他性格變得內向、沉默寡言,甚至疑似患有自閉症。

  他幾乎完全喪失了社交能力,但同時他也獲得了強大的思考能力。

卡文迪許

  這樣古怪的性格也讓卡文迪許越發沉迷於科研工作。他 18 歲考上了劍橋大學,學習了四年數學。

  但就在即將拿到畢業學位的前夕,他卻退學了。理由是對最後的考試中,關於神學知識的測試部分不滿。於是他寧願捨棄畢業學位而任性地退學。

  出於家境的優越,放棄了學位的卡文迪許並沒有因此而失去學習機會。這反而讓他不止局限於學校的數學教學,他又學習了深感興趣的物理和化學。

  在離開劍橋后不久,他追隨父親的影子,加入了皇家學會。融入科學界的圈子中,他才找到自己的價值,在深耕真理中做出影響世界的偉大貢獻。

英國皇家學會

  空氣的主要成分是氧氣、氮氣和二氧化碳。人類直到 18 世紀才發現,原來空氣的成分不止這些。

  卡文迪許在研究中發現了一種十分微量的惰性氣體。

  他用電火花消耗空氣中的氮氣時,出現了一些小氣泡。

  奇怪的是,無論實驗重複多少遍,最後都還會剩餘一些小氣泡不能被氧化。無論加入什麼試劑,這種氣泡都沒有消失。

  於是卡文迪許得出結論,空氣中除了氮氣和氧氣之外,還存在一種“濁氣”。這種“濁氣”非常穩定,而且總量不超過全部空氣的1/120。

  但這種氣體具體是什麼成分,卡文迪許就沒有繼續研究下去了。直到一百多年後,才有科學家依據卡文迪許當初的實驗,揭開了“濁氣”的真面目。

  物理學家瑞利重複卡文迪許當年的實驗得到小氣泡,測定出這種氣體的密度比氮氣大。

  化學家萊姆塞重新設計了一個新實驗,用分光鏡檢查后給其中一種新元素命了名。

  這是化學性質極其穩定的稀有氣體中的一種,氬氣。

  而位於元素周期表第一位的氫,也是在卡文迪許的研究下被人們認知。當時科學命名法還沒有誕生,普遍常見的氣體也只有俗名。

  比如氧氣在當時被稱為“消炎氣體”。而一種“易燃氣體”也引發了許多科學家的火熱研究。

卡文迪許也摻了一腳,還難得向皇家學會提交的一篇研究報告《人造空氣》。

  他用鐵、鋅等活潑金屬和稀硫酸反應,發現反應會產生一種氣體。這種氣體和空氣混合後點燃會爆炸,因此被叫做“易燃氣體”。它和氧氣相互反應還能生成液態的水。

  在當時,人們還以為水是一種元素,不知道這是氫和氧的化合物。

  卡文迪許的實驗其實就是現代高中化學中都學過的置換反應。而生成的氣體就是氫氣。

  現在人們對於氫氣的性質已經非常熟悉。但在那個時候,繁多的反應卻像一扇扇從未打開的大門,吸引了天生好奇心強烈的科學家們。

氫氣球爆炸

  卡文迪許跨域廣泛,除了化學之外,他對物理、天文、氣象等科學領域也有所研究。其中牛頓自然哲學觀點就對他產生了深遠的影響。

  地球有多重?自從牛頓發現萬有引力定律之後,這個問題似乎已經攻破在望。解決問題的關鍵在於計算出“萬有引力常數”。

  理論上來說,可以直接測量地面上兩個已知質量物體之間的引力求得。

  但實際上這個引力數值十分微小,測量起來非常困難。

  許多科學家為此設計了各種奇怪的模型進行計算,但始終難以攻克。

  在牛頓的理論影響下,卡文迪許從十幾歲就開始研究這個問題。

卡文迪許設計的扭稱模型

  他在劍橋大學的學習中請教到了一種巧妙的“扭稱”方法。於是他自己也設計了一個能觀察到微小力變化的模型。

  他在一根細長桿的兩端分別裝上一個小鉛球,再用石英絲橫吊著鉛球。

  如果用兩個大一些的鉛球靠近,由於產生引力,小鉛球就會發生擺動。

  而石英絲也會跟隨扭動,這時只要測量出石英絲的扭轉程度,就可以求出引力。

  為了排除干擾,他專門在一間屋子里進行實驗,還用價格昂貴的望遠鏡在屋子外觀察。

  但是當時實驗條件差,他只能通過肉眼觀察判斷石英絲的扭轉程度。

  然而引力的作用程度實在是微乎其微,眼看成功近在眼前,實驗結果卻無從得到。卡文迪許的實驗只好卡在半途。

  直到一天,他在路上看到小孩在玩鏡子反射太陽光的遊戲。小小的太陽光反射點映照在地上到處跳動。

  這讓卡文迪許大受啟發。他立馬回到實驗室改進了自己的扭稱裝置。

  他把在裝置上增加了一面鏡子,用反射到刻度線上的光線度量石英絲的扭動。這樣一來,石英絲的靈敏度大大提高,再通過簡單的力的計算就得出了引力的大小。

  這個堪稱上帝之手的扭稱實驗掂量起地球的質量,牛頓或許也因此安息了。

  5. 976×10^24 千克,也就是大約 60 萬億億噸。卡文迪許花費了四十多年的時間才得出這一個數值,最終終結了這個萬有引力難題。他被譽為“第一個稱量地球的人”。

  以上大體就是當時人們能了解到的卡文迪許成就了,至於為什麼將其他發現藏着掖着,只要跟他有過些許交流就能理解。

  孤僻的性格讓卡文迪許全心專註於科研實驗。濃厚的學術氛圍是對他不善言辭性格的極大寬容。他從來不主動結交朋友,對異性更是越發羞澀。

  甚至在家裡,大部分時候和女傭都是靠傳紙條來進行交流的。所以他終身都沒有結婚。

  而作為大富豪,卡文迪許對於錢財和交際卻完全沒有概念。

  有一次,一位工匠為他粉刷房間,過後他忘了給工匠付工錢。好友是在看不下去,告訴了他這件事。

  卡文迪許大吃一驚,連忙寫了一張兩萬英鎊的支票,還詢問夠不夠。這在當時幾乎是工匠十年的薪酬了,而他卻毫不在意。

  對於社交活動,卡文迪許是本能地抗拒的,除了每周一次的皇家學會聚會。而在宴會上,他也只是躲在角落默默地聆聽其他科學家的發言。

  在這裏他不需要說話,卻能收穫到最前沿的科學觀點和想法。但別人卻很難從他口中得知他深邃的思想和正在進行的研究。

  一位比較了解他的友人調侃,要想聽到卡文迪許高明的見解,就不能再宴會上和他有任何交流,否則他會羞澀地立馬逃跑。

  人們大都只知道卡文迪許稱量地球的成就,但他最成功的預言還埋藏在他的手稿中。他對電的研究甚至直接證明了牛頓對未來自然科學的設想。

  他原本打算用這篇文章當做牛頓提出萬有引力的《原理》中的續篇。但卻因為他羞於發表,而失去了與牛頓同享榮譽的機會。

曾經在皇家學會上發言的牛頓

  另外,他最早證明了電荷之間的相互作用力應該與距離的平方呈反比關係。

  在 1772-1773 年間,他作了個雙層同心球實驗,第一次精確測出電作用力與距離的關係,指數偏差不超過 0.02。

  後來法國人庫倫通過實驗驗證了他的發現,從此關於電荷間的受力規律被稱作庫倫定律。

夏爾·奧古斯丁·庫侖

  他還第一個提出了電勢的概念,指出了電勢與電流的正比關係。

  由於當時沒有測定電流的儀器,卡文迪許就把自己的身體當做實驗儀器。根據身體的麻木感覺來估計電流的強弱,發現了導體兩端的電勢(差)與通過它的電流成正比。

  這也就是我們物理課本電學章節中的歐姆定律。

格奧爾格·西蒙·歐姆

  後來麥克斯韋通過整理,才出版了卡文迪許手稿中關於電學的研究。而通過他本人的發表和後人的搜尋,才挖掘出卡文迪許冰山一角的研究成果。除了手稿之外,他還有多少不為人知的研究,我們也就不得而知了。

骨子里的自閉也鑄造了卡文迪許孤獨的一生。

  直到將死之際,他還刻意把傭人打發走,讓她在某個時間點再回來。

  而回來時發現,卡文迪許已經死在了床上。極度的羞澀讓他連死亡都不想別人看見。

  默默無聞的卡文迪許為科學事業做出了偉大貢獻,一生中卻沒有得過什麼獎。

  後來,麥克斯韋為紀念這位隱蔽的偉大科學家,建立了以他命名的實驗室。迄今為止,卡文迪許實驗室已經培養出 20 多位諾貝爾物理獎的獲得者。

  原本用沉默掩蓋科研成果,他捨棄了與牛頓齊名物理學史的機會。但他在角落裡散發出來的萬丈光芒卻無法收斂。假設卡文迪許的手稿當初沒有被藏着,我們現在課本里的可能就不止有牛頓力學三定律,或許還有卡文迪許電學定理一、定理二……

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

標準庫bufio個人詳解

本文是我有通俗的語言寫的如果有誤請指出。

先看bufio官方文檔

https://studygolang.com/pkgdoc文檔地址

 

 主要分三部分Reader、Writer、Scanner

分別是讀數據、寫數據和掃描器三種數據類型的相關操作 這個掃描後面會詳細說我開始也沒弄明白其實很簡單。

 

Reader

func 

func NewReaderSize(rd ., size ) *

NewReaderSize創建一個具有最少有size尺寸的緩衝、從r讀取的*Reader。如果參數r已經是一個具有足夠大緩衝的* Reader類型值,會返回r。

 

 

 解釋:看官方解釋這個方法可能不太容易懂,這個意思就是就是你可以給*Reader自定義一個size大小的緩衝區,*Reader每次從底層io.Reader(也就是你那個文件或者流)中預讀size大小的數據到緩衝區中(可能讀不滿),然後你每次讀數據實際是從這個緩衝區中拿數據。

 

 下面是NewReaderSize源碼

func NewReaderSize(rd io.Reader, size int) *Reader {
    // Is it already a Reader?
    b, ok := rd.(*Reader)
    if ok && len(b.buf) >= size {
        return b
    }
    if size < minReadBufferSize { //minReadBufferSize==16
        size = minReadBufferSize
    }
    r := new(Reader)
    r.reset(make([]byte, size), rd)
    return r
}

  r.reset 初始化了一個*Reader 返回大小是size。

func 

func NewReader(rd .) *

NewReader創建一個具有默認大小緩衝、從r讀取的*Reader。

解釋:那這個NewReader就很好解釋了 和NewReaderSize基本一樣就是緩衝區大小是默認設置好的

func (*Reader) 

func (b *) Peek(n ) ([], )

解釋:Peek就是返回緩存的一個切片,該切片引用緩存中的前N個字節的數據,如果n大於總大小,則返回能讀到的字節數的數據。

func (*Reader) 

func (b *) Read(p []) (n , err )

Read讀取數據寫入p。本方法返回寫入p的字節數。本方法一次調用最多會調用下層Reader接口一次Read方法,因此返回值n可能小於len(p)。讀取到達結尾時,返回值n將為0而err將為io.EOF。

解釋:如果緩存不為空則直接從緩存中讀數據不會從底層io.Reader讀,如果緩存為空len(p)>緩存大小,則直接從底層io.Reader讀數據到p。

如果len(p)<緩存大小,則先從底層io.Reader中讀數據到緩存再到p。

 

主要就這幾個 還有幾個文檔寫的都很清楚易懂我就不多寫了。

Writer類型的方法和Reader類型的方法差不多也很易懂主要就一個Flush要注意。

func (*Writer) 

func (b *) Flush() 

Flush方法將緩衝中的數據寫入下層的io.Writer接口。

和Reader是倒過來的,Writer每次寫數據是先寫入緩衝區的,進程緩衝區填滿后,通過進程緩衝寫入到內核緩衝再寫入到磁盤,使用Flush就不等填滿直接走寫入流程了,保證你的數據及時寫入文件。

 

 

 

 解釋:scanner類型掃描器 官方的說法很複雜,我也沒太看懂找了很多資料,其實就是你在數據傳輸的時候時候使用“分隔符”,scanner類型可以通過分隔符逐個迭代你的數據。

上面4個函數func Scan……  就是分隔符的判斷函數這4個是給你預設好的,你也可以按照自己的需求改寫。

怎麼改寫呢,看下面

func (*Scanner) 

func (s *) Split(split )

這個Split方法就是設置你這個scanner的用哪個SplitFunc類型的函數

在看下面這個SpliFunc類型的函數簽名

type SplitFunc func(data [], atEOF ) (advance , token [], err )

照着這個格式寫一個不就得了么,當然具體寫法給出了但是你不會?沒關係咱看一下官方是咋寫的。

https://github.com/golang/go/blob/master/src/bufio/scan.go?name=release#57官方源碼地址

func ScanLines(data []byte, atEOF bool) (advance int, token []byte, err error) {
	if atEOF && len(data) == 0 {
		return 0, nil, nil
	}
	if i := bytes.IndexByte(data, '\n'); i >= 0 {
		// We have a full newline-terminated line.
		return i + 1, dropCR(data[0:i]), nil
	}
	// If we're at EOF, we have a final, non-terminated line. Return it.
	if atEOF {
		return len(data), dropCR(data), nil
	}
	// Request more data.
	return 0, nil, nil
}

   

看bytes.IndexByte(data, ‘\n’);這段不就是在找行尾嘛 比如你想改成以“;”為分隔符的就改成bytes.IndexByte(data, ‘;’);不就得了么

func main(){
    scanner:=bufio.NewScanner(
        strings.NewReader("abcdefg\nhigklmn"),
    )
    scanner.Split(ScanLines) //這裏可以隨意選擇用哪個函數也可以自定義,可以不指定默認為\n做分隔符
  for scanner.Scan(){
    fmt.Println(scanner.Text())
  }
}

  

到此為止拉~

 

 

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

Android DecorView 與 Activity 綁定原理分析

一年多以前,曾經以為自己對 View 的添加显示邏輯已經有所了解了,事後發現也只是懂了些皮毛而已。經過一年多的實戰,Android 和 Java 基礎都有了提升,是時候該去看看 DecorView 的添加显示。

概論

Android 中 Activity 是作為應用程序的載體存在,代表着一個完整的用戶界面,提供了一個窗口來繪製各種視圖,當 Activity 啟動時,我們會通過 setContentView 方法來設置一個內容視圖,這個內容視圖就是用戶看到的界面。那麼 View 和 activity 是如何關聯在一起的呢 ?

 上圖是 View 和 Activity 之間的關係。先解釋圖中一些類的作用以及相關關係:

  • Activity : 對於每一個 activity 都會有擁有一個 PhoneWindow。

  • PhoneWindow :該類繼承於 Window 類,是 Window 類的具體實現,即我們可以通過該類具體去繪製窗口。並且,該類內部包含了一個 DecorView 對象,該 DectorView 對象是所有應用窗口的根 View。
  • DecorView 是一個應用窗口的根容器,它本質上是一個 FrameLayout。DecorView 有唯一一個子 View,它是一個垂直 LinearLayout,包含兩個子元素,一個是 TitleView( ActionBar 的容器),另一個是 ContentView(窗口內容的容器)。

  • ContentView :是一個 FrameLayout(android.R.id.content),我們平常用的 setContentView 就是設置它的子 View 。

  • WindowManager : 是一個接口,裏面常用的方法有:添加View,更新View和刪除View。主要是用來管理 Window 的。WindowManager 具體的實現類是WindowManagerImpl。最終,WindowManagerImpl 會將業務交給 WindowManagerGlobal 來處理。
  • WindowManagerService (WMS) : 負責管理各 app 窗口的創建,更新,刪除, 显示順序。運行在 system_server 進程。

ViewRootImpl :擁有 DecorView 的實例,通過該實例來控制 DecorView 繪製。ViewRootImpl 的一個內部類 W,實現了 IWindow 接口,IWindow 接口是供 WMS 使用的,WSM 通過調用 IWindow 一些方法,通過 Binder 通信的方式,最後執行到了 W 中對應的方法中。同樣的,ViewRootImpl 通過 IWindowSession 來調用 WMS 的 Session 一些方法。Session 類繼承自 IWindowSession.Stub,每一個應用進程都有一個唯一的 Session 對象與 WMS 通信。

DecorView 的創建 

先從 Mainactivity 中的代碼看起,首先是調用了 setContentView;

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
}

該方法是父類 AppCompatActivity 的方法,最終會調用 AppCompatDelegateImpl 的 setContentView 方法:

// AppCompatDelegateImpl  
public void setContentView(int resId) { this.ensureSubDecor(); ViewGroup contentParent = (ViewGroup)this.mSubDecor.findViewById(16908290); contentParent.removeAllViews(); LayoutInflater.from(this.mContext).inflate(resId, contentParent); this.mOriginalWindowCallback.onContentChanged(); }

ensureSubDecor 從字面理解就是創建 subDecorView,這個是根據主題來創建的,下文也會講到。創建完以後,從中獲取 contentParent,再將從 activity 傳入的 id xml 布局添加到裏面。不過大家注意的是,在添加之前先調用 removeAllViews() 方法,確保沒有其他子 View 的干擾。

    private void ensureSubDecor() {
        if (!this.mSubDecorInstalled) {
            this.mSubDecor = this.createSubDecor(); 
            ......
        }
        ......
    }        

 最終會調用 createSubDecor() ,來看看裏面的具體代碼邏輯:

 private ViewGroup createSubDecor() {
        // 1、獲取主題參數,進行一些設置,包括標題,actionbar 等 
        TypedArray a = this.mContext.obtainStyledAttributes(styleable.AppCompatTheme);
        if (!a.hasValue(styleable.AppCompatTheme_windowActionBar)) {
            a.recycle();
            throw new IllegalStateException("You need to use a Theme.AppCompat theme (or descendant) with this activity.");
        } else {
            if (a.getBoolean(styleable.AppCompatTheme_windowNoTitle, false)) {
                this.requestWindowFeature(1);
            } else if (a.getBoolean(styleable.AppCompatTheme_windowActionBar, false)) {
                this.requestWindowFeature(108);
            }

            if (a.getBoolean(styleable.AppCompatTheme_windowActionBarOverlay, false)) {
                this.requestWindowFeature(109);
            }

            if (a.getBoolean(styleable.AppCompatTheme_windowActionModeOverlay, false)) {
                this.requestWindowFeature(10);
            }

            this.mIsFloating = a.getBoolean(styleable.AppCompatTheme_android_windowIsFloating, false);
            a.recycle();
            // 2、確保優先初始化 DecorView
            this.mWindow.getDecorView();
            LayoutInflater inflater = LayoutInflater.from(this.mContext);
            ViewGroup subDecor = null;
            // 3、根據不同的設置來對 subDecor 進行初始化
            if (!this.mWindowNoTitle) {
                if (this.mIsFloating) {
                    subDecor = (ViewGroup)inflater.inflate(layout.abc_dialog_title_material, (ViewGroup)null);
                    this.mHasActionBar = this.mOverlayActionBar = false;
                } else if (this.mHasActionBar) {
                    TypedValue outValue = new TypedValue();
                    this.mContext.getTheme().resolveAttribute(attr.actionBarTheme, outValue, true);
                    Object themedContext;
                    if (outValue.resourceId != 0) {
                        themedContext = new ContextThemeWrapper(this.mContext, outValue.resourceId);
                    } else {
                        themedContext = this.mContext;
                    }

                    subDecor = (ViewGroup)LayoutInflater.from((Context)themedContext).inflate(layout.abc_screen_toolbar, (ViewGroup)null);
                    this.mDecorContentParent = (DecorContentParent)subDecor.findViewById(id.decor_content_parent);
                    this.mDecorContentParent.setWindowCallback(this.getWindowCallback());
                    if (this.mOverlayActionBar) {
                        this.mDecorContentParent.initFeature(109);
                    }

                    if (this.mFeatureProgress) {
                        this.mDecorContentParent.initFeature(2);
                    }

                    if (this.mFeatureIndeterminateProgress) {
                        this.mDecorContentParent.initFeature(5);
                    }
                }
            } else {
                if (this.mOverlayActionMode) {
                    subDecor = (ViewGroup)inflater.inflate(layout.abc_screen_simple_overlay_action_mode, (ViewGroup)null);
                } else {
                    subDecor = (ViewGroup)inflater.inflate(layout.abc_screen_simple, (ViewGroup)null);
                }

                if (VERSION.SDK_INT >= 21) {
                    ViewCompat.setOnApplyWindowInsetsListener(subDecor, new OnApplyWindowInsetsListener() {
                        public WindowInsetsCompat onApplyWindowInsets(View v, WindowInsetsCompat insets) {
                            int top = insets.getSystemWindowInsetTop();
                            int newTop = AppCompatDelegateImpl.this.updateStatusGuard(top);
                            if (top != newTop) {
                                insets = insets.replaceSystemWindowInsets(insets.getSystemWindowInsetLeft(), newTop, insets.getSystemWindowInsetRight(), insets.getSystemWindowInsetBottom());
                            }

                            return ViewCompat.onApplyWindowInsets(v, insets);
                        }
                    });
                } else {
                    ((FitWindowsViewGroup)subDecor).setOnFitSystemWindowsListener(new OnFitSystemWindowsListener() {
                        public void onFitSystemWindows(Rect insets) {
                            insets.top = AppCompatDelegateImpl.this.updateStatusGuard(insets.top);
                        }
                    });
                }
            }

            if (subDecor == null) {
                throw new IllegalArgumentException("AppCompat does not support the current theme features: { windowActionBar: " + this.mHasActionBar + ", windowActionBarOverlay: " + this.mOverlayActionBar + ", android:windowIsFloating: " + this.mIsFloating + ", windowActionModeOverlay: " + this.mOverlayActionMode + ", windowNoTitle: " + this.mWindowNoTitle + " }");
            } else {
                if (this.mDecorContentParent == null) {
                    this.mTitleView = (TextView)subDecor.findViewById(id.title);
                }

                ViewUtils.makeOptionalFitsSystemWindows(subDecor);
                ContentFrameLayout contentView = (ContentFrameLayout)subDecor.findViewById(id.action_bar_activity_content);
                ViewGroup windowContentView = (ViewGroup)this.mWindow.findViewById(16908290);
                if (windowContentView != null) {
                    while(windowContentView.getChildCount() > 0) {
                        View child = windowContentView.getChildAt(0);
                        windowContentView.removeViewAt(0);
                        contentView.addView(child);
                    }

                    windowContentView.setId(-1);
                    contentView.setId(16908290);
                    if (windowContentView instanceof FrameLayout) {
                        ((FrameLayout)windowContentView).setForeground((Drawable)null);
                    }
                }
                // 將 subDecor 添加到 DecorView 中
                this.mWindow.setContentView(subDecor);
                contentView.setAttachListener(new OnAttachListener() {
                    public void onAttachedFromWindow() {
                    }

                    public void onDetachedFromWindow() {
                        AppCompatDelegateImpl.this.dismissPopups();
                    }
                });
                return subDecor;
            }
        }
    }
                    

上面的代碼總結來說就是在做一件事,就是創建 subDecor。攤開來說具體如下:

1、根據用戶選擇的主題來設置一些显示特性,包括標題,actionbar 等。

2、根據不同特性來初始化 subDecor;對 subDecor 內部的子 View 進行初始化。

3、最後添加到 DecorView中。

添加的具體代碼如下:此處是通過調用 

 // AppCompatDelegateImpl   this.mWindow.getDecorView();

 // phoneWindow    public final View getDecorView() {
        if (mDecor == null || mForceDecorInstall) {
            installDecor();
        }
        return mDecor;
    }
 

private void installDecor() {
        mForceDecorInstall = false;
        if (mDecor == null) {
 // 生成 DecorView             mDecor = generateDecor(-1);
            mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);
            mDecor.setIsRootNamespace(true);
            if (!mInvalidatePanelMenuPosted && mInvalidatePanelMenuFeatures != 0) {
                mDecor.postOnAnimation(mInvalidatePanelMenuRunnable);
            }
        } else {
 // 這樣 DecorView 就持有了window             mDecor.setWindow(this);
        }
      ......
}


   protected DecorView generateDecor(int featureId) {
        // System process doesn't have application context and in that case we need to directly use // the context we have. Otherwise we want the application context, so we don't cling to the // activity.
        Context context;
        if (mUseDecorContext) {
            Context applicationContext = getContext().getApplicationContext();
            if (applicationContext == null) {
                context = getContext();
            } else {
                context = new DecorContext(applicationContext, getContext());
                if (mTheme != -1) {
                    context.setTheme(mTheme);
                }
            }
        } else {
            context = getContext();
        }
        return new DecorView(context, featureId, this, getAttributes());
   }

到此,DecorView 的創建就講完了。可是我們似乎並沒有看到 DecorView 是被添加的,什麼時候對用戶可見的。

 WindowManager

View 創建完以後,那 Decorview 是怎麼添加到屏幕中去的呢?當然是 WindowManager 呢,那麼是如何將 View 傳到 WindowManager 中呢。

看 ActivityThread 中的 handleResumeActivity 方法:

// ActivityThread
public
void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward, String reason) { ...... final int forwardBit = isForward ? WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION : 0; // If the window hasn't yet been added to the window manager, // and this guy didn't finish itself or start another activity, // then go ahead and add the window. boolean willBeVisible = !a.mStartedActivity; if (!willBeVisible) { try { willBeVisible = ActivityManager.getService().willActivityBeVisible( a.getActivityToken()); } catch (RemoteException e) { throw e.rethrowFromSystemServer(); } } if (r.window == null && !a.mFinished && willBeVisible) { r.window = r.activity.getWindow(); View decor = r.window.getDecorView(); decor.setVisibility(View.INVISIBLE); ViewManager wm = a.getWindowManager(); WindowManager.LayoutParams l = r.window.getAttributes(); a.mDecor = decor; l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION; l.softInputMode |= forwardBit; ...... if (a.mVisibleFromClient) { if (!a.mWindowAdded) { a.mWindowAdded = true; wm.addView(decor, l); } else { // The activity will get a callback for this {@link LayoutParams} change // earlier. However, at that time the decor will not be set (this is set // in this method), so no action will be taken. This call ensures the // callback occurs with the decor set. a.onWindowAttributesChanged(l); } } // If the window has already been added, but during resume // we started another activity, then don't yet make the // window visible. } else if (!willBeVisible) { if (localLOGV) Slog.v(TAG, "Launch " + r + " mStartedActivity set"); r.hideForNow = true; } // Get rid of anything left hanging around. cleanUpPendingRemoveWindows(r, false /* force */); // The window is now visible if it has been added, we are not // simply finishing, and we are not starting another activity. if (!r.activity.mFinished && willBeVisible && r.activity.mDecor != null && !r.hideForNow) { if (r.newConfig != null) { performConfigurationChangedForActivity(r, r.newConfig); if (DEBUG_CONFIGURATION) { Slog.v(TAG, "Resuming activity " + r.activityInfo.name + " with newConfig " + r.activity.mCurrentConfig); } r.newConfig = null; } if (localLOGV) Slog.v(TAG, "Resuming " + r + " with isForward=" + isForward); WindowManager.LayoutParams l = r.window.getAttributes(); if ((l.softInputMode & WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION) != forwardBit) { l.softInputMode = (l.softInputMode & (~WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION)) | forwardBit; if (r.activity.mVisibleFromClient) { ViewManager wm = a.getWindowManager(); View decor = r.window.getDecorView(); wm.updateViewLayout(decor, l); } } r.activity.mVisibleFromServer = true; mNumVisibleActivities++; if (r.activity.mVisibleFromClient) {           // 這裏也會調用addview r.activity.makeVisible(); } } r.nextIdle = mNewActivities; mNewActivities = r; if (localLOGV) Slog.v(TAG, "Scheduling idle handler for " + r); Looper.myQueue().addIdleHandler(new Idler()); }

上面的代碼主要做了以下幾件事:

1、獲取到 DecorView,設置不可見,然後通過 wm.addView(decor, l) 將 view 添加到 WindowManager;

2、在某些情況下,比如此時點擊了輸入框調起了鍵盤,就會調用 wm.updateViewLayout(decor, l) 來更新 View 的布局。

3、這些做完以後,會調用 activity 的  makeVisible ,讓視圖可見。如果此時 DecorView 沒有添加到 WindowManager,那麼會添加。 

// Activity
void makeVisible() { if (!mWindowAdded) { ViewManager wm = getWindowManager(); wm.addView(mDecor, getWindow().getAttributes()); mWindowAdded = true; } mDecor.setVisibility(View.VISIBLE); }

 接下來,看下 addview 的邏輯。 WindowManager 的實現類是 WindowManagerImpl,而它則是通過 WindowManagerGlobal 代理實現 addView 的,我們看下 addView 的方法:

// WindowManagerGlobal  
 public void addView(View view, ViewGroup.LayoutParams params,
            Display display, Window parentWindow) {
           // ......
    
            root = new ViewRootImpl(view.getContext(), display);
            view.setLayoutParams(wparams);

            mViews.add(view);
            mRoots.add(root);
            mParams.add(wparams);
           // do this last because it fires off messages to start doing things
            try {
                root.setView(view, wparams, panelParentView);
            } catch (RuntimeException e) {
                // BadTokenException or InvalidDisplayException, clean up.
                if (index >= 0) {
                    removeViewLocked(index, true);
                }
                throw e;
            } 
}

在這裏,實例化了 ViewRootImpl 。同時調用 ViewRootImpl 的 setView 方法來持有了 DecorView。此外這裏還保存了 DecorView ,Params,以及 ViewRootImpl 的實例。

現在我們終於知道為啥 View 是在 OnResume 的時候可見的呢。

 ViewRootImpl

實際上,View 的繪製是由 ViewRootImpl 來負責的。每個應用程序窗口的 DecorView 都有一個與之關聯的 ViewRootImpl 對象,這種關聯關係是由 WindowManager 來維護的。

先看 ViewRootImpl 的 setView 方法,該方法很長,我們將一些不重要的點註釋掉:

   /**
     * We have one child
     */
    public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
        synchronized (this) {
            if (mView == null) {
                mView = view;
                ......
               
                mAdded = true;
                int res; /* = WindowManagerImpl.ADD_OKAY; */

                // Schedule the first layout -before- adding to the window
                // manager, to make sure we do the relayout before receiving
                // any other events from the system.

                requestLayout();
                ......
            }
        }
    }

這裏先將 mView 保存了 DecorView 的實例,然後調用 requestLayout() 方法,以完成應用程序用戶界面的初次布局。

 public void requestLayout() {
        if (!mHandlingLayoutInLayoutRequest) {
            checkThread();
            mLayoutRequested = true;
            scheduleTraversals();
        }
    }

因為是 UI 繪製,所以一定要確保是在主線程進行的,checkThread 主要是做一個校驗。接着調用 scheduleTraversals 開始計劃繪製了。

void scheduleTraversals() {
        if (!mTraversalScheduled) {
            mTraversalScheduled = true;
            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
            if (!mUnbufferedInputDispatch) {
                scheduleConsumeBatchedInput();
            }
            notifyRendererOfFramePending();
            pokeDrawLockIfNeeded();
        }
    }

這裏主要關注兩點:

mTraversalBarrier : Handler 的同步屏障。它的作用是可以攔截 Looper 對同步消息的獲取和分發,加入同步屏障之後,Looper 只會獲取和處理異步消息,如果沒有異步消息那麼就會進入阻塞狀態。也就是說,對 View 繪製渲染的處理操作可以優先處理(設置為異步消息)。

mChoreographer: 編舞者。統一動畫、輸入和繪製時機。也是這章需要重點分析的內容。

mTraversalRunnable :TraversalRunnable 的實例,是一個Runnable,最終肯定會調用其 run 方法:

final class TraversalRunnable implements Runnable {
        @Override
        public void run() {
            doTraversal();
        }
    }

doTraversal,如其名,開始繪製了,該方法內部最終會調用 performTraversals 進行繪製。

  void doTraversal() {
        if (mTraversalScheduled) {
            mTraversalScheduled = false;
            mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

            if (mProfile) {
                Debug.startMethodTracing("ViewAncestor");
            }

            performTraversals();

            if (mProfile) {
                Debug.stopMethodTracing();
                mProfile = false;
            }
        }
    }

到此,DecorView 與 activity 之間的綁定關係就講完了,下一章,將會介紹 performTraversals 所做的事情,也就是 View 繪製流程。 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

豐田衝刺燃料電池車,傳產能將擴增至 10 倍以上

日刊工業新聞 3 日,豐田汽車(Toyota)計劃於 2020 年將燃料電池車(FCV)月產能提高至 3,000 台,將達現行的 10 倍以上水準。豐田計劃在 2020 年下半推出 FCV 車「MIRAI」的次代車款。

據報導,豐田目前利用元町工廠的專用產線生產「MIRAI」,年產能約 3,000 台,依此換算月產能相當於 250 台左右。

2018 年 MIRAI 全球銷售量約 2,400 台,而豐田目標在 2020 年以後將 FCV 年銷售量提高至 3 萬台以上水準。

截至台灣時間 3 日上午 10 點 21 分為止,豐田下跌 0.84%。

豐田於 2018 年 5 月 24 日宣布,為了因應計劃在 2020 年以後將 FCV 全球年銷售量提高至 3 萬台以上水準的目標,決議將增產 FCV 關鍵零件,計劃在愛知縣豐田市的本社工廠廠區內興建新廠房、增產燃料電池堆(Fuel Cell stack),且也計劃在愛知縣三好市的下山工廠內增設用來儲存氫燃料的高壓氫氣槽專用產線。上述新廠預計於 2020 年左右啟用。

(本文內容由 授權使用。首圖來源: CC BY 2.0)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

6000年前一隻狗的癌症,如何在今天席捲全球?

  即使睿智如人類,強壯如猛獸,也無法躲過疾病的侵襲,癌症就是其中尤為嚴重的一種。

  時至今日,我們仍舊深陷於與癌症抗爭的泥潭中苦苦掙扎。目前已有的治療手段有手術、化學療法、放射線療法、癌症疫苗、免疫細胞療法等。但很遺憾,目前除了針對非實體瘤的治療方法效果卓著接近曙光,對大多數癌症仍舊是無計可施。

  究其原因,仍是我們對癌症不夠了解,或者說是無從下手。以人類短短百餘年的壽命極限來抗衡與進化同生的癌症,實在是有些蚍蜉撼樹的意味。癌症的偶然發生,以單一生命個體為單位進行研究,百餘年的度量難以拼接成完整的畫面。

  而今,一種至今已存在了 6000 余年的癌症為我們的研究提供了絕佳的條件。


來源:Ernesto del Aguila III, NHGRI

  CTVT(canine transmissible venereal tumor),即犬類傳染性性病腫瘤。這種癌症最早起源於中亞地區,來自於某條“始祖犬”的生殖器細胞基因突變。隨後,伴隨犬類的交配,生生不息,如今已經幾乎遍布世界的每個角落,至今已有約 6000 年。

  來自 40 多個國家的聯合團隊,通過對來自 43 個國家的 546 個 CTVT 腫瘤樣本和 495 個 CTVT 腫瘤宿主的正常樣本進行了外顯子測序,構建出時間系統發育譜系。同時研究者們對 CTVT 的癌症突變特徵進行了分析,並由此識別出 CTVT 的高度環境特異性突變過程,以及中性遺傳漂變是癌症長期演化的主要特徵,相關的研究細節發表在 Science 雜誌上。

  對 CTVT 的研究,為人類在數千年的時間單位上更好地認識癌症進化上提供了絕佳的機會,這也將是人類未來戰勝癌症的重要參考。

  一、對癌症的認識

  癌症,又名惡性腫瘤,是指細胞不正常的增生,且這些增生的細胞可能隨淋巴或血液系統攻佔身體的每個角落。千萬年間,人們始終沒有放棄與癌症的抗爭,卻屢屢折戟沉沙。因此,癌症在很長時間內都被認為是無法治癒的疾病,神靈的詛咒。

  在人類身上,目前已知的癌症已經超過 100 種。2015 年,約有 880 萬人死於癌症,這幾乎佔到了全球死亡人數的六分之一,其中的 70% 發生在低收入和中等收入國家。

  癌症並非一種源於工業化的人造疾病,而是與演化如影隨形,共同塑造了生命。癌症的存在歷史可以追溯至上萬年,但直到近百年間,人們才開始真正地了解癌症。

  18 世紀,醫生藉助解剖刀開始了與癌症的正式交鋒——腫瘤切除治療。但癌症的複發與轉移,成為橫亘在醫生們面前的又一條門檻。

  那麼,究竟什麼才是癌症背後真正的力量呢?答案是基因

  事實上,癌症是一種依賴基因突變的慢性疾病。一般來說,同一種癌症在不同患者身上,甚至是同一患者的不同器官或組織中,都可能具有不同的基因型。癌症,似乎可以看做是某些邪惡基因隨機發生於宿主個體間的一種“寄生”。

  肉體總有終結之時,但癌症永生。當然,對於絕大多數不具有傳染性的癌症來說,只是在時間跨度下的眾多個體間的廣義永生。事實上,有極少數的癌症的確可以在生命個體間傳播,延續着自己的生命,完成永生。

  但值得一提的是,傳染性癌症區別於感染型癌症,並不是通過病毒感染誘發的。大多數病毒感染誘發的癌症,如人乳頭瘤病毒引起的宮頸癌、乙肝病毒引起的肝癌,都可以通過接種疫苗有效預防。

  二、古老的癌症

  對於大多數癌症來說,他們隨機的發生於單一個體,隨個體的壽命而發生、發展、終結。而其中的極少數癌症,可以在個體間進行傳播,就像“寄生”在宿主中完成自身的演化時間線,CTVT 就是其中一員。

  這種來源於犬類的癌症起源於中亞,遺傳信息穩定且高度相似。對於它開始的時間,研究者們尚存在爭議,一部分人認為約在 1.1 萬年前犬類的馴化時間點上,也有人認為發生於時間稍近的 6000 多年前。

  通過犬類之間的交配、甚至是舔舐,CTVT 在群體間進行傳播。每一顆癌細胞就像是種子,到達下一個宿主體內,等待合適的時機繼續傳播。

  隨着大航海時代的到來,人類的生活半徑增大,而犬類也跟隨人類開始了他們的遷移。時至今日,幾乎在每塊大陸上,都有 CTVT 的痕迹。

  而如今,它居然歪打正着地成為研究癌症的最佳手段,幫助人類追蹤癌症的演化,破解癌症的謎團。

  三、揭開千年疑團

  在此項研究中,研究者們對來自 43 個國家的 546 個 CTVT 腫瘤樣本和 495 個 CTVT 腫瘤宿主的正常樣本進行了外顯子測序,並構建出時間系統發育譜系。分析結果显示,CTVT 細胞大約在 6200 年前首次於亞洲出現,目前廣泛分佈的 CTVT 細胞的源頭可以追溯到約 1900 年前的印度。彼時 CTVT 開始產生亞型,並開始向歐洲、亞洲蔓延擴散。隨着大航海時代的到來,CTVT 的傳播也搭上了“順風船”,跟隨人類的足跡踏上更多的陸地。


來源:Science

  隨後研究者們對 CTVT 的癌症突變特徵進行了分析,並由此識別出 CTVT 的高度環境特異性突變過程。同時,研究者發現了 5 個促進 CTVT 發生和傳播的早期驅動基因:SETD2,CDKN2A,MYC,PTEN 和 RB1。研究者也發現,CTVT 幾乎沒有晚期陽性選擇,解釋了中性遺傳漂變是癌症長期演化的主要特徵。

  殖民、全球化、同質化,共同作用造成了如今的 CTVT。而存活了數千年、從來不能滅亡的 CTVT,同時也像活化石、錄影帶一樣記錄了癌症的進化歷程。管中窺豹,可見一斑。

  對於 CTVT 來說,癌細胞似乎更像是一種獨立的生命體在不同的“宿主”間傳播,雖然來源不同,但卻可以和不同個體的免疫系統都相安無事。儘管目前並未發現可以在人體間傳染的癌症,但足以為器官移植敲響警鐘。如果捐贈者的器官中留有癌症的“種子”,對於接受器官移植的人來說很可能是一場可怕的災難。

  同時,CTVT 的中性進化也為現代癌症的治療提供思路。對於一些進程緩慢的癌症,似乎可以嘗試適應性療法,而非在癌細胞和宿主間,一定要斗個“你死我活”。

  如果承載生命的主體是遺傳物質,那麼毫無疑問,癌症從未死去。如果短期內無法戰勝,找到與它“同生”的方法或許並不是最壞的選擇。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

JVM 問題排查和性能優化常用的 JDK 工具

JDK 提供了一系列用於監控、診斷 Java 進程的工具,它們在 JDK 安裝目錄的 bin 目錄下,有 jps、jcmd、jstack、jinfo、jmap 等。其中jmc、jconsole、jvisualvm 是 GUI 工具,其他大部分都是命令行工具。

cd $JAVA_HOME/bin
ls

本篇只是個入門介紹,不涉及深入分析。每一個工具都有它專門的作用,掌握使用方法只是很簡單的入門階段,更重要的是根據工具得到的信息去分析系統存在的問題以及性能瓶頸,每一個工具的使用和分析都可以單獨成文。

jps

如果你用過 Linux,那肯定熟悉 ps 命令,用來查看進程列表的。jps 就好比是 ps 命令的子集,它查詢的是當前用戶下已經啟動的 Java 進程。這是進行線上問題排查的大門鑰匙,有了它才能下手後面的動作。

下面是 jps 的幫助文檔

usage: jps [-help]
       jps [-q] [-mlvV] [<hostid>]

Definitions:
    <hostid>:      <hostname>[:<port>]

一般的用法是 jps -l,前面一列显示 pid,後面一列显示進程名稱。

還可以用下列參數查看更具體的 Java 進程信息,用法為 jps -lv

jstack

查看 Java 進程內當前時刻的線程快照,也就是每條線程正在執行的方法棧情況,用於定位線程停頓、死鎖等長時間等待的問題。

以下是 jstack 的幫助文檔。

Usage:
    jstack [-l] <pid>
        (to connect to running process)
    jstack -F [-m] [-l] <pid>
        (to connect to a hung process)
    jstack [-m] [-l] <executable> <core>
        (to connect to a core file)
    jstack [-m] [-l] [server_id@]<remote server IP or hostname>
        (to connect to a remote debug server)

Options:
    -F  to force a thread dump. Use when jstack <pid> does not respond (process is hung)
    -m  to print both java and native frames (mixed mode)
    -l  long listing. Prints additional information about locks
    -h or -help to print this help message

最常用的就是 jstack -pid 或者 jstack -l pid,打印線程狀態、棧使用情況。

如果是線上查看不方便的話,可以用命令 jstack -l pid > stack.log,輸出到文件中下載到本地查看。

jstack -m pid,打印 Java 和 Native 棧信息

如果 -l 和 -m 都不起作用的時候,可以使用 java -F pid 強制 dump。

jinfo

它的主要作用是查看 JVM 配置參數,還可以動態設置部分參數值。jinfo 使用時需要 attach 到目標 JVM 上。關於 attach jvm 可以點擊查看

使用 jinfo -h查看幫助文檔

Usage:
    jinfo [option] <pid>
        (to connect to running process)
    jinfo [option] <executable <core>
        (to connect to a core file)
    jinfo [option] [server_id@]<remote server IP or hostname>
        (to connect to remote debug server)

where <option> is one of:
    -flag <name>         to print the value of the named VM flag
    -flag [+|-]<name>    to enable or disable the named VM flag
    -flag <name>=<value> to set the named VM flag to the given value
    -flags               to print VM flags
    -sysprops            to print Java system properties
    <no option>          to print both of the above
    -h | -help           to print this help message

jinfo -flags pid

查看 JVM 參數,其中 Non-default VM flags 是虛擬機默認設置的參數,Command line 是用戶指定的參數,比如命令行啟動 jar 包的時候加上的參數。

jinfo -flag 參數名 pid

可以查看指定參數的值,比如查看堆的最大值(-XX:MaxHeapSize 也就是 -Xmx ):

jinfo -flag MaxHeapSize 92041

-XX:MaxHeapSize=20971520

jinfo -sysprops pid

查看系統參數

jinfo pid

查看 jvm 參數和系統參數

以上信息,如果我們用過 visualVM 等監控工具,一定非常熟悉。另外,我之前做過一個 ,也實現了這個功能。

另外,還可以修改部分參數值。

jinfo -flag [+|-] pid

jinfo -flag = pid

可以修改部分 JVM 參數。

前者可以修改布爾值參數,比如開啟簡單 GC 日誌

jinfo -flag +PrintGC 92041

後者是設置非布爾值參數的,比如設置 HeapDumpPath

jinfo -flag HeapDumpPath=/users/fengzheng/jvmlog

哪些參數是允許動態修改的呢,用下面這個命令可以查看

#Linux 和 Mac 
java -XX:+PrintFlagsInitial | grep manageable

#windows
java -XX:+PrintFlagsInitial | findstr manageable

jmap

jmap 查看給定進程、核心文件、遠程調試服務器的共享對象內存映射和堆內存細節的工具,可查看堆使用情況、堆內對象直方圖、加載類、生成堆快照等。

Usage:
    jmap [option] <pid>
        (to connect to running process)
    jmap [option] <executable <core>
        (to connect to a core file)
    jmap [option] [server_id@]<remote server IP or hostname>
        (to connect to remote debug server)

where <option> is one of:
    <none>               to print same info as Solaris pmap
    -heap                to print java heap summary
    -histo[:live]        to print histogram of java object heap; if the "live"
                         suboption is specified, only count live objects
    -clstats             to print class loader statistics
    -finalizerinfo       to print information on objects awaiting finalization
    -dump:<dump-options> to dump java heap in hprof binary format
                         dump-options:
                           live         dump only live objects; if not specified,
                                        all objects in the heap are dumped.
                           format=b     binary format
                           file=<file>  dump heap to <file>
                         Example: jmap -dump:live,format=b,file=heap.bin <pid>
    -F                   force. Use with -dump:<dump-options> <pid> or -histo
                         to force a heap dump or histogram when <pid> does not
                         respond. The "live" suboption is not supported
                         in this mode.
    -h | -help           to print this help message
    -J<flag>             to pass <flag> directly to the runtime system

jmap -heap pid

打印 JVM 堆概要信息,包括堆配置、新生代、老生代信息

jmap -histo pid

打印類的直方圖,也就是各個類實例的個數和空間佔用情況。

如果加 :live,jamp -histo:live pid 則只打印活動類的信息。這個命令會出發 GC 動作,會導致 JVM 停頓,所以在線上環境要慎用。

jmap -dump

dump 當前 JVM 堆,一般用法如下:

#dump 所有對象在堆中的分佈情況
jmap -dump:format=b,file=/Users/fengzheng/jvmlog/jamp_dump.hprof 95463

#加:live 參數 dump 存活對象在隊中的分佈情況
jmap -dump:live,format=b,file=/Users/fengzheng/jvmlog/jamp_dump.hprof 95463

之後再用堆分析工具,比如 visualVM、JProfile、MAT 等進行分析。和我們設置

-XX:+HeapDumpOnOutOfMemoryError 參數后,在發生 OOM 的時候 dump 的堆信息是一樣的。

注意,dump 的過程會比較慢,在這個過程中會發生 JVM 停頓,而且在使用 :live 參數后,會觸發 GC 操作。

jmap -clstats pid

Java 類加載器(ClassLoader)信息,包括加載器名稱、已加載類個數、佔用空間、父加載器、是否存活、類型信息。

jmap -finalizerinfo pid

查看等待被回收的對象。

jstat

jstat 主要用來通過垃圾回收相關信息來判斷 JVM 性能問題,也可以查看類加載、編譯的情況,主要的用法是通過持續的固定時間間隔的輸出來觀察。比如每 3 秒打印一次 GC 回收次數,連續打印 10 次,通過動態的變化來觀察 GC 是否過於密集。

下面是 jstat 的幫助手冊。

Usage: jstat -help|-options
       jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]

Definitions:
  <option>      An option reported by the -options option
  <vmid>        Virtual Machine Identifier. A vmid takes the following form:
                     <lvmid>[@<hostname>[:<port>]]
                Where <lvmid> is the local vm identifier for the target
                Java virtual machine, typically a process id; <hostname> is
                the name of the host running the target Java virtual machine;
                and <port> is the port number for the rmiregistry on the
                target host. See the jvmstat documentation for a more complete
                description of the Virtual Machine Identifier.
  <lines>       Number of samples between header lines.
  <interval>    Sampling interval. The following forms are allowed:
                    <n>["ms"|"s"]
                Where <n> is an integer and the suffix specifies the units as 
                milliseconds("ms") or seconds("s"). The default units are "ms".
  <count>       Number of samples to take before terminating.
  -J<flag>      Pass <flag> directly to the runtime system.

通過 jstat -options 可以看到 jstat 支持查看哪些信息。

$ jstat -options
-class  #類加載情況 加載個數和空間使用
-compiler #即時編譯器信息
-gc  # GC情況 包括 young gc、full gc 次數、時間等
-gccapacity #年輕代、老年代的使用情況
-gccause #GC 統計信息和回收原因
-gcmetacapacity #显示有關metaspace大小的統計信息
-gcnew #新生代 GC 統計
-gcnewcapacity #新生代內存統計
-gcold #老年代 GC 統計
-gcoldcapacity #老年代內存使用情況
-gcutil #GC 匯總信息
-printcompilation #編譯方法統計

上述這些大多數可以對應到 visualVM 的這一部分显示

示例用法,如下是打印 5301 進程下的垃圾回收情況,-h 3 表示每 3 行輸出一次標題信息,3s 5 表示每 3s 輸出一次,一共輸出 5 次

jstat -gcutil -h 3 5301 3s 5

最後輸出的內容如下:

jstat -gcutil -h 3 5301 3s 5
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
 99.92   0.00  11.90  35.29  94.96  94.08     34   12.675     3    1.946   14.621
 99.92   0.00  11.90  35.29  94.96  94.08     34   12.675     3    1.946   14.621
 99.92   0.00  11.90  35.29  94.96  94.08     34   12.675     3    1.946   14.621
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
 99.92   0.00  11.94  35.29  94.96  94.08     34   12.675     3    1.946   14.621
 99.92   0.00  11.94  35.29  94.96  94.08     34   12.675     3    1.946   14.621

jcmd

jcmd 會將命令發送給 JVM。這些命令包括用於控制 Java Flight Recording(飛行記錄)、診斷命令等。 必須運行在 JVM 本地,不能遠程使用,並且必須用 JVM 啟動用戶執行。

通過 jps 命令找到一個 JVM 進程,然後使用下面的代碼可以看到 jcmd 支持的命令

#進程 5173 
jcmd 5173 help 

5173:
The following commands are available:
JFR.stop
JFR.start
JFR.dump
JFR.check
VM.native_memory
VM.check_commercial_features
VM.unlock_commercial_features
ManagementAgent.stop
ManagementAgent.start_local
ManagementAgent.start
GC.rotate_log
Thread.print
GC.class_stats
GC.class_histogram
GC.heap_dump
GC.run_finalization
GC.run
VM.uptime
VM.flags
VM.system_properties
VM.command_line
VM.version
help

基本包含了問題排查的常用命令,並且和上面介紹的幾個工具有部分重合。

通過命令 jcmd 5173 help GC.heap_dump 可以查詢到 GC.heap_dump 命令的使用方法,其他命令都可以通過這個方法找到使用說明

jcmd 5173 help GC.heap_dump
5173:
GC.heap_dump
Generate a HPROF format dump of the Java heap.

Impact: High: Depends on Java heap size and content. Request a full GC unless the '-all' option is specified.

Permission: java.lang.management.ManagementPermission(monitor)

Syntax : GC.heap_dump [options] <filename>

Arguments:
    filename :  Name of the dump file (STRING, no default value)

Options: (options must be specified using the <key> or <key>=<value> syntax)
    -all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false)

然後通過如下代碼就可以 dump 堆信息下來了,和 jmap -dump 的作用一樣

jcmd 5173 GC.heap_dump /Users/fengzheng/jvmlog/jcmd_heap_dump.hprof

拋磚引玉就到此了,之後會對 jinfo、jmap、jstack、jstat、jcmd 做詳細說明,記得關注啊。

相關閱讀:

歡迎關注,不定期更新本系列和其他文章
古時的風箏 ,進入公眾號可以加入交流群

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

天啦!竟然從來沒有人講過 SpringBoot 支持配置如此平滑的遷移

SpringBoot 是原生支持配置遷移的,但是官方文檔沒有看到這方面描述,在源碼中才看到此模塊,spring-boot-properties-migrator,幸虧我沒有跳過。看到這篇文章的各位,可算是撿到寶了,相信你繼續往下看下去,定會忍不住點贊、收藏、關注。

效果

先放個效果吸引你 🙂

從 SpringBoot 2.0.0 版本開始,配置服務上下文,不支持 server.context-path,而需要server.servlet.context-path配置。但是只要加上以下一個官方依賴,就可以支持使用 server.context-path

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-properties-migrator</artifactId>
    </dependency>

server.context-path 所對應的屬性 ServerProperties#contextPath 在 Java 代碼中已不存在,server.servlet.context-path 所對應的的屬性在內部類 Servlet 中才有,為何加了此依賴就能實現如此神奇的效果呢。

原理

SpringBoot 對外部化配置原生支持遷移功能,所謂遷移,具體是指對應配置的屬性名變動,仍可以使用原來的屬性名配置。
spring-configuration-metadata.json 的信息可以輔助 IDE 進行配置的提示,也可以用來完成配置的遷移。非常的簡單。

相關文章:

通過閱讀代碼,獲得以下信息:

  1. 監聽 ApplicationPreparedEvent 事件(即:環境已準備事件),執行以下操作並收集信息
  2. classpath*:/META-INF/spring-configuration-metadata.json 中載入所有配置
  3. 從上下文的 environment 中過濾出提示的配置(滿足條件:1. deprecation 不為 null,且提示 level 為 error)
  4. 判斷是否兼容(兼容條件見下一節),提取出兼容的屬性
  5. 將 value 對應到 replacement 的 key,並將其屬性源命名為:migrate-原名
  6. 將配置遷移的新屬性源添加到 environment 中,且添加到原屬性源之前(優先級高)。
  7. 監聽事件:ApplicationReadyEvent(應用上下文已準備) 或 ApplicationFailedEvent(應用啟動失敗),打印以上步驟收集的遺留配置信息。以 warn 級別打印兼容的配置,以 error 級別打印不兼容的配置

配置兼容條件

根據元數據中定義的 type 判斷

  1. 如果舊類型、新類型其中之一為 null(元數據中未指定),則不兼容
  2. 如果兩個類型一樣,兼容
  3. 如果新類型是 Duration,而舊類型是 Long 或 Integer,則兼容
  4. 其他情況視為不兼容
  5. environment 中取配置信息,理論上支持 SpringBoot 所有的配置方式

效果

兼容效果:
棄用屬性(如果還存在)與替換后的屬性都會使用配置文件中的棄用的屬性名所對應的的值。

總結

使用配置遷移功能,需要以下步驟:

  1. 引入依賴:spring-boot-properties-migrator(支持配置遷移)、spring-boot-configuration-processor(生成元數據文件,如果已經有完整的,不需要此依賴)
  2. 元數據文件spring-configuration-metadata.json 中棄用屬性名對應的 properties 中必須有 deprecation(在additional-spring-configuration-metadata.json 中添加,相關文章: )
  3. deprecation 中需指定 levelerror
  4. deprecation 中需指定 replacement
  5. replacement 對應的屬性配置在元數據文件中存在,與棄用屬性兼容

經典示例之配置上下文

再說回一開始展示的配置上下文示例。

# 配置 servlet 服務上下文
server:
  context-path: test

從 SpringBoot 2.0.0 版本開始,以上配置不支持,點到配置元數據文件中(spring-configuration-metadata.json),發現如下信息:

{
  "properties": [
    {
      "name": "server.context-path",
      "type": "java.lang.String",
      "description": "Context path of the application.",
      "deprecated": true,
      "deprecation": {
        "level": "error",
        "replacement": "server.servlet.context-path"
      }
    },
    {
      "name": "server.servlet.context-path",
      "type": "java.lang.String",
      "description": "Context path of the application.",
      "sourceType": "org.springframework.boot.autoconfigure.web.ServerProperties$Servlet"
    }

替換屬性名為:server.servlet.context-path,此屬性在org.springframework.boot.autoconfigure.web.ServerProperties 中,且在類中可以發現,server.context-path 所對應的屬性 ServerProperties#contextPath 在代碼中已不存在,而是在內部類 Servlet 中有,也就是對應 server.servlet.context-path 的屬性才有。

但是其滿足配置兼容的條件,為什麼實際上使用卻好像不兼容呢?
其實是因為沒有引入依賴,當引入依賴,就會發現此方式配置可以起作用。

示例之兩種屬性都存在

代碼示例見

1、引入依賴

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-properties-migrator</artifactId>
</dependency>

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-configuration-processor</artifactId>
  <optional>true</optional>
</dependency>

2、Java 配置
此處故意保留棄用屬性

@Data
@Configuration
@ConfigurationProperties(prefix = "my")
public class MyProperties {
  /** the project name */
  private String name;

  private App app;

  @Data
  public static class App {
    private String name;
  }
}

3、元數據配置,spring-configuration-metadata.json 由程序生成,自定義配置放在 additional-spring-configuration-metadata.json

{
  "properties": [
    {
      "name": "my.name",
      "type": "java.lang.String",
      "description": "the project name.",
      "deprecation": {
        "reason": "test the properties-migrator feature.",
        "replacement": "my.app.name",
        "level": "error"
      }
    },
    {
      "name": "my.app.name",
      "type": "java.lang.String",
      "sourceType": "com.lw.properties.migrator.config.MyProperties$App",
      "description": "the project name."
    }
  ]
}

4、在 properties 或 yml 文件中配置

my:
  name: lw
  app:
    name: app

5、打印配置信息

@Slf4j
@SpringBootApplication
public class PropertiesMigratorApplication {

  public static void main(String[] args) {
    ConfigurableApplicationContext context =
        SpringApplication.run(PropertiesMigratorApplication.class, args);
    MyProperties myProperties = context.getBean(MyProperties.class);
    log.info("myProperties.name:{}", myProperties.getName());
    log.info(
        "myProperties$app.name:{}",
        Optional.ofNullable(myProperties.getApp()).orElse(new App()).getName());
  }
}

6、打印信息如下:

2019-11-23 21:42:09.580 WARN 109408 — [ main] o.s.b.c.p.m.PropertiesMigrationListener :
The use of configuration keys that have been renamed was found in the environment:

Property source ‘applicationConfig: [classpath:/application.yml]’:
Key: my.name
Line: 4
Replacement: my.app.name
Key: server.context-path
Line: 2
Replacement: server.servlet.context-path

Each configuration key has been temporarily mapped to its replacement for your convenience. To silence this warning, please update your configuration to use the new keys.
……… myProperties.name:lw
……… myProperties\(app.name:lw ……… serverProperties\)servlet.contextPath:/app

7、效果解析
在 yml 中棄用屬性名優先級更高,棄用屬性與新屬性都使用此棄用屬性名對應的值。

參考資料

SpringBoot 2.2.1.RELEASE 源碼
公眾號:逸飛兮(專註於 Java 領域知識的深入學習,從源碼到原理,系統有序的學習)

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

Facebook改進換臉術:無需“投喂”圖片,從視頻里直接變臉

  曉查 發自 凹非寺 
  量子位 報道 公眾號 QbitAI

  近兩年來,Deepfakes 讓許多歐美明星吃盡了苦頭,面對自己的頭像被替換到各種視頻中,卻無能為力。

  比如黑寡婦就對自己的臉被替換到小電影中感到很無奈,呼籲大家停止用 AI 作惡。

  而最近,Facebook 人工智能研究院讓換臉技術再次進化。

  過去 Deepfakes 這項技術需要很多準備材料:一是被替換人臉的原視頻,二是來自換臉人面部各個角度的照片。有這兩樣東西才能造出完美無暇的換臉視頻。

  而來自 Facebook 的技術不需要照片,可以從原視頻直接生成換臉視頻,甚至能對實時視頻進行換臉。

  它讓“大表姐”變得不再熟悉。 

  這項技術的換臉實際上是毫無違和感地修改五官特徵,好讓 AI 無法識別出,因此也就不需要照片了。

  而且 Facebook 的研究人員還表示,這項技術修改后的明星臉仍然可以被人識別出來,但是 AI 卻不行。 

  Facebook 研發這項技術可不是為了換臉好玩,最近因使用人臉識別技術飽受爭議,這家公司希望通過這項新技術來保護用戶的隱私。

  人臉識別和換臉技術對普通民眾的隱私也造成了很大的威脅。比如前一陣大熱的換臉應用 ZAO,讓每個人都享受到換臉帶來的樂趣,但同時也會收集用戶圖片。

  研究人員在論文摘要中說:“人臉識別可能會導致隱私丟失,而換臉技術可能會被用於製作誤導性視頻。”Facebook 用後者來去除視頻中的隱私信息。

  Facebook 聲稱,該技術屬於業內首創,足以抵禦複雜的人臉識別系統。

  Facebook 將在下周韓國首爾舉行的國際計算機視覺國際會議(ICCV)上介紹該工作。

  本周,Facebook 還聯合微軟和亞馬遜,提供 Deepfakes 換臉挑戰數據集,希望能夠提高識別換臉視頻算法的魯棒性,以控制假視頻的傳播。

  此舉頗有些以彼之矛攻彼之盾的意味。

  原文鏈接:

  https://venturebeat.com/2019/10/25/facebook-alters-video-to-make-people-invisible-to-facial-recognition/

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

是什麼觸發了宇宙大爆炸?


圖片來源:Christine Daniloff, MIT, ESA/Hubble and NASA

  1.

  根據大爆炸理論,我們的宇宙誕生於 138 億年前,從一個無限小的緻密“火球”,不斷地擴張膨脹,並慢慢冷卻。漸漸地,宇宙中形成了第一批恆星、星系,以及我們如今所見到的所有形式的物質。

  物理學家相信,就在大爆炸將宇宙推向不斷膨脹的進程之前,早期宇宙還經歷了另一個更具爆炸性的階段——宇宙暴脹。這個過程持續的時間不到萬億分之一秒,但膨脹的速度卻是以指數級增長的。  


Guth 的筆記

  上個世紀 80 年代,物理學教授 Alan Guth 首次提出了宇宙膨脹理論,該理論預測宇宙最初是一個極微小的物質點,其大小可能只有質子的千億分之一。這個點中充滿了超高能物質,能量非常之大,以至於內部的壓力產生了一種排斥性的引力——這就是暴脹背後的驅動力。就像火花之於引信一樣,這種引力以前所未有的速度將新生的宇宙向外推,在不到萬億分之一秒的時間內,使宇宙膨脹到接近原始大小的 10²⁷倍。

  許多天文觀測結果都支持了大爆炸和宇宙暴脹理論。但是,這是兩個截然不同的過程,科學家們一直難以理解其中一個是如何緊隨另一個之後出現的。

  在一項新的研究中,物理學家詳細地模擬了早期宇宙中一個可能連接了宇宙暴脹和大爆炸的中間階段。這個階段被稱為“再熱”,這一過程出現在宇宙暴脹末期和大爆炸開始之前的階段,將暴脹產生的冷的、均勻的物質轉變成超熱的、複雜的物質湯。

  論文的作者David Kaiser說:“后暴脹再熱時期為大爆炸創造了條件,在某種意義上,是它啟動了‘爆炸’,正是在這個橋樑時期,所有的事物都開始鬆動,物質的行為變得非常複雜。”

  2.

  對於這個連接了宇宙暴脹和大爆炸的橋樑階段,研究人員很好奇它最初會是什麼樣子。

  Kaiser 說:“再熱的最初階段應該用共振來標記。一種高能物質佔據主導地位,它在廣闊的空間中與自身同步來回擺動,導致爆炸式地產生新的粒子。但這種行為不會永遠持續下去,一旦它開始將能量轉移到另一種形式的物質上,它自身的擺動將在空間中變得更加起伏不平。我們想要測量的是,需要多長的時間共振效應才會破裂,產生的粒子才會彼此分散並且達到某種熱平衡,讓人想起大爆炸發生時的情況。”

  他們的計算機模擬中展示了一個很大的晶格,在這個晶格上,他們繪製了多種形式的物質,並追蹤了當某些條件被改變時,能量和分佈會如何隨之在空間和時間上發生變化。模擬的初始條件是基於一個特定的暴脹模型而設置的,這個模型是一組關於早期宇宙的物質分佈在宇宙暴脹期間的行為得到一系列預測。

  他們之所以選擇這一特定的暴脹模型,是因為它的預測與高精度的宇宙微波背景測量結果非常吻合。

  3.

  在模擬中,他們研究了兩種可能在暴脹期間佔主導地位的物質的行為,這些物質與希格斯玻色子非常相似。

  在進行模擬之前,研究人員對模型中的引力描述進行了一個微小的調整。我們如今看到的普通物質在引力下的作用應正如愛因斯坦廣義相對論中所預測的那樣;但在更高的能量下,比如在宇宙暴脹期間,物質的行為或許會略有不同,與之產生相互作用的引力是由量子力學修正過的。

  在廣義相對論中,引力的強度被表示為一個常數,物理學家稱之為是最小耦合,這意味着,無論一個特定粒子的能量為何,它都會以一個由普適常數所設定的強度對引力效應做出反應。

  然而,在宇宙暴脹的高能量下,物質與引力的相互作用會以一種更為複雜的方式進行。而量子力學效應預測,當與超高能物質發生相互作用時,引力的強度在空間和時間中會發生變化,這是一種被稱為非最小耦合的現象。

  研究人員將這一個非最小耦合項納入了他們的暴脹模型中,並觀察了物質和能量的分佈是如何隨着量子效應的漲落變化的。

  最後他們發現,量子修正過的引力效應對物質的影響越強,宇宙就會越快地從暴脹中寒冷、均勻的物質過渡到更熱、更多樣的大爆炸過程中特有的物質。

  “再熱是一個瘋狂的過程,一切都不受控制。我們發現,當時物質之間的相互作用非常強烈,以至於它可以相應地快速放鬆下來,為大爆炸創造了合適的條件。我們以前並不知道會是這個樣子,但這些都是我們用已知的物理學從模擬中得出的結論。這正是讓我們興奮的地方。”

  對於新的發現,其他物理學家認為,關於造成了暴脹階段的提議有數百種,但從暴脹階段到所謂的‘熱大爆炸’之間的過渡卻是人們最不了解的部分,而這篇論文則通過包含多個獨立的場和複雜的動力學在模型中精確地模擬后暴脹階段,開闢了新的領域。這是極具挑戰性的數值模擬,併為研究早期的宇宙非線性動力學提供了最新的技術。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

JSON——IT技術人員都必須要了解的一種數據交換格式

JSON作為目前Web主流的數據交換格式,是每個IT技術人員都必須要了解的一種數據交換格式。尤其是在Ajax和REST技術的大行其道的當今,JSON無疑成為了數據交換格式的首選

今天大家就和豬哥一起來學習一下JSON的相關知識吧!

一、XML

在講JSON之前,我覺得有必要先帶大家了解一下XML(Extensible Markup Language 可擴展標記語言),因為JSON正在慢慢取代XML。

1.XML起源

早期Web發展和負載的數據量並不是很大,所以基本靠HTML(1989誕生)可以解決。但是隨着Web應用的不斷壯大,HTML的一些缺點也慢慢顯現,如:可讀性差、解析時間長、數據描述性差等。

1998年2月10日,W3C(World WideⅥiebConsortium,萬維網聯盟)公布XML 1.0標準,XML誕生了。

XML使用一個簡單而又靈活的標準格式,為基於Web的應用提供了一個描述數據和交換數據的有效手段。但是,XML並非是用來取代HTML的。HTML着重如何描述將文件显示在瀏覽器中,它着重描述如何將數據以結構化方式表示。

XML簡單易於在任何應用程序中讀/寫數據,這使XML很快成為數據交換的唯一公共語言,所以XML被廣泛應用。

注意: XML是一種數據交換的格式,並不是編程語言。而且他是跨語言的數據格式,目前絕大多數編程語言均支持XML。

2.XML實例

XML究竟怎麼用?是什麼樣子的?我們來舉一個簡單的例子吧!

A公司要和B公司業務對接(A公司要獲取B公司的用戶基本信息),B公司提供接口讓A公司調用,A、B公司對接的開發人員會提前溝通好這個接口的:URL、傳參、返回數據、異常等等。

但是也許兩個公司使用的技術棧並不相同,所以支持的據格式也可能不同。為了解決因技術棧不同帶來的數據格式不同問題,A、B公司的開發協商使用一種通用的數據格式來傳輸,於是他們想到了XML。

  1. 假設現在A公司需要名稱叫pig的用戶信息,於是A公司調用B公司的接口,並傳參數name=pig。
  2. 然後B公司接口收到請求后,將用戶信息從數據庫拿出來,然後封裝成下面的XML格式,然後再返回給A公司。
  3. 最後A公司收到返回后,使用XML庫解析數據即可
<?xml version="1.0" encoding="UTF-8"?>
<person>
  <name>pig</name>
  <age>18</age>
  <sex>man</sex>
  <hometown>
    <province>江西省</province>
    <city>撫州市</city>
    <county>崇仁縣</county>
  </hometown>
</person>

3.XML十字路口

雖然XML標準本身簡單,但與XML相關的標準卻種類繁多,W3C制定的相關標準就有二十多個,採用XML制定的重要的电子商務標準就有十多個。這給軟件開發工程師帶來了極大的麻煩!

隨着AJax(之前叫XMLHTTP,2005年後才叫Ajax)技術的流行,XML的弊端也越來越顯現:大家都知道XML實現是基於DOM樹實現的,而DOM在各種瀏覽器中的實現細節不盡相同,所以XML的跨瀏覽器兼容性並不好,所以急需一種新的數據負載格式集成到HTML頁面中以滿足Ajax的要求!

二、JSON

前面我們說了隨着Ajax的流行,而各種瀏覽器對DOM的實現細節不盡相同,所以會出現兼容性問題,這對前端開發同學來講真的是災難。因為一個功能可能需要用代碼去兼容各種不同的瀏覽器,還要調試,工作量巨大。

1.JSON誕生

如何才能將數據整合到HTML中又解決瀏覽器兼容性問題呢?答案就是:利用所有主流瀏覽器中的一種通用組件——JavaScript引擎。這樣只要創造一種JavaScript引擎能識別的數據格式就可以啦!

2001 年 4 月,首個 JSON 格式的消息被發送出來。此消息是從舊金山灣區某車庫的一台計算機發出的,這是計算機歷史上重要的的時刻。道格拉斯·克羅克福特(Douglas Crockford) 和 奇普·莫寧斯達(Chip Morningstar) 是一家名為 State Software 的技術諮詢公司的聯合創始人(後來都在雅虎任職),他們當時聚集在 Morningstar 的車庫里測試某個想法,發出了此消息。

document.domain = 'fudco'; 

parent.session.receive( 
    { to: "session", do: "test", text: "Hello world" } 
) 

熟悉js的同學是不是也很驚訝,第一個 JSON 消息它明顯就是 JavaScript!實際上,Crockford 自己也說過他不是第一個這樣做的人。網景(Netscape )公司的某人早在 1996 年就使用 JavaScript 數組字面量來交換信息。因為消息就是 JavaScript,其不需要任何特殊解析工作,JavaScript 解釋器就可搞定一切。

最初的 JSON 信息實際上與 JavaScript 解釋器發生了衝突。JavaScript 保留了大量的關鍵字(ECMAScript 6 版本就有 64 個保留字),Crockford 和 Morningstar 無意中在其 JSON 中使用了一個保留字:do。因為 JavaScript 使用的保留字太多了,所以Crockford決定:既然不可避免的要使用到這些保留字,那就要求所有的 JSON 鍵名都加上引號。被引起來的鍵名會被 JavaScript 解釋器識別成字符串。這就為什麼今天 JSON 鍵名都要用引號引起來的原因。

這種數據格式既然可以被JavaScript引擎識別,那就解決了XML帶來的各種瀏覽器兼容性問題,所以這種技術完全可以推廣出去,於是Crockford 和 Morningstar 想給其命名為 “JSML”,表示JavaScript 標記語言(JavaScript Markup Language)的意思,但發現這個縮寫已經被一個名為 Java Speech 標記語言的東西所使用了。所以他們決定採用 “JavaScript Object Notation”,縮寫為 JSON,至此JSON正式誕生。

2.JSON發展

2005 年,JSON 有了一次大爆發。那一年,一位名叫 Jesse James Garrett 的網頁設計師和開發者在博客文章中創造了 “AJAX” 一詞。他很謹慎地強調:AJAX 並不是新技術,而是 “好幾種蓬勃發展的技術以某種強大的新方式彙集在一起。” AJAX 是 Garrett 給這種正受到青睞的 Web 應用程序的新開發方法的命名。他的博客文章接着描述了開發人員如何利用 JavaScript 和 XMLHttpRequest 構建新型應用程序,這些應用程序比傳統的網頁更具響應性和狀態性。他還以 Gmail 和 Flickr 網站已經使用 AJAX 技術作為了例子。

當然了,“AJAX” 中的 “X” 代表 XML。但在隨後的問答帖子中,Garrett 指出,JSON 可以完全替代 XML。他寫道:“雖然 XML 是 AJAX 客戶端進行數據輸入、輸出的最完善的技術,但要實現同樣的效果,也可以使用像 JavaScript Object Notation(JSON)或任何類似的結構數據方法等技術。 ”

這時JSON便在國外的博客圈、技術圈慢慢流行起來!

2006 年,Dave Winer,一位高產的博主,他也是許多基於 XML 的技術(如 RSS 和 XML-RPC)背後的開發工程師,他抱怨到 JSON 毫無疑問的正在重新發明 XML。

Crockford 閱讀了 Winer 的這篇文章並留下了評論。為了回應 JSON 重新發明 XML 的指責,Crockford 寫到:“重造輪子的好處是可以得到一個更好的輪子”。

3.JSON實例

還是以上面A、B公司業務對接為例子,兩邊的開發人員協商一種通用的數據交換格式,現在有XML與JSON比較流行的兩種數據格式,於是開發人員又將用戶信息以JSON形式展現出來,然後比較兩種數據格式:

{
  "person": {
    "name": "pig",
    "age": "18",
    "sex": "man",
    "hometown": {
      "province": "江西省",
      "city": "撫州市",
      "county": "崇仁縣"
    }
  }
}

比較XML與JSON的數據格式之後,開發人員發現:JSON可閱讀性、簡易性更好而且相同數據負載JSON字符數更少,所以兩個開發人員一致同意使用JSON作為接口數據格式!

而且還有重要的一點,在編寫XML時,第一行需要定義XML的版本,而JSON不存在版本問題,格式永遠不變!

4.當今JSON地位

當今的JSON 已經佔領了全世界。絕大多數的應用程序彼此通過互聯網通信時,都在使用 JSON。它已被所有大型企業所採用:十大最受歡迎的 web API 接口列表中(主要由 Google、Facebook 和 Twitter 提供),僅僅只有一個 API 接口是以 XML 的格式開放數據的。

JSON 也在程序編碼級別和文件存儲上被廣泛採用:在 Stack Overflow上,關於JSON的問題越來越多,下圖是關於Stack Overflow上不同數據交換格式的問題數和時間的曲線關係圖。
從上圖我們可以看出在Stack Overflow上越來越多JSON的問題,從這裏也可以反映出JSON越來越流行!

更詳細的關於創造JSON的故事可閱讀:

3、總結

由於篇幅原因我們今天只學習了JSON的誕生和起源相關知識,知道了JSON的誕生是因為XML無法滿足Ajax對瀏覽器兼容性問題,所以就有人想創造一種瀏覽器通用組件:JavaScript引擎 能識別的數據格式,這樣就可以解決瀏覽器不兼容問題,所以就從Js數據格式中提取了一個子集,取名為JSON!

我們還知道了為什麼JSON鍵為什麼需要用雙引號引起來,是因為JS中存在許多的關鍵字和保留關鍵字,為了避免與JS關鍵字衝突,所以Crockford就要求在所有的鍵名上加上雙引號,這樣JS引擎會將其識別為字符串,就避免與JS中關鍵字衝突!

下期我們會詳細介紹JSON數據結構、JSON序列化、JSON在Python中的使用等知識。

了解技術誕生與發展背後的故事同樣重要,因為這些可以作為你吹逼的資本!

參考資料:
百度百科:XML
Daniel Rubio:JSON 簡介

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※高價收購3C產品,價格不怕你比較

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

3c收購,鏡頭 收購有可能以全新價回收嗎?

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!