Weex组件方向晚间圆桌讨论总结1.Weex原生组件打包需要注意什么？通用性，只有多个服务同时使用，具有可分离特性的组件，如Video/TabBar/TitleBar/ImageUpload这些Native中的成熟组件是稳定的，Native组件不像上层组件那样可调weex大，所以需要注意Native组件一定不能有bug，以免修复和更新麻烦。同时，Native组件一开始大多数情况下应该是可配置的，防止频繁更新，导致需要适配很多版本。不推荐原子性一个组件同时做很多事情，应该是单一的功能，然后通过搭配得到更多的功能2.weex组件开发实践的一些经验？811原则，默认80%的功能不应该要求用户配置很多参数，10%的地方用户可以配置一些参数来达到目的，10%的罕见情况可以暂时忽略，可能需要很多有时间在这里开发，所以可以等到有业务需要用到的时候再更新，统一关闭原则。为了避免后续组件成为大杂烩，后续迭代的视觉交互和新功能的加入需要兼顾通用性。在这里，需要一个人统一关闭、开发和维护这个组件，可以避免很多“业务特性”干扰组件可用性和性能体验的优化。Weex组件比页面的写法更要保证其性能体验。你的组件没有问题，稳定，以后会经常维护。3.你觉得WeexUi组件还缺少什么？缺乏集体使用的场景。目前已经对单个组件的使用文档进行了详细的讲解。但是对于多组件的使用，或者页面级开发相关案例的缺乏，需要后期逐步增加weex-ui-demo主题配置的灵活性。需要考虑。目前主要通过参数配置来改变主题颜色。其实可以通过统一的外部参数配置来修改。4、未来跨终端发展会是什么样子？Native的布局方式需要借鉴H5的开发灵活性，逐步使用自动布局来实现。同时引入灵活的开发思路，避免绝对的计算数据绑定。它会变得越来越方便。立即修改它而不是手动触发它
