- 通用性，只有多个业务同时在使用，同时具备可抽离性特性的组件，譬如Video/TabBar/TitleBar/ImageUpload 这些在 Native中成熟的组件
- 稳定性，Native 组件不像 weex 上层的组件可调节性大，所以需要注意好 Native 组件一定需要没有Bug，防止修复和更新麻烦，同时 Native 组件一开始应该将大部分情况做成可配置化，防止频繁更新，导致需要适配很多版本
- 原子性，不建议一个组件同时做很多事情，应该是单一的功能，然后通过搭配的方式来得到更多功能
- 811原则，默认80%的功能应该是不需要用户配置很多参数，10%的地方用户可以通过配置一些参数来达到目的，10%的稀有情况可以暂时不考虑，可能这里会花费很多时间开发，所以可以等到有业务需要使用时候，再更新上去
- 统一收口原则，为了避免后续组件变成一个大杂烩，后续迭代视觉交互、新功能的增加需要将通用性考虑进去，这里需要一个人统一来收口、开发维护此组件，可以避免很多“业务特性”来干扰组件的可用性
- 性能体验的优化，Weex 组件比页面的编写更应该保证他的性能体验
- 信任机制：很多时候别人使用你的组件一个很大原因是由于相信你的组件没有问题，是稳定的，同时后续会常常维护的
- 缺少一些汇集起来使用的场景，目前单个组件的使用文档已经详细说明，但是对于多个组件的一些使用，或者页面层面的开发缺少相关案例，后期需要逐步补上weex-ui-demo
- 主题配置灵活性上需要考虑进行，目前更多是通过参数配置的方式来更改主题颜色，其实是可以通过一个统一外部参数的配置来使它修改
- Native的布局方式需要向H5的开发灵活性学习，逐步使用自动布局来实现，同时引入弹性思路开发，避免绝对计算
- 数据绑定方面会越来越便捷，譬如和MVVM思路一样，数据变化后，视图立马修改，而不是手动去触发
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。