前言
Hybrid App：PhoneGap、Titanium、WeX5、AppCan...
優(yōu)于Hybrid App：React native、Weex……
Native APP: 原生應(yīng)用
?。?！重點(diǎn)?。?！
Hera 當(dāng)下、未來的技術(shù)方向：https://github.com/weidian-inc/hera/projects/1?
Android實(shí)現(xiàn)原理：Native層[HeraActivity]作為邏輯流程控制中心，建立了頁面視圖層[Page]與AppService應(yīng)用邏輯層[AppService]之間的聯(lián)系，處理兩層之間的事件傳遞及數(shù)據(jù)流轉(zhuǎn)，同時(shí)也處理API的調(diào)用并返回結(jié)果
SDK本身提供了豐富的API實(shí)現(xiàn)，同時(shí)也提供了擴(kuò)展API的接口，方便被接入的App實(shí)現(xiàn)自定義的API功能。由于SDK運(yùn)行于獨(dú)立進(jìn)程，因此通過進(jìn)程通信的方式調(diào)用宿主提供的擴(kuò)展API。SdkApiManager和HostApiManager分別對(duì)應(yīng)SDK內(nèi)部API的管理和擴(kuò)展API的管理。
iOS實(shí)現(xiàn)原理：SDK Native層WDHManager作為邏輯流程控制中心，建立了頁面視圖層Page與應(yīng)用邏輯層WDHService之間的聯(lián)系，處理兩層之間的事件傳遞及數(shù)據(jù)流轉(zhuǎn)，同時(shí)也處理API的調(diào)用并返回結(jié)果。
SDK本身提供了豐富的api實(shí)現(xiàn)，同時(shí)也提供了擴(kuò)展api的接口，方便被接入的App實(shí)現(xiàn)自定義的API功能。WHHybridExtension負(fù)責(zé)API的調(diào)配與擴(kuò)
正文
學(xué)習(xí)以上任何框架最好有以下基礎(chǔ)（Html + css + js）：https://www.w3cschool.cn/javascript/js-tutorial.html
例如：做React native 兩端（iOS android）通用的代碼需要很深厚的Html + css + js功底，但是同樣，既然要求同必然會(huì)涉及存異，做兩端通用設(shè)計(jì)初期需要做部分過橋文件的編寫。這就涉及到了android過橋文件、objective-c/swfit過橋文件編寫。 React Native 的代碼只兼容兩個(gè)平臺(tái)（iOS 和 Android），并沒有兼容 Web 端訪問。這里是因?yàn)?Facebook 開發(fā)人員認(rèn)為 Web 端天生兼容性就巨麻煩，而且平臺(tái)差異性是注定存在而且也要保留的，所以 React Native 的目標(biāo)是 Learn once, write anywhere ，而不是 Write once, run anywhere 。
綜上要做iOS、Android以及Web的三端一套。1.創(chuàng)業(yè)公司首推Hera（成本小、受限制大）2.有實(shí)力的公司可以嘗試在react-native 上做做文章。
無論基于何種框架都是存在優(yōu)劣的。我門該如何選擇？我給出的建議是若要做三端一套的框架選型暫時(shí)首推React-native 。人手配備標(biāo)準(zhǔn)為：精通objective-c/swfit + js 1人? ? ?精通android+js 1人? ?統(tǒng)籌框架難點(diǎn)、通信分工 1人? 功能開發(fā)（Html + css + js ） 3-4人。其成本并不低于原平臺(tái)代碼開發(fā)人員。故而我個(gè)人建議移動(dòng)端的框架選型面向的其實(shí)是用戶，而不是公司的發(fā)展。能在其中節(jié)約人力和財(cái)力固然對(duì)公司是好的。但并不是所有的公司都有精力、時(shí)間去做這樣的轉(zhuǎn)型。但！無論何種代碼的編寫都要有迭代、更新、重構(gòu)。這也就存在一個(gè)血淋淋的事實(shí)。程序員永遠(yuǎn)都到寫代碼！故而以上因素永遠(yuǎn)都在影響著公司管理層的人員對(duì)框架選型騷動(dòng)。選型選什么不重要，重要的是適合公司當(dāng)前、以后階段業(yè)務(wù)發(fā)展的良性循環(huán)才是最重要的、也是最明智的。
對(duì)原安卓開發(fā)人員轉(zhuǎn)型建議（iOS同理）：
1.1. 基本
搭架子?
1. 目前以多Tab + Fragment為主，已成型;?
2. 項(xiàng)目結(jié)構(gòu)
異步加載圖片 – UIL,Glide
網(wǎng)絡(luò)請(qǐng)求 – robospice + google http client
Json – jackson2
緩存機(jī)制 – robospice
自動(dòng)更新 – lesscode
事件通信 – event bus, otto
數(shù)據(jù)庫 – litepal
內(nèi)存檢測(cè) – leakcanary
其他各種UI和功能類庫
1.2. 服務(wù)
統(tǒng)計(jì)服務(wù) – 友盟、百度
云存儲(chǔ)服務(wù) – 七牛
推送服務(wù) – 極光，個(gè)推，小米
支付服務(wù) – 支付寶、微信、銀聯(lián)、連連支付、現(xiàn)在支付、充話費(fèi)、語音支付等
分享 – share sdk
第三方登錄 – 各大開放平臺(tái)sdk
1.3. 工程
多渠道打包 – gradle flavor
持續(xù)集成 – jenkins
APK瘦身 – Proguard, AndResGuard, webp等
2. 持續(xù)優(yōu)化的重要性
把一個(gè)項(xiàng)目做到可以滿足需求的基本運(yùn)行，對(duì)于開發(fā)者開說，說明你成功了，但是只是第一階段的成功：實(shí)現(xiàn)。
接下來你要面臨的問題，很有可能會(huì)是一大波新的變化需求，代碼混亂，性能低下，錯(cuò)誤異常率下不來等等，這就需要：優(yōu)化，并且是持續(xù)的優(yōu)化。
持續(xù)的優(yōu)化，不僅能解決很多問題，而且能保證代碼有效健壯的發(fā)展，這對(duì)開發(fā)者來說，尤為重要，誰都喜歡寫更好的代碼，都不喜歡改那些亂到掉渣的代碼。
做項(xiàng)目評(píng)估的時(shí)候，考慮一下基本優(yōu)化的工作量；迭代版本的時(shí)候，留一定的持續(xù)優(yōu)化的工作量。
3. 困難挫折警示
經(jīng)常碰到困難，經(jīng)常被技術(shù)問題卡住，經(jīng)常粗心大意 … …
說明什么？
要么太沒經(jīng)驗(yàn)，要么能力不足。
我們可以從多個(gè)方面著手拓展技術(shù)視野、提高動(dòng)手能力、優(yōu)化放錯(cuò)機(jī)制等等：
關(guān)注社區(qū)動(dòng)向
官方資訊，github, 技術(shù)博客（國(guó)內(nèi)外），視頻（慕課網(wǎng)、極客學(xué)院等）… …
勤于實(shí)踐
把別人的一些好的經(jīng)驗(yàn)或者效果，動(dòng)手實(shí)現(xiàn)，轉(zhuǎn)化為自己的經(jīng)驗(yàn)，甚至進(jìn)一步升華成更好的成果。
多參與項(xiàng)目
珍惜參加項(xiàng)目的機(jī)會(huì)，多參與，用行動(dòng)改進(jìn)，不做旁觀者。
善假于物
多學(xué)習(xí)一些工具git,linux,python,tcpdump等等，用的比較多的，最好能吃透一點(diǎn)（比如git），小工具，大用處。
細(xì)節(jié)決定成敗
成也細(xì)節(jié)，敗也細(xì)節(jié)。會(huì)區(qū)分同類的不同點(diǎn)，能從小的地方改進(jìn)，遇到困難沉著應(yīng)付一個(gè)一個(gè)的攻克細(xì)節(jié)…
