make源碼剖析

❶ 怎麼使用，手上有一本linux內核2.4版源代碼分析大全

一般在Linux系統中的/usr/src/linux*.*.*（*.*.*代表的是內核版本，如2.4.23）目錄下就是內核源代碼（如果沒有類似目錄，是因為還沒安裝內核代碼）。另外還可從互連網上下載。注意，不要總到去下載，最好使用它的鏡像站點下載。請在mirrors/里找一個合適的下載點，再到pub/linux/kernel/v2.6/目錄下去下載2.4.23內核。
代碼目錄結構
在閱讀源碼之前，還應知道Linux內核源碼的整體分布情況。現代的操作系統一般由進程管理、內存管理、文件系統、驅動程序和網路等組成。Linux內核源碼的各個目錄大致與此相對應，其組成如下（假設相對於Linux-2.4.23目錄）：
1.arch目錄包括了所有和體系結構相關的核心代碼。它下面的每一個子目錄都代表一種Linux支持的體系結構，例如i386就是Intel CPU及與之相兼容體系結構的子目錄。PC機一般都基於此目錄。
2.include目錄包括編譯核心所需要的大部分頭文件，例如與平台無關的頭文件在include/linux子目錄下。
3.init目錄包含核心的初始化代碼（不是系統的引導代碼），有main.c和Version.c兩個文件。這是研究核心如何工作的好起點。
4.mm目錄包含了所有的內存管理代碼。與具體硬體體系結構相關的內存管理代碼位於arch/*/mm目錄下。
5.drivers目錄中是系統中所有的設備驅動程序。它又進一步劃分成幾類設備驅動，每一種有對應的子目錄，如音效卡的驅動對應於drivers/sound。
6.ipc目錄包含了核心進程間的通信代碼。
7.moles目錄存放了已建好的、可動態載入的模塊。
8.fs目錄存放Linux支持的文件系統代碼。不同的文件系統有不同的子目錄對應，如ext3文件系統對應的就是ext3子目錄。
Kernel內核管理的核心代碼放在這里。同時與處理器結構相關代碼都放在arch/*/kernel目錄下。
9.net目錄里是核心的網路部分代碼，其每個子目錄對應於網路的一個方面。
10.lib目錄包含了核心的庫代碼，不過與處理器結構相關的庫代碼被放在arch/*/lib/目錄下。
11.scripts目錄包含用於配置核心的腳本文件。
12.documentation目錄下是一些文檔，是對每個目錄作用的具體說明。
一般在每個目錄下都有一個.depend文件和一個Makefile文件。這兩個文件都是編譯時使用的輔助文件。仔細閱讀這兩個文件對弄清各個文件之間的聯系和依託關系很有幫助。另外有的目錄下還有Readme文件，它是對該目錄下文件的一些說明，同樣有利於對內核源碼的理解。
在閱讀方法或順序上，有縱向與橫向之分。所謂縱向就是順著程序的執行順序逐步進行；所謂橫向，就是按模塊進行。它們經常結合在一起進行。對於Linux啟動的代碼可順著Linux的啟動順序一步步來閱讀；對於像內存管理部分，可以單獨拿出來進行閱讀分析。實際上這是一個反復的過程，不可能讀一遍就理解。

❷ 有關計算機的好書介紹一下

《編程珠璣》（推薦，思維方法很好）
《c專家編程》（強烈推薦，雖然絕版，而且上面有些不符合現在標準的內容，不過看完後，C的功力還是會大增）
《c++ primer plus》（強烈推薦，C++入門級書本，內容相當詳細）
《effective c++》（強烈推薦，看完C++功力絕對大漲）
《more effective c++》（同上，一個作者寫的）
《c++標准程序庫》（推薦STL入門讀物，可當工具書）
《STL源碼剖析》（推薦，可以先通過該書了解STL的實作，結合現在的代碼，足以讓人領略STL的偉大之處……）
《深入淺出MFC》（說實話，沒看完，不過用來了解MFC的體系還是很不錯的，不推薦初學者看）

《linux c編程》（前半部分講make file很詳細，後半部分就一般般了……）
《UINX環境高級編程（second edition）》（強烈推薦，大師之作，怎能不看？這本英文容易看懂，看英文就可以了）
《linux內核完全剖析》（看得不多，感覺暫時還不大懂-,-）
《windows系統編程》（Johnson M.Hart）（學習windows api的入門書，不是GUI的API）
《Windows程序設計》（Charles Petzold）（強烈推薦，這本用來學習windows GUI就相當合適了）

《java how to program》（推薦，java入門書，內容很不錯）
《java編程思想》（沒讀過英文的，不過中文的讀著很累，對java剖析地很深）

《IBM-PC 匯編語言程序設計》（推薦，學匯編的好書……）

《數據結構與演算法分析——c語言描述》（Mark Allen Weiss）（推薦，內容豐富，不過基本上是偽代碼描述）
《數據結構與程序設計——c語言（第二版）》(Robert L.Kruse)（個人學這本入門，覺得很不錯＝。＝）
《計算機演算法（c++版）》（後半部分過難還沒看，前半部分還是很不錯的）
《演算法藝術與信息學競賽》（題目無數，提及了相當多的演算法，適合做OI/ICPC導向性讀物。）
《演算法導論（second edition）》（強烈推薦，沒聽過的話太讓人失望了……）
《C語言名題精選百則技巧篇》（推薦，都是一些很經典的東西，代碼風格不錯）

《operating system concepts》（強烈推薦，名著啊）
《modern operating systems》（推薦，英文沒上面那本好懂，不過作者有相同的人）
《artificial intelligence --- a modern approach》（看了一點，學習人工智慧絕對的好書）
《compilers: principles, techniques, and tools》（強烈推薦，學習編譯原理必備）

我很認真的上網搜的，希望可以幫到你，呵呵

❸ 作為一個新手，我該如何看懂UBOOT的源代碼，我看了幾天，還是分析不出那些函數的作用

拿到代碼都是先從整體再到局部的
先看框架 任何symbian復雜的代碼都是從UI生產view，view創建container的
很大一部分代碼都會和container打交道的，因為它是控制項的容器嘛。
不要太去專注人家的演算法 先沒必要浪費那時間 知道這個類是干什麼的 都有什麼方法 基本就可以了 還有類與類之間的關系呢 也要搞明白 這個呢 通常調試跟一下 會有所明白吧
代碼里肯定會有你不認識不了解陌生的API 你英語好的話 查SDK 英語不好的話 google一下 或多或少都有些答案的
以上是我看代碼的一個基本流程吧 當然拿到一分陌生又復雜的代碼頭很大 但還是有規律可循的 抓住主幹UI-

❹ 根據提供的Linux操作系統源碼中的Makefile結構，分析在工程多級目錄中存在多個makefile文件時編譯的順序如

書上56頁有講
make的遞歸過程指的是：在Makefile中使用「make」作為一個命令來執行本身或者其它makefile文件的過程。遞歸調用在一個存在有多級子目錄的項目中非常有用。例如，當前目錄下存在一個「subdir」子目錄，在這個子目錄中有描述此目錄編譯規則的makefile文件，在執行make時需要從上層目錄（當前目錄）開始並完成它所有子目錄的編譯。那麼在當前目錄下可以使用這樣一個規則來實現對這個子目錄的編譯：
subsystem:
cd subdir && $(MAKE)

其等價於規則：

subsystem:
$(MAKE) -C subdir

❺ 求一段Linux操作系統源代碼分析

Linux內核的配置系統由三個部分組成，分別是：
Makefile：分布在 Linux 內核源代碼中的 Makefile，定義 Linux 內核的編譯規則；
配置文件（config.in）：給用戶提供配置選擇的功能；
配置工具：包括配置命令解釋器（對配置腳本中使用的配置命令進行解釋）和配置用戶界面（提供基於字元界面、基於 Ncurses 圖形界面以及基於 Xwindows 圖形界面的用戶配置界面，各自對應於 Make config、Make menuconfig 和 make xconfig）。
這些配置工具都是使用腳本語言，如 Tcl/TK、Perl 編寫的（也包含一些用 C 編寫的代碼）。本文並不是對配置系統本身進行分析，而是介紹如何使用配置系統。所以，除非是配置系統的維護者，一般的內核開發者無須了解它們的原理，只需要知道如何編寫 Makefile 和配置文件就可以。所以，在本文中，我們只對 Makefile 和配置文件進行討論。另外，凡是涉及到與具體 CPU 體系結構相關的內容，我們都以 ARM 為例，這樣不僅可以將討論的問題明確化，而且對內容本身不產生影響。
2． Makefile
2.1 Makefile 概述
Makefile 的作用是根據配置的情況，構造出需要編譯的源文件列表，然後分別編譯，並把目標代碼鏈接到一起，最終形成 Linux 內核二進制文件。
由於 Linux 內核源代碼是按照樹形結構組織的，所以 Makefile 也被分布在目錄樹中。Linux 內核中的 Makefile 以及與 Makefile 直接相關的文件有：

Makefile：頂層 Makefile，是整個內核配置、編譯的總體控制文件。
.config：內核配置文件，包含由用戶選擇的配置選項，用來存放內核配置後的結果（如 make config）。
arch/*/Makefile：位於各種 CPU 體系目錄下的 Makefile，如 arch/arm/Makefile，是針對特定平台的 Makefile。
各個子目錄下的 Makefile：比如 drivers/Makefile，負責所在子目錄下源代碼的管理。
Rules.make：規則文件，被所有的 Makefile 使用。
用戶通過 make config 配置後，產生了 .config。頂層 Makefile 讀入 .config 中的配置選擇。頂層 Makefile 有兩個主要的任務：產生 vmlinux 文件和內核模塊（mole）。為了達到此目的，頂層 Makefile 遞歸的進入到內核的各個子目錄中，分別調用位於這些子目錄中的 Makefile。至於到底進入哪些子目錄，取決於內核的配置。在頂層 Makefile 中，有一句：include arch/$(ARCH)/Makefile，包含了特定 CPU 體系結構下的 Makefile，這個 Makefile 中包含了平台相關的信息。
位於各個子目錄下的 Makefile 同樣也根據 .config 給出的配置信息，構造出當前配置下需要的源文件列表，並在文件的最後有 include $(TOPDIR)/Rules.make。
Rules.make 文件起著非常重要的作用，它定義了所有 Makefile 共用的編譯規則。比如，如果需要將本目錄下所有的 c 程序編譯成匯編代碼，需要在 Makefile 中有以下的編譯規則：
%.s: %.c
$(CC) $(CFLAGS) -S $< -o $@

有很多子目錄下都有同樣的要求，就需要在各自的 Makefile 中包含此編譯規則，這會比較麻煩。而 Linux 內核中則把此類的編譯規則統一放置到 Rules.make 中，並在各自的 Makefile 中包含進了 Rules.make（include Rules.make），這樣就避免了在多個 Makefile 中重復同樣的規則。對於上面的例子，在 Rules.make 中對應的規則為：
%.s: %.c
$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(*F)) $(CFLAGS_$@) -S $< -o $@

2.2 Makefile 中的變數
頂層 Makefile 定義並向環境中輸出了許多變數，為各個子目錄下的 Makefile 傳遞一些信息。有些變數，比如 SUBDIRS，不僅在頂層 Makefile 中定義並且賦初值，而且在 arch/*/Makefile 還作了擴充。
常用的變數有以下幾類：
1） 版本信息
版本信息有：VERSION，PATCHLEVEL, SUBLEVEL, EXTRAVERSION，KERNELRELEASE。版本信息定義了當前內核的版本，比如 VERSION=2，PATCHLEVEL=4，SUBLEVEL=18，EXATAVERSION=-rmk7，它們共同構成內核的發行版本KERNELRELEASE：2.4.18-rmk7
2） CPU 體系結構：ARCH
在頂層 Makefile 的開頭，用 ARCH 定義目標 CPU 的體系結構，比如 ARCH:=arm 等。許多子目錄的 Makefile 中，要根據 ARCH 的定義選擇編譯源文件的列表。
3） 路徑信息：TOPDIR, SUBDIRS
TOPDIR 定義了 Linux 內核源代碼所在的根目錄。例如，各個子目錄下的 Makefile 通過 $(TOPDIR)/Rules.make 就可以找到 Rules.make 的位置。
SUBDIRS 定義了一個目錄列表，在編譯內核或模塊時，頂層 Makefile 就是根據 SUBDIRS 來決定進入哪些子目錄。SUBDIRS 的值取決於內核的配置，在頂層 Makefile 中 SUBDIRS 賦值為 kernel drivers mm fs net ipc lib；根據內核的配置情況，在 arch/*/Makefile 中擴充了 SUBDIRS 的值，參見4）中的例子。
4） 內核組成信息：HEAD, CORE_FILES, NETWORKS, DRIVERS, LIBS
Linux 內核文件 vmlinux 是由以下規則產生的：
vmlinux: $(CONFIGURATION) init/main.o init/version.o linuxsubdirs
$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o
--start-group
$(CORE_FILES)
$(DRIVERS)
$(NETWORKS)
$(LIBS)
--end-group
-o vmlinux
可以看出，vmlinux 是由 HEAD、main.o、version.o、CORE_FILES、DRIVERS、NETWORKS 和 LIBS 組成的。這些變數（如 HEAD）都是用來定義連接生成 vmlinux 的目標文件和庫文件列表。其中，HEAD在arch/*/Makefile 中定義，用來確定被最先鏈接進 vmlinux 的文件列表。比如，對於 ARM 系列的 CPU，HEAD 定義為：
HEAD := arch/arm/kernel/head-$(PROCESSOR).o
arch/arm/kernel/init_task.o
表明 head-$(PROCESSOR).o 和 init_task.o 需要最先被鏈接到 vmlinux 中。PROCESSOR 為 armv 或 armo，取決於目標 CPU。 CORE_FILES，NETWORK，DRIVERS 和 LIBS 在頂層 Makefile 中定義，並且由 arch/*/Makefile 根據需要進行擴充。 CORE_FILES 對應著內核的核心文件，有 kernel/kernel.o，mm/mm.o，fs/fs.o，ipc/ipc.o，可以看出，這些是組成內核最為重要的文件。同時，arch/arm/Makefile 對 CORE_FILES 進行了擴充：
# arch/arm/Makefile
# If we have a machine-specific directory, then include it in the build.
MACHDIR := arch/arm/mach-$(MACHINE)
ifeq ($(MACHDIR),$(wildcard $(MACHDIR)))
SUBDIRS += $(MACHDIR)
CORE_FILES := $(MACHDIR)/$(MACHINE).o $(CORE_FILES)
endif
HEAD := arch/arm/kernel/head-$(PROCESSOR).o
arch/arm/kernel/init_task.o
SUBDIRS += arch/arm/kernel arch/arm/mm arch/arm/lib arch/arm/nwfpe
CORE_FILES := arch/arm/kernel/kernel.o arch/arm/mm/mm.o $(CORE_FILES)
LIBS := arch/arm/lib/lib.a $(LIBS)

5） 編譯信息：CPP, CC, AS, LD, AR，CFLAGS，LINKFLAGS
在 Rules.make 中定義的是編譯的通用規則，具體到特定的場合，需要明確給出編譯環境，編譯環境就是在以上的變數中定義的。針對交叉編譯的要求，定義了 CROSS_COMPILE。比如：
CROSS_COMPILE = arm-linux-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
......
CROSS_COMPILE 定義了交叉編譯器前綴 arm-linux-，表明所有的交叉編譯工具都是以 arm-linux- 開頭的，所以在各個交叉編譯器工具之前，都加入了 $(CROSS_COMPILE)，以組成一個完整的交叉編譯工具文件名，比如 arm-linux-gcc。
CFLAGS 定義了傳遞給 C 編譯器的參數。
LINKFLAGS 是鏈接生成 vmlinux 時，由鏈接器使用的參數。LINKFLAGS 在 arm/*/Makefile 中定義，比如：
# arch/arm/Makefile
LINKFLAGS :=-p -X -T arch/arm/vmlinux.lds

6） 配置變數CONFIG_*
.config 文件中有許多的配置變數等式，用來說明用戶配置的結果。例如 CONFIG_MODULES=y 表明用戶選擇了 Linux 內核的模塊功能。
.config 被頂層 Makefile 包含後，就形成許多的配置變數，每個配置變數具有確定的值：y 表示本編譯選項對應的內核代碼被靜態編譯進 Linux 內核；m 表示本編譯選項對應的內核代碼被編譯成模塊；n 表示不選擇此編譯選項；如果根本就沒有選擇，那麼配置變數的值為空。
2.3 Rules.make 變數
前面講過，Rules.make 是編譯規則文件，所有的 Makefile 中都會包括 Rules.make。Rules.make 文件定義了許多變數，最為重要是那些編譯、鏈接列表變數。
O_OBJS，L_OBJS，OX_OBJS，LX_OBJS：本目錄下需要編譯進 Linux 內核 vmlinux 的目標文件列表，其中 OX_OBJS 和 LX_OBJS 中的 "X" 表明目標文件使用了 EXPORT_SYMBOL 輸出符號。
M_OBJS，MX_OBJS：本目錄下需要被編譯成可裝載模塊的目標文件列表。同樣，MX_OBJS 中的 "X" 表明目標文件使用了 EXPORT_SYMBOL 輸出符號。
O_TARGET，L_TARGET：每個子目錄下都有一個 O_TARGET 或 L_TARGET，Rules.make 首先從源代碼編譯生成 O_OBJS 和 OX_OBJS 中所有的目標文件，然後使用 $(LD) -r 把它們鏈接成一個 O_TARGET 或 L_TARGET。O_TARGET 以 .o 結尾，而 L_TARGET 以 .a 結尾。

❻ 根據提供的Linux 操作系統源碼中Makefile 結構，分析在工程中多級目錄中存在著多個makefile 時，編譯的順

多級目錄的編譯順序也是有Makefile控制的, 如下這個例子(3個子目錄, 一個Makefile), 子目錄的編譯順序由這個Makefile控制.
sub_a sub_b sub_c Makefile

❼ 推薦一些學C++的書

這是某個網友的工作總結，很適合你的。

掐指一算工作也已經十個月了，再過兩個月就算是我合理度過工作一年的門檻，這一年學到了什麼，錯過了什麼，很值得在新的一年開始的時候反思及總結一下，不然未來可能會更加盲目。。。。
回想起2008年剛剛出來找工作的時候，僅僅是學了《C++ Primer》一書，並且看過《Programming With MFC》的前面大部分章節，竟然找工作很順利：）因為好像大部分純粹是從學校出來的畢業生，哪怕是科班出生的，因為教材即教育方式的限制，甚至都還不知道什麼叫標准庫-_-!我沒有誇張，這是我工作後了解到的現實，也是與一些後來在讀大學生交流後才知道的。所以，雖然我當時感覺自己知道的並不多，但是實際上公司卻發現我似乎懂得很多：）

剛開始的計劃：作為電子通信專業出來，但是最後走向純粹軟體行業的我，知道自己的不足，對於基礎知識的掌握太過薄弱，可能會限制自己將來的發展，我一開始工作就知道的。我並不認為起步階段，在我們公司，更熟悉得一些C++語法能夠是一輩子的優勢，這些在工作一年以後都會成為泡沫。。。。所以這剛開始的時候，其實我給自己定下了一些目標：
1. 首先當然是繼續學習好C++，爭取把找工作前讀了一半的《Effective C++》讀完，另外應該再接再厲將《More Effective C++》和《Effective STL》讀完。
2. 數據結構及演算法部分我一直認為是自己最最欠缺的，因為畢竟大學學的「軟體技術基礎」課程和真正的計算機專業相差太遠，所以我一直以來認為自己起碼在開始的一年中補上，定的計劃是學習完Weiss《數據結構與演算法分析 C++描述》和《演算法導論》一書。
3. 當時剛開始進公司，是分配到網路游戲伺服器小組的，一開始自己就對伺服器方面能開發網路程序抱有興趣，學習網路方面的知識自然也在計劃之中，當時的設想是在Windows方面學習《Win32多線程編程》，Linux方面學習《Unix環境高級編程》，《TCP/IP詳解》第一卷，《Unix網路編程》第一卷的。
以上就是我為自己一年工作後應該學習的東西。。。。。。。。到現在回頭看看，感慨頗多，因為雖然一年期限只剩下2個月了，其實還有太多太多事情沒有做。

計劃的未完成：第1步的書我僅僅只看完了《Effective C++》。。。。因為當時買的都是原版書，所以看完《Effective C++》都是硬著頭皮上的，後來好像總感覺精力不足，沒有勇氣看下去了，或者是自己感覺有更多更重要的事情需要去做，所以就沒有繼續了。
第2步我一直認為很重要，中途的確也開始學習過，就在前段時間，我不僅僅是看Weiss《數據結構與演算法分析 C++描述》一書，並且還附帶同步閱讀侯捷的《STL源碼剖析》一書，最最絕的是，因為剛學完好幾種語言，我當時是嘗試用各種語言去實現書上的演算法和數據結構的。但是學習完了二叉樹部分以後，我的工作轉到了反外掛上面，因為的確比較喜歡這樣底層的工作，所以大部分工作後的時間（本來就不多）都自己去弄匯編去了，數據結構的學習也就中斷了。
第3步，除了《Win32多線程編程》一書我的確是從頭到尾看過了，《Unix環境高級編程》當時是安排在公司利用吃飯的間隙和下午休息時間看的，但是僅僅是看了個開頭，然後我的工作從伺服器組換到了客戶端去了，公司此時伺服器緊張，唯一的一台Linux伺服器也分配給了網路方面去做資料庫去了，我在公司甚至一台可以登陸的Linux伺服器都沒有，所以作罷，當書從公司帶到家裡來後，因為當時家裡也有別的學習計劃，所以中斷了。《TCP/IP詳解》第一卷一書TCP,UDP部分因為剛開始做伺服器時，在總監的指導下（其實就是給我用工作時間來看），大概看過了，《Unix網路編程》第一卷也是出於同樣的原因我看過了利用套接字編寫簡單的TCP，UDP程序部分，其他的後來都沒有看。
總而言之，從計劃的完成角度上來看，我這一年是及其失敗的，因為似乎該看的都沒有看。。。該學的都沒有學。但是回過頭來看，其實計劃一開始指定的時候是我剛剛開始工作，懂得並不多的時候，很多時候我的學習並沒有怠慢，僅僅是因為工作中碰到感覺自己更感興趣，或者是覺得更有作用的知識，所以學習方向有所偏差了。

計劃不如變化：的確後來發生的事情是計劃不如變化了-_-!因為第一個實際的工作並不是和網路有關的，所以剛開始工作時網路知識的學習中斷了，看過我以前的總結的人就會知道，我來公司做的第一個事情就是一個「未控制異常Dump系統」我也不知道該怎麼描述這個工作，也許用英文更能表達，「Error Dump」。在做這個工作的時候總監為了讓我理解SEH，所以拿出他的《Windows核心編程》給我看，看完此章節後，我如獲至寶，感覺此書非讀不可，好書就是好書，哪怕我僅僅是突然讀了12章節，都會覺得欲罷不能，所以，最後我從網上購得此書，完全學過！受益良多！在此推薦一下此書^^

在看此書的這個時候我的第2個工作內容也正如火如荼的進行，基本上那時候在公司我就看《Windows核心編程》在家我就看《Effective C++》，我的第2個工作（不是換公司哦,僅僅是換了內容）是做一個文件系統，一個這么大的東西給我一直當時剛參加工作不到一個月的傢伙，說明公司的確還看的起我，我一直這么認為：）其實這個文件系統的修補及優化一直是貫穿與我這一年的工作的-_-!直到最近還有個莫名奇妙的非必出Bug還沒有解決-_-!

就是在這個工作中我第一次寫概要設計，詳細設計等設計文檔，並開始自己設計並編碼完成一個獨立的模塊，對於這些知識的重要，在現在看來，怎麼評價都不過分，這是我非常非常感謝公司的地方，能夠在一開始就給了我這樣重要的機會，當時還趁著公司的需要，學習了一下軟體工程方面（當時甚至不理解什麼叫需求-_-!）的和UML方面的知識。這些我也是感覺受益良多。對於這么一個比較大的系統，我自己對怎麼編碼才能夠在後期能夠很好的改動維護也慢慢的有了一些想法，特別是對於OO思想的領悟感覺上了一個台階。畢竟我剛開始工作的時候，還談不上任何成型的思想的，僅僅是懂C++語法而已。
接下來的工作很有意思，我得將我在Windows下寫的文件系統移植到Linux下面去，這期間我開始在工作中真正的接觸Linux（以前讀書的時候僅僅是玩Linux，其實牽涉到編程的很少），這期間雖然工作中因為原有的框架很成型，並沒有太多的需要我學習的地方，但是我還是學習了一下Makefile的編寫，g++的使用，並且再一次的用上了Vim，呵呵,當時那樣用Putty登上伺服器編寫的模式，除了Vim我似乎沒有別的選擇。但是此時我還是勉強的適應Vim而已。此時也大概的了解了一下哪些函數可能是MS擴充的，哪些是ISO的，哪些是POSIX的，起碼對於這些概念都有了了解，以後也不至於編寫可移植程序還使用Win32 API的錯誤：）
最最有意思的是，在客戶端弄了這么久，伺服器已經暫時不需要我了，於是我繼續在客戶端方面工作，包括一個游戲TrayIcon功能，外置聊天窗口，這是對於GameUI方面的知識有所了解。然後是為游戲引擎分析並選擇一個最佳的XML解析器，再然後是為游戲底層類創建，添加了一個工廠模式。其實那時也還沒有理解XML到底是什麼用的，為什麼我們游戲需要那麼麻煩速度又不快的配置，那時候也不明白優化的過程中其實使用的是重構的思想，也不明白工廠模式這樣的設計模式到底有什麼功能，僅僅是參考CEGUI的實現硬生生的照搬了一套。但是說實話，不是這次的經歷，在第二次再碰到設計模式相關的知識需要時，我也不會下定決心，最後讀完了一整本原版GOF的《設計模式》一書。。。。
再後來的工作就更有意思了，客戶端總監叫我好好的看看Lua方面的知識，方便為客戶端添加一套腳本系統。這時真是變化太快，這些知識完全脫離了計劃，因為公司能夠讓我用整天整天的工作時間來看書，我無論是上班還是下班都在看書，整整學習完了一本《Programming in LUA》，對於腳本語言的特性理解受益匪淺，對於LUA這樣的為嵌入式而生的腳本語言更加是了解了更多。此時雖然因為公司考慮到因為游戲已經快要完成，此時添加這樣的腳本系統不再合適，所以使用Lua的工作中斷，但是我對腳本語言的興趣並沒有中斷，我接下來不僅沒有放棄LUA的學習，甚至想起來接著學完以前學過又中斷的python，看完了《Python核心編程》一書。學完Python後對於腳本語言的興趣更加是無法收拾了，對於Python語法的優美感嘆不已，庫的豐富更加是五體投地。這也是後來我能夠教女朋友去學Python的原因：）這和當年教她學習C簡直就是兩種體驗-_-!

Python學習告一段落後，也一直沒有使用機會，然後處於對Linux的興趣，我開始獨自摸索，我通過看完一本《Bash高級編程》學習了Bash，這是我學習的第3個腳本語言，但是說實話，感覺Bash是3個裡面最難的，-_-!但是就是對Bash的學習，讓我感覺Linux不再是繁復的操作系統，一切通過Bash來完成，很多時候能夠比圖形界面更加快，更加有效，這是實實在在的進步，因為以前在命令行中老是重復的敲代碼，快煩透了，學了Bash以後我也開始知道什麼叫「懶惰的程序員」了，那就是能夠自動化操作的絕不自己一步一步操作：）再加上學習Lua，Python,Bash時都能統一用到的Vim編輯器，我對Vim的使用已經從勉強沒有辦法的適應到了沒有Vim沒有辦法生存的地步。對於這么一個剛開始復雜到吐血，到用熟了極大的享受的工具，也讓我慢慢有了一些思想，能夠節省我時間的工具，我總是願意去花時間學習，因為無論其多復雜，學習曲線再長，學會了還是受益無窮的！這對於我後來提高工作效率，願意花時間去學習任何看起來能夠對我有幫助的工具起到了決定性的作用！要知道，很久以前的我是語言至上，工具僅僅是工具，沒有什麼技術含量，誰不能學的思想！這個時候我才慢慢領悟到總監所說「工欲善其事必先利其器」的思想！於是我願意花時間去學習Total Command提高我平時管理文件，操作文件的效率，去學習Visual Assist去提高我編碼的效率，去學習AQTime以提高我profile的效率，學習DevPartner以提高開發後Test的效率，學習SoftIce, OllyDbg, IDA Pro去提高我反匯編的效率，這些都和我使用Vim從勉強到離不開的經歷有關！
再到了後來我寫了一個日誌伺服器，用以記錄游戲運行時候的數據，雖然用到了MySQL C API,但是我竟然一直沒有想過好好地去重新學習SQL和MySQL的使用，這是我工作以來的第一次-_-!工作中碰到，然後自己沒有去好好深入學習的東西可能就是資料庫了，包括後來我再次用到了SQL Sever時，我還是沒有深入去學習。
然後開始完成工作中最大規模的系統，游戲伺服器的監控系統，對於一個這樣包含了監視，控制等操作的大型系統，設計來管理公司將來所有運行的伺服器，而此系統幾乎我是一人獨立設計編碼完成的！初期的概要設計階段，由我設計監控點端，由一同事設計監控中心，到了後來，除了監控的前段界面不是我做的，我一人全部包攬其他所有部分的設計及編碼工作。
此工作讓我對於一個系統整體的理解，設計，以編碼實現的思想提高，怎麼評價也不過分。其中最有意思的一個插曲是在監控點一端我用到了狀態機模式，也就是這樣，老總推薦了我一本書去看GOF的《設計模式》，雖然他僅僅是叫我去看看狀態機模式，並完成工作，但是按照本人的工作慣性，最後還是將整本《設計模式》23個設計模式完全看完，呵呵，只可惜，從那以後好像一直沒有再開發一個系統的工作可以做了，所以學到的東西都還在肚子裡面沒有辦法發揮。
再後來通過做一個內存管理模塊，對於號稱C/C++最大的缺陷，內存管理部分有了一定的了解，但是這個工作由於比較倉促，說實話，最後的了解實在有限。但是對於我後來去看《STL源碼剖析》最最前面的內存分配器方面的內容幫助不小，對於此號稱很難的部分理解起來幾乎全無困難。
再到後來，我開始做工具-_-!這是最無聊的工作，雖然是優化，但是我幾乎重做，這里我需要反思，因為我無規模概念的將本來可以短時間內完成的工作用了很長時間才完成，但是我在此時對於優化C++代碼的一些問題慢慢在腦海中形成。並且在這段時間中我按照原有計劃，開始學習數據結構的知識。
再接下來，我更進一步的去優化了原有的文件系統，使得其速度得到了很大的提升，這時候我愛上了AQTime這樣一個工具，就是它使得優化工作從以前的不停插入GetTime代碼，到後來的編碼完成，運行，看數據這樣享受的過程！
再後來，開始做反外掛工作，現在也還在做，但是慢慢的發現老總的想法和自己有所偏差，我一直希望盡量高強度的去預防，而老總卻常常覺得到一定規模就夠了，因為畢竟我們不是專家，花太多時間並不值得。這段時間我將我全部的精力都用在了反匯編上面，看了不少C++的反匯編代碼，結合前段時間看的《Inside C++ Object》一書，理解透了不少東西。正好也學習了一下C/C++中調用匯編代碼和匯編代碼中調用C/C++函數的方法，這些在將來做匯編優化的時候肯定有用。說實話，我很高興我能在工作的初期階段就能進行類似這樣的工作，去了解殼，PE文件結構等知識，這些工作的受益可以是影響一輩子的！和數據結構的知識相比也毫不遜色!我當時的想法我趁此時投入全部精力好好的學習Win32 匯編，但是看起來現在是沒有太多時間了。此事中間有個插曲，為了防止太容易的被人反匯編，我們在整個反外掛系統中加入了一些Python元素，這部分的工作因為我以前學過Python自然的交到了我頭上，而我在額外熟悉了Python C API介面的基礎上，肯定是很快的完成了任務：）這點倒真是戲劇性，工作外的學習，最後也對工作有了幫助。
接下來的目標：第一年就學習的我這么雜的程序員估計不多了，的確太雜了，所以我還是好好的按照原有計劃來，將網路部分好好精通吧，不然感覺和一事無成也差不太遠，雖然就算上述所有的雜項知識都用不上，其實對於我對於一些新API的掌握也比剛開始的速度要快多了，畢竟學的多了：）
網路，這是我剩下兩個月中最最重要的目標。我要在工作滿一年之際，發現我已經可以編寫一般的網路程序，甚至小型高效的網路框架！

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/vagrxie/archive/2009/02/09/3868743.aspx

❽ 黑馬程序員的Python培訓內容有什麼

黑馬程序員

鏈接: https://pan..com/s/1DLZapQQYaVhzQCC5Ek9jDA

若資源有問題歡迎追問~

❾ linux初學者問一個glibc的源代碼。

應該是宏定義吧，因為它不是一個語句，而是直接一行代碼。。另外，你可以閱讀一下。。

sysdeps/unix/make-syscalls.sh
sysdeps/unix/syscalls.list（sysdeps/unix/inet/syscalls.list）
sysdeps/unix/syscall-template.S
syscall-template.S顧名思義是個定義的模板，每個生成的系統調用都要參考這個模板，但是怎麼用模板來「刻畫」每一個系統調用呢？於是就有了syscalls.list，而make-syscalls.sh就是用模板和那個列表來構建生成系統調用定義的makefile，該makefile最終生成最後的定義。有興趣的朋友應該仔細看看這幾個文件。
現在再想想，這么做其實是有道理的，在Linux下，系統調用的真正定義有很多相似的地方，確實可以通過「模板」來生成對應的匯編，但是否真值得花時間去構建那麼抽象的一個模板和框架？我說不清楚，本著「懶惰」的原則確實應該如此，不過看看模板本身似乎原因不僅僅是「懶惰」。
從這里我們也可以看出glibc的代碼難讀啊，比起Linux內核來，不僅僅是風格的問題，還有就是使用了太多的tricks，導致的結果也很顯而易見，參與glibc開發的和參與linux內核開發的人明顯不是一個數量級的。

另外讀glibc 建議 參考 c函數庫 源碼剖析 （一本電子書 網上找一下） 有具體的實現。。

❿ 如何打包安卓手機Zip升級包如何簽名不換Recovery，用官方Recovery

通過分析update.zip包在具體android系統升級的過程，來理解Android系統中Recovery模式服務的工作原理。
我們先從update.zip包的製作開始，然後是Android系統的啟動模式分析，Recovery工作原理，如何從我們上層開始選擇system update到重啟到Recovery服務，以及在Recovery服務中具體怎樣處理update.zip包升級的，我們的安裝腳本updater-script怎樣被解析並執行的等一系列問題。分析過程中所用的Android源碼是gingerbread0919（tcc88xx開發板標配的），測試開發板是tcc88xx。
一、 update.zip包的目錄結構
|----boot.img
|----system/
|----recovery/
`|----recovery-from-boot.p
`|----etc/
`|----install-recovery.sh
|---META-INF/
`|CERT.RSA
`|CERT.SF
`|MANIFEST.MF
`|----com/
`|----google/
`|----android/
`|----update-binary
`|----updater-script
`|----android/
`|----metadata
二、 update.zip包目錄結構詳解
以上是我們用命令make otapackage 製作的update.zip包的標准目錄結構。
1、boot.img是更新boot分區所需要的文件。這個boot.img主要包括kernel+ramdisk。
2、system/目錄的內容在升級後會放在系統的system分區。主要用來更新系統的一些應用或則應用會用到的一些庫等等。可以將Android源碼編譯out/target/proct/tcc8800/system/中的所有文件拷貝到這個目錄來代替。
3、recovery/目錄中的recovery-from-boot.p是boot.img和recovery.img的補丁(patch),主要用來更新recovery分區，其中etc/目錄下的install-recovery.sh是更新腳本。
4、update-binary是一個二進制文件，相當於一個腳本解釋器，能夠識別updater-script中描述的操作。該文件在Android源碼編譯後out/target/proct/tcc8800/system bin/updater生成，可將updater重命名為update-binary得到。
該文件在具體的更新包中的名字由源碼中bootable/recovery/install.c中的宏ASSUMED_UPDATE_BINARY_NAME的值而定。
5、updater-script：此文件是一個腳本文件，具體描述了更新過程。我們可以根據具體情況編寫該腳本來適應我們的具體需求。該文件的命名由源碼中bootable/recovery/updater/updater.c文件中的宏SCRIPT_NAME的值而定。
6、 metadata文件是描述設備信息及環境變數的元數據。主要包括一些編譯選項，簽名公鑰，時間戳以及設備型號等。
7、我們還可以在包中添加userdata目錄，來更新系統中的用戶數據部分。這部分內容在更新後會存放在系統的/data目錄下。
8、update.zip包的簽名：update.zip更新包在製作完成後需要對其簽名，否則在升級時會出現認證失敗的錯誤提示。而且簽名要使用和目標板一致的加密公鑰。加密公鑰及加密需要的三個文件在Android源碼編譯後生成的具體路徑為：
out/host/linux-x86/framework/signapk.jar
build/target/proct/security/testkey.x509.pem
build/target/proct/security/testkey.pk8 。
我們用命令make otapackage製作生成的update.zip包是已簽過名的，如果自己做update.zip包時必須手動對其簽名。
具體的加密方法：$ java –jar gingerbread/out/host/linux/framework/signapk.jar –w gingerbread/build/target/proct/security/testkey.x509.pem gingerbread/build/target/proct/security/testkey.pk8 update.zip update_signed.zip
以上命令在update.zip包所在的路徑下執行，其中signapk.jar testkey.x509.pem以及testkey.pk8文件的引用使用絕對路徑。update.zip 是我們已經打好的包，update_signed.zip包是命令執行完生成的已經簽過名的包。
9、MANIFEST.MF：這個manifest文件定義了與包的組成結構相關的數據。類似Android應用的mainfest.xml文件。
10、CERT.RSA：與簽名文件相關聯的簽名程序塊文件，它存儲了用於簽名JAR文件的公共簽名。
11、CERT.SF：這是JAR文件的簽名文件，其中前綴CERT代表簽名者。
另外，在具體升級時，對update.zip包檢查時大致會分三步：①檢驗SF文件與RSA文件是否匹配。②檢驗MANIFEST.MF與簽名文件中的digest是否一致。③檢驗包中的文件與MANIFEST中所描述的是否一致。
三、 Android升級包update.zip的生成過程分析
1) 對於update.zip包的製作有兩種方式，即手動製作和命令生成。
第一種手動製作：即按照update.zip的目錄結構手動創建我們需要的目錄。然後將對應的文件拷貝到相應的目錄下，比如我們向系統中新加一個應用程序。可以將新增的應用拷貝到我們新建的update/system/app/下（system目錄是事先拷貝編譯源碼後生成的system目錄），打包並簽名後，拷貝到SD卡就可以使用了。這種方式在實際的tcc8800開發板中未測試成功。簽名部分未通過，可能與具體的開發板相關。
第二種製作方式：命令製作。Android源碼系統中為我們提供了製作update.zip刷機包的命令，即make otapackage。該命令在編譯源碼完成後並在源碼根目錄下執行。 具體操作方式：在源碼根目錄下執行
①$ . build/envsetup.sh。
②$ lunch 然後選擇你需要的配置(如17)。
③$ make otapackage。
在編譯完源碼後最好再執行一遍上面的①、②步防止執行③時出現未找到對應規則的錯誤提示。命令執行完成後生成的升級包所在位置在out/target/proct/full_tcc8800_evm_target_files-eng.mumu.20120309.111059.zip將這個包重新命名為update.zip，並拷貝到SD卡中即可使用。
這種方式(即完全升級)在tcc8800開發板中已測試成功。
2) 使用make otapackage命令生成update.zip的過程分析。
在源碼根目錄下執行make otapackage命令生成update.zip包主要分為兩步，第一步是根據Makefile執行編譯生成一個update原包（zip格式）。第二步是運行一個python腳本，並以上一步准備的zip包作為輸入，最終生成我們需要的升級包。下面進一步分析這兩個過程。
第一步：編譯Makefile。對應的Makefile文件所在位置：build/core/Makefile。從該文件的884行（tcc8800,gingerbread0919）開始會生成一個zip包，這個包最後會用來製作OTA package 或者filesystem image。先將這部分的對應的Makefile貼出來如下：

[python] view plainprint?
# -----------------------------------------------------------------
# A zip of the directories that map to the target filesystem.
# This zip can be used to create an OTA package or filesystem image
# as a post-build step.
#
根據上面的Makefile可以分析這個包的生成過程：
首先創建一個root_zip根目錄，並依次在此目錄下創建所需要的如下其他目錄
①創建RECOVERY目錄，並填充該目錄的內容，包括kernel的鏡像和recovery根文件系統的鏡像。此目錄最終用於生成recovery.img。
②創建並填充BOOT目錄。包含kernel和cmdline以及pagesize大小等，該目錄最終用來生成boot.img。
③向SYSTEM目錄填充system image。
④向DATA填充data image。
⑤用於生成OTA package包所需要的額外的內容。主要包括一些bin命令。
⑥創建META目錄並向該目錄下添加一些文本文件，如apkcerts.txt(描述apk文件用到的認證證書)，misc_info.txt(描述Flash內存的塊大小以及boot、recovery、system、userdata等分區的大小信息)。
⑦使用保留連接選項壓縮我們在上面獲得的root_zip目錄。
⑧使用fs_config(build/tools/fs_config)配置上面的zip包內所有的系統文件(system/下各目錄、文件)的許可權屬主等信息。fs_config包含了一個頭文件#include「private/android_filesystem_config.h」。在這個頭文件中以硬編碼的方式設定了system目錄下各文件的許可權、屬主。執行完配置後會將配置後的信息以文本方式輸出 到META/filesystem_config.txt中。並再一次zip壓縮成我們最終需要的原始包。
第二步：上面的zip包只是一個編譯過程中生成的原始包。這個原始zip包在實際的編譯過程中有兩個作用，一是用來生成OTA update升級包，二是用來生成系統鏡像。在編譯過程中若生成OTA update升級包時會調用（具體位置在Makefile的1037行到1058行）一個名為ota_from_target_files的python腳本，位置在/build/tools/releasetools/ota_from_target_files。這個腳本的作用是以第一步生成的zip原始包作為輸入，最終生成可用的OTA升級zip包。
二 下面我們分析ota_from_target_files這個python腳本是怎樣生成最終zip包的。先講這個腳本的代碼貼出來如下：
[python] view plainprint?
import sys
if sys.hexversion < 0x02040000:
print >> sys.stderr, "Python 2.4 or newer is required."
sys.exit(1)
主函數main是python的入口函數，我們從main函數開始看，大概看一下main函數（腳本最後）里的流程就能知道腳本的執行過程了。
① 在main函數的開頭，首先將用戶設定的option選項存入OPTIONS變數中，它是一個python中的類。緊接著判斷有沒有額外的腳本，如果有就讀入到OPTIONS變數中。
② 解壓縮輸入的zip包，即我們在上文生成的原始zip包。然後判斷是否用到device-specific extensions（設備擴展）如果用到，隨即讀入到OPTIONS變數中。
③ 判斷是否簽名，然後判斷是否有新內容的增量源，有的話就解壓該增量源包放入一個臨時變數中（source_zip）。自此，所有的准備工作已完畢，隨即會調用該 腳本中最主要的函數WriteFullOTAPackage(input_zip,output_zip)
④ WriteFullOTAPackage函數的處理過程是先獲得腳本的生成器。默認格式是edify。然後獲得metadata元數據，此數據來至於Android的一些環境變數。然後獲得設備配置參數比如api函數的版本。然後判斷是否忽略時間戳。
⑤ WriteFullOTAPackage函數做完准備工作後就開始生成升級用的腳本文件(updater-script)了。生成腳本文件後將上一步獲得的metadata元數據寫入到輸出包out_zip。
⑥至此一個完整的update.zip升級包就生成了。生成位置在：out/target/proct/tcc8800/full_tcc8800_evm-ota-eng.mumu.20120315.155326.zip。將升級包拷貝到SD卡中就可以用來升級了。
四、 Android OTA增量包update.zip的生成
在上面的過程中生成的update.zip升級包是全部系統的升級包。大小有80M多。這對手機用戶來說，用來升級的流量是很大的。而且在實際升級中，我們只希望能夠升級我們改變的那部分內容。這就需要使用增量包來升級。生成增量包的過程也需要上文中提到的ota_from_target_files.py的參與。
下面是製作update.zip增量包的過程。
① 在源碼根目錄下依次執行下列命令
$ . build/envsetup.sh
$ lunch 選擇17
$ make
$ make otapackage
執行上面的命令後會在out/target/proct/tcc8800/下生成我們第一個系統升級包。我們先將其命名為A.zip
② 在源碼中修改我們需要改變的部分，比如修改內核配置，增加新的驅動等等。修改後再一次執行上面的命令。就會生成第二個我們修改後生成的update.zip升級包。將 其命名為B.zip。
③ 在上文中我們看了ota_from_target_files.py腳本的使用幫助，其中選項-i就是用來生成差分增量包的。使用方法是以上面的A.zip 和B.zip包作為輸入，以update.zip包作 為輸出。生成的update.zip就是我們最後需要的增量包。
具體使用方式是：將上述兩個包拷貝到源碼根目錄下，然後執行下面的命令。
$ ./build/tools/releasetools/ota_from_target_files -i A.zip B.zip update.zip。
在執行上述命令時會出現未找到recovery_api_version的錯誤。原因是在執行上面的腳本時如果使用選項i則會調用WriteIncrementalOTAPackage會從A包和B包中的META目錄下搜索misc_info.txt來讀取recovery_api_version的值。但是在執行make otapackage命令時生成的update.zip包中沒有這個目錄更沒有這個文檔。
此時我們就需要使用執行make otapackage生成的原始的zip包。這個包的位置在out/target/proct/tcc8800/obj/PACKAGING/target_files_intermediates/目錄下，它是在用命令make otapackage之後的中間生產物，是最原始的升級包。我們將兩次編譯的生成的包分別重命名為A.zip和B.zip，並拷貝到SD卡根目錄下重復執行上面的命令：
$ ./build/tools/releasetools/ota_form_target_files -i A.zip B.zip update.zip。
在上述命令即將執行完畢時，在device/telechips/common/releasetools.py會調用IncrementalOTA_InstallEnd,在這個函數中讀取包中的RADIO/bootloader.img。
而包中是沒有這個目錄和bootloader.img的。所以執行失敗，未能生成對應的update.zip。可能與我們未修改bootloader（升級firmware）有關。此問題在下一篇博客已經解決。
製作增量包失敗的原因，以及解決方案。

Android系統Recovery工作原理之使用update.zip升級過程分析（二）---update.zip差分包問題的解決
在上一篇末尾提到的生成差分包時出現的問題，現已解決，由於最近比較忙，相隔的時間也比較長，所以單列一個篇幅提示大家。這個問題居然是源碼中的問題，可能你已經製作成功了，不過我的這個問題確實是源碼中的一個問題，不知道是不是一個bug，下文會具體分析！
一、生成OTA增量包失敗的解決方案
在上一篇中末尾使用ota_from_target_files腳本製作update.zip增量包時失敗，我們先將出現的錯誤貼出來。
在執行這個腳本的最後讀取input_zip中RADIO/bootloader.img時出現錯誤，顯示DeviceSpecifiParams這個對象中沒有input_zip屬性。
我們先從腳本中出現錯誤的調用函數中開始查找。出現錯誤的調用地方是在函WriteIncrementalOTAPackage（443行）中的device_specific.IncrementalOTA_InstallEnd()，其位於WriteIncrementalOTAPackage()中的末尾。進一步跟蹤源碼發現，這是一個回調函數，他的具體執行方法位於源碼中/device/telechips/common/releasetools.py腳本中的IncrementalOTA_InstallEnd()函數。下面就分析這個函數的作用。
releasetools.py腳本中的兩個函數FullOTA_InstallEnd()和IncrementalOTA_InstallEnd()的作用都是從輸入包中讀取RADIO/下的bootloader.img文件寫到輸出包中，同時生成安裝bootloader.img時執行腳本的那部分命令。只不過一個是直接將輸入包中的bootloader.img鏡像寫到輸出包中，一個是先比較target_zip和source_zip中的bootloader.img是否不同（使用選項-i生成差分包時），然後將新的鏡像寫入輸出包中。下面先將這個函數(位於/device/telechips/common/releasetools.py)的具體實現貼出來：
我們的實際情況是，在用命令make otapackage時生成的包中是沒有這個RADIO目錄下的bootloader.img鏡像文件（因為這部分更新已被屏蔽掉了）。但是這個函數中對於從包中未讀取到bootloader.img文件的情況是有錯誤處理的，即返回。所以我們要從 出現的實際錯誤中尋找問題的原由。
真正出現錯誤的地方是：
target_bootloader=info.input_zip.read(「RADIO/bootloader.img」)。
出現錯誤的原因是：AttributeError：『DeviceSpecificParams』object has no attribute 『input_zip』，提示我們DeviceSpecificParams對象沒有input_zip這個屬性。
二、updater-script腳本執行流程分析：
先看一下在測試過程中用命令make otapackage生成的升級腳本如下：
[python] view plainprint?
assert(!less_than_int(1331176658, getprop("ro.build.date.utc")));
assert(getprop("ro.proct.device") == "tcc8800" ||
下面分析下這個腳本的執行過程：
①比較時間戳：如果升級包較舊則終止腳本的執行。
②匹配設備信息：如果和當前的設備信息不一致，則停止腳本的執行。
③顯示進度條：如果以上兩步匹配則開始顯示升級進度條。
④格式化system分區並掛載。
⑤提取包中的recovery以及system目錄下的內容到系統的/system下。
⑥為/system/bin/下的命令文件建立符號連接。
⑦設置/system/下目錄以及文件的屬性。
⑧將包中的boot.img提取到/tmp/boot.img。
⑨將/tmp/boot.img鏡像文件寫入到boot分區。
⑩完成後卸載/system。
三、總結
以上的九篇著重分析了Android系統中Recovery模式中的一種，即我們做好的update.zip包在系統更新時所走過的流程。其核心部分就是Recovery服務的工作原理。其他兩種FACTORY RESET、ENCRYPTED FILE SYSTEM ENABLE/DISABLE與OTA INSTALL是相通的。重點是要理解Recovery服務的工作原理。另外詳細分析其升級過程，對於我們在實際升級時，可以根據我們的需要做出相應的修改。