混合应用框架优化思路梳理

前一阵攒了个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的技术支持打交道比较多,体验真心不咋地。

前端路上原创技术文章,转载请注明出处:http://refined-x.com/2017/07/03/混合应用框架优化思路梳理/

对文章内容有任何疑问欢迎留言讨论,或者扫描下方二维码加入“前端路上-知识星球”付费提问。

前端路上-知识星球