[設計原則] 爲模塊設計初始化和終止化函數

    在軟件行業，模塊化編程早已深刻人心，經過模塊的劃分能有效地減少軟件系統的複雜度，模塊化其實就是將系統「分而治之」的方法。在嵌入式系統中，每個模塊存在初始化函數相對比較的廣泛，可是並非每個模塊都存在一個終止化函數，相反，有可能整個系統根本就沒有終止化函數。之因此出現這種現象，這與嵌入式系統的特色有關。與桌面系統上的軟件不一樣的是，因爲整個嵌入式設備就只有一個應用軟件在運行，所以，對軟件的關閉或重啓大都是經過開、關設備電源或按下重啓按鈕這種「粗暴的」方式來完成的。長此以往你們都就習慣了，進而將設計模塊的終止化函數看成了多餘。     從完整性的角度來看，一個模塊若是存在初始化的過程，就理應提供終止化函數以實現模塊的終止，固然設計終止化函數不該當只是爲了感受更好，而應當還有其它的目的和內涵，那是什麼呢？爲每個模塊設計終止化函數的目的是爲了提供一種「優雅地」關機或重啓系統的手段，而其進一步的內涵是，經過這種方式將提供一個檢測系統資源泄漏的機會。     如今，讓咱們之內存資源爲例來分析採用優雅關機的好處。在嵌入式系統中，因爲不考慮各模塊終止化函數的設計，形成從堆中分配出來的具備全局生命週期的內存在系統系統關閉時不存在釋放操做。如此一來，在系統的關閉過程當中不容易發現內存泄露問題，由於分不清哪些內存是系統運行期間必須永久持有的（即非內存泄漏），哪些又是動態分配但沒有釋放的（即內存泄漏）。假設使用內存的每一個模塊都提供了終止化函數，且系統提供一種方式（好比經過命令行）以觸發優雅關機流程，其結果就是致使每個模塊的終止化函數被有序地調用。顯然，那些具備全局生命週期的內存在每個模塊的終止化函數中都應進行釋放操做，最終在優雅關機的過程當中也會被釋放。進一步，在內存管理模塊的終止化函數中（注意：前面講的是使用內存的模塊，而如今講的是管理內存的模塊），能夠設計成檢測當前是否仍有內存被分配出去了，若是有，則頗有可能存在內存泄漏。若是內存管理模塊被設計成能記錄全部已分配出去內存的詳細信息的話（指內存的分配是在哪個文件的哪一行），在發現仍有內存沒有釋放的話，將這些相關信息經過某種方式輸出將有助於發現內存泄漏點。固然，這裏有一個很重要的前提假設，那就是在優雅關機的過程當中使用內存的模塊的終止化函數必須在內存管理模塊的終止化函數以前被調用，這一點能夠經過必定的模塊管理輕鬆作到。     內存資源能夠經過優雅關機的方式發現泄漏，其它的資源一樣能夠採用這一方法發現泄漏。好比，在定時器管理模塊的終止化函數中能夠檢查是否全部的定時器都已回收了，等等。有了優雅關機的方式之後，並不妨礙咱們採用「粗暴的」方式進行系統的關閉或重啓，但它的存在卻提供了一種須要時能被使用以輔助發現潛在的資源泄漏問題。     設計模塊的終止化函數須要一點工做量，但這點工做量是能夠承受的，並且也應當承擔它。與潛在的資源泄漏相比，花上這些時間是值得的。另外，設計得好的系統，不僅是簡單地提供初始化和終止化函數，還應當站在整個系統的角度設計必定的機制去管理系統中模塊的初始化和終止化。