C, C++, Obj-C

[译]Android冰淇淋三明治ICS(4.0+)JNI局部引用的变化

2013年05月14日 4, ? C, C++, Obj-C Java, JavaScript 移动平台 设计开发

译序：

这篇文章的内容实际是在我发现一个项目bug后寻找解决方案时找到的，当时项目原有target为8（ICS 4.0之前的2.X版本），在4.0+的S3上运行一切正常，而后target升级到14时再在S3上运行时就会出现类似如下的native crash：

05-13 14:07:13.139: E/dalvikvm(22265): JNI ERROR (app bug): attempt to use stale local reference 0x20d00001
05-13 14:07:13.139: E/dalvikvm(22265): VM aborting
05-13 14:07:13.139: A/libc(22265): Fatal signal 11 (SIGSEGV) at 0xdeadd00d (code=1), thread 22457 (Thread-1276)
05-13 14:07:13.239: I/DEBUG(1894): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-13 14:07:13.249: I/DEBUG(1894): Build fingerprint: ‘samsung/m0zc/m0chn:4.1.2/JZO54K/I9300ZCEMB1:user/release-keys’
05-13 14:07:13.249: I/DEBUG(1894): pid: 22265, tid: 22457, name: Thread-1276 >>> cn.android.app <<<
05-13 14:07:13.249: I/DEBUG(1894): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadd00d
05-13 14:07:13.489: I/DEBUG(1894): r0 00000000 r1 00000000 r2 deadd00d r3 00000000
05-13 14:07:13.489: I/DEBUG(1894): r4 408cb1a8 r5 0000020c r6 20d00001 r7 fffff86c
05-13 14:07:13.489: I/DEBUG(1894): r8 5ee308dc r9 00004e58 sl fffff870 fp 5ee307b8
05-13 14:07:13.489: I/DEBUG(1894): ip 00004000 sp 5ee30540 lr 400f7c95 pc 40866e50 cpsr 60000030
05-13 14:07:13.489: I/DEBUG(1894): d0 3ff000003f800000 d1 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d2 0000000000000000 d3 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d4 0000000000000000 d5 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d6 0000000000000000 d7 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d8 0000000000000000 d9 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d10 0000000000000000 d11 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d12 0000000000000000 d13 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d14 0000000000000000 d15 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d16 0000000000000000 d17 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d18 0000000000000000 d19 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d20 0000000000000000 d21 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d22 0000000000000000 d23 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d24 0000000000000000 d25 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d26 0000000000000000 d27 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d28 0000000000000000 d29 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): d30 0000000000000000 d31 0000000000000000
05-13 14:07:13.489: I/DEBUG(1894): scr 60000010
05-13 14:07:13.499: I/DEBUG(1894): backtrace:
05-13 14:07:13.499: I/DEBUG(1894): #00 pc 00045e50 /system/lib/libdvm.so (dvmAbort+75)
05-13 14:07:13.499: I/DEBUG(1894): #01 pc 00028c3c /system/lib/libdvm.so (IndirectRefTable::get(void*) const+336)
05-13 14:07:13.499: I/DEBUG(1894): #02 pc 00049eeb /system/lib/libdvm.so (dvmDecodeIndirectRef(Thread*, _jobject*)+30)
05-13 14:07:13.499: I/DEBUG(1894): #03 pc 0004ca77 /system/lib/libdvm.so
05-13 14:07:13.499: I/DEBUG(1894): #04 pc 00653480 /data/data/cn.android.app/lib/libgameapp.so (CKSoundManager::LoadBGM(char const*)+56)
…
05-13 14:07:13.509: I/DEBUG(1894): memory map around fault addr deadd00d:
05-13 14:07:13.509: I/DEBUG(1894): be9ae000-be9cf000 [stack]
05-13 14:07:13.509: I/DEBUG(1894): (no map for address)
05-13 14:07:13.509: I/DEBUG(1894): ffff0000-ffff1000 [vectors]
05-13 14:07:13.674: I/DEBUG(1894): !@dumpstate -k -t -z -d -o /data/log/dumpstate_app_native -m 22265

Continue reading…

cocos2d-x创建android项目后NDK编译警告被当作错误的处理方法

2013年04月24日 0, ? C, C++, Obj-C Java, JavaScript 移动平台

问题为编译cocos2d-x创建的android项目时，原生代码部分编译脚本build_native.sh触发的NDK编译警告被当作错误处理，项目实际编译生成成功了但是Eclipse不能运行！

开发环境：

Mac OSX ML 10.8.3

Android Developer Tools Build: v21.1.0-569685 (developer.android.com下载的整合ADT SDK的Eclipse)

android-ndk-r8e 64bit

cocos2d-2.1rc0-x-2.1.2-hotfix

Continue reading…

iOS程序开发引用的第三方库之间出现duplicate symbol时的处理方法

2012年03月20日 15, ? C, C++, Obj-C 移动平台 设计开发

iOS程序集成的第三方库过多时，很容易出现某几个库同时用到了一样的函数库，也就是在你的程序link时会提示duplicate symbol，而重复的符号又不是由你自己程序的代码造成的，也就说没法通过直接修改代码把重复的符号去掉！这样呢，要不就要求第三方库提供方该代码，要不就自己修改第三方库的库文件。第一种方法多少有点无理要求，所以还是直接用第二种方法自己解决了吧，也就是直接修改.a文件或framework里的库二进制文件：

Continue reading…

在Eclipse CDT项目中使用llvm-clang作为编译器并解决gdb调试不显示变量的问题

2013年03月18日 0, ? C, C++, Obj-C 设计开发

用了一段时间的Xcode做Mac OSX, iOS的开发后，深深的体会到llvm clang编译器的速度、人性！于是打算在刚换上的Ubuntu 12.10上也装一个好好研究研究。

装好Eclipse Version: 4.2.2和CDT后，先是发现toolchain里只有gcc，意识到又得去google了，好在很容易的就找到了llvm4eclipsecdt这个Eclipse插件（看下面的项目链接或者直接到Eclipse Marketplace里搜llvm clang就能找到），果断装上之后，开了个新C++项目，随便写了几句build，失败，看了一下找不到clang执行程序，猜想应该是还没装伟大的llvm clang编译器吧，打开Ubuntu软件中心一搜，嘿！还真有，这下省事了，直接装上llvm clang还有一些可选项，再回到Eclipse Build运行，ok，一切正常！可后来发现想运行一下Debug吧，却发现虽然断点可以正常下，单步运行也没什么问题，但视图里的局部变量之类的都没有任何显示，watch也不行，根本找不到symbol… Continue reading…

Mac NSOpenGLView NSOpenGLProfileVersion3_2Core glGetString取GL_EXTENSIONS时返回null

2012年12月10日 0, ? C, C++, Obj-C 设计开发

实验NSOpenGLView和NSOpenGLProfileVersion3_2Core时发现通过glGetString取GL_EXTENSIONS时一直返回null，不管是放在prepareOpenGL里还是awakeFromNib里，甚至是drawRect:里都不行。尝试调整NSOpenGLView的layer host或layer backed模式结果也都一样。后来查文档发现说3.0+的profile对glGetString传GL_EXTENSIONS已经被deprecated，属于invalid enumeration，正确的方法是用glGetStringi代替：

GLint n, i;
glGetIntegerv(GL_NUM_EXTENSIONS, &n);
for (i = 0; i < n; i++) {
printf("%s\n", glGetStringi(GL_EXTENSIONS, i);
}

另外NVidia Cg的cgGLGetLatestProfile也一直返回Unknown，怀疑和这个性质类似……

UPDATE1:换回NSOpenGLProfileVersionLegacy后，cg问题解决，看来现在的cg sdk还不支持3.0+的profile。

iOS的UDID废用以及UUID配合keychain的替换方案实现

2012年06月26日 30, ? C, C++, Obj-C 移动平台

首先，简单介绍一下UDID这个东西：

UDID是Unique Device Identifier的简称，也就是唯一设备标识的意思。于iOS SDK中取得的方法是UIDevice的一个叫uniqueIdentifier的NSString*，由于这个ID字符串是基于设备的，应用开发人员可以通过获取此ID来用于记录区分设备。正是由于这个特性，可能会导致一些隐私等等相关的问题，Apple于iOS5中将这个UDID废掉了，SDK中被标记为了Deprecated，虽然为了兼容低版本的源代码而继续存在，但并不会再返回任何有实际意义的东西。

最近在做Flurry的统计功能时，发现还是需要用到可以识别设备的东西的，好方便分析数据，经过一段时间的研究、试验，发现了这个应该还算是比较靠谱的方法……

Continue reading…

在Mac OSX下编译用于iOS的FreeType静态库

2012年05月16日 3, ? C, C++, Obj-C 移动平台

记得上学的时候自己研究DirectDraw的文字绘制时，曾经用过FreeType开源库做过一些简单的TTF字库文字绘制操作，那时没什么强力CPU、GPU，而且又是用的DirectDraw，Alpha混合这种操作都是CPU计算，量稍微大一些的时候FPS是相当的不尽人意，就算做了MMX、SSE等的SIMD优化，感觉也不是很理想，而FreeType画文字没有半透明的抗锯齿的话效果也不是很好，所以当时就留下个印象：FreeType的确是非常强力的文字绘图解决方案。现在在像iOS、Android等移动设备的硬件都已经相当强大了（相对而言），所以我又忍不住想要继续一下当年的小研究了！

首先，先做好准备工作。因为是在Mac下编译，所以Xcode是必不可少的，这里需要注意一点，最近的某个版本（好像是4.3）开始Xcode被变成了独立app的形式发布，而这个默认是不带command line tools，而我们要做的FreeType编译是需要用到make等命令行工具的，所以进入Preferences->Downloads里把它下载下来吧，相对1.6G的Xcode来说，180M的命令行工具应该没什么痛苦。

Continue reading…