[feather]StarlingUi框架——feather抱怨

     虽然feather基于Starling的，由于3D特性纹理会自动铺满，并且只要符合缩放比就可以很好的控制自适应素材的准备。但是自己P图对于自己的代码进行异构，发现其实这样做反而并不是什么好事情。发现问题如下：以待以后慢慢总结！

     1、由于纹理自动平铺，所以我们没有办法自定义素材大小的能力，反而被弱化有一些需要强制的地方反而需要更多的其他辅助操作才能完成。见别人都是直接复写autoSize()方法。

     2、对于素材的要求很高，每一个素材都得符合缩放比率，而策划将界面元素以及构想搭好，美术的素材准备必须严格遵循缩放比率完成。这种侧重显然不适合一些不易于拉伸的图片素材较多的项目吧。

     3、由于feather是基于渲染器来完成的界面显示，但是正是由于渲染器的引入，我们不需要原生提供的渲染器皮肤的时候往往要完全复写渲染器的属性。要不然还不显示。

     4、每一个布局，组件都是作为screen显示，都相当一个容器吧。所以每一个组件内部都有内部组件的对齐方式的调整属性layout,且这种layout的设置就如同CSS一样，符合“大套小”和“就近原则”。由于没有办法可视化编程，所以写起来很坑爹就是，得设置一下，看一下。

     5、虽然官方交给了我们自定义皮肤和主题的方法，但是我们在实际开发的过程当中我们需要的按钮，图标不只是简单的一两个。所以如果能够统一UI库的大公司，可能还有必要开发自己的UI库的可能，像是一般公司估计就得做一个项目渲染一套UI库了。虽然稍微降低了3的抱怨

     6、自定义组件，官方给的教程就是俩字坑爹的！说明了组件的生命周期以及组件结构，就以一个最简单的Label源代码来看，即使我们不见得写的如原生组件那么强大的修改功能吧，但是至少对于几个最基本默认渲染器的了解要很熟悉才行。

     7、最新的1.1.1在air3.1的SDK存在跑位的情况！3.6正常了！

     虽然上面这么多的抱怨，其实主要还是基于渲染器的！加入能够开发一套自己的UI渲染库，那么开发是非常快的。上面提到的缺点往往也变成了优点！

     正因为每一个组件都相当于一个screen来显示的，所以layout这个属性，可以很好地将布局和样式脱离开。并且皮肤素材可以根据官方提供的方法做素材脱离！

      feather不仅在界面显示当中很好的脱离了样式，布局，素材之间的关系，并且在事件的优势以及screen之间的切换上的优势和效率让人值得青睐的。

      正是由于有效显示才渲染，所以显示再多和显示一个没什么区别，并且事件地图的引入，将控制层很好的脱离了出来。加之初始化事件的完善，还是值得一用的。如果真的需要深入学习feather,除了上一次总结，关于开发流程控制和权衡，反而更为重要一些，新的毕竟是新的啊！

      如果想屏幕自适应的话，建议多考虑使用一下layout属性！将一些比较通用的layout封装一下类似于CSS一样。 

　　今天晚上就为了把前面的监听转换为事件地图，并且仔细的更改一个UI页面的自适应方式！坑啊，大坑啊！

转载于:https://www.cnblogs.com/flashbird/p/3393548.html