分類
發燒車訊

不看好歐洲純電動車市場,BMW 高層:監管機構想要,但沒有顧客真的需要

電動車已成為多數車商的發展趨勢,然而近日在慕尼黑舉行的 NextGen 活動期間,BMW 執行董事 Klaus Fröhlich 卻語出驚人的表示,他認為電動車轉型被過度吹捧,實際上消費者對這些車輛根本沒有需求。

考量到 BMW 日前才宣布將加速純電動車發展計畫,Fröhlich 的發言看似大膽,但其實並非沒有道理。據了解,這項發言主要是針對遊說團體 Transport and Environment 日前公開譴責歐洲車商的回應。

該篇報告 T&E 引述 EEA 的最新排氣數據,指出歐洲在電動車銷售明顯落後中美兩國,主要原因是市場純電動車的選擇和可用性都受侷限,而 T&E 認為,這是因為歐洲車商故意推遲純電動車的銷售計畫,好最大程度提高燃油車的利潤,「在環境方面,車商只會做法律規定他們要做的事情」。

對這項指控,Fröhlich 表示,他認為 T&E 忽略了最重要的問題:那就是歐洲客戶實際上並不想買純電動車。

Fröhlich 解釋,與美國人為不同目的駕駛不同車輛的習慣不同,歐洲人通常是「單車家庭」,車庫中只會有一輛車使用,因此他們並不願完全依賴純電動車,不應該拿美國的市場情況來比較。

除此之外,還有充電基礎設施的普及問題,Fröhlich 認為,柴油引擎至少還有 20 年、汽油引擎至少還有 30 年,即使是俄羅斯、中東、中國中西部地區這些市場,在缺乏基礎建設下,燃油引擎都至少還有 10~15 年時間。

「純電動車只適用中國、美國加州市場,至於其他地方,有更大電池的混合式動力車應該是更好的選擇。」

除了基礎設施普及,Fröhlich 也指出,在電池原始材料,純電動車的成本要遠高於燃油或混合動力車,隨著未來市場對電池原料的需求增加,一旦供應鏈無法支持,那麼價格可能只會有增無減。

Fröhlich 表示,如果政府能提供許多協助,BMW 可生產足以淹沒歐洲的百萬台純電動車,但在他看來,歐洲人並不想買這些東西,「監管機構想要純電動車,但沒有顧客真的需要。」

(合作媒體:。首圖來源: CC BY 2.0)

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

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

分類
發燒車訊

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

  來源:我是科學家 iScientist

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

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

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

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

卡文迪許

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

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

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

卡文迪許

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

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

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

卡文迪許

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

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

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

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

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

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

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

卡文迪許

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

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

卡文迪許家裡的餐廳

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

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

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

卡文迪許

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

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

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

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

英國皇家學會

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

氫氣球爆炸

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

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

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

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

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

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

卡文迪許設計的扭稱模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

夏爾·奧古斯丁·庫侖

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

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

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

格奧爾格·西蒙·歐姆

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

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

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

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

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

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

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

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

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

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

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

分類
發燒車訊

坑~夏令時冬令時引發的時間換算問題

 

起因

最近接觸到一些國外的項目,由於國內外有時差這個東西,對於某些基礎數據存到數據庫的時候需要記錄時間,為了方便,這裏採用了時間戳(int或者timestamp)記錄。由於時間戳全球都是一樣的,需要的時候根據時區進行轉換就能夠拿到當地的時間。

嗯~ o(* ̄▽ ̄*)o,這樣看起來確實沒什麼毛病。眾所周知,一天有24小時,換算成秒就是:24*60*60=86400秒。

然而,我在某次使用 MySql 的 FROM_UNIXTIME 發現一個問題,兩個時間相差86400秒,但是格式化之後卻不是相差一天!!!

假設北京時間2019年11月25日 12:00:00,對應的時間戳是:1574654400,照理說這個時間戳加上一天86400秒,理論上就是北京時間2019年11月26日 12:00:00,事實上確實如此,國內的話這麼算確實沒什麼問題,但是如果是國外時區的話,那可能會出問題。

由於國外部分國家有夏令時冬令時之分(具體下面會細說),直接加上86400秒可能會有問題。

感興趣的可以拿1572764400(太平洋時間2019-11-03 00:00:00,單位:)這個時間戳驗證下

拿代碼演示下:

PHP:

<?php

echo "PST時區的時間\n";
date_default_timezone_set('PST8PDT');
echo date('Y-m-d H:i:s',1572764400);
echo "\n";
echo date('Y-m-d H:i:s',1572764400+86400);
echo "\n";

//換個時區
echo "換成上海時區看看\n";
date_default_timezone_set('Asia/Shanghai');
echo date('Y-m-d H:i:s',1572764400);
echo "\n";
echo date('Y-m-d H:i:s',1572764400+86400);
echo "\n";

運行結果:

PST時區的時間
2019-11-03 00:00:00
2019-11-03 23:00:00
換成上海時區看看
2019-11-03 15:00:00
2019-11-04 15:00:00

明明是同一個時間戳,都是加上86400(一天),為什麼在上海這個時區是第二天,而在PST(美國太平洋時區)只加了23小時?神不神奇!意不意外!

為了弄清楚這個問題,首先得先了解下什麼是夏令時,什麼是冬令時

 

夏令時

夏令時,表示為了節約能源,人為規定時間的意思。也叫夏時制,夏時令(Daylight Saving Time:DST),又稱“日光節約時制”和“夏令時間”,在這一制度實行期間所採用的統一時間稱為“夏令時間”。

一般在天亮早的夏季人為將時間調快一小時,可以使人早起早睡,減少照明量,以充分利用光照資源,從而節約照明用電。各個採納夏時制的國家具體規定不同。目前全世界有近110個國家每年要實行夏令時。[1]

 

冬令時

有夏令時就會有冬令時。高緯度和中緯度的許多國家在夏季到來前,把時針撥快一小時,新的時間就是夏令時,到下半季秋季來臨前,再把時針撥回一小時,即形成冬令時。 [2] 

 

夏令時和冬令時的影響

拿美國來說,美國各個地區的時間都不同,不像中國一樣統一使用北京時間,美國一般以三月份第二個周日凌晨兩點當成夏季的開始,十一月份第一個周日的凌晨兩點當成冬季的開始。

所以在每年的三月份第二個周日凌晨兩點過後,時間就會往前調快一個小時;同理,十一月份第一個周日把這一個小時調回來

你也可以理解成美國那邊,一年裡面有一天只有23小時(夏天開始那一天),有一天有25小時(冬天開始那一天),其他時間每天都是24小時。

所以你會發現,夏天的時候,中國的北京時間(東八區)與美國太平洋時區(西八區)的時差是15小時,而到了冬天卻變成16小時

 

解決方案

回到開頭那個問題,如果我們想直接算第二天,直接加上86400(一天)可能在其他國家就會有我上面那個夏令時和冬令時時間換算的問題,要如何避免呢?首先能夠確定的是,直接加上86400是不可取的,如果加上一天能否行得通

PHP:

<?php

echo "PST時區的時間\n";
date_default_timezone_set('PST8PDT');
echo date('Y-m-d H:i:s',1572764400);
echo "\n";
echo date('Y-m-d H:i:s',1572764400+86400);
echo "\n";

echo "--------------------------\n";
echo date('Y-m-d H:i:s',1572764400);
echo "\n";
echo date('Y-m-d H:i:s',strtotime('+1 day',1572764400));
echo "\n";

運行結果:

PST時區的時間
2019-11-03 00:00:00
2019-11-03 23:00:00
--------------------------
2019-11-03 00:00:00
2019-11-04 00:00:00

可以看出,不直接加上86400,直接在日期上加上一天是完全沒問題的。

JavaScript:

var date = new Date(1572764400*1000);
date.setDate(date.getDate()+1);
var timestamp = Math.round(date.getTime()/1000);

注意:JS的時間戳是毫秒!!!

 

結論

在經濟全球化快速發展的今天,在軟件開發的過程中,盡量養成習慣,由於夏令時和冬令時不是固定的,開發在時間計算上應該慎用86400進行加減運算,時間計算請直接對日期進行加減,展示時間給用戶看的時候盡量結合當地時間,結合夏令時和冬令時計算出準確的當地時間,避免產生不必要的分歧。

 

參考:

[1]. 

[2]. 

 

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

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置台北網頁設計,各種案例分享

分類
發燒車訊

.NET高級特性-Emit(2)類的定義,.NET高級特性-Emit(1)

  在上一篇博文發了一天左右的時間,就收到了博客園許多讀者的評論和推薦,非常感謝,我也會及時回復讀者的評論。之後我也將繼續撰寫博文,梳理相關.NET的知識,希望.NET的圈子能越來越大,開發者能了解/深入.NET的本質,將工作做的簡單又高效,拒絕重複勞動,拒絕CRUD。

  ok,咱們開始繼續Emit的探索。在這之前,我先放一下我往期關於Emit的文章,方便讀者閱讀。

  《》

一、基礎知識

  既然C#作為一門面向對象的語言,所以首當其沖的我們需要讓Emit為我們動態構建類。

  廢話不多說,首先,我們先來回顧一下C#類的內部由什麼東西組成:

  (1) 字段-C#類中保存數據的地方,由訪問修飾符、類型和名稱組成;

  (2) 屬性-C#類中特有的東西,由訪問修飾符、類型、名稱和get/set訪問器組成,屬性的是用來控制類中字段數據的訪問,以實現類的封裝性;在Java當中寫作getXXX()和setXXX(val),C#當中將其變成了屬性這種語法糖;

  (3) 方法-C#類中對邏輯進行操作的基本單元,由訪問修飾符、方法名、泛型參數、入參、出參構成;

  (4) 構造器-C#類中一種特殊的方法,該方法是專門用來創建對象的方法,由訪問修飾符、與類名相同的方法名、入參構成。

  接着,我們再觀察C#類本身又具備哪些東西:

  (1) 訪問修飾符-實現對C#類的訪問控制

  (2) 繼承-C#類可以繼承一個父類,並需要實現父類當中所有抽象的方法以及選擇實現父類的虛方法,還有就是子類需要調用父類的構造器以實現對象的創建

  (3) 實現-C#類可以實現多個接口,並實現接口中的所有方法

  (4) 泛型-C#類可以包含泛型參數,此外,類還可以對泛型實現約束

  以上就是C#類所具備的一些元素,以下為樣例:

public abstract class Bar
{
    public abstract void PrintName();
}
public interface IFoo<T> { public T Name { get; set; } } //繼承Bar基類,實現IFoo接口,泛型參數T
public class Foo<T> : Bar, IFoo<T>
  //泛型約束
  where T : struct {
//構造器 public Foo(T name):base() { _name = name; } //字段 private T _name; //屬性 public T Name { get => _name; set => _name = value; } //方法 public override void PrintName() {
    Console.WriteLine(_name.ToString()); }
}

  在探索完了C#類及其定義后,我們要來了解C#的項目結構組成。我們知道C#的一個csproj項目最終會對應生成一個dll文件或者exe文件,這一個文件我們稱之為程序集Assembly;而在一個程序集中,我們內部包含和定義了許多命名空間,這些命令空間在C#當中被稱為模塊Module,而模塊正是由一個一個的C#類Type組成。

 

 

 

   所以,當我們需要定義C#類時,就必須首先定義Assembly以及Module,如此才能進行下一步工作。

二、IL概覽

   由於Emit實質是通過IL來生成C#代碼,故我們可以反向生成,先將寫好的目標代碼寫成cs文件,通過編譯器生成dll,再通過ildasm查看IL代碼,即可依葫蘆畫瓢的編寫出Emit代碼。所以我們來查看以下上節Foo所生成的IL代碼。

  

 

 

   從上圖我們可以很清晰的看到.NET的層級結構,位於樹頂層淺藍色圓點表示一個程序集Assembly,第二層藍色表示模塊Module,在模塊下的均為我們所定義的類,類中包含類的泛型參數、繼承類信息、實現接口信息,類的內部包含構造器、方法、字段、屬性以及它的get/set方法,由此,我們可以開始編寫Emit代碼了

三、Emit編寫

  有了以上的對C#類的解讀和IL的解讀,我們知道了C#類本身所需要哪些元素,我們就開始根據這些元素來開始編寫Emit代碼了。這裏的代碼量會比較大,請讀者慢慢閱讀,也可以參照以上我寫的類生成il代碼進行比對。

  在Emit當中所有創建類型的幫助類均以Builder結尾,從下錶中我們可以看的非常清楚

元素中文 元素名稱 對應Emit構建器名稱
程序集  Assembly AssemblyBuilder
模塊  Module ModuleBuilder
 Type TypeBuilder
構造器  Constructor ConstructorBuilder
屬性  Property PropertyBuilder
字段  Field FieldBuilder
方法  Method MethodBuilder

  由於創建類需要從Assembly開始創建,所以我們的入口是AssemblyBuilder

  (1) 首先,我們先引入命名空間,我們以上節Foo類為樣例進行編寫

using System.Reflection.Emit;

  (2) 獲取基類和接口的類型

var barType = typeof(Bar);
var interfaceType = typeof(IFoo<>);

  (3) 定義Foo類型,我們可以看到在定義類之前我們需要創建Assembly和Module

//定義類
var assemblyBuilder = AssemblyBuilder.DefineDynamicAssembly(new AssemblyName("Edwin.Blog.Emit"), AssemblyBuilderAccess.Run);
var moduleBuilder = assemblyBuilder.DefineDynamicModule("Edwin.Blog.Emit");
var typeBuilder = moduleBuilder.DefineType("Foo", TypeAttributes.Public | TypeAttributes.Class | TypeAttributes.AutoClass | TypeAttributes.AnsiClass | TypeAttributes.BeforeFieldInit);

  (4) 定義泛型參數T,並添加約束

//定義泛型參數
var genericTypeBuilder = typeBuilder.DefineGenericParameters("T")[0];
//設置泛型約束
genericTypeBuilder.SetGenericParameterAttributes(GenericParameterAttributes.NotNullableValueTypeConstraint);

  (5) 繼承和實現接口,注意當實現類的泛型參數需傳遞給接口時,需要將泛型接口添加泛型參數后再調用AddInterfaceImplementation方法

//繼承基類
typeBuilder.SetParent(barType);
//實現接口
typeBuilder.AddInterfaceImplementation(interfaceType.MakeGenericType(genericTypeBuilder));

  (6) 定義字段,因為字段在構造器值需要使用,故先創建

//定義字段
var fieldBuilder = typeBuilder.DefineField("_name", genericTypeBuilder, FieldAttributes.Private);

  (7) 定義構造器,並編寫內部邏輯

//定義構造器
var ctorBuilder = typeBuilder.DefineConstructor(MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.SpecialName | MethodAttributes.RTSpecialName, CallingConventions.Standard, new Type[] { genericTypeBuilder });
var ctorIL = ctorBuilder.GetILGenerator();
//Ldarg_0在實例方法中表示this,在靜態方法中表示第一個參數
ctorIL.Emit(OpCodes.Ldarg_0);
ctorIL.Emit(OpCodes.Ldarg_1);
//為field賦值
ctorIL.Emit(OpCodes.Stfld, fieldBuilder);
ctorIL.Emit(OpCodes.Ret);

  (8) 定義Name屬性

//定義屬性
var propertyBuilder = typeBuilder.DefineProperty("Name", PropertyAttributes.None, genericTypeBuilder, Type.EmptyTypes);

  (9) 編寫Name屬性的get/set訪問器

//定義get方法
var getMethodBuilder = typeBuilder.DefineMethod("get_Name", MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.NewSlot | MethodAttributes.SpecialName | MethodAttributes.Virtual, CallingConventions.Standard, genericTypeBuilder, Type.EmptyTypes);
var getIL = getMethodBuilder.GetILGenerator();
getIL.Emit(OpCodes.Ldarg_0);
getIL.Emit(OpCodes.Ldfld, fieldBuilder);
getIL.Emit(OpCodes.Ret);
typeBuilder.DefineMethodOverride(getMethodBuilder, interfaceType.GetProperty("Name").GetGetMethod()); //實現對接口方法的重載
propertyBuilder.SetGetMethod(getMethodBuilder); //設置為屬性的get方法
//定義set方法
var setMethodBuilder = typeBuilder.DefineMethod("set_Name", MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.NewSlot | MethodAttributes.SpecialName | MethodAttributes.Virtual, CallingConventions.Standard, null, new Type[] { genericTypeBuilder });
var setIL = setMethodBuilder.GetILGenerator();
setIL.Emit(OpCodes.Ldarg_0);
setIL.Emit(OpCodes.Ldarg_1);
setIL.Emit(OpCodes.Stfld, fieldBuilder);
setIL.Emit(OpCodes.Ret);
typeBuilder.DefineMethodOverride(setMethodBuilder, interfaceType.GetProperty("Name").GetSetMethod()); //實現對接口方法的重載
propertyBuilder.SetSetMethod(setMethodBuilder); //設置為屬性的set方法

   (10) 定義並實現PrintName方法

//定義方法
var printMethodBuilder = typeBuilder.DefineMethod("PrintName", MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.Virtual, CallingConventions.Standard, null, Type.EmptyTypes);
var printIL = printMethodBuilder.GetILGenerator();
printIL.Emit(OpCodes.Ldarg_0);
printIL.Emit(OpCodes.Ldflda, fieldBuilder);
printIL.Emit(OpCodes.Constrained, genericTypeBuilder);
printIL.Emit(OpCodes.Callvirt, typeof(object).GetMethod("ToString", Type.EmptyTypes));
printIL.Emit(OpCodes.Call, typeof(Console).GetMethod("WriteLine", new Type[] { typeof(string) }));
printIL.Emit(OpCodes.Ret);
//實現對基類方法的重載
typeBuilder.DefineMethodOverride(printMethodBuilder, barType.GetMethod("PrintName", Type.EmptyTypes));

  (11) 創建類

var type = typeBuilder.CreateType(); //netstandard中請使用CreateTypeInfo().AsType()

  (12) 調用

var obj = Activator.CreateInstance(type.MakeGenericType(typeof(DateTime)), DateTime.Now);
(obj as Bar).PrintName();
Console.WriteLine((obj as IFoo<DateTime>).Name);

四、應用

  上面的樣例僅供學習只用,無法運用在實際項目當中,那麼,Emit構建類在實際項目中我們可以有什麼應用,提高我們的編碼效率

  (1) 動態DTO-當我們需要將實體映射到某個DTO時,可以用動態DTO來代替你手寫的DTO,選擇你需要的字段回傳給前端,或者前端把他想要的字段傳給後端

  (2) DynamicLinq-我的第一篇博文有個讀者提到了表達式樹,而linq使用的正是表達式樹,當表達式樹+Emit時,我們就可以用像SQL或者GraphQL那樣的查詢語句實現動態查詢

  (3) 對象合併-我們可以編寫實現一個像js當中Object.assign()一樣的方法,實現對兩個實體的合併

  (4) AOP動態代理-AOP的核心就是代理模式,但是與其對應的是需要手寫代理類,而Emit就可以幫你動態創建代理類,實現切面編程

  (5) …

五、小結

  對於Emit,確實初學者會對其感到複雜和難以學習,但是只要搞懂其中的原理,其實最終就是C#和.NET語言的本質所在,在學習Emit的同時,也是在鍛煉你的基本功是否紮實,你是否對這門語言精通,是否有各種簡化代碼的應用。

  保持學習,勇於實踐;Write Less,Do More;作者之後還會繼續.NET高級特性系列,感謝閱讀!

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

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

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

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

分類
發燒車訊

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 是電子產業重要的元件?

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

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

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

分類
發燒車訊

Java虛擬機詳解(十)——類加載過程

  在上一篇文章中,我們詳細的介紹了Java,那麼這些Class文件是如何被加載到內存,由虛擬機來直接使用的呢?這就是本篇博客將要介紹的——類加載過程。

1、類的生命周期

  類從被加載到虛擬機內存開始,到卸載出內存為止,其聲明周期流程如下:

  

  上圖中紅色的5個部分(加載、驗證、準備、初始化、卸載)順序是確定的,也就是說,類的加載過程必須按照這種順序按部就班的開始。這裏的“開始”不是按部就班的“進行”或者“完成”,因為這些階段通常是互相交叉混合的進行的,通常會在一個階段執行過程中調用另一個階段。

2、加載

  “加載”階段是“類加載”生命周期的第一個階段。在加載階段,虛擬機要完成下面三件事:

  ①、通過一個類的全限定名來獲取定義此類的二進制字節流。

  ②、將這個字節流所代表的靜態存儲結構轉化為方法區的運行時數據結構。

  ③、在Java堆中生成一個代表這個類的java.lang.Class對象,作為方法區這些數據的訪問入口。

  PS:類的全限定名可以理解為這個類存放的絕對路徑。方法區是JDK1.7以前定義的運行時數據區,而在JDK1.8以後改為元數據區(Metaspace),主要用於存放被Java虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯后的代碼等數據。詳情可以參考這邊該系列的第二篇文章——。

  另外,我們看第一點——通過類的權限定名來獲取定義此類的二進制流,這裏並沒有明確指明要從哪裡獲取以及怎樣獲取,也就是說並沒有明確規定一定要我們從一個 Class 文件中獲取。基於此,在Java的發展過程中,充滿創造力的開發人員在這個舞台上玩出了各種花樣:

  1、從 ZIP 包中讀取。這稱為後面的 JAR、EAR、WAR 格式的基礎。

  2、從網絡中獲取。比較典型的應用就是 Applet。

  3、運行時計算生成。這就是動態代理技術。

  4、由其它文件生成。比如 JSP 應用。

  5、從數據庫中讀取。

  加載階段完成后,虛擬機外部的二進制字節流就按照虛擬機所需的格式存儲在方法區中,然後在Java堆中實例化一個 java.lang.Class 類的對象,這個對象將作為程序訪問方法區中這些類型數據的外部接口。

  注意,加載階段與連接階段的部分內容(如一部分字節碼文件的格式校驗)是交叉進行的,加載階段尚未完成,連接階段可能已經開始了。

3、驗證

  驗證是連接階段的第一步,作用是為了確保 Class 文件的字節流中包含的信息符合當前虛擬機的要求,並且不會危害虛擬機自身的安全。

  我們說Java語言本身是相對安全,因為編譯器的存在,純粹的Java代碼要訪問數組邊界外的數據、跳轉到不存在的代碼行之類的,是要被編譯器拒絕的。但是前面我們也說過,Class 文件不一定非要從Java源碼編譯過來,可以使用任何途徑,包括你很牛逼,直接用十六進制編輯器來編寫 Class 文件。

  所以,如果虛擬機不檢查輸入的字節流,將會載入有害的字節流而導致系統崩潰。但是虛擬機規範對於檢查哪些方面,何時檢查,怎麼檢查都沒有明確的規定,不同的虛擬機實現方式可能都會有所不同,但是大致都會完成下面四個方面的檢查。

①、文件格式驗證

  校驗字節流是否符合Class文件格式的規範,並且能夠被當前版本的虛擬機處理。

  一、是否以魔數 0xCAFEBABE 開頭。

  二、主、次版本號是否是當前虛擬機處理範圍之內。

  三、常量池的常量中是否有不被支持的常量類型(檢查常量tag標誌)

  四、指向常量的各種索引值中是否有指向不存在的常量或不符合類型的常量。

  五、CONSTANT_Utf8_info 型的常量中是否有不符合 UTF8 編碼的數據。

  六、Class 文件中各個部分及文件本身是否有被刪除的或附加的其他信息。

  以上是一部分校驗內容,當然遠不止這些。經過這些校驗后,字節流才會進入內存的方法區中存儲,接下來後面的三個階段校驗都是基於方法區的存儲結構進行的。

②、元數據驗證

  第二個階段主要是對字節碼描述的信息進行語義分析,以保證其描述的信息符合Java語言規範要求。

  一、這個類是否有父類(除了java.lang.Object 類之外,所有的類都應當有父類)。

  二、這個類的父類是否繼承了不允許被繼承的類(被final修飾的類)。

  三、如果這個類不是抽象類,是否實現了其父類或接口之中要求實現的所有普通方法。

  四、類中的字段、方法是否與父類產生了矛盾(例如覆蓋了父類的final字段、或者出現不符合規則的重載)

③、字節碼驗證

  第三個階段字節碼驗證是整個驗證階段中最複雜的,主要是進行數據流和控制流分析。該階段將對類的方法進行分析,保證被校驗的方法在運行時不會做出危害虛擬機安全的行為。

  一、保證任意時刻操作數棧中的數據類型與指令代碼序列都能配合工作。例如不會出現在操作數棧中放置了一個 int 類型的數據,使用時卻按照 long 類型來加載到本地變量表中。

  二、保證跳轉指令不會跳轉到方法體以外的字節碼指令中。

  三、保證方法體中的類型轉換是有效的。比如把一個子類對象賦值給父類數據類型,這是安全的。但是把父類對象賦值給子類數據類型,甚至賦值給完全不相干的類型,這就是不合法的。

④、符號引用驗證

  符號引用驗證主要是對類自身以外(常量池中的各種符號引用)的信息進行匹配性的校驗,通常需要校驗如下內容:

  一、符號引用中通過字符串描述的全限定名是否能夠找到相應的類。

  二、在指定類中是否存在符合方法的字段描述符及簡單名稱所描述的方法和字段。

  三、符號引用中的類、字段和方法的訪問性(private、protected、public、default)是否可以被當前類訪問。

4、準備

  準備階段是正式為類變量分配內存並設置類變量初始值的階段,這些內存是在方法區中進行分配。

  注意:

  一、上面說的是類變量,也就是被 static 修飾的變量,不包括實例變量。實例變量會在對象實例化時隨着對象一起分配在堆中。

  二、初始值,指的是一些數據類型的默認值。基本的數據類型初始值如下(引用類型的初始值為null):

  

 

   比如,定義 public static int value = 123 。那麼在準備階段過後,value 的值是 0 而不是 123,把 value 賦值為123 是在程序被編譯后,存放在類的構造器方法之中,是在初始化階段才會被執行。但是有一種特殊情況,通過final 修飾的屬性,比如 定義 public final static int value = 123,那麼在準備階段過後,value 就被賦值為123了。

5、解析

  解析階段是虛擬機將常量池中的符號引用替換為直接引用的過程。

  符號引用(Symbolic References):符號引用以一組符號來描述所引用的目標,符號可以是任何形式的字面量,只要使用時能無歧義的定位到目標即可。符號引用與虛擬機實現的內存布局無關,引用的目標不一定已經加載到內存中。

  直接引用(Direct References):直接引用可以是直接指向目標的指針、相對偏移量或是一個能間接定位到目標的句柄。直接引用是與虛擬機實現內存布局相關的,同一個符號引用在不同虛擬機實例上翻譯出來的直接引用一般不會相同。如果有了直接引用,那麼引用的目標必定已經在內存中存在。

  解析動作主要針對類或接口、字段、類方法、接口方法四類符號引用,分別對應於常量池的 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANTS_InterfaceMethodref_info四種類型常量。

6、初始化

   初始化階段是類加載階段的最後一步,前面過程中,除第一個加載階段可以通過用戶自定義類加載器參与之外,其餘過程都是完全由虛擬機主導和控制。而到了初始化階段,則開始真正執行類中定義的Java程序代碼(或者說是字節碼)。

  在前面介紹的準備階段中,類變量已經被賦值過初始值了,而初始化階段,則根據程序員的編碼去初始化變量和資源。

  換句話來說,初始化階段是執行類構造器<clinit>() 方法的過程

  ①、<clinit>() 方法 是由編譯器自動收集類中的所有類變量的賦值動作和靜態語句塊(static{})中的語句合併產生的,編譯器收集的順序是由語句在源文件中出現的順序所決定的,靜態語句塊中只能訪問到定義在靜態語句塊之前的變量,定義在它之後的變量,在前面的靜態語句塊中可以賦值,但是不能訪問。

  比如如下代碼會報錯:

  

 

   但是你把第 14 行代碼放到 static 靜態代碼塊的上面就不會報錯了。或者不改變代碼順序,將第 11 行代碼移除,也不會報錯。

  ②、<clinit>() 方法與類的構造函數(或者說是實例構造器<init>()方法)不同,它不需要显示的調用父類構造器,虛擬機會保證在子類的<init>()方法執行之前,父類的<init>()方法已經執行完畢。因此虛擬機中第一個被執行的<init>()方法的類肯定是 java.lang.Object。

  ③、由於父類的<clinit>() 方法先執行,所以父類中定義的靜態語句塊要優先於子類的變量賦值操作。

  ④、<clinit>() 方法對於接口來說並不是必須的,如果一個類中沒有靜態語句塊,也沒有對變量的賦值操作,那麼編譯器可以不為這個類生成<clinit>() 方法。

  ⑤、接口中不能使用靜態語句塊,但仍然有變量初始化的賦值操作,因此接口與類一樣都會生成<clinit>() 方法。但接口與類不同的是,執行接口中的<clinit>() 方法不需要先執行父接口的<clinit>() 方法。只有當父接口中定義的變量被使用時,父接口才會被初始化。

  ⑥、接口的實現類在初始化時也一樣不會執行接口的<clinit>() 方法。

  ⑦、虛擬機會保證一個類的<clinit>() 方法在多線程環境中被正確的加鎖和同步。如果多個線程同時去初始化一個類,那麼只會有一個線程去執行這個類的<clinit>() 方法,其他的線程都需要阻塞等待,直到活動線程執行<clinit>() 方法完畢。如果在一個類的<clinit>() 方法中有很耗時的操作,那麼可能造成多個進程的阻塞。

  比如對於如下代碼:

package com.yb.carton.controller;

/**
 * Create by YSOcean
 */
public class ClassLoadInitTest {


    static class Hello{
        static {
            if(true){
                System.out.println(Thread.currentThread().getName() + "init");
                while(true){}
            }
        }
    }

    public static void main(String[] args) {
        new Thread(()->{
            System.out.println(Thread.currentThread().getName()+"start");
            Hello h1 = new Hello();
            System.out.println(Thread.currentThread().getName()+"run over");
        }).start();


        new Thread(()->{
            System.out.println(Thread.currentThread().getName()+"start");
            Hello h2 = new Hello();
            System.out.println(Thread.currentThread().getName()+"run over");
        }).start();
    }

}

View Code

  運行結果如下:

  

 

   線程1搶到了執行<clinit>() 方法,但是該方法是一個死循環,線程2將一直阻塞等待。

  知道了類的初始化過程,那麼類的初始化何時被觸發呢?JVM大概規定了如下幾種情況:

  ①、當虛擬機啟動時,初始化用戶指定的類。

  ②、當遇到用以新建目標類實例的 new 指令時,初始化 new 指定的目標類。

  ③、當遇到調用靜態方法的指令時,初始化該靜態方法所在的類。

  ④、當遇到訪問靜態字段的指令時,初始化該靜態字段所在的類。

  ⑤、子類的初始化會觸發父類的初始化。

  ⑥、如果一個接口定義了 default 方法,那麼直接實現或間接實現該接口的類的初始化,會觸發該接口的初始化。

  ⑦、使用反射 API 對某個類進行反射調用時,會初始化這個類。

  ⑧、當初次調用 MethodHandle 實例時,初始化該 MethodHandle 指向的方法所在的類。

 

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

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

分類
發燒車訊

豐田衝刺燃料電池車,傳產能將擴增至 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 是電子產業重要的元件?

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

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

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

分類
發燒車訊

搶攻 EV 需求,三菱化學傳倍增美國鋰電池關鍵材料產能

日刊工業新聞 3 日報導,為了搶攻電動車(EV)需求,三菱化學(Mitsubishi Chemical)將擴增鋰離子電池關鍵材料「電解液」產能,計畫於 2019 年度內(2020 年 3 月底前)將美國工廠(位於田納西州曼非斯)電解液年產能提高至 2 萬噸、將達現行的 2 倍水準。

三菱化學計畫於 2020 年度結束前(2021 年 3 月底前)將電解液全球年產能提高至 8.5 萬噸、將較 2017 年度大增 95%,且計畫將另一項鋰電池關鍵材料「負極材」全球年產能提高至 2.9 萬噸(將較 2017 年度增加 61%),目標在 2020 年度將電池材料等新能源部門營收提高至 1,000 億日圓、2025 年度進一步倍增至 2,000 億日圓的規模。

三菱化學 2018 年 12 月 26 日宣布,日本國內外電動車、插電式油電混合車(PHV)、油電混合車(HV)市場呈現急速擴大,因此將擴增日本「電解液」產能,計畫將四日市事業所的電解液年產能自現行的 1.1 萬噸大幅擴產約 5 成至 1.6 萬噸。

日韓企業紛紛擴增鋰離子電池關鍵材料產能

旭化成(Asahi Kasei)3 月 14 日宣布,因鋰離子電池以電動車等車用需求為中心呈現急速增長,故決議投資 300 億日圓對位於日本滋賀縣守山市的守山製造所、以及位於北卡羅萊納州的美國工廠進行增產投資,增產鋰離子電池關鍵材料「分隔膜」,上述增產工程預計於 2021 年度上半年開始商轉,預估 2021 年度旭化成分隔膜全球年產能將擴增至約 15.5 億平方公尺、將較 2018 年度末提高 1 倍。

住友化學(Sumitomo Chemical)日前也傳出將階段性提高南韓工廠產能,目標在 2021 年度將分隔膜總年產能(合併日本工廠產能計算)提高至 6 億平方公尺、將達現行的近 2 倍水準。

全球第 2 大鋰離子電池關鍵材料「分隔膜」廠商南韓 SK Innovation 5 月 27 日表示,計畫在 2025 年結束前將分隔膜產能提高至現行的 5 倍,SK Innovation 社長金俊 27 日在首爾舉行的記者會上表示,「目標藉由大規模增產、搶當全球龍頭」。在全球分隔膜市場上,日本旭化成市佔約 2 成、位居首位,SK Innovation 市佔率超過 1 成居次。

日本民間調查機構矢野經濟研究所公布調查報告指出,因中國自 2019 年起開始實施新能源車規範,加上 2019-2020 年期間日歐車廠將進行車輛電動化,提振車用鋰離子電池材料需求今後將持續擴大,預估 2020 年全球 4 大關鍵材料(正極材、負極材、電解液和分隔膜)市場規模(廠商出貨金額)將擴增至 281.46 億美元、將較 2017 年暴增 9 成(增加 91.3%)。

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

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

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

分類
發燒車訊

Chrome OS 80 將可以直接構建 Android 應用

  在近期 Android Dev Summit 上,Chrome OS 團隊宣布 Chrome OS 80 將使 Chromebook 可以直接構建 Android 應用。

  這項特性其實是在 Chrome OS 中引入 Android 應用側加載(sideloading),該功能的具體介紹來自一個非公開 bug 記錄以及相應的代碼更改,根據該記錄,Android 應用的側加載被帶到了 Chromebook 上的 Android 容器中。

  根據內部文件,具體開發時的操作是啟動 Crostini 容器時需要一個特殊命令(從 Chromebook 的命令行啟動 Linux 時),需要添加–enable-features = ArcAdbSideloading

  目前開發人員必須通過 USB 線將 Android 設備連接到 Chromebook,然後將其應用推送到設備上進行測試或使用 Chrome OS 開發人員模式,才能構建 Android 應用,但這兩種都不是理想的選擇。

  這項新特性對於使用 Android Studio 在 Chromebook 上構建其應用的 Android 開發人員來說,是極其方便的功能。具體來看,Chrome OS 80 將為 Android 開發人員添加選項,這樣可以直接在 Chrome OS 設備上安裝和測試其應用。

  消息來源:

  https://www.aboutchromebooks.com/news/chrome-os-80-to-bring-arc-sideloading-of-android-apps-to-chromebooks

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

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置台北網頁設計,各種案例分享

分類
發燒車訊

區塊鏈成重要突破口,與幣圈無關卻與5G有關

  幾乎是一夜之間,區塊鏈就成了更熱門的話題,此前,如果我們還在說“物聯網、大數據、雲計算、人工智能和 5G”,那麼,以後這一長串的背後可能就要加上“區塊鏈”。

  誠然,國家將區塊鏈當成戰略來發展,並“要把區塊鏈作為核心技術自主創新的重要突破口,明確主攻方向,加大投入力度,着力攻克一批關鍵核心技術,加快推動區塊鏈技術和產業創新發展”,這對整個區塊鏈產業都是巨大的利好,但是,這種利好卻實實在在與現在網絡上那些頂着區塊鏈帽子實際卻是在搞傳銷的“幣”們,毫無關係。如果有關係,那也一定是負面。

  在國內,區塊鏈技術佔據優勢的公司依然是 BAT,特別是阿里巴巴和螞蟻金服。在 2018 年的世界互聯網大會上,螞蟻金服“自主可控金融級商用區塊鏈平台”與“阿里雲 supET 工業互聯網平台”同時入選 15 項世界互聯網領先科技成果之列。前者的區塊鏈因素顯而易見,後者實際上也在由區塊鏈提供製造生產質量追溯和供應鏈管理服務。

  據全球知名智能信息服務機構科睿唯安公布信息,截至 2019 年 4 月 30 日,阿里巴巴以 290 件區塊鏈專利方案數量穩居全球第一。結合權威知識產權產業媒體 IPRdaily 過去兩年發布的“全球區塊鏈專利企業排行榜”显示,阿里巴巴申請的區塊鏈專利數量已經連續三年全球第一。2019 上半年全球區塊鏈企業發明專利排行榜(TOP100) 中,阿里巴巴以 322 件專利位列第一,中國平安以 274 件專利排名第二,Nchain 以 241 件專利排名第三。此外,百度( 7 名)、騰訊( 13 名)、京東( 14 名)、華為( 28 名)、獵豹( 40 名)、中國移動( 44 名)等均榜上有名。

  從上面的數據可以看出來,真正在區塊鏈的研究上佔據優勢且不斷應用的,沒有一個是“發幣”的,都是實實在在的在落地。

  當然了,也許與幣有關。此前有消息傳言,央行可能將在未來幾個月內正式推出國家支持的数字貨幣“DCEP”,初期將向中國工商銀行、中國建設銀行、中國銀行、中國農業銀行、阿里巴巴、騰訊以及銀聯七家機構發行。如果成行,那將是世界上是首個法定数字貨幣,意義深遠。

  在官方發布的新聞中,將區塊鏈發展方向定位為四個方面:

  1、要探索“區塊鏈+”在民生領域的運用,积極推動區塊鏈技術在教育、就業、養老、精準脫貧、醫療健康、商品防偽、食品安全、公益、社會救助等領域的應用,為人民群眾提供更加智能、更加便捷、更加優質的公共服務。

  2016 年,螞蟻金服聯合中國紅十字基金會等公益機構上線區塊鏈試驗項目,使捐款人可以追蹤善款的完整流轉情況。2017 年 3 月,支付寶愛心捐贈平台全面引入區塊鏈技術,所有捐贈數據上鏈。實現了實時賬目公示,有助於解決公益財務透明的“痛點”。螞蟻金服公益運用區塊鏈技術追蹤籌款,建立起第三方公示體系區塊鏈資金流公示,為公益機構進行數據統計、項目執行跟蹤提供便利。區塊鏈具有不可篡改的特性,任何寫入區塊鏈的記錄均不能更改,可以供公眾監督及審計。而“區塊鏈+公益”正是利用這一特性,發揮公眾賬本的價值,不論用戶是捐十塊、二十塊還是幾百塊,讓用戶所獻出的每一筆都記錄在區塊鏈上,有跡可循,持續追溯。

  2016 年 10 月,阿里與微軟、小蟻、法大大等合作開發“法鏈”,推出基於阿里雲平台的郵箱存證產品,通過法鏈上備份的电子郵件和雲服務,阿里將使中國法院能大規模採用数字證據郵件。

  2017 年 3 月,阿里巴巴與普華永道合作,打造可追溯的跨境食品供應鏈,用於跟蹤產品從生產者到消費者之間的整個流程。

  2017 年 8 月,阿里健康與江蘇常州市合作推出我國首個基於醫療場景的區塊鏈應用――“醫聯體+區塊鏈”試點項目。

  2017 年 10 月 11 日,螞蟻金服 CTO 程立在螞蟻金服金融科技開放峰會上首度披露未來的技術布局――“BASIC”戰略,其中的B對應的就是區塊鏈(Blockchain),同時,技術實驗室宣布開放區塊鏈技術,支持進口食品安全溯源、商品正品溯源等,第一個落地場景將是海外奶粉品牌的追蹤,先是產自澳洲、新西蘭的 26 個品牌的奶粉。2017 年 11 月 24 日,天貓國際宣布升級全球原產地溯源計劃,未來將覆蓋全球 63 個國家和地區,3700 個品類,14500 個海外品牌,也將向全行業開放,賦能整個行業。2018 年 2 月,菜鳥與天貓國際官方消息,已啟用區塊鏈技術跟蹤、上傳、查證跨境進口商品的物流全鏈路信息,涵蓋生產、運輸、通關、報檢、第三方檢驗等商品進口全流程,為每個跨境進口商品打上獨一無二的“身份證”,供消費者查詢驗證。

  騰訊旗下的微眾銀行於 2016 年 6 月開發出面向金融業的聯盟鏈雲服務 BaaS,並在 2017 年 1 月落地了第一個商業場景,即微黃金項目。微黃金是騰訊的一項在線黃金交易服務,用戶可以在微信低門檻靈活購買黃金,其背後正是由騰訊開發底層基礎架構的聯盟鏈。騰訊、工商銀行等多個節點共同參与記帳。2018 年 4 月底,騰訊發布第一款區塊鏈遊戲《一起來捉妖》,試圖通過區塊鏈技術保障了遊戲稀有內容投放的公開公平性,同時用戶可以將稀有妖怪上鏈永久保存。

  2017 年 12 月,沃爾瑪、京東、IBM、清華大學电子商務交易技術國家工程實驗室共同宣布成立安全食品區塊鏈溯源聯盟,運用區塊鏈技術搭建“京東區塊鏈防偽追溯開放平台”。該平台推出之後,用戶只需打開京東 APP 找到購物訂單,通過“一鍵溯源”或直接掃描產品溯源碼,即可獲取溯源信息。

  2018 年 10 月,百度正式發布自主研發的區塊鏈網絡系統——超級鏈。同時,宣布與海南省政府合作,區塊鏈實驗室及度鏈公司落戶海南,並推出“區塊鏈+大閘蟹溯源”應用。

  2、要推動區塊鏈底層技術服務和新型智慧城市建設相結合,探索在信息基礎設施、智慧交通、能源電力等領域的推廣應用,提升城市管理的智能化、精準化水平。

  5 月 22 日,上海、浙江、江蘇、安徽 4 地法院成立全國首個區域司法鏈,實現從起訴到執行全程上鏈,極大提高了訴訟效率和法院公信力,降低訴訟成本。最早引入區塊鏈技術的杭州互聯網法院,上鏈半年,其知識產權糾紛案件的調撤率上升至 95.3%。

  2017 年 5 月,阿里投資 Symbiont,該公司致力於利用區塊鏈技術打造一個發行和交易智能證券的平台。此外,深圳財富文化集團已經打造了一個文化產權交易的區塊鏈平台,並與螞蟻雙鏈打通,解決文化藝術品流通、交易和一系列金融服務。

  2017 年 11 月 8 日,阿里巴巴集團、螞蟻金服集團與雄安新區簽署了戰略合作協議,阿里巴巴與螞蟻金服將承建数字雄安區塊鏈實施平台。

  另外,國網電商公司已建成國家電網公司系統內首個司法級可信區塊鏈公共服務平台,作為唯一央企與北京互聯網法院“天平鏈”互信互通,掛牌工信部區塊鏈重點實驗室電力應用實驗基地,參与首個區塊鏈國家標準制定,實現了區塊鏈技術在電力積分通兌、光伏簽約、票據繳費、电子發票等多場景落地應用。

  3、要利用區塊鏈技術促進城市間在信息、資金、人才、徵信等方面更大規模的互聯互通,保障生產要素在區域內有序高效流動。

  在 9 月末舉行的雲棲大會·螞蟻區塊鏈生態峰會上,螞蟻金服集團副總裁蔣國飛透露,螞蟻區塊鏈已落地 40 多個應用。含括跨境支付、供應鏈金融、通用溯源、电子票據等多個行業領域。並於同期宣布了與全球最大的種子和農藥公司拜耳合作,應用方向進一步擴展。

  螞蟻金服 8 月份宣布,基於區塊鏈技術的供應鏈協作網絡——螞蟻區塊鏈“雙鏈通”全面升級開放。這一服務運用區塊鏈技術可解決供應鏈金融中的信任難題,同時讓小微商家也能享受高效便捷的金融服務。目前,這一模式已在成都率先應用。通過與成都商業銀行、成都中小企業融資擔保公司的合作,“雙鏈通”完成了供應鏈金融的全鏈路覆蓋。上鏈后,整個融資流轉過程清晰留痕、不可篡改,所有參与方都要通過“雙鏈通”進行身份核實和意願確認,数字簽名實時上鏈,杜絕了資金挪用等風險。

  4、要探索利用區塊鏈數據共享模式,實現政務數據跨部門、跨區域共同維護和利用,促進業務協同辦理,深化“最多跑一次”改革,為人民群眾帶來更好的政務服務體驗。

  3 月,杭州地鐵聯合支付寶、螞蟻區塊鏈推出了區塊鏈电子發票。全程手機操作,耗時不到 10 秒,上班族再也不用前往窗口排隊取票了。支付寶聯合雲南省相關部門,在醫療、教育等多個民生服務場景落地區塊鏈电子票據。從地鐵电子發票到法院訴訟案件,再到电子票據平台,螞蟻區塊鏈在過去近 3 年時間里,相繼落地了 40 多個場景。其中長三角佔比超過一半。“上鏈”后長三角人辦事效率大大提升,不少事項可享受“秒級”服務。

  我們看到,在 5G 時代,無差別計算能力的流通成本會大幅下降,無差別計算能力是 AI 最重要的勞動要素,而區塊鏈就是 AI 最重要的勞動要素。阿里巴巴達摩院在《2019 十大科技趨勢》中提到,5G 和區塊鏈是未來十年的發展方向。《福布斯》發布的《2020 十大科技趨勢》也提到,5G 和區塊鏈都將於 2020 年崛起,未來與人們日常生活相關的每一個行業都會被變革。還是那句話,“誰能把當前的技術和資源用到最充分,誰就是這個時代的最強者”,也許 5G 的流量充沛,正是區塊鏈的黃金歲月。

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

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

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

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