终端开发

使用Android Studio开发可独立运行(runnable)混淆过的Jar程序 Android安装包精简系列之资源精简 Android安装包精简系列之图片优化 Android安装包精简系列之为什么要优化精简安装包 Android安装包精简系列(总纲) Android安装包精简系列之图标转字体 gradle相关资料汇总 Android编译常见错误解决 Android编译编译速度提升 终端基于gradle的开源项目运行环境配置指引 制作终端产品演示的gif 一个关于APK Signature Scheme v2签名的神奇bug定位经历 如何随apk一起打包并使用SQLite SDK热更之gradle插件(如何在SDK代码中自动插桩及如何生成补丁包) 关于Android的APK Signature Scheme v2签名相关的资料汇总 封装HttpURLConnection实现的简单的网络请求库 一款基于Java环境的读取应用包名、签名、是否V2签名等基本信息的工具 Android的APK Signature Scheme v2签名及一款基于Java环境的校验工具介绍 如何使用Eclipse开发可执行Jar程序,并生成混淆过的jar程序 Android 相关的学习资料整理(持续更新) macOS(Sierra 10.12)上Android源码(AOSP)的下载、编译与导入到Android Studio Google也看不下去被玩坏的悬浮窗了么? Android开发常用工具资源 SDK热更系列之概述(持续整理编辑中~) SDK热更系列之SDKHotfix待优化点 Android 终端开发相关的一些神图(持续更新) SDK热更系列之Demo项目介绍概述 SDK热更系列之Demo体验方法 SDK热更系列之如何获取应用在当前设备上的so对应的指令集 Gradle Android插件使用的中那些特别注意的点 Experimental Plugin User Guide(From Android Tools Project Site) 基于Android Studio使用gradle构建包含jni以及so的构建实例 基于Instrumentation框架的自动化测试 - Android自动化测试系列(四) Instrumentation框架介绍-Android自动化测试系列(三) 关于终端设备的设备唯一性的那些事之MAC地址 关于终端设备的设备唯一性的那些事之IMEI Android 检查应用是否有root权限 ant常见错误解决方案 Gradle介绍 iMac上Android Studio 相关设置及常见问题 再说adb 再看Android官方文档之分享 再看Android官方文档之Fragment&数据保存 再看Android官方文档之Activity&Intent 再看Android官方文档之ActionBar和兼容性 adb shell input(Android模拟输入)简单总结 再看Android官方文档之建立第一个APP Android开发调试常用工具 ANR(网络资料整理) Java参数引用传递引发的惨案(又一次Java的String的“非对象”特性的踩坑经历) android.view.WindowManager$BadTokenException,Unable to add window Android签名校验机制(数字证书) Robotium二三事-Android自动化测试系列(二) Robotium介绍-Android自动化测试系列(一) Android开发中遇到的那些坑 Eclipse使用中部分经验总结 Android中关于Nativa编译(NDK、JNI)的一些问题 Android简单实现的多线程下载模块 Android内存耗用之VSS/RSS/PSS/USS adb Advanced Command URL编码中的空格(编码以后变为+) Android MD5后 bye数组转化为Hex字符串的坑(记一次为女神排忧解难的经历) Android学习之路 adb Base Command Android Log的那些坑…………

标签

android 46

Android编译常见错误解决 一个关于APK Signature Scheme v2签名的神奇bug定位经历 关于Android的APK Signature Scheme v2签名相关的资料汇总 封装HttpURLConnection实现的简单的网络请求库 一款基于Java环境的读取应用包名、签名、是否V2签名等基本信息的工具 Android的APK Signature Scheme v2签名及一款基于Java环境的校验工具介绍 如何使用Eclipse开发可执行Jar程序,并生成混淆过的jar程序 Android 相关的学习资料整理(持续更新) macOS(Sierra 10.12)上Android源码(AOSP)的下载、编译与导入到Android Studio Android开发常用命令备忘 Google也看不下去被玩坏的悬浮窗了么? Android开发常用工具资源 Android 终端开发相关的一些神图(持续更新) Gradle Android插件使用的中那些特别注意的点 Experimental Plugin User Guide(From Android Tools Project Site) iMac(OS X)搭建私有maven仓库,提供Nexus Responsitory镜像 基于Android Studio使用gradle构建包含jni以及so的构建实例 基于Instrumentation框架的自动化测试 - Android自动化测试系列(四) Instrumentation框架介绍-Android自动化测试系列(三) 关于终端设备的设备唯一性的那些事之MAC地址 关于终端设备的设备唯一性的那些事之IMEI Android 检查应用是否有root权限 iMac(OS X)El Capitan 更新遇到的那些坑 ant常见错误解决方案 Gradle介绍 iMac上Android Studio 相关设置及常见问题 再说adb 再看Android官方文档之分享 再看Android官方文档之Fragment&数据保存 再看Android官方文档之Activity&Intent 再看Android官方文档之ActionBar和兼容性 adb shell input(Android模拟输入)简单总结 再看Android官方文档之建立第一个APP Android开发调试常用工具 ANR(网络资料整理) Java参数引用传递引发的惨案(又一次Java的String的“非对象”特性的踩坑经历) android.view.WindowManager$BadTokenException,Unable to add window Android签名校验机制(数字证书) Eclipse使用中部分经验总结 Android内存耗用之VSS/RSS/PSS/USS adb Advanced Command URL编码中的空格(编码以后变为+) Android MD5后 bye数组转化为Hex字符串的坑(记一次为女神排忧解难的经历) Android学习之路 adb Base Command Android Log的那些坑…………

SDK设计心得之错误码

2015年03月24日

错误码,是仅次于接口的游戏与SDK交流的工具。好的错误码就像接口设计一样可以大大降低接入成本,甚至不需要错误描述,仅仅通过错误码一眼就能大概确定问题原因。但是现实常常并不是这样的。这里主要是对开发中与错误码相关的一些细节的分析和探讨,包括错误码有几级,默认的错误返回怎么初始化一级对于第三方平台的错误码如何处理等。

错误码怎么定义

目前我们的接口的调用结果只有一级。因此有时候调用完一个接口以后,游戏处理的内容就会很多。有些游戏很勤快,他愿意处理各种细分的错误和异常,但是有些游戏比较懒,他其实不想去处理的,于是经常遇到有游戏有些逻辑没有处理而出现问题或者异常。

由于意识到这个问题的时候,SDK的使用量已经不小了。因此我们没法直接改为两级,这样总有一些游戏会有问题。我们目前的做法就是收归flag,把之前暴露给游戏的flag能合并的尽量合并,减少游戏的flag的数量。

推荐做法: 对外暴露的接口调用结果错误码分为两级:一级为flag,表示接口调用的结果:成功、失败、异常。一级为errorCode,表示错误原因。具体代码如下,关于一些flag的处理,我也加在代码注释里了

public abstract class CallbackRet {

	//接口调用成功,这种是获得了预期的值,走正常逻辑
	public final static int SUCC = 0;
	//接口调用失败,这种其实也是获得了预期的值,走正常的失败逻辑,如果游戏要细分因为什么失败,根据errorCode即可
	public final static int FAIL = -1;
	//接口调用异常,这种都是意外情况,一般是处理一些可以重试的逻辑。不过内部要保证重拾不要死循环
	public final static int EXCEPTION = -2;
public int flag = FAIL; public int errorCode = ErrorCode.FAIL;
	public String desc = "";
	public int platform = 0;
}


public class errorCode {
	public final static int SUCC = 0;
	public final static int FAIL = 0;
	……
}

关于错误码的默认值

我们之前回调的flag默认为成功(我也不知道当时设计的人为啥这么写,估计是手误,我就不说他脑抽了,哈哈),这就出现了一个问题,有人再失败的时候忘了设置flag,导致接口调用失败了,收到了成功的flag,然后游戏的处理逻辑就噶屁了。

因此建议:所有回调结构体或者错误码或者变量值的初始化一定是按照失败或者错误值去初始化,这样才能保证正常逻辑也错误逻辑都不会出错。

关于错误码的分段

我们这部分做的其实不是很好,虽然错误码总体没有大的问题,但是还没有做到一看错误码就知道大概什么问题,还是要对照错误码表去看。真真好的错误码,一看数字就能知道大概是什么地方的什么模块出了问题。真真做到快速方便的定位问题。这里就直接说下个人的想法。

推荐做法:

  • 错误码用五位数表示,第一位区分前后台或者内外部等、第二三位用于区分模块名称、第四五位用于区分具体的错误。之前曾经任性过,用二三位区分接口,结果发现一个模块内的很多接口,有很多的重复,造成了错误码资源的浪费和维护成本的增高
  • 每个系统都会有一些通用的错误码,因此建议把错误码最前面预留一部分出来放一些出现频率很高的通用错误码

如何处理第三方的错误码

这个问题是最头疼的问题了。例如我们接入的某个周边平台,平台没有规划号自己的错误吗,导致我们比较被动。有些错误码出现在好几个接口,但是意思竟然是完全不同的,这真(绝)是(逼)高(坑)大(死)上(人)。

目前我们的做法是直接把平台的错误码透传给游戏,这样虽然省事了,但是带来最直接的后果就是我们的错误码乱了。目前说实话还没有想到比较好的办法,这里就把想到的两种方案都列举一下吧。

推荐方案:

  • 对于调用外部平台或者第三方接口返回的错误码,做一次封装,对外提供我们的错误码,但是把平台的错误码放在callBack的错误描述中。用于核对和确认。这样就需要我们自行维护平台错误码和自己的错误码的对应关系,这是一个体力活,会很头疼,尤其如果平台有调整的时候。
  • 对于第三方平台的错误码,专门开一个错误码段,例如正数为我们的错误码,负数为平台的错误码。但是如果像我们接入多个平台,有的平台错误码是正数,有的是负数就噶屁了。这样的好处是不用维护平台的错误码和我们的错误码的对应关系。不过这种方法和直接透传平台的错误码没太大区别,而且直接透传反而更简单明了。


PS:我的博客即将搬运同步至腾讯云+社区,邀请大家一同入驻:https://cloud.tencent.com/developer/support-plan?invite_code=10zhijuy24v4f

赞赏

取消
微信扫一扫,赞赏子勰
扫码支持
屌丝程序猿,鸡血攻城狮!努力学技术,潜心做精品!