输入关键字进行搜索
刚开始用的时候很有惊艳的感觉，可是越深入，越感觉无力。发几个使用MUI时遇到的问题，不知有没有办法解决。1。首先是文档问题，不知道下面这个址是不是全部文档，http://ask./docs/，如果是的话，那也太少了，为什么不像phonegap那样分门别类做一个列表，这应该不会很费时间吧。现在的情况是我想找某一项功能，比如prompt，根本就无从下手，不知需要哪些参数，具体怎么写。只能建一个Hello mui的演示项目，在手机上运行，找到dialog示例，然后再到电脑上的相应页面找代码。抛开在手机上找示例麻烦不说，HBuilder只能在一个手机上运行一个项目，也就是说我工作时要用两个手机，一个用于查看API，一个用于调试。。。2。Hello mui示例代码里有一段代码，template = plus.webview.getWebviewById(&default-main&);我不知道&default-main&这个ID是在哪里设置的，我只能认为系统默认的webview的id,可是我参考这个写法在我新建的项目里，并没有取到任何东西。3。我想做一个类似prompt的功能，但是不能用系统的prompt，因为我要自定义样式，并且放上一张图片。开始我的做法是用popover的框架，自己写了css，带出来的问题就是黑色半透明的遮罩层不能全屏，因为我们的界面是由两个webview组成的，一个header，一个list，popover在list里，不能覆盖header，因为我的header有一个搜索框，高度是88px，出来的结果是界面上白下黑分成两段很明显，肯定是不能接受的。如果把list和header放在一个webview里可以解决这个问题，但是恐怕下拉刷新和滚动又会出新的问题。然后我又做了另外一个方案，参考示例中的slideMenu，新建两个webview，一个用于显示遮罩，一个用于显示弹窗，但是问题又出现了。首先webview没办法设置圆角（或者我没找到方法），这和我们的设计稿不符；第二当软键盘弹出时，在IOS中可用，但是弹窗界面会向上移，导致弹窗像被裁切了，看起来很突兀，而在Android，则干脆用不了，软键盘在弹出后闪一下又缩回去了。没办法我只能放弃设计用回系统的prompt，可是这也并不完美，在Android中软键盘仍会弹出后自动缩回去，需要再点一下，这个体验很不好。现在我仍在考虑是否要放弃mui寻求其它解决方案，可是又有不舍。真是很好的东西，可为什么有这么多瑕疵呢。最后，我还要吐槽一下这个网站上的编辑器，为何数字列表编辑的时候明明是1.2.3.，发布后却变成1.1.1，最后把&.&改成&。&才解决。
详细的文档可以直接看5+的API
http://www.html5plus.org/#specification#/default-main这个ID是在list.html中设置的，预加载共用父模板那部分:&id:name+&-main&要把要把获取webview对象和DOM对象区分开来，不要局限在某个文件里。
popover阴影的问题 可以通过evalJS执行父页面的mask.show()来解决。官方明显是人手不够，再加上本身有负责IDE的，负责5+的，负责MUI的，太分散了，没有太多精力去做这些吧。想用好MUI，最好还是了解一些原生开发的知识，很多坑碰到过一次之后，发现处理起来还是很简单的。目前，在性能优化和方便易用上只能取其一，不考虑性能问题的话可以试试APPCAN或者Apicloud，封装好了大量的原生控件供调用——但是我还是更看好MUI，因为能看出来官方实在用心优化每一个细节，好东西不怕等…
可以在www.dcloud.io/helloh5和www.dcloud.io/hellomui下载包单独安装，避免和真机调试包混合。
mui的api确实少，因为大部分api在，html5plus.org/#specification ，比如prompt，在http://www.html5plus.org/#specification#/specification/nativeUI.html 里。
我们正在升级文档系统，尤其是搜索强化后，会更方便大家找到功能。另外mui本身有些api是内部实验api，虽然出现在示例代码里，但因为还有争议而没放到文档里。近期大部分争议已经有了明确结论，已经开始调整文档了。新的测试版HBuilder，已经提供了原生的全屏遮罩层，是webview的一个新style，mask。
预览版下载地址是：/s/1i3EGwWd
第二个问题：
可以参考一下list.html 的 444行
id:name+&-main&,父窗体在493行：getTemplate('default', 'examples/template.html');这个问题也是我第一次装HBuilder的时候折腾了好久的。
同感。文档欠缺太大了，开发过程坑太多。我估计框架本身的bug还太多，根本没精力去搞文档。
希望等过一阵dcloud都理顺了，能够真正开源协作的了，会上一个新台阶。
先填文档这个坑吧，现在感觉就是多套产品之间步伐不协调，刚看到网站时，阅读半天才分清楚这个产品线，每块都是干嘛的，应该如何选择。
HBuilder在性能方面比APPCAN强，但在做实际应用的时候，会发现很多很难解决的问题，可能是我们对HBuilder理解不透，但也从另一方面说明很难从现有的文档或案例中找到解决方案。
希望HBuilder能尽快成长起来
有道理必须得支持
可能觉得整理文档太简单了，没有重视。
同感，很多js和css的用法文档中都没有
该问题目前已经被锁定, 无法添加新回复
浏览: 1659
关注: 11 人输入关键字进行搜索
众所周知，APICloud因为侵权DCloud而被DCloud起诉。
APICloud将面临高额赔偿和倒闭风险，详见DCloud官方声明但本文先盖住DCloud工程师对APICloud侵权的愤怒，理性的分析下两家公司的产品。
关于HTML5的重视力度不同
DCloud是专注于发展HTML5的，而APICloud是更关心iOS和Android的跨平台App开发。
所以DCloud有专业的HTML5开发工具HBuilder，除了开发App还是可以开发普通前端，包括手机浏览器版本和微信版本。
所以DCloud有mui框架，可以用于App，也可以用于手机浏览器和微信。
这造成的结果就是，开发者使用DCloud产品，可以真正的跨平台，一套项目代码略做判断，可以变成手机浏览器版本、iOS App、Android App、微信App，而APICloud开发一次，只能输出iOS和Android App。
对HTML5的价值理解不同
HTML5不如原生，所以需要扩展。但如何扩展，两家公司思路不同。
DCloud的产品命名就可以看出DCloud的思路，HTML5+的意思是基于HTML5做扩展，不做HTML5能做的事情。DCloud本身是W3C的会员，HTML5plus.org里的专家委员很多都是W3C的标准参与者，不会重复立项HTML5可以做的事情。
但APICloud的思路不是这样，他不是W3C会员，他们不在意HTML5能做什么，或许也不够了解HTML5能做什么，统统写原生控件，比如城市选择这些业务也通过原生控件来实现。而如果DCloud做了这种封装，会被W3C的同仁笑死。
原生有40多万API，DCloud的思路是HTML5Plus来解决28原则里最常用的跨平台API，比如barcode、file，尽量控制封装层的厚度，减少runtime的体积。然后DCloud开发了Native.js技术，来解决剩余40w原生API的调用问题。此外DCloud还提供了5PlusSDK，也支持三方开发者开发原生插件。
但APICloud的思路不是这样，当然也可能是技术水平不足以突破Native.js，这使得APICloud在疯狂的封装原生API，包括之前提到的城市选择也通过原生封装。当然40w个api这么封装下去不是事，所以APICloud做了模块市场，希望其他人也来做封装。但问题是这个市场真的存在吗？交易流通能活跃吗？
结果就很明显了，DCloud的runtime更小，API更多，40w原生API都可以调用。当然Native.js开发需要些原生基础，这和APICloud模块开发需要原生基础一样，但Native.js的门槛更低、并且是开放自由的，DCloud提供了大量的现成Native.js示例代码。以及DCloud的5PlusSDK的开放性比APICloud的模块开放性更好，只是DCloud还没有为此建立市场（其实是因为DCloud认为技术人员的钱没有赚的意义，DCloud鼓励开源而不鼓励商业，我们也相信APICloud的模块开发者事实上也赚不到钱，一个APICloud模块开发商也亲口向我证实）
至于APICloud，它的runtime包体积更大，能力更少，虽然看起来模块较多，但质量和可用性并不好，有问题也无法自己修改。
对开放性和开发者自定义权力的理解不同
DCloud很在意开放性，ui部分的核心，mui是基于MIT的开源协议，完全允许开发者自己随便改。
但APICloud的ui大多是原生封死，不开源也无法自己定义。而ui是app里非常个性化的部分，经常需要改。
DCloud的runtime里业务组件都在github上开源的，比如audio、barcode、map、payment、push、share等，开发者如需要自定义相关功能或发现bug要改，可以自己直接处理，甚至可阅读源码以方便排错。
但APICloud对于开发者是没有自定义能力的，它不开源，它的ui和功能都是封死的，无法自定义，它的bug或三方模块的bug开发者也改不了，也无法扩展。
DCloud允许本地打包，开发者可以自由内嵌5
SDK，开发者不用担心代码必须提交给DCloud的服务器。但APICloud只能使用他们的云打包，代码必须提交到他们的服务器。对于很多内网开发者，这点更无法接受。
DCloud支持开放的规范，DCloud本身是W3C的会员，参与HTML5规范的制订讨论，HTML5Plus.org也是一个三方公立组织，允许任何厂商按照HTML5+规范来开发实现自己的runtime，甚至APICloud也可以按照HTML5+规范来开发自己的产品，这样开发者开发一次，就可以有更多终端可以使用。但APICloud都是私有规范，或者说都是自己定义的api，上升不到规范高度。
关于HTML5Plus.org，多说几句。HTML5Plus.org是W3C指导下运作的组织，很多大公司或深或浅的参与其中。比如360手机助手就支持HTML5Plus规范，它首页有一个上门服务，这个栏目的App都是基于HTML5的，里面的应用访问扩展能力如原生登陆、原生支付都是调用plus.oauth和plus.payment。
开发便利性
众所周知，HBuilder是业内一流的HTML5开发工具，代码提示、用户体验、极客风格、真机运行、边改边看，拥有众多创新，让开发者开发和调试过程更爽更高效。
HBuilder有最全的语法库和浏览器兼容性，有强大的js解析提示引擎，APICloud虽然抄袭了HBuilder的代码助手，但HBuilder的语法库和js引擎是单独加密的，没有被抄走。所以APICloud的代码提示界面看起来和HBuilder一模一样，但提示功能却弱很多。
HBuilder有mac版，支持ios模拟器；APICloud不支持。
HBuilder支持iOS设备真机运行和日志反馈，还可直接定位行号。APICloud虽然早期抄袭了HBuilder的真机运行代码，但后期HBuilder改进的iOS设备日志反馈因此而单独加密过，APICloud没有此功能。（也因此导致今年DCloud每个版本发布都得多花时间做加密，降低了DCloud的效率，最终逼迫我们发起诉讼）
前端框架的比对
DCloud有开源的mui框架，小巧、漂亮、高性能。这对于开发者非常重要。
而且DCloud就基本js操作推荐使用原生，没有依赖jquery或zepto。因为手机端都是webkit内核，基本js操作无需再封一层框架，多封装一层反而降低执行效率。
APICloud的前端框架并不是ui框架，而是在zepto上改了一个js框架，去掉了一些功能。这样的框架我们认为没什么存在意义。还不如开发者自己引用zepto更方便和可控。
DCloud重视精品App，APICloud重视入门新手
DCloud认为HTML5要起来，需要精品App，我们极力在改善高级开发人员的体验，因为我们知道这样的人才能做出精品App。所以很多大公司都在使用DCloud的产品，比如360、csdn、明道等知名公司。还有很多非常大的公司的App还在开发中，过段时间会陆续发布。
而APICloud更重视新手，强调从0开始30天完成App，APICloud确实有很多这样的App，但我们都知道这样的App无法获得最终用户。从实际案例来看，目前还没有任何知名公司在在APICloud平台上开发App。
产品观不同
DCloud的产品观有2个特点，一个是极致，一个是节制。
我们在关键点上非常追求极致，通过突破创新来解决遇到的问题，我们要最全的语法库、我们要调用40万原生API，我们会突破这些技术难题。
同时我们又会极力控制HTML5 和mui的功能蔓延，控制封装层的厚度，控制runtime和mui的体积，保证每个新增的功能都精巧的解决关键问题。
但APICloud是遇到什么问题就增加什么功能，不停的用原生封装封装，功能越来越多，问题越来越多。
也说说APICloud的优势
APICloud也有它自己认为的优势。但我们允许他这种优势的存在，是因为我们并不认为那叫优势。
&优势1&：代码加密
APICloud宣传自己可以加密开发者的HTML代码，但事实上他们的技术不过关，根本无法加密。我们已经通过北京方正公证处公证了如何轻易得到APICloud的加密后的源码，无需任何专业破解过程，其漏洞很可笑。并且我们也以虚假宣传的名义起诉了APICloud。请广大开发者不要被误导。
&优势2&：模块市场
APICloud之所以重视模块的原因是他们没有Native.js技术，自己封装40多万原生api不可行，所以建立模块市场希望其他人来开发模块。但我们很清楚这类市场无法正常运转，制作模块的人无法获得足够的收入来支持他开发和持续维护优质的模块，使用模块的人也得不到优质的产品和服务。后续DCloud会在合适时机建立插件共享平台，我们会以不同的思路来做成这事。
&优势3&：云端一体
不知道哪个初创公司敢喊出这种口号，一个创业团队要先做好一件事。没人能把云和端同时做好。
DCloud虽然也挂着Cloud字眼，但我们的云服务都是与外部专业机构合作的，比如推送、统计是个推和友盟提供的。
但APICloud是自己都做的，推送、统计和数据存储都想自己做也都在自己做。
事实上优质App的开发者也还是会选择专业的人来做专业的事。
&优势4&：社区和用户
本来本文是对比产品的。但APICloud最近总是通过宣传他们用户更多、他们社区更活跃来混淆视听，一个枪手原文如下：“AC的用户越来越多，截止到本帖，论坛用户最新UID=94711
共有主题34000多，DC的问答区的类别是42页共计418个，问题共计1000不到。是想借机炒作吗”。我本来不知道APICloud用户是多少，不过如这位枪手所说的话，那还真是反被笑话了。DCloud的用户数不便公开，但怎么也是6位数啊。DCloud的用户数、用户质量、项目数、项目质量各个都更高，你们就别闹了好吗？
关于DCloud的问答系统和APICloud的论坛，有完全不同的定位。APICloud的论坛是当做论坛来运营的，会关注帖子数和活跃度。但DCloud不是这样的，我们是做产品的、不是做论坛的。问答系统是产品的支撑工具，要求沉淀高质量内容。我们还会删除水贴、定期清理过期问题，即便这样，我们也沉淀了6千多条问题，APICloud的枪手这算数不知道怎么算的。
\n通过以上的分析，已经比较系统的梳理了两家公司的不同。
当然如何选择，还在于开发者自己。
关于技术细节，api如何转换，可以访问这篇文章关于本文的评论，请APICloud的枪手自重。我们并没有删除你们的枪手号，允许你们留言辩论APICloud的真正优势，我们接受就产品技术而言的理性讨论问题，你们有真正好的东西我们会承认。但不要像小孩吵架那样没由来的攻击。
我的回复很客观，没有什么怒火。哪个避重就轻，不懂。那就点对点应答下：
1.a抄袭d已经是基本事实.
2.d技术实力比a高,基本肯定
3.d没有a人性化,可通过测试说明
不理解，我们觉得我们的产品设计的更人性化
4.a支持第三方虚拟机直接真机测试(天天模拟器).d不支持第三方,仅支持谷歌
误解，我们支持三方模拟器，天天模拟器没用过，但Genymotion和海马玩都是支持的。
5.a集成了很多模块,d没有
正文已经说过，a全部依赖封装，封装部分比d重，但d的Native.js更强大，api数量更多，d也有扩展插件，只是未建立插件市场。这个方面我们是有计划的，但思路又与a不同。
6.a生成体验要比d好
没觉得a的哪个案例达到d的案例水平
7.a的ide没有d好
感谢认可。
我们不藐视一切问题，我们也天天加班在解决各种问题，但我们确实有我们的思路和取舍，也有众多认可我们思路的开发者和知名合作伙伴。
要回复文章请先或对于我们开发者来说，收到抨击同行业竞争的邮件，感觉非常不舒服，产品好不好，服务好不好，应该由用户来反馈，不要把我们开发者当做你们的武器，请那些发匿名信的人像个爷们一样挑战我们开发者，让我们心服口服，不然我们永远都瞧不起！！！
1. “卧底说”纯属瞎扯
APICloud在2014年发布的第一个版本就含有侵权代码，他们发版时我们根本不知道这家公司，如何派卧底。其次我们也不耻于做这种事，DCloud从来都行得正、走的端。
APICloud确实侵权了，我公司官方声明说的很清楚，我个人也实名再次在这里告诉大家：APICloud确实大量抄袭了DCloud的代码，并且远不止那个一个dll文件。他们是抄我们连续抄了很多个版本搞得我们实在受不了了才决定动用法律武器。2. DCloud从未雇佣过水军，也没有派小号故意破坏对手的群提醒各位开发者，不要看到反apicloud的人或事就以为是我们做的，对apicloud有意见的人和公司很多。我们这次发起诉讼后，业内很多公司和个人都给我发泄对APICloud的不满。3. 判断真伪，不要看匿名吵架，很多匿名人士发言都是为了混淆视听。要看就看官方或实名的言论。
别的不说，我想知道DCloud说APICloud开发的东西居然包含DCloud的数字证书，这是怎么回事？只有两种可能：1.APICloud真的侵权了。2.APICloud出内鬼了。问题补充&&
本页链接：
猜你感兴趣
服务声明： 信息来源于互联网，不保证内容的可靠性、真实性及准确性，仅供参考，版权归原作者所有！Copyright &
Powered by}