Ionic系列——Ionic介紹

一、一張圖預覽混合應用開發

二、混合應用開發介紹

    智能手機日益普及，移動互聯網亂戰日趨白熱化，開發一個應用早就不是技術圈熱議的話題，iOS和Android上的App已經成了每一個互聯網產品的標配。 「惟快不破」也是中被移動互聯網人尊爲鐵律，快速迭代，高效開發，低成本上線是每個App開發團隊追求的目標。同時，隨着HTML 5的不斷升溫和智能手機硬件性能的提升，Hybrid App的概念應運而生。這種「Native搭臺，HTML 5唱戲」的Hybrid App開發模式一時間受到各個開發團隊追捧，快速進入了大量開發團隊，成爲主流開發模式。

一、HTML五、Native或混合型應用開發全接觸     http://blog.jobbole.com/21298/   基礎
二、Hybrid App開發實戰    http://www.infoq.com/cn/articles/hybrid-app-development-combat/   高級  介紹了混合開發的三種模式，工具，趨勢
三、別闖進Hybrid App的誤區    http://www.infoq.com/cn/articles/hybridapp-misunderstanding?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk  
四、原生應用、Web應用、混合應用優缺點分析    http://mobile.51cto.com/app-show-410661.htm

三、爲何選擇Hybrid開發模式

•折衷考慮——若是企業使用Hybrid開發方法，就能集二者之所長。一方面，Native讓開發者能夠充分利用 現代移動設備所提供的所有不一樣的特性和功能。另外一方面，使用Web語言編寫的全部代碼均可以在不一樣的移動平臺之間共享，使得開發和平常維護過程變得集中 式、更簡短、更經濟高效。

•內部技能——Web開發技能十分常見，許多企業都擁有這類技能。若是選擇Hybrid開發方法，在合適解決方案的支持下，Web開發者只要僅僅運用HTML、CSS和JavaScript等Web技能，就能構建App，同時提供Native用戶體驗。

•考慮將來——HTML5的可用性和功能都在迅速改進。許多分析師預測，它可能會成爲開發前端App的默認技術。 若是用HTML來編寫App的大部分代碼，而且只有在須要時才使用Native代碼，公司就能確保他們今天的投入在明天不會變得過期，由於HTML功能變 得更豐富，能夠知足現代企業一系列更普遍的移動要求。

四、混合應用開發誤區

一、爲了HTML 5而Hybrid App。
       HTML 5在Hybrid App模式中是一個最常被提起的概念。HTML 5做爲一個HTML 4.0.1和XHTML 1.0的升級版，基於舊版本有更強大的表現功能，並加入了Local Storage等技術，確實爲Web頁面提供了更大的想象空間和更多的可能性。但HTML 5處在目前的發展階段，受到瀏覽器兼容性和手機硬件性能水平的影響，它所能提供的功能與Native仍然有很大差距。
       因此，我認爲做爲工程師要明確一款App採用Hybrid App模式的根本緣由是什麼。做爲一款App其最根本的功能是知足使用者的需求，而並非服務某項新技術。所以當決定採用Hybrid App去構建一款應用時，應該從應用自己功能特色和整個團隊的開發資源配比統一考慮，是否有必要同時又有能力去駕馭一款「Native搭臺，HTML唱 戲」的Hybrid App。相似「HTML 5的時代已經到來，若是咱們不這麼作就變土鱉了，錯過這場技術革新的大潮，終將被這個時代所淘汰」的話真不是一個有責任心的工程師應該發出的聲音。
二、忽略關鍵因素
       在談到Hybrid App的場合咱們更多說起的是它有諸多優勢，如何架構一個Hybrid App，怎麼讓Web和Native和諧共處，然而Web開發中會被忽略的一些因素少被提起，這些因素又偏偏常常是一個Web頁面可否正常運行在App中的決定性因素。
       Web開發是基於PC的一種開發模式，開發者使用PC瀏覽器模擬App中的Web View進行調試。PC瀏覽器與手機Web View的區別是巨大的，能支配的CPU資源，最大佔有的內存，運行的網絡環境，鼠標操做與觸控操做的區別，瀏覽器對CSS/JS的解析和對事件處理，等 等。
      App工程師，不管是iOS仍是Android，最敏感的一個問題莫過於內存管理，而在Web開發則對這個問題沒有過多注意。這就常常致使同一個功 能界面Native實現中會經過一些技術手段，把內存容量控制在操做系統容許的範圍內保證App正常運行。若是以Web方式接入App的頁面沒有一個明確 的標準和嚴格的驗收機制，相應的Web實現則不會過多考慮這方面的問題，並且瀏覽器也沒有給前端工程師提供足夠的Api支持處理內存問題，致使在某些條件 下形成App沒法正常運行，甚至Crash。
       一樣的問題會出如今網絡環境方面，雖然如今wifi覆蓋愈來愈廣，3G網絡也日益普及，但App運行的網絡環境與PC相比仍然有着巨大差 距，wifi和蜂窩網絡的切換，基站變化等諸多因素都會致使網絡間歇性斷開。Web開發老是默認有一個穩定的網絡環境，所以在對於不穩定網絡環境問題的處 理上也有所欠缺。沒有明確的對於低速網絡或不穩定網絡訪問的處理，在不少狀況下這些頁面也會很是不給面子。
三、富交互致使體驗差
      這裏所謂的體驗問題一分爲二：一是與手機平臺默認交互習慣不一致的體驗，二是與一樣功能Native界面存在的體驗差距。
      不管在Android仍是iOS平臺上，都有各自的一套交互習慣，包括視覺風格，界面切換，操做習慣等，與Web習慣徹底不一樣。若是使用Web方式開發富交互的頁面，或多頁面功能就會出現這樣的問題。
      以iOS界面切換爲例，系統風格是新界面自右向左推入，後退時界面自左向右推出，而舊界面保持狀態。Web開發的默認習慣則是刷新頁面，不管新載入 頁面或是後退，都會對頁面進行刷新。所以使用Web模式開發多界面功能就面臨這樣的交互習慣差別，形成體驗上的損失。固然Web方式也可模擬Native 的交互方式，但這樣的模擬首先提升了開發成本，有悖於最初的高效原則，從效果上看，也很難達到Native的流暢性。
      另外一個方面，也是上述提到的與Native相比，一樣的功能在性能上存在巨大差距。Web界面上JS對HTML Node的操做須要消耗大量的CPU資源，手機CPU的性能還不能與PC相提並論，就算在智能手機之間，硬件水準也良莠不齊，一個能夠在iPhone 5上流暢運行的界面，跑到三星S III上極可能就卡住不動了。因此咱們常常能夠發現一些富交互頁面上的操做沒法達到使人滿意的流暢度，而流暢度也正是用戶評價一款App優劣的最直觀因 素。
四、跨平臺
       一次開發，跨平臺運行是Web的優點，這也是不少App採用Hybrid模式的重要緣由之一。兼容性問題在Web開發過程當中每每不被關注，但當下智能手機的軟硬件版本衆多，兼容性絕對是一個不容忽視的問題。
       以Android手機爲例，諸多主流品牌都有各自定製過的操做系統，瀏覽器內核對JS和CSS的解析，事件處理等方面都存在區別。以HTC One爲例重疊在一塊兒的層在某些狀況下會對點擊事件透傳，而其餘多數平臺則不存在這個問題。而且目前移動平臺的開發框架尚未徹底成熟，能夠很好的解決兼 容性問題。因此就要求開發者在開發過程當中要對兼容性作充分測試，對於某些特殊版本進行特殊處理。
       即便在相對統一的iOS平臺，不一樣版本之間也存在較大差別。例如：在iOS 4.x版本中CSS甚至不支持position fix的屬性，4英寸屏幕的設備沒法很好的支持apple-mobile-web-app-capable屬性，等等。
五、交互一致性
       交互一致性是一個很是容易被誤讀的概念，「一致性」常常被理解爲同一個應用在各類平臺和場景下要有一致性的體驗。我認爲在移動平臺開發過程當中，「一 致性」應該是App視覺和交互習慣與其運行平臺的習慣保持一致。而Web開發「一次開發，跨平臺運行」的特性與此存在必定程度上的衝突。
       以「返回上一頁面」的操做爲例，在iOS平臺上在頁面頂部始終存在一個44像素高的導航欄，左側有一個返回按鈕用於返回操做，而Android平臺 則習慣使用設備提供的返回鍵操做。這個返回按鈕在iOS平臺能夠經過絕對地址的方式鏈接到任何其餘頁面，而在Android平臺返回按鈕和設備的返回鍵則 可能指向不一樣的位置。
       例如這樣的一個流程：首頁->列表->篩選->刷新過的列表，此時的返回操做被指望是導向首頁，則頁面上的返回按鈕能夠經過絕對連接的方式實現，而Android設備的返回鍵則只能返回上一個篩選頁面，再次返回是篩選前的列表頁。

五、Hybrid開發總結

    移動端開發不能肯定哪種是最佳的開發方式，由於不存在最佳的開發方式，每種方式都有天生的優勢和侷限性，找到最適合本企業需求的一種開發方式是關鍵。
    過分依賴Hybrid方案會形成Web前端開發成本快速上升，甚至形成 App總體體驗降低，甚至形成功能缺失。不要爲了Hybrid而Hybrid，控制好方案中Native與Web的邊界。

六、Ionic介紹

•Ionic 是一個強大的 HTML5 應用程序開發框架，號稱 Advanced HTML5 Hybrid Mobile AppFramework 是 AngularJS 移動端解決方案 能夠幫助您使用 Web 技術，好比 HTML、 CSS 和Javascript 構建接近原生體驗的移動應用程序。 Ionic 主要關注外觀和體驗，以及和你的應用程序的 UI 交互，特別適合用於基於 Hybird 模式的 HTML5 移動應用程序開發。

•Ionic 是一個輕量的手機 UI 庫，具備速度快，界面現代化、美觀等特色。爲了解決其餘一些UI 庫在手機上運行緩慢的問題。

•漂亮的界面　追求性能 　專一原生　免費開源

Ionic中文網地址   http://www.ionic.wang/

Ionic官網地址   http://ionic.io/

七、Ionic開發現狀

    一、使用Ionic框架，能夠有效利用AngularJs的特性，極大的提供HTML5應用開發效率，質量，模塊化程度。根據咱們的經驗，使用ionic開 發，比使用基於jquery的移動框架，一樣功能代碼量會減小50%，開發速度提升一倍以上。
    二、與原生開發相比，不考慮原生應用開發不能跨平臺的因素，一樣 是在iOS上開發，使用ionic要比使用oc開發快一倍以上。用戶體驗方面，在iOS和高端Android設備（1500元以上的手機，平板）上，與原 生應用差異不大，通常用戶沒法分辨出是HTML5的。
    三、目前來看，市場競爭激烈的App，暫時還不適合用HTML5開發，即便HTML5徹底能實現業務需 求，例如去哪兒，攜程這種競爭性的App。但在企業應用領域，使用ionic有明顯優點，咱們已經用ionic框架上線了iPad和android Pad企業應用。

八、Ionic框架包含三部份內容

Ionic   Css樣式     http://www.ionic.wang/css_doc-index.html
Ionic   AngularJS 擴展     http://www.ionic.wang/js_doc-index.html
Ionic   Icon庫      http://ionicons.com/

九、Ionic學習資料

•匯智網上的Ionic教程
•Ionic中不少東西官網文檔並無寫的很全，因此要看源碼
•GitHub上找項目源碼學習

十、Angular使用場合

適合：
一、單頁面應用程序
二、Angular更適合於CRUD的管理系統開發。
三、也很是適合模塊化，分層化，數據綁定
四、hybrid開發神器

不適合：
一、內容網站，須要SEO的。(SEO目前也有了prerender解決方案)二、交互頻繁的，如遊戲之類交互體驗網站。（單頁面應用程序）
三、太過於簡單的頁面。（由於要考慮mvc,注入等，就會笨重）

單頁Web應用或引領下一代Web新趨勢   http://www.csdn.net/article/2012-12-10/2812658-Single-Page-Applications

十一、Angular開發

Angular代碼規範
http://www.reqianduan.com/1722.html
Yeoman  前端開發神器
http://my.oschina.net/u/1416844/blog/196199
25 款最有用的 AngularJS 工具
http://www.oschina.net/news/60200/bestl-angularjs-tools
推薦 15 個 Angular.js 應用擴展指令
http://www.oschina.net/translate/15-directives-to-extend-your-angular-js-apps

Angular樣例 http://www.ngnice.com/showcase/#/input/file

十二、Angular2介紹

    移動：新的版本將專一於移動應用的開發。依據是它更容易處理桌面方面的事情，一旦挑戰涉及到移動（性能、加載時間），注重這方面會使問題獲得解決。
    模塊化：各個模塊將從Angular的核心中移除，從而得到更好的性能。這意味着你能夠選擇你須要的零件。
    現代化：Angular 2.0將把ES6和「常青」現代瀏覽器（自動更新到最新版本）做爲目標。這意味着開發者能夠專一於業務領域相關的代碼。

    AngularJS 2.0會有哪些新特性？  http://www.csdn.net/article/2015-03-03/2824087

    Angular2官網    https://angular.io/

1三、ECMAScript6介紹

    ECMAScript和JavaScript的關係是，前者是後者的規格，後者是前者的一種實現。在平常場合，這兩個詞是能夠互換的。
2015年6月，ECMAScript 6正式經過，成爲國際標準。
    Node.js和io.js（一個部署新功能更快的Node分支）是JavaScript語言的服務器運行環境。它們對ES6的支持度，比瀏覽器更高。經過它們，能夠體驗更多ES6的特性。
    這個標準的牛逼之處就在於會逐步統一前端，由於新增長的module,異步編程，Generator函數這些東西在angular中和node中都有很好的實現了。而他們又是按照ECMAScript5規範寫的。

    ECMAScript6學習網址    http://es6.ruanyifeng.com/#docs/intro

1四、Cordova介紹

    Cordova提供了一組設備相關的API，經過這組API，移動應用可以以JavaScript訪問原生的設備功能，如攝像頭、麥克風等。
    Cordova支持以下移動操做系統：iOS, Android,ubuntu phone os, Blackberry, Windows Phone, Palm WebOS, Bada 和 Symbian。
    Cordova是貢獻給Apache後的開源項目，是從PhoneGap中抽出的核心代碼，目前(PhoneGap和Apache Cordova之間的)惟一區別是下載的包的名字，這會持續一段時間。

1五、Phonegap和cordova的關係

          Adobe將會繼續以Cordova加上PhoneGap Build和Adobe Shadow的組合提供PhoneGap。　早在2011年10月，Adobe收購了Nitobi Software和它的PhoneGap產品，而後宣佈這個移動開發框架將會繼續開源，並把它提交到Apache Incubator，以便徹底接受ASF的管治。咱們想知道爲何Adobe會收購Nitobi並開源PhoneGap，尤爲是爲何PhoneGap還會繼續，若是另外一個項目應該完成它的工做?
         最近Adobe出現了一系列的溝通問題，包括處理Flash、Flex、AIR和PhoneGap的過渡問題。幾個月以後，Adobe終於搞清楚他們對Flash和Flex的規劃了，如今發帖澄清圍繞着PhoneGap的一些謎團。
        PhoneGap的項目主管Brian LeRoux指出開源PhoneGap的決定在Adobe收購Nitobi以前就作出了，因爲Adobe如今擁有PhoneGap商標，他們不得不換個名 字。第一個選中的名字是Callback，毫無創意，所以再改一次，產品如今叫Apache Cordova。
        雖然不少人認爲PhoneGap這個名字不會再用，由於代碼已在一個不一樣的名字下面，但現實的狀況是，Adobe想 繼續在PhoneGap品牌下提供Cordova。在不久的未來，Adobe會把Cordova、PhoneGap Build(一個在線應用程序構建服務)和Adobe Shadow(一個檢查和預覽工具)打包起來，未來極可能還會向PhoneGap包添加更多移動開發工具。
       目前還不清楚Adobe是否會鞏固PhoneGap品牌，雖然開發者對它已經耳熟能詳，或者是否換成另外一個名字。此 外，也不清楚他們是否會在Cordova代碼之上構建私有代碼，但LeRoux的帖子留下了線索：「目前(PhoneGap和Apache Cordova之間的)惟一區別是下載的包的名字，這會持續一段時間(加劇語氣)。」

1六、ng-cordova介紹

    ngCordova是在Cordova Api基礎上封裝的一系列開源的AngularJs服務和擴展，讓開發者能夠方便的在HybridApp開發中調用設備能力，便可以在AngularJs代碼中訪問設備能力Api。    在cordova插件的sucess和error js回調方法中，是沒法使用 angularjs的$scope對象和注入的方法的，只能訪問全局的方法和變量，這樣會致使不少麻煩，必須使用傳統的js方法寫不少難看的代碼。使用 ngCordova應該能夠解決這個問題。    Ng-cordova官網   http://ngcordova.com/docs/plugins/