rubymotionandroid

1. leapmotion長方形盒子是仿的嗎

github搜索LeapMotion-for-android-Mobile，手機很方便的連接使用leap

2. reactnative 怎麼自定義控制項

人才稀缺的問題首先的問題是：移動開發人才的稀缺。看看那些培訓班出來的人吧，經過3個月的培訓就可以拿到8K甚至上萬的工作。在北京稍微有點工作經驗的iOS開發，就要求2萬一個月的工資。這說明當前移動互聯網和創業的火熱，已經讓業界沒有足夠的開發人才了，所以大家都用漲工資來搶人才。而由於跨平台的框架（例如PhoneGap，RubyMotion）都還是不太靠譜，所以對於稍微大一些的公司，都會選擇針對iOS和Android平台分別做不同的定製開發。而javaScript顯然是一個群眾基礎更廣的語言，這將使得相關人才更容易獲得，同時由於後面提到的代碼復用問題得到解決，也能節省一部分開發人員。代碼復用的問題ReactNative雖然強調自己不是「Writeonce,runanywhere」的框架，但是它至少能像Google的 j2objc 那樣，在Model層實現復用。那些底層的、與界面無關的邏輯，相信ReactNative也可以實現復用。這樣，雖然UI層的工作還是需要做iOS和Android兩個平台，但如果抽象得好，Logic和Model層的復用不但可以讓代碼復用，更可能實現底層的邏輯的單元測試。這樣移動端的代碼質量將更加可靠。其實ReactNative宣傳的「Learningonce,writeanywhere」本身也是一種復用的思想。大家厭煩了各種各樣的編程語言，如果有一種語言真的能夠統一移動開發領域，對於所有人都是好事。UI排版的問題我自己一直不喜歡蘋果新推出的AutoLayout那套解決方案，其實HTML和CSS在界面布局和呈現上深耕多年，Android也是借鑒的HTML的那套方案，蘋果完全可以也走這套方案的。但是蘋果選擇發明了一個Constraint的東西來實現排版。在企業的開發中，其實大家很少使用Xib的，而手寫Constraint其實是非常痛苦的。所以出現了 Masonry 一類的開源框架來解決這類同行的痛苦。我一直在尋找使用類似HTML+CSS的排版，但是使用原生控制項渲染的框架。其實之前 BeeFramework 就做了這方面的事情。所以我還專門代表InfoQ對他進行過采訪。BeeFramework雖然開源多年，而且有2000多的star數，但是受限於它自身的影響力以及框架的復雜性，一直沒有很大的成功。至少我不知道有什麼大的公司採用。這次Facebook的ReactNative做的事情相比 BeeFramework 更加激進。它不但採用了類似HTML+CSS的排版，還把語言也換成了JavaScript，這下子改變可以稱作巨大了。但是Facebook有它作為全球互聯網企業的光環，相信會有不少開發者跟進採用ReactNative。不過也說回來，Facebook開源的也不一定都好，比如 three20 就被Facebook放棄了，但是不可否認 three20 作為一個框架，在那個時期的特定價值。所以ReactNative即使沒有成功，它也將人們關注的焦點放在了移動開發的效率上了。很可能會有越來越多相關的框架因此涌現出來。MVVMMVVM在Web開發領域相當火熱，而iOS領域的 ReactiveCocoa 雖然很火，但是還是非常小眾。糾其原因，一方面是ReactiveCocoa帶來的編程習慣上的改變實在太大，ReactiveCocoa和MVVM的學習成本還是很高。另一方面是ReactiveCocoa在代碼可讀性、可維護性和協作上不太友好。而Web開發領域對MVVM編程模式的接受程度就大不相同了，在Web開發中有相當多的被廣泛使用的MVVM的框架，例如 AngularJS。相信ReactNative會推動MVVM應用在移動端的開發。動態更新終於說到最「雞凍人心」的部分了。你受夠了每次發新版本都要審核一個星期嗎？蘋果的審核團隊在效率上的低下，使得我們這一群狠不得每天迭代更新一版的敏捷開發團隊被迫每2周或1個月更新一次版本。很多團隊上一個版本還沒審核結束，下一個版本就做好了。ReactNative的語言是基於JavaScript，這必然會使得代碼可以從伺服器端動態更新成為可能。到時候，每天更新不再是夢想。當然，代碼的安全性將更一步受到挑戰，如何有效保護核心代碼的安全將是一個難題。總結不管怎麼樣，這確確實實是一個移動互聯網的時代，我相信隨著幾年的發展，移動互聯網的開發生態也會積累出越來越多寶貴的框架，以支撐出更加偉大的App出現。作為一個移動開發者，我很高興能夠成為這個時代的主角，用移動開發技術改變人們的生活。

3. 未來編程語言的發展方向

python是一種易讀的語言。它的格式非常整齊，而且在其他語言使用標點符號時，它經常使用英文關鍵字。與許多其他語言不同，它不使用大括弧來限定塊，語句之後的分號是可選的。與C或Pascal相比，它具有更少的語法異常和特殊情況。

Python是一種多範式編程語言。面向對象的編程和結構化編程得到了全面支持，其許多特性支持函數式編程和面向方面編程（包括元編程和元對象），所以Python是人工智慧機器人研發首選語言，也是未來最賺錢的計算機編程語言。

顯式比隱式更好

簡單勝於復雜

可讀性計數

Swift語言

當談到移動應用程序開發時，Swift是一種不同於其他語言的編程語言。2014年由AppleInc.發布，它是用於iOS移動應用程序開發的主要編程語言。

但是，Swift並不是Apple獨有的，它也逐漸走向了Linux。這種編程語言的好處在於它的開放源代碼，以及有趣的工作。下面是為什麼在開發移動應用程序時應該考慮Swift的一些更多的原因：讀取更簡單,它消除了對傳統約定的需要

需要更少的代碼

維護非常簡單，因為它統一了Objective-C的雙文件系統

它可以讓開發人員檢查他們的代碼，而無需開發整個應用程序

Ruby

你知道你只需要10分鍾就可以在Ruby上創建應用程序嗎？令人印象深刻的，對吧這就是為什麼全球各地的移動應用開發服務都喜歡這種編程語言的答案。此外，Ruby是其中增長最快的之一，因為它能夠支持多種平台。

但是，當涉及到移動應用程序開發時，在Ruby上創建應用程序需要使用RubyMotion和Rhodes等框架。通過利用這些框架中的任何一個的服務，開發人員可以為許多平台構建應用程序，例如Android，Windows，iOS以及OSX.許多熱門網站都使用Ruby編碼。這些包括Basecamp，Airbnb，Pixlr，彭博等等。想知道Ruby是如此的輝煌嗎？這里有一些非凡的功能包括：

它允許你使用現有的代碼

動態類型支持

任何人都可以使用它編碼

它包括面向對象的語言

4. 想成為一個Android開發工程師，還需學習其他什麼技術

開發android，需要掌握這些基礎。
①Java基礎知識 ②Linux基礎知識 ③資料庫基礎知識 ④網路協議 ⑤Android基礎知識 ⑥伺服器端開發知識①Java基礎知識
很多朋友一上手就開始學習Android，似乎太著急了一些。Android應用程序開發是以Java語言為基礎的，所以沒有扎實的Java基礎知識，只是機械的照抄別人的代碼，是沒有任何意義的。萬丈高樓平地而起，Java就是築起高樓的每一塊磚頭。那麼Java學到什麼程度才算是過關呢？我個人認為至少要掌握以下兩個方面的內容：
a)Java基礎語法：具體的知識點列表可以在這里下載：《Java知識點列表》V1.0。這部分內容沒有討價還價的餘地，必須爛熟於胸。至於具體的學習方法，可以看書或者是看視頻，但是關鍵是要多加練習，無論是書上的練習還是視頻裡面的練習，都需要仔仔細細的完成；
b)設計模式：由於在Android系統的框架層當中，使用了大量的設計模式，如果沒有這個方面的知識，對於Android的理解就會大打折扣。設計模式的種類非常之多，一個一個的全部掌握，是不現實的，必須首先掌握面向對象的基礎設計原則，有了這些基礎原則的支持，就可以舉一反三。這部分內容可以在《Effective Java》和《Agile.Software.Development：Principles,Patterns.and.Practices》這兩本書中找到。
②Linux基礎知識
大家都知道，Android系統的基礎是Linux操作系統。在開發過程當中，我們也需要使用到一些Linux命令。所以說一些Linux的基礎知識是必須的（話說現在的程序員，不懂Linux都不好意思跟人家打招呼），推薦大家看看《鳥哥的私房菜》這本書，寫的相當不錯；
③資料庫基礎知識
這個比較簡單，就是一個增刪改查的資料庫操作，可以看一下這本書：《SQL編程練習與解答》
④網路協議
至少需要學習兩種基礎的協議，HTTP協議與Socket協議；
⑤Android基礎知識

⑥伺服器端開發知識
由於很多Android應用程序都需要伺服器端的支持，所以掌握一些伺服器端開發知識還是非常有必要的。至於選擇哪一種伺服器端知識進行學習，就比較麻煩了，因為技術的種類實在是太多了：
a)Java EE：就是上面郵件當中所提到的SSH—Struts+Spring+Hibernate。這種技術的優點的功能完整、強大，已經使用了很多年，而且既然大家已經非常熟悉Java了，那麼學習SSH看起來也順理成章。但是使用這種技術開發伺服器端程序，非常麻煩。即使是一些簡單的功能，也可能需要大量的代碼和配置文件來實現；
b)PHP：簡單易學，開發快速。但是我們需要多學一種語言，是否得不償失，就要大家自己判斷了；
c).NET:這項技術的特點和Java EE差不多，但是要想掌握.NET，則需要掌握c#，也是個麻煩的事情；
d)ruby on rails：這是我個人最喜歡的伺服器端技術，簡潔，優雅，寥寥幾行代碼，就可以實現很復雜的功能，但是這需要Ruby語言知識作為基礎；
至於選擇哪一種知識，就看大家自己的判斷了，畢竟每個人想法不一樣，愛好也不相同。

安卓開發學習書籍
書的話建議買 精通Android2 ，或者 Android2高級編程 這兩本書，講解的細致，但是一定要結合sdk來看。國內的不要買。。。。（切身體會，千萬別買）
看完之後就可以自己動手做做項目了。

對於java基礎，我現在的感覺是 如果要深入學習android平台，java基礎一定要好（里邊包括各種java類庫的用法，本地代碼jni什麼的）。但如果平時隨便做做應用的話，會面向對象編程就完全可以了。
安卓開發學習學習網站
推薦你關注DevStore（主要是開發者服務商店）還有csdn和開源中國，都是開發者經常關注的網站。
DevStore（全球首家開發者服務商店）主要是整合開發者會用到的服務，可以實現在線對比評測，省去自己去網上搜索尋找的過程，還有sdk配置過程，很方便的，嘿嘿，我還在這個網站上寫評測掙過外快呢。
csdn是 中國最大的開發者技術社區，牛人還是很多的
開源中國是目前國內最大的開源技術社區，主要是軟體下載，源碼託管
自學的話平時就多看一些官方文檔，幫助文檔也是一個很好的參考資料，多看看，平時多敲代碼，多看住喲啊哈斯看規范，看完之後去敲代碼主要是在實踐過程中發現錯誤，多做項目自然多遇見問題，遇見問題解決問題，下次自然就知道怎麼解決，在實踐中發現真理。
當然可以的話有一個老師還是很好的，但是要記得要是的作用只是引導，師傅領進門修行在個人。

5. 我為什麼棄用Objective-C而選擇RubyMotion

關於Ruby語言

Hendrik以前不僅從未用過
Ruby，還沒少嘲笑過它。而現在Hendrik卻認為，Ruby絕對是一種有著清晰漂亮語法的編程語言。Ruby是一種讓你靈活機動的編程語言。

有時我們可能會對某種語言嗤之以鼻，然後說：「我絕不會在這種語言上浪費時間。」但Ruby一定不會讓你這么說。Ruby強大的元編程特性能夠幫助建立
領域專用語言（DSL）；Ruby精煉的語法能幫助我們有效解決一些特定問題和處理許多復雜問題的細節。

Ruby語言具有強大的反射機制與元編程功能

更重要的是，Java、PHP、Perl以及Objective-C都不具備的，而Ruby具備的特徵是：Ruby有一群追求完美的鐵桿粉
絲。Ruby程序員們選擇Ruby，意味著他們不僅僅選擇了一種編程語言，還選擇了一種生活方式。Ruby粉絲們所追求的是一種極簡的、精緻的編程體驗。

RubyMotion的優勢

RubyMotion是完全由Ruby語言編譯的二進制實現，它基於iOS構建並直接與iOS
API封裝，開發者可以訪問所有公開的iOS
API，也可以使用第三方的Objective-C庫和Gems。RubyMotion能夠讓Rails開發者編程時感到得心應手。

Rake是RubyMotion的創建和執行工具，它的程序是在
REPL環境下執行的。應用程序可在iOS模擬器上運行，RubyMotion提供一個互動式的Shell用來即時編碼和調試，能夠方便地實現互動式檢查和修改。

Hendrik對於RubyMotion是這樣評價的：在iOS開發方面，RubyMotion的核心思想是用優美的Ruby語言代替醜陋的Objective-C語言。

RubyMotion為Ruby程序員（尤其是那些因Objective-C和Cocoa Touch犯難的Ruby程序員）提供了一個iOS開發的入口。盡管RubyMotion誕生還不到一年的時間，但它為使用Ruby語言進行高效開發提供了很大便利。

RubyMotion的劣勢

1. 不提供免費版本。許多開發者不願嘗試RubyMotion多半是因為它不免費，盡管199美金的價格物有所值，但是開發者們往往需要先體驗產品，再考慮付費購買。如果未來RubyMotion能夠提供免費或試用版本，將會吸引更多的開發者前來參與。

2. 缺少Ruby高手。正因為RubyMotion比較年輕，所以RubyMotion社區（
RubyMotion community）缺少Ruby編程高手，社區中許多開發者的作品都比較簡單，比較初級。

3. 不能徹底擺脫Xcode。使用RubyMotion還是需要Xcode提供的SDK、模擬器以及數字簽名功能，只不過不需要全程使用Xcode，尤其是在撰寫代碼的時候。

正確看待RubyMotion

在一些蘋果開發社區中，我們時不時會看到一些污衊RubyMotion的言論。如果你經常瀏覽
HackerNews上對於RubyMotion的討論，你會很容易發現人們對RubyMotion不加遮掩的蔑視。

RubyMotion創始人Laurent Sansonetti

Rails也好，RubyMotion也好，都是前輩們嘔心瀝血的作品，是從知識、代碼、編程技巧等多個層面的經驗總結，他們的目的無非是
幫助大家用更精煉的代碼進行編程，使得程序開發更為簡便。所以對於新興的編程語言、工具，大家大可不必投以藐視的態度，這也是對前輩們勞動成果的一種尊
重。

6. android app自動化測試工具有哪些

1、Monkey是Android SDK自帶的測試工具，在測試過程中會向系統發送偽隨機的用戶事件流，如按鍵輸入、觸摸屏輸入、手勢輸入等)，實現對正在開發的應用程序進行壓力測試，也有日誌輸出。實際上該工具只能做程序做一些壓力測試，由於測試事件和數據都是隨機的，不能自定義，所以有很大的局限性。

2、MonkeyRunner也是Android SDK提供的測試工具。嚴格意義上來說MonkeyRunner其實是一個Api工具包，比Monkey強大，可以編寫測試腳本來自定義數據、事件。缺點是腳本用Python來寫，對測試人員來說要求較高，有比較大的學習成本。

3、Instrumentation是早期Google提供的Android自動化測試工具類，雖然在那時候JUnit也可以對Android進行測試，但是Instrumentation允許你對應用程序做更為復雜的測試，甚至是框架層面的。通過Instrumentation你可以模擬按鍵按下、抬起、屏幕點擊、滾動等事件。Instrumentation是通過將主程序和測試程序運行在同一個進程來實現這些功能，你可以把Instrumentation看成一個類似Activity或者Service並且不帶界面的組件，在程序運行期間監控你的主程序。缺點是對測試人員來說編寫代碼能力要求較高，需要對Android相關知識有一定了解，還需要配置AndroidManifest.xml文件，不能跨多個App。

4、UiAutomator也是Android提供的自動化測試框架，基本上支持所有的Android事件操作，對比Instrumentation它不需要測試人員了解代碼實現細節（可以用UiAutomatorviewer抓去App頁面上的控制項屬性而不看源碼）。基於Java，測試代碼結構簡單、編寫容易、學習成本，一次編譯，所有設備或模擬器都能運行測試，能跨App（比如：很多App有選擇相冊、打開相機拍照，這就是跨App測試）。缺點是只支持SDK 16（Android 4.1）及以上，不支持Hybird App、WebApp。

5、Espresso是Google的開源自動化測試框架。相對於Robotium和UIAutomator，它的特點是規模更小、更簡潔，API更加精確，編寫測試代碼簡單，容易快速上手。因為是基於Instrumentation的，所以不能跨App。配合Android Studio來編寫測試的簡單例子

6、Selendroid：也是基於Instrumentation的測試框架，可以測試Native App、Hybird App、Web App，但是網上資料較少，社區活躍度也不大。

7、Robotium也是基於Instrumentation的測試框架，目前國內外用的比較多，資料比較多，社區也比較活躍。缺點是對測試人員來說要有一定的Java基礎，了解Android基本組件，不能跨App。

8、Athrun是淘寶出的一個移動測試框架/平台，同時支持iOS和Android。Android部分也是基於Instrumentation，在Android原有的類基礎上進行了擴展，提供一整套面向對象的API。這里有詳細介紹。

9、Appium是最近比較熱門的框架，社區也很活躍。這個框架應該是是功能最強大的，

它的優點：

• 開源；

• 支持Native App、Hybird App、Web App；

• 支持Android、iOS、Firefox OS；

• Server也是跨平台的，你可以使用Mac OS X、Windows或者Linux；

它的哲理是：

• 用Appium自動化測試不需要重新編譯App；

• 支持很多語言來編寫測試腳本，Java、Javascript、PHP、Python、C#、Ruby等主流語言；

• 不需要為了自動化測試來重造輪子，因為擴展了WebDriver。（WebDriver是測試WebApps的一種簡單、快速的自動化測試框架，所以有Web自動化測試經驗的測試人員可以直接上手）；

• 移動端自動化測試應該是開源的；

它的設計理念：

• Client/Server架構，運行的時候Server端會監聽Client端發過來的命令，翻譯這些命令發送給移動設備或模擬器，然後移動設備或模擬器做出響應的反應。正是因為這種架構，所以Client可以使用Appium client libraries多種語言的測試腳本，而且Server端完全可以部署在伺服器上，甚至雲伺服器。

• Session，每個Client連接到Server以後都會有一個Session ID，而且Client發送命令到Server端都需要這個Session ID，因為這個seesion id代表了你所打開的瀏覽器或者是移動設備的模擬器。所以你甚至可以打開N個Session，同時測試不同的設備或模擬器。

• Desired Capabilities，其實就是一個鍵值對，設置一些測試的相關信息來告訴Server端，我們需要測試iOS、還是Android，或者換是WebApp等信息。

• Appium Server是Node.js寫的，所以可以直接用NPM來進行安裝。

• Appium Clients，Mac OS和Win下提供GUI，不需要裝Node.js，方便測試人員操作。

相關限制：

• 如果你在Windows使用Appium，你沒法使用預編譯專用於OS X的.app文件，因為Appium依賴OS X專用的庫來支持iOS測試，所以在Windows平台你不能測試iOS Apps。這意味著你只能通過在Mac上來運行iOS測試。

總結：

• 在iOS部分是封裝了UIAutomation；Android 4.2以上是用UiAutomator，Android 2.3 ~ 4.1用的是 Instrumentation，也就說Appium同時封裝了UiAutomator和Instrumentation。所以Appium擁有了以上幾大框架的所有優點：跨App，支持Native App、Hybird App、Web App，還支持N種語言來編寫你的測試腳本。

7. Android 想學一些後台的東西 是選 Python 還是 ruby

語言層面上這兩者有很多相似之處，不過從應用上，如果你想往 web 後端或者機器學習、數據挖掘上發展，選 Python；對前端感興趣就學 Ruby 吧，LESS、SCSS 這些 CSS 預處理工具都是 Ruby 寫的，而且 Ruby 開發者社區跟前端重疊度很高。另外，在 Mac 上，Ruby 的地位也是很高的。

偏後台關注性能的話,可以參考一下這個benchmark https。//www。techempower。com/benchmarks/
裡面有很多的測試方式,可以綜合看一下

當然開發效率也要綜合考慮,python和ruby的開發效率我估計都比較高,但 python 有一個好處是適用面很廣,很多後台運維的東東都可以用python很快搞定

8. Web前端開發與iOS終端開發的異同

語言
前端和終端作為面向用戶端的程序，有個共同特點：需要依賴用戶機器的運行環境，所以開發語言基本上是沒有選擇的，不像後台想用什麼就用什麼，iOS只能用Objective-C，前端只能javascript，當然iOS還可以用RubyMotion，前端還能用GWT/CoffieScript，但不是主流，用的人很少，真正用了也會多出很多麻煩。
這兩者有個有意思的對比：變數/方法命名的風格正好相反。蘋果一直鼓吹用戶體驗，寫代碼也不例外，程序命名都是用英文全稱並且要多詳細有多詳細，力求看變數和方法名就能知道是幹嘛的，例如application:didFinishLaunchingWithOptions:。而js因為每次都要從網路下載，要力求減少代碼體積，所以變數方法名是盡量用縮寫，實際上有代碼壓縮工具，無論變數名寫多長最終上線的效果是一樣的，但大家也都習慣了用短的命名，例如上述objc的application:didFinishLaunchingWithOptions:方法在js里習慣的命名是:$()。
objc與js都是動態語言，使用起來還蠻像，但objc是編譯型，速度快，很多錯誤也能在編譯過程中被發現，js是解釋型，性能依賴於解釋引擎，即使在強勁的v8引擎下性能也趕不上編譯型語言，語言太動態，變數完全沒有類型，寫起來爽，debug起來稍微費點勁。一直感覺js輕巧靈活放盪不羈充滿各種奇技淫巧，objc中規中矩沒c++ java那麼嚴肅也沒有js那麼靈活。
線程
前端開發幾乎不需要線程這個概念，瀏覽器實現上頁面HTML和CSS解析渲染可能與js不在同一個線程，但所有js代碼只執行在一條線程上，不會並發執行，也就不需要考慮各種並發編程的問題。在新的JS特性中可以創建worker任務，這樣的任務是可以另起一條線程並行執行的，但由於並不是所有瀏覽器都支持，不同線程傳遞數據各個標準定的還不一樣，使用場景也少，似乎沒有大規模用起來。對於資料庫操作/發送網路請求這樣的任務是在不同於js代碼執行線程的，不過這些都由瀏覽器管理，前端無需關心也無法影響這些線程，只需接收事件回調，不需要處理任何並發問題。
終端開發需要大量使用多線程，iOS有一條主線程，UI渲染都在這個線程，其他耗時長的邏輯或者資料庫IO/網路請求都需要自己另開線程執行，否則會佔用主線程的時間，導致界面無法響應用戶交互事件，或者渲染慢導致滾動卡頓。程序邏輯分布在多個線程里跑，需要處理好各種代碼並發執行可能帶來的數據不一致/時序錯亂之類的問題，並發也導致有些bug難以排查，一不留神就掉坑，需要適當用一些隊列/鎖保證程序的執行順序。iOS提供了一套多線程管理的方法GCD，已經把線程和隊列封裝得非常簡單易用功能強大，比其他端或後台是好很多了，但還是會花大量功夫在處理多線程問題上。
存儲
終端開發需要大量的數據存儲邏輯，手機APP不像瀏覽器，用戶打開瀏覽器必定是連著網，但打開一個APP時很可能是離線，也很可能處於網路狀況極差的移動GPRS，所以必須把之前請求回來的數據保存好。保存數據後又需要與服務端最新的數據同步，如果全量同步數據量太大，耗流量速度也慢，於是需要增量同步，需要與服務端一起制定實現增量數據返回的方案，需要處理好客戶端與服務端數據一致性的問題。當數據存儲量大結構復雜時，還需要利用好有限的內存做cache，優化各類存儲查詢性能。
前端在桌面端很少需要存儲，除非是Single Page App，不存儲自然就不需要數據更新的一系列工作，數據都是從後台取出拼接後直接顯示到頁面上，即使像微博有可以在頁面內不斷載入更多數據，數據也只存在於內存，不會持久化存儲，因為桌面端網速穩定，不計流量，所有數據可以直接從後端拿取，客戶端沒必要再做一套存儲。移動端那些做得很像原生APP的Web應用就跟終端開發一樣了，數據同樣保存到SQLite，存儲邏輯以及要處理的問題都差不多。
框架
在第三方框架上Web前端和iOS開發完全相反，Web原生弱小又十分開放，讓大量第三方框架和類庫可以施展拳腳，而iOS原生強大又十分封閉，導致第三方框架沒有多少生存空間。
瀏覽器一開始只為內容型的網頁而設計，js也只是這個網頁上能加點小特效的腳本語言，在Web應用時代跟不上發展，需要很多第三方庫和框架輔助，再加上前端開發是完全開放的領域，導致庫和框架百花齊放多如牛毛，在初期多數庫的作用集中在封裝dom操作，大家不斷重復造dom操作基礎庫的輪子，在一段時間百家爭鳴後獨尊jQuery，在有使用庫的網站中90%以上使用jq，幾乎成了個標准基礎庫。後期大家已經不再重復造這個基礎庫的輪子了，多了一些代碼組織和前端架構的框架，例如一些幫助項目模塊化的框架require.js，MVC框架backbone/angular.js等。
iOS開發蘋果已提供了完整的開發框架cocoa，而這框架在每一代系統中都在升級優化和添磚加瓦，開發模式也已經定型，第三方框架沒有多少生存空間，大量流行的開源項目是一些通用組件和庫，像網路請求庫AFNetworking，資料庫操作庫FMDB。而一些大的框架像beeFramework/ReactiveCocoa較難流行起來。
兼容
前端開發需要兼容大——量的瀏覽器，桌面的chrome，safari，ie6-ie10，firefox，以及各種套殼獵豹360等瀏覽器，移動端iOS/Android各自的瀏覽器，以及無限的不同的屏幕尺寸。看起來挺可怕，實際上也沒那麼難搞，只是拿出來嚇唬下人。桌面端chrome/safari以及各種套殼的極速模式用的都是Webkit，差異很小，firefox也大體遵從標准實現，與Webkit差別不大，舊的ie6/7就需要特別照顧，不過很多網站都不支持ie6了，移動端更是一家親，全是Webkit，除了新特性上的支持程度不一，其他差異不大。對於不同的屏幕尺寸，高端點的會用響應式布局，針對不同屏幕尺寸自適應到不同布局，一般點的桌面端定死寬度，移動端拉伸自適應寬度就搞定。
終端開發也需要兼容各種不同的系統版本和手機尺寸，Android不用說，iOS也有3.5/4/4.7/5.5/9.7英寸這些尺寸，不過兼容起來跟Web一樣挺容易，就是自適應寬度，iOS的UIKit把這些都處理好了，還有autolayout，sizeClass等高級特性可用，在尺寸上並不用花太多功夫。系統版本上iOS7為分水嶺，iOS7前後版本UI上差異比較大，需要做一些功夫兼容，不過iOS用戶更新換代很快，預計再過一兩年iOS7以下用戶就可以忽略了。
性能
終端和前端都是面向用戶的，性能優化目的都是盡快呈現內容，以及讓程序在用戶操作下流暢運行。終端主要關注的是存儲/渲染性能。當一個APP存儲數據量大，數據關系復雜時，數據查詢很容易成為性能瓶頸，需要不斷優化數據存取的效率，規劃數據IO線程，設計內存cache，利用好終端設備有限的內存，渲染上避免重復渲染，盡可能復用視圖，尋找最高效的渲染方案。
前端關注頁面載入速度，由於Web頁面的結構/樣式/程序/資源圖片都是實時請求的，要讓頁面更快呈現內容，就要優化這些請求，讓這些資源以最快速度載入下來，包括合並圖片/合並代碼減少請求數，壓縮代碼，並行請求，根據版本號緩存代碼請求，gzip壓縮，模塊/圖片懶載入等。此外跟終端一樣也關注渲染性能，遵從一些規則避免頁面reflow，避免使用CSS陰影這樣耗性能的特效，用CSS3動畫代替js等。
編譯
終端開發需要編譯的過程，把程序編譯成機器語言，再與各種庫鏈接後生成平台對應的可執行文件，最後由操作系統調度執行。在iOS終端開發中編譯和鏈接的規則蘋果已經在xcode這個開發工具上封裝好，一般開發可以不用關心，但有深層需求時還是需要跟編譯打很多交道，例如用編譯前端Clang自定義靜態代碼檢測規則，寫編譯腳本做自動化編譯和持續集成，打包生成靜態庫，根據鏈接後的可執行文件的組成優化APP體積等。
前端開發的程序則不需要編譯過程，只需要把代碼扔給瀏覽器，瀏覽器邊解析代碼邊執行。雖然js/css代碼寫完無需做任何事情瀏覽器就可以解析執行，但為了上面說的性能優化，前端代碼上線前會對所有代碼和資源文件進行處理，這些處理包括：壓縮合並js/css，合並css sprite圖，處理模塊依賴，處理代碼資源版本號，處理資源定位等。這個過程很像傳統程序的編譯，把給人看的代碼優化處理成給機器看的，並解決一些依賴關系，可以算是前端的編譯過程。像grunt.js/fis這些工具可以幫助完成這個編譯過程，通常前端編譯跟上線部署結合在一起，作為上線系統的一部分。
安全
前端和終端的安全性問題上雖然不需要像後端考慮得那麼多，但還是有些需要注意。在請求的安全上，終端和前端都一樣，用戶向後端發送的請求都需要經過層層路由，不知道在哪裡就被截獲篡改或回放了，於是需要做一些措施防禦這些情況，最常見的就是身份驗證，多是採用會過期的token形式代替用戶名密碼，防止被抓包後黑客可以永遠登陸這個賬號。數據安全要求高的會用加密傳輸，或者使用https，另外還需要看情況處理一些DNS劫持，運營商廣告植入等問題。
其他安全問題終端很少考慮，在未越獄的iOS機器上系統已經幫忙保證了整個APP運行環境的安全，而在越獄的機器下惡意程序擁有root許可權可以做任何事情，APP也難以防範。前端方面瀏覽器的特性使前端開發有幾個安全隱患，一是Web頁面上任意位置都可以動態插入js代碼，瀏覽器會無區別地執行這些代碼，二是身份驗證信息都統一保存在cookie里，三是頁面上可以隨意通過iframe嵌入其他網站的頁面。造成XSS、CSRF、cookie劫持這些攻擊手段，所以前端寫代碼時都需要考慮還這些安全問題，做好相應的防範，最簡單和重要的防範就是對所有用戶輸入輸出的內容做完整的過濾，避免頁面內被嵌入惡意代碼。
交互/開發
最後說下對這兩個領域在交互和開發上的個人感觸。以前在做Web前端時，感覺Web讓人機交互倒退了十年，交互都是硬邦邦的點擊—啪一下出來結果，滾動是一格格地刷新，很多人當時在鼓吹html5可以做出多麼炫的效果時，實際上FLASH在十年前就可以做出來了，還比最現代的瀏覽器更流暢。iPhone流行後，人機交互終於恢復了應有的水平，體驗上比Web流暢太多，指尖交互/流暢的動畫/便捷的滑動手勢/無限制的實現，主流終於恢復或超越了十年前Flash的水平。
但人機交互提升了，開發方式卻大倒退，Web的開發方式非常先進，用戶用到的都是最新版本，發現bug可以馬上上線秒修復，特別適用於互聯網環境下的快速迭代，而終端APP不行，撇開iPhone的審核不說，Android也無法做到保證用戶用的是最新的程序，用的都是傳統的客戶端更新的方式，bug的修復版無法及時給到用戶，無法一天上線幾十次，需要維護很多舊版本，開發方式倒退回Web時代以前。這都是因為移動網路不穩定以及流量有限造成的，移動端無法像桌面端瀏覽器那樣完全依賴網路，所以在移動網路穩定流量免費之前，開發方式都不會有多大變化。
另外並不看好HTML5，網路上說它可以取代APP說了三四年，到現在也沒什麼戰績，我看不到它的優勢，原生APP可以獲得更多的系統資源，更流暢的人機交互體驗，HTML5在這方面永遠比不上，而它在移動端網路和流量的限制下也無法發揮Web的開發優勢，所以它不會成為主流，只適合做一些輕量的小東西。

9. 安卓app主要用什麼編程語言的

安卓App用Java和Kotlin作為開發語言。

Google IO 2017宣布了 Kotlin 會成為 Android 官方開發語言。在Kotlin 語言出現之前，幾乎所有的安卓應用程序都是使用Java語言編寫的。

(9)rubymotionandroid擴展閱讀

Google在今年I/O2017開發者大會中宣布，正式把Kotlin納入Android程序的一級開發語言（First-classlanguage），並與開發團隊JetBrains合組非牟利基金會推廣Kotlin。據多間外國媒體報導，這是GoogleI/O開發者大會中引來最多歡呼聲的消息。

Kotlin將於AndroidStudio3.0得到支持，JetBrians指開發者不用再安裝額外元件或擔心兼容問題。Kotlin能與Java互通，但擁有Java不支持的功能。Google相信利用Kotlin可使Android程序開發更快捷有趣，但他們補充，此舉絕非取代Java和C++的官方支持。