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