» 您尚未登录:请 登录 | 注册 | 标签 | 帮助 | 小黑屋 |


 34 123
发新话题
打印

[数码手机] 我终于相信android可以一统江湖了!!

We released the first version of the Native Development Kit, a development toolchain for building shared libraries in C or C++ that can be used in conjunction with Android applications written in the Java programming language, way back in July of 2009. Since that initial release we’ve steadily improved support for native code; key features such as OpenGL ES support, debugging capabilities, multiple ABI support, and access to bitmaps in native code have arrived with each NDK revision. The result has been pretty awesome: we’ve seen huge growth in certain categories of performance-critical applications, particularly 3D games.
These types of applications are often impractical via Dalvik due to execution speed requirements or, more commonly, because they are based on engines already developed in C or C++. Early on we noted a strong relationship between the awesomeness of the NDK and the awesomeness of the applications that it made possible; at the limit of this function is obviously infinite awesomeness (see graph, right).
With the latest version of the NDK we intend to further increase the awesomeness of your applications, this time by a pretty big margin. With NDK r5, we’re introducing new APIs that will allow you to do more from native code. In fact, with these new tools, applications targeted at Gingerbread or later can be implemented entirely in C++; you can now build an entire Android application without writing a single line of Java.
Of course, access to the regular Android API still requires Dalvik, and the VM is still present in native applications, operating behind the scenes. Should you need to do more than the NDK interfaces provide, you can always invoke Dalvik methods via JNI. But if you prefer to work exclusively in C++, the NDK r5 will let you build a main loop like this:
复制内容到剪贴板
代码:
void android_main(struct android_app* state) {
    // Make sure glue isn't stripped.
    app_dummy();

    // loop waiting for stuff to do.
    while (1) {
        // Read all pending events.
        int ident;
        int events;
        struct android_poll_source* source;

        // Read events and draw a frame of animation.
        if ((ident = ALooper_pollAll(0, NULL, &events,
                (void**)&source)) >= 0) {
            // Process this event.
            if (source != NULL) {
                source->process(state, source);
            }
        }
        // draw a frame of animation
        bringTheAwesome();
    }
}
(For a fully working example, see the native-activity sample in NDK/samples/native-activity and the NativeActivity documentation.)In addition to fully native applications, the latest NDK lets you play sound from native code (via the OpenSL ES API, an open standard managed by Khronos, which also oversees OpenGL ES), handle common application events (life cycle, touch and key events, as well as sensors), control windows directly (including direct access to the window’s pixel buffer), manage EGL contexts, and read assets directly out of APK files. The latest NDK also comes with a prebuilt version of STLport, making it easier to bring STL-reliant applications to Android. Finally, r5 adds backwards-compatible support for RTTI, C++ exceptions, wchar_t, and includes improved debugging tools. Clearly, this release represents a large positive ∆awesome.
We worked hard to increase the utility of the NDK for this release because you guys, the developers who are actually out there making the awesome applications, told us you needed it. This release is specifically designed to help game developers continue to rock; with Gingerbread and the NDK r5, it should now be very easy to bring games written entirely in C and C++ to Android with minimal modification. We expect the APIs exposed by r5 to also benefit a wide range of media applications; access to a native sound buffer and the ability to write directly to window surfaces makes it much easier for applications implementing their own audio and video codecs to achieve maximum performance. In short, this release addresses many of the requests we’ve received over the last year since the first version of the NDK was announced.
We think this is pretty awesome and hope you do too.


简单说,现在用android NDK编写android 程序,不用任何一行java代码都可以了。
这样可以充分的发挥其硬件的性能

[ 本帖最后由 masterfish 于 2011-1-13 11:02 编辑 ]


TOP

posted by wap, platform: UC

不翻译,小黑屋



TOP

看不懂,标红也没用。


TOP

不就是能用C++开发?

TOP

posted by wap, platform: GoogleChrome

早就有了,这都是第五版了,不过还是有较大改进

TOP

引用:
原帖由 jun4rui 于 2011-1-13 11:04 发表
posted by wap, platform: GoogleChrome

早就有了,这都是第五版了,不过还是有较大改进
这次的最大不同,就是标红的那句:你现在可以完全不用写任何一行java了。
由于底层的所有的设施,包括内存调度、opengl、电源管理、网路传输等等都是c写的,以前的版本里,你都只能在java下调用,因此效率低下,现在可以直接在c、c++的程序中调用了,进一步的优化必然可以期望。

TOP

posted by wap, platform: GoogleChrome

看到了,有些直接调用API,或者访问视频缓冲区,很好很强大

TOP

现在的发展,软件优化速度赶不上硬件更新

TOP

可惜.这些内容在果青眼里都是android死亡的前兆....

TOP

我还以为是电源管理有所突破了,呵呵呵

TOP

没有友好的ide 开发环境 什么语言都白扯, 弄了那么多开发语言 结果没有一种是好用的易用的而且成熟的,

TOP

posted by wap, platform: GoogleChrome
引用:
原帖由 @jinwyp  于 2011-1-13 11:25 发表
没有友好的ide 开发环境 什么语言都白扯, 弄了那么多开发语言 结果没有一种是好用的易用的而且成熟的,
楼上别扯啥IDE了,专业编程人员用的东西VS/月蚀/VIM/Emacs哪个是友好的?友好的那个菜鸟用的好吧?编程人员不是要友好的IDE,而是好用的IDE。

推荐你看一篇客观点的东西:

John Blanco发表了一篇关于iPhone和Android开发环境比较的文章。虽然从编程语言角度他倾向于Java,但是,他认为XCode和iPhone的模拟器比Google提供的工具更优秀。你觉得呢?

随着移动应用的日益普及,很多人开始尝试比较不同开发环境下的开发体验。大约一年前,David Green发表了一篇针对Android和iPhone开发环境的比较文章,而John Blanco在上周也针对二者进行了比较分析。Dave和John都同意:

使用Java好于Objective-C。私有方法、内部类、匿名类、泛型、更好的功能语法和广泛的第三方代码仅仅体现了Java优势的一小部分,这已经不是竞争了。

John和Dave在Xcode与Eclipse的比较上,意见就没那么一致了:

[John] 我曾经喜欢过Eclipse。我能掌握一个IDE并在工作中获益。从我不得不使用Eclipse以来已经一年多了[...] 收获的是可怕的使用体验...我不知道是怎么发生的。Eclipse臃肿,速度慢,改变编辑器上下文环境(XML vs. Java vs. Android Manifest等)这样的简单行为都会让人心烦意乱,这些动作居然需要几秒钟的时间。[...]它使得做Android开发变成了“悲惨”的经历。与XCode相比,XCode能为你带来快乐的工作。它优雅、快如闪电,在写代码时我从未看见XCode发生迟缓的现象。我对XCode给与肯定。Xcode占有压倒性优势。

Dave认为Eclipse的增量编译器是其主要优点。对他来说内容辅助做的并不好,而XCode则打开了太多窗口:

XCode是如此糟糕,我甚至不知道从哪开始。我觉的XCode要想成为可行的IDE,至少应该完善我提到的最小列表中的特征。

不过Dave喜欢iPhone的Interface Builder。

从模拟器的角度来看,John觉得iPhone的模拟器在真正模拟GPS或加速器方面还有一些欠缺。不过iPhone模拟器的准确性给他留下了深刻影响:

我很少见到在设备上出的问题在模拟器不出现的情况。iPhone模拟器运行很快,我随时可以关闭它,可以很容易进行复位,改变语言等。相反,Android的模拟器是我见过最烂的模拟器。比黑莓的还烂──这说明了一些问题。有时我在模拟器上运行一个程序,无论如何都不能运行,我不得不重新启动。另外它还慢的要命。有一次我想显示某个功能居然用了8秒钟。这正好和我提到的Eclipse问题相关,之所以指出这些问题,是因为我在iPhone开发环境中没有遇到任何以上问题。我碰到的每个Android开发者都说,他们几乎不怎么用模拟器,而是直接在设备上运行程序。

Dave看到的是Java开发环境十年不懈改进的能力,包括全功能调试器、使用JUnit的能力和内存配置工具。

20年前的秋天,我写下了第一行Objective-C程序。我记得那真是个神奇的经历,以至于我不能长时间离开宾夕法尼亚州立大学的计算机实验室。对于很多人来说很难想象,在那样一个遥远的过去(NeXTStep),XCode会和今天一样犀利。Interface Builder作为NeXTStep的基础功能,是Jean-Marie Hullot的智慧结晶,他从1985年就开始做这方面的工作,NeXTStep引导Tim Berners-Lee在CERN建立了Web的基础。与他一起的还有Jack Greenfield,他开发了第一个ORM工具,为模型驱动引擎建立了坚实的基础。有了这样一个创新的历史,也就难怪XCode依然可以运行在2010年了。但是它现在仍然与时俱进吗?还在领先么?能持续改进吗?与其他语言相比,Objective-C还是一门足够先进的语言吗?或者,XCode已经落后了,会因为更先进的、模型驱动工具的出现而不再流行?我们甚至可以问MVC是未来吗?或者,Android的概念和方法更优越?

对此你有什么考虑?

TOP

引用:
原帖由 jun4rui 于 2011-1-13 11:31 发表
posted by wap, platform: GoogleChrome

楼上别扯啥IDE了,专业编程人员用的东西VS/月蚀/VIM/Emacs哪个是友好的?友好的那个菜鸟用的好吧?编程人员不是要友好的IDE,而是好用的IDE。

推荐你看一篇客观点的东西: ...
我就想说xcode 好用的来者
android 有什么, 不知道你举的这篇文章本来就是证明我的观点.

TOP

posted by wap, platform: GoogleChrome

Xcode有Xcode的好用,月蚀有月蚀的好用

TOP

引用:
原帖由 jun4rui 于 2011-1-13 11:31 发表
posted by wap, platform: GoogleChrome

楼上别扯啥IDE了,专业编程人员用的东西VS/月蚀/VIM/Emacs哪个是友好的?友好的那个菜鸟用的好吧?编程人员不是要友好的IDE,而是好用的IDE。

推荐你看一篇客观点的东西: ...
喷了,obj-c和java就是一路东西,有什么好比得。
2个都有垃圾回收
obj-c用得是protocol,java用得是interface
obj-c下面有runtime环境,java有jvm环境
obj-c得类库强大,java得类库也丰富
java多了跨平台尽管用处不大,但obj-c可以变身为obj-c++通吃c/c++等。

至于ide完全是看个人习惯,好用得代码编辑工具太多。

TOP

 34 123
发新话题
     
官方公众号及微博