類原生編譯

㈠ 編譯調試Android系統原生App - 以Settings為例

本文已過時，最新文章：向大家推薦《使用 AS 開發 System App》 https://xiaozhuanlan.com/system-app

Android原生系統帶有許多原生的App，比如 瀏覽器、錄音機、計算器、設置 等，有些時候，我們需要用到一些系統的功能，或者是對已有的功能做二次開發，比如我上學時給一個公司做過一個Launcher和Wizard，就需要用到系統設置中的某些功能，比如Wifi、聲音、顯示等功能，於是就需要從Settings源碼中提取出需要的功能。

特別是公司自己定製Android系統，需要在上面做一些 系統級的App 的時候，原生App已有的功能就可以通過編譯其源碼的方式直接拿過來改改就能用，而且可用度很高。

這里有兩種情況，分為 原生 的和 公司定製 的系統。無論是原生的還是定製的，類似於Settings這樣需要使用到 系統級或隱藏API 的App，都需要系統簽名文件和編譯系統源碼後得到相應的jar包才可以在IDE中編譯，因為標准SDK根本沒有那些API可供調用。

舉個栗子：

需要額外的Jar就需要自己編譯系統源碼啦，這個是比較麻煩的，有興趣可以試試自己編譯定製自己的Android系統。

** 注意，既然是定製的，源碼、jar、簽名文件，還有系統都是一一對應的，你不能拿其他公司的系統簽名來給你公司的系統app簽名，這樣無法運行的。 **

有了源碼，下一步當然是要跑起來啦。

建議都使用Eclipse來編譯，不要使用AS，因為AS編譯大型的原生App能卡到你吐血，而且出錯提示也不友好。但是用過AS的人都不想再碰Eclipse了有沒有？？別急，可以先用Eclipse編譯過了，再貼到AS中，這樣好很多，也很節省時間。

初始化：

放入源碼：

修正res錯誤：

修正src錯誤：

使用到系統級API的，或者AndroidManifest.xml文件中聲明了

那麼沒有系統簽名，直接debug簽名運行是不行的，需要向底層工程師要系統的簽名文件，在源碼目錄
build\target\proct\security
下的 platform.pk8 和 platform.x509.pem ，如果你想看此次編譯Settings是否已成功了，可以適當的在入口加一下Log，然後導出未簽名的apk，使用系統簽名進行簽名後，放到 /system/app/ 下替換掉Settings.apk，然後重啟系統，打開設置，看看Logcat是否輸出里加入的Log。

在不知道系統簽名可以轉換成debug簽名前，老實說我一直都是用Log的方式調試，太特么痛苦了。現在知道後整個人都懵逼了。

我們都希望可以像調試普通app那樣調試系統app，以下是如何通過 openssl 將 platform.pk8 和 platform.x509.pem 轉換成 debug.keystore 文件：

三個命令

此方法來自： http://curlog.com/2016/08/30/android-pk2debug-keystore/

Mac自帶openssl，linux和Win需要安裝。

然後就可以使用得到的debug簽名配置到eclipse後愉快的調試啦，當然，得先把系統中已經存在的app先刪除掉。然後重啟系統，至於如何配置eclipse的debug簽名，請Google。

使用過AS後，當然希望在AS中也可以調試系統App，抽空再寫篇相關編譯和調試的文章。如果這篇文章幫到你了，給個贊唄。

㈡ 什麼是C++原生類型

Nature Type，原生類型，我的理解，就是編譯器自身支持的數據類型
包括簡單數據類型和復雜數據類型，比如：
int、char、float、double、short、long 這些就是簡單類型
union、enum、struct、class 這些就是復雜類型

其中 class 是 C++ 特有的，而 C 沒有
wchar_t 是新增的特性，還有 size_t、sizeof、typeinfo 等
BYTE 其實就是 unsigned char

㈢ 什麼是原生代碼

原生代碼: native code

是本地cpu的目標執行代碼, 不是il, 所以速度很快, 它的執行不依賴某個虛擬機或者解釋器，編譯後可直接依附操作系統運行，不需要經過虛擬機之類的東西。
希望能幫助到你！
還請及時採納謝謝

㈣ 為什麼交叉編譯的原生編譯器找不到/usr/include/limits.h

差別只在gcc提供的include-fixed的limits.h的內容
/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20080926/include-fixed/limits.h

正常的這個文件里有
#ifdef _GCC_NEXT_LIMITS_H
#include_next /* recurse down to the real one */
#endif

有問題的文件里則沒有

㈤ 不同的c語言編譯系統差別在哪裡代碼是否 存在兼容性的問題

ANSI
C
一般都可以支持，但也涉及到不同版本的C標準的兼容性問題，比如VC6不支持C99，VS2003,2005,2008,20120等就可以部分支持C99標准；而且很多標准並沒有規定實現，不同的編譯器實現可能不同，比如C標准只規定了short<=int<=long,但並沒有規定位元組數，導致不同的編譯器數據類型的大小各不相同。
非
ANSI
C標準的話，不同的編譯器一般都有不同的實現，需要分別實現。
在移植到不同編譯器的時候這些都要注意處理，比較常規的做法是數據類型和函數等自己根據不同編譯器封裝成一個統一的格式，在程序中使用封裝後的數據類型或函數，而不要使用原生類型，這樣在移植時只需要在封裝的地方根據編譯器的不同進行修改就可以了，不需要再修改源代碼。

㈥ 應用編譯優化哪個模式好

即時編譯技術。
JIT為「即時編譯技術」，當App運行時，每當遇到一個新類，JIT編譯器就會對這個類進行編譯，經過編譯後的代碼，會被優化成相當精簡的原生型指令碼（即nativecode），這樣在下次執行到相同邏輯的時候，速度就會更快。

㈦ flutter與原生混編(iOS)

一、創建項目及配置
1，創建ios項目，同時在同一個根目錄下創建flutter項目
flutter項目使用命令flutter create -t mole xxxflutter項目名
如圖

2，將flutter項目以pod的形式加入ios項目
2.1，如果項目之前沒有用過pod，則pod init創建podfile
如果使用過，直接進行步驟2.2。
2.2，podfile中添加

flutter_application_path是flutter項目的路徑
2.3，target中加入（一次性將flutter的編譯產物由此依賴進入iOS項目中，可跳過步驟3）

3，配置腳本（已完成步驟2.3可進行步驟4）
打開ios項目，在Build Phases中左上角添加Run Script

4，設置bitcode
Flutter 目前還不支持 BitCode，需要設置為No

二、混編使以後添加的每個模塊都以package形式，在mole中pubspec.yaml文件中引用（基於內存消耗考慮）
1，頁面跳轉
原生處理：
flutter在iOS中的使用，主要是以FlutterViewController為載體，並在其內部採用FlutterEngine對視圖進行渲染。
導入頭文件：

flutter處理：
在mole項目的main里

定義channel，名字與原生保持一致

2，數據傳遞
二者之間的數據傳遞iOS使用FlutterBasicMessageChannel類，flutter使用BasicMessageChannel類，用法與MethodChannel類似
原生處理：

接收數據：

發送數據：

flutter處理：

問題：

網上搜的方法，在podfile最前邊加eval(File.read(File.join(flutter_application_path, '.ios', 'Flutter', 'podhelper.rb')), binding)句話
執行pod install失敗

於是又搜了下別的文章，添加的第二句話為load File.join(flutter_application_path, '.ios', 'Flutter', 'podhelper.rb')，試了下成功了

㈧ 請教各位關於G1/G2]★安卓網原創★ Android 原生編譯 ROM 3.121 美化版！無泡版

呵呵，樓主！我自己根據你說的這個ROM，精簡了一個：去安卓市場、電子市場、播放器、視頻、重力球、瀏覽器、天氣、還有幾個忘了，我自己裝了測試了一天半，沒有問題，不過我感覺應用程序裡面太單調又換回來了。

㈨ 如何將android原生應用改成ant方式編譯

android 程序打包成apk，如果在是命令行方式，一般都要經過如下步驟：
1.用aapt命令生成R.java文件
2.用aidl命令生成相應java文件
3.用javac命令編譯java源文件生成class文件
4.用dx.bat將class文件轉換成classes.dex文件
5.用aapt命令生成資源包文件resources.ap_
6.用apkbuilder.bat打包資源和classes.dex文件,生成unsigned.apk
7.用jarsinger命令對apk認證,生成signed.apk

eclipase手動打包生成apk方式，只不過是eclipase代替執行了以上命令而已。

eclipse用起來雖然方便，為什麼要使用Ant批量打包Android應用，對於個人來說主要有以下兩方面考慮：
1、咱們在發布App的時候，可能需要發送到十幾，甚至幾十個不同的分發渠道，比如360手機市場，網路，應用寶等等，咱們可能需要對各個渠道的下載量，用戶存留和用戶使用情況等數據進行分析，比如使用網路移動統計，友盟統計等。為了實現統計功能，需要在配置文件中添加一個數據元，來標識咱們的應用要發布到哪一個渠道上，因此，若使用傳統的方法，咱們每發布一個渠道的版本，就需要修改清單文件中的數據元，然後再使用keystore進行簽名和打包。若只有一兩個分發渠道，工作量還是可以接受的，但是若咱們的分發渠道打到幾十個的時候，咱們如果再手動的進行修改然後簽名打包發布，那工作量就很可觀了。因此，為解決這種需求，咱們採用Ant來實現對Android應用的自動打包。
2、咱們做產品的時候，肯定需要經常打不同環境的包，比如開發環境，測試環境，生產環境，這個時候怎麼辦，如果用傳統方法，打開發環境包要把自己的服務端IP和圖片伺服器IP改成開發的，打包，然後打測試的包，又要改成測試伺服器IP和圖片伺服器IP，這樣多麻煩，如果把這服務端IP和圖片伺服器IP，配置到一個xml文件里，用ant打包方式實現自動替換，多方便。