posted by wap, platform: iPhone

引用:

原帖由 @lewx  于 2017-6-29 20:18 发表
正常使用差距在纳秒级别？

理解能力捉急，基本的积分概念都不懂

本帖最后由 KARUTO 于 2017-6-29 20:33 通过手机版编辑

iPhone用什么语言开发？

posted by wap, platform: iPhone

引用:

原帖由 @asac  于 2017-6-29 20:44 发表
iPhone用什么语言开发？

水果官方用Objective-C，还有最近几年刚开始推的Swift

开发者使用任何Xcode支持的语言都可以

6以后强制ART，安卓现在也是机器码。

posted by wap, platform: iPod iTouch

引用:

原帖由 @wangmax  于 2017-6-30 11:20 发表
6以后强制ART，安卓现在也是机器码。

你先搞清楚art的原理，说白了只是少一步编译，执行一样低能

posted by wap, platform: Chrome

引用:

原帖由 @KARUTO  于 2017-6-28 22:35 发表
安卓为了当初的全世界大同计划，采用的JAVA为其应用层的实现方式，而java都是跑在JVM就是java虚拟机里面的。

而且Google自己搞了一套什么所谓的Dalvik virtual machine，这玩意儿效率更低，要打水果的应用，光靠纯虚拟机不行，怎么办呢，Google就在Dalvik里搞了个JNI，所谓的java原生介面，来和其他语言的函数库（主要是c和c++互通），所以基本上JNI在大型游戏和重度应用里早就用的很常见，不过这个只是调用运行层面的东西，JAVA还有一大特点就是程序载入JVM的时候非常缓慢而且消耗大量内存，所以安卓机器祖传普遍需要大内存不足为奇。再者，所谓的调用效率也是可圈可点，以下是别人做的测试。

JNI调用和C++直接调用测试，均for循环1,000,000,000次
JNI调用耗时：6,000ms        6.0ns/次

C++调用耗时：1,400ms        1.4ns/次

单次的时间差应该体现了JNI调用dll的额外时间损耗。这个简单函数的调用效率，C++是JNI的4~5倍。

少年你这个数据都不对啊，Dalvik是几代以前的东西了

posted by wap, platform: iPhone

引用:

原帖由 @jun4rui  于 2017-6-30 23:28 发表
少年你这个数据都不对啊，Dalvik是几代以前的东西了

自己打脸了吧，art说白了就是预编译过后的dalvik，少了一次装载标准，但是效率并没比dalvik 有质的提升，还是虚拟机构架，而且感谢你的论据让大家可以看得更清楚

posted by wap, platform: Chrome
另外Android的JVM载入程序非常缓慢且消耗大量内存，这个麻烦看一下Android各种版本JVM的进化吧，ART是4.4就有的东西，现在都8.0了

这消息的出处应该是这里吧，一看就知道不是搞移动开发的，你这例子根本证明不了什么。

JNI本来就是用JAVA调用原生代码，JNI的全称就是Java Native Interface，java原生接口啊，给java代码和原生代码互相搞基用的，java、原生代码互相搞来搞去当然需要额外的损耗啊，就像Python调用C的库，这很正常。

JNI是两个基佬用网线互插振动棒通过网络搞基，你说怎么爽？

两者互相调用会有时间损耗，这又有什么关系？JAVA和原生代码之间又不需要频繁互通，谁没事写个for循环互通10亿次啊，这不有病吗？就像Python一样，我简单的任务自己干，复杂任务交给C代码去干，干完了返回个结果给我就好了，需要频繁调用吗？

本来这数据就是那人无聊测着好玩的

posted by wap, platform: Chrome

引用:

原帖由 @KARUTO  于 2017-6-30 03:55 发表
自己打脸了吧，art说白了就是预编译过后的dalvik，少了一次装载标准，但是效率并没比dalvik 有质的提升，还是虚拟机构架，而且感谢你的论据让大家可以看得更清楚

Dalvik是在运行中不断将字节码翻译成机器码，ART是一次性翻译成机器码。

所以从来就不是少了一次装载，而是少了很多次的翻译，你的错误在于以为Dalvik是在运行时再翻译，其实不是，Dalvik的JIT机制是在运行时不断翻译的。

另外你犯的一个错误就是ART从4.4推出至今已经更新过很多次了，假设Dalvik真的是多一次装载，但是多年时间来的编译器和虚拟机优化也能提供很大的性能飞跃了，就像Dalvik当初拥有JIT后性能就暴涨了一次。

最后，我贴的那个图是ART早期的性能对比，里面速度已经比Dalvik快了

posted by wap, platform: Chrome
顺便纠正下，ART是编译成Linux本地的ELF原生代码直接跑的
而Dalvik只是编译成dex格式的字节码，然后需要靠JIT引擎去解释执行


要是有人说ELF和dex跑的都很慢，那我只能呵呵了

posted by wap, platform: iPhone
Dalivk 本身就有jin 啊，执行层真的效率不行，art 编译并没有多大改变，而且art编译并不改变程序结构，本质还是要调用runtime

ART会把apk的代码编译成二进制程序，但是光有这个还是没法运行的，需要runtime。

所以还是个虚拟机

本帖最后由 KARUTO 于 2017-7-1 00:53 通过手机版编辑

还有java本身的编程特性是每执行一次就需要装载一次编译一次，art的改善是缩短了这个过程，使得效率提升。

安卓的os构架早定下来了，底层是c，应用层必然是java，既然是java肯定是虚拟机方式跑，就不要再纠结了行不行。

当然这个应用层的java是可以调用其他语言的库的，不过本质上就是java虚拟机，所以效率这种东西在java这里真心不存在的。

posted by wap, platform: Samsung
你对art的理解太浅了，可以去知乎先入门一下，不然解释起来很累

真心的，java机制都没搞清，你以为art出来的机器语言=可执行的？
Java Runtime Environment，JRE知道么…android sdk里面包含了 jre里的类库，所有app要实现功能首选调用的库就是java的runtime，要不然就是调用c++写的库，然则互通效率很低，就算翻译成机器码，运行时候还是要调jre的纯种安卓程序效率更低。
我劝你没事拿个eclipse自己好好写几段玩玩就知道怎么个运行过程了。