Native提供容器，不要涉及太多的业务，否则就失去了通用性。
H5和Native的差异是短时间内解决不了的，React Native 超越Hydrid跨平台解决方案。
前端和 Native约定了一个规范，Native会根据规范生成你要的页面，这时布局会有一个限制，栅格化限制，由于css完整体系，总可以完成布局。看到的页面都是Native的，点击按钮的时候回调是javascript写的，这样一来的体验和Native的体验相差无几。React Native 的一般型业务的APP的，体验和Native的体验无从分辨。
weex走的是React Native的路线，由于推动方是前端，对前端更友好。
开发时，可以在浏览器中调试，再内嵌到Native中。如果直接在前端容器里调试，就是开发过程中就依赖app了，这样开发效率会打很大的折扣。像微信的小程序等，有自己的一套IDE，直接从工程层面上绕过了这一圈。如，微信公众号，直接提供了一套开发和工具。
开发团队有一套自己的东西，会极大的提升开发效率。
思维拓展：
条条大路通罗马----设计的时候让罗马只有一个入口，只有一个出口。不管路从哪里来，可以在统一的地方打一个标识。不同的出入口要有相同的规则，否则就会出问题。例如：高速路收费站，入口的时候做标识，出口的时候做标识。如此，流量的统计就会实现。收口的工作会让效率变低，但是会更有利于管理。做收口会有一些好处，坏处是面向用户会增加一些成本。生活中的收口的例子有很多，这个思想可以运用在前端甚至整个开发中。前端中的例子：ajax收口。
在业务架构层做个约定：如果在请求url时带了参数，就把参数放在commonData中。在进行ajax请求时一定会把commonData带上。创建订单时会将commonData带上，将flag的数据存在数据库。
整个这些有2个用处：1、例如这个app要去线下推广，会给很多人生成一个二维码，url => domain.com ，如果用户扫了这个二维码就会访问这个url，如果是通过这个url注册了，就会带一个flag参数。这样就知道这个人引导了多少个用户注册了账号。这样每个业务员的KPI一下就做完了。2、现在创业团队拿分红，我们有订单数据，投资人那边会质疑你的数据的真实性。订单数据中会有通用标识的数据，如：Native的app的设备号，获取的ip号。如此，数据齐全了，投资人是不会怀疑数据的真实性的。
以上是请求参数上做的处理。
ajax会返回数据，可能是城市数据，一般的一级城市二级城市基本不会改变，可以存在localstorage。这种存储localstorage的行为不需要业务开发去写，只需要一个方法做一些收口，做一些配置，城市数据就会存到localstorage中去。localstorage也应该封装出来，而不应该直接操作localstorage ，例如可以用store去操作localstorage。数据映射到store就行了。store会操作关注localstorage，什么时候过期什么时候该存。这样就是收口，收口做得好的话，重复的业务就会少很多。