前一阵攒了个HybridStart，本来只是自己平时在混合应用项目中用用，后来发现不少前端同行也有这个需求，市面上的同类产品基本都是引擎厂家自己推出的，没办法作为通用框架，于是决定重新整理一下HybridStart，尝试把它做成一个更好用、更通用的混合应用开发框架。
定位
框架定位于混合应用开发最佳实践。
代码层面由核心和UI两部分组成。核心提供一套固定的、足够简单的api，实现混合开发中必不可少的功能；UI由插件和前端组件组成，插件具有一定的通用性，可以适度结合核心功能，前端组件则应该保持独立性，必要时可随意替换。
开发体验上结合混合开发的特点做进一步优化，包括代码组织、文件组织和一些细节优化等。
平台通用性
虽然框架当前版本底层基于APICloud，但各家引擎的核心功能应该是一致的，这些功能使基于web前端技术开发混合应用成为可能，通用框架只能建立在这些核心特性上，周边功能以插件、模板的形式提供，这样适度降低对引擎的依赖，使UI层面的大部分代码掌握在前端开发者手里，同时也可以降低更换引擎的成本。
单从APIcloud的插件库质量来看，原生插件的效果真心不一定好过web前端插件，所以不能迷信原生，原生只是理论上效果最好，到底好不好还得看开发者的能力。
更换引擎的需求也很有必要，长期来看Appcan/APICloud/Dcloud不可能一直共存，短期来看APICloud的api封装对比Dcloud有其不足之处，而且从我自己的角度，也很想在通用性上做一点尝试。
UI可剥离
前几天对比研究了一下Dcloud，从文档各方面看好像更专业，介绍的优化手段也很极致，但演示APP的体验并没有拉开差距，测试机型是红米4高配，已经是千元机了，可能在更低端的机型上有差距？没有进一步测试。不过Dcloud的路数确实跟APICloud不一样，api设计的更底层，确实像是个规范该有的样子，问题是操作起来很麻烦，估计他们也知道这个问题，所以推出mui，mui声称只做UI，但其实还有一个很大的作用是将常用操作集成进来了，也就是说对自家引擎做了易用性封装，这就使得剥离mui的成本变得很高，需要将底层api都重新封装一遍。
我对UI的理解就是一套前端组件，应该可以很容易的从功能上剥离出来，随意替换，否则就是对开发者的绑架。mui已经深度结合了Dloud，做不到单纯的剥离UI同时保留封装功能，对于不愿意使用或学习mui的开发者就不太友好，所以HybridStart要做的就是一个自由度更高的mui，功能该有的有，还可以换引擎，UI不想用可以整个拿掉，一切为了方便。
只解决60%的需求
应用场景是无穷无尽的，妄图覆盖到任何程度都是徒劳。这里的60%并不是严格意义上的大多数，而是结合经验对最常用需求的猜测，在核心功能封装上取最小集合，其他功能以插件或模板的形式体现，或者干脆留给开发者自己去做。
重要的不是做什么，而是不做什么。框架的开箱可用很重要，其中一个指标是冗余程度在接受范围内，否则有代码洁癖的开发者就得花时间去删改，这就违背了框架的初衷。
最后，可能无论如何尝试，结果也只是满足了一小部分人的需求，其他人看看就算了，因为所有的封装理论上都是定向的，不存在哪一个框架能适应各种场景，所以从设计之初就要摒弃这种虚妄，功能不求多，只求精。
后记
总体思路就是这样，具体工作正在展开，有更好的建议或想看看进度，参看这里。
附：最近跟APICloud的技术支持打交道比较多，体验真心不咋地。
前端路上原创技术文章，转载请注明出处：https://refined-x.com/2017/07/03/混合应用框架优化思路梳理/
不甘平庸的你，快来跟我一起充电吧，关注看风景，获取更多精彩内容。