補丁編譯原理

㈠ 了解什麼叫做jit compiling，與傳統的編譯技術有何不同

java 應用程序的性能經常成為開發社區中的討論熱點。因為該語言的設計初衷是使用解釋的方式支持應用程序的可移植性目標，早期
Java 運行時所提供的性能級別遠低於 C 和
C++
之類的編譯語言。盡管這些語言可以提供更高的性能，但是生成的代碼只能在有限的幾種系統上執行。在過去的十年中，Java
運行時供應商開發了一些復雜的動態編譯器，通常稱作即時（Just-in-time，JIT）編譯器。程序運行時，JIT
編譯器選擇將最頻繁執行的方法編譯成本地代碼。運行時才進行本地代碼編譯而不是在程序運行前進行編譯（用 C 或
C++ 編寫的程序正好屬於後一情形），保證了可移植性的需求。有些 JIT 編譯器甚至不使用解釋程序就能編譯所有的代碼，但是這些編譯器仍然通過在程序執行時進行一些操作來保持 Java 應用程序的可移植性。
由於動態編譯技術的多項改進，在很多應用程序中，現代的 JIT 編譯器可以產生與 C 或 C++
靜態編譯相當的應用程序性能。但是，仍然有很多軟體開發人員認為 —— 基於經驗或者傳聞 ——
動態編譯可能嚴重干擾程序操作，因為編譯器必須與應用程序共享 CPU。一些開發人員強烈呼籲對 Java
代碼進行靜態編譯，並且堅信那樣可以解決性能問題。對於某些應用程序和執行環境而言，這種觀點是正確的，靜態編譯可以極大地提高 Java
性能，或者說它是惟一的實用選擇。但是，靜態地編譯 Java 應用程序在獲得高性能的同時也帶來了很多復雜性。一般的
Java 開發人員可能並沒有充分地感受到 JIT 動態編譯器的優點。

本文考察了 Java 語言靜態編譯和動態編譯所涉及的一些問題，重點介紹了實時 (RT) 系統。簡要描述了 Java
語言解釋程序的操作原理並說明了現代 JIT 編譯器執行本地代碼編譯的優缺點。介紹了 IBM 在 WebSphere Real Time 中發布的
AOT 編譯技術和它的一些優缺點。然後比較了這兩種編譯策略並指出了幾種比較適合使用 AOT
編譯的應用程序領域和執行環境。要點在於這兩種編譯技術並不互斥：即使在使用這兩種技術最為有效的各種應用程序中，它們也分別存在一些影響應用程序的優缺
點。

執行 Java 程序

Java 程序最初是通過 Java SDK 的 javac程序編譯成本地的與平台無關的格式（類文件）。可將此格式看作 Java
平台，因為它定義了執行 Java 程序所需的所有信息。Java 程序執行引擎，也稱作 Java 運行時環境（JRE），包含了為特定的本地平台實現
Java 平台的虛擬機。例如，基於 linux 的 Intel x86 平台、Sun Solaris 平台和 AIX 操作系統上運行的 IBM
System p 平台，每個平台都擁有一個 JRE。這些 JRE 實現實現了所有的本地支持，從而可以正確執行為
Java 平台編寫的程序。

事實上，操作數堆棧的大小有實際限制，但是編程人員極少編寫超出該限制的方法。JVM 提供了安全性檢查，對那些創建出此類方法的編程人員進行通知。

Java 平台程序表示的一個重要部分是位元組碼序列，它描述了 Java
類中每個方法所執行的操作。位元組碼使用一個理論上無限大的操作數堆棧來描述計算。這個基於堆棧的程序表示提供了平台無關性，因為它不依賴任何特定本地平台
的 CPU 中可用寄存器的數目。可在操作數堆棧上執行的操作的定義都獨立於所有本地處理器的指令集。Java
虛擬機（JVM）規范定義了這些位元組碼的執行（參見 參考資料）。執行 Java 程序時，用於任何特定本地平台的任何 JRE 都必須遵守 JVM
規范中列出的規則。

因為基於堆棧的本地平台很少（Intel X87 浮點數協處理器是一個明顯的例外），所以大多數本地平台不能直接執行 Java 位元組碼。為了解決這個問題，早期的 JRE 通過解釋位元組碼來執行 Java 程序。即 JVM 在一個循環中重復操作：

◆獲取待執行的下一個位元組碼；

◆解碼；

◆從操作數堆棧獲取所需的操作數；

◆按照 JVM 規范執行操作；

◆將結果寫回堆棧。

這種方法的優點是其簡單性：JRE 開發人員只需編寫代碼來處理每種位元組碼即可。並且因為用於描述操作的位元組碼少於 255 個，所以實現的成本比較低。當然，缺點是性能：這是一個早期造成很多人對 Java 平台不滿的問題，盡管擁有很多其他優點。

解決與 C 或 C++ 之類的語言之間的性能差距意味著，使用不會犧牲可移植性的方式開發用於 Java 平台的本地代碼編譯。

編譯 Java 代碼

盡管傳聞中 Java 編程的 「一次編寫，隨處運行」
的口號可能並非在所有情況下都嚴格成立，但是對於大量的應用程序來說情況確實如此。另一方面，本地編譯本質上是特定於平台的。那麼 Java
平台如何在不犧牲平台無關性的情況下實現本地編譯的性能？答案就是使用 JIT 編譯器進行動態編譯，這種方法已經使用了十年（參見圖 1）：

圖 1. JIT 編譯器

使用 JIT 編譯器時，Java
程序按每次編譯一個方法的形式進行編譯，因為它們在本地處理器指令中執行以獲得更高的性能。此過程將生成方法的一個內部表示，該表示與位元組碼不同但是其級
別要高於目標處理器的本地指令。（IBM JIT
編譯器使用一個表達式樹序列表示方法的操作。）編譯器執行一系列優化以提高質量和效率，最後執行一個代碼生成步驟將優化後的內部表示轉換成目標處理器的本
地指令。生成的代碼依賴運行時環境來執行一些活動，比如確保類型轉換的合法性或者對不能在代碼中直接執行的某些類型的對象進行分配。JIT
編譯器操作的編譯線程與應用程序線程是分開的，因此應用程序不需要等待編譯的執行。

圖 1 中還描述了用於觀察執行程序行為的分析框架，通過周期性地對線程取樣找出頻繁執行的方法。該框架還為專門進行分析的方法提供了工具，用來存儲程序的此次執行中可能不會改變的動態值。

因為這個 JIT 編譯過程在程序執行時發生，所以能夠保持平台無關性：發布的仍然是中立的 Java 平台代碼。C 和 C++ 之類的語言缺乏這種優點，因為它們在程序執行前進行本地編譯；發布給（本地平台）執行環境的是本地代碼。

挑戰

盡管通過 JIT 編譯保持了平台無關性，但是付出了一定代價。因為在程序執行時進行編譯，所以編譯代碼的時間將計入程序的執行時間。任何編寫過大型 C 或 C++ 程序的人都知道，編譯過程往往較慢。

為了克服這個缺點，現代的 JIT
編譯器使用了下面兩種方法的任意一種（某些情況下同時使用了這兩種方法）。第一種方法是：編譯所有的代碼，但是不執行任何耗時多的分析和轉換，因此可以快
速生成代碼。由於生成代碼的速度很快，因此盡管可以明顯觀察到編譯帶來的開銷，但是這很容易就被反復執行本地代碼所帶來的性能改善所掩蓋。第二種方法是：
將編譯資源只分配給少量的頻繁執行的方法（通常稱作熱方法）。低編譯開銷更容易被反復執行熱代碼帶來的性能優勢掩蓋。很多應用程序只執行少量的熱方法，因
此這種方法有效地實現了編譯性能成本的最小化。

動態編譯器的一個主要的復雜性在於權衡了解編譯代碼的預期獲益使方法的執行對整個程序的性能起多大作用。一個極端的例子是，程序執行後，您非常清楚哪些方
法對於這個特定的執行的性能貢獻最大，但是編譯這些方法毫無用處，因為程序已經完成。而在另一個極端，程序執行前無法得知哪些方法重要，但是每種方法的潛
在受益都最大化了。大多數動態編譯器的操作介於這兩個極端之間，方法是權衡了解方法預期獲益的重要程度。

Java 語言需要動態載入類這一事實對 Java
編譯器的設計有著重要的影響。如果待編譯代碼引用的其他類還沒有載入怎麼辦？比如一個方法需要讀取某個尚未載入的類的靜態欄位值。Java
語言要求第一次執行類引用時載入這個類並將其解析到當前的 JVM
中。直到第一次執行時才解析引用，這意味著沒有地址可供從中載入該靜態欄位。編譯器如何處理這種可能性？編譯器生成一些代碼，用於在沒有載入類時載入並解
析類。類一旦被解析，就會以一種線程安全的方式修改原始代碼位置以便直接訪問靜態欄位的地址，因為此時已獲知該地址。

IBM JIT
編譯器中進行了大量的努力以便使用安全而有效率的代碼補丁技術，因此在解析類之後，執行的本地代碼只載入欄位的值，就像編譯時已經解析了欄位一樣。另外一
種方法是生成一些代碼，用於在查明欄位的位置以前一直檢查是否已經解析欄位，然後載入該值。對於那些由未解析變成已解析並被頻繁訪問的欄位來說，這種簡單
的過程可能帶來嚴重的性能問題。

動態編譯的優點

動態地編譯 Java 程序有一些重要的優點，甚至能夠比靜態編譯語言更好地生成代碼，現代的 JIT 編譯器常常向生成的代碼中插入掛鉤以收集有關程序行為的信息，以便如果要選擇方法進行重編譯，就可以更好地優化動態行為。

關於此方法的一個很好的例子是收集一個特定 array操作的長度。如果發現每次執行操作時該長度基本不變，則可以為最頻繁使用的

array長度生成專門的代碼，或者可以調用調整為該長度的代碼序列。由於內存系統和指令集設計的特性，用於復制內存的最佳通用常式的執行速度通
常比用於復制特定長度的代碼慢。例如，復制 8
個位元組的對齊的數據可能需要一到兩條指令直接復制，相比之下，使用可以處理任意位元組數和任意對齊方式的一般復制循環可能需要 10 條指令來復制同樣的 8

個位元組。但是，即使此類專門的代碼是為某個特定的長度生成的，生成的代碼也必須正確地執行其他長度的復制。生成代碼只是為了使常見長度的操作執行得更快，
因此平均下來，性能得到了改進。此類優化對大多數靜態編譯語言通常不實用，因為所有可能的執行中長度恆定的操作比一個特定程序執行中長度恆定的操作要少得
多。

此類優化的另一個重要的例子是基於類層次結構的優化。例如，一個虛方法調用需要查看接收方對象的類調用，以便找出哪個實際目標實現了接收方對象的虛方法。
研究表明：大多數虛調用只有一個目標對應於所有的接收方對象，而 JIT
編譯器可以為直接調用生成比虛調用更有效率的代碼。通過分析代碼編譯後類層次結構的狀態，JIT
編譯器可以為虛調用找到一個目標方法，並且生成直接調用目標方法的代碼而不是執行較慢的虛調用。當然，如果類層次結構發生變化，並且出現另外的目標方法，
則 JIT
編譯器可以更正最初生成的代碼以便執行虛調用。在實踐中，很少需要作出這些更正。另外，由於可能需要作出此類更正，因此靜態地執行這種優化非常麻煩。

因為動態編譯器通常只是集中編譯少量的熱方法，所以可以執行更主動的分析來生成更好的代碼，使編譯的回報更高。事實上，大部分現代的
JIT
編譯器也支持重編譯被認為是熱方法的方法。可以使用靜態編譯器（不太強調編譯時間）中常見的非常主動的優化來分析和轉換這些頻繁執行的方法，以便生成更好
的代碼並獲得更高的性能。

這些改進及其他一些類似的改進所產生的綜合效果是：對於大量的 Java 應用程序來說，動態編譯已經彌補了與 C 和 C++ 之類語言的靜態本地編譯性能之間的差距，在某些情況下，甚至超過了後者的性能。

缺點

但是，動態編譯確實具有一些缺點，這些缺點使它在某些情況下算不上一個理想的解決方案。例如，因為識別頻繁執行的方法以及編譯這些方法需要時間，所以應用
程序通常要經歷一個准備過程，在這個過程中性能無法達到其最高值。在這個准備過程中出現性能問題有幾個原因。首先，大量的初始編譯可能直接影響應用程序的
啟動時間。不僅這些編譯延遲了應用程序達到穩定狀態的時間（想像 Web
伺服器經
歷一個初始階段後才能夠執行實際有用的工作），而且在准備階段中頻繁執行的方法可能對應用程序的穩定狀態的性能所起的作用也不大。如果 JIT
編譯會延遲啟動又不能顯著改善應用程序的長期性能，則執行這種編譯就非常浪費。雖然所有的現代 JVM
都執行調優來減輕啟動延遲，但是並非在所有情況下都能夠完全解決這個問題。

其次，有些應用程序完全不能忍受動態編譯帶來的延遲。如 GUI 介面之類互動式應用程序就是這樣的例子。在這種情況下，編譯活動可能對用戶使用造成不利影響，同時又不能顯著地改善應用程序的性能。

最後，用於實時環境並具有嚴格的任務時限的應用程序可能無法忍受編譯的不確定性性能影響或動態編譯器本身的內存開銷。

因此，雖然 JIT 編譯技術已經能夠提供與靜態語言性能相當（甚至更好）的性能水平，但是動態編譯並不適合於某些應用程序。在這些情況下，Java 代碼的提前（Ahead-of-time，AOT）編譯可能是合適的解決方案。

AOT Java 編譯

大致說來，Java 語言本地編譯應該是為傳統語言（如 C++ 或
Fortran）而開發的編譯技術的一個簡單應用。不幸的是，Java 語言本身的動態特性帶來了額外的復雜性，影響了 Java
程序靜態編譯代碼的質量。但是基本思想仍然是相同的：在程序執行前生成 Java 方法的本地代碼，以便在程序運行時直接使用本地代碼。目的在於避免
JIT 編譯器的運行時性能消耗或內存消耗，或者避免解釋程序的早期性能開銷。

挑戰

動態類載入是動態 JIT 編譯器面臨的一個挑戰，也是 AOT
編譯的一個更重要的問題。只有在執行代碼引用類的時候才載入該類。因為是在程序執行前進行 AOT
編譯的，所以編譯器無法預測載入了哪些類。就是說編譯器無法獲知任何靜態欄位的地址、任何對象的任何實例欄位的偏移量或任何調用的實際目標，甚至對直接調
用（非虛調用）也是如此。在執行代碼時，如果證明對任何這類信息的預測是錯誤的，這意味著代碼是錯誤的並且還犧牲了 Java 的一致性。

因為代碼可以在任何環境中執行，所以類文件可能與代碼編譯時不同。例如，一個 JVM
實例可能從磁碟的某個特定位置載入類，而後面一個實例可能從不同的位置甚至網路載入該類。設想一個正在進行 bug
修復的開發環境：類文件的內容可能隨不同的應用程序的執行而變化。此外，Java 代碼可能在程序執行前根本不存在：比如 Java
反射服務通常在運行時生成新類來支持程序的行為。

缺少關於靜態、欄位、類和方法的信息意味著嚴重限制了 Java 編譯器中優化框架的大部分功能。內聯可能是靜態或動態編譯器應用的最重要的優化，但是由於編譯器無法獲知調用的目標方法，因此無法再使用這種優化。

內聯

內聯是一種用於在運行時生成代碼避免程序開始和結束時開銷的技術，方法是將函數的調用代碼插入到調用方的函數中。但是內聯最大的益處可能是優化方可見的代碼的范圍擴大了，從而能夠生成更高質量的代碼。下面是一個內聯前的代碼示例：

int foo() { int x=2, y=3; return bar(x,y); }final int bar(int a, int b) { return a+b; }

如果編譯器可以證明這個 bar就是 foo()中調用的那個方法，則 bar中的代碼可以取代 foo()中對
bar()的調用。這時，bar()方法是 final類型，因此肯定是 foo()中調用的那個方法。甚至在一些虛調用例子中，動態 JIT
編譯器通常能夠推測性地內聯目標方法的代碼，並且在絕大多數情況下能夠正確使用。編譯器將生成以下代碼：

int foo() { int x=2, y=3; return x+y; }

在這個例子中，簡化前名為值傳播的優化可以生成直接返回
5的代碼。如果不使用內聯，則不能執行這種優化，產生的性能就會低很多。如果沒有解析
bar()方法（例如靜態編譯），則不能執行這種優化，而代碼必須執行虛調用。運行時，實際調用的可能是另外一個執行兩個數字相乘而不是相加的
bar方法。所以不能在 Java 程序的靜態編譯期間直接使用內聯。

AOT
代碼因此必須在沒有解析每個靜態、欄位、類和方法引用的情況下生成。執行時，每個這些引用必須利用當前運行時環境的正確值進行更新。這個過程可能直接影響
第一次執行的性能，因為在第一次執行時將解析所有引用。當然，後續執行將從修補代碼中獲益，從而可以更直接地引用實例、靜態欄位或方法目標。

另外，為 Java 方法生成的本地代碼通常需要使用僅在單個 JVM 實例中使用的值。例如，代碼必須調用 JVM
運行時中的某些運行時常式來執行特定操作，如查找未解析的方法或分配內存。這些運行時常式的地址可能在每次將 JVM 載入到內存時變化。因此 AOT
編譯代碼需要綁定到 JVM 的當前執行環境中，然後才能執行。其他的例子有字元串的地址和常量池入口的內部位置。

在 WebSphere Real Time 中，AOT 本地代碼編譯通過 jxeinajar工具（參見圖 2）來執行。該工具對 JAR 文件中所有類的所有方法應用本地代碼編譯，也可以選擇性地對需要的方法應用本地代碼編譯。結果被存儲到名為 Java eXEcutable (JXE) 的內部格式中，但是也可輕松地存儲到任意的持久性容器中。

您可能認為對所有的代碼進行靜態編譯是最好的方法，因為可以在運行時執行最大數量的本地代碼。但是此處可以作出一些權衡。編譯的方法越多，代碼佔用的內存
就越多。編譯後的本地代碼大概比位元組碼大 10 倍：本地代碼本身的密度比位元組碼小，而且必須包含代碼的附加元數據，以便將代碼綁定到 JVM
中，並且在出現異常或請求堆棧跟蹤時正確執行代碼。構成普通 Java 應用程序的 JAR
文件通常包含許多很少執行的方法。編譯這些方法會消耗內存卻沒有什麼預期收益。相關的內存消耗包括以下過程：將代碼存儲到磁碟上、從磁碟取出代碼並裝入
JVM，以及將代碼綁定到 JVM。除非多次執行代碼，否則這些代價不能由本地代碼相對解釋的性能優勢來彌補。

圖 2. jxeinajar

跟大小問題相違背的一個事實是：在編譯過的方法和解釋過的方法之間進行的調用（即編譯過的方法調用解釋過的方法，或者相反）可能比這兩類方法各自內部之間
進行的調用所需的開銷大。動態編譯器通過最終編譯所有由 JIT
編譯代碼頻繁調用的那些解釋過的方法來減少這項開銷，但是如果不使用動態編譯器，則這項開銷就不可避免。因此如果是選擇性地編譯方法，則必須謹慎操作以使
從已編譯方法到未編譯方法的轉換最小化。為了在所有可能的執行中都避免這個問題而選擇正確的方法會非常困難。
優點
雖然 AOT 編譯代碼具有上述的缺點和挑戰，但是提前編譯 Java 程序可以提高性能，尤其是在不能將動態編譯器作為有效解決方案的環境中。

可以通過謹慎地使用 AOT 編譯代碼加快應用程序啟動，因為雖然這種代碼通常比 JIT
編譯代碼慢，但是卻比解釋代碼快很多倍。此外，因為載入和綁定 AOT
編譯代碼的時間通常比檢測和動態編譯一個重要方法的時間少，所以能夠在程序執行的早期達到那樣的性能。類似地，互動式應用程序可以很快地從本地代碼中獲
益，無需使用引起較差響應能力的動態編譯。

RT 應用程序也能從 AOT 編譯代碼中獲得重要的收益：更具確定性的性能超過了解釋的性能。WebSphere Real Time
使用的動態 JIT 編譯器針對在 RT 系統中的使用進行了專門的調整。使編譯線程以低於 RT
任務的優先順序操作，並且作出了調整以避免生成帶有嚴重的不確定性性能影響的代碼。但是，在一些 RT 環境中，出現 JIT
編譯器是不可接受的。此類環境通常需要最嚴格的時限管理控制。在這些例子中，AOT
編譯代碼可以提供比解釋過的代碼更好的原始性能，又不會影響現有的確定性。消除 JIT
編譯線程甚至消除了啟動更高優先順序 RT 任務時發生的線程搶占所帶來的性能影響。

優缺點統計

動態（JIT）編譯器支持平台中立性，並通過利用應用程序執行的動態行為和關於載入的類及其層次結構的信息來生成高質量的代碼。但是
JIT
編譯器具有一個有限的編譯時預算，而且會影響程序的運行時性能。另一方面，靜態（AOT）編譯器則犧牲了平台無關性和代碼質量，因為它們不能利用程序的動
態行為，也不具有關於載入的類或類層次結構的信息。AOT 編譯擁有有效無限制的編譯時預算，因為 AOT
編譯時間不會影響運行時性能，但是在實踐中開發人員不會長期等待靜態編譯步驟的完成。

表 1 總結了本文討論的 Java 語言動態和靜態編譯器的一些特性：

表 1. 比較編譯技術

兩種技術都需要謹慎選擇編譯的方法以實現最高的性能。對動態編譯器而言，編譯器自身作出決策，而對於靜態編譯器，由開發人員作出選擇。讓
JIT 編譯器選擇編譯的方法是不是優點很難說，取決於編譯器在給定情形中推斷能力的好壞。在大多數情況下，我們認為這是一種優點。

因為它們可以最好地優化運行中的程序，所以 JIT 編譯器在提供穩定狀態性能方面更勝一籌，而這一點在大量的生產 Java
系統中最為重要。靜態編譯可以產生最佳的互動式性能，因為沒有運行時編譯行為來影響用戶預期的響應時間。通過調整動態編譯器可以在某種程度上解決啟動和確
定性性能問題，但是靜態編譯在需要時可提供最快的啟動速度和最高級別的確定性。表 2 在四種不同的執行環境中對這兩種編譯技術進行了比較：

表 2. 使用這些技術的最佳環境

圖 3 展示了啟動性能和穩定狀態性能的總體趨勢：

圖 3. AOT 和 JIT 的性能對比

使用 JIT 編譯器的初始階段性能很低，因為要首先解釋方法。隨著編譯方法的增多及 JIT
執行編譯所需時間的縮短，性能曲線逐漸升高最後達到性能峰值。另一方面，AOT 編譯代碼啟動時的性能比解釋的性能高很多，但是無法達到 JIT
編譯器所能達到的最高性能。將靜態代碼綁定到 JVM 實例中會產生一些開銷，因此開始時的性能比穩定狀態的性能值低，但是能夠比使用 JIT
編譯器更快地達到穩定狀態的性能水平。

沒有一種本地代碼編譯技術能夠適合所有的 Java
執行環境。某種技術所擅長的通常正是其他技術的弱項。出於這個原因，需要同時使用這兩種編譯技術以滿足 Java
應用程序開發人員的要求。事實上，可以結合使用靜態和動態編譯以便提供最大可能的性能提升 —— 但是必須具備平台無關性，它是 Java
語言的主要賣點，因此不成問題。

結束語

本文探討了 Java 語言本地代碼編譯的問題，主要介紹了 JIT 編譯器形式的動態編譯和靜態 AOT 編譯，比較了二者的優缺點。

雖然動態編譯器在過去的十年裡實現了極大的成熟，使大量的各種 Java 應用程序可以趕上或超過靜態編譯語言（如 C++ 或
Fortran）所能夠達到的性能。但是動態編譯在某些類型的應用程序和執行環境中仍然不太合適。雖然 AOT
編譯號稱動態編譯缺點的萬能解決方案，但是由於 Java 語言本身的動態特性，它也面臨著提供本地編譯全部潛能的挑戰。

這兩種技術都不能解決 Java 執行環境中本地代碼編譯的所有需求，但是反過來又可以在最有效的地方作為工具使用。這兩種技術可以相互補充。能夠恰當地使用這兩種編譯模型的運行時系統可以使很大范圍內的應用程序開發環境中的開發人員和用戶受益。

㈡ 適合初學者學習的嵌入式教程

原文鏈接：網頁鏈接

嵌入式Linux學習路線圖

我是1999年上的大學，物理專業。在大一時，我們班裡普遍彌漫著對未來的不安，不知道學習了物理後出去能做什麼。你當下的經歷、當下的學習，在未來的一天肯定會影響到你。畢業後我們也各自找到了自己的職業：出國深造轉行做金融、留校任教做科研、設計晶元、寫程序、創辦公司等等，這一切都離不開在校時學到的基礎技能（數學、IT、電子電路）、受過煅煉的自學能力。

所以，各位正在迷茫的在校生，各位正在嘗試轉行的程序員，未來一定有你的位置，是好是壞取決於你當下的努力與積累。

我不能預言幾年後什麼行業會熱門，也不能保證你照著本文學習可以發財。我只是一個有十幾年經驗的程序員，給對編程有興趣的你，提供一些建議。

1.程序員的三大方向

程序員的方向，一般可以分為3類：專業領域、業務領域、操作系統領域。你了解它們後，按興趣選擇吧。

對於專業領域，我提供不了建議。

業務，也就是應用程序，它跟操作系統並不是截然分開的：

①開發實體產品時，應用程序寫得好的人，有時候需要操作系統的知識，比如調度優先順序的設置、知道某些函數可能會令進程休眠。

②寫應用程序的人進階為系統工程師時，他需要從上到下都了解，這時候就需要有操作系統領域的知識了，否則，你怎麼設計整個系統的方案呢？

③做應用程序的人，需要了解行業的需求，理解業務的邏輯。所以，當領導的人，多是做應用的。一旦鑽入了某個行業，很難換行業。

④而操作系統領域，做好了這是通殺各行業：他只負責底層系統，在上面開發什麼業務跟他沒關系。這行很多是技術宅，行業專家。

⑤操作系統和業務之間並沒有一個界線。有操作系統經驗，再去做應用，你會對系統知根知底，碰到問題時都有解決思路。有了業務經驗，你再了解一下操作系統，很快就可以組成一個團隊自立門戶，至少做個CTO沒問題。

1.1 專業領域

它又可以分為下面2類。

1.1.1 學術研究

比如語音、圖像處理、人工智慧，這類工作需要你有比較強的理論知識，我傾向於認為這類人是「科學家」，他們鑽研多年，很多時候是在做學術研究。

在嵌入式領域，需要把他們的成果用某種演算法表達出來，針對某種晶元進行優化，這部分工作也許有專人來做。

1.1.2 工程實現

也有這樣一類人，他們懂得這些專業領域的概念，但是沒有深入鑽研。可以使用各類開源資料實現某個目標，做出產品。比如圖像處理，他懂得用opencv里幾百個復雜函數來實現頭像識別。有時候還可以根據具體晶元來優化這些函數。

「專業領域」不是我的菜，如果你要做這一塊，我想最好的入門方法是在學校學習研究生、博士課程。

1.2 業務領域

換句話說，就是應用程序，這又可以分為下面2類。

1.2.1 界面顯示

做產品當然需要好的界面，但是，不是說它不重要，是沒什麼發展後勁。

現在的熱門詞是Android APP和IOS APP開發。你不要被Android、IOS兩個詞騙了，它們跟以前的VC、VB是同一路貨色，只是、僅僅是一套GUI控制項的實現。

希望沒有冒犯到你，我有理由。

一個程序需要有GUI界面，但是程序的內在邏輯才是核心。Android、IOS的開發工具給我們簡化了GUI的開發，並提供了這些控制項的交互機制，封裝並提供了一些服務(比如網路傳輸)。但是程序內部的業務邏輯、對視頻圖像聲音的處理等等，這才是核心。另外別忘了伺服器那邊的後台程序：怎樣更安全地保存數據、保護客戶的隱私，怎樣處理成千上萬上百萬的並發訪問，等等，這也是核心。

但是，從Android、IOS APP入門入行，這很快！如果你是大四，急於找到一份工作，那麼花上1、2個月去學習Android或IOS，應該容易找到工作，畢竟APP的需求永遠是最大的，現在這兩門技術還算熱門。在2011、2012年左右，Android程序員的起薪挺高，然後開始下滑。Android APP的入門基本只要1個月，所以懂的人也越來越多。2013、2014年，IOS開發的工資明顯比Android高了，於是各類IOS培訓也火曝起來。中華大地向來不缺速成人才，估計再過一陣子IOS工程師也是白菜價了。

會Android、IOS只是基本要求，不信去51job搜搜Android或IOS，職位要求里肯定其他要求。

1.2.2 業務邏輯

舉個簡單例子，做一個打卡軟體，你需要考慮這些東西：

①正常流程是上班下班時都要打卡

②有人忘記了怎麼辦？作為異常記錄在案，推送給管理員

③請假時怎麼處理？

④加班怎麼處理？

對於更復雜的例子，視頻會議系統里，各個模塊怎麼對接，各類協議怎麼兼容，你不深入這個行業，你根本搞不清楚。

應用開發的職位永遠是最多的，入門門檻也低。基本上只要你會C語言，面試時表現比較得體，一般公司都會給你機會。因為：

①你進公司後，還需要重新培訓你：熟悉它們的業務邏輯。

②你要做的，基本也就是一個個模塊，框架都有人給你定好了，你去填代碼就可以了。

說點讓你高興的事：軟體公司里，做領導的基本都是寫應用程序的（當然還有做市場的）。寫應用程序的人，對外可以研究市場接待客戶，對內可以管理程序員完成開發，不讓他做領導讓誰做？

如果你的志向是寫應用程序，那麼我建議你先練好基本功：數據結構、演算法是必備，然後憑興趣選擇資料庫、網路編程等等進行深入鑽研。

最後，選擇你看好的、感興趣的行業深耕個10年吧。做應用開發的人選擇了某個行業，後面是很難換行業的，選行很重要！

1.3 操作系統領域

UCOS太簡單，VxWorks太貴太專業，Windows不玩嵌入式了，IOS不開源，所以對於操作系統領域我們也只能玩Linux了。

在嵌入式領域Linux一家獨大！

Android呢？Android跟QT一樣，都是一套GUI系統。只是Google的實力太強了，現在Android無處不在，所以很多時候Linux+Android成了標配。注意，在這里我們關心的是Android的整個系統、裡面的機制，而不是學習幾個API然後開發界面程序。操作系統領域所包含的內容，簡單地說，就是製作出一台裝好系統的專用「電腦」，可以分為：

①為產品規劃硬體：

按需求、性能、成本選擇主晶元，搭配周邊外設，交由硬體開發人員設計。

②給單板製作、安裝操作系統、編寫驅動

③定製維護、升級等系統方案

④還可能要配置、安裝Android等GUI系統：

⑤為應用開發人員配置開發環境

⑥從系統角度解決疑難問題

這個領域，通常被稱為「底層系統」或是「驅動開發」。

先解決2個常見誤區：

①這份工作是寫驅動程序嗎？

看看上面羅列的6點，應該說，它包含驅動開發，但遠遠不只有驅動開發。

②我們還需要寫驅動嗎？不是有原廠嗎？或者只需要改改就可以？

經常有人說，晶元原廠都做好驅動了，拿過來改改就可以了。如果，你的硬體跟原廠的公板完全一樣，原廠源碼毫無BUG，不想優化性能、削減成本，不想做一些有特色的產品，那這話是正確的。

但是在這個不創新就是找死的年代，可能嗎？！原因有二：

①即使只是修改代碼，能修改的前提是能理解；能理解的最好煅煉方法是從零寫出若干驅動程序。

②很多時候，需要你深度定製系統。

以前做聯發科手機只需要改改界面就可以出貨了，現在山寨廠一批批倒下。大家都使用原廠的方案而不加修改時，最後只能拼成本。

舉個例子，深圳有2家做交通攝像頭、監控攝像頭的廠家，他們曾經找我做過4個項目：

①改進廠家給的SD卡驅動性能，使用DMA。

②換了Flash型號後，系統經常出問題，需要修改驅動BUG。

③觸摸屏點擊不準，找原因，後來發現是旁路電容導致的。

④裁減成本，把4片DDR換為2片DDR，需要改bootloader對DDR的初始化。

這些項目都很急，搞不定就無法出貨，這時候找原廠？除非你是中興華為等大客戶，否則誰理你？

我在中興公司上班時，寫驅動的時間其實是很少的，大部分時間是調試：系統調優，上幫APP工程師、下幫硬體工程師查找問題。我們從廠家、網上得到的源碼，很多都是標準的，當然可以直接用。但是在你的產品上也許優化一下更好。比如我們可以把攝像頭驅動和DMA驅動揉合起來，讓攝像頭的數據直接通過DMA發到DSP去。我們可以在軟體和硬體之間起橋梁作用，對於實體產品，有可能是軟體出問題也可能是硬體出問題，一般是底層系統工程師比較容易找出問題。

當硬體、軟體應用出現問題，他們解決不了時，從底層軟體角度給他們出主意，給他們提供工具。再比如方案選擇：晶元性能能否達標、可用的BSP是否完善等等，這只能由負責整個方案的人來考慮，他必須懂底層。

在操作系統領域，對知識的要求很多：

①懂硬體知識才能看懂電路圖

②英文好會看晶元手冊

③有編寫、移植驅動程序的能力

④對操作系統本身有一定的理解，才能解決各類疑難問題

⑤理解Android內部機制

⑥懂匯編、C語言、C++、JAVA

它絕對是一個大坑，沒有興趣、沒有毅力的人慎選。

①這行的入門，絕對需要半年以上，即使全天學習也要半年。

②它的職位，絕對比APP的職位少

③並且你沒有1、2年經驗，招你到公司後一開始你做的還是APP。

優點就是：

①學好後，行業通殺，想換行就換行；想自己做產品就自己做產品。

②相比做應用程序的人，不會被經常變動的需求搞得天天加班。

③門檻高，當然薪水相對就高。

操作系統領域，我認為適合於這些人：

①硬體工程師想轉軟體工程師，從底層軟體入門會比較好

②單片機工程師，想升級一下。會Linux底層的人肯定會單片機，會單片機的人不一定會Linux。

③時間充足的學生：如果你正讀大二大三，那麼花上半年學習嵌入式Linux底層多有益處。

④想掌握整個系統的人，比如你正在公司里寫APP，但是想升為系統工程師，那麼底層不得不學。

⑤想自己創業做實體產品的工程師，你有錢的話什麼技術都不用學，但是如果沒錢又想做產品，那麼Linux底層不得不學。

⑥做Linux APP的人，沒錯，他們也要學習。

這部分人不需要深入，了解個大概就可以：bootloader是用來啟動內核，Linux的文件系統(第1個程序是什麼、做什麼、各目錄幹嘛用)、APP跟驅動程序的調用關系、工具鏈，有這些概念就可以了

本文中，就把操作系統默認為Linux，講講怎麼學習嵌入式Linux+Android系統。

1.4 嵌入式Linux+Android系統包含哪些內容

嵌入式Linux系統包含哪些東西？不要急，舉一個例子你就知道了。

①電腦一開機，那些界面是誰顯示的？

是BIOS，它做什麼？一些自檢，然後從硬碟上讀入windows，並啟動它。

類似的，這個BIOS對應於嵌入式Linux里的bootloader。這個bootloader要去Flash上讀入Linux內核，並啟動它。

②啟動windows的目的是什麼？

當然運行應用程序以便上網、聊天什麼的了。

這些上網程序、聊天程序在哪？

在C盤、D盤上。

所以，windows要先識別出C盤、D盤。在Linux下我們稱之為根文件系統。

③windows能識別出C盤、D盤，那麼肯定有讀寫硬碟的能力。

這個能力我們稱之為驅動程序。當然不僅僅是操作硬碟，還有網卡、USB等等其他硬體。嵌入式Linux能從Flash上讀出並執行應用程序，肯定也得有Flash的驅動程序啊，當然也不僅僅是Flash。

簡單地說，嵌入式LINUX系統里含有bootloader、內核、驅動程序、根文件系統、應用程序這5大塊。而應用程序，我們又可以分為：C/C++、Android。

所以，嵌入式Linux+Android系統包含以下6部分內容：

①bootloader

②Linux內核

③驅動程序

④使用C/C++編寫的應用程序

⑤Android系統本身

⑥Android應用程序

Android跟Linux的聯系實在太大了，它的應用是如此廣泛，學習了Linux之後沒有理由停下來不學習Android。在大多數智能設備中，運行的是Linux操作系統；它上面要麼安裝有Android，要麼可以跟Android手機互聯。現在，Linux+Android已成標配。

2. 怎麼學習嵌入式Linux操作系統

本文假設您是零基礎，以實用為主，用最快的時間讓你入門；後面也會附上想深入學習時可以參考的資料。

在實際工作中，我們從事的是「操作系統」周邊的開發，並不會太深入學習、修改操作系統本身。

①操作系統具有進程管理、存儲管理、文件管理和設備管理等功能，這些核心功能非常穩定可靠，基本上不需要我們修改代碼。我們只需要針對自己的硬體完善驅動程序

②學習驅動時必定會涉及其他知識，比如存儲管理、進程調度。當你深入理解了驅動程序後，也會加深對操作系統其他部分的理解

③Linux內核中大部分代碼都是設備驅動程序，可以認為Linux內核由各類驅動構成

但是，要成為該領域的高手，一定要深入理解Linux操作系統本身，要去研讀它的源代碼。

在忙完工作，閑暇之餘，可以看看這些書：

①趙炯的《linux內核完全注釋》，這本比較薄，推薦這本。他後來又出了《Linux 內核完全剖析》，太厚了，搞不好看了後面就忘記前面了。

②毛德操、胡希明的《LINUX核心源代碼情景分析》，此書分上下冊，巨厚無比。當作字典看即可：想深入理解某方面的知識，就去看某章節。

③其他好書還有很多，我沒怎麼看，沒有更多建議

基於快速入門，上手工作的目的，您先不用看上面的書，先按本文學習。

2.1 入門路線圖

假設您是零基礎，我們規劃了如下入門路線圖。前面的知識，是後面知識的基礎，建議按順序學習。每一部分，不一定需要學得很深入透徹，下面分章節描述。

2.2 學習驅動程序之前的基礎知識

2.2.1 C語言

只要是理工科專業的，似乎都會教C語言。我見過很多C語言考試90、100分的，一上機就傻了，我懷疑他們都沒在電腦上寫過程序。

理論再好，沒有實踐不能幹活的話，公司招你去幹嘛？

反過來，實踐出真知，學習C語言，必須練練練、寫寫寫！

當你掌握基本語法後，就可以在電腦上練習一些C語言習題了；

當你寫過幾個C程序後，就可以進入下一階段的裸機開發了。

①不需要太深入

作為快速入門，只要你會編寫「Hello, world!」，會寫冒泡排序，會一些基礎的語法操作，暫時就夠了。

指針操作是重點，多練習；

不需要去學習過多的數據結構知識，只需要掌握鏈表操作，其他不用學習，比如：隊列、二叉樹等等都不用學；不需要去學習任何的函數使用，比如文件操作、多線程編程、網路編程等等；這些知識，在編寫Linux應用程序時會用，但是在操作系統特別是驅動學習時，用不著！

永往直前吧，以後碰到不懂的C語言問題，我們再回過頭來學習。

在後續的「裸機開發」中，會讓你繼續練習C語言，那會更實戰化。

C語言是在寫代碼中精進的。

②可以在Visual Studio下學習，也可以在Linux下學習，後者需要掌握一些編譯命令，我們暫時沒有提供C語言的教程，找一本C語言書，網上找找免費的C語言視頻(主要看怎麼搭建環境)，就可以自學了。

2.2.2 PC Linux基本操作：

對於PC Linux，我們推薦使用Ubuntu，在它上面安裝軟體非常簡便。

我們的工作模式通常是這樣：在Windows下閱讀、編寫代碼，然後把代碼上傳到PC Linux去編譯。實際上，Ubuntu的桌面系統已經很好用了，我們拿到各種智能機可以很快上手，相信Ubuntu的桌面系統也可以讓你很快上手。為了提高工作效率，我們通常使用命令行來操作Ubuntu。

不用擔心，你前期只需要掌握這幾條命令就可以了，它們是如此簡單，我乾脆列出它們：

①cd : Change Directory（改變目錄）

cd 目錄名 // 進入某個目錄cd .. // cd 「兩個點」：返回上一級目錄cd - // cd 「短橫」：返回上一次所在目錄

②pwd : Print Work Directory（列印當前目錄 顯示出當前工作目錄的絕對路徑）

③mkdir : Make Directory（創建目錄）

mkdir abc // 創建文件夾abcmkdir -p a/b/c // 創建文件夾a，再a下創建文件夾b，再在b下創建文件夾c

④rm : Remove（刪除目錄或文件）

rm file // 刪除名為file的文件rm -rf dir // 刪除名為dir的目錄

⑤ls : List（列出目錄內容）

⑥mount : 掛載

mount -t nfs -o nolock,vers=2 192.168.1.123:/work/nfs_root /mntmount -t yaffs /dev/mtdblock3 /mnt

⑦chown : Change owner（改變文件的屬主，即擁有者）

chown book:book /work -R //對/work目錄及其下所有內容，屬主改為book用戶，組改為book

⑧chmod : Change mode（改變許可權），下面的例子很簡單粗暴

chmod 777 /work -R // 對/work目錄及其下所有內容，許可權改為可讀、可寫、可執行

⑨vi : Linux下最常用的編輯命令，使用稍微復雜，請自己搜索用法。

要練習這些命令，你可以進入Ubuntu桌面系統後，打開終端輸入那些命令；或是用SecureCRT、putty等工具遠程登錄Ubuntu後練習。

2.2.3 硬體知識

我們學習硬體知識的目的在於能看懂原理圖，看懂通信協議，看懂晶元手冊；不求能設計原理圖，更不求能設計電路板。

對於正統的方法，你應該這樣學習：

①學習《微機原理》，理解一個計算機的組成及各個部件的交互原理。

②學習《數字電路》，理解各種門電路的原理及使用，還可以掌握一些邏輯運算（與、或等）。

③《模擬電路》？好吧，這個不用學，至少我在工作中基本用不到它，現在全忘光了。

就我個人經驗來說，這些課程是有用的，但是：

①原理有用，實戰性不強。

比如《微機原理》是基於x86系統，跟ARM板子有很大差別，當然原理相通。

我是在接觸嵌入式編程後，才理解了這些課程。

②每本書都那麼厚，內容都很多，學習時間過長，自學有難度。

針對這些校園教材的不足，並結合實際開發過程中要用到的知識點，我們推出了《學前班_怎麼看原理圖》的系列視頻：

學前班第1課第1節___怎麼看原理圖之GPIO和門電路.wmv

學前班第1課第2.1節_怎麼看原理圖之協議類介面之UART.wmv

學前班第1課第2.2節_怎麼看原理圖之協議類介面之I2C.wmv

學前班第1課第2.3節_怎麼看原理圖之協議類介面之SPI.wmv

學前班第1課第2.4節_怎麼看原理圖之協議類介面之NAND Flash.wmv

學前班第1課第2.5節_怎麼看原理圖之協議類介面之LCD.wmv

學前班第1課第3節___怎麼看原理圖之內存類介面.wmv

學前班第1課第4.1節_怎麼看原理圖之分析S3C2410開發板.wmv

學前班第1課第4.2節_怎麼看原理圖之分析S3C2440開發板.wmv

學前班第1課第4.3節_怎麼看原理圖之分析S3C6410開發板.wmv

即使你只具備初中物理課的電路知識，我也希望能通過這些視頻，讓你可以看懂原理圖，理解一些常見的通信協議；如果你想掌握更多的硬體知識，這些視頻也可以起個索引作用，讓你知道缺乏什麼知識。

這些視頻所講到的硬體知識，將在《裸板開發》系列視頻中用到，到時可以相互對照著看，加深理解。

2.2.4 要不要專門學習Windows下的單片機開發

很多學校都開通了單片機的課程，很多人都是從51單片機、AVR單片機，現在比較新的STM32單片機開始接觸嵌入式領域，並且使用Windows下的開發軟體，比如keil、MDK等。

問題來了，要不要專門學習Windows下的單片機開發？

①如果這是你們專業的必修課，那就學吧

②如果你的專業跟單片機密切相關，比如機械控制等，那就學吧

③如果你只是想從單片機入門，然後學習更廣闊的嵌入式Linux，那麼放棄在Windows下學習單片機吧！

理由如下：

①Windows下的單片機學習，深度不夠

Windows下有很好的圖形界面單片機開發軟體，比如keil、MDK等。

它們封裝了很多技術細節，比如：

你只會從main函數開始編寫代碼，卻不知道上電後第1條代碼是怎麼執行的；

你可以編寫中斷處理函數，但是卻不知道它是怎麼被調用的；

你不知道程序怎麼從Flash上被讀入內存；

也不知道內存是怎麼劃分使用的，不知道棧在哪、堆在哪；

當你想裁剪程序降低對Flash、內存的使用時，你無從下手；

當你新建一個文件時，它被自動加入到工程里，但是其中的機理你完全不懂；

等等等。

②基於ARM+Linux裸機學習，可以學得更深，並且更貼合後續的Linux學習。實際上它就是Linux下的單片機學習，只是一切更加原始：所有的代碼需要你自己來編寫；哪些文件加入工程，需要你自己來管理。

在工作中，我們當然傾向於使用Windows下更便利的工具，但是在學習階段，我們更想學習到程序的本質。

一切從零編寫代碼、管理代碼，可以讓我們學習到更多知識：

你需要了解晶元的上電啟動過程，知道第1條代碼如何運行；

你需要掌握怎麼把程序從Flash上讀入內存；

需要理解內存怎麼規劃使用，比如棧在哪，堆在哪；

需要理解代碼重定位；

需要知道中斷發生後，軟硬體怎麼保護現場、跳到中斷入口、調用中斷程序、恢復現場；

你會知道，main函數不是我們編寫的第1個函數；

你會知道，晶元從上電開始，程序是怎麼被搬運執行的；

你會知道，函數調用過程中，參數是如何傳遞的；

你會知道，中斷發生時，每一個寄存器的值都要小心對待；

等等等。

你掌握了ARM+Linux的裸機開發，再回去看Windows下的單片機開發，會驚呼：怎麼那麼簡單！並且你會完全明白這些工具沒有向你展示的技術細節。

驅動程序=Linux驅動程序軟體框架+ARM開發板硬體操作，我們可以從簡單的裸機開發入手，先掌握硬體操作，並且還可以：

①掌握如何在PC Linux下編譯程序、把程序燒錄到板子上並運行它

②為學習bootloader打基礎：掌握了各種硬體操作後，後面一組合就是一個bootloader

2.2.5 為什麼選擇ARM9 S3C2440開發板，而不是其他性能更好的？

有一個錯誤的概念：S3C2440過時了、ARM9過時了。

這是不對的，如果你是軟體工程師，無論是ARM9、ARM11、A8還是A9，對我們來說是沒有差別的。

一款晶元，上面有CPU，還有眾多的片上設備(比如UART、USB、LCD控制器)。我們寫程序時，並不涉及CPU，只是去操作那些片上設備。

所以：差別在於片上設備，不在於CPU核；差別在於寄存器操作不一樣。

因為我們寫驅動並不涉及CPU的核心，只是操作CPU之外的設備，只是讀寫這些設備的寄存器。

之所以推薦S3C2440，是因為它的Linux學習資料最豐富，並有配套的第1、2期視頻。

2.2.6 怎麼學習ARM+Linux的裸機開發

學習裸機開發的目的有兩個：

①掌握裸機程序的結構，為後續的u-boot作準備

②練習硬體知識，即：怎麼看原理圖、晶元手冊，怎麼寫代碼來操作硬體

後面的u-boot可以認為是裸機程序的集合，我們在裸機開發中逐個掌握各個部件，再集合起來就可以得到一個u-boot了。

後續的驅動開發，也涉及硬體操作，你可以在裸機開發中學習硬體知識。

注意：如果你並不關心裸機的程序結構，不關心bootloader的實現，這部分是可以先略過的。在後面的驅動視頻中，我們也會重新講解所涉及的硬體知識。

推薦兩本書：杜春蕾的《ARM體系結構與編程》，韋東山的《嵌入式Linux應用開發完全手冊》。後者也許是國內第1本涉及在PC Linux環境下開發的ARM裸機程序的書，如果我說錯了，請原諒我書讀得少。

對於裸機開發，我們提供有2部分視頻：

①環境搭建

第0課第1節_剛接觸開發板之介面接線.wmv

第0課第2節_剛接觸開發板之燒寫裸板程序.wmv

第0課第3節_剛接觸開發板之重燒整個系統.wmv

第0課第4節_剛接觸開發板之使用vmwae和預先做好的ubuntu.wmv

第0課第5節_剛接觸開發板之u-boot打補丁編譯使用及建sourceinsight工程.wmv

第0課第6節_剛接觸開發板之內核u-boot打補丁編譯使用及建sourceinsight工程.wmv

第0課第7節_剛接觸開發板之製作根文件系統及初試驅動.wmv

第0課第8節_在TQ2440,MINI2440上搭建視頻所用系統.wmv

第0課第9節_win7下不能使用dnw燒寫的替代方法.wmv

.................

原文鏈接：網頁鏈接

㈢ linux 的學習除了掌握必要的指令外，還要學習什麼

談如何學習linux一.為什麼要學linux?

當然最重要是愛好和興趣！如果你這種必要學，或者根本不喜歡，請不要浪費時間，你學也學不好！

二.起步

你應該為自己創造一個學習linux的環境--在電腦上裝一個linux或unix
問題1：版本的選擇

北美用redhat,歐洲用SuSE,桌面mandrake較多，而debian是技術最先進的linux
開發人員中用debian的最多，其次是redhat,從全球linux各應用領域市場份額來看
無疑redhat是最多的，此外還有很多出名的發行版本，不再列舉。
對於初學linux的人來說，我建議是使用redhat,原因如下：
1）現在很多書都是以redhat為例講的，為了與書本協調一致
2）周圍的人都用redhat,交流比較方便
3）redhat應用范圍廣，有典型性和代表性
4）它易於使用和安裝，我們沒有必要把時間浪費在「裝系統」上
而應集中精力學習最有用的東西。

//註：現在覺得RH很死板，AS,ES等用在伺服器上或許不錯，
Personal desktop用mandrake,debian,suse都不錯，筆者現在用Mandrake,因為她長得漂亮

如果你並不打算深入學習linux，而是有諸如適應北京市政府辦公平台遷移到
linux上這種需要，那麼中軟，紅旗等中文linux是不錯的選擇

我強烈建議：自己親自動手把linux裝到你的硬碟上，
你必須學會獨立安裝linux系統的技能，對於現在的版本來說，其實跟裝WinXP一樣簡單

從此現在開始，請不要以windows的工作方式來考慮問題，
應該嘗試挖掘linux身上的「天才unix」的氣質。

三.進階
掌握至少50個以上的常用命令
理解shell管道"|",文件流重定向">"及追加">>"等
熟悉Gnome/KDE等X-windows桌面環境操作
掌握.tgz.rpm.biz等軟體包的常用安裝方法
學習添加外設，安裝設備驅動程序（比如modem)
熟悉Grub/Lilo引導器及簡單的修復操作
熟悉系統固有目錄的名稱及公用
學會用mount命令訪問其他文件系統
了解vi,gcc,gdb等常用編輯器，編譯器，調試器
學習linux環境下的簡單組網

建議：買一本不需要太厚的linux教材，大致可以滿足要求
//現在的書越來越多了，還帶很多圖，我當時可沒這么多書：）

四.高級應用

澄清一些概念：
linux的普通操作與真正的系統管理不能相提並論，後者需要很多知識

我個人認為比較重要幾種linux語言
1.英語
即使你不學linux，我也強烈建議你學好英文[U.S.english]
因為實質上計算機語言就是英文和字元,所謂的多國語言只是外部包裝
你必須能無障礙的閱讀大量的英文技術文檔
在搜索引擎找到的英文網站和網頁中熟練的檢索
最好能有用英文直接交流的能力，
擺脫了這個障礙，你的學習和理解速度就能快很多，你就有機會拉開和別人的差距

2.shell[sed/awk]
shell是命令解釋器，是內核與用戶界面交流通道，shell寫的小腳本有點類似於win下的.bat
但shell比.bat強大的多，shell不只是解釋命令，更是一種編程語言，有時候幾百行的c用shell
幾十行就能代替完成工作，因為shell的工作方式建立在系統已有的眾多應用程序之上
這也是CS中的一個重要思想。
此外，shell可以實現工作自動化，這個概念也比較重要
sed,awk用來處理文本，歷來很常用

3.Perl/php
漂亮的腳本， CGI的首選，比ASP好，應用面很廣

4.C\C++
C、C++是linux/unix的核心語言，系統代碼都是C寫的

5.ASM
系統底層及內核，硬體，設備驅動程序，嵌入式開發都需要
//走核心路線的話，才c\c++,asm最重要

6.Java,Python,Tcl,XML

*系統管理篇
在熟悉linux的基礎上還需要掌握至少一種unix
我首推Solaris，其次是FreeBSD
比如運營級系統一般是Solaris+Oracle/DB2之類的
學習apache,ssh,sendmail/Qmail,proftp/vsftp,Samba,Squid,MySQL/PostgreSQL/Oracle,Bind
等各種應用伺服器的構架及電子商務的應用
熟悉TCP/IP協議族，學習諸如apache+php+proftp+mysql+quota的實現以及大型區域網，分布式集群
等各種企業級應用解決方案
熟悉多用戶管理，資料庫管理，文件系統，邏輯存儲管理，日誌分析，備份與災難數據修復
系統補丁，內核升級，以及在此基礎上的防火牆構架等以保障系統安全在內的各種系統管理技能

我覺得，如果在此基礎上再掌握路由/交換設備便是一個不錯的系統管理員

各種基於linux的解決方案可參考相關書籍和文獻，必要時用google或各大linux站點站內
搜索引擎尋找最新文檔，以避免錯誤和漏洞
有幾本技術大全和技術內幕我認為都是這方面不錯的書

*深入學習linux

我個人理解的讀linux內核需要的基礎：
在此之前,希望先把應用層的東西學一下,那樣會比較好理解
1.C
如果學過潭浩強的大學教科書(除了編幾個數學模型好像什麼也做不了的那種)，
建議再看一下
《The C Programming Language》Second Edition這本聖經
/*如果想學緩沖區溢出，這點C的功力可能是不夠的*/
還有,,,
反正經典書看多了是沒有壞處的

2.asm (AT&T語法，保護模式)
保護模式下的比較復雜，基本上每本講內核的書都會有介紹
有80x86 Intel語法的基礎就行，
有興趣可以看看Intel的官方****

3.數據結構（離散數學）
計算機專業的核心課程，重要性我就不說了

4.操作系統原理
看懂這個再去讀linux吧

5.微機原理/組成原理（數字電路）
底層直接和硬體打交道，所以這個也要

6.了解linux/unix
我想至少你要會操作吧，了解unix的API

7.軟體工程/編譯原理

這方面的經典書去www.china-pub.com可以搜到很多
我覺得APUE這種書不適合初學者，還是先看看UPE之類的吧

APUE:
《》
《unix環境高級編程》
作者：W.Richard.Stevens共有6本經典書，尊為「聖經」
他的書為全世界黑客所拜讀！

UPE:《unixprogrammingenvironment》
《unix編程環境》比較適合初學者的，深入淺出，
其中有一些比較重要的思想
另外,介紹linux下應用層編程的書也有很多,比如
,redhat,redflag出的書...........
經典書還有很多很多......
操作系統：設計與實現//交大的考研參考書目，講Minix的
unix操作系統設計
4.4BSD操作系統設計與實現
昂萊氏unix源代碼分析
ulk:understanding the linux kernel (2nd)深入理解linux內核
linux設備驅動程序 (2nd)
linux內核源代碼情景分析
保護方式下的80386及其編程

參考資料來自：51cto技術論壇

㈣ 就業方向

考哪些證書對我的就業有幫助
如CCNA就是思科的入門體系，這表明你已經基本地掌握了思科的網路知識，可是現在的話CCNA人數已經大有人在，如果以後想往思科方向發展最少要通過CCNP了，能拿到CCIE的證書是最好不過了。

再有就是思科屬於國際認證，是各大企業招聘的優先選擇標准，有真正的技術和能力，是很受社會青睞的呀。

計算機專業畢業後大致的工作方向是軟、硬、網、圖 四大類
尤其以軟體、網路為現今的首選

從崗位上分，又可以分為技術道路、營銷道路兩大方向

if 你選擇作技術，then 從現在開始，牢記：
天道酬勤！！！
if 你選擇軟體技術 then 每天都要用大量的時間學習高級語言，絕對不能僅限於學校的安排。優秀的程序員都是大學階段就已經自學得非常深入了。
if you選擇網路技術，那麼你就多多從網上閱讀有關資料

if you 選擇營銷類，那麼，你只要將老師教授的學好就ok
但是，一定要用大量的時間到計算機公司去兼職做營銷，踏踏實實提高自己與客戶接觸能力。

一、給計算機專業的同學

1.首先請你熱愛這個專業。只有這樣，你才會從抽象的理論中找到實實在在的快樂。如果你不熱愛她，或者只因為這是個熱門專業，那麼極力要求你放棄這個專業，因為計算機是一把雙刃劍，學好了你會飛黃騰達，學不好你畢業後會極其痛苦，高不成低不就，沒有發展潛力，如同學英語專業的人到了美國一樣。
2.不要用功利眼光對待這個學科，這絕對不是點點滑鼠就能掙錢的專業。不要去想做網站掙錢，不要想靠點擊率增加廣告，這個在4年前已經過時，如果你現在仍然這么想，千萬別說出來，因為我會覺得你很土。計算級專業的成就感總是伴隨著身體上的痛苦而來，肩周炎，頸椎病，眼睛干澀，掉頭發，腰椎間盤突出，關節炎，不誇張，這么帥的我工作了兩個月以後發現開始掉頭發了。
3.搞明白計算機「科學」與「技術」的含義。做網頁，做圖片，做flash，玩游戲，上網，聽歌，錄mp3,搞電影字幕，裝windows，改注冊表，為軟體皮膚……這通通不叫計算機科學與技術，如果你是計算機的學生，會做以上事情，那是你應該的，不會做，也沒什麼丟人的，我們需要的不是讓別人稱作「高手」。
4.明確你最終的專業方向是軟體還是硬體。方向是網路？網路不是專業方向。網路是最優秀的軟體工程師、最優秀的硬體工程師與最優秀的通信工程師的智慧結晶。如果你是軟體方向，請你在學精一攬子數學、數據結構、演算法設計、數值分析、匯編語言、操作系統、編譯原理、資料庫原理、軟體工程之類課程後，仔細的聽一聽硬體課程，他對你有用。軟體工程絕對不是背背就能過的課，計算機理論可能是一個人就能研究出來，軟體工程是成千萬網軟體工程師幾十年來失敗的教訓凝結成的結晶，請認真聽課。不要問我應該學什麼語言，計算級專業的人必須具備任何語言1小時上手的能力，最起碼要在10分鍾把"hello world"做出來。如果說有必須學的兩種語言，那他們是c++與java，學他們不是在學語言，而是在學thinking in c++，thinging in java，一個是軟體的基礎理論，一個是面向對象的基礎理論，從來沒有人聽說過「thinking in basic」。如果你說c++過時了，那麼千萬別告訴別人你的名字，因為很丟人。山科大的老師只會教給你c，不會教給你++，所以不要被他蒙蔽，大膽的問他++，如果他不會，乾脆換老師。學硬體的同學在認真聽聽以上課程後，學精除了政治以外的其他課程。
5.即使你學好了以上課程，我們仍然差得很遠，我們只弄清學什麼了，但是還不知道做什麼。我們的課程設計太小兒科了，別對你在國外的同學說，否則會被笑話，所以我們要盡可能的多做設計，別一個人們悶著頭做，兩三個人合作一個項目，不會交流的計算機人員30歲以後肯定會下崗。題目呢，盡量是一些簡單的底層開發，可以去國外大學網站上搜一搜，要自信你一定能做出來，畢竟不是什麼難題，而是我們應當具備的素質。
6.如果你對網路有意，在具備了一定動手能力後從協議或者底層硬體的角度去學習它。否則你是自甘從一名高貴的計算機專業人員墮落為做著沉重機械體力勞動的民工。對網路安全感興趣，那麼你就在學會使用各種工具的一個月後從編程的角度深入學習網路協議和操作系統吧！只會用工具攻擊無知人員的漏洞是一種意淫的行為，如果樂此不疲，並到處叫嚷「黑客」，那麼這種行為可以被稱作「手淫」。網上呼籲中美、中日黑客戰時，希望你安心學習課程，或者睡覺休息，或者去運動娛樂，不要給祖國抹黑。
7.正確對待認證。絕大部分認證不是高薪的敲門磚，而是你上崗前的智商水平測試。如果你考過了認證，別對別人說這個認證是垃圾，請告訴別人你在學習中懂得了那些知識，如果你沒有懂得知識，那麼你是個paper，認證不是垃圾，你是垃圾。如果你連認證都沒考就到處喊它垃圾，那麼你就親自考考試試，考過了，懂了，那麼你隨便；如果過了但是不懂，認證不是垃圾你是垃圾，如果沒考過，那麼看這個貼子的所有人都知道你是什麼了。MCSE、CCNA、CIW等等都有它存在的意義，只要你有錢都值得一學，他們是最正規的知識來源，是經過理論、實踐、時間與市場考驗的產品。

㈤ 大家好，小弟一直不明白對linux或uboot源碼包打補丁的原因。在網上查了資料也沒有詳細的介紹。

1、配置源碼需要重新編譯，而重新編譯系統會花費大量的時間，而且Linux系統並不是修改源碼就能編譯通過，還涉及到很多的Makefile，那麼要你單獨一個個的修改工作量也會比較大。但是源碼補丁可以自動識別和替換需要的，方便了一些並不是太熟悉Linux的人，而且減輕了用戶的工作量。
2、既然是補丁，肯定都是針對某一些特殊情況開發的，並不是所有人都會遇到這些情況，也並不是所有人都需要這些補丁。Linux發布的源碼都是一些Linux比較大的升級時候發布一次的，而源碼是提供給所有人的，那麼也不是每個人都需要這個補丁的源碼呀，一般都只是下載和自己所從事專業有關的。

補丁的話隨便你自己，因為不是所有人都需要那個補丁，就算你不裝，也沒什麼問題的

㈥ Linux和windows的優勢對比

Linux和Windows是兩種操作系統，對於伺服器運維的人來說，在為伺服器選擇操作系統系統的時候，是選擇Linux還是Windows是讓人困惑的事？

從用戶群來說Linux是一個以開發者為中心的操作系統，而windows是以消費者為中心的操作系統，這也是兩個操作系統作為根本的區別。簡單來講，兩個系統的選擇就是看你是開發用還是作為消費者使用。

具體到Linux與Windows的優缺點，可以總結為一下幾點

1.Linux可以看到源代碼，windows不行。

這一點直接導致的結果就是在特殊應用的場合可以自行剪裁和定製所需的內核模塊，這對於高級系統內核管理優化和驅動程序的開發相當有利，另外也因為代碼可見，不用擔心惡意功能或者後門，對於軍政企的使用比較有利。另外在系統出現嚴重問題的時候，可以自行修改代碼或者接個幾k的patch就能編譯然後使用，而windows你得等微軟的補丁。

2、Linux命令行功能強大，可以做任何事情，windows也有命令行，但是屬於附屬品。

命令行是Linux的根本，甚至你對某些命令不滿意，你也可以自己修改或者編個自己的命令出來。命令行的好處是可重復。想要知道命令行的具體是什麼你可以訪問老男孩教育。如果你想要告訴別人一件事怎麼做，一個命令行發過去就可以，想要再做一遍之前做過的一件事，調出歷史命令記錄重新執行一下就行。很多要定時做的事情寫成腳本設個crontab定時，就完事兒。另外這樣也可以保證你用一樣的命令行，做的是一樣的事情。

3、開放源碼和高度可定製

開放源碼的初衷，不是為了自由而是為了定製。AT&T UNIX從來就是有版權的，但是源代碼仍然可用，這是為了讓用戶能夠根據需要，去修改它。Linux社區所贊賞的軟體和系統，多半遵循同樣的規則——它應該能夠適應不同用戶的不同環境，能夠輕易的改變自己的行為，能夠輕松的與不同環境整合。與其假設別人和你的需求一致，不如給予它們定製系統的自由。

4、去中心化

分散的軟體開發，也註定了系統的介面和形式不統一——因為大家都喜歡發明輪子。而每個人的輪子或多或少更適合自己和社區，而非所有人，而在Linux的環境下又沒有人能強迫所有人用自己的輪子(除了Kernel開發者，但其實很多distro對kernel也有patch)，所以與其制定一種實踐，Linux更多的讓用戶去選擇生活的方式。

你會看到Linux生態環境中有大量的distro，不同的distro有不同的init方式，不同的軟體包管理器和安裝策略；每個人習慣使用不同的VCS，不同的shell，不同的編輯器，都就是更多的選擇的哲學的體現。

5、Linux是基於網路的，誕生於網路。

遠程連接上SSH，你就可以輕松操控遠在千里之外的Linux伺服器，只要有相應的許可權，幾乎和坐在物理機面前沒有區別，哪怕網速很糟糕，實際只是一些加密的字元在傳送，需要的帶寬很小。

㈦ c語言編譯程序屬於應用軟體,系統軟體還是工具軟體

c語言編譯程序屬於系統軟體。

編譯程序（Compiler，compiling program）也稱為編譯器，是指把用高級程序設計語言書寫的源程序，翻譯成等價的機器語言格式目標程序的翻譯程序。這里的編譯程序是一種動作，是根據編譯原理技術，由高級程序設計語言編譯器翻譯成機器語言二進制代碼行為。因此它是系統軟體。

計算機軟體總體分為系統軟體和應用軟體兩大類：系統軟體是各類操作系統，如windows、Linux、UNIX等，還包括操作系統的補丁程序及硬體驅動程序，都是系統軟體類。

應用軟體可以細分的種類就更多了，如工具軟體、游戲軟體、管理軟體等都屬於應用軟體類。電腦工具軟體就是指在使用電腦進行工作和學習時經常使用的軟體。

(7)補丁編譯原理擴展閱讀：

不同點

1、表現形式不同

硬體有形，有色，有味，看得見，摸得著，聞得到。而軟體無形，無色，無味，看不見，摸不著，聞不到。軟體大多存在人們的腦袋裡或紙面上，它的正確與否，是好是壞，一直要到程序在機器上運行才能知道。這就給設計、生產和管理帶來許多困難。

2、生產方式不同

軟體是開發，它是人的智力的高度發揮，不是傳統意義上的硬體製造。盡管軟體開發與硬體製造之間有許多共同點，但這兩種活動是根本不同的。

3、要求不同

硬體產品允許有誤差，而軟體產品卻不允許有誤差。

4、維護不同

硬體是要用舊用壞的，在理論上，軟體是不會用舊用壞的，但在實際上，軟體也會變舊變壞。因為在軟體的整個生存期中，一直處於改變(維護)狀態。

網路-計算機軟體