arm編譯app

❶ android jni程序（c++）如何編譯適用於arm-v8指令集的32位程序

可以看到Android上層的Application和ApplicationFramework都是使用java編寫，

底層包括系統和使用眾多的LIiraries都是C/C++編寫的。

所以上層Java要調用底層的C/C++函數庫必須通過Java的JNI來實現。

下面將學習Android是如何通過Jni來實現Java對C/C++函數的調用。以HelloWorld程序為例：

第一步：

使用Java編寫HelloWorld 的Android應用程序：

package com.lucyfyr;
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;

public class HelloWorld extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
Log.v("fresne", printJNI("I am HelloWorld Activity"));
}
static
{
//載入庫文件
System.loadLibrary("HelloWorldJni");
}
//聲明原生函數 參數為String類型 返回類型為String
private native String printJNI(String inputStr);
}

這一步我們可以使用eclipse來生成一個App；

因為eclipse會自動為我們編譯此Java文件，後面要是用到。

第二步：

生成共享庫的頭文件：

進入到eclipse生成的Android Project中 ：/HelloWorld/bin/classes/com/lucyfyr/
下：

可以看到裡面後很多後綴為.class的文件，就是eclipse為我們自動編譯好了的java文件，其中就有：

HelloWorld.class文件。

退回到classes一級目錄：/HelloWorld/bin/classes/

執行如下命令：

javah com.lucyfyr.HelloWorld

生成文件:com_lucyfyr_HelloWorld.h

/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class com_lucyfyr_HelloWorld */
#ifndef _Included_com_lucyfyr_HelloWorld
#define _Included_com_lucyfyr_HelloWorld
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: com_lucyfyr_HelloWorld
* Method: printJNI
* Signature: (Ljava/lang/String;)Ljava/lang/String;
*/
JNIEXPORT jstring JNICALL Java_com_lucyfyr_HelloWorld_printJNI
(JNIEnv *, jobject, jstring);
#ifdef __cplusplus
}
#endif
#endif

可以看到自動生成對應的函數：Java_com_lucyfyr_HelloWorld_printJNI

Java_ + 包名（com.lucyfyr） + 類名(HelloWorld) + 介面名(printJNI)：必須要按此JNI規范來操作；

java虛擬機就可以在com.simon.HelloWorld類調用printJNI介面的時候自動找到這個C實現的Native函數調用。

當然函數名太長，可以在.c文件中通過函數名映射表來實現簡化。

第三步：

實現JNI原生函數源文件：

新建com_lucyfyr_HelloWorld.c文件：

#include <jni.h>
#define LOG_TAG "HelloWorld"
#include <utils/Log.h>
/* Native interface, it will be call in java code */
JNIEXPORT jstring JNICALL Java_com_lucyfyr_HelloWorld_printJNI(JNIEnv *env, jobject obj,jstring inputStr)
{
LOGI("fresne Hello World From libhelloworld.so!");
// 從 instring 字元串取得指向字元串 UTF 編碼的指針
const char *str =
(const char *)(*env)->GetStringUTFChars( env,inputStr, JNI_FALSE );
LOGI("fresne--->%s",(const char *)str);
// 通知虛擬機本地代碼不再需要通過 str 訪問 Java 字元串。
(*env)->ReleaseStringUTFChars(env, inputStr, (const char *)str );
return (*env)->NewStringUTF(env, "Hello World! I am Native interface");
}
/* This function will be call when the library first be load.
* You can do some init in the libray. return which version jni it support.
*/
jint JNI_OnLoad(JavaVM* vm, void* reserved)
{
void *venv;
LOGI("fresne----->JNI_OnLoad!");
if ((*vm)->GetEnv(vm, (void**)&venv, JNI_VERSION_1_4) != JNI_OK) {
LOGE("fresne--->ERROR: GetEnv failed");
return -1;
}
return JNI_VERSION_1_4;
}

OnLoadJava_com_lucyfyr_HelloWorld_printJNI

函數裡面做一些log輸出 注意JNI中的log輸出的不同。

JNI_OnLoad函數JNI規范定義的，當共享庫第一次被載入的時候會被回調，

這個函數裡面可以進行一些初始化工作，比如注冊函數映射表，緩存一些變數等，

最後返回當前環境所支持的JNI環境。本例只是簡單的返回當前JNI環境。

http://www.cnblogs.com/bastard/archive/2012/05/19/2508913.html

❷ 如何適配Arm64架構的 iosAPP

如何適配Arm64架構的 iosAPP
我們先來談談「64位」這個術語及其含義。大家對於這個術語一直比較困惑，很大一部分原因在於，它沒有統一的、約定俗成的定義。然而，在大體上卻達成了一些共識，盡管這些共識並未為大眾所知。
「×× 位」CPU通常是指兩個部分的寬度：整數寄存器的寬度和指針的寬度。值得慶幸的是，在大多數現代CPU中，它們是一致的。「64位」通常是指CPU有64 位整數寄存器和64位指針。除了搞清楚「64位」所指的對象外，明白非「64位」所指的對象也十分重要，這些對象通常包括以下幾種。
內存（RAM）地址大小。這一數值（關繫到硬體可支持的最大內存）與CPU的位數無關。ARM架構的內存地址通常從26位到40位不等。
數據匯流排大小。CPU從內存或緩存中獲取的數據量也與CPU的位數無關，某些CPU指令可能需要特定大小的數據，但在實際應用中，既可一次獲取多條指令， 也可多次獲取一條指令。上一代iPhone就已經以64位塊為單位從內存獲取數據了。在PC中，塊大小最高可達192位。
與浮點運算相關的參數。FPU寄存器的大小和內部設計是獨立的，ARM架構採用64位FPU已頗有段時間了。
「64位」的優點與缺點
盡管64位與硬體可支持的最大內存無關，但便於單一程序使用更大內存。在32位CPU中，單一程序僅有4GB地址空間，減去被操作系統和標准庫所佔用的部 分，只剩1～3GB可用。如果一個32位系統的RAM超過4GB，單一程序很難充分利用全部空間，除非開發者耍些小聰明，例如直接命令操作系統按需求分配 內存，或將程序拆分成多個進程。但在實際應用中，很少有程序這么做，因為編程更麻煩，還會有損性能。系統擁有更多內存的好處是，能同時運行多個應用並減少 硬碟緩存。這樣固然不錯，但難免有個別程序需要使用更多內存的情況。
即使對於物理內存較小的系統，更大的地址空間也有幫助。內存映射文件是種有用的結構，在32位系統中，程序不能映射大文件（通常是指超過幾百MB的文件），而64位系統的可用地址空間更大，不必有這方面的擔心。
不過，增加指針寬度有個嚴重的缺點：在所有其他條件都相同的情況下，單一程序在64位CPU系統中更占內存。因為指針本身也需要存儲於內存中，在64位系統 上，這個空間增加了一倍。而大多數程序運用指針很頻繁，所以額外佔用的空間往往不少。這給緩存帶來了壓力，從而導致性能降低。
簡而言之，「64位」可以提升某些應用的性能，並使內存映射文件這種編程技術更易用。不過，它也會因佔用更多內存而降低性能。
ARM64
iPhone 5S的64位CPU是配有更寬寄存器的ARM處理器，與32位ARM架構相比，64位ARM架構包括以下重大變動：首先是名稱的變化——它的官方名稱為 「AArch64」，但這個名字讀起來很繞口，敲起來也別扭。蘋果稱它為ARM64，我也更傾向於用這個名字。
較32位ARM架構而 言，ARM64的整數寄存器數量增加了一倍，32位ARM架構有16個整數寄存器，其中1個是專用的程序計數器，還有2個用於堆棧指針和鏈接，其他13個 則作一般用途。而ARM64位架構有32個整數寄存器，包括1個專用的零寄存器，1個鏈接寄存器和1個幀指針寄存器，還有1個寄存器預留給平台，另外28 個則為通用整數寄存器。ARM64上可用浮點寄存器的數量有所增加。32位ARM處理器有32個32位浮點寄存器，還有16個額外的64位寄存器。這些寄 存器的結構有些特殊，可被視為等價於16個重疊的128位寄存器。ARM64則將其簡化為32個128位寄存器，且沒有重疊。
寄存器的數量 會對性能會產生巨大影響。與CPU相比，內存要慢得多。與CPU處理一條指令的時間相比，讀取和寫入內存都需要更長時間。CPU試圖通過引入緩存來緩解這 一差距。但與CPU內部的寄存器相比，即使速度最快的緩存也慢得多。更多的寄存器意味著更多數據能存儲在CPU內部，這降低了內存訪問頻率，同時提高了性 能。
除了增加寄存器數量，ARM64也為指令集帶來了重大變化。大多數32位ARM處理器可基於運行時條件寄存器的狀態執行條件指令，這使 得在編譯if等語句時無需分支。不過這種方式引入的麻煩多於便利，因此ARM64取消了條件執行。ARM64的NEON SIMD單元完全符合IEEE754雙精度標准，而32位版本的NEON SIMD單元只支持單精度。ARM64還增加了專門的AES、SHA-1、SHA-256加密指令。這些指令也許對普通應用幫助不大，但對特定領域的應用 來說價值無窮。

❸ 利用arm-linux-gcc編譯時出現collect2: ld returned 1 exit status 錯誤：具體步驟如下：

我看上面寫的是 /armlinux/app/mylib這個路徑，下面指定庫路徑的時候就成了/armlinux/ex/mylib了，是不是路徑不對啊，你生成的.so文件是不是在/armlinux/app/mylib這個裡面了。

❹ app-armeabi-release.apk和app-universal-release.apk的區別

app-debug.apk 和 app-release.apk 的核心區別在AndroidManifest.xml 。

生成app-debug.apk時，編譯器會自動在該apk的AndroidManifest.xml中添加android:debuggable="true"

生成app-release.apk時，編譯器會自動在該apk的AndroidManifest.xml中去掉 android:debuggable

make project(ctrl+F9) 生成app-debug.apk

run app (shift + F10)生成app-debug.apk

(4)arm編譯app擴展閱讀：

1、 app-debug.apk只能通過run app運行到目標設備，如果把這個apk通過adb install安裝到目標設備，則報錯：INSTALL_FAILED_TEST_ONLY2. adb install只能安裝release版apk

2、系統許可權簽名：

簽名工具存放在系統源碼的目錄out/host/linux-x86/framework/signapk.jar

簽名文件存放在系統源碼的目錄build/target/proct/security/

簽名方法：java-jarsignapk.jarplatform.x509.pemplatform.pk8old.apknew.apk

3、INSTALL_FAILED_SHARED_USER_INCOMPATIBLE報錯是因為沒有系統許可權簽名，即沒有用platform.pk8和platform.x509.pem進行許可權簽名。

4、 android studio中如下簽名不是許可權簽名，是java包名唯一性簽名，即為了防止他人反編譯用同樣包名篡改apk。簡而言之，沒有同樣的.jks簽名文件，則同樣包名的apk無法覆蓋安裝同包名的apk。

❺ cpu 是arm 架構的linux 麒麟系統 怎樣使用android studio 開發app 程序

這個你需要去下載相應的Linux版本的android studio開發軟體，然後將其安裝到你的Linux系統上，安裝好後，進行相應的設置，就可以使用android studio開發app程序了。
樓主如果對Linux系統感興趣，想學習更多Linux系統知識，可以網路《Linux就該這么學》，不錯的一本Linux系統教程。

❻ 如何適配Arm64架構的 iosAPP

根據最新消息從2015年2月1日起，上傳到AppStore的iOS應用必須包含對64位系統的支持，並且必須使用Xcode6或更高版本中的iOS8SDK編譯。為了讓您的項目支持64位系統，Unity建議您使用Xcode默認的發布設置「Standardarchitectures」，從而可以編譯

❼ gcc -arm這個交叉編譯工具。有沒有可以再window上使用的

yagarto和codesourcery都是在windows下用的，官方已經編譯打包好的
EXE文件
cygwin下可以自己編譯源代碼，做出GNU工具鏈
mingw也可以實現
還有一些在windows下用的IDE，專門針對GNU工具鏈的，code::blocks,emide等
我在用emIDE,arm-none-eabi-gdb調試ARM

❽ gcc -arm這個交叉編譯工具。有沒有可以再window上使用的

yagarto和codesourcery都是在windows下用的，官方已經編譯打包好的EXE文件
cygwin下可以自己編譯源代碼，做出GNU工具鏈
mingw也可以實現
還有一些在windows下用的IDE，專門針對GNU工具鏈的，code::blocks,emide等
我在用emIDE,arm-none-eabi-gdb調試ARM

❾ 如何適配Arm64架構的 iosAPP

從iPhone 5S的A7 CPU開始到剛剛發布的iPhone 6（A8 CPU）都已經支持64-bit ARM 架構。關於64-bit的介紹詳見維基網路。知乎上有很多關於蘋果使用A7，A8晶元的討論，可以參考 iPhone 6 的 Apple A8 晶元對比 Apple A7 提升明顯嗎？, iPhone 5s 配備的 A7 處理器是 64 位，意味著什麼？
Xcode 5.0.1開始支持編譯32-bit和64-bit的Binary
同時支持32-bit和64-bit，我們需要選擇的minimum deployment target為 iOS 5.1.1
64-bit的Binary必須運行在支持64-bit的CPU上，並且最小的OS版本要求是 7.0.3
關於Xcode 「Build Setting」中的Architectures參數問題
Architectures：你想支持的指令集。（支持指令集是通過編譯生成對應的二進制數據包實現的，如果支持的指令集數目有多個，就會編譯出包含多個指令集代碼的數據包，造成最終編譯的包很大。）
Valid architectures：即將編譯的指令集。（Valid architectures 和 Architecture兩個集合的交集為最終編譯生成的版本）
Build Active Architecture Only：是否只編譯當前設備適用的指令集（如果這個參數設為YES，使用iPhone 6調試，那麼最終生成的一個支持ARM64指令集的Binary。一般在DEBUG模式下設為YES，RELEASE設為NO）