React native充分利用了Facebook的現(xiàn)有輪子，是一個很優(yōu)秀的集成作品，并且我相信這個團隊對前端的了解很深刻，否則不可能讓Native code「退居二線」。
建平網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)建站,建平網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為建平超過千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的建平做網(wǎng)站的公司定做！
對應(yīng)到前端開發(fā)，整個系統(tǒng)結(jié)構(gòu)是這樣：
JSX vs HTML
CSS-layout vs css
ECMAScript 6 vs ECMAScript 5
React native View vs DOM
無需編譯，我在第一次編譯了ipa裝好以后，就再也沒更新過app，只要更新云端的js代碼，reload一下，整個界面就全變了。
多數(shù)布局代碼都是JSX，所有Native組件都是標(biāo)簽化的，這對于前端程序員來說，降低了不少學(xué)習(xí)成本，也大大減少了代碼量。不信你可以看看JSX編譯后的代碼。
復(fù)用React系統(tǒng)，也減少了一定學(xué)習(xí)和開發(fā)成本，更重要的是利用了React里面的分層和diff機制。js層傳給Native層的是一個diff后的json，然后由Native將這個數(shù)據(jù)映射成真正的布局視圖。
css-layout也是點睛之筆，前端可以繼續(xù)用熟悉的類css方式來編寫布局，通過這個工具轉(zhuǎn)換成constrain布局。
系統(tǒng)只有js-objc的單向調(diào)用，就是把原生UI組件的方法通過javascritcore或者webview（低版本iOS）映射到j(luò)s中來，整個調(diào)用過程是異步的，這樣的設(shè)計令React native可以讓js運行在桌面chrome中，通過websocket連接Native code和桌面chrome，極大地方便了調(diào)試。對其中的機制Bang的一篇文章寫得很詳細(xì)，我就不拾人牙慧了：React Native通信機制詳解 ? bang’s blog 。但這樣設(shè)計也會帶來一些問題，后面說。
點按操作也被抽象成了一組組件（TouchableXXX），這種抽象方式是我在之前做類似工作中沒有想到的。facebook還列出Native為什么和web「手感」不同的原因：實時的點按反饋和取消能力。React Native 這套相應(yīng)機制設(shè)計得很完善，能像Native code那樣控制整個點按操作的所有過程。
Debug相當(dāng)方便！修改了js以后，通過內(nèi)建的nodejs watcher編譯成bundle，在模擬器里面按cmd+r就可以看到效果。而且按cmd+d，可以打開一個chrome窗口，所有的js都移到了chrome里面運行，所以什么斷點單步打調(diào)用棧，都不在話下。
上面的既是特點也是優(yōu)點，下面說說缺點，或者應(yīng)該說：「仍然遺留的問題」，在我看來，這個方案已經(jīng)超越了Hybird方案。
系統(tǒng)仍然（不得不）依賴原生組件暴露出來的組件和方法。舉兩個例子，ScrollView這個組件，在Native層是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，這些事件在現(xiàn)有的版本都沒有暴露，基本上做不了組件聯(lián)動效果。另外，這個版本中有大量組件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反過來看，剩余的都是一些抽象程度極強的基本組件。這樣，用戶必須在不同的平臺下寫兩套代碼，而且所有能力仍然強烈依賴 React native 開發(fā)人員暴露的接口。
由于最外層是React，初次學(xué)習(xí)成本高，不像往常的Hybird方案，只要多學(xué)幾個JS API就可以開始干活了。當(dāng)然，React的確讓后續(xù)開發(fā)變得簡單了一些，這么一套外來的（基于iOS）、殘缺不全的（css-layout）在React的包裝下，的確顯得不那么面目可憎了。
另外，React Native仍然很不完善。文檔還不全，我基本上是看著他的示例代碼完成的demo，集成到已有app的文檔也是今天才出來。按照官方的說法，Android版本要到半年后才發(fā)布：Blog | React ，屆時整個系統(tǒng)設(shè)計可能還會有很大的變化。
PS，在使用Tabbar的時候，我驚喜的發(fā)現(xiàn)他們居然用了iconfont方案，我現(xiàn)在手頭的項目中也有同樣的實現(xiàn)，不過API怎么設(shè)計一直很頭疼。結(jié)果，我發(fā)現(xiàn)他是這么寫的：
TabBarItemIOS
name="blueTab"
icon={_ix_DEPRECATED('favorites')}
....
在 _ix_DEPRECATED 的定義處，有一句注釋： // TODO(nicklockwood): How can this fit our require system?
以上。
下面是一周前，在React native還沒開源的時候，通過反解ipa的一些分析過程，有興趣的可以看看。
------------------------簡單粗暴的分割線--------------------
背景和調(diào)研手段
React Native還沒開源，最近和組里兄弟「反編譯」了Facebook Group（這個應(yīng)用是用React Native實現(xiàn)的）的ipa代碼，出來幾百個JS文件，格式化一下，花了幾天時間讀了一下源碼，對React Native的內(nèi)部核心機制算是有了一個基本了解。
React Native的核心實現(xiàn)：
先簡單說幾點，詳細(xì)的等回頭更新。
1. React Native里面沒有webview，這貨不是Hybrid app，里面執(zhí)行JS是用的
JavascriptCore。
2. 再說React Native的核心，iOS Native code提供了十來個最基本核心的類（RCTDeviceEventEmitter、RCTRenderingPerf等）、或組件（RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等），然后由React Native的JS部分，組成二十來個基本組件（Popover、Listview等），交由上層的業(yè)務(wù)方來使用（THGroupView）。
3. 就如他們在宣傳時所說，他們實現(xiàn)了一套類似css的子集，用來解決樣式問題，相當(dāng)復(fù)雜和強大，靠這個才能將Native的核心組件組成JS層的基本組件再組成業(yè)務(wù)端的業(yè)務(wù)組件，應(yīng)該是采用facebook/css-layout · GitHub的C語言版本實現(xiàn)的（在ppt中我們看到了類似flex-direction: column一類的代碼，這個正是css-layout支持的語法）。
4. 在React Native中，寫JS的工程師解決的是「將基本組件拼裝成可用的React組件」的問題，寫Native Code的工程師解決的是「提供核心組件，提供足夠的擴展性、靈活性和性能」的問題。
React Native的設(shè)計考慮：
ReactJS對React Native有著直接的影響（我沒在生產(chǎn)環(huán)境中用過React，只看過代碼用過Angular，如果有誤請指出）
ReactJS里面有這樣的設(shè)計：
1. ReactJS 的大工廠入口createElement返回的不是某個實體DOM對象，而只是一個數(shù)組
2. 通過源碼中 ui/browser/ 目錄中的代碼，將這個數(shù)組轉(zhuǎn)換成DOM
3. 底層的渲染核心是可以更換的
另外，F(xiàn)acebook自己有JSX，css-layout等開源項目，基于這些，如果要做一個用 JS來開發(fā)Native app的東西，很自然就想到了一套最有效率的搞法：
1. 將 ui/browser 里面的代碼替換成一套 Native 的橋接JS（實際上，iOS版是通過
injectGenericComponentClass方法，將核心組件的方法注入到JS里面 ），就直接復(fù)用React的MVVM，自動將數(shù)據(jù)映射到Native了
2. Native code里面實現(xiàn)三組核心API，一組提供核心組件的API（create、update、delete），一組事件方法（ReactJS里面的EventEmitter ），一組對css進(jìn)行解析（css-layout）以及返回Style的ComputedStyle（React Native里面叫meatureStyle）。
這樣，用上了ReactJS本身的所有核心功能和設(shè)計思路，Native的開發(fā)也足夠簡單。
那，React Native是什么？
其實這東西從Native開發(fā)來說，相當(dāng)于重新發(fā)明了一個瀏覽器渲染引擎并且套一個React的殼，從Web開發(fā)角度來說，就是把原來React的后端換成了Native code來實現(xiàn)，就跟Flipboard最近搞的React Canvas 一樣： Flipboard · GitHubreact-canvas
React Native的優(yōu)勢和劣勢：：
優(yōu)勢相對Hybird app或者Webapp：
1. 不用Webview，徹底擺脫了Webview讓人不爽的交互和性能問題
2. 有較強的擴展性，這是因為Native端提供的是基本控件，JS可以自由組合使用
3. 可以直接使用Native原生的「牛逼」動畫（在FB Group這個app里面，面板滑出帶一點果凍彈動，面板基于某個點展開這種動畫隨處可見，這種動畫用Native code來做小菜一碟，但是用Web來做就難上加難）。
優(yōu)勢相對于Native app：
1. 可以通過更新遠(yuǎn)端JS，直接更新app，不過這快成為各家大型Native app的標(biāo)配了…
劣勢：
1. 擴展性仍然遠(yuǎn)遠(yuǎn)不如web，也遠(yuǎn)遠(yuǎn)不如直接寫Native code（這個不用廢話解釋了吧）
2. 從Native到Web，要做很多概念轉(zhuǎn)換，勢必造成雙方都要妥協(xié)。比如web要用一套CSS的閹割版，Native通過css-layout拿到最終樣式再轉(zhuǎn)換成native原生的表達(dá)方式（比如iOS的Constraint\origin\Center等屬性），再比如動畫。另外，若Android和iOS都要做相同的封裝，概念轉(zhuǎn)換就更復(fù)雜了。
更新1：添加了React對React Native的影響。
更新2：基本確定其使用了 css-layout，添加了對React Native的總結(jié)
更新3: React native已經(jīng)開源了： React Native，只有iOS版。我寫了幾個demo，簡單看了看objc代碼并和開源前的我們的一些結(jié)論（見后文）交叉驗證。簡單地從前端工程師和系統(tǒng)整體角度說一下React native的特點和優(yōu)劣吧。
更新4: 補充了幾條優(yōu)勢和與前端開發(fā)的對照
最為一個iOS開發(fā)人員，最近在研究rn開發(fā)，坑還挺多的。下面我就來說說iOS接入rn的步驟以及我遇到的問題.
前提：電腦已經(jīng)安裝過React-Native相關(guān)環(huán)境;
創(chuàng)建：首先我們創(chuàng)建一個iOS項目，我命名為React-IOS；
這個相信大家都會創(chuàng)建，就不說了。
platform :ios, ‘9.0’
target 'React-IOS' do
pod'yoga', :path = './reactnative/node_modules/react-native/ReactCommon/yoga'
pod'React', :path = './reactnative/node_modules/react-native', :subspecs = [
'Core',
'RCTImage',
'RCTNetwork',
'RCTText',
'RCTWebSocket',
'CxxBridge', # 如果RN版本 = 0.45則加入此行
'DevSupport', # 如果RN版本 = 0.43，則需要加入此行才能開啟開發(fā)者菜單
#'BatchedBridge',
# 添加你的項目中需要的其他三方庫
]
# 如果RN版本 = 0.45則加入下面三個第三方編譯依賴
pod'DoubleConversion', :podspec = './reactnative/node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
pod'glog', :podspec = './reactnative/node_modules/react-native/third-party-podspecs/glog.podspec'
pod'Folly', :podspec = './reactnative/node_modules/react-native/third-party-podspecs/Folly.podspec'
end
我們只需要把紅色換成自己第四步創(chuàng)建的那個文件夾的名字
NSURL*jsCodeLocation = [NSURL
? ? ? ? ? ? ? ? ? ? ? ? URLWithString:@""];
RCTRootView*rootView =
[[RCTRootViewalloc]initWithBundleURL: jsCodeLocation
? ? ? ? ? ? ? ? ? ? moduleName? ? ? ? :@"ReactIOS"
? ? ? ? ? ? ? ? ? ? initialProperties:
@{
? @"scores":@[
? ? ? ? ? @{
? ? ? ? ? ? ? @"name":@"Alex",
? ? ? ? ? ? ? @"value":@"42"
? ? ? ? ? ? ? },
? ? ? ? ? @{
? ? ? ? ? ? ? @"name":@"Joel",
? ? ? ? ? ? ? @"value":@"10"
? ? ? ? ? ? ? }
? ? ? ? ? ]
? }
? ? ? ? ? ? ? ? ? ? ? launchOptions? ? :nil];
self.view= rootView;
說說我遇到的問題吧，首先我在第五步遇到的問題?
當(dāng)時紅色部分沒有加，一直報錯，找了好幾天才看到別人有一篇文章是說的這個問題，要把紅色部分加上。上面問題解決后我又遇到一個問題，錯誤在第三步和第七步，
這三個紅色地方不對應(yīng),導(dǎo)致不錯
解決辦法就是把-去掉就好了。
希望能幫到大家!!!!!!
項目地址:,先cd到reactnative下 npm install ,在cd到項目目錄下pod install 現(xiàn)在依賴
既然要承載 web 頁面，一個原生的 WebView 必不可少。在 iOS 中，目前已經(jīng)有兩款高性能、功能齊全的 web 瀏覽器，UIWebView (=2.0)和 WKWebView(=7.0)。
當(dāng)然，兩種 web 瀏覽器選其一即可。網(wǎng)上有很多文章，包括我之前已經(jīng)發(fā)表的博文中，都介紹過這兩種瀏覽器，讀者可以根據(jù)自己的需要選擇。
就目前的情況看，UIWebView 發(fā)展了很多年，目前市面上大部分的 web 頁面也都支持這樣的瀏覽器，因此很多公司在選擇的時候都使用這個，但是，我們知道，WKWebView 有太多改善前者的優(yōu)點，而且也是蘋果官方提倡大家使用的，為了性能，為了更多的特性，建議初次搭建的朋友采用 WKWebView。
為了實現(xiàn) h5 與 native 之間的互相調(diào)用，我們需要在兩者之間架一層橋來實現(xiàn)，關(guān)于 bridge，之前的文章也有介紹。
bridge 的功能包括：native 調(diào)用 h5，h5 回調(diào) native，h5 調(diào)用 native，native 回調(diào) h5。
有了 bridge，h5可以使用 native 支持的更多特性，native 可以獲取 h5 頁面加載的信息，也可以讓 web 頁面動態(tài)執(zhí)行一些腳本做一些事。
總之，在 web 容器框架中，這個 bridge 還是很有必要的。
嗯，這個是輔助項，做了這一步可以進(jìn)一步提高 web 容器的加載性能，而且資源緩存到本地后可以做到不依賴網(wǎng)絡(luò)，提高用戶體驗。
通常有兩種做法，
UIWebView 使用簡單，而且現(xiàn)在用戶的手機性能也已經(jīng)不再是頁面展示性能的瓶頸，所以，這里介紹的依然采用 UIWebView 作為 web 瀏覽器。
WebViewJavascriptBridge 是一款非常強大的第三方開源 bridge 庫，同時支持 UIWebView 和 WKWebView。
git 地址
NJKWebViewProgress 是一款能使 UIWebview 顯示加載進(jìn)度的第三方開源框架，支持代理協(xié)議處理和 progressview 展示兩種功能。
git 地址
你好，原生(native)開發(fā)一般是指用原生開發(fā)語言開發(fā),原生開發(fā)語言就是開發(fā)整個系統(tǒng)時使用的編程語言.對于iOS來說就是Objective C,對于Android來說...不太好說,因為Android用的Linux內(nèi)核是用C開發(fā)的,中間層的庫是用C/C++開發(fā)的,但應(yīng)用程序框架和應(yīng)用程序都是用"Java"開發(fā)的,這個系統(tǒng)就是用一堆開源的工程拼起來的,真不太好說哪種語言算是它的原生開發(fā)語言原生App實際上是一種基于智能手機本地操作系統(tǒng)如Android、IOS和Windows Phone并且使用原生程序編寫運行的第三方移動應(yīng)用程序。開發(fā)原生App軟件需要針對不同智能手機的操作系統(tǒng)來選擇不同的App開發(fā)語言，如安卓App是Java開發(fā)語言、IOS APP是Objective-C語言、Windows Phone的APP開發(fā)是C##語言。
如今市面上多數(shù)的APP軟件開發(fā)都是使用的原生程序編寫的應(yīng)用程序，也就是說大部分的手機APP屬于原生APP應(yīng)用軟件。原生APP因為位于平臺層上方，所以向下訪問和兼容的能力也比較好，可以支持在線或者離線消息推送或是進(jìn)行本地資源訪問，以及攝像撥號功能的調(diào)取。
原生App
原生APP又稱Native App，該開發(fā)針對IOS、Android、Windows等不同的手機操作系統(tǒng)要采用不同的語言和框架進(jìn)行開發(fā)，該模式通常是由“云服務(wù)器數(shù)據(jù)+APP應(yīng)用客戶端”兩部份構(gòu)成，APP應(yīng)用所有的UI元素、數(shù)據(jù)內(nèi)容、邏輯框架均安裝在手機終端上。
原生App
1、每一種移動操作系統(tǒng)都需要獨立的開發(fā)項目。
2、每種平臺都需要獨立的開發(fā)語言。Java(Android), Objective-C(iOS)以及Visual C++(Windows phone)等等。
3、需要使用各自的軟件開發(fā)包，開發(fā)工具以及各自的控件。
原生App僅供參考
很高興回答你的問題。
一直以來，ios的開發(fā)語言都相對比較單一，要么是swift，要么就是object-c，這樣的情況對于ios開發(fā)人員來說，還是比較友好的，沒有那么多的語言要學(xué)習(xí)，專心研究一門語言就可以了，可是在KotlinConf 大會宣布了 Kotlin 1.2 RC 版，并宣布 Kotlin/Native 已支持用于開發(fā) iOS 應(yīng)用和 Web 應(yīng)用開發(fā)。這也將是 Kotlin/Native 0.4 的特性之一。雖然對 iOS 開發(fā)的支持仍處于早期階段，但確實已經(jīng)實現(xiàn)了，這是在所有平臺上使用 Kotlin 進(jìn)行開發(fā)的重要一步。官方還特意展示了利用 Kotlin/Native 開發(fā)的兩款應(yīng)用，它們都可以運行于 iOS 和 Android 平臺。Android 和 iOS 平臺共享了不少代碼，其中包括大多數(shù)圖形處理、聲音播放和用戶輸入響應(yīng)代碼。而且IDEA也已經(jīng)支持Kotlin/Native了，對于Kotlin/Native是否能夠勝任ios的開發(fā)，我覺得應(yīng)該從以下幾點來看。
1、性能
現(xiàn)在移動端的開發(fā)，很注重的就是用戶體驗以及產(chǎn)品的性能，Kotlin/Native作為一個新生的語言，在性能這一塊，還有待考究。
2、技術(shù)成熟性
現(xiàn)在的Kotlin/Native在技術(shù)方面感覺尚未成熟，想要撼動swift或者object-c的地位，可能還需要一段時間，就像kotlin，雖然官方已經(jīng)宣布將kotlin作為Android開發(fā)的官方語言，可是，這么久過去了，還是沒能取代Java。
3、實際的開發(fā)體驗
因為我沒有用過Kotlin/Native開發(fā)ios，但是，在Android平臺上面，很多的程序員拋棄Java投奔向kotlin，但是使用了一段時間后，又轉(zhuǎn)過頭來使用Java，這便是在實際的開發(fā)過程中，很多程序員覺得kotlin并沒有想象中的那么好，轉(zhuǎn)而又開始使用Java。
如果以上三點，Kotlin/Native都做的很好了，那么ios的開發(fā)市場，應(yīng)該就會被Kotlin/Native給占據(jù)了，各位有什么看法，歡迎評論。
以上便是我對開發(fā)iOS應(yīng)用，Kotlin Native是否夠格？問題的回答，如果您覺得有道理，請點贊，關(guān)注，支持我，謝謝。
重慶分公司
重慶分公司
