189 8069 5689
React native充分利用了Facebook的现有轮子，是一个很优秀的集成作品，并且我相信这个团队对前端的了解很深刻，否则不可能让Native code「退居二线」。
建平网站建设公司创新互联建站,建平网站设计制作，有大型网站制作公司丰富经验。已为建平超过千家提供企业网站建设服务。企业网站搭建\外贸网站建设要多少钱，请找那个售后服务好的建平做网站的公司定做！
对应到前端开发，整个系统结构是这样：
JSX vs HTML
CSS-layout vs css
ECMAScript 6 vs ECMAScript 5
React native View vs DOM
无需编译，我在第一次编译了ipa装好以后，就再也没更新过app，只要更新云端的js代码，reload一下，整个界面就全变了。
多数布局代码都是JSX，所有Native组件都是标签化的，这对于前端程序员来说，降低了不少学习成本，也大大减少了代码量。不信你可以看看JSX编译后的代码。
复用React系统，也减少了一定学习和开发成本，更重要的是利用了React里面的分层和diff机制。js层传给Native层的是一个diff后的json，然后由Native将这个数据映射成真正的布局视图。
css-layout也是点睛之笔，前端可以继续用熟悉的类css方式来编写布局，通过这个工具转换成constrain布局。
系统只有js-objc的单向调用，就是把原生UI组件的方法通过javascritcore或者webview（低版本iOS）映射到js中来，整个调用过程是异步的，这样的设计令React native可以让js运行在桌面chrome中，通过websocket连接Native code和桌面chrome，极大地方便了调试。对其中的机制Bang的一篇文章写得很详细，我就不拾人牙慧了：React Native通信机制详解 « bang’s blog 。但这样设计也会带来一些问题，后面说。
点按操作也被抽象成了一组组件（TouchableXXX），这种抽象方式是我在之前做类似工作中没有想到的。facebook还列出Native为什么和web「手感」不同的原因：实时的点按反馈和取消能力。React Native 这套相应机制设计得很完善，能像Native code那样控制整个点按操作的所有过程。
Debug相当方便！修改了js以后，通过内建的nodejs watcher编译成bundle，在模拟器里面按cmd+r就可以看到效果。而且按cmd+d，可以打开一个chrome窗口，所有的js都移到了chrome里面运行，所以什么断点单步打调用栈，都不在话下。
上面的既是特点也是优点，下面说说缺点，或者应该说：「仍然遗留的问题」，在我看来，这个方案已经超越了Hybird方案。
系统仍然（不得不）依赖原生组件暴露出来的组件和方法。举两个例子，ScrollView这个组件，在Native层是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，这些事件在现有的版本都没有暴露，基本上做不了组件联动效果。另外，这个版本中有大量组件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反过来看，剩余的都是一些抽象程度极强的基本组件。这样，用户必须在不同的平台下写两套代码，而且所有能力仍然强烈依赖 React native 开发人员暴露的接口。
由于最外层是React，初次学习成本高，不像往常的Hybird方案，只要多学几个JS API就可以开始干活了。当然，React的确让后续开发变得简单了一些，这么一套外来的（基于iOS）、残缺不全的（css-layout）在React的包装下，的确显得不那么面目可憎了。
另外，React Native仍然很不完善。文档还不全，我基本上是看着他的示例代码完成的demo，集成到已有app的文档也是今天才出来。按照官方的说法，Android版本要到半年后才发布：Blog | React ，届时整个系统设计可能还会有很大的变化。
PS，在使用Tabbar的时候，我惊喜的发现他们居然用了iconfont方案，我现在手头的项目中也有同样的实现，不过API怎么设计一直很头疼。结果，我发现他是这么写的：
TabBarItemIOS
name="blueTab"
icon={_ix_DEPRECATED('favorites')}
....
在 _ix_DEPRECATED 的定义处，有一句注释： // TODO(nicklockwood): How can this fit our require system?
以上。
下面是一周前，在React native还没开源的时候，通过反解ipa的一些分析过程，有兴趣的可以看看。
------------------------简单粗暴的分割线--------------------
背景和调研手段
React Native还没开源，最近和组里兄弟「反编译」了Facebook Group（这个应用是用React Native实现的）的ipa代码，出来几百个JS文件，格式化一下，花了几天时间读了一下源码，对React Native的内部核心机制算是有了一个基本了解。
React Native的核心实现：
先简单说几点，详细的等回头更新。
1. React Native里面没有webview，这货不是Hybrid app，里面执行JS是用的
JavascriptCore。
2. 再说React Native的核心，iOS Native code提供了十来个最基本核心的类（RCTDeviceEventEmitter、RCTRenderingPerf等）、或组件（RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等），然后由React Native的JS部分，组成二十来个基本组件（Popover、Listview等），交由上层的业务方来使用（THGroupView）。
3. 就如他们在宣传时所说，他们实现了一套类似css的子集，用来解决样式问题，相当复杂和强大，靠这个才能将Native的核心组件组成JS层的基本组件再组成业务端的业务组件，应该是采用facebook/css-layout · GitHub的C语言版本实现的（在ppt中我们看到了类似flex-direction: column一类的代码，这个正是css-layout支持的语法）。
4. 在React Native中，写JS的工程师解决的是「将基本组件拼装成可用的React组件」的问题，写Native Code的工程师解决的是「提供核心组件，提供足够的扩展性、灵活性和性能」的问题。
React Native的设计考虑：
ReactJS对React Native有着直接的影响（我没在生产环境中用过React，只看过代码用过Angular，如果有误请指出）
ReactJS里面有这样的设计：
1. ReactJS 的大工厂入口createElement返回的不是某个实体DOM对象，而只是一个数组
2. 通过源码中 ui/browser/ 目录中的代码，将这个数组转换成DOM
3. 底层的渲染核心是可以更换的
另外，Facebook自己有JSX，css-layout等开源项目，基于这些，如果要做一个用 JS来开发Native app的东西，很自然就想到了一套最有效率的搞法：
1. 将 ui/browser 里面的代码替换成一套 Native 的桥接JS（实际上，iOS版是通过
injectGenericComponentClass方法，将核心组件的方法注入到JS里面 ），就直接复用React的MVVM，自动将数据映射到Native了
2. Native code里面实现三组核心API，一组提供核心组件的API（create、update、delete），一组事件方法（ReactJS里面的EventEmitter ），一组对css进行解析（css-layout）以及返回Style的ComputedStyle（React Native里面叫meatureStyle）。
这样，用上了ReactJS本身的所有核心功能和设计思路，Native的开发也足够简单。
那，React Native是什么？
其实这东西从Native开发来说，相当于重新发明了一个浏览器渲染引擎并且套一个React的壳，从Web开发角度来说，就是把原来React的后端换成了Native code来实现，就跟Flipboard最近搞的React Canvas 一样： Flipboard · GitHubreact-canvas
React Native的优势和劣势：：
优势相对Hybird app或者Webapp：
1. 不用Webview，彻底摆脱了Webview让人不爽的交互和性能问题
2. 有较强的扩展性，这是因为Native端提供的是基本控件，JS可以自由组合使用
3. 可以直接使用Native原生的「牛逼」动画（在FB Group这个app里面，面板滑出带一点果冻弹动，面板基于某个点展开这种动画随处可见，这种动画用Native code来做小菜一碟，但是用Web来做就难上加难）。
优势相对于Native app：
1. 可以通过更新远端JS，直接更新app，不过这快成为各家大型Native app的标配了…
劣势：
1. 扩展性仍然远远不如web，也远远不如直接写Native code（这个不用废话解释了吧）
2. 从Native到Web，要做很多概念转换，势必造成双方都要妥协。比如web要用一套CSS的阉割版，Native通过css-layout拿到最终样式再转换成native原生的表达方式（比如iOS的Constraint\origin\Center等属性），再比如动画。另外，若Android和iOS都要做相同的封装，概念转换就更复杂了。
更新1：添加了React对React Native的影响。
更新2：基本确定其使用了 css-layout，添加了对React Native的总结
更新3: React native已经开源了： React Native，只有iOS版。我写了几个demo，简单看了看objc代码并和开源前的我们的一些结论（见后文）交叉验证。简单地从前端工程师和系统整体角度说一下React native的特点和优劣吧。
更新4: 补充了几条优势和与前端开发的对照
最为一个iOS开发人员，最近在研究rn开发，坑还挺多的。下面我就来说说iOS接入rn的步骤以及我遇到的问题.
前提：电脑已经安装过React-Native相关环境;
创建：首先我们创建一个iOS项目，我命名为React-IOS；
这个相信大家都会创建，就不说了。
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，则需要加入此行才能开启开发者菜单
#'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
我们只需要把红色换成自己第四步创建的那个文件夹的名字
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;
说说我遇到的问题吧，首先我在第五步遇到的问题
当时红色部分没有加，一直报错，找了好几天才看到别人有一篇文章是说的这个问题，要把红色部分加上。上面问题解决后我又遇到一个问题，错误在第三步和第七步，
这三个红色地方不对应,导致不错
解决办法就是把-去掉就好了。
希望能帮到大家!!!!!!
项目地址:,先cd到reactnative下 npm install ,在cd到项目目录下pod install 现在依赖
既然要承载 web 页面，一个原生的 WebView 必不可少。在 iOS 中，目前已经有两款高性能、功能齐全的 web 浏览器，UIWebView (=2.0)和 WKWebView(=7.0)。
当然，两种 web 浏览器选其一即可。网上有很多文章，包括我之前已经发表的博文中，都介绍过这两种浏览器，读者可以根据自己的需要选择。
就目前的情况看，UIWebView 发展了很多年，目前市面上大部分的 web 页面也都支持这样的浏览器，因此很多公司在选择的时候都使用这个，但是，我们知道，WKWebView 有太多改善前者的优点，而且也是苹果官方提倡大家使用的，为了性能，为了更多的特性，建议初次搭建的朋友采用 WKWebView。
为了实现 h5 与 native 之间的互相调用，我们需要在两者之间架一层桥来实现，关于 bridge，之前的文章也有介绍。
bridge 的功能包括：native 调用 h5，h5 回调 native，h5 调用 native，native 回调 h5。
有了 bridge，h5可以使用 native 支持的更多特性，native 可以获取 h5 页面加载的信息，也可以让 web 页面动态执行一些脚本做一些事。
总之，在 web 容器框架中，这个 bridge 还是很有必要的。
嗯，这个是辅助项，做了这一步可以进一步提高 web 容器的加载性能，而且资源缓存到本地后可以做到不依赖网络，提高用户体验。
通常有两种做法，
UIWebView 使用简单，而且现在用户的手机性能也已经不再是页面展示性能的瓶颈，所以，这里介绍的依然采用 UIWebView 作为 web 浏览器。
WebViewJavascriptBridge 是一款非常强大的第三方开源 bridge 库，同时支持 UIWebView 和 WKWebView。
git 地址
NJKWebViewProgress 是一款能使 UIWebview 显示加载进度的第三方开源框架，支持代理协议处理和 progressview 展示两种功能。
git 地址
你好，原生(native)开发一般是指用原生开发语言开发,原生开发语言就是开发整个系统时使用的编程语言.对于iOS来说就是Objective C,对于Android来说...不太好说,因为Android用的Linux内核是用C开发的,中间层的库是用C/C++开发的,但应用程序框架和应用程序都是用"Java"开发的,这个系统就是用一堆开源的工程拼起来的,真不太好说哪种语言算是它的原生开发语言原生App实际上是一种基于智能手机本地操作系统如Android、IOS和Windows Phone并且使用原生程序编写运行的第三方移动应用程序。开发原生App软件需要针对不同智能手机的操作系统来选择不同的App开发语言，如安卓App是Java开发语言、IOS APP是Objective-C语言、Windows Phone的APP开发是C##语言。
如今市面上多数的APP软件开发都是使用的原生程序编写的应用程序，也就是说大部分的手机APP属于原生APP应用软件。原生APP因为位于平台层上方，所以向下访问和兼容的能力也比较好，可以支持在线或者离线消息推送或是进行本地资源访问，以及摄像拨号功能的调取。
原生App
原生APP又称Native App，该开发针对IOS、Android、Windows等不同的手机操作系统要采用不同的语言和框架进行开发，该模式通常是由“云服务器数据+APP应用客户端”两部份构成，APP应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上。
原生App
1、每一种移动操作系统都需要独立的开发项目。
2、每种平台都需要独立的开发语言。Java(Android), Objective-C(iOS)以及Visual C++(Windows phone)等等。
3、需要使用各自的软件开发包，开发工具以及各自的控件。
原生App仅供参考
很高兴回答你的问题。
一直以来，ios的开发语言都相对比较单一，要么是swift，要么就是object-c，这样的情况对于ios开发人员来说，还是比较友好的，没有那么多的语言要学习，专心研究一门语言就可以了，可是在KotlinConf 大会宣布了 Kotlin 1.2 RC 版，并宣布 Kotlin/Native 已支持用于开发 iOS 应用和 Web 应用开发。这也将是 Kotlin/Native 0.4 的特性之一。虽然对 iOS 开发的支持仍处于早期阶段，但确实已经实现了，这是在所有平台上使用 Kotlin 进行开发的重要一步。官方还特意展示了利用 Kotlin/Native 开发的两款应用，它们都可以运行于 iOS 和 Android 平台。Android 和 iOS 平台共享了不少代码，其中包括大多数图形处理、声音播放和用户输入响应代码。而且IDEA也已经支持Kotlin/Native了，对于Kotlin/Native是否能够胜任ios的开发，我觉得应该从以下几点来看。
1、性能
现在移动端的开发，很注重的就是用户体验以及产品的性能，Kotlin/Native作为一个新生的语言，在性能这一块，还有待考究。
2、技术成熟性
现在的Kotlin/Native在技术方面感觉尚未成熟，想要撼动swift或者object-c的地位，可能还需要一段时间，就像kotlin，虽然官方已经宣布将kotlin作为Android开发的官方语言，可是，这么久过去了，还是没能取代Java。
3、实际的开发体验
因为我没有用过Kotlin/Native开发ios，但是，在Android平台上面，很多的程序员抛弃Java投奔向kotlin，但是使用了一段时间后，又转过头来使用Java，这便是在实际的开发过程中，很多程序员觉得kotlin并没有想象中的那么好，转而又开始使用Java。
如果以上三点，Kotlin/Native都做的很好了，那么ios的开发市场，应该就会被Kotlin/Native给占据了，各位有什么看法，欢迎评论。
以上便是我对开发iOS应用，Kotlin Native是否够格？问题的回答，如果您觉得有道理，请点赞，关注，支持我，谢谢。