※回頭車貨運收費標準

宇安交通關係企業，自成立迄今，即秉持著「以誠待人」、「以實處事」的企業信念

本文是個人的2020年年中總結

還有十幾天就要畢業，面臨着身份從學生到互聯網社畜的轉變，未來的一切捉摸不定，但凡心中萬千情緒，也只能「但行好事，莫問前程」。

介紹下博主背景：計算機本科大四，剛進大三時還是個沒有實習、沒有項目經歷的小白，
經過一年時間的刻意練習[deliberate practice]，最後在校招中拿到了一些大廠offer，
標題中30k的offer已經拒掉了，有了更好的去處，只是用來舉例。

文章同步自 https://github.com/mio4/interview

0x0 前期調研

以下經驗根據個人的經驗來談，有一定的局限性，僅供參考。

1. 為什麼不選擇算法

計算機專業的就業方向很多，對於應屆生來說，工種大概可以分為移動端、前端、後端、算法、運維、測試。

由於近年來ML和DL的快速發展，特別是16年AlphaGo以及視覺檢測、自然語言處理方向的進展，人工智能方向成為了繼大數據之後的又一個學術熱點。

周圍接觸到的同學，大部分集中於算法和後端方向。我最開始就是準備深入後端方向，並且決定本科直接就業。但是我有兩點糾結：

1. 後端是否不如算法？
2. 對於後端，本科學歷是否適合職業發展預期？

1. 本科生以算法作為工作目標難度太高，和字節跳動的面試官交流，目前字節AI Lab的成員組成是大部分碩博，以及少部分優秀的本科生（acm區域金作為參考）
2. 算法需要的三點：實習、競賽和paper，我都沒有信心和諸多轉專業的工科碩士抗衡
3. 個人對於算法沒有強烈興趣，發展空間不明朗，行業未來搭上5G的車，可能會有比較大的想象空間，風險和收益並存。

參考

2021 校招算法崗， 勸退還是繼續

如何看待 2020 屆校招算法工程師崗位求職人數遠大於招聘崗位的現象？

2. 為什麼選擇Java後端

如果認定了後端，後端語言這麼多，如何選擇適合自己的方向？

業界有一種說法：『語言只是工具，數據結構和算法是解決問題的根本』。這種說法本身是沒有錯的，但是從普遍來看，本科生從有工作的想法到秋招，只有（或者不到）一年的時間，泛泛了解多個方向不如深入特定方向，更有助於求職。

後端主要的開發語言有Java、C++、Python、PHP、Go，PHP目前除了百度和騰訊部分部門之外，使用範圍不廣，不予討論。另外，Golang作為高併發場景的常見支持，在雲計算領域使用比較廣泛。

互聯網和其他資本市場沒有本質區別，既然是市場，就存在供求關係。 對於算法這種供遠遠大於求的情況，就是買方市場，賣方（求職者）需要更好的產品（技能）來獲得同等的價格。對於應屆生來說，找到一個良好的買方市場，更加有利。

調研基於兩個預設條件：

1. 崗位數目越多，市場的需求越大。
2. 高薪崗位越多，該方向的發展前景越大。

我們參考www.lagou.com，互聯網大部分獵頭或者對外招聘崗位都會發布在上面，有一定的參考價值。

地點選擇北京，薪資範圍選擇25~50k/month。

Java

（1）職位500+，可以看出需求缺口很大。

（2）除此之外，Java生態系統最為完善，e.g. Spring全家桶。

（3）Java是電商網站的技術首選，阿里、京東、拼多多等電商公司的技術棧。

Python

Python主要是作為腳本語言，適用於運維開發和算法崗位，目前在字節跳動使用比較廣泛，可以看出崗位相對較少。適合作為輔助開發語言，畢竟寫腳本算得上是程序員的必備技能了。

C++

C++是遊戲開發（其次還有lua）和系統開發的首選語言，但是因為上手成本比較高（指針和內存管理）以及需要對操作系統深入了解，市場崗位需求也不如Java，所以不推薦。不過如果有acm或者信息競賽基礎，也不成問題。

0x1 秋招準備

隨着互聯網從業人數越來越多，競爭也呈現白熱化。科班學生不僅要和同專業同學競爭，也會感受到轉專業同學（大部分是碩士）帶來的壓力。參考同系講師的數據，我航15年時6系本科同學比較容易就能去BAT，到了19年BAT頭條對於大部分同學不是想進就進了。

從宏觀意義上來看招聘，企業需要找到適配崗位的員工，學生需要謀取職業生涯的第一份工作。對於學生來說，秋招和高考在本質上是相似的，都是一種選拔，需要證明自己的能力比別人更強。

在準備的時候，定量的標準往往更加具有說服力，『我守望先鋒玩的很厲害』遠遠不如『我守望先鋒全國天梯4000分』，『我學習Java花了很多時間』不如『我閱讀了《Java核心思想》和《Effective Java》以及…，並且復現了書中的代碼，在github倉庫xxx』。

我是從2018.8月下旬（進入大三）開始準備，到找到工作總共花了一年的時間，基本上分為三個時期：

1. 2018.8 – 2018.12 ：基本素質培養
2. 2019.1 – 2019.8 ： 百度智能雲實習
3. 2019.7 – 2019.8 : 秋招提前批

整個秋招的核心思路 = 基礎+實習+項目

1. 基本素質

第一次認清自己的水平，是在大二下學期結束的暑假。當時投了百度暑期實習，毫無準備的前提下，只用了20分鐘就掛在了一面。

面試慘跪之後，我分析了自己的處境，當時的我GPA排名40%，沒有參加過ACM程序競賽，沒有實習經驗，除了OO課程，沒有寫過”大型”項目。從編程能力上看，大一數據結構60分醬油飄過，算法課程也限於理論，只能說能夠應付考試不掛科，Java只會語法，web框架更是沒有項目經驗。

這時候的我深刻意識到自己在編程方面還是個在新手村找不到北的green hand，記得剛上大一的時候，哪位神仙說我校混的差躺着也能去BAT？夢想很美好，現實很骨感。

相對於隔壁北郵，我航更加註重學生的深造（校內讀研和出國留學），對於工作方面的指導甚少。我大部分的時間都是一個人準備，所以經常陷入迷茫orz，這期間主要的問題是：

1. 選擇什麼方向？ （前面已經對市場進行了就業分析）
2. 要學習什麼內容？（算法太高級了，玩玩可以，找工作水平不夠）
3. 要學到什麼程度，才能找到實習/工作？

整個秋招的過程，就是我解決這三個問題的過程。

於是，首先我使用Hexo + Github.io 搭建了個人博客：mio4

博客有兩個作用：

1. 能夠體系化自己的學習，方便複習
2. 量化自己的學習成果，面試的時候，給面試官帶來好印象

其次開始有針對性的訓練自己的編程能力，

Java程序員的基本素質有：Java基礎（語法+JVM+多線程），Spring框架（SSM/SpringBoot，進階可以SpringCloud），算法能力（刷題）

2. BAT實習

找工作本身就是一個經驗和需求矛盾的過程：

找實習，認準BAT TMD，其中BATT（頭條）基本屬於一個檔；外企的話，ms/hulu/airbnb認可度也很高。

拿周圍同學舉例，即使是小廠開了一個月8、9k的實習補助，也不要因此放棄BAT的實習機會。

※智慧手機時代的來臨，RWD網頁設計為架站首選

網動結合了許多網際網路業界的菁英共同研發簡單易操作的架站工具，及時性的更新，為客戶創造出更多的網路商機。

雖然近幾年百度已經明顯掉隊於BAT，但是就我個人體驗來看，外界對於百度的技術還是很認可的。對於實習來說，鍍金的效果完全夠用。【2020.5 update：目前應屆不滿一年沒有晉陞和普調資格，除非部門極好，否則不推薦轉正】

在2019.1月，托研二直系學長的福，內推經過三面通過了百度智能雲計算部的後端實習，面經：https://www.nowcoder.com/discuss/151829

到8月結束了實習，半年的實習時光對於工業屆有了更深入的了解。

3. 秋招面試

離開baidu主要有兩個原因：

1. 工作內容不算滿意：在baidu的工作語言主要是php，大廠目前使用php的很少，不利於職業長期發展；另外實習負責的模塊也不算核心。
2. 薪資不夠預期：baidu本科白菜價15k*15，每個月的工資扣掉五險一金和稅，只剩下11k，再加上北京動輒3、4k的房租，過於艱難。

因為花了接近一年時間準備，所以在提前批就結束了秋招，9月大部分企業剛開通秋招正式批通道前，我就歇了，真正準備校招的時間不足兩個月。【2020.5 update： offer這種東西當然是越多越好，去年的我太佛系了，騰訊、微軟、快手這些公司甚至沒投簡歷，現在覺得去年還是naive】

AI四小龍面過了兩家，都是sp | ssp，雲從當時沒聽說所以沒投，商湯提前批四道題A了三道解題報告，結果居然沒有不給面試機會Excuse me？

提前批收到了百度、字節跳動等大廠和一些獨角獸的offer，互聯網薪資保密，已經簽約的就不談具體待遇了。

拿個去年8月已經拒掉的獨角獸offer舉例：

0x2 其他經驗

1. 書籍推薦

國內csdn以及各種類似菜鳥教程的博客的知識系統往往支離破碎，不能深入學習。

看書能夠系統化學習知識，下面推薦我看過的一些書

• 算法：

  • 《劍指Offer》

• Java：

  • 《Java核心技術》，當字典看，不需要整遍過

  • 《Java併發編程實戰》 ，熟悉多線程

  • 《深入理解Java 虛擬機》，熟悉JVM必備

  • 《圖解Java多線程設計模式》，日本人寫的書，直觀易懂，強力推薦

  • 《Java 8實戰》

  • 《Effective Java》

• Spring：

  • 《Spring實戰》

• MySQL：

  • 《高性能MySQL》，主要是第五六章
  • 《Redis實戰》

• 網絡：

  • 《圖解HTTP》
  • 《計算機網絡自頂向下方法》

• 代碼規範：

  • 《重構》

2. 準備項目

對於在校學生來說，準備項目可能會面臨着無法下手的問題。

首先項目一般不是自己憑空想出來的，可以通過實驗室等方式接手比較成熟的方案。

我的操作是直接使用網課，比如慕課

選擇一個感興趣的，從0到1復現一個項目，完善自己的技術棧。

當然，imooc上大部分乾貨需要付費，學生黨如果沒錢可以考慮下面的方式：

蒲公英論壇：ipv6，好處是下載視頻不走校園網流量，有部分從imooc搬運的資源。

當然對於買不起資料的窮孩子，還是有灰色路徑可以『曲徑通幽』的，比如【已刪除】：盜版的論壇，基本上涵蓋所有imooc的視頻代碼資料，僅供參考。作為程序員，這裏盡量推薦支持正版。

3. 算法能力

面試必備：《劍指offer》 + LeetCode

LeetCode題目比較多，參考Hot/Top 100：

到秋招結束，刷題量不多，總共100左右，但是對每道題使用思維導圖進行總結，盡可能舉一反三：

4. 實習投遞

投遞實習的方式一般有：

• [x] 熟人內推：最靠譜最快的方式，投遞簡歷到百度實習面試邀約只花了不到半天。

• [x] 牛客網：響應時間一般，1~7天

• [x] 實習僧app ：響應時間一般，一般一周

• [x] 官方通道：比如騰訊的暑期實習官方在線投遞。

4. 面試技巧

分公司分崗位的面經可參考：www.nowcoder.com

我的個人面經總結：https://github.com/mio4/learn-java/blob/master/Note/interview.md ，總共250頁的PDF，綜合個人經歷的所有面試，題目覆蓋率至少有50%。根據研二轉專業的同學反饋來看，作用很大。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

※評比南投搬家公司費用收費行情懶人包大公開

搬家價格與搬家費用透明合理，不亂收費。本公司提供下列三種搬家計費方案，由資深專業組長到府估價，替客戶量身規劃選擇最經濟節省的計費方式

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

透過選單樣式的調整、圖片的縮放比例、文字的放大及段落的排版對應來給使用者最佳的瀏覽體驗，所以不用擔心有手機版網站兩個後台的問題，而視覺效果也是透過我們前端設計師優秀的空間比例設計，不會因為畫面變大變小而影響到整體視覺的美感。

一、背景

　　近期有一個項目在運行當中出現一些問題，程序順利啟動，但是觀察一陣子后發現內存使用總量在很緩慢地升高，

雖然偶爾還會往下降一些，但是總體還是不斷上升；內存運行6個小時候從33M上升到80M；

　　程序存在內存泄漏是確定無疑的了，大概出問題的方向也知道，就是程序新加入一個採集協議（BACnet協議，MSTP_DLL），

但是怎麼把具體泄漏位置找出來卻非常麻煩，因為這個協議是封裝在一個C語言寫的動態庫中，想要單步調試好像不太可能，

況且源碼也不再我這裏；

　　如果到此為止，推脫給其他同事找問題，那聯合調試費時不說。其他同事也身兼數職，不大可能有時間調試，

那項目推進肯定停滯；那沒辦法了，只能硬着頭皮上；網上了解一番，對於這種內存泄漏問題，比較好的處理方式就是

抓取內存快照，然後分析數據提交記錄，使用查看使用堆棧等信息；所以基於以上原因，選擇了windbg內核調試工具；

先分析一下看看，說不定可以發現問題；

 

二、windbg注意事項

1、首先要安裝對版本，即你的程序是32位還是64位，對於的windbg版本也要一致，否則會報錯；詳情了解：點擊這裏

2、需要用64位的任務管理器抓32位的dump文件，那不能直接在任務管理器右鍵“創建轉儲文件“，需要運行（C:\Windows\SysWOW64\taskmgr.exe）

3、或者直接在windbg上使用命令存儲，先附加到進程，然後使用命令：（.dump /ma c:\xxx.dmp）,這樣就將快照保存在C盤了；

4、最重要的，要確保你的機器能連接外網；由於windbg的使用需要在線更新符號文件，但是這個地址剛好被國家防火牆屏蔽；

 

三、windbg必要設置

1、首先我先抓取2個內存快照文件（中間相隔一段時間），如下

 

 

2、打開windbg，設置符號下載路徑

將33.dmp直接拖進工作區即可，然後打開菜單File -> Symbol File Path

輸入地址：SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

 

四、分析文件

1、分別打開兩個dmp文件，輸入命令!dumpheap -stat查看各種類型的內存分配情況

33.dmp
>.load C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll
>!dumpheap -stat
.....
61f87928     2292        34012 System.RuntimeType[]
5d2dbe74      267        34176 System.Data.DataColumn
61fd75e0      668        37408 System.Reflection.RuntimePropertyInfo
61f8426c      702        48976 System.Int32[]
5d2dcc24       70        72520 System.Data.RBTree`1+Node[[System.Data.DataRow, System.Data]][]
61f883e4     1242        84456 System.Reflection.RuntimeParameterInfo
61f8839c     2045        89980 System.Signature
0a7566bc      596        92976 HG.MacamUnit.Entity.TSubSysNodes
61f82788 723 117736 System.Object[] 61f89850 8 131696 System.Int64[] 61fd8938 2792 167520 System.Reflection.RuntimeMethodInfo 007988d0 220 434392 Free 61f824e4 12187 738904 System.String 61f85c40 2138 743067 System.Byte[] 61f82c60 294 6629796 System.Char[] Total 55014 objects 

80.dmp
>.load C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll
>!dumpheap -stat
.....
61f83698      876        24528 System.RuntimeType
61f84ec0      159        26472 System.Collections.Hashtable+bucket[]
61fc9020      631        27764 System.Reflection.RtFieldInfo
61f95be8       46        28392 System.Reflection.Emit.__FixupData[]
61f87928     2292        34012 System.RuntimeType[]
61fd75e0      668        37408 System.Reflection.RuntimePropertyInfo
5d2dcc24       42        43512 System.Data.RBTree`1+Node[[System.Data.DataRow, System.Data]][]
61f8426c      595        45868 System.Int32[]
61f883e4     1242        84456 System.Reflection.RuntimeParameterInfo
61f8839c     2045        89980 System.Signature
61f82788 622 113684 System.Object[] 61f89850 8 131696 System.Int64[] 61fd8938 2769 166140 System.Reflection.RuntimeMethodInfo 61f824e4 9800 676596 System.String 61f85c40 2064 705655 System.Byte[] 61f82c60 195 2369402 System.Char[] 007988d0 114 3338792 Free Total 47306 objects　　

着重分析(紅色部分)這兩個文件的內存分配情況，似乎差別不大，完全看不出來80-33=近50M的內存消耗在哪裡；

但認真思考一下，這樣好像也沒有問題，因為System.***這種類型是C#環境獨有的，已知C#沒有內存泄漏，所以這裏沒有體現應該是正常的；

那C語言接口文件裡邊的問題該如何找出來呢？

 

2、再來試試!heap -s，查看各種堆的內存提交數據量

33.dmp

0:047> !heap -s
LFH Key                   : 0x343fce0b
Termination on corruption : ENABLED
  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                    (k)     (k)    (k)     (k) length      blocks cont. heap 
-----------------------------------------------------------------------------
00780000 00000002    8192   4636   8192    209  2484     4    0      e   LFH
002e0000 00001002     256      4    256      2     1     1    0      0      
00280000 00001002    1088     72   1088      5     2     2    0      0      
00c70000 00041002     256      4    256      2     1     1    0      0      
002d0000 00001002    1088    132   1088      8    23     2    0      0      
00450000 00001002     256      4    256      0     1     1    0      0      
07230000 00041002     256      4    256      2     1     1    0      0      
00c10000 00001002     256    216    256      3    39     1    0      0   LFH
09b50000 00001002     256     80    256     39    28     1    0      0      
09d00000 00001002      64      4     64      2     1     1    0      0      
09ef0000 00001002    1088     72   1088      6     2     2    0      0      
004c0000 00001002    1088    192   1088     15   140     2    0      0      
09760000 00041002     256     28    256      4     4     1    0      0      
09ed0000 00001002      64     12     64      1     1     1    0      0      
0b210000 00001002    3136   1456   3136     52    84     3    0      0   LFH
0a700000 00001002     256    212    256      2     1     1    0      0      
0e1e0000 00011002     256      4    256      0     1     1    0      0      
0d030000 00001002     256     16    256      3     1     1    0      0      
11b30000 00001002    1088    388   1088      0     1     2    0      0      
-----------------------------------------------------------------------------

 

80.dmp

0:051> !heap -s
LFH Key                   : 0x343fce0b
Termination on corruption : ENABLED
  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                    (k)     (k)    (k)     (k) length      blocks cont. heap 
-----------------------------------------------------------------------------
00780000 00000002    8192   4808   8192    225  2505     4    0     f1   LFH
002e0000 00001002     256      4    256      2     1     1    0      0      
00280000 00001002    1088    132   1088      4     6     2    0      0      
00c70000 00041002     256      4    256      2     1     1    0      0      
002d0000 00001002    1088    168   1088     12    26     2    0      0      
00450000 00001002     256      4    256      0     1     1    0      0      
07230000 00041002     256      4    256      2     1     1    0      0      
00c10000 00001002     256    228    256     26    69     1    0      0   LFH
09b50000 00001002     256     80    256     39    25     1    0      0      
09d00000 00001002      64      4     64      2     1     1    0      0      
09ef0000 00001002    1088    132   1088      6     5     2    0      0      
004c0000 00001002    1088    220   1088     26   173     2    0      0      
09760000 00041002     256     28    256      4     8     1    0      0      
09ed0000 00001002      64     12     64      1     1     1    0      0      
0b210000 00001002    3136   1456   3136     74    71     3    0      0   LFH
0a700000 00001002     256    212    256      2     1     1    0      0      
0e1e0000 00011002     256      4    256      0     1     1    0      0      
0d030000 00001002     256     16    256      1     1     1    0      0      
11b30000 00001002   47808  46068  47808    396  6836     7    0      0      
-----------------------------------------------------------------------------

這次有異常了，可以看到11b30000這一行內存提交變化很大 47808 – 1088 = 46720；

這次可以肯定問題就在這個堆裡邊；

3、進去看看11b30000，使用命令：!heap -stat -h 11b30000

80.dmp


0:051> !heap -stat -h 11b30000 
 heap @ 11b30000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
 1f0 102d9 - 1f58470 (92.48) 18 102b0 - 184080 (4.47) 10 102ae - 102ae0 (2.98)
    214 13 - 277c  (0.03)
    1000 2 - 2000  (0.02)
    800 2 - 1000  (0.01)
    220 1 - 220  (0.00)
    1d7 1 - 1d7  (0.00)
    80 3 - 180  (0.00)
    a4 1 - a4  (0.00)
    24 4 - 90  (0.00)
    14 4 - 50  (0.00)
    4a 1 - 4a  (0.00)
    25 2 - 4a  (0.00)
    48 1 - 48  (0.00)
    46 1 - 46  (0.00)
    41 1 - 41  (0.00)
    3e 1 - 3e  (0.00)
    3c 1 - 3c  (0.00)
    37 1 - 37  (0.00)

 

可以看到前面3項幾乎佔據99%的內存提交記錄；尤其以內存塊大小為1f0的數據塊使用最多內存；

到目前為止，我們知道了幾項有效信息，有大小分別為1f0、18、10的三種數據塊，不斷申請出新空間；

但是這樣還不夠，根據一個內存塊的大小並不能準確定位是哪裡出了問題，這是一個結構體？還是字符串？還是數組？

都不知道，所以有必要進去看看，有哪些地方使用到了這些數據塊

 

4、查看使用了1f0數據塊大小的位置列表，使用命令：!heap -flt s [size]

80.dmp

0:051> !heap -flt s 1f0
    _DPH_HEAP_ROOT @ 5a1000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
    _HEAP @ 780000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        0078e5b8 0045 0000  [00]   0078e5e0    001f0 - (busy)
    _DPH_HEAP_ROOT @ 9d11000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
    _HEAP @ 4c0000
    _DPH_HEAP_ROOT @ af41000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
    _HEAP @ b210000
        0cf61680 0045 0045  [00]   0cf616a8    001f0 - (busy)
    _DPH_HEAP_ROOT @ d871000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
    _HEAP @ d030000
    _DPH_HEAP_ROOT @ 11631000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
    _HEAP @ 11b30000
        11b312e8 0045 0045  [00]   11b31310    001f0 - (busy)
        11b315a8 0045 0045  [00]   11b315d0    001f0 - (busy)
        11b356f8 0045 0045  [00]   11b35720    001f0 - (busy)
        11b35920 0045 0045  [00]   11b35948    001f0 - (busy)
        11b36f30 0045 0045  [00]   11b36f58    001f0 - (busy)
        11b37b58 0045 0045  [00]   11b37b80    001f0 - (busy)
        11b37e18 0045 0045  [00]   11b37e40    001f0 - (busy)
        11b3e4f0 0045 0045  [00]   11b3e518    001f0 - (busy)
        11b3f570 0045 0045  [00]   11b3f598    001f0 - (busy)
        11b3f830 0045 0045  [00]   11b3f858    001f0 - (busy)
        11b3faf0 0045 0045  [00]   11b3fb18    001f0 - (busy)
        11b3fdb0 0046 0045  [00]   11b3fdd8    001f0 - (busy)
        12890578 0045 0046  [00]   128905a0    001f0 - (busy)
        ......　　

可以看到有很多堆都有使用到1f0大小的內存塊，但是只有最後一個堆 _DPH_HEAP_ROOT @ 11631000

是記錄最多的，滿屏都是，這裏只能截斷，選取一部分看看　　

5、查看調用堆棧,使用命令：!heap -p -a [address]

80.dmp

0:051> !heap -p -a 11b3fdd8
    address 11b3fdd8 found in
    _HEAP @ 11b30000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        11b3fdb0 0046 0000  [00]   11b3fdd8    001f0 - (busy)
        Trace: 083a
        7405a6a7 verifier!AVrfpDphNormalHeapAllocate+0x000000d7
        74058f6e verifier!AVrfDebugPageHeapAllocate+0x0000030e
        77d10fe6 ntdll!RtlDebugAllocateHeap+0x00000030
        77ccab8e ntdll!RtlpAllocateHeap+0x000000c4
        77c73461 ntdll!RtlAllocateHeap+0x0000023a
        664668e5 msvcr90!_calloc_impl+0x00000125
        66463c5a msvcr90!calloc+0x0000001a

 
0:051> !heap -p -a 11b3fdd8
    address 11b3fdd8 found in
    _HEAP @ 11b30000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        11b3fdb0 0046 0000  [00]   11b3fdd8    001f0 - (busy)
        Trace: 083a
        7405a6a7 verifier!AVrfpDphNormalHeapAllocate+0x000000d7
        74058f6e verifier!AVrfDebugPageHeapAllocate+0x0000030e
        77d10fe6 ntdll!RtlDebugAllocateHeap+0x00000030
        77ccab8e ntdll!RtlpAllocateHeap+0x000000c4
        77c73461 ntdll!RtlAllocateHeap+0x0000023a
        664668e5 msvcr90!_calloc_impl+0x00000125
        66463c5a msvcr90!calloc+0x0000001a

 
0:051> !heap -p -a 11b3fb18
    address 11b3fb18 found in
    _HEAP @ 11b30000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        11b3faf0 0045 0000  [00]   11b3fb18    001f0 - (busy)
        Trace: 083a
        7405a6a7 verifier!AVrfpDphNormalHeapAllocate+0x000000d7
        74058f6e verifier!AVrfDebugPageHeapAllocate+0x0000030e
        77d10fe6 ntdll!RtlDebugAllocateHeap+0x00000030
        77ccab8e ntdll!RtlpAllocateHeap+0x000000c4
        77c73461 ntdll!RtlAllocateHeap+0x0000023a
        664668e5 msvcr90!_calloc_impl+0x00000125
        66463c5a msvcr90!calloc+0x0000001a　　

　　隨意挑選幾個查看調用堆棧，似乎沒有有用的特徵信息，verifier、ntdll、msvcr90這些都是操作系統內核級別的函數；

並不能暴露出使用1f0大小的數據塊大概位置，這就有點難辦了，難道此路不通？如果不找到有效堆棧信息，想定位

內心泄漏點，靠單步調試會相當麻煩。。。

　　不急，先看看，這些地方內存塊內容是什麼，說不定能找到一些有效特徵信息；

使用命令：db [UserPtr]

80.dmp

0:051> db 11b3fb18
11b3fb18  00 00 04 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fb28  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fb38  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fb48  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fb58  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fb68  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fb78  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fb88  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0:051> db 11b3fdd8
11b3fdd8  00 00 04 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fde8  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fdf8  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fe08  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fe18  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fe28  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fe38  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fe48  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0:051> db 11b3fdd8
11b3fdd8  00 00 04 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fde8  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fdf8  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fe08  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fe18  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fe28  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fe38  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
11b3fe48  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................　　

結果是令人失望的；

显示這些基本都是空白內存，裡邊已經沒有任何有效信息，，

陷入死衚衕里了，難道到此為止？

還不死心，我們再看看這些地址有沒有引用跟，如果有引用跟，也可以打印堆棧信息

使用命令：!gcroot [UserPtr]

80.dmp

0:051> !gcroot 11b3fb18
Found 0 unique roots (run '!GCRoot -all' to see all roots).
0:051> !gcroot 11b3fdd8
Found 0 unique roots (run '!GCRoot -all' to see all roots).
0:051> !gcroot 11b3fdd8
Found 0 unique roots (run '!GCRoot -all' to see all roots).

 願望是美好的，這個大小位1f0的數據塊被申請了0x102d9次，使用！gcroot命令查看得到貌似都是無引用的野數據

我們再來看看，這個 _DPH_HEAP_ROOT @ 11631000堆的創建堆棧

80.dmp

0:051> dt ntdll!_DPH_HEAP_ROOT CreateStackTrace 11631000
   +0x0b8 CreateStackTrace : 0x04d54f8c _RTL_TRACE_BLOCK
0:051> dds 0x04d54f8c 
04d54f8c  04d1b714
04d54f90  0000f801
04d54f94  000f0000
04d54f98  74058969 verifier!AVrfDebugPageHeapCreate+0x439
04d54f9c  77cbcea2 ntdll!RtlCreateHeap+0x41
04d54fa0  757356bc KERNELBASE!HeapCreate+0x50
04d54fa4  66463a4a msvcr90!_heap_init+0x1b
04d54fa8  66422bb4 msvcr90!__p__tzname+0x2a
04d54fac  66422d5e msvcr90!_CRTDLL_INIT+0x1e
04d54fb0  77c79264 ntdll!LdrpCallInitRoutine+0x14
04d54fb4  77c7fe97 ntdll!LdrpRunInitializeRoutines+0x26f
04d54fb8  77c7ea4e ntdll!LdrpLoadDll+0x472
04d54fbc  77cbd3df ntdll!LdrLoadDll+0xc7
04d54fc0  75732e6a KERNELBASE!LoadLibraryExW+0x233
04d54fc4  7562483c kernel32!LoadLibraryW+0x11
04d54fc8  6d3d18de*** WARNING: Unable to verify checksum for Win32Project1.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for Win32Project1.dll - 
 Win32Project1+0x18de
04d54fcc  6d3d28fc Win32Project1!BACNet::Init+0x5c
04d54fd0  6d3d5925 Win32Project1!Init+0x25
04d54fd4  66639972*** WARNING: Unable to verify checksum for SMDB.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for SMDB.dll - 
 SMDB!LogPop+0x12
04d54fd8  66639452 SMDB!CreateSharedMemory+0x12
04d54fdc  6d8e47bd clrjit!Compiler::impImportBlockCode+0x2aac [f:\dd\ndp\clr\src\jit32\importer.cpp @ 10258]
04d54fe0  6d8c2e6b clrjit!Compiler::impImportBlock+0x5f [f:\dd\ndp\clr\src\jit32\importer.cpp @ 13246]
04d54fe4  6d8c306a clrjit!Compiler::impImport+0x235 [f:\dd\ndp\clr\src\jit32\importer.cpp @ 14195]
04d54fe8  6d8c364f clrjit!Compiler::compCompile+0x62 [f:\dd\ndp\clr\src\jit32\compiler.cpp @ 2491]
04d54fec  6d8c4276 clrjit!Compiler::compCompileHelper+0x32f [f:\dd\ndp\clr\src\jit32\compiler.cpp @ 3615]
04d54ff0  6d8c43fc clrjit!Compiler::compCompile+0x2ab [f:\dd\ndp\clr\src\jit32\compiler.cpp @ 3086]
04d54ff4  6d8c45c8 clrjit!jitNativeCode+0x1f6 [f:\dd\ndp\clr\src\jit32\compiler.cpp @ 4057]
04d54ff8  6d8c377d clrjit!CILJit::compileMethod+0x7d [f:\dd\ndp\clr\src\jit32\ee_il_dll.cpp @ 180]
04d54ffc  633b39b3 clr!invokeCompileMethodHelper+0x10b
04d55000  633b3a8b clr!invokeCompileMethod+0x3d
04d55004  633b3ae8 clr!CallCompileMethodWithSEHWrapper+0x39
04d55008  633b3d97 clr!UnsafeJitFunction+0x431

動態庫Win32Project1.dll是對MSTP_DLL動態庫的再次封裝可以確定不存在內存泄漏問題；

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

搬家費用：依消費者運送距離、搬運樓層、有無電梯、步行距離、特殊地形、超重物品等計價因素後，評估每車次單

看到這個堆是在於硬件設備通信的時候，初始化時CLR創建的線程；

不過知道這個好像也沒有什麼用，因為我們本來就知道是BACnet協議通信的動態庫有問題；

只能說明是初始化之後產生的內存泄漏；

 

但是為什麼這些無跟指針沒有被垃圾回收？　

但是仔細一想，好像也是正常，因為這些是可以明確的在C語言編寫的動態庫里申請的內存，屬於不受託管的內存；

C#垃圾回收也只能回收託管內存，所以這部分數據不主動釋放，那就會永遠在那裡；

但是現在，好像陷入死衚衕了，找不到思路，既然如此就先放放，先看看其他兩個數據塊的調用情況；

6、!heap -flt s 18

80.dmp

> !heap -flt s 18
...
        16f45098 000a 000a  [00]   16f450c0    00018 - (busy)
        16f45358 000a 000a  [00]   16f45380    00018 - (busy)
        16f45618 000a 000a  [00]   16f45640    00018 - (busy)
        16f458d8 000a 000a  [00]   16f45900    00018 - (busy)
        16f45b98 000a 000a  [00]   16f45bc0    00018 - (busy)
        16f46080 000a 000a  [00]   16f460a8    00018 - (busy)
        16f46118 000a 000a  [00]   16f46140    00018 - (busy)
        16f461b0 000a 000a  [00]   16f461d8    00018 - (busy)
        16f46248 000a 000a  [00]   16f46270    00018 - (busy)
        16f462e0 000a 000a  [00]   16f46308    00018 - (busy)
        16f46378 000a 000a  [00]   16f463a0    00018 - (busy)
        16f46410 000a 000a  [00]   16f46438    00018 - (busy)
        16f464a8 000b 000a  [00]   16f464d0    00018 - (busy)
        16f46548 000a 000b  [00]   16f46570    00018 - (busy)
        16f46808 000a 000a  [00]   16f46830    00018 - (busy)
        16f46ac8 000a 000a  [00]   16f46af0    00018 - (busy)
        16f46d88 000a 000a  [00]   16f46db0    00018 - (busy)
        16f47048 000a 000a  [00]   16f47070    00018 - (busy)
        16f47308 000a 000a  [00]   16f47330    00018 - (busy)
...

7、隨意挑幾個看看，命令:!heap -p -a [UserPtr]　　

80.dmp

0:051> !heap -p -a 
invalid address  passed to `-p -a'0:051> !heap -p -a 16f460a8    
    address 16f460a8 found in
    _HEAP @ 11b30000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        16f46080 000a 0000  [00]   16f460a8    00018 - (busy)
        Trace: 074b
        7405a6a7 verifier!AVrfpDphNormalHeapAllocate+0x000000d7
        74058f6e verifier!AVrfDebugPageHeapAllocate+0x0000030e
        77d10fe6 ntdll!RtlDebugAllocateHeap+0x00000030
        77ccab8e ntdll!RtlpAllocateHeap+0x000000c4
        77c73461 ntdll!RtlAllocateHeap+0x0000023a
        664668e5 msvcr90!_calloc_impl+0x00000125
        66463c5a msvcr90!calloc+0x0000001a
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for MSTP_DLL.dll - 
        669baea1 MSTP_DLL!MSTP_Get_RPM_ACK_Data+0x00000091

 
0:051> !heap -p -a 16f46570    
    address 16f46570 found in
    _HEAP @ 11b30000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        16f46548 000a 0000  [00]   16f46570    00018 - (busy)
        7405a6a7 verifier!AVrfpDphNormalHeapAllocate+0x000000d7
        74058f6e verifier!AVrfDebugPageHeapAllocate+0x0000030e
        77d10fe6 ntdll!RtlDebugAllocateHeap+0x00000030
        77ccab8e ntdll!RtlpAllocateHeap+0x000000c4
        77c73461 ntdll!RtlAllocateHeap+0x0000023a
        664668e5 msvcr90!_calloc_impl+0x00000125
        66463c5a msvcr90!calloc+0x0000001a
        669baea1 MSTP_DLL!MSTP_Get_RPM_ACK_Data+0x00000091

 
0:051> !heap -p -a 16f46308
    address 16f46308 found in
    _HEAP @ 11b30000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        16f462e0 000a 0000  [00]   16f46308    00018 - (busy)
        Trace: 074b
        7405a6a7 verifier!AVrfpDphNormalHeapAllocate+0x000000d7
        74058f6e verifier!AVrfDebugPageHeapAllocate+0x0000030e
        77d10fe6 ntdll!RtlDebugAllocateHeap+0x00000030
        77ccab8e ntdll!RtlpAllocateHeap+0x000000c4
        77c73461 ntdll!RtlAllocateHeap+0x0000023a
        664668e5 msvcr90!_calloc_impl+0x00000125
        66463c5a msvcr90!calloc+0x0000001a
        669baea1 MSTP_DLL!MSTP_Get_RPM_ACK_Data+0x00000091　　

這次很順利，這個內存使用的地方實在MSTP_DLL的 MSTP_Get_RPM_ACK_Data裡邊；這個就是我們要找的最終的內存泄漏點信息；

同樣操作堆10大小的數據塊操作一遍

80.dmp

> !heap -flt s 10
...
        15359fa0 0009 0009  [00]   15359fc8    00010 - (busy)
        1535a2a0 0009 0009  [00]   1535a2c8    00010 - (busy)
        1535a560 0009 0009  [00]   1535a588    00010 - (busy)
        1535aee8 0009 0009  [00]   1535af10    00010 - (busy)
        1535af80 0009 0009  [00]   1535afa8    00010 - (busy)
        1535b018 0009 0009  [00]   1535b040    00010 - (busy)
        1535b360 0009 0009  [00]   1535b388    00010 - (busy)
        1535b620 0009 0009  [00]   1535b648    00010 - (busy)
        1535c420 0009 0009  [00]   1535c448    00010 - (busy)
        1535d220 0009 0009  [00]   1535d248    00010 - (busy)
        1535d4e0 0009 0009  [00]   1535d508    00010 - (busy)
        1535d7a0 0009 0009  [00]   1535d7c8    00010 - (busy)
        1535da60 0009 0009  [00]   1535da88    00010 - (busy)
        1535dd20 0009 0009  [00]   1535dd48    00010 - (busy)
        1535dfe0 0009 0009  [00]   1535e008    00010 - (busy)
        1535e2a0 0009 0009  [00]   1535e2c8    00010 - (busy)
        1535e560 0009 0009  [00]   1535e588    00010 - (busy)
        1535e820 0009 0009  [00]   1535e848    00010 - (busy)
        1535eae0 0009 0009  [00]   1535eb08    00010 - (busy)
        1535eda0 0009 0009  [00]   1535edc8    00010 - (busy)
        1535f060 0009 0009  [00]   1535f088    00010 - (busy)
        1535f320 0009 0009  [00]   1535f348    00010 - (busy)
        1535f5e0 0009 0009  [00]   1535f608    00010 - (busy)
...

80.dmp

0:051> !heap -p -a 1535eb08    
    address 1535eb08 found in
    _HEAP @ 11b30000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        1535eae0 0009 0000  [00]   1535eb08    00010 - (busy)
        Trace: 0817
        7405a6a7 verifier!AVrfpDphNormalHeapAllocate+0x000000d7
        74058f6e verifier!AVrfDebugPageHeapAllocate+0x0000030e
        77d10fe6 ntdll!RtlDebugAllocateHeap+0x00000030
        77ccab8e ntdll!RtlpAllocateHeap+0x000000c4
        77c73461 ntdll!RtlAllocateHeap+0x0000023a
        664668e5 msvcr90!_calloc_impl+0x00000125
        66463c5a msvcr90!calloc+0x0000001a
        669bb07b MSTP_DLL!MSTP_Get_RP_ACK_Data+0x0000003b

 
0:051> !heap -p -a 1535f088    
    address 1535f088 found in
    _HEAP @ 11b30000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        1535f060 0009 0000  [00]   1535f088    00010 - (busy)
        Trace: 0817
        7405a6a7 verifier!AVrfpDphNormalHeapAllocate+0x000000d7
        74058f6e verifier!AVrfDebugPageHeapAllocate+0x0000030e
        77d10fe6 ntdll!RtlDebugAllocateHeap+0x00000030
        77ccab8e ntdll!RtlpAllocateHeap+0x000000c4
        77c73461 ntdll!RtlAllocateHeap+0x0000023a
        664668e5 msvcr90!_calloc_impl+0x00000125
        66463c5a msvcr90!calloc+0x0000001a
        669bb07b MSTP_DLL!MSTP_Get_RP_ACK_Data+0x0000003b

 
0:051> !heap -p -a 1535f348    
    address 1535f348 found in
    _HEAP @ 11b30000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        1535f320 0009 0000  [00]   1535f348    00010 - (busy)
        Trace: 0817
        7405a6a7 verifier!AVrfpDphNormalHeapAllocate+0x000000d7
        74058f6e verifier!AVrfDebugPageHeapAllocate+0x0000030e
        77d10fe6 ntdll!RtlDebugAllocateHeap+0x00000030
        77ccab8e ntdll!RtlpAllocateHeap+0x000000c4
        77c73461 ntdll!RtlAllocateHeap+0x0000023a
        664668e5 msvcr90!_calloc_impl+0x00000125
        66463c5a msvcr90!calloc+0x0000001a
        669bb07b MSTP_DLL!MSTP_Get_RP_ACK_Data+0x0000003b　　

這次也順利拿到另一個內存泄漏的位置信息在MSTP_DLL的 MSTP_Get_RP_ACK_Data裡邊；　　

MSTP_Get_RP_ACK_Data

MSTP_Get_RPM_ACK_Data

這兩個方法其實是讀取模塊點數值或者收集模塊信息的時候返回的一個數據指針；

現在很明顯這兩個方法返回的指針可能是有問題的，裡邊非常大的可能存在內存泄漏；

7、驗證

跟同事找到原來的MSTP_DLL的源碼，找到以上兩個方法體

 

 可以看到當初那位同事設計這個方法的時候，很明顯有2個錯誤；

1）返回的指針只見聲明內存空間，不見釋放；

2）返回數據的指針不應該在方法體中的返回值中傳出來，應該寫在方法參數中，外部聲明，傳進去賦值，然後外部使用，再外部釋放

3）兩個方法體都一樣的問題

 

五、整理

1）我們知道有三處內存泄漏，分別大小是1f0、18、10 

2）三者佔據99%的新增不釋放的內存消耗

3）我們已經找到其中兩個泄漏位置，還剩下一個

4）1f0是重中之重，佔據內存消耗92%，不解決這個BUG，問題基本就相當於沒解決

5）無法找到1f0的調用堆棧信息，無明顯特徵信息，無引用跟；

5）emmmmm? （第二聲）

 

好像被我們錯過了一個信息， 

是否還記得最開始那一段？

80.dmp

0:051> !heap -stat -h 11b30000 
 heap @ 11b30000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
    1f0 102d9 - 1f58470  (92.48)
    18 102b0 - 184080  (4.47)
    10 102ae - 102ae0  (2.98)　　

 這幾個數據很接近，都是申請次數大小，也就是說著三個數據塊被申請的次數差不多。。

鑒於此，我們再去看看33M內存的時候這幾個次數的值是多少

33.dmp

0:047> !heap -s
LFH Key                   : 0x343fce0b
Termination on corruption : ENABLED
  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                    (k)     (k)    (k)     (k) length      blocks cont. heap 
-----------------------------------------------------------------------------
00780000 00000002    8192   4636   8192    209  2484     4    0      e   LFH
002e0000 00001002     256      4    256      2     1     1    0      0      
00280000 00001002    1088     72   1088      5     2     2    0      0      
00c70000 00041002     256      4    256      2     1     1    0      0      
002d0000 00001002    1088    132   1088      8    23     2    0      0      
00450000 00001002     256      4    256      0     1     1    0      0      
07230000 00041002     256      4    256      2     1     1    0      0      
00c10000 00001002     256    216    256      3    39     1    0      0   LFH
09b50000 00001002     256     80    256     39    28     1    0      0      
09d00000 00001002      64      4     64      2     1     1    0      0      
09ef0000 00001002    1088     72   1088      6     2     2    0      0      
004c0000 00001002    1088    192   1088     15   140     2    0      0      
09760000 00041002     256     28    256      4     4     1    0      0      
09ed0000 00001002      64     12     64      1     1     1    0      0      
0b210000 00001002    3136   1456   3136     52    84     3    0      0   LFH
0a700000 00001002     256    212    256      2     1     1    0      0      
0e1e0000 00011002     256      4    256      0     1     1    0      0      
0d030000 00001002     256     16    256      3     1     1    0      0      
11b30000 00001002    1088    388   1088      0     1     2    0      0      
-----------------------------------------------------------------------------
0:047> !heap -stat -h 11b30000 
 heap @ 11b30000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
    1f0 1f2 - 3c4e0  (86.13)
    18 1c9 - 2ad8  (3.82)
    1000 2 - 2000  (2.86)
    10 1c7 - 1c70  (2.54)
    214 c - 18f0  (2.23)
    800 2 - 1000  (1.43)
    220 1 - 220  (0.19)
    1d7 1 - 1d7  (0.16)
    80 3 - 180  (0.13)
    a4 1 - a4  (0.06)
    24 4 - 90  (0.05)
    14 4 - 50  (0.03)
    4a 1 - 4a  (0.03)
    25 2 - 4a  (0.03)
    48 1 - 48  (0.03)
    46 1 - 46  (0.02)
    41 1 - 41  (0.02)
    3e 1 - 3e  (0.02)
    3c 1 - 3c  (0.02)
    37 1 - 37  (0.02)　　

 分別是1f2、1c9、1c7;

1f0：102d9 – 1f2 = 65767

18：102b0 – 1c9 = 65767

10：102ae – 1c7 = 65767

居然申請的次數一模一樣！

穩了！這個1f0可以斷定與其他兩個緊密相關；首先懷疑的就是

MSTP_Get_RP_ACK_Data

MSTP_Get_RPM_ACK_Data

1）這兩個方法體中使用到的所有子方法體有沒有申請空間的語句；

2）申請的空間大小是不是就是1f0；

 

依據上面的推測，再次閱讀那2個方法體；

 

 

 

 

經過分析BACNET_APPLICATION_DATA_VALUE結構體大小剛好就是1f0 

好了，搞定

 

如果對你有幫助，請點贊、評論；　　

　

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

節能減碳愛地球是景泰電動車的理念，是創立景泰電動車行的初衷，滿意態度更是服務客戶的最高品質，我們的成長來自於你的推薦。

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

以設計的實用美學觀點，規劃出舒適、美觀的視覺畫面，有效提昇使用者的心理期待，營造出輕鬆、愉悅的網站瀏覽體驗。

4T渦輪增壓發動機，最大功率為140匹，最大扭矩為200牛米，匹配了一台6速手自一體變速箱，加速時初段反映還是不錯的，不過據市場反映，其運用的普利司通輪胎質量容易開裂。北京現代ix25指導價:11。98-18。68萬最大優惠價1。6萬元北京現代ix25自上市以來還沒有經歷過改款，在市場的受歡迎程度也僅次於本田XR-V車型，月銷量維持在1萬輛左右，現在全國市場普遍優惠1萬元左右，最優惠的是成都，達到了1。

年底買車優惠大，確實是很多消費者所想的，眼看着金九銀十這個最佳買車時期快過去了，可能接下來買車的時機還有下個月的廣州車展，以及元旦前經銷商為了沖銷量榜這幾個優惠期間了，但這一期介紹的這幾款10萬級小型SUV，常年的優惠也很大，最大達到了2.2萬元，如果與銷售多磨一磨價格，確實能夠在你的預算中再狠狠地砍個幾千塊，話不多說，趕緊往下看。

東風標緻2008

指導價:9.97-16.37萬

最大優惠價2.2萬元

標緻2008在全國各地具有1.5萬元以上的優惠，其中在上海地區的優惠最大，全系優惠達到了2-2.2萬元。

作為東風標緻的一款小型SUV產品標緻2008，車身最大的亮點就是擁有着全景天幕玻璃頂和超大視野的前擋風玻璃，透視感極佳，配合高品質的遮陽簾可以隔絕八成以上的紅外線，以及99%的紫外線，外觀設計上與208有些相似，都採用了極具運動風格的前臉設計，再加上車身的越野套件，整體形象十分硬朗。

動力上全新標緻2008搭載1.2T三缸的渦輪增壓發動機，以及1.6L自然吸氣發動機和1.6T渦輪增壓發動機，如今小排量渦輪發動機已經是發展趨勢，如果只是想用來代步，稍微兼容起家用空間的朋友們，可以入手1.2T發動機版本，百公里油耗為7L，安全配置齊全，帶ESp車身穩定和發動機啟停系統，經濟油耗低同時動力又跟得上，但後排空間稍微比較小，喜歡這款車的朋友可以去實測一下。

上汽通用 雪佛蘭創酷

指導價:10.99-14.99萬

最大優惠價2.0萬元

新款雪佛蘭創酷上市時，廠家主要是針對該車型進行一些配置的升級，創酷在全國平均有1萬元以上的優惠，在上海地區的優惠幅度最大，達到了1.6-2.0萬元。

雪佛蘭創酷採用了和別克昂科拉相同的平台打造，到售價卻比昂科拉便宜了挺多，創酷的車身外觀肌肉感比較強，線條簡潔，有着美系車的獨有味道，但整體的外觀還是比較中庸。

內飾風格依然非常地簡約，

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

台中景泰電動車行只是一個單純的理由，將來台灣的環境，出門可以自由放心的深呼吸，讓空氣回歸自然的乾淨，減少污染，留給我們下一代有好品質無空污的優質環境

中控台按鈕劃分清晰，比較容易上手，儀錶盤為單轉速表，右側則有行車電腦显示屏和數顯時速表。配置上全系標配ESp車身穩定系統，電動天窗，上坡輔助等等，而頂配還多了真皮座椅，倒車雷達，中控大屏等等。

動力上則搭載了1.4T渦輪增壓發動機，最大功率為140匹，最大扭矩為200牛米，匹配了一台6速手自一體變速箱，加速時初段反映還是不錯的，不過據市場反映，其運用的普利司通輪胎質量容易開裂。

北京現代ix25

指導價:11.98-18.68萬

最大優惠價1.6萬元

北京現代ix25自上市以來還沒有經歷過改款，在市場的受歡迎程度也僅次於本田XR-V車型，月銷量維持在1萬輛左右，現在全國市場普遍優惠1萬元左右，最優惠的是成都，達到了1.6萬元的優惠。

外觀設計上，北京現代ix25依舊延續了現代家族“流體雕塑2.0”的設計語言，相對於其他的現代車型，現代ix25顯得更加硬朗帥氣，非常符合國人的審美觀。

內飾同樣沒有太多花哨的設計，比較實用，硬塑料比較多，沒有其他點綴之物。新車標配了車身穩定系統，定速巡航，坡道輔助，倒車雷達，全景天窗，多功能方向盤，藍牙和一鍵啟動功能，確實性價比非常之高，動力則有1.6L和2.0L自然吸氣發動機和1.6T渦輪增壓發動機，能夠滿足對於動力不同需求的消費者，變速箱則涵括了6擋手動，6擋自動和6速雙離合變速器。

上汽大眾斯柯達Yeti

指導價：12.98-20.98萬

最大優惠價1.8萬元

新款斯柯達Yeti車型，取消了以前的老名字“野帝”，斯柯達Yeti在全國各地均為1萬元左右的優惠，其中上海地區的優惠還是最大，幅度達到了1.2-1.8萬元。

新款Yeti在外觀上並不會和老款野帝相差太多，只是在翼子板上多了些許裝飾件，更換了全新的輪圈，整體外觀看起來比較方正。

儀錶盤採用大眾傳統的雙錶盤+中央單色液晶显示屏，沒有什麼新意，後排座椅能夠前後移動，在空間靈活多變，比較實用。配置上大部分版本都配備了ESp車身穩定系統，全系標配電動天窗，動力上則搭配了1.6L自然吸氣發動機，1.4T和1.8T渦輪增壓發動機，變速箱則分別搭載5擋手動，7速雙離合和6速雙離合變速器。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

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

網站的第一印象網頁設計，決定了客戶是否繼續瀏覽的意願。台北網動廣告製作的RWD網頁設計，採用精簡與質感的CSS語法，提升企業的專業形象與簡約舒適的瀏覽體驗，讓瀏覽者第一眼就愛上它。

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

擁有後台管理系統的網站，將擁有強大的資料管理與更新功能，幫助您隨時新增網站的內容並節省網站開發的成本。

98-16。58萬元上汽通用別克-英朗指導價：10。99-15。99萬元東風本田-思域指導價：12。18-19。98萬元總結：會刻意選擇獨立后懸挂，證明你對汽車的操控和舒適性等底盤表現是有一定要求的，當然市面上也有些獨懸的車開起來也不咋地，文中所提及的幾輛車，都是緊湊型裏面使用獨懸的同時底盤操控的表現都不錯的。

一輛車配備獨立后懸挂，往往意味着比非獨立懸挂車型有更好的操控性和舒適性表現，但車輛的實際行駛品質，

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

擁有後台管理系統的網站，將擁有強大的資料管理與更新功能，幫助您隨時新增網站的內容並節省網站開發的成本。

又和底盤調校有莫大關係。既然這樣，在獨立后懸的車子裏面找出月銷量破萬的車型，這些被市場認可的車子，相信底盤調校的功底自然不會差。跟看看這樣的車子有那幾輛？

長安馬自達-昂克賽拉

指導價：11.49-15.99萬元

長安福特-福克斯

指導價：9.98-16.58萬元

上汽通用別克-英朗

指導價：10.99-15.99萬元

東風本田-思域

指導價：12.18-19.98萬元

總結：會刻意選擇獨立后懸挂，證明你對汽車的操控和舒適性等底盤表現是有一定要求的，當然市面上也有些獨懸的車開起來也不咋地，文中所提及的幾輛車，都是緊湊型裏面使用獨懸的同時底盤操控的表現都不錯的。想要兼顧駕駛樂趣和家庭用車，不妨考慮這些傢伙。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

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

擁有後台管理系統的網站，將擁有強大的資料管理與更新功能，幫助您隨時新增網站的內容並節省網站開發的成本。

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

透過資料庫的網站架設建置，建立公司的形象或購物系統，並提供最人性化的使用介面，讓使用者能即時接收到相關的資訊

另一方面，很多低端的車子，都會全系標配手動變速箱來壓低售價，像寶駿310、長安歐尚就是這樣的角色。所以就目前的經濟狀況來看，手動擋汽車的存在無論對於消費者還是廠商來說，還是有很大意義。假如不管好壞，只要最好玩呢。

據國外媒體消息，法拉利首席技術官Michael HugoLeiters接受採訪時表示，法拉利未來將不會再推出手動擋車型，因此，California成為了法拉利最後一款可以選裝手動變速箱的車型。

聽到了這個消息，作為法拉利車迷的不禁為之震驚，而震驚以後，更多的惋惜。在這個微涼的傍晚，不禁在思考，連跑車都開始放棄手動變速箱了，那這個變速箱還有存在的意義嗎？

雙離合真的比手動擋要快

要評價一個變速箱的性能，主要看它的換擋邏輯、平順性和換擋速度。從換擋邏輯和平順性來看，雙離合的表現主要跟廠商的調校有關，實際表現也是有好有壞的，而手動變速箱則主要跟個人的操作有關，新老司機的差別也很大。所以最具可比性的應該是兩種變速箱的換擋速度了，不說保時捷的pDK了，光大眾的DSG，官方就膽敢給出200毫秒的換擋速度，而手動擋呢？踩離合、從原擋位拔出、再推進新的擋位、松離合，即使是老司機，完成這一套動作的時間也不可能少於200毫秒吧？所以你要是單論換擋速度，雙離合真的完勝手動擋。

但手動擋有一個無敵的優點

手動變速箱造價低，手動擋車也一般比自動擋要便宜差不多一萬軟妹幣，所以對於部分消費者來說，想購得心儀的車輛又想省錢的話，手動擋就是最佳的選擇。對於廠商來說，手動擋則是一個市場工具，用來拉低新車的整體售價，博取眼球，

※想知道最厲害的網頁設計公司嚨底家"!

RWD（響應式網頁設計）是透過瀏覽器的解析度來判斷要給使用者看到的樣貌

而實際上，很多手動擋的最低配車型，壓根就很難買到。像新思域的手動版本，都幾乎成了珍稀物品。另一方面，很多低端的車子，都會全系標配手動變速箱來壓低售價，像寶駿310、長安歐尚就是這樣的角色。所以就目前的經濟狀況來看，手動擋汽車的存在無論對於消費者還是廠商來說，還是有很大意義。

假如不管好壞，只要最好玩呢？

新手開手動擋一天下來，左腳都是要報廢的節奏，市區擁堵路段的頻繁換擋更是考驗司機手臂耐力和換擋技巧，手動擋的各種麻煩相信都是不言而喻的。那還有沒有在購車預算充足的情況下還願意購買手動擋汽車的人？答案是肯定的，就有一位這樣的朋友，他是手動版昂克賽拉的車主。還記得那天和他開車出去吃飯，隔壁車道也來了一輛昂克賽拉，右側車道的我們眼看前面修路必須要併入左側車道，但隔壁的車子絲毫沒有避讓的意思，緊急時候，豈能認慫？只見他踩下離合，一個之字型的手勢，馬上從5擋換下4擋，小昂轉速馬上飈至3500，緊跟一腳油門和及時的打方向，順利搶在鄰車前面進入左車道，揚長而去。

當然，並不是呼籲大家要怎樣的暴力駕駛，只是想讓大家知道，有些樂趣，只有手動擋能給你。它不是最好的，但一定是最好玩的。

總結：就像汽車會取代馬車那樣，舊事物總是會被更符合人們需求的新事物所取代，自動擋逐漸取代手動擋，這是個必然的趨勢。車企會繼續生產手動擋汽車，但也絕對不是因為部分人的情懷，相信手動擋並不會消失，就像在這個汽車工業發達的年代，在旅遊景點里不是還有人坐馬車嗎？本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

當全世界的人們隨著網路時代而改變向上時您還停留在『網站美醜不重要』的舊有思維嗎？機會是留給努力改變現況的人們，別再浪費一分一秒可以接觸商機的寶貴時間！

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

日本、大陸，發現這些先進的國家已經早就讓電動車優先上路，而且先進國家空氣品質相當好，電動車節能減碳可以減少空污

　　圖一

　　圖二

　　“花饃”是陝西走親訪友的互贈禮品，也是鄉土風情濃郁的藝術奇葩。圖為陝西省合陽縣村民李金賢（左）與婆婆為花饃上彩。新華社

　　臘月二十三小年一過，陝北人就開始做“年茶飯”，即春節傳統食物，神木叫“熬年食子”。年茶飯主要是容易存放的麵食、肉食等。比如，過生日、過年必不可少的“糕”；白黃相間的凌形蒸饃“糕斜”；還有因《舌尖上的中國》而名聲大噪的“黃饃饃”。肉食主要是丸子、酥雞、燒肉、清蒸雞、豬肉鑽雞等。

　　在年茶飯和日常飲食的製作和名稱中，有幾個頗具地方特色的高頻詞。最有特色、出現頻率最高的詞首選“和”，其次是“燴、熬”，還有“拼”等。這些詞凸顯了陝北語言和飲食文化的特點。

　　（一）和（huò）

　　“和”讀huò，去聲，《現代漢語詞典》解釋為：“把粉狀或粒狀物摻和在一起，或加水攪拌使成較稀的東西：～葯〡藕粉里～點兒糖。”陝北飲食詞語中的“和”，意義比普通話寬泛，指把不同的食材摻到一起烹制和食用。“和”在《廣韻》“胡卧切”中，“聲相應。”此義普通話讀[hè]，用於詩文唱和。《廣韻》“胡卧切”另有一個“盉”字，指調味。此義保留在陝北話的“調和[tiáohuò]”一詞中，指調料。方言中的“和”，本字應該就是“盉”。“調味”是將調料加入食材，將不同食材“調和”在一起。

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

有別於一般網頁架設公司，除了模組化的架站軟體，我們的營業主軸還包含：資料庫程式開發、網站建置、網頁設計、電子商務專案開發、系統整合、APP設計建置、專業網路行銷。

　　比如，八分黃米面“和”二分糕面（軟黃米面，又叫軟糜子面），蒸“黃饃饃”；兩層厚厚的白面中間夾一層糕面，蒸“糕斜”，神木人把白面“和”上粱穀米面蒸“米面饃饃”。困難時期，常用白面“和”上玉米面蒸“兩面饃饃”，玉米面“和”上黑豆面或高粱面蒸“窩窩”。

　　除了將不同的米、面“和”起來做飯，還可將主食和副食，或幾種副食“和”在一起。這時“和”就直接進入了飲食名稱。例如“面和和飯”，將穀米、山藥圪瘩瘩（土豆丁兒）放在一起熬，快熟時把麵條煮進去，再“和”以炒酸菜。整個晉語區都有這種吃法，綏德叫“和和飯”，延安叫“和淘”“和飯”，山西太原、清徐叫“和子飯”。

　　（二）燴（huì）

　　“燴”在《現代漢語詞典》中的解釋是：“①烹調方法：炒菜后加少量的水和芡粉：～蝦仁〡～什錦。②烹調方法，把米飯等和葷菜、素菜混在一起加水煮：～飯〡～餅”。“燴（燴）”是後起字，《廣韻》未收。從“燴菜、燴餅”等的烹調方法看，這個字應當是從“會”孳乳出來的。

　　“燴”無疑是陝北副食中最常用的動詞。陝北人過去不炒碟子菜，所有熱菜都是多種原料燴出來的。肉燴菜，是用豬骨肉、白豆腐、山藥、酸菜、粉條燴的菜，是人們最喜愛的葷菜。素燴菜，主料多為白豆腐、山藥、酸菜，熗鍋時加上當地特有的“擇蒙兒（類似野韭菜）”。夏天就加入紅豆兒（豆角）、茄子、蓮花白等時令蔬菜。以“酸菜”為主的素燴菜也叫“熬酸菜”。“燴粉湯”配油糕，是過年、結婚、過生日、慶祝升學的必備食品。燴粉湯是用粉條兒配上羊肉丁兒或雞絲兒、丸子、炸豆腐、金針等做成的臊子。在日常生活中，“扁食粉湯、餃子粉湯”都是佳配。

　　（三）熬（áo）

　　“熬”是指把糧食等放在水裡，煮成糊狀，如：～粥。陝北飲食中所有的稀飯都是“熬”出來的，如熬米湯、熬稠粥、熬八寶飯；副食也要熬，如熬臊子、熬酸菜、熬骨頭湯。此外，煎湯藥叫“熬藥”，冬至日燉豬頭、燉羊肉叫“熬冬”。做“年茶飯”神木叫“熬年食子”，可見“熬”字在飲食文化中的重要地位。

　　在方言中，“熬”主要作為動詞使用，用“熬”命名的飯菜較少。榆林、米脂、綏德冬天常吃“熬菜”，是把晒乾的豆角浸泡后，和土豆塊兒、豬肉片、酸菜一起熬。“西葫蘆兒熬羊肉”“茄子熬羊肉”則是夏末、秋天羊肥了以後常吃的好菜。諺語云：“六月六，西葫蘆兒/茄子熬羊肉。”

　　把“和”“燴”“熬”三個詞合起來看，陝北人飲食習慣的核心，可以用一個“和”字來概括：稀飯可以和菜，小米稀粥可以和麵條兒，小米可以和大米、黃米，糜子米可以和黍子米，白面可以和玉米面、小米面。撈飯要和上菜吃，麵條、揪片兒、抿夾兒、圪飥兒等麵食都要和上臊子吃，挂面、餄餎、擀豆面要和上臊子吃。

　　飲食用詞也延伸到了陝北方言的日常用語中，現代語言學叫“隱喻”。陝北晉語把不睡覺趕夜工叫“熬夜”，把大年三十兒晚上守歲叫“熬年”，把打工叫“熬工”，把折磨和被折磨的狀態叫“熬煎、煎熬”。有一條嘲諷懶人的諺語云：“白日兒游門走四方，黑夜熬油補褲襠。”尤其有意思的是把“累”叫“熬”，由動詞引申為形容詞，“熬死了”（累極了）是陝北人的口頭禪，還可組成“熬累、熬乏、熬苦、苦熬實掙”等詞。“和”則可構成“夾和、摻和、攪和、調和”等詞。飲食習慣在人際關係的表達上也有所反映。陝北人把稀飯、米湯黏叫（見圖一），將人和人（尤指親戚之間）關係親近、走動多叫（見圖二），把頭腦清醒、辦事利索叫“湯清水利”或“清湯利水”。

　　不論是年茶飯還是平日的飲食習慣，乃至有關的日常用語，最能體現一個地方的地理、物產和風俗特點。陝北位於農耕文化和牧業文化的交接地帶，多山、缺水，土地貧瘠，盛產谷、糜、黍、蕎、豆等雜糧，主食較為豐富，羊、豬、雞肉較多，但蔬菜匱乏，從9月一直到第二年5月，副食主要是土豆、白菜。正因如此，陝北人就想方設法藉助“和”來做出花樣美食。三個飲食特色詞，不僅反映了陝北地區飲食文化的特點，而且反映出特有的飲食文化在語言生活乃至社會心理上的投射。（邢向東）

本站聲明:網站內容來http://www.societynews.cn/html/wh/fq/,如有侵權,請聯繫我們,我們將及時處理

※超省錢租車方案

商務出差、學生出遊、旅遊渡假、臨時用車!GO 神州租賃有限公司!合法經營、合法連鎖、合法租賃小客車!

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

網動廣告出品的網頁設計，採用精簡與質感的CSS語法，提升企業的專業形象與簡約舒適的瀏覽體驗，讓瀏覽者第一眼就愛上她。

北宋年間，家家戶戶貼年畫已是一種風尚，也由此，木版年畫在歷史的長河中始終留存着時尚的記憶。當代，手工木版年畫被以非物質文化遺產的形態加以保護，同時，傳承和創新也成為木版年畫傳承人肩負的兩個重任。有這樣一群人，他們視木版年畫為中國民間藝術寶庫中的一顆璀璨明珠，一直走在挖掘、創新、變革的路上。又是新年將至，今年的木版年畫可以為人們帶來哪些新意？這些心心念念的新時代“年畫家”都在忙些什麼？

 設計師王全傑 ：年畫新可能

楊柳青年畫周曆簽

新年將至，北京順義區的一所小院里，設計師王全傑剛剛忙完楊柳青年畫周曆簽——2020年“世象新語”周曆的預售，5000套周曆幾乎都已被單位預定出去。初次嘗試與楊柳青木版年畫合作，並能夠得到市場的認可，王全傑不斷回味。

2019年7月，王全傑在清華美院校友召喚下加入了年畫日新創作營，本着對於年畫的關注與喜愛，帶着輕鬆自在的心情，王全傑輕裝上陣了。

剛入營，兩件事讓王全傑心情無法平靜。首先創作營的主辦方將組織結構安排得相當縝密，全國11個木版年畫產地會自發組成一個個創作小組（注：最終實際組成了9個創作小組），年畫傳承人+插畫師+設計師+導師（清華美院和中央美院的教授和副教授）作為一個小組組合，王全傑成了楊柳青組組長。主辦方的安排是，經過一個階段的年畫知識學習，再經歷1個月的創作，然後做出創新作品和產品進行展覽，最後對社會公開創作成果。

在學習了年畫知識、深入年畫創作地區了解了年畫歷史后，王全傑原先以為會憑藉著豐富設計經驗輕鬆完成這份任務，但卻被厚重的傳統文化攪動了內心。“真是無處下手，年畫傳承人深陷其中很難改變，我們作為外來者，出於對老祖宗留下的這些寶物的敬畏，似乎也不敢隨便說、隨便做了。”王全傑說。

一個月的迷茫期過後，王全傑總結出年畫轉化的兩個難點：第一，作為傳承人，雖然擁有老祖宗留下的年畫模板、掌握着傳統的刻畫技藝，但是缺少產品轉化能力；第二，作為外來者——設計人員，雖有很強的設計能力，但究竟轉化成什麼是最大的難點。

王全傑在腦海中翻轉：做什麼樣的產品，怎麼能體現楊柳青風格，怎麼能有新意，怎麼能增加使用的體驗感、情景感，還得製造點小驚喜。

經歷了無數個靈感的沉浮，一次次被自己或小組成員否定，王全傑關於周曆的創意橫空出世。機緣巧合的是，這樣一個創意很快得到北京一家企業的認可，並有意出資支持該創意。王全傑信心倍增。

“創意有了，落實到產品時，第一版就被出資方否定了。”王全傑再次回到原點。利用楊柳青年畫元素設計的第一版周曆美觀，但缺少生活黏性、很難達到與使用者的互動。

年畫日新創作營楊柳青組設計師們再次前往楊柳青，找到楊柳青木版年畫國家級非遺傳承人霍慶順，聽霍慶順細數年畫民俗，並對其所擁有的與老百姓生活相關的藏品做了仔細研究。霍慶順老人一句話點亮了王全傑內心。

“你看踩高蹺，大多數人都只看到表面上的熱鬧，但很少有人知道這其中最主要的用意是祭拜藥王、祈福安康。進入年關，每一天都有特殊的意義……”這句話就像一把開啟創意之門的鑰匙，為迷途中的王全傑和設計師們打開了門：“周曆的基礎上加入日曆，在臘月的最後一周開始日曆倒計時。”

創意有了，楊柳青創作小組成員連續两天兩夜的頭腦風暴，將創意再次細化落實在產品上：在周曆基礎之上特別策劃的“過年日曆”，篇篇辣詞趣語，以當下語境直入現代生活，內置如意轉盤每天跟你靈犀互動。這些新意讓2020年“世象新語”周曆產品順利出版落地。

“我們設計師想給楊柳青木版年畫傳承者做出一個示範，讓他們看到傳統年畫與當代流行文化融合的更多可能性。為大眾提供一個日常使用載體，讓人們了解楊柳青木版年畫的豐富性和多樣性。”王全傑說。

故事記錄者恭弘=叶 恭弘萌 ：回歸當代時尚

穀雨平台上的金華木板年畫

對傳統手工藝有着濃厚興趣的恭弘=叶 恭弘萌，探索傳統與當代文化融合的路徑用了5年時間，為了讓更多人了解傳統手工藝他組建了一個傳統手工藝視頻傳播平台——穀雨，這個平台免費為手工藝人們拍攝宣傳片。

※產品缺大量曝光嗎?你需要的是一流包裝設計!

窩窩觸角包含自媒體、自有平台及其他國家營銷業務等，多角化經營並具有國際觀的永續理念。

“中國上下五千年，從來不缺故事，但卻沒有人會講這些中國故事，有太多我們為之自豪的傳統手工藝散落於四野。如果不能讓人看見，又何談傳承呢？”恭弘=叶 恭弘萌說。

恭弘=叶 恭弘萌畢業於中國美術學院視覺傳達系。他做過設計師，參与設計的項目有中國國際西湖博覽會、第21屆金雞百花電影節標誌等；在電視台工作了十幾年。為了追逐心中的夢想，放棄穩定的工作，恭弘=叶 恭弘萌創業成立了自己的文化公司。服務了幾百個商業客戶后，2015年他突然感覺工作生涯中所有的積累都應該為了達成他內心中一個夢想——用各種方式構築傳統手工藝從再現到再生的體系，讓傳統手工藝能夠回歸當代生活，成為新的時尚，至此，穀雨——傳統手工藝內容轉化平台宣告問世。

2019年，穀雨的木版年畫產品轉化項目“傳統節中國禮”主旨就是讓傳統節更中國、更時尚。“穀雨打造的內容轉化平台是要做傳統手工藝時尚品牌孵化池。”恭弘=叶 恭弘萌說。

穀雨的平台上金華木版年畫製作者黃菁菁就是一位不甘於讓傳統成為傳說的女性。

金華木版年畫，孕育於漢唐，形成於宋元，鼎盛於明清。浙江在五代吳越時期就是木版畫比較發達的地區，至宋代，金華已經是全國木版年畫的中心之一。

黃菁菁出身木版年畫世家，長大后並沒有從事年畫製作，而成為一名商人，在杭州開了一家文化公司，經營得紅紅火火。雖然她在商界收穫了成功，但內心深處無數次回憶起兒時父輩們製作木版年畫的場景、父親抱着她給她講《五子登科》年畫故事的場景……她對記憶中的年畫魂牽夢繞。

那段日子里，似乎總有一個聲音，在向她不停地召喚。她決定：回家，做木版年畫。

回鄉之時正是金華木版年畫最蕭條的時期，曾經有專家對金華木版年畫的萎縮倍感痛心，黃菁菁的回歸讓金華木板年畫再現生機。

說來容易，做起來才知道苦辣辛酸。首先需搜集老版與老畫，“尋回金華年畫的根”。剛開始的那幾年，黃菁菁一直奔波在路上，從南疆到北國。後來甚至還走出了國門，無論是老版還是老畫，黃菁菁的用語都是“請回來”。 就這樣，黃菁菁一點一滴地打造起金華木版年畫博物館和年畫製作體驗館。如今，她的年畫博物館中已收藏了60餘套老版、2000多幅老年畫，其中六成都是孤版。而她的年畫製作體驗基地成了中國第六個年畫製作基地，也是浙江唯一的年畫基地。

傳承人邰立平：讓年畫“火”起來

邰立平作品《方弼》

年關將至，鳳翔木版年畫代表性傳承人邰立平忙得不亦樂乎。

鳳翔年畫“始於唐宋，盛於明清”，早在600多年前的明初洪武年間，世代耕居於此的邰氏家族就已經開始從事年畫的生產了。邰立平是鳳翔木版年畫第20代傳人。他創辦了鳳怡年畫社，致力於對流散民間的古樣進行挖掘、整理、研究和複製，使這一古老民間傳統藝術得以傳承。

邰立平這一代傳承人經歷了年畫從興到衰整個過程。“隨着時代的轉變和人們生活方式的變化，之前人們張貼年畫的習俗正在慢慢地改變。雖然春節時張貼年畫的習俗還未消失，但也從張貼傳統手工印製的年畫轉變為張貼機器印刷品，這就對傳統的非遺手工年畫形成了很大衝擊。傳統的木版年畫就是反映人民生活的一部百科全書。近年來，隨着國家對傳統文化的重視，社會上對這項古老的傳承技藝越來越推崇和認可，出現了很多國潮風格的文創作品，這都是傳統非遺技藝的文化土壤。”邰立平說。

邰立平認為，當下是鳳翔木版年畫發展的最佳時機。“把木版年畫繼承下去，讓民間美術發揚光大”這是邰立平最大的心愿。為了能夠儘早實現自己的心愿，他分步驟推動自己的計劃。

首先需要找回失散的木刻版。從1978年改革開放到上世紀90年代的年畫，邰立平共復刻了400多套版，大概2000塊木版，把散落民間的老畫樣基本全部恢復。他還分別在1994年出版了手工裝訂的《鳳翔木版年畫選》第一卷、1997年出版了第二卷。目前第三卷的出版工作也在緊張進行中。

其次，在創作上，鳳翔年畫風格緊貼時代脈搏。1999年巴黎中國文化周，邰立平創作了活動吉祥物獅子滾繡球版畫，2008年奧運會時創作了福娃主題作品。鳳翔年畫的名氣越來越大。邰立平先後應邀在澳大利亞、德國、法國等多個國家以及國內各大美院和美術館參展，其作品也陸續被中國國家博物館和國內外200多家藝術學院與機構收藏。

再次，從經營的角度，邰立平也不斷進行着適應市場的改變。傳統年畫的尺寸和包裝都不適應現代都市人的需求，他們專門推出了適合張貼在城市單扇門上的小門神年畫，對年畫的包裝進行變革，更能使現代人喜歡和接受。

這些年邰立平一直在探索如何讓年畫走進千家萬戶，使老百姓能真正用起來。他參与非遺進校園活動；他和國內知名設計師合作，推出了雕刻時光日曆；和中國手藝網和雅昌合作，推出了鳳翔木版年畫年曆；和騰訊、京東合作，跨界進入手游領域，讓年輕人在玩遊戲時也能體驗國潮風。（鄭芋）

本站聲明:網站內容來http://www.societynews.cn/html/wh/fq/,如有侵權,請聯繫我們,我們將及時處理

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

上新台中搬家公司提供您一套專業有效率且人性化的辦公室搬遷、公司行號搬家及工廠遷廠的搬家服務

※台中搬家公司費用怎麼算?

擁有20年純熟搬遷經驗，提供免費估價且流程透明更是5星評價的搬家公司

清晨過橋來。 　　張崢嶸攝

古村新課堂。 　　張崢嶸攝

　　一條小溪，從高處流下，縱穿小村南北，飛鳳山、馬鞍山、鳥崗山、文筆峰四圍環護，溪水不舍晝夜，兩岸參差人家。

※台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

台中搬家公司推薦超過30年經驗,首選台中大展搬家

　　這就是福建省寧德市屏南縣甘棠鄉漈下村。作為我國第四批歷史文化名村，漈下村於明正統二年（1437年）開基，至今已有500多年的歷史，村落古建築承明清風格，既有徽派雕梁畫棟的細節，又有江南水鄉臨水而居的情調。

　　近幾年來，屏南縣推進村落文創計劃，致力於“用文化喚醒鄉土，以創意激活鄉村”，漈下村改造老宅10多棟，創辦农民畫室、民宿、餐館10多家，年接待遊客10萬人次以上。

　　村裡的氛圍漸漸變了，很多人支起了畫板，到處都能看到正在拿着油畫筆寫生的农民，外出打工的人回來了，村裡的遊客也多了起來，很多城裡人帶着孩子，在村裡一住就是幾個月……鄉土煥發了新的活力。

　　本報記者 劉曉宇文 

本站聲明:網站內容來http://www.societynews.cn/html/wh/fq/,如有侵權,請聯繫我們,我們將及時處理

※台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

台中搬家公司推薦超過30年經驗,首選台中大展搬家

※台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

還在煩惱搬家費用要多少哪？台中大展搬家線上試算搬家費用，從此不再擔心「物品怎麼計費」、「多少車才能裝完」

18日，江蘇省宿遷市沭陽縣，工人們正在抓緊時間懸挂燈籠、調試彩燈。

※推薦台中搬家公司優質服務,可到府估價

台中搬鋼琴,台中金庫搬運,中部廢棄物處理,南投縣搬家公司,好幫手搬家,西屯區搬家

為營造春節歡樂祥和的喜慶氣氛，沭陽縣在城區的公園、廣場等處掛上大紅燈籠和不同樣式的彩燈，成為一道亮麗的風景線。

仲崇亮攝（人民視覺）

本站聲明:網站內容來http://www.societynews.cn/html/wh/fq/,如有侵權,請聯繫我們,我們將及時處理

※推薦台中搬家公司優質服務,可到府估價

台中搬鋼琴,台中金庫搬運,中部廢棄物處理,南投縣搬家公司,好幫手搬家,西屯區搬家