android升級編譯器
❶ ANDROID上能用編譯器嗎
有不完美的解釋器
ruby解釋器..
irb吧...
❷ Android Studio升級到3.0版本後布局不能預覽
在左上角點擊File,找到Invaludate Caches/Restart...，點擊，編譯器在重啟完後，在真機上跑一遍就可以了，記住未在真機上跑一遍，預覽都是沒有的，跑完真機，預預覽才能出來
❸ 我的手機上編譯時間是11月10日，安卓更新時間是10月1日，這是什麼意思
編譯時間是手機系統軟體版本編譯完成的時間，新手機的系統編譯時間通常會早於手機出廠和購買時間的。
❹ 如何讓編譯器架構Android.mk動態
Android.mk文件用來告知NDK Build 系統關於Source的信息。 Android.mk將是GNU Makefile的一部分，且將被Build System解析一次或多次。
所以，請盡量少的在Android.mk中聲明變數，也不要假定任何東西不會在解析過程中定義。
Android.mk文件語法允許我們將Source打包成一個"moles". moles可以是：
靜態庫
動態庫。
只有動態庫可以被 install/到應用程序包(APK). 靜態庫則可以被鏈接入動態庫。
可以在一個Android.mk中定義一個或多個moles. 也可以將同一份source 加進多個moles.
Build System幫我們處理了很多細節而不需要我們再關心。例如：你不需要在Android.mk中列出頭文件和外部依賴文件。
NDK Build System自動幫我們提供這些信息。這也意味著，當用戶升級NDK後，你將可以受益於新的toolchain/platform而不必再去修改Android.mk.
1. Android.mk語法：
首先看一個最簡單的Android.mk的例子：
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c
include $(BUILD_SHARED_LIBRARY)
講解如下：
LOCAL_PATH := $(call my-dir)
每個Android.mk文件必須以定義LOCAL_PATH為開始。它用於在開發tree中查找源文件。
宏my-dir則由Build System提供。返回包含Android.mk的目錄路徑。
include $(CLEAR_VARS)
CLEAR_VARS 變數由Build System提供。並指向一個指定的GNU Makefile，由它負責清理很多LOCAL_xxx.
例如：LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES等等。但不清理LOCAL_PATH.
這個清理動作是必須的，因為所有的編譯控制文件由同一個GNU Make解析和執行，其變數是全局的。所以清理後才能避免相互影響。
LOCAL_MODULE := hello-jni
LOCAL_MODULE模塊必須定義，以表示Android.mk中的每一個模塊。名字必須唯一且不包含空格。
Build System會自動添加適當的前綴和後綴。例如，foo，要產生動態庫，則生成libfoo.so. 但請注意：如果模塊名被定為：libfoo.則生成libfoo.so. 不再加前綴。
LOCAL_SRC_FILES := hello-jni.c
LOCAL_SRC_FILES變數必須包含將要打包如模塊的C/C++ 源碼。
不必列出頭文件，build System 會自動幫我們找出依賴文件。
預設的C++源碼的擴展名為.cpp. 也可以修改，通過LOCAL_CPP_EXTENSION。
include $(BUILD_SHARED_LIBRARY)
BUILD_SHARED_LIBRARY：是Build System提供的一個變數，指向一個GNU Makefile Script。
它負責收集自從上次調用 include $(CLEAR_VARS) 後的所有LOCAL_XXX信息。並決定編譯為什麼。
BUILD_STATIC_LIBRARY：編譯為靜態庫。
BUILD_SHARED_LIBRARY ：編譯為動態庫
BUILD_EXECUTABLE：編譯為Native C可執行程序
2. NDK Build System變數：
NDK Build System 保留以下變數名：
以LOCAL_ 為開頭的
以PRIVATE_ ,NDK_ 或者APP_ 開頭的名字。
小寫字母名字：如my-dir
如果想要定義自己在Android.mk中使用的變數名，建議添加 MY＿前綴。
2.1: NDK提供的變數：
此類GNU Make變數是NDK Build System在解析Android.mk之前就定義好了的。
2.1.1：CLEAR_VARS：
指向一個編譯腳本。必須在新模塊前包含之。
include $(CLEAR_VARS)
2.1.2：BUILD_SHARED_LIBRARY：
指向一個編譯腳本，它收集自從上次調用 include $(CLEAR_VARS) 後的所有LOCAL_XXX信息。
並決定如何將你列出的Source編譯成一個動態庫。 注意，在包含此文件前，至少應該包含：LOCAL_MODULE and LOCAL_SRC_FILES 例如：
include $(BUILD_SHARED_LIBRARY)
2.1.3：BUILD_STATIC_LIBRARY：
與前面類似，它也指向一個編譯腳本，
收集自從上次調用 include $(CLEAR_VARS) 後的所有LOCAL_XXX信息。
並決定如何將你列出的Source編譯成一個靜態庫。 靜態庫不能夠加入到Project 或者APK中。但它可以用來生成動態庫。
LOCAL_STATIC_LIBRARIES and LOCAL_WHOLE_STATIC_LIBRARIES將描述之。
include $(BUILD_STATIC_LIBRARY)
2.1.4: BUILD_EXECUTABLE:
與前面類似，它也指向一個編譯腳本，收集自從上次調用 include $(CLEAR_VARS) 後的所有LOCAL_XXX信息。
並決定如何將你列出的Source編譯成一個可執行Native程序。 include $(BUILD_EXECUTABLE)
2.1.5：PREBUILT_SHARED_LIBRARY：
把這個共享庫聲明為 「一個」 獨立的模塊。
指向一個build 腳本，用來指定一個預先編譯好多動態庫。 與BUILD_SHARED_LIBRARY and BUILD_STATIC_LIBRARY不同，
此時模塊的LOCAL_SRC_FILES應該被指定為一個預先編譯好的動態庫，而非source file. LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := foo-prebuilt # 模塊名
LOCAL_SRC_FILES := libfoo.so # 模塊的文件路徑（相對於 LOCAL_PATH）
include $(PREBUILT_SHARED_LIBRARY) # 注意這里不是 BUILD_SHARED_LIBRARY
這個共享庫將被拷貝到 $PROJECT/obj/local 和 $PROJECT/libs/<abi> (stripped) 主要是用在將已經編譯好的第三方庫
使用在本Android Project中。為什麼不直接將其COPY到libs/armabi目錄呢？因為這樣做缺陷很多。下一節再詳細說明。
2.1.6: PREBUILT_STATIC_LIBRARY:預先編譯的靜態庫。 同上。
2.1.7: TARGET_ARCH: 目標CPU架構名。如果為「arm」 則聲稱ARM兼容的指令。與CPU架構版本無關。
2.1.8: TARGET_PLATFORM: 目標的名字。
2.1.9：TARGET_ARCH_ABI
Name of the target CPU+ABI
armeabi For ARMv5TE armeabi-v7a
2.1.10：TARGET_ABI
2.2: NDK提供的功能宏：
GNUMake 提供的功能宏，只有通過類似： $(call function) 的方式來得到其值，它將返迴文本化的信息。
2.2.1: my-dir: $(call my-dir):
返回最近一次include的Makefile的路徑。通常返回Android.mk所在的路徑。它用來作為Android.mk的開頭來定義LOCAL_PATH. LOCAL_PATH := $(call my-dir)
請注意：返回的是最近一次include的Makefile的路徑。所以在Include其它Makefile後，再調用$(call my-dir)會返回其它Android.mk 所在路徑。 例如：
LOCAL_PATH := $(call my-dir) declare one mole include $(LOCAL_PATH)/foo/Android.mk LOCAL_PATH := $(call my-dir) declare another mole
則第二次返回的LOCAL_PATH為：$PATH/foo。 而非$PATH.
2.2.2: all-subdir-makefiles:
返回一個列表，包含'my-dir'中所有子目錄中的Android.mk。
例如： 結構如下： sources/foo/Android.mk sources/foo/lib1/Android.mk sources/foo/lib2/Android.mk
在If sources/foo/Android.mk 中， include $(call all-subdir-makefiles) 那則自動include 了sources/foo/lib1/Android.mk and sources/foo/lib2/Android.mk。
2.2.3：this-makefile：
當前Makefile的路徑。
2.2.4：parent-makefile：
返回include tree中父Makefile 路徑。 也就是include 當前Makefile的Makefile Path。
2.2.5：import-mole：
允許尋找並inport其它moles到本Android.mk中來。 它會從NDK_MODULE_PATH尋找指定的模塊名。 $(call import-mole,<name>)
2.3: 模塊描述變數：
此類變數用來給Build System描述模塊信息。在'include $(CLEAR_VARS)' 和 'include $(BUILD_XXXXX)'之間。必須定義此類變數。 include $(CLEAR_VARS) script用來清空這些變數。
include $(BUILD_XXXXX)收集和使用這些變數。
2.3.1: LOCAL_PATH:
這個值用來給定當前目錄。必須在Android.mk的開是位置定義之。
例如： LOCAL_PATH := $(call my-dir) LOCAL_PATH不會被include $(CLEAR_VARS) 清理。
2.3.2: LOCAL_MODULE:
moles名。在include $(BUILD_XXXXX)之前，必須定義這個變數。此變數必須唯一且不能有空格。
通常，由此變數名決定最終生成的目標文件名。
2.3.3: LOCAL_MODULE_FILENAME:
可選。用來override LOCAL_MODULE. 即允許用戶重新定義最終生成的目標文件名。 LOCAL_MODULE := foo-version-1 LOCAL_MODULE_FILENAME := libfoo
2.3.4：LOCAL_SRC_FILES：
為Build Moles而提供的Source 文件列表。不需要列出依賴文件。 注意：文件相對於LOCAL_PATH存放，
且可以提供相對路徑。 例如： LOCAL_SRC_FILES := foo.c \ toto/bar.c
2.3.5: LOCAL_CPP_EXTENSION:
指出C++ 擴展名。(可選) LOCAL_CPP_EXTENSION := .cxx 從NDK R7後，可以寫多個：
LOCAL_CPP_EXTENSION := .cxx .cpp .cc
2.3.6：LOCAL_CPP_FEATURES：
可選。用來指定C++ features。 LOCAL_CPP_FEATURES := rtti
LOCAL_CPP_FEATURES := exceptions
2.3.7：LOCAL_C_INCLUDES：
一個可選的path列表。相對於NDK ROOT 目錄。編譯時，將會把這些目錄附上。 LOCAL_C_INCLUDES := sources/foo LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
2.3.8: LOCAL_CFLAGS:
一個可選的設置，在編譯C/C++ source 時添加如Flags。
用來附加編譯選項。 注意：不要嘗試在此處修改編譯的優化選項和Debug等級。它會通過您Application.mk中的信息自動指定。
也可以指定include 目錄通過：LOCAL_CFLAGS += -I<path>。 這個方法比使用LOCAL_C_INCLUDES要好。因為這樣也可以被ndk-debug使用。
2.3.9: LOCAL_CXXFLAGS: LOCAL_CPPFLAGS的別名。
2.3.10: LOCAL_CPPFLAGS:
C++ Source 編譯時添加的C Flags。這些Flags將出現在LOCAL_CFLAGS flags 的後面。
2.3.11: LOCAL_STATIC_LIBRARIES:
要鏈接到本模塊的靜態庫list。(built with BUILD_STATIC_LIBRARY)
2.3.12: LOCAL_SHARED_LIBRARIES:
要鏈接到本模塊的動態庫。
2.3.13：LOCAL_WHOLE_STATIC_LIBRARIES：
靜態庫全鏈接。 不同於LOCAL_STATIC_LIBRARIES，類似於使用--whole-archive
2.3.14：LOCAL_LDLIBS：
linker flags。 可以用它來添加系統庫。 如 -lz: LOCAL_LDLIBS := -lz
2.3.15: LOCAL_ALLOW_UNDEFINED_SYMBOLS:
2.3.16: LOCAL_ARM_MODE:
預設模式下，ARM目標代碼被編譯為thumb模式。每個指令16位。如果指定此變數為：arm。 則指令為32位。 LOCAL_ARM_MODE := arm 其實也可以指定某一個或者某幾個文件的ARM指令模式。
2.3.17: LOCAL_ARM_NEON:
設置為true時，會講浮點編譯成neon指令。這會極大地加快浮點運算(前提是硬體支持)
只有targeting 為 'armeabi-v7a'時才可以。
2.3.18：LOCAL_DISABLE_NO_EXECUTE：
2.3.19: LOCAL_EXPORT_CFLAGS:
定義這個變數用來記錄C/C++編譯器標志集合，
並且會被添加到其他任何以LOCAL_STATIC_LIBRARIES和LOCAL_SHARED_LIBRARIES的模塊的LOCAL_CFLAGS定義中 LOCAL_SRC_FILES := foo.c bar.c.arm
注意：此處NDK版本為NDK R7C.（不同NDK版本，ndk-build所產生的Makefile並不完全相同）
❺ android studio怎樣升級編譯器
安裝最新版的jdk，然後 eclipse配置好即可，如：
1、點擊eclipse菜單欄的window下拉菜單選中preference
2、點擊preference進入配置項管理對話框，展開java，再選中Installed JREs，右邊窗口就出現了jdk配置項了
3、點擊Add按鈕，進入jdk選擇對話框
4、這里會要求選中一個jre版本添加到工作空間中，我們選擇第三個Standard VM，點擊「Next>」按鈕，進入具體的jre選中頁面。
5、點擊「directory」按鈕，進入jdk所在文件夾選擇對話框，找到你的jdk解壓目錄，選中，點「確定」即可
6、選中後，回到自動回到eclipse的jdk選中對話框，選中的jdk相關信息會填入對話框中，點擊「finish」即可。
❻ Android 7.0有哪些優點
Android 7.0的有以下優點（來源：網路-Android 7.0）：
分屏多任務。進入後台多任務管理頁面，然後按住其中一個卡片，然後向上拖動至頂部即可開啟分屏多任務，支持上下分欄和左右分欄，允許拖動中間的分割線調整兩個APP所佔的比例。
全新下拉快捷開關頁。在安卓7.0中，下拉打開通知欄頂部即可顯示5個用戶常用的快捷開關，支持單擊開關以及長按進入對應設置。如果繼續下拉通知欄即可顯示全部快捷開關，此外在快捷開關頁右下角也會顯示一個「編輯」按鈕，點擊之後即可自定義添加/刪除快捷開關，或拖動進行排序。
通知消息快捷回復。安卓7.0加入了全新的API，支持第三方應用通知的快捷操作和回復，例如來電會以橫幅方式在屏幕頂部出現，提供接聽/掛斷兩個按鈕；信息/社交類應用通知，還可以直接打開鍵盤，在輸入欄里進行快捷回復。
通知消息歸攏。安卓7.0會將同一應用的多條通知提示消息歸攏為一項，點擊該項即可展開此前的全部通知，允許用戶對每個通知執行單獨操作。
夜間模式。安卓7.0中重新加入了夜間深色主題模式，該功能依然需要在系統調諧器中開啟，從頂部下劃打開快捷設置頁，然後長按其中的設置圖標，齒輪旋轉10秒鍾左右即可提示已開啟系統調諧器，之後用戶在設置中即可找到「系統調諧器」設置項。點開其中的「色彩和外觀」，即可找到夜間模式，開啟後即可使用全局的深色主題模式，同時亮度和色彩也會進行一定的調整，該功能可以基於時間或地理位置自動開啟。另外，系統調諧器中也提供了RGB紅綠藍三色調節滑動條，允許用戶手動精細調節，例如減少藍色或增加紅色以提供類似護眼模式的效果。
流量保護模式。安卓7.0新增的流量保護模式不僅可以禁止應用在後台使用流量，還會進一步減少該應用在前台時的流量使用。其具體實現原理目前尚不清楚，推測其有可能使用了類似Chrome瀏覽器的數據壓縮技術。此外，谷歌還擴展了ConnectivityManager API的能力，使得應用可以檢測系統是否開啟了流量保護模式，或者檢測自己是否在白名單中。安卓7.0允許用戶單獨針對每個應用，選擇是否開啟數據保護模式。
全新設置樣式。安卓7.0啟用了全新的設置樣式，首先每個分類下各個子項之間的分割線消失了，只保留分類之間的分割線。全新的設置菜單還提供了一個綠色的頂欄，允許用戶通過後方的下拉箭頭，快速設定勿擾模式等。除了勿擾模式外，頂欄菜單還可以顯示諸多其他的設置狀態，例如數據流量的使用情況，自動亮度是否開啟等。谷歌也在安卓7.0的設置中加入了漢堡菜單，在二級設置界面中的左上角，你就會看到這個漢堡菜單，點擊後即可看到所有設置項，方便用戶快速跳轉。
改進的Doze休眠機制。谷歌在安卓7.0中對Doze休眠機製做了進一步的優化，在此前的安卓6.0中，Doze深度休眠機制對於改善安卓的續航提供了巨大的作用。而在安卓7.0中，谷歌對Doze進行了更多的優化，休眠機制的使用規則和場景有所擴展，例如只要手動在後台刪掉應用卡片，關屏後該應用就會被很快深度休眠。
系統級電話黑名單功能。安卓7.0將電話攔截功能變成了一個系統級功能。其它應用可以調用這個攔截名單，但只有個別應用可以寫入，包括撥號應用、默認的簡訊應用等。被攔截號碼將不會出現在來電記錄中，也不會出現通知。另外用戶也可以通過賬戶體系備份和恢復這個攔截名單，以便快速導入其它設備或賬號。
菜單鍵快速應用切換。雙擊菜單鍵，就能自動切換到上一個應用。此外，如果你不停地點擊菜單鍵的話，就會在所有應用中不間斷地輪換，應用窗口會自動放大，頂部還會出現倒計時條，停止點擊且倒計時結束後，當前應用會自動放大並返回到前台。
無縫更新。由於現有安卓系統，更新過程非常繁瑣（下載、安裝、重新啟動等），谷歌在Android7.0中引入了無縫更新功能。當手機在無線網連接的情況下，更新就會在後台中悄悄地下載，然後在你手機下一次重啟的時候自動升級。
更高的性能。Android7.0建立了先進的圖形處理Vulkan系統，能少的減少對CPU的佔用。與此同時，Android7.0加入了JIT編譯器，安裝程序快了75%，所佔空間減少了50%。
更高的安全性。Android7.0加入了全新安全性能，其中包括基於文件的數據加密。
提升了系統的效率。Android7.0可以自動關閉用戶較長時間未使用的應用程序。在通知上新增了直接回復功能，並支持一鍵全部清除功能。
❼ 安卓編譯器是干什麼用的…具體一點…
剛剛碼完1000多字，手累了，就跟你簡單的說下。
編譯器就是編譯用的工具，安卓編譯器就是安卓系統編譯用的工具。
參考資料里有關於「編譯」的解釋。
❽ 為什麼安卓系統升級運行應用尤其是游戲可能會卡，但是ios系統沒這個問題
蘋果iOS系統為什麼比谷歌安卓更流暢
不少人都反應蘋果iPhone要比一般Android手機流暢，這是一個現象要說是大問題談不上，畢竟兩者是完全兩個不同的系統所以嚴格來說放在一起對比是不公平的。不過因為Android以及iOS是當下兩大主流操作系統，對比抗衡之類的說法自然難以避免。今天我們就來談談為什麼iOS產品在使用過程中會讓人覺得更加流暢一些，而為何一些Android手機則容易出現卡頓延遲的情況。
iOS手機為什麼比安卓流暢
優先順序別不同：iOS最先響應屏幕
當我們使用iOS或者是Android手機時，第一步就是滑屏解鎖找到相應程序點擊進入。而這個時候往往是所有操控開始的第一步驟，iOS系統產品就表現出來了流暢的一面，但Android產品卻給人一種卡頓的現象，更別說後續深入玩游戲或者進行其它操控了。這是為什麼?
其實這與兩個系統的優先順序有關，iOS對屏幕反應的優先順序是最高的，它的響應順序依次為Touch–Media–Service–Core架構，換句話說當用戶只要觸摸接觸了屏幕之後，系統就會最優先去處理屏幕顯示也就是Touch這個層級，然後才是媒體(Media)，服務(Service)以及Core架構。而Android系統的優先順序響應層級則是Application–Framework–Library–Kernal架構，和顯示相關的圖形圖像處理這一部分屬於Library，你可以看到到第三位才是它，當你觸摸屏幕之後Android系統首先會激活應用，框架然後才是屏幕最後是核心架構。
iOS系統優先處理Touch層級(圖片來自網路)
可以看到優先順序的不同導致了iOS產品以及Android手機在操控過程中的表現差異，當你滑動屏幕進行操控的時候，iOS系統會優先處理Touch層級，而Android系統則是第三個才響應Library層級，這是造成它們流暢度不同的因素之一。不過優先順序對系統流暢性有有影響不假，但並不是最絕對的，造成兩系統之間流暢性不一的現象還有其它因素，我們可以接著往下看。
硬體工作配置不同：iOS基於GPU加速
目前智能手機硬體裝備競賽當中，其實處理器等配置已經達到了一個瓶頸期，各大旗艦產品在硬體比拼當中基本上沒有太大的區別，而這時候GPU就成為了一個凸顯差異的重要因素。一些大型軟體像是3D游戲對GPU性能要求都會比較高，蘋果iPhone產品採用的Power VR SGX系列GPU在當下來說非常的主流，跑分測試數據證明了它並不會比一些旗艦級別的Android產品差勁。
A6處理器集成了Power VR SGX543顯示晶元(圖片來自網路)
而iOS系統對圖形的各種特效處理基本上正好都是基於GPU硬體進行加速的，它可以不用完全藉助CPU或者程序本身，而是通過GPU進行渲染以達到更流暢的操控表現。但是Android系統產品則並非如此，因為Android需要適應不同的手機硬體，需要滿足各種差異配置，所以很多圖形特效大多都要靠程序本身進行加速和渲染，並嚴重依賴CPU運算的操作自然會加大處理器的負荷，從而出現卡頓的問題。雖然Android 4.0以及4.1等更高版本中進行了改進將硬體加速設為默認開啟，但依舊無法做到所有特效全部都靠GPU進行加速。在很多Android手機裡面都自帶有「是否開啟GPU渲染」這個功能選項，不過開啟之後的改善也是微乎其微。
iOS圖形特效基於GPU加速渲染
屏幕最先響應的優先順序關系，再加上iSO本身GPU加速程序的特性，使得大家在操控過程中感覺iOS手機擁有著不錯的流暢性。因為它本身的整個流程都是在為最大化的流暢做服務，不管是第一印象的滑動接觸屏幕，還是你進一步使用程序之後的更深層操作都是如此。而GPU加速這點特性，應該是它優於Android系統流暢性的又一個因素。
開發機制不同：安卓機制效率低
Android的編程語言是JAVA，而iOS的則為Objective-C，不過要是說Android系統之所以有些卡頓是因為JAVA開發語言的關系，或者是拿它和Objective-C對比肯定會有人提出質疑。Objective-C的優勢是效率高但比較「唯一」，而JAVA的優勢則是跨平台不過運行效率相對偏低，其實這兩個編程語言所帶來的機制不同，就已經造成了各自系統之間的流暢性差異化。
Android系統架構(圖片來自網路)
iOS的Objective-C，編譯器gcc，而這個gcc編譯出來的代碼又被蘋果專為iOS架構優化到了極致，運行過程中也不需要虛擬機在中間插手，執行效率自然很高–引自網路。這一段話應該是iOS系統本身運行程序的執行過程，而Android是通過JAVA虛擬機來執行，並且系統需要佔用大量內存來換取執行速度，再加上不定期的內存自動回收機制，從而直接導致了卡頓現象的出現。
iOS系統架構有著不錯的運行效率
Android的JAVA編程本身運行效率比Objective-C低一些，而且再加上內存自動回收的機制，所以造成了一些卡頓不流暢的現象出現。但根據技術人員講解，現代的JAVA虛擬機效率已經不再是最大的瓶頸，Android 4.0系統版本之後的卡頓現象明顯得到了改善，所以這也是有用戶並沒有發現自己新買的Android手機出現太多卡頓現象的原因。看來編程語言和機制已經被Android進行了改善，這同樣也不是造成它與iOS流暢性偏差的唯一因素，不過影響卻是實實在在存在著。
系統設計不同：安卓APP無法統一
有了優先順序的關系，有了GPU加加速的影響，還有兩個系統各自編程以及機制的問題，似乎已經可以說明為什麼iOS相比Android更為流暢的原因。但最終還有一個問題是就是應用程序，很顯然用戶覺得卡頓都是在運行軟體的過程中產生，畢竟沒有安裝任何應用的初始出廠手機基本上都不存在不流暢或者延遲等現象，而且一款智能手機不安裝任何應用程序那也不符合用戶的購買初衷和使用行為。所以歸根結底，Android相比iOS的應用程序，到底出了什麼問題?
App Store是蘋果和iOS的另一個標志
因為iOS產品的封閉性，所以所有的APP運行對象都比較單一，因為每個應用程序都是被運行在iPhone，iPad等iOS產品當中，它們有著很高的硬體利用效率。因為iOS系統的配件供應商只有那麼幾家，CPU也是一年換一次，這點不像Android終端年年變月月變，開發者很難遇見未來終端解析度會包含多少種，GPU驅動會包含哪些等等，所以相對來說Android應用開發成本較高且收益較慢。而iOS應用開發則因為軟硬體垂直整合而受益，這樣一來蘋果自然就保證了應用本身其與硬體產品之間的完美結合程度。
其實Android和iOS兩大系統APP開發情況的不同，也正是它們開發和不開放的特性所造成的。如果要是拿旗艦Android手機加上一個專為這款旗艦產品設計的游戲，來和蘋果iPhone 5運行對比的話，你真的不會遇到Android旗艦機出現卡頓延遲的問題，為什麼因為這款游戲針對這款手機設計，在軟硬等方面都達到了最大化的兼容和優化，自然就不會出現停滯的現象。
Android App雖然奮力追趕在但數量和質量上並未超越iOS
而Android系統程序要被安裝在各種符合要求的手機上面，開發者也不可能針對所有的機器型號進行開發，只能在比較主流的機器上進行測試並保證運行效果，所以他們為了兼顧整個產品線只能不得不降低游戲體驗以達到高中低產品可以共用的效果。最後那些占據了Android終端份額的大量大眾用戶們由於自己的手機不是旗艦產品而得不到流暢的使用體驗，自然而然就會產生Android產品不如iOS流暢的抱怨。
寫在最後：
不管是iOS產品感覺比Android流暢還是真的比它流暢，其實說到底原因很簡單。蘋果會花費一年甚至兩年的時間去開發一個桌面icon，一種字體，並去測試屏幕點位，而Android終端中除了Nexus系列之外似乎沒有太多產品可以做到用這么長的時間去做這么細致的事情。有網友說得好，Android做的更多的是「讓系統跑起來」，而iOS擁有著蘋果做的更多的則是「讓系統以最高的效率跑起來」，或許這就是iOS產品比Android更流暢的原因吧。但更好的一面的是隨著谷歌對Android的持續升級以及各廠商對自家產品的循序改進，使得越來越多的Android終端正在擺脫卡頓不流暢的束縛，未來安卓用戶的期待同樣有望得到更好的滿足。