随着移动设备性能不断增强，web 页面的性能体验逐渐变得可以接受，又因为 web 开发模式的诸多好处(跨平台，动态更新，减体积，无限扩展)，APP 客户端里出现越来越多内嵌 web 页面（为了配上当前流行的说法，以下把所有网页都称为 H5 页面，虽然可能跟 H5 没关系），很多 APP 把一些功能模块改成用 H5 实现。
虽然说 H5 页面性能变好了，但如果没针对性地做一些优化，体验还是很糟糕的，主要两部分体验：
本文先不讨论第二点，只讨论第一点，怎样减少白屏时间。对 APP 里的一些使用 H5 实现的功能模块，怎样加快它们的启动速度，让它们启动的体验接近原生。
最近工作需要，重新看 React Native (以下简称RN) 源码，了解机制，寻找优化空间，过程中看能不能整理出一些东西。
RN 这个项目已经是庞然大物，打开 github 项目主页，根目录下文件和文件夹就多达五六十个，看起来一脸懵逼，不知道哪些是源码，在看源码之前先理理 RN 最终用到哪些代码，项目是怎样创建，怎样跑起来的。以下皆以 iOS 端为例。
先看看标准 RN 项目创建和运行过程：
react-native，执行 react-native init AwesomeProject 可以创建一个新 RN 项目。上述流程跑下来整个过程是个黑盒，对黑盒里的处理有一些疑问点：
react-native init AwesomeProject 这个命令做了什么，是怎样创建 RN 模板项目的？接下来一条条看。
（更多…）
很多中大型互联网公司都会有晋升评审，也就是对技术/产品等职位划分成若干个等级，每个员工都有一个等级，若要晋升到下一级，需要由几个评委面试决定是否合格。这跟传统公司的考职称差不多，只不过传统公司是通过考试，互联网公司是通过面试。
为什么会有这种晋级评审？等级是公司内部对员工的一种评价和定位，等级的参照物是公司内的所有员工，假如一个公司比较小，老板每天跟所有员工一起工作，在老板识人能力又没有问题的前提下，老板就很清楚每个人的能力，直接对他们排等级，不需要什么评审，得出来的结果其实是更公正准确的，因为这是根据平时工作过程中获取的大量信息综合考虑得出的结果。但在中大型公司做不到，老板认识不了那么多人，没在一起工作，没法对每个人给出公正的评价。若把评判权都交给一起工作的组长总监又不妥，因为职级的参照系是全公司，而不是组内或部门内，很容易出现偏颇/标准不一的情况。
于是出现一个评审系统，由公司里一些有经验的人士去判断某个人能不能晋升到下一个等级，而这些人平时很可能没有跟他们一起工作，仅仅是通过大概一个小时的陈述和沟通去评判，这导致了这一个小时里陈述的方式和沟通的技巧变得很重要，同样一个人同样的工作，不同的 PPT 不同的陈述方式，结果会完全不一样。这里大致说下我所了解到的套路，套路并不是贬义词，只是能帮助更好地表现自己的能力，让评委得出更公正的评价。
先列一下在准备晋级评审 PPT 时我认为重要的几个要点：目标，重点，思路，数据。
在准备晋级 PPT 时，得先搞清楚目标，这种 PPT 目标很简单只有一个，就是告诉评委我很NB我完全可以晋升到下个等级。时刻问自己 PPT 表现出这个目标了没有。
只有一个小时时间，不可能面面俱到表现出所有，讲的内容多了评委也不会记得，必须突出一两个重点和亮点，用2/3以上篇幅去深入讲，并且要让人听得懂。有人误解了以为晋升评审是述职，罗列过去一年做的工作，这个其实很为难评委，评委需要帮你在你罗列的众多工作中寻找能体现你技术水平的点，整体印象也大打折扣。
另外需要有一些亮点，如果你陈述的都是业界常规做法，其他人也是这样做的，评委会觉得没什么特别，是个人都会这么做，若有自己独特的创新点和亮点，就算是小的点，让评委眼前一亮也是很好的加分项。其实这是这个评审制度本身的缺陷和局限，因为评委每次评审的人数太多，如果大家能力都没有太突出，那决定谁更好的方式就是谁更特别留下更多的印象，这也就是亮点的意义。
讲思路不要讲细节，特别是代码细节，除非是非常有技术含量的，作为亮点的细节。着重表现自己在解决问题过程中的思路，表达出自己在项目/问题涉及到的方方面面都有考虑到（全局观），有深入思考的能力，面对一个问题有能力抽象出关键点，有能力分解问题，若最终能总结出类似问题的统一解决思路（方法论）更好。
要有数据证明做出的成绩，经过你NB的工作后，是性能提升百分之多少，还是工作效率提高多少，还是投诉率降低多少，还是有多少个产品都在用你的东西，业务的核心数据是怎样，都要有证据证明自己不是在吹牛，尽量使用量化的指标。
这里列个常用的结构供参考：
我是谁：工作经历
我做出了什么成绩：在本公司做的事情，负责的业务，做出的成绩。
1-3个重点：
未来计划
谢谢
当然并不是说都要按这个结构写，若个人能有创新发挥用更适合自己的方式陈述自然更好。
交流环节里，一般评委都是会根据 PPT 内容问问题。
最容易被挑战的就是数据，若 PPT 上列的数据不是很常规就会被问为什么，对所有数据都必须准备好被质疑。
评委对某个点感兴趣会追问细节，一些重要的技术细节可以以附录的形式附在PPT后面，问到时方便讲解。
PPT 上提到的点最好对相关技术都了解清楚，例如提到客户端网络层优化，最好把网络层底层相关知识都准备好，评委可能会追问下去以考察技术深度。
有些评委喜欢问一些固定问题，例如你觉得为什么你应该晋级，你觉得有哪些不足，你后续的技术规划是什么等等。
公司一般会有每个职级对应的能力表，有些评委喜欢对着能力表问相关问题。
评审也是个双向mg游戏平台官方网站的过程，如果你能让评委觉得学到东西了效果会很好。
很多评委喜欢问他擅长的专业领域内的问题。显然这个环节有一定运气成分存在，遇到匹配度高的评委通过几率直线上升。
这种一小时判断一个人的晋级评审肯定做不到非常公正，有一些运气成分，甚至有一些关系成分，但已经是相对较好的一种形式，而且评审的准备过程中还能让自己梳理总结一下过去做的事情，虽然准备过程会很痛苦，但也会很有收获。晋升的前提当然是要有足够的技术能力/影响力和视野，这里一些套路只供参考，希望能帮助有需要的人更好地表现自己的实力。
iOS 签名机制挺复杂，各种证书，Provisioning Profile，entitlements，CertificateSigningRequest，p12，AppID，概念一堆，也很容易出错，本文尝试从原理出发，一步步推出为什么会有这么多概念，希望能有助于理解 iOS App 签名的原理和流程。
先来看看mg游戏网站的签名机制是为了做什么。在 iOS 出来之前，在主流操作系统(Mac/Windows/Linux)上开发和运行软件是不需要签名的，软件随便从哪里下载都能运行，导致平台对第三方软件难以控制，盗版流行。mg游戏网站希望解决这样的问题，在 iOS 平台对第三方 APP 有绝对的控制权，一定要保证每一个安装到 iOS 上的 APP 都是经过mg游戏网站官方允许的，怎样保证呢？就是通过签名机制。
通常我们说的签名就是数字签名，它是基于非对称加密算法实现的。对称加密是通过同一份密钥加密和解密数据，而非对称加密则有两份密钥，分别是公钥和私钥，用公钥加密的数据，要用私钥才能解密，用私钥加密的数据，要用公钥才能解密。
简单说一下常用的非对称加密算法 RSA 的数学原理，理解简单的数学原理，就可以理解非对称加密是怎么做到的，为什么会是安全的：
上述的 (n,e) 这两个数据在一起就是公钥，(n,d) 这两个数据就是私钥，满足用私钥加密，公钥解密，或反过来公钥加密，私钥解密，也满足在只暴露公钥 (只知道 n 和 e)的情况下，要推导出私钥 (n,d)，需要把大整数 n 因数分解。目前因数分解只能靠暴力穷举，而 n 数字越大，越难以用穷举计算出因数 p 和 q，也就越安全，当 n 大到二进制 1024 位或 2048 位时，以目前技术要破解几乎不可能，所以非常安全。
若对数字 d 是怎样计算出来的感兴趣，可以详读这两篇文章：RSA 算法原理（一）（二）
现在知道了有非对称加密这东西，那数字签名是怎么回事呢？
数字签名的作用是我对某一份数据打个标记，表示我认可了这份数据（签了个名），然后我发送给其他人，其他人可以知道这份数据是经过我认证的，数据没有被篡改过。
有了上述非对称加密算法，就可以实现这个需求：
今天聊聊 iOS 动态化的故事。
在开发模式上，web 的方式是比较先进的，有各种优点，包括跨平台/UI开发效率高，最重要的是可以时刻保证用户看到的程序是最新的，没有版本概念，整个系统时刻保持在掌握之中，而客户端开发模式相对 web 开发是一种倒退，客户端做不到这样的动态化，无法随时更新，目前一个客户端程序要更新成本是很高的，需要发布版本，也无法保证所有人都能更新到这个版本，这是最大的弱点，也是非常大的一块需求。
为什么会有这种倒退，最主要原因是：mg游戏网站引领的体验优先规则。
在 iPhone 出现之前大家并不太在意一个软件的动画体验，一个 web 应用是很少有动画的，点一个按钮，一整块内容直接刷新，再点个链接整个页面变白刷新，PC上网页滚动都是一格格滚动的，而不是现在手机上那种顺滑流畅的滚动，PC客户端软件也一样，大家都觉得没什么问题，用得挺好，但mg游戏网站改变了这种情况，iPhone 刚推出时页面间切换的动画，60fps 的丝滑滚动，点击的即时响应，微软的人都惊呼是黑魔法，让人用了就上瘾，再也回不去，而 web 的方式还不足以像原生客户端那样支持这样的流畅性，做不到好的体验，无法被人接受，开发上优势再多也无法干过客户端，参考 facebook 初期用 web 技术构建 app 的惨状，没办法，服了mg游戏网站，大家只能按照mg游戏网站的方式干，做原生客户端。
当然这里还有手机环境网络不稳定，流量费贵的原因，但这些都可以在技术上通过缓存解决，最主要还是体验问题。
那发展到今天，这个体验问题解决了没有呢？没有，即使发展到今天手机性能已上天，但 web 做出来的东西体验仍然跟客户端有差别，大家也已经习惯了 APP 的方式，也被流畅的 APP 惯坏。现在 APP 里也有不少功能是 web实现，但大家都知道这是牺牲了一些性能体验去换取开发和发布效率，只是一种权衡。
那这个问题怎么解决呢，现在业界有两种方案。
既然用 web 方式开发的劣势只是性能体验跟不上，那就优化性能吧。web 性能瓶颈在哪里？在那个有悠久历史的 webkit 引擎，它有各种历史问题，要改进它并不容易。我们要的是 web 的开发和发布方式，不需要 web 的全部，那能不能重新实现一个渲染引擎呢，这个引擎可以针对原生客户端优化，不需要兼容繁杂的 web 标准，不跟 web 那些历史问题扯上关系，于是就有了 React Native 和 Weex 这种方案，web 的方式开发，原生的方式渲染，拥有 web 优秀的开发和发布方式，又有不错的性能体验，看起来很完美，很有前途的方案。
一个方案能不能推广开让大家都使用，主要看成本和收益。目前 React Native 和 Weex 等这些方案的接入成本是很高的，一是它们本身就是大型框架，mg游戏平台官方网站成本高，后期维护成本以及团队mg游戏平台官方网站成本同样高。二是它们还不够成熟，还在继续填坑中，使用的过程可能要一起去填坑。收益上也不够理想，就目前状况它们能代替的是那些本来用 H5 实现的模块，换成这种方式实现后性能体验会更好，但也不能保证像原生那样好，很多场景需要深入框架进行优化。整个 APP 都使用这种方案构建还不靠谱，部分使用又无法使整个 APP 保持动态化，总体上来说收益也没有达到有绝对优势的程度，成本高收益低，推广起来会比较困难，还需期待其继续发展。
另一种是方案是，我可以放弃用 web 的开发方式，放弃 web 跨平台/UI开发简单的优越性，我想继续用原生的方式开发这个APP，但又希望这个 APP 随时可以更新，让程序时刻在自己掌握中，出了问题可以快速修复，还想要可以随时更新版本快速迭代，可以不？完全可以，用动态库就行了。
技术上要在 iOS 上做到原生动态化比 Android 更容易，iOS 开发语言 Objective-C 天生动态，运行时都能随意替换方法，运行时加载动态库又是项很老的技术，只要我把增量的代码和资源打包到一个 framework 里，动态下发运行时加载，修 bug，加功能都不在话下，性能完全无损，这件事就结束了。
但是呢。mg游戏网站把加载动态库的功能给封了，动态库必须跟随安装包一起签名才能被加载，无法通过别的途径签名后再下发。
为什么这么做呢，这又涉及到mg游戏网站另一个创举：审核模式（mg游戏网站的创举之多令人发指）。一个软件，要在一个平台上发布，需要先通过这个平台的人工审核，这个好像在mg游戏网站之前没见过有别人这样做过，windows 不用，mac 不用，各种 unix 不用，web 也不用，mg游戏网站为了对自己的平台有绝对控制权，搞了这样一个东西，审核模式就跟动态化冲突了，如果我一个 APP 可以不经过审核不断下发 framework 添加修改功能， 还需要mg游戏网站审核做什么？
因为这种限制，没法用最方便的方式进行动态更新了，整个 APP 发出去后就不受控制，有什么严重 bug，需要添加什么功能，都乖乖打个包提交给mg游戏网站审核，再等用户慢慢更新，对于急性子的中国人来说，这种事难以容忍。
mg游戏网站把动态库这扇门关了，我们可以绕个道从另一个门进，动态加功能可以缓缓，大家需求还不那么迫切，但修 bug 的需求就很急，很多公司 APP 的 crash 率是 KPI 来着，看着线上 crash 不断增多又毫无办法是很不爽的事，于是有了 waxPatch 和 JSPatch 这种方案，曲线救国。
JSPatch 把 OC 手动翻译成 JS，在运行时通过 OC 的动态特性去调用和替换 OC 方法，实时修复 bug。修 bug 这个需求基本是满足了，虽然小绕了下道，但成本还是很低的，引擎本身也很小很轻量，接入对 APP 不会有任何负面影响，在关键时刻又可以帮大忙，成本低收益高，于是很容易推广开。
人欲望是无穷的，技术宅的折腾是无止境的，JSPatch 满足了修 bug 的需求，但还是无法满足动态化的全部需求，最大的缺点在于需要手写 JS，虽然已经有转换器辅助，但还没做到100%准确，用来修 bug 还好，用来添加功能的话mg游戏平台官方网站成本和开发效率还不够。
于是有了滴滴的 DynamicCocoa 这种方案，绕了一个更大的道，从编译阶段入手，通过 clang 把 OC 代码编译成自己定制的 JS 格式，再动态下发去执行，做到原生开发，动态运行，主打动态添加功能，当然顺便把修 bug 也给支持了。手机 QQ 内部也有一个类似的方案，不过更进一步，他们通过 clang 把 OC 代码编译成自己定制的字节码动态下发，然后开发一个虚拟机去执行（惊呆了），同样实现了原生开发，动态运行，都是 NB 得很的方案。只要底层处理做得足够好，也是个成本低收益高的方案，不过目前都还没开源，还没能看到实际效果和 NB 的源码，挺期待。
这种方案有没有什么问题呢，问题在对于mg游戏网站审核比较尴尬。这种方案做到极致后(所有OC/C语法都支持)，实际上是绕道实现了动态加载 framework 的全部功能，开发体验还是一致的，如果mg游戏网站同意这种方案，那相当于允许加载动态库，那还不如直接把门开了，让大家直接用动态库去做这个事情，用动态库还能在签名时禁止使用私有 API，用这种编译成脚本/字节码下发的方案可就禁止不了了。
这跟 JSPatch 还不太一样，JSPatch 虽然我也想推广动态添加功能的用法，但因为开发体验问题大部分还是用于修 bug，mg游戏网站审核对 JSPatch 开始也是有一些拒绝案例，后来估计看到大家只是用它来修 bug 和 crash，提升 APP 的质量，就默许了。但 DynamicCocoa 和手Q的方案一开始目标和效果就是跟加载动态库对齐，大规模推广后mg游戏网站会怎么看就不知道了。
我觉得mg游戏网站现在的审核方式挺有问题的，有多少APP是审核时用一套，审核通过后又通过后台一些开关把不符合规则的一些功能开放出来？只要能连上网，就有N种方式修改 APP 里的功能，mg游戏网站完全拦不住。个人认为审核方式应该改为只在发布新 APP 时审核，发布后允许动态下发代码更新，版本更新也不需要重新审核，而是通过举报和抽查的方式去审核已上线的 APP，这样既能顾及开发效率，方便开发者快速迭代做出更好的 APP，也更能确保审核效果，只是实施起来没有现在简单粗暴。
故事讲到这里已经差不多了，再多说一点，有个让我觉得很奇怪的问题，就是国外开发者只热衷于使用第一种方案解决问题，也就是使用web技术，用 React Native / NativeScript 的方式去做这个事情，对第二种方案很冷淡，包括 iOS Android 都是，原生热更新只在国内火，国外根本不感冒，国外有个 rollout 热更新平台也不温不火，为什么呢？是国外用户更守规则，或是用户对线上 bug 容忍度高，开发者对线上 bug 并不那么着急？还是 Android 被 Google Play 卡死断了这念想，iOS JSPatch 之类的方案推广不利？缺少国外一线开发者的支持，让系统原生支持动态化就比较困难了。
个人认为由系统支持动态化（允许加载动态库）在当前环境下是最好的，兼顾开发效率和 APP 体验，虽然不能跨平台，但也还能接受，可惜这个主动权掌握在mg游戏网站手上，开发者无能为力，才会出现这么多强行绕道突破的方案。web 的方式可能是未来，但目前适用范围有限，接下来怎么发展，拭目以待吧。
一般一个 iOS APP 做的事就是：请求数据->保存数据->展示数据，一般用 Sqlite 作为持久存储层，保存从网络拉取的数据，下次读取可以直接从 Sqlite DB 读取。我们先忽略从网络请求数据这一环节，假设数据已经保存在 DB 里，那我们要做的事就是，ViewController 从 DB 取数据，再传给 view 渲染：
这是最简单的情况，随着程序变复杂，多个 ViewController 都要向 DB 取数据，ViewController本身也会因为数据变化重新去 DB 取数据，会有两个问题：
JSPatch 是 iOS 平台上的一个开源库，只需接入极小的三个引擎文件，即可以用 JS 调用和替换任意 OC 方法，也就是说可以在 APP 上线后通过下发 JS 脚本，实时修改任意 OC 方法的实现，达到修复 bug 或动态运营的目的。目前 JSPatch 被大规模应用于热修复(hotfix)，已有超过 2500 个 APP 接入。
虽然 JSPatch 目前大部分只用于热修复，但因为 JSPatch 可以调用任意 OC 方法，实际上它也可以做热更新的工作，也就是动态为 APP 添加功能模块，并对这些功能模块进行实时更新，可以起到跟 React Native 一样的作用。我们从mg游戏平台官方网站成本、接入成本、开发效率、热更新能力和性能体验这几个方面来对比一下使用 React Native 和 JSPatch 做热更新的差异。
React Native 是从 web 前端开发框架 React 延伸出来的解决方案，主要解决的问题是web页面在移动端性能低的问题，React Native 让开发者可以像开发web页面那样用 React 的方式开发功能，同时框架会通过 JS 与 OC 的通信让界面使用原生组件渲染，让开发出来的功能拥有原生APP的性能和体验。
这里会有一个mg游戏平台官方网站成本的问题，大部分 iOS 开发者并不熟悉web前端开发，当他们需要一个动态化的方案去开发一个功能模块时，若使用React Native，就意味着他需要mg游戏平台官方网站web前端的一整套开发技能，mg游戏平台官方网站成本很高，所以目前一些使用 React Native 的团队里，这部分功能的开发是由前端开发者负责，而不是终端开发者负责。
但前端开发者负责这部分功能也会有一些mg游戏平台官方网站成本的问题，因为 React Native 还未达到十分成熟的程度，出了bug或有性能问题需要深入 React Native 客户端代码去排查和优化。也就是说 React-Native 是跨 web 前端开发和终端开发的技术，要求使用者同时有这两方面能力才能使用得当，这不可避免带来mg游戏平台官方网站成本的提高。
而 JSPatch 是从终端开发出发的一种方案，JSPatch 写出来的代码风格与 OC 原生开发一致，使用者不需要有 web 前端的知识和经验，只需要有 iOS 开发经验，再加上一点 JS 语法的了解，就可以很好地使用，对终端开发来说mg游戏平台官方网站成本很低。
可以看一下同样实现一个简单的界面，React Native 和 JSPatch 代码的对比：
//React Native
class HelloWorld extends Component {
render() {
return (
<View style={styles.btnArea}>
<View style={styles.btnWrapper}>
<TouchableHighlight underlayColor="#ED5F37” onPress={this.login}
activeOpacity={0.7}>
<Text style={styles.btn}>登录</Text>
</TouchableHighlight>
</View>
</View>
);
}
login(){
};
}
var styles = StyleSheet.create({
btnArea: {
justifyContent: 'center',
marginLeft: 20,
marginRight: 20,
marginTop: 100,
flexDirection: 'row',
},
btnWrapper: {
backgroundColor: '#FC6E50',
borderRadius: 5,
flex: 1
},
btn: {
paddingTop: 10,
paddingBottom: 10,
color: '#ffffff',
textAlign: 'center',
},
});
//JSPatch
require('UIColor, UIScreen, UIButton')
defineClass('HelloWord : UIView', {
initWithFrame: function(frame) {
if(self = super.initWithFrame(frame)){
var screenWidth = UIScreen.mainScreen().bounds().width
var loginBtn = UIButton.alloc().initWithFrame({x: 20, y: 50, width: screenWidth - 40, height: 30});
loginBtn.setBackgroundColor(UIColor.greenColor())
loginBtn.setTitle_forState("Login", 0)
loginBtn.layer().setCornerRadius(5)
loginBtn.addTarget_action_forControlEvents(self, 'handleBtn', 1<<6);
self.addSubview(loginBtn);
}
return self;
},
handleBtn: function() {
}
})
接入成本上，React Native 是比较大的框架，据统计目前核心代码里 OC 和 JS 代码加起来有4w行，接入后安装包体积增大 1.8M 左右。而 JSPatch 是微型框架，只有 3 个文件 2k 行代码，接入后增大 100K 左右。另外 React Native 需要搭建一套开发环境，有很多依赖的库，环境的搭建被称为一个痛点。而 JSPatch 无需搭建环境，只需要拖入三个文件到工程中即可使用。
React Native 是大框架，维护起来成本也会增大，在性能调优和 bug 查找时，必须深入了解整个框架的原理和执行流程，此外 React Native 目前还未达到稳定状态，升级时踩坑不可避免。相对来说 JSPatch 接入后的维护成本会低一些，因为 JSPatch 只是作为很薄的一层转接口，没有太多规则和框架，也就没有太多坑，本身代码量小，需要深入了解去调试 bug 或性能调优时成本也低。
在 UI 层上目前 HTML + CSS 的方式开发效率是比手写布局高的，React Native 也是用近似 HTML+CSS 去绘制 UI，这方面开发效率相对 JSPatch 会高一些，但 JSPatch 也可以借助 iOS 一些成熟的库去提高效率，例如使用 Massory，让 UI 的开发效率不会相差太多。逻辑层方面的开发效率双方是一样的。
此外 React Native 在开发效率上的另一个优势是支持跨平台，React Native 本意是复用逻辑层代码，UI 层根据不同平台写不同的代码，但 UI 层目前也可以通过 ReactMix 之类的工具做到跨平台，所以UI层和逻辑层代码都能得到一定程度的复用。而 JSPatch 目前只能用于 iOS 平台，没有跨平台能力。
实际上跨平台有它适用和不适用的场景，跨平台有它的代价，就是需要兼顾每个平台的特性，导致效果不佳。
跨平台典型的适用场景是电商活动页面，以展示为主，重开发效率轻交互体验，但不适用于功能性的模块。对 Android 来说目前热更新方案十分成熟，Android 十分自由，可以直接用原生开发后生成diff包下发运行，这种无论是开发效率和效果都是最好的。所以若是重体验的功能模块，Android使用原生的热更新方案，iOS 使用 JSPatch 开发，会更适合。
JSPatch 也做了一些事情尝试提高开发效率，例如做了 XCode 代码提示插件 JSPatchX，让用 JS 调用 OC 代码时会出现代码提示，另外跟 React Native 一样有开发时可以实时刷新界面查看修改效果的功能，目前仍在继续做一些措施和工具提高开发效率。
React Native 和 JSPatch 都能对用其开发出来的功能模块进行热更新，这也是这种方案最大的好处。不过 React Native 在热更新时无法使用事先没有做过桥接的原生组件，例如需要加一个发送短信功能，需要用到原生 MessageUI.framework 的接口，若没有在编译时加上提供给 JS 的接口，是无法调用到的。而 JSPatch 可以调用到任意已在项目里的组件，以及任意原生 framework 接口，不需要事先做桥接，在热更新的能力上，相对来说 JSPatch 的能力和自由度会更高一些。
使用 React Native 和 JSPatch 性能上会比原生差点，但都能得到比纯 H5 页面或 hybrid 更好的性能和体验。
JSPatch 的性能问题主要在于 JS 和 OC 的通信，每次调用 OC 方法都要通过 OC runtime 接口，并进行参数转换。runtime 接口调用带来的耗时一般不会成为瓶颈，参数转换则需要注意避免在 JS 和 OC 之间传递大的数据集合对象。JSPatch 在性能方面也针对开发功能做了不少优化，尽力减少了 JS 和 OC 的通信，github 项目主页上有完整的小 App demo，目前来看并没有碰到太多性能问题。
React Native 的性能问题会复杂一些，因为框架本身的模块初始化/react组件初始化/JS渲染逻辑等会消耗不少时间和内存，这些地方若使用或优化不当都会对性能和体验造成影响。JS 和 OC 的通信也是一个耗性能的点，不过这点上 React Native 优化得比较好，没有成为主要消耗点。
在性能和体验问题上，两者有不同的性能消耗点，从最终效果来看两者差别不大。
|
mg游戏平台官方网站成本
|
接入成本
|
热更新能力
|
开发效率
|
性能体验
|
|
|
JSPatch
|
低 |
低
|
高
|
中，不跨平台
|
高
|
|
React Native
|
高
|
高
|
中
|
高，跨平台
|
高
|
总的来说，JSPatch在mg游戏平台官方网站成本，接入成本，热更新能力上占优，而 React Native 在开发效率和跨平台能力上占优，大家可以根据需求的不同选用不同的热更新方案。JSPatch 目前仍在不断发展中，后续会致力于提高开发效率，完善周边支持，欢迎参与这个开源项目的开发。
（本文发表于《程序员》2016年8月刊）
JSPatch平台: http://jspatch.com
JSPatch 支持了动态调用 C 函数，无需在编译前桥接每个要调用的 C 函数，只需要在 JS 里调用前声明下这个函数，就可以直接调用：
require('JPEngine').addExtensions(['JPCFunction'])
defineCFunction("malloc", "void *, size_t")
malloc(10)
我们一步步来看看怎样可以做到动态调用 C 函数。
首先若要动态调用 C 函数，第一步就是需要通过传入一个函数名字符串找到这个函数地址，这里一个必要的前提条件就是 C 编译后的可执行文件里必须有原函数名的信息，才有可能做到通过函数名字符串找到函数地址。我们写个简单的程序来看看它编译后可执行文件的内容有没有这个信息：
//main.m
void test() {
}
int main() {
return 0;
}
编译这个文件，并用otool看下它的汇编：
（更多…）