第一篇:【嵌入式】Android开发NDK C++开发注意事项
Android开发NDK C++开发注意事项
相信Android开发者都喜欢用C++编写一些高效的应用,有关Android NDK的C++开发相关知识Android123总结如下:
1.从Android NDK r5开始支持了STL Port,在这个版本开始就可以使用部分STL库的功能了,比如说vector、string摆脱c下面容易出现的数组未初始化、越界,增强应用的健壮性。
2.很多网友包含了include
system 使用默认最小的C++运行库,这样生成的应用体积小,内存占用小,但部分功能将无法支持
stlport_static 使用STLport作为静态库,这项是Android开发网极力推荐的stlport_shared STLport作为动态库,这个可能产生兼容性和部分低版本的Android固件,目前不推荐使用。
gnustl_static 使用 GNU libstdc++ 作为静态库
默认情况下STLPORT是不支持C++异常处理和RTTI,所以不要出现-fexceptions或-frtti,如果真的需要可以使用gnustl_static来支持标准C++的特性,但生成的文件体积会偏大,运行效率会低一些。
3.支持C++异常处理,在Application.mk中加入 LOCAL_CPPFLAGS +=-fexceptions这句,同理支持RTTI,则加入LOCAL_CPPFLAGS +=-frtti,这里Android123再次提醒大家,第二条说的使用gnustl静态库,而不是stlport
4.强制重新编译 STLPort,在Application.mk中加入 STLPORT_FORCE_REBUILD := true 可以强制重新编译STLPort源码,由于一些原因可能自己需要修改下STLPort库,一般普通的开发者无需使用此项。Android目前最新的NDK版本为r6,相关的学习可以查看NDK中的Samples整体和在PC上开发没有太大的不同。
嵌入式相关资料,欢迎下载!
《嵌入式相关资料》
第二篇:Android 嵌入式开发心得体会
Android 嵌入式开发心得体会
刚开始接触Android感觉到它很有意思,在界面开发上和web也可以形成了相通的架构,更加方便,视觉上也是非常的酷,在前期我通过的大量的Android SDK开发范例大全中的例子以及Android提供的APIDEMOS进行学习,尽管例子之间的连接比较零散,不过通过这些例子的学习我可以学习到了很多和以前java上相通的思想,因为Android在现在也是全新的技术和框架,在其中我也学到了如何用单例模式、工厂模式等常用的设计模式进行学习,通过API进行开发客户端,对Request发送,Response处理中通过比较方便的JSON对象传输,以及对XML、JSON、图片、业务等下载处理,对API接口调用等问题处理,学习Android心得体会。首先在界面上,我们同样可以通过不同布局进行设计非常酷的界面,这些界面可以通过include进行引入,和jsp、html也有相通的地方,同样在android上可以用到自定义的样式这和css也有比较相通的地方,我们可以通过一些公用的方法写个BaseActivity这个基类,通过继承方式比较不错的实现了Activity的界面,因为这样你可以Header(头部)和Footer(尾部)进行处理一些触发事件或者特效等,布局模式以相对模式为主,线线布局模式可以在比较简单的include进行完成,最重要的一点就是:我们可以自己通过重写方法或者通过实现View或者Layout等类进行扩充项目需要的布局(或者控件),在学习界面中,我发现Android为我们提供了很好的类似反射机制,通过Layout文件夹下的配置文件,可以快速的形成界面,在配置文件可以设置属性或者样式都是很快捷方便。对比较特殊的界面也可以通过处理嵌入到指定的界面,同样你可以通过java代码直接创建View进行添加,不过这种方式比较复杂。对一些点击、选中、按键等处理的事件,界面之间的跳转Intent管理,通过Bundle对数据在界面之间进行传输。其次在手机交互式通信服务中,学习了Android手机之间进行短信发送、广播、对广播的监听、服务等,在Service类中没有context,可以通过Handler来每秒反复运行,自动送出系统广播信息,同时在这里我们也知道可以设计一个常用的变量类,设计一个当前的CurrentActivity这个变量进行控制,进行处理。
总而言之,Android设计还是比较自由开阔的,只要有想法,自己动手便能实现。
第三篇:【嵌入式】android教程JNI开发疑点总结
android教程JNI开发疑点总结
很多Android新手对于JNI开发过程中的疑问不是很清楚,根据android123@163.com邮箱中反馈的内容我们整理如下:
1.JNI中,什么情况才处理jstring、jint、jobject这样的类型,其实通过NDK开发Android C++应用,大部分仍然是常规的cpp和h的标准写法,只有需要和Java层通讯的方法才包含了类似JNIEXPORT void JNICALL XXX这样的函数,大多数的逻辑和标准C/C++没有什么区别。
2.我有一个在Windows上开发好的dll能否在Android上使用呢? 这里Android开发网提醒大家,对于dll这样的PE文件只能在Windows平台下使用,而linux上的动态库so文件如果是PC上的也无法通过JNI在Android上调用,由于CPU的指令不同,手机上必须使用ARM交叉编译器生成才可以使用,而PC上的为x86或64位,即使是Hello World这样代码兼容性很强,也必须在NDK中重新编译才能在Android上使用。
3.学习JNI的基础是什么,或者说什么顺序学习? 这点Android123推荐大家先了解Java的类型,和内部编码,然后学习C/C++语言,对于NDK r5开始支持的C++语言,这里Android开发网要和大家说下了,如果需要在JNI中调用Java的类,你可以学习下反射机制,同时C++ STL在NDK r5开始支持,这样开发应用维护起来更方便些。最后看下NDK的Samples下载Android源码Framework层基本上就没有什么大问题了。
4.学习NDK最大的困难是什么? 这里Android123认为,国内网友大多数都在Windows下做开发工作,整个NDK环境需要Cygwin,同时mk这样的makefile编译脚本的手动编写可能不是很友好,这点Android开发网已经准备了一整套的Android开发工具,将在近期公开,帮助大家在PC辅助开发Android应用,同时常见问题提供了相应的链接。
5.在Android JNI用处大吗? 对于大多数开发者来说可能主要用于OpenGL游戏设计上,不过对于纯运算,算法上C语言比Java有着很多天生的优势,这点不容置疑,多一门技术多一个出路嘛,整个Android源代码十分庞大,开源的力量最终还是能打败更封闭的Windows Phone和iOS的。
嵌入式相关资料,欢迎下载!
《嵌入式相关资料》
第四篇:Android NDK C++开发注意事项总结
由麦可网整理,转载请注明出处
Android NDK C++开发注意事项总结
相信Android开发者都喜欢用C++编写一些高效的应用,有关Android NDK的C++开发相关知识Android123总结如下:
1.从Android NDK r5开始支持了STL Port,在这个版本开始就可以使用部分STL库的功能了,比如说vector、string摆脱c下面容易出现的数组未初始化、越界,增强应用的健壮性。
2.很多网友包含了include
system 使用默认最小的C++运行库,这样生成的应用体积小,内存占用小,但部分功能将无法支持
stlport_static 使用STLport作为静态库,这项是Android开发网极力推荐的stlport_shared STLport作为动态库,这个可能产生兼容性和部分低版本的Android固件,目前不推荐使用。
gnustl_static 使用 GNU libstdc++ 作为静态库
默认情况下STLPORT是不支持C++异常处理和RTTI,所以不要出现-fexceptions或-frtti,如果真的需要可以使用gnustl_static来支持标准C++的特性,但生成的文件体积会偏大,运行效率会低一些。
3.支持C++异常处理,在Application.mk中加入 LOCAL_CPPFLAGS +=-fexceptions这句,同理支持RTTI,则加入LOCAL_CPPFLAGS +=-frtti,这里Android123再次提醒大家,第二条说的使用gnustl静态库,而不是stlport
4.强制重新编译 STLPort,在Application.mk中加入 STLPORT_FORCE_REBUILD := true 可以强制重新编译STLPort源码,由于一些原因可能自己需要修改下STLPort库,一般普通的开发者无需使用此项。Android目前最新的NDK版本为r6,相关的学习可以查看NDK中的Samples整体和在PC上开发没有太大的不同。
第五篇:android 开发心得
即 使你的应用程序是快速且响应灵敏的,但一些设计仍然会给用户造成问题——与其它应用程序或对话框未事先计划的交互,意外的数据丢失,意料之外的阻塞等等。避免这些问题,有助于理解应用程序运行的上下文和系统的交互过程,而这些又正影响着你的应用程序。简而言之,你应该竭尽全力去开发一个与系统和其它应用程 序流畅交互的应用程序。
一 个常见的流畅问题是,一个应用程序的后台处理——例如,一个 Service或者
BroadcastReceiver——弹出一个对话框来响应一些事件。这可能看起来没啥大碍,尤其是你在模拟器上单独地构建和测试你 的应用程序的时候。然而,当你的应用程序运行在真机上时,有可能你的应用程序在没有获得用户焦点时后台处理显示了一个对话框。因此,可能会出现在活跃的应 用程序后方显示了你的应用程序的对话框,或者从当前应用程序夺取焦点显示了一个对话框,而不管当前用户正在做什么(例如,正在打电话)。那种行为,对应用 程序或用户来说,就不应该出现。
为了避免这些问题,你的应用程序应该使用合适的系统资源来通知用户——Notification类。使用Notification,你的应用程序可以在状态栏显示一个 icon来通知用户已经发生的事情,而不是夺取焦点和打断用户。
另 一个流畅问题的例子是未能正确实现Activity的 onPause()和其它生命周期方法而造成意外丢失了状态或用户数据。又或者,如果你的应用程序想暴露数据给其它应用程序使用,你应该通过 ContentProvider来暴露,而不是(举例)通过一个可读的原始文件或数据库来实现。
这 些例子的共同点是它们都应该与系统和其它应用程序协作好。Android系统设计时,就把应用程序看作是一堆松散耦合的组件,而不是一堆黑盒代码。作为开 发者来说,允许我们把整个系统看作是更大的组件集合。这有益于我们可以与其它应用程序进行清晰无缝的集成,因此,作为回报,我们应该更好的设计我们的代 码。
下面将讨论常见的流畅问题以及如何避免它们:
一 定要记住Android是一个移动平台。可以显而易见地说,其它Activity(例如,“Incoming Phone Call”应用程序)可能会在任何时候弹出来遮盖你的Activity,记住这个事实很重要。因为这个过程将触发 onSaveInstanceState()和 onPause()方法,并可能导致你的应用程序
被杀死。
如 果用户在你的应用程序中正在编辑数据时,其它 Activity出现了,这时,你的应用程序被杀死时可能丢失那些数据。当然了,除非你事先保存了正在进行的工作。“Android方式”是这样做的:能 接收和编辑用户输入的 Android应用程序应该重写 onSaveInstanceState()方法,并以恰当的方式保存它们的状态。当用户重新访问应用程序时,她能得到她的数据。进行这种处理方式最经典的例子是 mail应用程序。如果用户正在输入 email,这时其它 Activity启动了,mail应用程序应该把正在编辑的email以草稿的方式保存起来。
如果你不想穿着内衣在大街上溜达的话,你的数据也不应该这样。尽管可能存在暴露应用程序的某种形式给其它应用程序,但这通常不是最好的主意。暴露原始数据,要求其它应用程序能够理解你的数据的格式;如果你变更了格式,那么,你将破坏那些没有进行同步更新的应用程序。
“Android 方式”是创建一个 ContentProvider,以一种清晰的、深思熟虑的和可维护的API方式暴露你的数据给其它应用程序。使用 ContentProvider,就好像是插入Java接口来分离和组装两片高耦合的代码。这意味着你可以修改数据的内部格式,而不用修改由 ContentProvider暴露的接口,这样,也不会影响其它应用程序。
如果用户正在运行一个应用程序(例如,Phone程序),断定对用户操作的目的才是安全的。这也就是为什么必须避免创建Activity,而是直接在当前的 Activity中响应用户的输入。那 就是说,不要在 BroadcastReceiver或在后台运行的 Service中调用 callActivity()。这么做会中断当前运行的应用程序,并导致用户恼怒。也许更糟糕的是,你的 Activity可能成为“按键强盗”,窃取了用户要提供给前一个 Activity的输入。视乎你的应用程序所做的事情,这可能是个坏消息。
不 选择在后台直接创建 Activity UI,取而代之的是,应该使用NotificationManager来设置 Notification。它们会出现在状态栏,并且用户可以在他空闲的时候点击它们,来查看你的应用程序向他显示了什么。(注意,如果你的 Activity已经在前台了,以上将不适用:这时,对于用户的输入,用户期望的是看到下一个 Activity来响应)
如果你的应用程序需要执行一些昂贵或耗时的计算的话,你应该尽可能地将它挪到线程里。这将阻止向用户显示可怕的“Application Not Responding”对话框,如果不这样做,最终的结果会导致你的应用程序完全终止。
一 般情况下,Activity中的所有代码,包括它的 View,都运行在相同的线程里。在这个线程里,还需要处理UI事件。例如,当用户按下一个按键,一个 key-down事件就会添加到 Activity的主线程队列里。事件处理系统需要很快让这个事件出列并得到处理;如果没有,系统数秒后会认为应用程序已经挂起并为用户提供杀死应用程序 的机会。
如果有耗时的代码,内联在Activity上运行也就是运行在事件处理线程里,这在很大程度上阻塞了事件处理。这会延迟输入处理,并导致ANR对话框。为了避免这个,把你的计算移到线程里。
任 何值得使用的应用程序都可能有几个不同的屏幕。当设计UI屏幕时,请一定要使用多个Activity对象实例。依赖于你的开发背景,你可能理解 Activity类似于 Java Applet,它是你应用程序的入口点。然而,那并不精确:Applet子类是一个 Java Applet的单一入口点,而一个Activity应该看作是你的应用程序多个潜在入口点之一。你的“main”Activity和其它之间的唯一不同点 是“main”Activity正巧是在AndroidManifest.xml文件中唯一对“android.intent.action.MAIN”动作感兴趣的Activity。因此,当设计你的应用程序的时候,把你的应用程序看作是Activity对象的 集合。从长远来看,这会使得你的代码更加方便维护。
当 谈到 UI观感时,巧妙地交融非常重要。用户在使用与自己期望相反的 UI的应用程序时,会产生不愉快的感觉。当设计你的 UI时,你应该尽量避免太多自己的主题。相反的,使用同一个主题。你可以重写或扩展你需要的主题部分,但至少在与其它应用程序相同的 UI基础上开始。
不 同的 Android设备可能支持不同的屏幕分辨率。甚至一些可以自己变更分辨率,例如,切换到风景模式。确保你的布局和图片能足够灵活地在不同的设备屏幕上正 常显示。幸运的是,这很容易做到。简而言之,你需要做的是为主要分辨率提供不同版本的作品,然后为不同的尺寸设计你的布局。(例如,避免使用硬编码位置而 使用相对布局。)如果那样做的话,系统会处理剩下的部分,而且你的应用程序在任何设备上都看起来很棒。
Android设备会有多种网络连接选项。所有的都提供数据访问,但之间肯定有更快的。其中,速度最慢的是GPRS,GSM网络的非 3G数据服务。即使具备 3G能力的设备在非3G的网络上也会花费很多的时间,所以,网络很慢仍然是一个长期存在的事实。
这 就是为什么你应该按照最小化的网络访问和带宽来编写你的代码。你不能假设网络是快速的,所以,你应该总是计划它是慢的。如果你的用户碰巧在一个快速的网络 上,那很好——他们的用户体验会提升。你要避免相反的情形:在不同的地点和不同时间,应用程序有时可用,有时慢得令人抓狂,这样的程序可能不会受欢迎。
还 有一个潜在的地方是,如果你正在使用模拟器,那么你很容易受它迷糊,因为模拟器使用电脑的网络连接。这比手机网络快很多,所以,你需要修改模拟器设定来模 拟较低的网络速度。你可以在 Eclipse中做到这点,在启动选项的模拟器设置页里设置或者在启动模拟器时通过命令行选项设置。
Android 可以支持多种外观形状。也就是说,一些Android设备拥有全“QWERTY”键盘,而其它可能会有40键、12键或其它键盘设置。同样的,一些设备可 能有触摸屏,但一些也会没有。当创建你的应用程序的时候,记住这一点。不要假定特定的键盘布局——除非你真的想限定你的应用程序只运行在某些设备上。
如 果移动设备经常插在墙上,那么,它也就不是很“移动”。移动设备是电池供电的,如果我们能让每次充电的电池使用得更持久一些,那么每个人都会更加开心—— 尤其是用户。
其中两大耗电硬件是处理器和无线;这也就是我们为什么要写尽可能少做工作、尽可能少去使用网络的应用程序的重要原因。
如 何让你的应用程序最小化的占用处理器,归根结底还是要写高效代码。为了减少无线的电量消耗,确保对错误条件进行正确的处理,并只获取你要的东西。例如,如 果某一个网络操作失败了,不要不断地进行重试。如果失败了一次,有可能是用户不受欢迎,因此,如果你再以正确的方式操作,有可能还会失败;所有你做的都是 在浪费电池。
用户是相当聪明的:如果你的程序高耗电,他们是一定会发现的。到那个时点,你唯一可以确定的是,你的程序将很快被卸载掉。