先來看看本來的體系界面是如何子的：
?
其功用如下,我新寫的客戶端增加了支持生成OCX控件的功用：
全部體系的物理架構(gòu)是這樣的：
跟著界面數(shù)量的增加，會(huì)需求更多的加載時(shí)刻
跟著地址和設(shè)備的增加，加載會(huì)需求更多的時(shí)刻
咱們來看看經(jīng)過一些啥辦法能夠處理本來的體系存在的這些疑問。
大多數(shù)的狀況下，咱們本來所能看到的東西都是極端有限的，不管體系是多么巨大，功用多么的豐厚，本來呈現(xiàn)給用戶的都是極端有限的。
前面說了，監(jiān)控主界面里的界面都是組態(tài)的，是由工程師拖拉控件上去完結(jié)的，咱們也看到上面圖形還算豐厚，主要是運(yùn)用了許多的圖像，因而咱們體系中在保留這些組態(tài)界面的時(shí)分，一同也保留了界面圖像的字節(jié)省。大型的數(shù)據(jù)中心由于界面較多，這些界面加起來是也許會(huì)超越1G巨細(xì)的。這么大的界面，假如都是直接加載到界面中，首要就要費(fèi)不少的時(shí)刻，即便是在內(nèi)網(wǎng)的狀況下，假定你網(wǎng)絡(luò)能夠1s下載20M擺布，也要50秒，接近1分鐘，遇上網(wǎng)絡(luò)頂峰，花個(gè)1~2分鐘并不奇怪。
咱們是不是有必要把一切界面都加載進(jìn)來呢，當(dāng)然沒有。咱們只需加載第一個(gè)界面，其他界面在需求的時(shí)分(用戶點(diǎn)擊或許發(fā)作告警需求跳轉(zhuǎn)的時(shí)分)才加載，這樣咱們的速度里邊就提高了，這即是按需加載！
當(dāng)然說的輕盈，實(shí)踐做的會(huì)有許多疑問。比方，如何完結(jié)不完結(jié)頁面又能曉得該頁面是不是告警(有必要解析每個(gè)界面上的控件，才干曉得某個(gè)界面包含了哪些控件，才曉得監(jiān)控目標(biāo)告警在哪個(gè)界面上)？
我的進(jìn)程如下：
做監(jiān)控體系，除了告警頁面有必要實(shí)時(shí)告訴到客野外，監(jiān)控?cái)?shù)據(jù)界面，本來只需展示當(dāng)時(shí)顯現(xiàn)頁面的數(shù)據(jù)即可。
如何做呢，咱們能夠供給一個(gè)獨(dú)自的程序來辦理一切接收到的數(shù)據(jù)，然后再供給一個(gè)獲取當(dāng)時(shí)數(shù)據(jù)的接口給客戶端，具體請(qǐng)看下面更改的架構(gòu)。
有些人也許會(huì)疑問，為何不直接在采集器中供給這個(gè)接口呢？由于這是組態(tài)界面，界面上的控件要取哪個(gè)采集器的數(shù)據(jù)是未知的，所以把數(shù)據(jù)放在一同統(tǒng)一辦理會(huì)愈加便利。并且采集器能夠7*24小時(shí)作業(yè)，而客戶端是常常要翻開封閉的……
假如用過VS2010開發(fā)自定義的Winform組件，那么咱們對(duì)它的工具箱加載自定義組件這個(gè)功用必定形象深入，每次挑選增加項(xiàng)，然后挑選自定義控件dll的時(shí)分，都十分苦楚，特別我電腦比照忙而又裝了不少插件的狀況下，為了一個(gè)十分簡(jiǎn)略的功用，我需求花費(fèi)4分多的時(shí)刻來翻開那個(gè)挑選文件的界面，這個(gè)界面加載了一大堆我絕大多數(shù)時(shí)分都用不上的COM組件，我真實(shí)無法幻想開發(fā)這個(gè)功用的程序猿是如何想的。還好，在VS2013中微軟總算是改進(jìn)了這個(gè)功用，可是做得還不行。按我的主意，徹底能夠把COM組件部分異步加載，給出正在加載的提示即可，能夠當(dāng)即顯現(xiàn)“挑選”按鈕，這樣領(lǐng)會(huì)性當(dāng)即上升了一個(gè)層次。
推遲加載是指用到的時(shí)分，再去進(jìn)行實(shí)踐的構(gòu)建。
樹形菜單的樹形節(jié)點(diǎn)的構(gòu)建即是一個(gè)最適合解說的比如。咱們能夠測(cè)驗(yàn)加載1000個(gè)樹形節(jié)點(diǎn)然后構(gòu)建成一棵樹，看看在Winform中需求多長(zhǎng)的時(shí)刻。咱們的實(shí)踐中有沒有必要這么去做呢？
各位能夠思考下自個(gè)檢查樹形導(dǎo)航的時(shí)分，是不是從根節(jié)點(diǎn)到子節(jié)點(diǎn)終究到葉子節(jié)點(diǎn)這樣一步步看下去的，大多數(shù)的時(shí)分，本來咱們只需首要看到根節(jié)點(diǎn)即可。例如下面這個(gè)：
關(guān)于這種狀況，咱們徹底能夠把樹形節(jié)點(diǎn)都獲取，可是先只創(chuàng)立只要根節(jié)點(diǎn)的一棵樹，在用戶點(diǎn)擊以后加載子節(jié)點(diǎn)，假如已判別過，則不履行加載的操作。底子的辦法是在Tag中附加一個(gè)字段指示子節(jié)點(diǎn)是不是現(xiàn)已加載，參閱代碼如下：
|
private void TreeDevices_BeforeSelect(object sender, TreeViewCancelEventArgs e)
{
var myNode = e.Node.Tag as NTier.Model.MyTreeNode;
if (myNode == null) return;
if (myNode.IsSubNodeLoaded == false)
{
//還沒有加載數(shù)據(jù)，主要是指機(jī)房節(jié)點(diǎn)
LoadNodesOfSubMainForm(e.Node, myNode); //加載樹形子節(jié)點(diǎn)
}
//已加載了數(shù)據(jù)，則生成相應(yīng)的界面
LoadFormModel(myNode);
}
|
這兒推遲加載與按需加載有點(diǎn)相似，區(qū)別是，推遲加載有必要把一切數(shù)據(jù)加載進(jìn)來，可是并不構(gòu)建成一棵UI樹，而是在用到的時(shí)分再去生成。
另一個(gè)當(dāng)?shù)丶词敲總€(gè)控件的右鍵菜單。由于每個(gè)右鍵菜單顯現(xiàn)的內(nèi)容是需求依據(jù)控件的類型以及有關(guān)的權(quán)限來判別的，可是咱們看到右鍵菜單的時(shí)分一定是人為進(jìn)行操作才干顯現(xiàn)出來，因而沒有必要再界面生成的進(jìn)程中去為每個(gè)控件生成對(duì)應(yīng)的右鍵菜單，而是在彈出右鍵菜單時(shí)進(jìn)行有關(guān)的判別，推遲右鍵菜單的生成。
咱們曉得，假如要檢查一棵樹的一切節(jié)點(diǎn)，常用的辦法即是運(yùn)用遞歸進(jìn)行廣度遍歷或許深度遍歷?？墒?，在樹形節(jié)點(diǎn)較多的時(shí)分，遍歷本來是十分耗時(shí)的。在咱們這個(gè)體系中，告警是有必要要最早處理的，因而，我在體系中運(yùn)用Dictionary類型緩存了每個(gè)特點(diǎn)節(jié)點(diǎn)與它有關(guān)聯(lián)的數(shù)據(jù)類型(ID)，然后能夠在發(fā)作告警時(shí)立刻定位到指定樹形節(jié)點(diǎn)。
咱們體系是組態(tài)的界面，這就約束了界面的生成有必要是動(dòng)態(tài)的。假如咱們選用按需加載的辦法，那么界面的生成即是實(shí)時(shí)的，如何能夠做到疾速的進(jìn)行頁面的切換呢？
|
var tempPanel = _panelCache.CreatePanel(this, formModel, myNode.AgentBm); //創(chuàng)立Panel
|
在這兒，我專門寫了一個(gè)界面的緩存類，假如沒有緩存，則動(dòng)態(tài)創(chuàng)立，假如有緩存，就直接回來緩存的界面。一同，依據(jù)界面的最新的翻開時(shí)刻和點(diǎn)擊次數(shù)，對(duì)緩存的界面進(jìn)行辦理。咱們曉得，全部大型體系中，本來用戶重視的界面也是有限的，通常他們只會(huì)重視最重要的幾個(gè)界面，最常用的也是這幾個(gè)界面。經(jīng)過緩存的辦理，不但能夠完結(jié)界面之間的疾速切換，一同也減少了體系占用的內(nèi)存。我全部客戶端程序文件巨細(xì)緊縮以后在500k以內(nèi)，而運(yùn)轉(zhuǎn)期間占用內(nèi)存底子維持在50M擺布。
檢查上面改造過后的架構(gòu)，咱們曉得如今獲取數(shù)據(jù)是在翻開界面以后再去獲取，直到樹立銜接并獲得數(shù)據(jù)以后，才干在界面上顯現(xiàn)，這個(gè)進(jìn)程通常會(huì)耗時(shí)1~2秒，網(wǎng)絡(luò)差的狀況會(huì)更糟。如何才干讓用戶更為疾速的斷定咱們的體系現(xiàn)已運(yùn)轉(zhuǎn)了呢？這兒咱們經(jīng)過一個(gè)簡(jiǎn)略的辦法，集中服務(wù)端經(jīng)過守時(shí)把當(dāng)時(shí)監(jiān)控到的數(shù)據(jù)寫入控件的特點(diǎn)中，在體系加載控件的一同把這個(gè)值顯現(xiàn)出來，這樣能夠看起來好像是體系立刻獲取到了數(shù)據(jù)。而由于緩存的值是守時(shí)把最新值寫入進(jìn)入的，這種做法在很大程度上保證了緩存中的數(shù)值是準(zhǔn)確的。
異步是進(jìn)步程序響應(yīng)和用戶領(lǐng)會(huì)的不貳法寶。C#中的控件和大多數(shù)流操作類等都供給了支持異步操作的辦法：BeginXXX和EndXXX.它的原理也十分簡(jiǎn)略，運(yùn)用BeginXXX時(shí)，把操作參加線程池，履行完結(jié)以后調(diào)用一個(gè)回調(diào)函數(shù)。
一個(gè)用戶領(lǐng)會(huì)杰出的體系，應(yīng)當(dāng)能夠合理的運(yùn)用異步操作，保證履行UI更新時(shí)以及履行耗時(shí)的操作時(shí)不會(huì)堵塞。大多數(shù)人在寫代碼的時(shí)分，老是直接進(jìn)行調(diào)用，在控件較少或許完結(jié)簡(jiǎn)略使命的時(shí)分，你通常都感受不出來，可是在控件數(shù)量多的時(shí)分，咱們很簡(jiǎn)略就感受到界面卡，不流通。
我在新體系開發(fā)的時(shí)分，就有認(rèn)識(shí)的在控件加載、控件數(shù)據(jù)改寫、控件告警狀況切換等操作中運(yùn)用了異步的操作，讓體系在翻開界面時(shí)徹底感受不到卡的跡象。
不過運(yùn)用異步要時(shí)刻記住，異步能夠進(jìn)步用戶領(lǐng)會(huì)性，可是不會(huì)有性能上的本質(zhì)提高，假如感受到數(shù)據(jù)響應(yīng)有推遲，你仍是得花功夫找到底子的緣由。
咱們來看看本來界面是如何改寫數(shù)據(jù)的：
翻開界面->改寫數(shù)據(jù)->新建一個(gè)線程->守時(shí)改寫數(shù)據(jù)->封閉界面->封閉線程。
對(duì)Windows體系有滿足了解的人都曉得，新開一個(gè)線程都是十分消耗資本的。這種狀況，咱們是能夠在全部體系中，供給一個(gè)統(tǒng)一辦理的改寫線程，只需對(duì)當(dāng)時(shí)需求改寫的界面進(jìn)行改寫即可：
改寫線程->判別當(dāng)時(shí)界面是不是存在->守時(shí)改寫數(shù)據(jù)
聯(lián)系上述的異步操作，咱們的控件在改寫數(shù)據(jù)的時(shí)分十分的流通。
上面咱們提到了，在體系發(fā)作告警時(shí)，有必要要跳轉(zhuǎn)到報(bào)警的頁面，這個(gè)機(jī)制在許多告警并發(fā)的時(shí)分，就會(huì)有十分大的疑問，很也許咱們的體系就會(huì)在不一樣的界面中進(jìn)行跳轉(zhuǎn)而卡死。關(guān)于體系的用戶來說，在1~3秒內(nèi)的多個(gè)告警，咱們本來能夠處理為一個(gè)告警，咱們只需往終究一個(gè)告警發(fā)作的頁面跳轉(zhuǎn)即可，這樣既達(dá)到了相應(yīng)的作用，也減少了體系的壓力。這即是告警并發(fā)時(shí)的歸并處理。
在一些狀況中，咱們確實(shí)短時(shí)刻沒有辦法對(duì)性能進(jìn)行提高了，花費(fèi)的時(shí)刻卻要要這么多，這種狀況下，咱們有些啥好的做法呢？
假如咱們常常用手機(jī)登入微博、微信等，必定對(duì)這些app加載圖像有過一些領(lǐng)會(huì)，特別假如你是在網(wǎng)絡(luò)較差的狀況下，同樣是要等1分鐘才干加載出圖像，假如這個(gè)app沒有任何提示，那么，過了30秒或許20秒，你就有也許受不了把他點(diǎn)掉了，由于你感受它好像現(xiàn)已過了幾分鐘，還有也許遙遙無期；而假如這個(gè)app能夠提示當(dāng)時(shí)下載的字節(jié)數(shù)、當(dāng)時(shí)下載的進(jìn)展，那么，1分鐘的等候，你好像也能承受，這畢竟是網(wǎng)絡(luò)致使的疑問。這即是一種視覺上的詐騙。
在一個(gè)體系的加載進(jìn)程中，有提示信息和沒FF;"> ?提示信息，有進(jìn)展條和沒進(jìn)展條，給人感受的速度是不一樣的，即便從實(shí)踐的狀況來看這兩者沒有任何不同。
許多時(shí)分，咱們體系的運(yùn)轉(zhuǎn)需求從服務(wù)器中獲取一些最新的數(shù)據(jù)，以支持底子的運(yùn)轉(zhuǎn)。這部分時(shí)刻是你必不可少的，許多人都認(rèn)為這是沒有任何辦法??;"> ?98化的，本來不然。咱們?cè)S多程序本來都供給了一個(gè)用戶名和暗碼的輸入框，本來在用戶輸入的進(jìn)程中，咱們?nèi)允悄軌蜻\(yùn)用的。在彈出登入窗到輸入賬號(hào)和暗碼到登入體系的進(jìn)程中，通常都會(huì)有3~5秒的時(shí)刻。
我看到許多人寫程序，彈出登錄框就老老實(shí)實(shí)的彈出，然后在輸入完用戶名和暗碼以后在進(jìn)行數(shù)據(jù)的獲取和加載?F;"> ?F??實(shí)踐上，咱們現(xiàn)已浪費(fèi)了這些時(shí)刻。假如你能有用運(yùn)用這3~5秒，那么，你就現(xiàn)已贏在了起跑線。
視覺詐騙的別的一個(gè)重要運(yùn)用，即是在曲線的烘托中。在機(jī)房監(jiān)控中，咱們有些設(shè)備的監(jiān)控比照頻頻，一天發(fā)生的數(shù)據(jù)高達(dá)幾萬條，把這么多的數(shù)據(jù)制作到一條24小?F;"> ?6??的曲線上，咱們將會(huì)看到許多鱗次櫛比的點(diǎn)，制作這些點(diǎn)十分的耗時(shí)和耗資本。而咱們供給曲線給用戶檢查的意圖是啥呢，是想檢查一天的趨勢(shì)變化，過多密布的點(diǎn)本來是沒有必要的，咱們看看下圖，假如數(shù)據(jù)點(diǎn)更多的話，第二個(gè)曲線會(huì)愈加密布，看起來會(huì)像一條粗大的直線：
經(jīng)過簡(jiǎn)略算法對(duì)曲線進(jìn)行緊縮以后，顯現(xiàn)前史趨勢(shì)的速度十分的快，十分的流通。咱們比照上面兩條曲線，本來對(duì)用戶來說，或許更喜愛第一條曲線，由于他反響的趨勢(shì)更為優(yōu)美，有木有？
在我的博文中，我一向著重運(yùn)用單元測(cè)驗(yàn)，不管是開發(fā)仍是重構(gòu)。我覺得這個(gè)不管是如何著重都不為過的。
在開發(fā)的進(jìn)程，咱們應(yīng)當(dāng)有認(rèn)識(shí)的按單元測(cè)驗(yàn)的意圖來構(gòu)建咱們的函數(shù)、類、以及程序集，假如你的函數(shù)契合單元測(cè)驗(yàn)需求的話，通常都是比照簡(jiǎn)略重構(gòu)和維護(hù)的。別的，咱們開發(fā)的進(jìn)程中，許多時(shí)分需求驗(yàn)證某個(gè)功用是不是可用，運(yùn)用單元測(cè)驗(yàn)，將會(huì)很疾速的幫你完結(jié)這個(gè)驗(yàn)證操作。我看咱們?cè)S多程序員開發(fā)功率都不高，特別在開發(fā)一個(gè)大型體系的時(shí)分，喜愛把全部體系開起來調(diào)試，或許是在體系里邊加上各種裝備或許條件編譯來進(jìn)行調(diào)試，這種習(xí)氣十分欠好。在程序中參加裝備簡(jiǎn)略讓程序結(jié)構(gòu)呈現(xiàn)紊亂，代碼的閱覽領(lǐng)會(huì)也欠好，許多時(shí)分假如咱們忘掉去掉這個(gè)裝備，很簡(jiǎn)略就對(duì)發(fā)布的體系發(fā)生較大的影響。
運(yùn)用單元測(cè)驗(yàn)別的一個(gè)優(yōu)點(diǎn)是，咱們能夠隨時(shí)針對(duì)某個(gè)辦法進(jìn)行性能上的測(cè)驗(yàn)，發(fā)現(xiàn)哪些代碼對(duì)咱們的體系造成了較大的影響。我習(xí)氣連私有的函數(shù)也一同參加測(cè)驗(yàn)，以下是調(diào)用私有函數(shù)的一個(gè)輔佐辦法：
|
public static object InvokePMethod(Type type, string methodName, object classInstance,object[] @params)
{
const BindingFlags flags = BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Static;
var methodInfo = type.GetMethod(methodName, flags);
var result = methodInfo.Invoke(classInstance, @params);
return result;
}
|
在平時(shí)的開發(fā)中，我一向跟我的搭檔著重日志的重要性。信任有一定開發(fā)經(jīng)歷的都曉得在體系中寫日志，可是，如何把日志寫好，許多人都掌握不了。在這兒我提幾點(diǎn)主張：
之前咱們的體系是自個(gè)完結(jié)的日志組件，我用C#重寫時(shí)，引入了NLog日志組件，我覺得這個(gè)日志組件十分好用。別的，我還專門供給了一個(gè)UI界面的調(diào)試窗，以便實(shí)施工程師在現(xiàn)場(chǎng)調(diào)試的時(shí)分能夠疾速定位疑問。
在實(shí)踐運(yùn)轉(zhuǎn)的進(jìn)程中，由于有杰出的日志信息，我很快能夠排查許多的疑問，而大多數(shù)的疑問都是由于裝備致使的。我一致跟研制的搭檔著重，盡也許的不要信任現(xiàn)場(chǎng)工程師給你的判別，應(yīng)當(dāng)要現(xiàn)場(chǎng)工程師供給依據(jù)給你，而要供給啥樣的依據(jù)，作為一個(gè)研制，你才是最明白的。好的日志體系應(yīng)當(dāng)能夠依據(jù)日志信息精確的定位到疑問，在離線的狀況下能夠最大程度的反響當(dāng)時(shí)體系的裝備、運(yùn)轉(zhuǎn)狀況、以及錯(cuò)誤信息。
終究用C#重寫的客戶端在各方面變現(xiàn)都十分的好，體系十分穩(wěn)定，全部體系進(jìn)入在2s擺布，頁面切換在1s擺布，最重要的是，客戶端跟體系的巨細(xì)沒有關(guān)系，習(xí)慣巨細(xì)的數(shù)據(jù)中心。咱們看看新老體系在加載進(jìn)程中的一個(gè)比照：
很明顯，經(jīng)過上述辦法進(jìn)行一些優(yōu)化以后，咱們的體系在各個(gè)進(jìn)程都有了提高，并且經(jīng)過異步、緩存、詐騙等辦法讓一些進(jìn)程能夠同步進(jìn)行，大大加馬上體系的加載和相應(yīng)。
我希望經(jīng)過這篇文章，把客戶端優(yōu)化的一些辦法共享出來，供咱們參閱。這其間沒有啥深邃的常識(shí)，也沒有說要你有必要選用如何的編程言語，僅僅是經(jīng)過一些簡(jiǎn)略的辦法，并歸納應(yīng)用，就能把一個(gè)體系的響應(yīng)速度從4分鐘提高到只需兩秒。當(dāng)然，咱們還有其他許多的辦法，比方分布式……不管是啥樣的技巧，我覺得有一些底子的準(zhǔn)則是要遵循的：
專線：劉剛 13911133352
E-mail：[email protected]
北京金恒智能系統(tǒng)工程技術(shù)有限責(zé)任公司 版權(quán)所有 Copyright 2007-2020 by Create-china.com.cn Inc. All rights reserved.
法律聲明：未經(jīng)許可，任何模仿本站模板、轉(zhuǎn)載本站內(nèi)容等行為者，本站保留追究其法律責(zé)任的權(quán)利！
電話：86+10-62104277/2248/4249 傳真：86+10-62104193-819 京ICP備10010038號(hào)-2網(wǎng)站XML
智慧機(jī)房
在線體驗(yàn)
