今天早上我刚升级也是非常卡，iphone 6。
百度了一下。重置设置以后，好了很多。

@joshz 我的免费数据库挂了，以前它是这个样子的。


http://r.photo.store.qq.com/psb?/V104D9rV1frjT9/VxX3O6H1lmwqQDcWElC8YPMJtj*ZkNfjJED5WLbZzoE!/o/dB1*3HRdMQAA&bo=QAY2AkAGNgIDACU!&rf=viewer_4

楼主可以搜索一下这个
GitHub - ACRA/acra: Application Crash Reports for Android
https://github.com/ACRA/acra

我就是配置的这个，错误信息会自动发送到远程服务器指定的数据库里面

具体的设备信息 堆栈日志 都是有的。

@4faramita 已验证流量节省，虽然开启能打开网页（还很慢），但无法连接 google 服务器。

内容未压缩，没什么用。

谢谢，我去验证下第一个。

我觉得智能电视或者电视盒子很不忠诚，前段时间我的电视盒子（阿里云系统），右上角出现了一个通知，上面写着 test ，你测试你的东西就算了，还推送给真实用户。推送一个消息也就算了，

还给我自动（静默）安装了一个 app 。

试问如此“智能”之电视，真的有传统电视好吗？

做为程序员，我感觉电视变成了别人的肉鸡。

感谢楼主 github已关注。

仔细推敲一下，你的思维认知是站不住脚的。

+=触发了dom的reflow，与之比较的其他方法是否也进行了reflow？
这里我断定reflow的时间成本是相同的。

从数据结构上进行分析，你也知道dom是一个树形结构了。
树形结构添加元素需要什么？节点

createElement正好创建的就是节点。
而innerHtml这个字符串对于树来说，没有任何意义。


假设你的说法成立，innerHtml的效率比createElement的高。
那么站在规则制定者的角度来说。同一个功能，有2种方法都能实现。
而且其中一个方法效率优于另一个，且还最便捷。

那是不是应该将效率低的方法标记为deprecated，日后慢慢的移除？
w3c有这么做吗？



从facebook工程师向createElement这一经典方法进行致敬，不难看出，
这个方法的用法、理念将不断延续下去。

dom树都是需要构建的，不论怎么优化，至少是要构建1次的

createElement方法的确繁琐，但你自己写浏览器的话，是不是既要开放繁琐高效的接口，又要提供便利的接口。

字符串描述的是dom对象。中间需要转化

你可能见过React.createElement这个方法
facebook的工程师肯定是知道原生js有同名方法的，假设用法不同，理念不同，人家是不会用这个名字的

为什么它不叫React.innerHtml?

值得思考

@xujif 既然讨论技术，我也就谦虚点。

我没有费尽心思优化。document.createElement是js里面一个比较基础的方法，是由各个浏览器厂商根据w3c的规范进行实现的。很早就有的方法。

这个方法是在内存里面构建dom元素
而innerHtml也是浏览器原生方法，但它接收字符串。

添加dom节点的时候实际上是需要添加一个dom对象的
createElement相当于在内存中描述好了这个对象，

而innerHtml的字符串是需要浏览器自己解析字符串，并且构建dom对象的，相当于多了字符串解析的过程

这个快慢还不明了?

关于你上面提到的+=，你可以反推一下，这个符号重载的拼接字符串就算是慢，有可能慢40%吗，它真正的开销在于字符串解析

我是一个比较较真的人，我喜欢研究技术。请用你理性的经验说服我。

上面那个是女孩，她对性能不追求，不好强求，但作为一个认真的程序员，就算不写这样的代码，也应该知道哪些东西是真正能提升代码性能和质量的。

@xujif 你跟我讲技术，我没听？

你扯7扯8，只能显露你的无知，

拜托你多百度一下，多学点东西。你以为前端就你想的那样，就你还能来看javascript代码？

就你这样，对待知识一点不认真、不严谨，就在这里装b



好的前端开发都是懂后台的，你写的那些东西，我不用看就知道是啥玩意。

我上面说的知识点，你自己稍微百度一下，看看你自己是多无知。



我这么无礼是因为我见不得对待知识不谦逊的人，就知道瞎放屁，一句都不在理。

一行代码没写过，就来跟我讨论dom渲染性能。

@xujif 我说你这种sb能别在这里丢人现眼

模板引擎自己createElement?

这个方法是bom原生 浏览器自己实现的方法。

国内东西做的垃圾就因为你这样不求甚解 敷衍鸟事。

2b东西

@xujif 所有的编程语言里面的思想，理念都是相通的。只有你这样的sb才会觉得不能类比。

你举得性能例子是为的举例而举例。
渲染数据一般都是要渲染一些集合，是需要用到循环的。

我举得例子是我实际开发经验中，经常碰到的，的确能提升性能的例子。

你讲技术，讲不出个东西，一说到一些深的东西，你说你不清楚。

你不清楚就不要装b，搞的好像你要在你不懂的领域装b，别人看不出你是个sb一样。

@zythum “优化是浏览器去做的”

行了，没别的了，你做的东西我明白了。


楼主问这个问题说明他不是很清楚。这个时候他该使用bom的一些原生方法去渲染结构。

只有经历过这些，才会思考，有没有更好的方法。怎样做更好。

模版引擎是怎么实现的。他们有哪些差异...


什么都不明白就直接开始用模版引擎，就跟你现在一样，对性能一无所知。

就等着浏览器帮你优化。当然大多数应用不太需要这些性能的提升。


但移动端或许需要，以及未来更多的智能设备。

@xujif 你是sb吗 你不知道手动操作内存，比自动的效率高很多吗。

懒得和你当键盘侠了，你去问问做ios的 资深的 看 手动效率高 还是 自动高。。

自动是因为程序员能力不足，人家给你一种舒服的方式，降低难度。

真要做好的 还得是手动人工管理的东西。



另外createElement相关方法是DOM 1 specification 里面就有的，也就是说ie6也是支持的。

效率的提升同样适用，别拿你不知道的兼容性说事，你是做前端的吗？

你是做开发吗，写过多少行代码，就研究编译器了？

@Ahri 我想楼主并没有玩插件这样一个东西，chrome有许多好用的前端插件。

比如有一个插件名字叫做 SnappySnippet


比如我现在要模仿支付宝做一个页面，我用这个插件只需要点一下按钮，html、css、全部搞定了


楼主呢，需要多长时间呢？是不是需要开发一天呢？ 这就是效率。不用再争论了

@xujif http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/61


sb东西 性能高了40% 另外createDocumentFragment这个方法dom结构只会reflow一次

作为一个程序员，天天写些垃圾代码，从不思考怎么提升代码性能，有什么用？

@zythum 性能差异微乎其微？好意思说出口？

你看老外现在研究的前端框架，没什么人讨论jquery了吧？因为大家都会用了，现在要求精了

react为什么这么多人用，难道不是因为别人的性能高？ react的开发成本比jquery可高多了


假设你只要完成任务，ok你现在的技能足够了。假设你要做的性能好，远远不够。

代码级别的性能就应该开始追求，那怕一点点。