项目开发笔记(十五)

我以为我早已经摸透各种编码,各种开发语言转码早就可以写得666,但是这次填坑真的把人虐得欲罢不能.这次的事情有比较苛刻的前提条件,所以不一定适用于通过搜索找到此文章的各位遇到的类似情况.

先说说项目基本情况:

Client: Unity 5.3.4 (C#开发逻辑,Java OC原生开发支持,iOS下iL2CPP编译模式)
Server: 纯C++开发的服务器,PHP辅助

0x01. 引发的GBK编码问题

这个项目的网络数据的全部中文都是走GBK格式,数据到了客户端在iOS下所有中文均显示乱码.在 PC和Android下正常

关于编码问题有一篇经典文章 – 字符编码笔记:ASCII,Unicode和UTF-8

这个项目是一个超过十年的老项目(我主要负责移动客户端的实现),服务端使用纯c++开发,服务端底层架构和所有模块已经正常运行十年以上.导致遇到很多问题只能是客户端去适应服务端.所以不可能让协调服务端直接修改数据格式.

0x02. 使用I18N.CJK.DLL库

一个被提及最多的GBK格式数据在iOS iL2CPP模式下的转换方案是: 在link.xml中添加配置防止I18N.CJK.DLL被裁剪.配置方式为:

需从Unity安装目录 Editor\Data\Mono\lib\mono\unity 或 Editor\Data\Mono\lib\mono\2.0 两个目录中,拷贝I18N.DLL 和I18N.CJK.DLL到项目目录Asset文件夹下,在Assets根目录下添加link.xml文件,其内容如下:

但是我反复测试,这种方式在我当前的环境下(Unity 5.3.4,iOS,iL2CPP,Mac Pro,iPhone7P)一直是失败的.

继续阅读

这是一篇把Unity做的应用提审到AppStore的踏坑指南,记录这个过程中遇到的几乎所有问题。

!!注意!! 这篇文章可能具有一定时效性,由于苹果审核策略一直在更改,所以文章中所述言论仅仅基于当前的审核制度。

首先…Show一下苹果对我提交的应用的拒绝记录(我的内心此刻布满黑人问号)

从上图的时间看,苹果的审核速度大大加快,与2013年的审核速度简直云泥之别.然而反观国内的某些平台审核..越来越慢(客观非黑)

继续阅读

项目开发笔记(十)

最近真是繁忙,公司项目 业余项目都同步推进中

公司的项目最近略有松散,但是感觉自己也应该做到了称职。按照公司目前的项目开发模式,可以预见未来很长一段时间都会处在一种 改 改 改 改 的节奏中。在这种节奏下 很容易把代码写烂,在很多次产品改需求 催进度的时候 我都时刻暗示自己 不要因为时间紧迫,而生产垃圾代码,不要因为功能变动,而产生过多硬编码,从这种角度来看 可能这种开发模式可以磨练人呢。

业余项目最近也处在最关键的一个阶段,业余项目的一个好处就是 我可以把任意一个地方模块 写成我自己想要的样子,我不用担心任何人破坏我原本的代码思路,我可以无限次重构 直到自己觉得优雅为止。可喜可贺的是,业余的项目终于可以产生收益了 Orz,之前的独立游戏 也有国外渠道愿意推广(太有眼光了),虽然对独立游戏的收益不抱希望。不管这些事情结果如何 都感谢大家的赏识。

好了,我们接下来扯今天要分享的技术内容。针对Unity使用c#脚本编写逻辑的项目,逻辑代码的保护也就是DLL文件的防反编译(Anti-Decompile) 目前市面上还没有一套完整的方案。

一般的防破解思路

在软件保护中 一般分为 客户端软件的保护 和 web软件的保护。客户端软件一般的防破解思路基本都一致,无论是win/OSX/Linux/Android/iOS 还是其他单片机上的软件程序。防破解的做法都是从 静态保护动态保护 两个方面着手。有可能很多其他地方管着两种方式的命名不一样。通俗的叫法应该是 防止静态反编译 防止动态反编译。

静态反编译(Static decompile)

所谓的静态反编译,就是在不调试的情况下根据软件的本体去查看实现逻辑或者原理(Q.普通没代码的软件也可以调试? A.一般无论是什么系统 Win Linux Android OSX iOS,其核心库 – Kernel层中都会带有调试功能的API,即使是在发行版本的操作系统中 这些调试接口也会被保留,而这些调试接口可以调试任意User层的软件,而我们开发的大多都是属于User层的软件。)

举几个例子:

使用Dex2jar工具对安卓安装文件APK进行导出jar,就属于一种针对安卓软件的静态反编译技术,
使用IDA OD等工具对 .exe .dll进行反编译 也算是一种针对win平台软件的静态反编译的行为。
使用JDgui工具对jar进行查看代码,也算是针对Java软件的一种静态反编译行为

继续阅读

个人游戏杂谈(一)

今天,我的第二款游戏装机用户已经突破1000,这里统计的是启动并玩过的用户,只下载不启动的不算,在没有任何推广策略。没有任何商业运营手段的情况下,我觉得已经非常惊喜了。特别是锤子,从锤子商店过来的用户让我大大吃了一惊,看来我要把几年来黑过老罗的话收回去了。以后尽量不黑他了Orz。

以下是我后台收集的自然用户来源比率:

这张图让我大吃一惊,从平台用户基数(平台的总用户量)来讲。锤子商店是图中最少的。从锤子科技发布的锤子手机销售情况判断,注意 市面上并没有锤子商店这个APP 也就是说只有用锤子系统的用户才能够进入锤子商店APP,才能从锤子渠道下载到我的游戏,作为一个用户基数最少的平台 竟然是游戏里用户最大的来源渠道,真猜不透这是为何。按照一般的来说,在不买量不推广的情况下,上图的比率应该是各自平台用户基数比率才对。

继续阅读

之前


在九月份的时候我对自己参与的项目做了一次粗浅的总结:传送门,到了四个月后的现在,这个项目我能参与的部分应该只剩接渠道的时候写ANE(前后端)和更新版本的时候负责出所有渠道的版本,关于我的第一个项目的所有模块几乎都已经转给其他同事了,而项目新版本的开发我也完全没有参与了,在这项目最后的这几个月也让我对AIR这个跨平台"引擎"又有了新的认识.在前一个月多的时间里我把AIR仔细分析了一遍,对于跨平台的认知感觉和之前又有了区别,我们总是抱怨在现有的环境下学不到东西,很多道友在抱怨每天写同样的if-elseif-else逻辑枯燥无比,其实很多时候你换几个视角看东西会让你获益匪浅.

 

之一


对于我参与的这个AIR项目,我虽然并没有在项目中参与运营,但是这个项目从无到有,再到上平台,到第一个玩家付费,到第一个单笔10K的大R出现,每一个让团队激动的时刻 我都算见证了,这个项目从无到上线总共经历了207天的时间(6~7个月左右,以前可能只听到网上分析或者预估的时间,但是这个时间是我从写的第一句代码到上平台开服的那一天的准确时间.)

继续阅读

最近在有平台合作伙伴告诉我全国SDK“百度最差,联想第二”。

听到这句话让我很感慨,因为我接过联想的SDK,而且知道联想的SDK的外包方。

可能巨头都比较专注自己的业务而忽略一些边缘的东西。

不过我最近听说的华为和TX在开发自己的flash。不知道两年后浏览器视频流会有什么变化。

2014.01.07


 

继续阅读

网上有很多的人分享IOS越狱,官方版的程序自更新。但是我还是习惯记录一下。IOS项目的程序更新使用到了itms-services协议,我们并不需要太了解itms-services协议是什么,只需要在服务器配置一个xml 和在 AIR 项目中调用遍可以实现我们想要的功能。
针对以下XML需要改 的地方只是:

  1. 需要更新的ipa包(修改为你的IPA所在服务器路径)
  2. 程序图标 (修改为你项目本身图标)
  3. 程序包名(修改为你项目的包名ID,其实就是-app.xml中的id)
  4. 程序名字(修改为你的程序名字 其实就是-app.xml中的fileName)

首先是需要在服务器配置一个xml:

继续阅读

最近研究Flascc顺道应用到AIR for IOS项目中,发现Flascc编译的优化等级与打包IPA有着非常大的关系

首先是一个老外先发现的:传送门

AIR 打包IPA

先说说AIR for IOS打包,打包限制发行版和发行版 官方文档说需要多一点时间,其实那里止需要多一点时间啊,除了时间需要多一点以外(4G内存版MAC 需要15分钟以上),还需要配置64位的机子 4G以上内存,32位的别想打包IPA顺畅了(注意 是顺畅 不是不能),翻看JAVA虚拟机LVM官方解释是 32位的虚拟机限制到1.5G的内存,而64位的JDK则不限制内存,而AIR 打包IPA的时候虚拟机内存一路飙升,我一开始使用32位+4G内存打包的时候  打开内存查看器看到java.exe所占内存一路高歌 直到爆掉。不禁让人唏嘘,请问adobe打包个ipa要那么多内存干什么?

继续阅读

对于AIR项目的签名类型 无论是android 还是IOS。似乎大家都只知道是.p12 也就是PKCS12类型,很多人都苦恼怎么签名和原生开发的不一样(主要是针对android)。一般android原生开发是使用JKS也就是 .keystore文件来签名。我一直以来想研究出用.p12签名文件转换成.keystor文件的方法。但是很抱歉。从.p12文件转到.keystore会缺少密匙链。当然反方向转换没什么问题。

在AIR手机游戏联合运营的今天。充斥着各种平台的签名 繁杂而讨厌。很多时候如果APK或者IPA需要自己做后台服务器更新的话 还需要去找运营商签名。严重影响更新进度。当然让运营商提供.keystore文件也可以。但是很多人只知道AIR打包只能用.p12文件签名。而使用.keystore文件似乎只有走 打包好APK再重新签的方式。其实不然。p12文件的签名方式 只是FB上限制的。在adt中已经提供了所有签名方式:

-storetype keystore 的类型,由 keystore 实现确定。大多数 Java 安装随附的默认 keystore 实现支持 JKS 和 PKCS12 类型。
Java 5.0 包含对 PKCS11 类型和 Keychain 类型的支持,前者用于访问硬件标记中的 keystore,后者用于访问 Mac OS X
keychain。Java 6.0 包含对 MSCAPI 类型的支持(在 Windows 中)。如果安装和配置了其他 JCA 提供程序,则可能还可以
使用其他 keystore 类型。如果未指定任何 keystore 类型,则使用默认 JCA 提供程序的默认类型。

在ios中程序间互相调用可以通过url来解决。在oc里面直接在函数handleOpenURL 便可,但是在ane中就没那么简单了。下面详细介绍下air项目中url的设置和使用,使用支付宝快捷支付ane作为例子。网上有稀稀疏疏的几篇文章偶尔提及,但是并没有完全给出一个DEMO来.

在此之前请详细阅读官方文档:传送门

关于打开URL的ANE例子:传送门

IOS里OC的处理方式:传送门

在AIR中配置URL供其他程序调用


1.首先需要在-app.xml中加入如下配置:([IPHONE]标签中)

<iPhone>
        <InfoAdditions><![CDATA[
			<key>UIDeviceFamily</key>
			<array>
				<string>1</string>
				<string>2</string>
			</array>
			<key>CFBundleURLTypes</key> 
			<array> 
	    	<dict> 
	        	 <key>CFBundleURLSchemes</key> 
    	    	<array> 
        		    <string>AlipayANE</string> 
    	    	</array> 
    	    	<key>CFBundleURLName</key> 
    	    	<string>com.rect.app</string> 
    		</dict> 
		</array>
		]]></InfoAdditions>
        <requestedDisplayResolution>high</requestedDisplayResolution>
    </iPhone>

在这类配置了一个Name为”com.rect.app”的Schemes.调用方式为”AlipayANE://”;

继续阅读