首先在1703的win10下装好flash builder 4.7，然后新建个as项目，然后调试运行，发现默认的chrome 版本 61.0.3163.100（正式版本） （64 位）打开生成的html页面后根本没有加载flash控件，eclipse的调试部分也完全没有反应，又尝试了非调试运行，结果也是一样加载不了flash。于是更改设置中的浏览器为IE，再试，结果弹出的IE11倒是显示了flash控件，但提示“影片未加载”，显示一片黑！
随后修改运行配置，改为直接执行swf文件，也就是用standalone player的方式运行，结果一切正常！随即想到以前研究fb早期版本时，貌似需要将浏览起的flash插件替换为debug版本，于是17年这个新时代的各种浏览器对flash的恶意就显现出来了…
Continue reading…
设计开发
Android Studio通过CMake编译原生代码运行时符号(函数)丢失的问题
由于新版Android Studio的native调试功能实在是太好用了，所以试了下把旧版Cococs2d-x项目（大概是2.x版本吧）重建Android Studio项目。花了很长时间添加各种source，static library，prebuilt library以后，终于项目可以在Android Studio的cmake编译工具下成功编译链接并生成.so了，迫不及待的一运行，发现直接闪退，检查后发现是”Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeOnResume”这个cocos2d-x的jni函数没有找到！
初步检查了下，发现cmake编译出的cocos2d静态库.a中存在这个函数符号，但是最终生成的.so中确实是没有这个函数(使用ndk toolchain里面的nm)，于是想到应该是链接时认为这个符号没有代码调用，被stripe掉了。
后来又仔细看了下Android.mk，发现玄机貌似在于
LOCAL_WHOLE_STATIC_LIBRARIES += cocos2dx_static
对cocos2dx的静态库使用了WHOLE的链接方式，于是开始查找同样功能在cmake中的实现方式，最后查的结果如下：
Continue reading…
quick-cocos2d-x-2.2.6的CCHTTPRequest在Android 5.0+系统上的崩溃问题
虽然是比较旧版本的quick了，但也许会有人需要此版本的项目重新编译运行在新版本Android系统上，或是有遇到类似问题可以供参考，所以此篇文章记录解决这个问题的方法。
报错的现象是在使用“network.createHTTPRequest”进行http访问的时候（也就是lua调用的CCHTTPRequest类），出现native crash，大致异常信息是“use of deleted local reference XXXX”，看下logcat中的调用栈信息可以发现是在CCHTTPRequest::setRequestMethodJava调用时导致的。
关于这个问题我以前曾经写过相关的文章：
[译]Android冰淇淋三明治ICS(4.0+)JNI局部引用的变化 – http://blog.k-res.net/archives/1525.html
Android NDK中多线程JNI的local reference释放问题 – http://blog.k-res.net/archives/1794.html
基本问题就是高版本安卓系统的JNI部分有一些关于Local Reference的改动，导致曾经没问题的JNI逻辑在新版本系统上crash，先放出修改吧，修改
lib\cocos2d-x\external\extra\platform\android\CCHTTPRequestAndroid.cpp这个文件中Android平台下对于CCHTTPRequest的实现，找到getClassID_，修改为如下所示：
Continue reading…
回避由于Unity3D编辑器播放时编译脚本重加载程序集导致报错卡死等问题
Unity3D有一个叫做”live recompile”的功能，即在编辑器处于播放状态时修改脚本代码或替换托管dll等操作时，当场触发重新编译生成项目脚本assembly，并会进行重新加载操作，然而，这个功能很多时候并不能保证重加载后的代码逻辑依然能正常运行，轻则报错，重则卡死。经过博主测试发现，Unity在重加载assembly后，会清空类实例部分成员变量的值（如在Awake中new出的数组对象等），且不负责还原。最终，为了避免由于此导致的问题，采取了一种回避的手段：通过Editor脚本方式检测是否在播放状态时触发了脚本编译，是的话立即停止播放，代码如下：
Continue reading…
Unity3D游戏实现微信分享截图功能
Unity3D本身内置了一个截屏并保存为图片的功能：
public static void CaptureScreenshot(string filename, int superSize = 0);
然而，在配合微信做截屏分享的时候，发现这个简单的静态函数并不能顺利实现功能逻辑，关键原因在于这个函数的实现是异步的，也就是说，你想要的截图并不会在这个函数调用后立即生成！尤其是在移动平台上，这个函数的延迟可能更大，而且更悲剧的是：这个函数并没有让调用方知道截图生成ok了的机制，比如回调等，所以，在参考了网上的资料后，还是自己实现了一个截图保存的方法： Continue reading…
Android获取未经启动器launcher主题theme修改过的应用图标icon
今天说的这个问题是这样的，在Android App中获取自身或其它某个包名应用的图标时，取到的Drawable并不是实际资源的图标图，而是被启动器或者主题“风格化”后的版本，比如我的一加一的CM13s系统默认主题下启动器中的应用图标会被自动P成这样：
其它如MIUI等也会有类似操作，而无论你是用这样：
getPackageManager().getApplicationIcon(getApplicationInfo());
还是这样：
// Unity应用默认的图标res名叫app_icon，AS会叫ic_launcher，看下manifest中指定的资源ID串就知道了
int iconId = getResources().getIdentifier("app_icon", "drawable", getPackageName());
if (iconId>0) {
if(android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.LOLLIPOP) {
dIcon = getResources().getDrawable(iconId, getTheme());
} else {
dIcon = getResources().getDrawable(iconId);
}
}
取到的都会是修改后的图标图，那么如何取得apk中的原版图标图片呢？答案在此（感谢伟大的google及stackoverflow！）：
Continue reading…
多说难民的畅言搬家过程[附wordpress评论转换畅言json格式脚本]
本博客在很早以前就启用了多说社交评论功能，这么多年虽然不能说很完美吧，但在同类产品中多说已经算是做的相当不错的了。但从大概这周1开始，多说后台开始出现大量垃圾评论，其量之大真是这些年从来没有过的！（之前虽然也有垃圾评论，但也就极偶尔的1-2条而已，而且看了下网站访问统计，也没有大量的PV，明显是直接刷的多说评论接口），最后实在无法忍受，开启了所有评论的审核机制，即使这样，后台还是会定时出现大量的新垃圾评论。去多说官方论坛看了下，发现也没人提，官方也没反应，而且看论坛上的消息貌似是已经放弃治疗了，果不其然在前天，多说官方放出了即将关闭多说项目的通知：http://dev.duoshuo.com/threads/58d1169ae293b89a20c57241。其实之前也曾一度想从多说转移到其他的社交评论系统，但几番对比后，发现多说还是有较绝对的优势的，这回却是不得不搬家了！
Continue reading…
64位Unity集成亲加(gotye)即时通讯SDK时的editor动态库设置DllNotFoundException
最近在测试亲加的语音聊天SDK(版本：gotyeapi_ex_v3.0_20170121_u3d.zip)，由于直接提供了Unity版本的插件实现，简化了用Unity引擎开发的App集成时的难度，尤其还提供了Windows平台的实现，可在Editor环境下直接测试大部分功能，这是大部分平台相关SDK所不具备的！在实际测试中，发现了一些官方文档中没有说明的小问题，特记录于此。
首先，下载的zip并没有像官方文档中描述的一样，只有一个unitypackage，这点影响不大，直接解开zip中的内容，复制所有cs文件到项目中即可，后面根据官方文档上的指引，windows平台需要将对应32位或64位版本的Plugins中的dll复制到Unity安装路径的Editor下，也就是Unity编辑器执行文件所在的位置。这点要注意并不是常规的项目中的Plugins路径！操作完成后，项目中加入初始化代码，然后运行，出现了官方文档中提到的“win64下的U3D的DLL找不到”的问题：
DllNotFoundException: gotyeapi
gotye.GotyeAPI..ctor () (at Assets/gotye/GotyeAPI.cs:52)
(wrapper remoting-invoke-with-check) gotye.GotyeAPI:.ctor ()
gotye.GotyeAPI.GetInstance () (at Assets/gotye/GotyeAPI.cs:122)
IAsyncOperation does not contain a definition for GetAwaiter…
最近研究MS的UWP，发现虽然平台统一了，但是.net的API却变化很大，很多以前的常用的系统库函数、类都被砍掉了，比如读写文件的System.IO.FileStream，UWP下要改用StorageFile，结合异步操作async, await倒还算方便，但看完文档后一试：
StorageFile file = await ApplicationData.Current.LocalFolder.CreateFileAsync(SAVE_FILE, CreationCollisionOption.ReplaceExisting);
就报了错：
error CS4036: ‘IAsyncOperation
‘ does not contain a definition for ‘GetAwaiter’ and no extension method ‘GetAwaiter’ accepting a first argument of type ‘IAsyncOperation ‘ could be found (are you missing a using directive for ‘System’?)
虽然看提示也发现了原来是缺少”using System;”，究其原因，原来是这样：
await关键字的出现会触发编译器调用WindowsRuntimeSystemExtensions.GetAwaiter，是CreateFileAsync返回的泛型类IAsyncOperation的扩展方法（从而获得TaskAwaiter来进行await），而WindowsRuntimeSystemExtensions是存在于System命名空间下的，所以对System的using是必不可少的。
Android Studio中项目NDK原生部分整合方式
UPDATE 2016.11.14:
目前的新版Android Studio 2.2已经可以完美支持NDK原生代码整合，通过cmake以及lldb实现c/c++代码调试，并且支持代码补全等功能！
自从Android Studio出现以后，我就很少再使用Eclipse+ADT的组合做Android开发了，更快的反应速度和更人性化的操作方式以及智能感知方面等等的优势，确实体现出了Google最初宣传Android Studio时的大部分特点，不过这些种种优势目前还只是体现在Java应用开发部分，而对于需要用到C/C++的Android NDK开发时，目前还没有很好的支持，当然，参考目前Android Studio的版本迭代速度来看，这应该也只是时间问题，当初ADT刚出的时候也是问题多多，包括后来的CDT+NDK支持，最初也只是支持原生代码的编译生成so，过了很久很久的某次update才加入了原生代码的可视化调试功能（当时也是历尽万难才测试成功的，还只是很简单的混合ndk项目…）。
最近看到了ndk又更新到了r10b版本，而且又据说新版的Android Studio中已经加入了一些ndk支持，于是正好一次测试一下(Android Studio beta 0.8.14, android-ndk32-r10b-windows-x86_64)：