欢迎留言、转载请注明出处
随着项目规模的增大，源代码文件增多，结构越来越复杂，导致项目编译链接速度变慢是一件让人非常头痛的事！
在Windows上我们用Visual Studio可以使用IncrediBuild (http://www.incredibuild.com/) 这个非常好用的分布式编译工具，配合其自带的VS Add-In可以很方便的将大型项目的编译工作负担分布到网络上的其它机器完成，极大的缩短了项目编译时间，提高工作效率！
不过遗憾的是IncrediBuild目前只支持Windows系统和VS等一些编译环境，对于Android, iOS等交叉编译的移动平台开发环境就无能为力了。
其实对于linux系OS上还是有可用的分布式编译解决方案的，就是接下来我要说的这个distcc，项目介绍请猛击这里：https://code.google.com/p/distcc/
以前在做Symbian的时候，曾经研究过ARM CPU的指令集问题，ARM处理器支持两套指令集，即ARM和Thumb。ARM为32位指令集而Thumb为16位指令集，理论上32位可以提供更快的执行速度但会生成更大的二进制执行文件，而16位的Thumb则恰恰相反，省地儿但慢，这也正是体现出了ARM对于嵌入式设备的专业性。对于我这种牺牲一切换速度的理念来说，当时就留下了ARM就比Thumb快的印象，以致于现在在做Android NDK原生开发时，也是优先用ARM指令集。（这个可以通过在Android.mk中加入LOCAL_ARM_MODE := arm控制，默认情况下NDK使用Thumb指令集）
但是最近在Xcode编译iOS项目时，注意到同为ARM处理器的苹果设备，使用的是Thumb指令集，而且好像还是某种新版本的Thumb指令集，小搜索了一下看到有人说这种armv7引入的叫做Thumb-2的指令集要比arm指令集更好！于是又重新搜索更新了一下大脑知识库…
是一个可以在U3D生成iOS所需Xcode项目时自动完成一些如添加framework，修改编译参数等操作的Editor插件。这个插件对于同一个项目需要接入各种不同渠道的SDK生成对应IPA的需求可以很方便快捷的实现自动化操作，降低项目维护复杂度。
在使用这个插件时，发现了些小问题，查看作者声明时发现其已经不在对这个插件进行维护了，于是只好自己动手做一些修改完善：
本文记录的就是对plist的处理功能，原代码逻辑中XCProject.cs中的ApplyMod函数会根据.projmods的信息对Xcode项目文件进行一系列的修改，其中一部是对项目.plist的修改，但这一步用我当时取到的github最新版本时会出错，仔细检查了下，发现无论projmods中的plist段写不写，生成对应的XCMod对象的plist总会是null，检查了下这个json数据解析生成类，发现plist的类型是“Hashtable”，而不像其他一些字段，如group是string，libs是ArrayList等，改换了下projmods中的json写法，又发现虽然可以解析成功不为null了，但实际修改plist逻辑又出现了问题，原逻辑是通过XCPlist的Process函数对projmods中提供的信息项对原项目plist进行合并修改，但是代码中对各种plist选项的处理不并完善，只有一个特殊if：
public void AddPlistItems(string key, object value, Dictionary<string, object> dict)
{
Debug.Log ("AddPlistItems: key=" + key);
if (key.CompareTo(PlistUrlType) == 0)
{
processUrlTypes((ArrayList)value, dict);
}
else
{
dict[key] = HashtableToDictionary<string, object>((Hashtable)value);
plistModified = true;
}
}
会对URLSchemes做处理，显然这样无法实现通用的plist修改逻辑，思考过后我决定将其实现改为读取指定plist文件中的key项并与项目plist进行合并，覆盖已有的项，添加没有的项，具体实现如下：
Continue reading…
问题大致就如标题描述的那样，应用图标修改后重新打包安装到设备上时并没有变化，当然，前提是已经排除了人为因素导致的res内图标文件替错等原因。许久以前，在Android的原始时期，1.6、2.2时代时，就曾经在HTC的Sense UI上遇到过类似问题，当时也没太在意，现在在OnePlus One上(CM12s系统)又遇到了同样的问题，决定彻查一下原因。
百度下发现MIUI等也有类似的问题，基本确定是Launcher对应用图标建立了缓存，最直接的破除缓存的方法就是修改应用的Package Name，换包名后重装图标就会显示正确，明显就是没有缓存的特征！然而，应用发布过后一般是不会更换包名的，所以这个方法实际应用意义不大，仅仅是确认了这个图标缓存的机制。
这之后又查到了一些解决方法，如删除 /data/system/customized_icons 路径下的响应图标（这个需要root，且在5.0上没有这个路径，估计是Pre Lollipop用的），再如杀掉Launcher的进程，强制其重启刷新缓存（这个貌似不科学，因为重启Launcher的话应该和重启系统性质是一样的，但是我试过重启机器后图标依然没有刷新，再有就是CM上也没找到明显的Launcher进程，只有个systemui看起来比较像，不过也不敢强制结束，怕玩坏啊，哈哈！），这之后又自己尝试了下别的可能作为缓存key的要素，如改VersionCode，改VersionName，同时改VersionCode和VersionName，改res下的图标文件名等，均无效！
Continue reading…
很久以前曾经被wchar的问题在iOS和Android上被坑过，这次是在参研一份有年头的代码时又遇到了宽字符的问题，当然，也是和wchar有关系的，就是这个wchar在各个系统平台下的sizeof问题，关键的是一段UTF-8转UTF-16的代码：
size_t Utf8ToUtf16(const char* src_, wchar_t* dest_, size_t destlen_, size_t srclen_ /*= 0*/)
{
if (srclen_ == 0)
srclen_ = _utf_length(src_);
size_t destcapacity = destlen_;
for (size_t idx = 0; ((idx < srclen_) && (destcapacity > 0));)
{
wchar_t cp;
unsigned char cu = src_[idx++];
if (cu < 0x80)
cp = (wchar_t)(cu);
else if (cu < 0xE0)
{
cp = ((cu & 0x1F) << 6);
cp |= (src_[idx++] & 0x3F);
}
else if (cu < 0xF0)
{
cp = ((cu & 0x0F) << 12);
cp |= ((src_[idx++] & 0x3F) << 6);
cp |= (src_[idx++] & 0x3F);
}
else
{
cp = L'?';
}
*dest_++ = cp;
--destcapacity;
}
return destlen_ - destcapacity;
}
这段代码在win下可以正常将utf-8的char*转换为utf-16的char*，但在Android, iOS下却不能得到和win下一样的转换结果，刚发现这个问题时，以为又是当年遇到的wchar坑，宽字符函数不支持之类的，但是仔细看了下并没有用到什么字符串函数，转换部分也是自己实现的，最后在各平台调试器的帮助下找到了问题：
Continue reading…
在用Cococs2d-X的lua binding时，遇到了需要RTTI的时候，也就是运行时类型识别，这点对于lua类来说还是很容易做到的，可以参考引擎lua framework中cocos/cocos2d/functions.lua中的function iskindof(obj, classname)，不过，这个函数的递归实现函数iskindof_有些小问题，这里是修正方法：
local iskindof_
iskindof_ = function(cls, name)
local __index = rawget(cls, "__index")
if type(__index) == "table" and rawget(__index, "__cname") == name then return true end
if rawget(cls, "__cname") == name then return true end
-- By K-Res: should use __index instead of cls!
-- local __supers = rawget(cls, "__supers")
local __supers = rawget(__index, "__supers")
if not __supers then return false end
for _, super in ipairs(__supers) do
if iskindof_(super, name) then return true end
end
return false
end
然而，当遇到需要对binding到lua的native class进行RTTI就有些麻烦了，可以看到借助tolua过去的lua对象是usertable挂metatable实现的，而metatable中也没有可以用lua类（确切的说是模拟class行为的table）的RTTI方式，因为需要查找的一些__cname等meta成员并不存在，作为class标识的只有一个.isclass的bool值，看了下binding实现的原生代码，发现在不添加额外元表信息的前提下获取class名称是需要用到LUA_REGISTRYINDEX这个只能由原生代码获取到的lua全局信息注册表，于是放弃了通过lua代码实现绑定类类型识别的想法，转而使用原生函数实现了个简单的获取binding时设置的本类class名方法，暂时实现了本对象所属类识别的功能：
Continue reading…
在使用Cocos Studio制作游戏UI等元素时，一定会使用到“动画”功能：
这种“动画”反应到代码中会被作为Cocos2d-x的ActionTimeline处理，而在应用过程中免不了要进行一些时间轴上的事件监测处理，其中最常用的莫过于动画结束时的侦听。
简单看下源码可以找到很明显的回调设置函数：
/** Set ActionTimeline's frame event callback function */
void setFrameEventCallFunc(std::function<void(Frame *)> listener);
void clearFrameEventCallFunc();
/** Last frame callback will call when arriving last frame */
void setLastFrameCallFunc(std::function<void()> listener);
void clearLastFrameCallFunc();
上面的setFrameEventCallFunc是用来配合编辑器中设置的帧事件用的，可以用来实现比如UI打开到指定位置时播放特定音效等效果，下面的setLastFrameCallFunc则是刚刚提到的更为常用的动画播放结束后的回调函数！
不过，很遗憾，在不使用原生方式开发而使用lua脚本作为主要编程语言时，发现setLastFrameCallFunc的Lua Binding代码并没有实现实际功能（最新3.7版本也是）：
Continue reading…
Cocos2d-x 3.6中使用Lua脚本作为主要开发语言，基于新的mvc框架，根据查到的响应安卓真机设备的返回按键back的方法，registerScriptKeypadHandler为Node下的注册按键事件侦听方法，新的框架中对此还进行了一次封装，在LayerEx.lua中的onKeypad实现，完成后的按键侦听代码如下：
function MyView:onKeypad(event)
if event == "backClicked" then
-- back clicked!
end
end
-- ...
function MyView:onCreate()
display.newLayer()
:onTouch(handler(self, self.onTouch))
:onKeypad(handler(self, self.onKeypad))
:addTo(self)
end
在Windows模拟器上测试时可以看到键盘上的任意键按下时都会触发这个回调函数，但是参数均为nil，读了一下源码发现在CCLuaEngine.cpp中的回调原生代码实现如下：
Continue reading…
使用Cocos集成开发环境配合Cocos Code IDE 1.2.0可以很方便的创建cocos2d-x lua binding项目并支持脚本语言的智能感知及调试。同时在添加native代码支持后还可以在一定程度上方便的进行原生代码功能扩展，如植入一些第三方库，扩展lua脚本功能等。但是在使用Cocos创建项目时，发现一个非常奇怪的问题，就是如果不使用自带的PrebuiltRuntime：C:\Program Files (x86)\Cocos\cocos-simulator-bin\win32\Simulator.exe 来作为主执行程序调试（Windows平台，其他平台未测试），所有lua脚本中的print、printf等调试输出代码都不会在控制台内输出任何内容！这样就丧失了添加native代码后自定义runtime执行程序的能力。
Continue reading…
使用Android Studio创建的空项目作为Xposed Module App，对于Api Jar包的引用方式，一开始是按照傻瓜式Jar Lib的处理方式，复制XposedBridgeApi-54.jar到app/lib中，然后直接右键Add As Library，也就是在build.gradle中生成了
这样的代码，结果写完IXposedHookLoadPackage实现类，加入assets/xposed_init，修改manifest中的meta后打包安装，Xposed Installer中也顺利检测出了新安装的模块，开启后重启系统，再看Log中出现了：
java.lang.IllegalAccessError class ref in preverified class resolved to unexpected implementation
这样的异常提示，结果当然是hook的代码也没有正确执行，研究后发现原来是jar包的引入方式不对，不能以compile方式加入，而应以provided方式，具体如下：
Continue reading…