來源：我是科學家 iScientist

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

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

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

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

卡文迪許

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

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

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

卡文迪許

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

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

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

卡文迪許

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

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

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

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

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

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

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

卡文迪許

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

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

卡文迪許家裡的餐廳

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

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

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

卡文迪許

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

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

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

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

英國皇家學會

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

氫氣球爆炸

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

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

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

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

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

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

卡文迪許設計的扭稱模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

夏爾·奧古斯丁·庫侖

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

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

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

格奧爾格·西蒙·歐姆

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

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

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

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

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

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

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

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

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

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

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

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

先看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()) 
 　　}
 }

　　

到此為止拉~

 

 

 

 

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

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

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

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

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

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

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

　　而今，一種至今已存在了 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 的中性進化也為現代癌症的治療提供思路。對於一些進程緩慢的癌症，似乎可以嘗試適應性療法，而非在癌細胞和宿主間，一定要斗個“你死我活”。

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

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

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

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

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

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 中需指定 level 為 error
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 領域知識的深入學習，從源碼到原理，系統有序的學習）

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

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

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

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

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收購,鏡頭 收購有可能以全新價回收嗎?

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

　　10 月 27 日，國內領先的 AI Camera 系統芯片及解決方案供應商星宸科技（SigmaStar）在深圳舉行了以“Leading AI Everywhere”為主題的 2019 新產品發布會，現場發布了三大產品線的 AI 芯片新品。商湯科技、艾為智能、邁宸科技、智芯原動、愛華盈通、天瞳威視等眾多合作夥伴共同到場見證。

　　源自 MStar，三年時間成為安防監控芯片市場前三

　　對於星宸科技可能有些朋友不是很熟悉，但是提起曾經智能電視芯片領域的龍頭大廠——MStar（晨芯半導體，已被聯發科收購），想必大多數業內的朋友都有所了解。而於 2017 年在廈門成立的廈門星宸科技有限公司（簡稱“星宸科技”）的核心團隊則是源於 MStar。

　　根據資料显示，星宸科技實際上是由聯發科控股的子公司，聯發科通過 SigmaStar Technology Inc. 持有星宸科技 81.05% 的股份。

　　正因為如此，源自於 MStar 的核心團隊在芯片設計、算法、全球營銷、供應鏈等方面都有着深厚的積累，特別是在 ISP、音視頻編解碼、模擬電路設計、SoC 系統設計以及自研 IP 方面擁有着巨大的優勢。此外，在供應鏈資源方面，星宸科技還可獲得聯發科規模採購優勢的助力。

　　結合自身優勢，星宸科技一開始就 AI Camera SoC 入手，針對 USB 攝像機、安防監控、車載攝像等市場推出相關的 SoC 芯片。

　　對於星宸科技這樣一家起點很高的公司來說，經過短短一年的時間，星宸科技很快就拿到了 2017 年 1080P 車載智能 DVR 芯片市場 10% 的份額，2018 年市場份額更是一下子增長到了 45%，成為了該市場的第一名。據星宸科技預計，2019 年其將拿下該市場 60% 的市場份額。

　　此外，在 2018 年星宸科技還成為了 USB 攝像芯片市場的第二名。在安防監控 IPC 芯片市場，星宸科技在 2018 年也成功進入了全球第三。

　　星宸科技董事長兼總經理林永育先生表示，未來目標是成為安防監控芯片市場的全球第一。

　　針對智能显示市場，軒轅系列芯片發布

　　當前，人工智能技術已經讓智能機器逐漸實現從“認識物理世界”到“個性化場景落地”的轉變，就像電視、手機等行業，都經歷了從模擬到数字、從数字到智能的變遷，小屏显示也在經歷這個過程，智能化的显示終端將極大的提高效率和人性化，那麼怎麼定義智能显示？

　　星宸科技显示芯片的市場負責人陳立敬表示，“智能显示主要要解決一個信息呈現和人機交互的智能化，這需要智能显示具備多網絡連接、多視窗、觸控和語音交互等特徵。其中，多網絡連接是解決一個互聯互通、信息來源處理和更人性化的控制，對於显示設備而言，它既是一個端，同時也是一個小中樞，起到連接周邊設備及显示控制功能，显示設備在這個網絡當中起到了一個小型中心的作用，這個小中心的作用就是連接、控制其他設備以及及時處理 IoT 的信息的能力。”

　　陳立敬認為，多視窗是解決信息處理的效率提高問題，多視窗使信息更直觀，交互更直接！隨着大數據及算法的不斷進步，AI 發展的很快，語音交互也越來越成熟，而語音交互是當前人機交互的最好方式，特別是在設備功能越來越多的情況更是合適，成本增加不多，使用也更為方便。

　　正是基於這些考量，星宸科技在此次發布會上推出“軒轅”系列智能显示產品 SSD201、SSD202D 芯片方案，基於 Arm Cortex-A7 雙核，集成了 2D 加速引擎、智能語音處理引擎，支持H.264/265 FHD 解碼、MIPI/TTL 屏驅動、智能多網口多網絡接入、多解碼多視窗、工業級寬溫等應用需求。

　　特別是在显示方面，得益於軒轅先進的显示技術的加持，SSD201、SSD202D 在畫質提升、點屏技術、多畫面拼接方面有了很大的提升。

　　在智能語音處理方面，SSD201、SSD202D 加入了對於 4 麥克風陣列、降噪、迴音消除、聲源定位、關鍵字喚醒、本地詞條識別、本地 NLP、本地 TTS 等功能的支持。

　　據介紹，星宸科技軒轅系列芯片應用於樓宇對講、智能家居、白電/廚電顯控以及各種 HMI 產品等。星宸的軒轅系列將助力显示領域的智能化落地，提高產品價值！

　　越影系列車載智能 DVR 芯片發布

　　正如前面所提到的，星宸科技去年在 1080P 車載 DVR 芯片市場拿下了第一的市場份額。而這也得益於其此前推出的 SSC832X 和 SSC83X 兩款 DVR 芯片被小米、凌度等超百家終端客戶的採用。

　　此次，針對 DVR 市場對於 4K+AI 的需求，星宸科技發布了全新的“越影”系列車載智能 DVR 芯片：SSC8629D、SSC8629Q、SSC8668G、SSC8539，提供 Arm 多核，同時內置自主研發的 NPU 內核、CEVA DSP 內核版本。

　　在車載智能 DVR 產品中，高解析率的視頻處理可以讓用戶還原更加真實的行車場景，車主可以實時預覽高品質圖像，同時可以保證有效的視頻取證、高質量的視頻分享等後續操作，輔以先進的編碼格式H.264/H.265，可以大幅地提升壓縮效率，提高存儲空間的利用率。

　　星宸科技越影系列在高清 1080P，超高清 4K 等高解析度的視頻前處理/后處理，編解碼有深厚的積累，並且可以同時接入多通道視頻進行處理，滿足車載 DVR 市場差異化應用的需求。

　　此外，行業車輛、准前裝/前裝車輛對 SoC 有着高標準的安全等級要求，需要其能抵禦大範圍溫度波動的要求，星宸科技此前已經針對這些市場系列化地推出滿足工業級溫度特性的 SSC8339、SSC8668G。

　　此次，星宸科技還推出了首款支持 AEC-Q100 認證的車規芯片 SSC8539，以適應產品需求。

　　星宸科技越影系列芯片市場負責人朱傑表示，伴隨着汽車產業的快速發展，基於行車安全性的考慮，車載視頻實時監控，存儲，分享等功能越來越多的在車載產品形態中出現，智能化應用也呈逐年增長的態勢。星宸科技的車載類芯片從開發之初就致力於圍繞視頻圖像處理的核心能力，不斷滿足客戶需求，力求打造出中國最好的汽車电子半導體產品。

　　內置自研 NPU 內核，“降龍”系列 IPC 芯片發布

　　針對目前增長最快，星宸科技重點布局的 IPC 芯片市場，星宸科技發布了全新的集成了自主研發的 NPU 內核的“降龍”系列 IPC 芯片：SSC336D/Q，SSC338G，SSC339G。

　　降龍系列智能芯片市場負責人賀曉明表示，隨着人工智能技術的發展，IPC 市場也對於 IPC 芯片的“智能化”提出了更高的要求。一顆合格的“智能”IPC 不僅需要看得清、聽得見、穩定可靠，還需要集成按照場景優化的 NPU，並且還要能夠買得起。但是，目前市場上能夠提供高質量圖像效果、算法兼容性好、功耗低、價格親民的智能 IPC 芯片非常少。也缺少一款解碼能力高、支持高分辨率、集成度高的 NVR 芯片，這些對推動安防的智能化普及至關重要。因此，星宸科技推出了“降龍”系列 IPC 芯片。

　　“降龍”系列 IPC 芯片不僅配備了專業級的智能音頻 codec，支持超高信噪比 AD/DA、多路麥克風陣列、嘈雜及遠距離環境下的清晰拾音、關閉關鍵詞識別、異常聲源報警、雙向語音對講下的回聲抑制。同時，“降龍”系列 IPC 芯片還集成了專業級的 ISP，支持數千倍以上增益的降噪技術，顯著提升夜視亮度，減少動態拖影，並維持鮮艷的色彩，提供超星光級夜視效果，還支持多次曝光合成 HDR 技術。

　　更為關鍵的是，“降龍”系列 IPC 芯片內置了星宸科技自研的“降龍”NPU 內核，具有兼容性好（支持 Caffe/TensorFlow 兩大主流 AI 開發平台）、覆蓋面廣（同時支持 Int8、Int16，可滿足不同場景下的精度需求）、容易開發（提供 C Model 驗證與完整的開發工具鏈）、極高效率（針對網絡模型提供芯片級的硬件加速優化）等四大優勢。可實現人體偵測、運動追蹤、姿態檢測、人臉識別對比、面部表情偵測、寵物偵測、車型款式/車牌識別等智能化視頻分析需求。

　　據介紹，“降龍”系列 IPC 芯片基於台積電 22/12nm 工藝，支持 LPDDR2/DDR3L，可選配混合式操作系統，同時還支持 Secure Boot 安全啟動，可避免一些安全隱患。在具體性能方面，SSC336D/Q支持 1080P/3M@30FPS，算力 0.5TOPs；SSC338G 支持4/5M@30fps，算力 1TOPs；SSC339G 支持 4K@30FPS。可以實現高中低階市場的全面覆蓋。

　　星宸科技表示，SSC336D/Q，SSC338G SDK/EVB 將於今年 12 月正式推出，SSC339G 將於明年 3 月推出。

　　小結：

　　“目前我們已經發布了多達 6 個系列的安防 IPC 主控芯片及 NVR 芯片，攜手各大合作夥伴，致力於讓 AI 技術用得起、用得好、用得廣，讓客戶滿意。”降龍系列智能芯片市場負責人賀曉明表示，隨着視頻監控高清化的普及和人工智能算法的發展，市場催生了智能家居、智慧交通、智慧城市、平安城市、雪亮工程等需求，行業需求已經從看得清轉變為看得懂。高清的海量數據如果都交由平台去處理會造成計算量巨大和時間滯后的問題，市場對邊緣端智能的需求大漲。

　　在此趨勢之下，星宸科技在軒轅系列智能显示芯片、越影系列車載智能 DVR 芯片、降龍系列智能安防芯片等新品的加持下，AI 芯片產品覆蓋會更加全面，產品競爭力也將進一步提升。

　　值得注意的是，在安防監控 IPC 芯片市場，星宸科技在 2018 年也成功進入了全球第三。同時，星宸科技還在現場表示，其 2019 年出貨將居全球第二。可以說這距離星宸科技未來希望拿下安防監控芯片市場的全球第一的目標又近了一步。

　　不過，目前華為海思在安防監控芯片市場牢牢佔據着第一的位置。此前有數據显示，華為佔據了國內安防監控芯片市場約 70% 的市場份額。不過，近兩年來，憑藉極高性價比，星宸科技和富瀚微等廠商已經從華為海思手上搶下了了一些的份額。

　　另外，在目前華為本身開始進入安防監控市場，與海思在安防監控市場的合作夥伴產生競爭的之勢的情況之下，目前海康、大華等頭部的安防監控廠商也開始紛紛自研，同時也在尋找新的可選方案，以避免對於海思的過渡依賴。而這似乎也正是星宸科技的機會所在。

　　另外一個重要的機會點是，星宸科技看到了安防市場對於 AI 計算的巨大需求，正因為如此，星宸科技也率先推出了集成自研 NPU 內核的降龍系列 IPC 芯片，以爭奪市場。

　　不過，即便如此，星宸科技想要搶下華為海思在安防監控市場的第一寶座，可謂是難度極大。至少在可見的未來兩三年內，幾乎是不可能，除非得到海康、大華、宇視等安防監控市場龍頭企業的全力支持。長期來看，星宸科技如果能坐穩第二的位置，並持續擴大份額，徐徐圖之，還是有機會與海思一教高下的，畢竟其背後還有着聯發科的助力。

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

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

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

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

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

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