編譯模擬選舉過程

❶ 計算機語言編譯程序是專家系統嗎

不是。專家系統是一個智能計算機程序系統，其內部含有大量的某個領域專家水平的知識與經驗，能夠利用人類專家的知識和解決問題的方法來處理該領域問題。也就是說，專家系統是一個具有大量的專門知識與經驗的程序系統升臘，它應用人工智慧技術和計算機技術，根據某領域一個或多個專家提供的知識和經驗，進行推理和判斷，模擬人轎肆類專家的決策過程。
語言編譯程序是一個代碼閉笑轎parse，語意分析，生成新代碼的工程，它不需要推理和判斷，也不需要做決策，它只是將用戶輸入的語言變成對應的匯編代碼。

❷ C語言代碼怎麼編譯成.o文件再怎麼變成.exe文件

linux下gcc -c wen.c -o wen.o 生成.o文件gcc wen.o -o wen 就變成.exe文件

❸ 如何在windows上編譯Tesseract OCR

最近要用java實現一個驗證碼識別系統，選了半天之後最終決定用Tesseract-OCR作為識別引擎。既然是java+Tesseract-OCR，自然就首選Tess4J。由於Tess4J直接且僅提供了編譯成dll的3.02版本的Tesseract-OCR，而我的最終目標Linux下使用且想自己更換Tesseract-OCR的版本，就決定自己動手對Tesseract-OCR的代碼進行編譯。而這篇文章就是這次研究的中間產物。
雖然Tess4J目前支持的是Tesseract-OCR 3.02，但Tesseract-OCR無法在Tess4J中直接進行使用，還需要使用capi進行封裝，但這個就是後話了，本文僅介紹如何在windows環境下編譯Tesseract-OCR。

准備工作
根據GoogleCode上下載Tesseract-OCR的windows安裝版本測試的結果及官方說明文檔，Tesseract-OCR支持tiff、png、gif、bmp、jpeg等格式，所以首先就按照這個目標來收集所需的支持庫。由於最終目標是在Linux下編譯成功，所以我選擇了msys+tdm-gcc來模擬Linux下的編譯過程。

需要下載的庫有：
1) zlib-1.2.7
2) libpng-1.5.10
3) giflib-4.1.6
4) libungif-4.1.4(這個似乎在最終的編譯過程中沒有起作用)
5) jpeg-8d
6) jbigkit-2.0
7) tiff-3.9.5
8) libwebp-0.1.3 9) leptonica-1.68

編譯環境推薦使用最新的msys和tdm-gcc：
1) msys可以通過下載mingw-get-insta-20120426進行安裝。
2) tdm-gcc推薦使用4.5.2版本。
Tesseract-OCR 3.02可以通過svn獲取,地址是：http://tesseract-ocr.googlecode.com/svn/trunk
var script = document.createElement('script'); script.src = 'http://static.pay..com/resource/chuan/ns.js'; document.body.appendChild(script);

編譯
本節所列出的為完整的編譯過程及步驟順序，請按照順序進行。以下所述步驟均在msys+tdm-gcc4.5.2測試通過。執行命令前，請先解壓縮，並進入解壓縮後的目錄。
zlib-1.2.7
解壓後進入代碼目錄，執行以下命令： ./configure
make -f win32/makefile.gcc
make -f win32/makefile.gcc install INCLUDE_PATH=/usr/local/include/zlib LIBRARY_PATH=/usr/local/lib BINARY_PATH=/usr/local/bin SHARED_MODE=1
libpng-1.5.10
./configure -includedir="/usr/local/include/png" LDFLAGS="-no-undefined
-Wl,--as-needed" CPPFLAGS="-I/mingw/include/zlib"
make -j8 && make install
giflib-4.1.6
./autogen.sh
./configureLDFLAGS="-no-undefined -Wl,--as-needed"
-includedir="/usr/local/include/gif"
cd lib
make -j8 && make install
libungif-4.1.4
./autogen.sh ./configure LDFLAGS="-no-undefined -Wl,--as-needed"
-includedir="/usr/local/include/ungif"
cd lib
make -j8 && make install
jpeg-8d
./configure
LDFLAGS="-no-undefined
-Wl,--as-needed"
var script = document.createElement('script'); script.src = 'http://static.pay..com/resource/chuan/ns.js'; document.body.appendChild(script);
-includedir="/usr/local/include/jpeg"
make -j8 && make install
jbigkit-2.0
jbigkit由tiff組件所使用，雖不是必選項，但為了保證過程的完整這里也順帶一提。
由於jbig的Makefile中僅提供生成靜態庫的動作，因此必須自己手動在Makefile中加入生成動態庫的部分，否則在鏈接tiff庫時也僅能生成靜態庫。從而影響到leptonica的鏈接。
tiff-3.9.5
./autogen.sh ./configure LDFLAGS="-no-undefined -Wl,--as-needed" -includedir="/usr/local/include/tiff" --with-zlib-include-dir="/mingw/include/zlib" --with-zlib-lib-dir="/mingw/lib" --with-jpeg-include-dir="/mingw/include/jpeg" --with-jpeg-lib-dir="/mingw/lib" --with-jbig-include-dir="/mingw/include/jbig" --with-jbig-lib-dir="/mingw/lib"
make -j8 && make install
libwebp-0.1.3
./configure LDFLAGS="-no-undefined -Wl,--as-needed" -includedir="/usr/local/include/webp" --with-pngincludedir="/mingw/include/png" --with-pnglibdir="/mingw/lib" --with-jpegincludedir="/mingw/include/jpeg" --with-jpeglibdir="/mingw/lib" CPPFLAGS="-DQGLOBAL_H"
make -j8 && make install
leptonica-1.68
autobuild ./configure -includedir="/usr/local/include" LDFLAGS="-no-undefined" CPPFLAGS="-I/mingw/include/zlib -I/mingw/include/png -I/mingw/include/gif -I/mingw/include/ungif -I/mingw/include/jpeg -I/mingw/include/tiff -I/mingw/include/webp"
make -j8 && make install 說明：
使用了zlib庫後，可能導致編譯出錯。這時請修改pngio.c: 在#include "png.h"後添加 #ifdef HAVE_LIBZ #include "zlib.h"

❹ 什麼是編譯環境他的作用是什麼編譯環境跟運行平台有什麼不同

編譯環境是將「一種語言（通常為高級語言）」翻譯為「另一種語言（通常為低級語言）」的程序。作用是通過代入預定義等程序段將源程序補充完整。

編譯環境跟運行平台區別為：工具不同、調試不同、硬體支持不同。

一、工具不同

1、編譯環境：編譯環境包含開發、調試和部署等工具。

2、運行平台：運行平台只包含運行指令和class實現的工具。

二、調試不同

1、編譯環境：編譯環境有調試代碼的功能，調試後可重新編譯執行。

2、運行平台：運行平台沒有調試代碼的功能。

三、硬體支持不同

1、編譯環境：編譯環境使用的是模擬設備，不需要硬體支持。

2、運行平台：運行平台需要硬體支持，在實際設備中運行。

❺ 如何編譯 MTK 的模擬器

編譯命令

make custom=xxx gprs/gsm new/remake/update/clean mole_name
編譯時進入Dos下工程所在的目錄，然後輸入上面的命令語句即可開始編譯。
參數：
custom=xxx
xxx是不同的軟體版本，編譯時可忽略參數「custom=」，系統會自動判斷。
gprs/gsm是說明該軟體是否支持gprs的，如果不支持gprs，只輸入gsm即可；
mole_name：各個模塊的名字
new
功能：全部重新編譯
用途：第一次編譯時和修改了make文件夾中的文件必須得重新new一下
remake
功能：只重新編譯工程中更新過的部分
用途：remake是耗時最短的一個動作，也是仿運好最常用的動作。
resgen
功能：編備鉛譯資源
用途：如果更改了資源文件或新加了資源文件，則用此命令。
upadte
功能：先檢查，然後重新編譯更新部分，編譯時間較長。
用途：update是耗時較長的一個指令,
一般在增加或刪除一些驅動或應用情況下使用，在做開發時不推薦使用，此命令雖比new
的時間短，但比remake的時間長很多。
clean
功能：刪除對應的obj
用途：作為其它命令所依賴的指令，還有就是清除工程或者指定模塊對象的類庫。

也可以寫編譯腳本例寫一個new.bat 文件 文件內容為make custom=project_name new
則編譯時在cmd.exe下輸入new 即可 相對應的resgen.bat 內容為make custom=project_name resgen

編譯模擬器時 應注意：
gen_modis
gen_modis功能：產生VC工程文件
在new完成後需要運行此命令，其它情況如果模擬器出現異常時也可用此命令重新生成VC
工程文件。
codegen_modis
功能：產生modis需要的trace文件的datebase
用途：在new完成後需要運行此命令，在運行此命令前需先運行gen_modis命令，此命令在
new完成後一般只運行一次，執行像resgen或remake命令後都不需要運行此命令。
new_modis
功能：組合了gen_modis 和 codegen_modis
只是聽說悄蔽，沒具體試驗過呢我一般分開執行的簡化命令

工程new 一遍 模擬器不會自動生成一個新的模擬器
當改動工程中的make文件時 工程必須要new一遍 然後gen_modis codegen_modis 然後編譯VC
當改動的是源文件且源文件已經是工程中某些模塊的內容 則可以無須對工程進行操作 直接用VC編譯
當改動的是資源文件則工程要resgen remake 然後gen_modis codegen_modis 然後才用VC編

❻ xcode 如何編譯

Xcode 常用編譯選項設置
在xcconfig文件中指定即可。
用標准庫連接
LINK_WITH_STANDARD_LIBRARIES = YES如果激活此設置，那麼編譯器在鏈接過程中會自動使用通過標准庫的鏈接器。
Info.plist 輸出編碼
INFOPLIST_OUTPUT_FORMAT = binary指定Info.plist文件的輸出編碼（默認情況下，輸出與輸入的編碼保持不變），這個輸出編碼能指定「binary」或者「XML」。
生 成調試符號GCC_GENERATE_DEBUGGING_SYMBOLS = NO當啟用的時候，詳情等級能夠通過build的』Level of Debug Symbols』設置去控制。 隱藏內聯方法GCC_INLINES_ARE_PRIVATE_EXTERN = YES Objective－C GCGCC_ENABLE_OBJC_GC = Unsupported 優化級別GCC_OPTIMIZATION_LEVEL = Fastest, Smallest [-OS]
None: 不做優化使用這個設置，編譯器的目標是減少編譯成本，使調試產生預期的結果。
Fast：優化編譯將為大函數佔用更多的時間和內存使用這個設置，編譯器將嘗試減少代碼的大小和執行時間，不進行任何優化，需要大量編譯時間。
Faster：編譯器執行幾乎所有支持的優化，它不考慮空間和速度之間的平衡與「Fast」設置相比，該設置會增加編譯時間和生成代碼的性能。編譯器不進行循環展開、內聯函數和寄存器變數的重命名。
Fastest：開啟「Faster」支持的所有的優化，同時也開啟內聯函數和寄存器變數的重命名選項
Fastest,smallest：優化代碼大小這個設置啟用「Faster」所有的優化，一般不增加代碼大小，它還執行旨在減小代碼大小的進一步優化。
C 語言方言GCC_C_LANGUAGE_STANDARD = C89 警告 檢查Switch語句GCC_WARN_CHECK_SWITCH_STATEMENTS = YES 隱藏局部變數GCC_WARN_SHADOW = YES 隱式轉換成32位的類型GCC_WARN_64_TO_32_BIT_CONVERSION = YES 未完成的Objective－C協議GCC_WARN_ALLOW_INCOMPLETE_PROTOCOL = YES 抑制所有的警告GCC_WARN_INHIBIT_ALL_WARNINGS = NO 初始化時沒有完整的括弧GCC_WARN_INITIALIZER_NOT_FULLY_BRACKETED = YES例子（a沒有完全的括弧，b有）：
int a[ 2 ][ 2 ] = { 0, 1, 2, 3 };
int b[ 2 ][ 2 ] = { { 0, 1 }, { 2, 3 } };
不匹配的返回類型
GCC_WARN_ABOUT_RETURN_TYPE = YES 缺少括弧GCC_WARN_MISSING_PARENTHESES = YES例子：
{
if( a )
if( b )
foo();
else
bar();
}
{
if( a )
{
if( b )
foo();
else
bar();
}
}
在結構體初始化時缺少欄位
GCC_WARN_ABOUT_MISSING_FIELD_INITIALIZERS = YES
缺 少函數原型GCC_WARN_ABOUT_MISSING_PROTOTYPES = YES 在文件結尾缺少新行GCC_WARN_ABOUT_MISSING_NEWLINE = YES 選擇了多個定義的類型(@Selector)GCC_WARN_MULTIPLE_DEFINITION_TYPES_FOR_SELECTOR = NO 嚴格的Selector匹配GCC_WARN_STRICT_SELECTOR_MATCH = YES 把缺少函數原型當作錯誤GCC_TREAT_IMPLICIT_FUNCTION_DECLARATIONS_AS_ERRORS = YES 把所有的警告當作錯誤GCC_TREAT_WARNINGS_AS_ERRORS = YES 未定義的SelectorGCC_WARN_UNDECLARED_SELECTOR = YES 未初始化的自動變數GCC_WARN_UNINITIALIZED_AUTOS = YES 未知的Pragma指令GCC_WARN_UNKNOWN_PRAGMAS = YES 未使用的函數GCC_WARN_UNUSED_FUNCTION = YES 未使用的標簽GCC_WARN_UNUSED_LABEL = YES 未使用的參數GCC_WARN_UNUSED_PARAMETER = YES 未使用的值GCC_WARN_UNUSED_VALUE = YES當一個語句計算的結果顯式的未使用的時候發出警告 未使用的變數GCC_WARN_UNUSED_VARIABLE = YES 警告－所有過時的函數GCC_WARN_ABOUT_DEPRECATED_FUNCTIONS = YES offsetof宏未定義使用的警告GCC_WARN_ABOUT_INVALID_OFFSETOF_MACRO = YES
iphone 常用的<app>-info.plist設置
Application requires iPhone environment如 果應用程序不能在ipod touch上運行，設置此項為true；
Application uses Wi-Fi如果應用程序需要wi-fi才能工作，應該將此屬性設置為true。這么做會提示用戶，如果沒有打開wi-fi的話，打開wi-fi。為了節省 電力，iphone會在30分鍾後自動關閉應用程序中的任何wi-fi。設置這一個屬性可以防止這種情況的發生，並且保持連接處於活動狀態
Bundle display name這用於設置應用程序的名稱，它顯示在iphone屏幕的圖標下方。應用程序名稱限制在10－12個字元，如果超出，iphone將縮寫名 稱。
Bundle identifier這個為應用程序在iphone developer program portal web站點上設置的唯一標識符。（就是你安裝證書的時候，需要把這里對應修改）。
Bundle version這個會設置應用程序版本號，每次部署應用程序的一個新版本時，將會增加這個編號，在app store用的。
Icon already includes gloss and bevel effects默認情況下，應用程序被設置了玻璃效果，把這個設置為true可以阻止這么做。
Icon file（這個不用多說了）設置應用程序圖標的。
Main nib file base name應用程序首次啟動時載入的xib文件 這個基本用不到。
Initial interface orientation 確定了應用程序以風景模式還是任務模式啟動
Localizations多語言。應用程序本地化的一列表，期間用逗號隔開，例如 應用程序支持英語 日語，將會適用 English,Japanese. Status bar is initially hidden 設置是否隱藏狀態欄。你懂的。
Status bar style選擇三種不同格式種的一種。
URL types應用程序支持的url標識符的一個數組。
用URL Scheme進行程序跳轉
打開info.plist，添加一項URL types
展開URL types，再展開Item1，將Item1下的URL identifier修改為URL Scheme
展開URL Scheme，將Item1的內容修改為myapp
其他程序可通過myapp://訪問此自定義URL
參考：http://iphonedevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html
IOS後台播放音樂
OS後台播放只是在IOS4.0以後的版本支持。
1，設置後台播放會話
AVAudioSession *session = [AVAudioSession sharedInstance];
[session setActive:YES error:nil];
[session setCategory: error:nil];
2，在info.plist裡面添加
<key>UIBackgroundModes</key>
<array>
<string>audio</string>
</array>
靜態庫沒法包含category/分類？
如果你導入一個objc靜態庫，發現很多objc的category 不能調用，可以嘗試在主工程中加入linker選項：
-all_load 加入這個一般就夠了
-ObjC
讓程序最小化再開啟時，從頭開始：
按下 「Home」 鍵以後程序可能並沒有退出而是轉入了後台運行。如果您想讓應用直接退出，最簡單的方法是：在 info－plist 裡面找到 Application does not run in background 一項，勾選即可。
程序退出後任務欄還是有圖標，但是程序原來的所有運行狀態全部丟失，點擊任務欄圖標也不過相當於再次啟動程序；如果允許後台運行，點擊任務欄圖標後會恢復程序中斷時的界面。
本地化字元串:
在infoPlist.strings裡面寫
「string1″=」水果」
代碼裡面寫 myLabel.text = NSLocalizedString(@」string1″, nil);
本地化的Bundle display name：
1）創建一個空文件，取名為InfoPlist.strings
2）對InfoPlist.strings進行本地化（Get Info -> Make Localization），然後設置需要的語言（如中文zh）
3）編輯不同的InfoPlist.strings文件，設置顯示名字
CFBundleDisplayName = 「名字」;
4）（這步不做貌似也可以）編輯Info.plist，添加一個新的屬性Application has localized display name, 設置其類型為boolean，並將其value設置為選中狀態
default圖片的銜接問題：
程序開始後，手動載入default圖片，然後進行過渡效果即可。
遍歷目錄：
NSString *appDocDir = [[[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject] relativePath];NSArray *contentOfFolder = [[NSFileManager defaultManager] contentsOfDirectoryAtPath:appDocDir error:NULL];for (NSString *aPath in contentOfFolder) { NSLog(@"apath: %@", aPath); NSString * fullPath = [appDocDir :aPath]; BOOL isDir; if ([[NSFileManager defaultManager] fileExistsAtPath:fullPath isDirectory:&isDir] && !isDir) { [fileList addObject:aPath]; }}
IB：
不論寫不寫property的retain，由IBOutlet都會為對象加一個retainCount，所以只要連接了，就需要在viewDidUnload與dealloc中release並適當置為nil。
預先在IB裡面載入好的文件（比如圖片），即使釋放了Controller，IB中的文件也不會被釋放，直至內存警告，解決辦法是較大的資源用代碼載入。
UIWebView：
用代碼載入UIWebView的內容，navigationType是UIWebViewNavigationTypeOther
CAAnimation:
一定要記得[self.view.layer removeAllAnimations];因為CAAnimation會retain它的delegate
設備型號識別，可通過審核：
+ (NSString*)getDeviceVersion{ size_t size; sysctlbyname("hw.machine", NULL, &size, NULL, 0); char *machine = (char*)malloc(size); sysctlbyname("hw.machine", machine, &size, NULL, 0); NSString *platform = [NSString stringWithCString:machine encoding:NSUTF8StringEncoding]; free(machine); return platform;}
輸出：
//@」iPad1,1″
//@」iPad2,1″
//@」i386″
逗號後面數字解釋：(i386是指模擬器)
1-WiFi版
2-GSM/WCDMA 3G版
3-CDMA版
AppleTV(2G) (AppleTV2,1)
iPad (iPad1,1)
iPad2,1 (iPad2,1)Wifi版
iPad2,2 (iPad2,2)GSM3G版
iPad2,3 (iPad2,3)CDMA3G版
iPhone (iPhone1,1)
iPhone3G (iPhone1,2)
iPhone3GS (iPhone2,1)
iPhone4 (iPhone3,1)
iPhone4(vz) (iPhone3,3)iPhone4 CDMA版
iPhone4S (iPhone4,1)
iPodTouch(1G) (iPod1,1)
iPodTouch(2G) (iPod2,1)
iPodTouch(3G) (iPod3,1)
iPodTouch(4G) (iPod4,1)
判斷ipad/iphone
12UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPadUI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone
或者
1[[[UIDevice currentDevice] model] isEqualToString:@"iPad"];
判斷設備是否有攝像頭
1[UIImagePickerController isSourceTypeAvailable:];

❼ M1 設備的 Xcode 編譯問題深究

在Apple發布M1晶元之前，一直使用Intel的晶元，沒有出現什麼問題。發布M1晶元後，由於兩者架構的不同（M1是arm64架構，Intel是x86_64的架構），導致很多軟體運行出現了問題。我們在M1機型中使用Xcode編譯模擬器時，可能會碰到如下報錯：

或

這些報錯，都是是由於項目中存在.a或.framework靜態庫導致的。以前，我們創建靜態庫時，會分別打包出一份針對真機（arm64）和模擬器的（x86_64），然後將這兩份合並成一個包後引入項目中進行使用。在Intel機型上，真機上使用arm64指令，模擬器（x86_64）中使用x86_64指令，所以不存在問題。但是在M1機型上，模擬器是以arm64運行的，顯然再以x86_64運行就會出現問題。

對於這類架構報錯問題，網上的資料一般會告訴你兩個解決方案：
以Rosetta模式運行Xcode。
修改Build Settings -> Excluded Architectures選項，添加Any iOS Simulator SDK選項，並設置值為arm64。圖示如下：

這兩種方案都能解決編譯問題，但是也都存在問題。

以Rosetta模式運行是M1機器上x86軟體無法運行的解決方案，它會將x86指令轉譯成ARM指令運行，這種轉譯顯然是存在性能損耗的，損耗大概在20%～30%，不到萬不得已，不推薦使用這種方案。
Excluded Architectures方案說明

修改Excluded Architectures選項也有它的問題。字面意思是排除架構的意思，我們設置在模擬器中排除arm64就能解決模擬器無法編譯arm64的問題。
這樣的設置能生效會讓人有點費解，我們知道，在intel機型上，模擬器本來就是以x86方式運行的，排除arm64毫無影響。但是在M1機型上，模擬器是以arm64方式運行的，排除了arm64反而能跑，這不是把我的智商摁在地上摩擦么？，但是蘋果就是這樣乾的，當在M1機型上，排除了模擬器的arm64架構後，模擬器還是會以arm64的方式運行，但是模擬器中的app是以x86的方式運行的，對蘋果的這個騷操作我們不得不服。圖示如下：

有時候在Excluded Architectures選項中排除了模擬器的arm64指令，依然無法編譯通過，那麼一般是項目設置和cocoapods的設置不一致導致，設置為一致後一般可以解決問題。可以通過在Podfile中添加如下內容來解決：

通過上述內容，我們知道了問題的由來，它是由於項目中存在.a或.framework，它們提供的指令集不完整導致的。Apple對於這類問題，也提供了解決方案，請由我細細道來。

以Xcode13為例，在我們創建靜態庫時，選擇真機編譯出來的包只包含arm64指令，選擇模擬器編譯出來的會同時包含arm64和x86_64指令。我看一些網上的教程，教別人將模擬器部分的arm64移除，其實大可不必。因為要支持M1機器正常跑模擬器，模擬器必須同時包含arm64和x86_64指令。

2019年的WWDC，apple提供了一種新的框架封裝格式XCFramework。簡單理解就是以前使用lipo合並不同指令集的包，現在則使用新的指令合並成XCFramework格式

打包成framework，格式如下：

打包成XCFramework後，格式如下：

從上述可以看出，XCFramework就是把兩個不同指令集的framework放入了同一個文件夾(.xcframework)，並生成了一個配置文件Info.plist。這樣生成的XCFramework就可以完美的解決M1機器無法編譯模擬器的問題。
XCFramework的創建指令也很簡單：

以現在的情況，很多第三方框架，並沒有使用XCFramework，而項目中只要有一個框架沒有支持模擬器的arm64指令，那麼在M1機器上，模擬器只能以Rosetta模式運行應用，對這一塊的普遍支持估計要等M1普及以後了。

蘋果換芯，成了開發者們的噩夢？
armv6、armv7、armv7s、armv8、armv64及其i386、x86_64區別
細說iOS靜態庫和動態庫
關於Xcode11的XCFrameworks框架

❽ 誰能簡單闡述下java編譯執行的過程

Java虛擬機(JVM)是可運行Java代碼的假想計算機。

只要根據JVM規格描述將解釋器移植到特定的計算機上，就能保證經過編譯的任何Java代碼能夠在該系統上運行。

本文首先簡要介紹從Java文件的編譯到最終執行的過程，隨後對JVM規格描述作一說明。

一.Java源文件的編譯、下載、解釋和執行

Java應用程序的開發周期包括編譯、下載、解釋和執行幾個部分。

Java編譯程序將Java源程序翻譯為JVM可執行代碼?位元組碼。

這一編譯過程同C/C++的編譯有些不同。

當C編譯器編譯生成一個對象的代碼時，該代碼是為在某一特定硬體平台運行而產生的。

因此，在編譯過程中，編譯程序通過查表將所有對符號的引用轉換為特定的內存偏移量，以保證程序運行。

Java編譯器卻不將對變數和方法的引用編譯為數值引用，也不確定程序執行過程中的內存布局，而是將這些符號引用信息保留在位元組碼中，由解釋器在運行過程中創立內存布局，然後再通過查表來確定一個方法所在的地址。

這樣就有效的保證了Java的可移植性和安全性。

運行JVM位元組碼的工作是由解釋器來完成的。

解釋執行過程分三部進行：代碼的裝入、代碼的校驗和代碼的執行。

裝入代碼的工作由"類裝載器"（classloader）完成。

類裝載器負責裝入運行一個程序需要的所有代碼，這也包括程序代碼中的類所繼承的類和被其調用的類。

當類裝載器裝入一個類時，該類被放在自己的名字空間中。

除了通過符號引用自己名字空間以外的類，類之間沒有其他辦法可以影響其他類。

在本台計算機上的所有類都在同一地址空間內，而所有從外部引進的類，都有一個自己獨立的名字空間。

這使得本地類通過共享相同的名字空間獲得較高的運行效率，同時又保證它們與從外部引進的類不會相互影響。

當裝入了運行程序需要的所有類後，解釋器便可確定整個可執行程序的內存布局。

解釋器為符號引用同特定的地址空間建立對應關系及查詢表。

通過在這一階段確定代碼的內存布局，Java很好地解決了由超類改變而使子類崩潰的問題，同時也防止了代碼對地址的非法訪問。

隨後，被裝入的代碼由位元組碼校驗器進行檢查。

校驗器可發現操作數棧溢出，非法數據類型轉化等多種錯誤。

通過校驗後，代碼便開始執行了。

Java位元組碼的執行有兩種方式：

1.即時編譯方式：解釋器先將位元組碼編譯成機器碼，然後再執行該機器碼。

2.解釋執行方式：解釋器通過每次解釋並執行一小段代碼來完成Java位元組碼程序的所有操作。

通常採用的是第二種方法。

由於JVM規格描述具有足夠的靈活性，這使得將位元組碼翻譯為機器代碼的工作

具有較高的效率。

對於那些對運行速度要求較高的應用程序，解釋器可將Java位元組碼即時編譯為機器碼，從而很好地保證了Java代碼的可移植性和高性能。

二.JVM規格描述

JVM的設計目標是提供一個基於抽象規格描述的計算機模型，為解釋程序開發人員提很好的靈活性，同時也確保Java代碼可在符合該規范的任何系統上運行。

JVM對其實現的某些方面給出了具體的定義，特別是對Java可執行代碼，即位元組碼(Bytecode)的格式給出了明確的規格。

這一規格包括操作碼和操作數的語法和數值、標識符的數值表示方式、以及Java類文件中的Java對象、常量緩沖池在JVM的存儲映象。

這些定義為JVM解釋器開發人員提供了所需的信息和開發環境。

Java的設計者希望給開發人員以隨心所欲使用Java的自由。

JVM定義了控制Java代碼解釋執行和具體實現的五種規格，它們是：

JVM指令系統

JVM寄存器

JVM棧結構

JVM碎片回收堆

JVM存儲區

2.1JVM指令系統

JVM指令系統同其他計算機的指令系統極其相似。

Java指令也是由操作碼和操作數兩部分組成。

操作碼為8位二進制數，操作數進緊隨在操作碼的後面，其長度根據需要而不同。

操作碼用於指定一條指令操作的性質（在這里我們採用匯編符號的形式進行說明），如iload表示從存儲器中裝入一個整數，anewarray表示為一個新數組分配空間，iand表示兩個整數的"與"，ret用於流程式控制制，表示從對某一方法的調用中返回。

當長度大於8位時，操作數被分為兩個以上位元組存放。

JVM採用了"bigendian"的編碼方式來處理這種情況，即高位bits存放在低位元組中。

這同Motorola及其他的RISCCPU採用的編碼方式是一致的，而與Intel採用的"littleendian"的編碼方式即低位bits存放在低位位元組的方法不同。

Java指令系統是以Java語言的實現為目的設計的，其中包含了用於調用方法和監視多先程系統的指令。

Java的8位操作碼的長度使得JVM最多有256種指令，目前已使用了160多種操作碼。

2.2JVM指令系統

所有的CPU均包含用於保存系統狀態和處理器所需信息的寄存器組。

如果虛擬機定義較多的寄存器，便可以從中得到更多的信息而不必對棧或內存進行訪問，這有利於提高運行速度。

然而，如果虛擬機中的寄存器比實際CPU的寄存器多，在實現虛擬機時就會佔用處理器大量的時間來用常規存儲器模擬寄存器，這反而會降低虛擬機的效率。

針對這種情況，JVM只設置了4個最為常用的寄存器。

它們是：

pc程序計數器

optop操作數棧頂指針

frame當前執行環境指針

vars指向當前執行環境中第一個局部變數的指針

所有寄存器均為32位。

pc用於記錄程序的執行。

optop,frame和vars用於記錄指向Java棧區的指針。

2.3JVM棧結構

作為基於棧結構的計算機，Java棧是JVM存儲信息的主要方法。

當JVM得到一個Java位元組碼應用程序後，便為該代碼中一個類的每一個方法創建一個棧框架，以保存該方法的狀態信息。

每個棧框架包括以下三類信息：

局部變數

執行環境

操作數棧

局部變數用於存儲一個類的方法中所用到的局部變數。

vars寄存器指向該變數表中的第一個局部變數。

執行環境用於保存解釋器對Java位元組碼進行解釋過程中所需的信息。

它們是：上次調用的方法、局部變數指針和操作數棧的棧頂和棧底指針。

執行環境是一個執行一個方法的控制中心。

例如：如果解釋器要執行iadd(整數加法)，首先要從frame寄存器中找到當前執行環境，而後便從執行環境中找到操作數棧，從棧頂彈出兩個整數進行加法運算，最後將結果壓入棧頂。

操作數棧用於存儲運算所需操作數及運算的結果。

2.4JVM碎片回收堆

Java類的實例所需的存儲空間是在堆上分配的。

解釋器具體承擔為類實例分配空間的工作。

解釋器在為一個實例分配完存儲空間後，便開始記錄對該實例所佔用的內存區域的使用。

一旦對象使用完畢，便將其回收到堆中。

在Java語言中，除了new語句外沒有其他方法為一對象申請和釋放內存。

對內存進行釋放和回收的工作是由Java運行系統承擔的。

這允許Java運行系統的設計者自己決定碎片回收的方法。

在SUN公司開發的Java解釋器和HotJava環境中，碎片回收用後台線程的方式來執行。

這不但為運行系統提供了良好的性能，而且使程序設計人員擺脫了自己控制內存使用的風險。

2.5JVM存儲區

JVM有兩類存儲區：常量緩沖池和方法區。

常量緩沖池用於存儲類名稱、方法和欄位名稱以及串常量。

方法區則用於存儲Java方法的位元組碼。

對於這兩種存儲區域具體實現方式在JVM規格中沒有明確規定。

這使得Java應用程序的存儲布局必須在運行過程中確定，依賴於具體平台的實現方式。

JVM是為Java位元組碼定義的一種獨立於具體平台的規格描述，是Java平 *** 立性的基礎。

目前的JVM還存在一些限制和不足，有待於進一步的完善，但無論如何，JVM的思想是成功的。

對比分析：如果把Java原程序想像成我們的C++原程序，Java原程序編譯後生成的位元組碼就相當於C++原程序編譯後的80x86的機器碼（二進製程序文件），JVM虛擬機相當於80x86計算機系統,Java解釋器相當於80x86CPU。

在80x86CPU上運行的是機器碼，在Java解釋器上運行的是Java位元組碼。

Java解釋器相當於運行Java位元組碼的「CPU」,但該「CPU」不是通過硬體實現的，而是用軟體實現的。

Java解釋器實際上就是特定的平台下的一個應用程序。

只要實現了特定平台下的解釋器程序，Java位元組碼就能通過解釋器程序在該平台下運行，這是Java跨平台的根本。

當前，並不是在所有的平台下都有相應Java解釋器程序，這也是Java並不能在所有的平台下都能運行的原因，它只能在已實現了Java解釋器程序的平台下運行。

❾ 如何編譯MTK的模擬器

MTK的emulator是基於MTK平台的codeabse編譯得到用來閉槐模擬真機的虛擬Device,以下是具體的操作步驟：
1. Build MTK SDK Packages
-對於mt6572以前的chip，用如下的命令編譯:
./makeMtk banyan_addon
-從mt6572開始的chip,由於mt6572之後CPU開始支持X86架構，其performace會更好，mt6572之後，建議編譯x86的emulator來使用.

./makeMtk banyan_addon_x86

編譯完成後會在out/host/linux-x86/sdk_addon下生成MTK的SDK包，比如mtk_sdk_api_addon-17.1.zip，(其中17是android api level)

2. 解壓mtk_sdk_api_addon_17.1.zip
將解壓後的mtk_sdk_api_addon-17.1整個文件夾放在android原本的sdk的add-ons目錄下。

3. 拷貝emulator相關的執行文件到android sdk tool下：
- 對ICS 4.0之前的版本：
進 入android-sdk-windows\add-ons\banyan_addon_ALPS.GB.FDD.MP.V1_eng\tools 目錄下，將其中的 emulator.exe 或者 emulator（如果使用Linux的SDK的話）復制出來，覆蓋android-sdk-windows\tools下的相應 emulator.exe

- 對ICS 4.0及之後的版本：
將 mtk_sdk_api_addon-15.1\emulator對應文件夾下的emulator,emulator-arm,emulator-x86 這三支文件替換android原本sdk的tools目錄下的emulator,emulator-arm,emulator-x86這三支文件(建議備 份google原始sdk下的emulator,emulator-arm,emulator-x86，以團亮便後面用到Google emulator)。

4. 創建新的AVD
在Target裡面選擇帶有MediaTek標塌態寬志的，然後啟動這一AVD就可以了
PS：創建AVD時需要同步將SDK的版本升級到相對的android版本，比如JB2對應的android API level 17,則對應SDK的版本也要升級到level 17,否則將在創建AVD的時候將load不出帶MediaTek標志的target

❿ Android反編譯（三）— 手動編譯

PS: 最近沒工作，沒工作就沒需求，沒需求就沒什麼技術總結的靈感，那就沒更新什麼。但是兩個月不更新了，要是三個月不更新就會出大事，所以這次打算做一件有意思又不難的事。
之前有發文章寫過反編譯，今天就來試試反編譯之正編譯，開玩笑的，就是試試手動編譯的過程， 平時我們在項目中編譯出包都是使用Gradle直接執行assemble任務就能解決，我打算試試手動模擬整個過程。當然我也是第一次這樣搞，所以如果有寫得不對的地方，還望指出。

眾所周知，apk實質上就是一個壓縮包。復習一下，我們寫個最簡單的Demo，然後打包，然解壓，注意是解壓，不是反編譯，意義是不同的。

注意我這個Demo很簡單，什麼都不引入

然後我們看看整個出包的過程，隨便從網上拿張圖

然後這里我們用Android SDK給我們提供的工具來完成整個流程，工具在sdk文件夾下的build-tools文件夾下，有什麼aapt.exe、dx.bat，用的就是這些

這步應該是整個流程最簡單的吧，我感覺，所以從最簡單的開始。
我們先看看生成的dex有什麼

對比項目，我是一開始最基本的項目，什麼都沒動，所以只有一個MainActivity.clas，所以這里肯定是要先想辦法得到BuildConfig.class和R.class。

輸入命令：
aapt p -f -m -J <輸出路徑> -S <res路徑> -I <android.jar路徑> -M <Manifest路徑>

下一步，我們需要BuildConfig.class
這個BuildConfig.java是由gradle在我們配置好gradle之後自己幫我們生成的，所以我們直接拿來用，然後再javac就得到class文件了

然後我們再編譯我們的MainActivity.java並將它們放到同一個文件夾下， MainActivity因為引用了Android.jar和R文件，所以編譯時注意點，我為此被動好好的復習了一遍javac，都是淚

最後一步，我們用dx工具就能打出dex文件了

然後執行命令就得到一個Dex文件，看看這個文件裡面和上面直接打出的apk中的Dex文件有什麼不同：

看圖，我們上一步已經生成.dex了，那麼我們需要和compiled Resource 還有 Other Resource 一起生成APK。

我們先來生成compiled Resource，也就是resources.arsc
發現之前使用aapt生成R文件的時候沒寫完整，當時可以加一個-F參數直接生成arsc和Manifest

導出的abc.zip裡面就有resources.arsc和AndroidManifest.xml。
因為之前寫漏了，所以肯定要重新編一次MainActivity.java和Dex

我們把剛才的dex文件和aapt生成的resources.arsc、AndroidManifest.xml和res放到一個文件夾裡面。
PS：res文件夾也是上面aapt的命令生成的
然後我們對比這個文件夾和之前apk解壓的文件夾

最後運行

看來是成功了。

再說說遇到的還有兩個問題，並說下我解決問題的思路
（1）我把它們都放到一個文件夾之後，我壓縮成壓縮包，然後改後綴成.apk，然後發現安裝不了，我就直接反編譯，發現發編譯失敗，提示包有問題，以我多點玩包的經驗，我感覺就是壓縮工具出了問題，然後我去下個「好壓」（這不是廣告啊），然後就能正常反編譯了。
（2）但是還是安裝不了，再根據我多年的玩包經驗，我感覺是簽名問題，然後我隨便給這個包上一個簽名，就能正常安裝得到上圖的結果了。

總體來說，還真挺好玩的，這整個過程，就是翻車了幾次。做完之後感覺非常牛逼，為什麼這樣說，因為我知道這整個過程，我就可以做到，我不經過gradle來打包，我自己寫個python腳本來調用aapt和dx來打包也是能做到的。
當然上面純屬異想天開，因為這是個什麼都沒有的Demo所以覺得簡單，要是一個真實的項目，我感覺肯定要有很多坑，別的先不說，一個項目那麼多依賴關系，我這javac要搞死人。
最後如果有不對的地方，希望有大佬能夠指出，畢竟能運行也不能證明完全沒問題。然後我使用的build-tools是28的，不敢保證其它版本包括以後版本的玩法都一樣。