网络游戏同步法则【转】

网路的硬件也有限,而人的创造也无限,在公网平均130ms的Latency下,是不存在“完全的”的同步情况。如何通过消除/隐藏延时,将用户带入快速的交互式实时游戏中,体验完美的互动娱乐呢?

以下六点,将助你分清楚哪些我们可以努力,哪些我们不值得努力,弄明白实时游戏中同步问题关键之所在,巧妙的化解与规避游戏,最终在适合普遍用户网络环境中(200ms),实现实时快速互动游戏:

1. 基本情况:
(A) 网络性能指标一:带宽,限制了实时游戏的人数容量
(B) 网络性能指标二:延时,决定了实时游戏的最低反应时间

2. 两个基本原则:
(A) 让所有的用户屏幕上面表现出完全不同的表象是完全没有问题的。
(B) 把这些完全不同表象完全柔和在一个统一的逻辑中也是完全没有问题的。

3. 同步的十二条应对策略:
(A) 最大可能减少游戏中的数据传输
(B) 将阻塞通信放到线程池中实现
(C) 永远不要为了等待某个数据而不让游戏进行下去
(D) 利用预测和插值改进游戏的效果
(E) 当使用预测插值的时候传送的数据不仅包括坐标,还需要速度和加速度
(F) 将输入数据枷锁或者队列化(例如键盘消息队列),直到下次发送数据的时刻,传统的方法是在固定的时间(发送数据前)检测键盘,在游戏的原理上隐藏延时
(G) 使用事件调度表,将需要在所有用户客户端同时发生的事件,提前广播到所有用户
(H) 使用多次攻击来杀死一个精灵,尽量减少一次性的、确定性的、延时敏感的事件
(I) 延长子弹或者火箭在空中飞行的时间(在其飞行的同时,在所有客户端进行预测插值)
(J) 所有物体从一个地方移动到另外一个地方都需要时间,避免诸如“瞬间移动”的设计
(K) 尽量使游戏中所有精灵,飞船或者其他物体,都按照可预测的轨迹运行,比如在移动中增加惯性
(L) 充分发挥创造力,尽最大可能的合并游戏中前后相关的事件,合并游戏中存在的延时此问题,需要在技术上改进的同时也需要策划有所重视,规避一些影响较大的设计,巧妙的隐藏”延时”

4. 同步问题现状:
(A) 重视程度不够:很多人尚未意识到此问题的存在,曾有公司花半年时间打算做一款“松鼠大战”的网络版。
(B) 技术上无彻底解决方案:对于多数程序员,单机游戏技术善未成熟就匆匆步入网络时代。
(C) 研究这个技术需要条件:需要有实力的公司才能提供,无此条件,即便有能力的程序员也无法成功。

5. 目前网游的三大技术难题:
(A) 服务器的响应问题:如何使服务器在支持越来越多的人数的情况下提供最高的响应。
(B) 同步问题:如何在有限的网络响应情况下,实现快速实时类游戏,提供最完美的交互。
(C) 服务器分布式问题:如何在统一用户数据的情况下,利用分部式将各个分散的“世界”统一到一个“世界”中。
谁能真正解决好以上三个问题,配合策划在设计上的突破,将使其他人在至少两年内无法超越。

6. 相关补充:
(A) 网格技术现在还是抄作,真正用到游戏中,还有很多技术难点需要突破(比如:目前网格的单位计算时间是以秒计算).
(B) 其实与很多人想法相反的是现在3D技术早已不是主要的矛盾。而现在国内外对于以上三个问题可以说处于同一个起跑线上,完全有机会取得先机。
(C) 现在解决同步问题已经很紧迫,而同时所需要的环境也已经成熟,只要有所关注,半年之内可以得出较成熟的结论

那么具体怎么解决呢?再下一步怎么办?
这就得自己去实践了,我只说这么多了,哈哈,不然又教懒了那些成天再网上搜方案的人。

转载请注明出处:http://www.skywind.me/

帧锁定同步算法【转】

帧锁定算法解决游戏同步

早期 RTS,XBOX360 LIVE游戏常用同步策略是什么?格斗游戏多人联机如何保证流畅性和一致性?如何才能像单机游戏一样编写网游?敬请观看《帧锁定同步算法》

《帧锁定同步算法》转载请注明出处:http://www.skywind.me/blog/archives/131

算法概念

该算法普遍要求网速RTT要在100ms以内,一般人数不超过8人,在这样的情况下,可以像单机游戏一样编写网络游戏。所有客户端任意时刻逻辑都是统一的,缺点是一个人卡机,所有人等待。

1.客户端定时(比如每五帧)上传控制信息。
2.服务器收到所有控制信息后广播给所有客户。
3.客户端用服务器发来的更新消息中的控制信息进行游戏。
4.如果客户端进行到下一个关键帧(5帧后)时没有收到服务器的更新消息则等待。
5.如果客户端进行到下一个关键帧时已经接收到了服务器的更新消息,则将上面的数据用于游戏,并采集当前鼠标键盘输入发送给服务器,同时继续进行下去。
6.服务端采集到所有数据后再次发送下一个关键帧更新消息。

这个等待关键帧更新数据的过程称为“帧锁定”
应用案例:大部分RTS游戏,街霸II(xbox360),Callus模拟器。

算法流程

客户端逻辑:
1. 判断当前帧F是否关键帧K1:如果不是跳转(7)。
2. 如果是关键帧,则察看有没有K1的UPDATE数据,如果没有的话重复2等待。
3. 采集当前K1的输入作为CTRL数据与K1编号一起发送给服务器
4. 从UPDATE K1中得到下一个关键帧的号码K2以及到下一个关键帧之间的输入数据I。
5. 从这个关键帧到下 一个关键帧K2之间的虚拟输入都用I。
6. 令K1 = K2。
7. 执行该帧逻辑
8. 跳转(1)

服务端逻辑:
1. 收集所有客户端本关键帧K1的CTRL数据(Ctrl-K)等待知道收集完成所有的CTRL-K。
2. 根据所有CTRL-K,计算下一个关键帧K2的Update,计算再下一个关键帧的编号K3。
3. 将Update发送给所有客户端
4. 令K1=K2
5. 跳转(1)

服务器根据所有客户端的最大RTT,平滑计算下一个关键帧的编号,让延迟根据网络情况自动调整。

算法演示

我根据该算法将街机模拟器修改出了一个可用于多人对战的版本,早期有一个叫做kaillera的东西,可以帮助模拟器实现多人联机,但是并没有作帧锁定,只是简单将键盘消息进行收集广播而已,后来Capcom在PSP和360上都出过街霸的联网版本,但是联网效果不理想。这个算法其实局域网有细就经常使用了,只是近年来公网速度提高,很容易找到RTT<50ms的服务器,因此根据上述算法,在平均RTT=100ms(操作灵敏度1/10秒),情况下,保证自动计算关键帧适应各种网络条件后,就能够像编写单机游戏一样开发网游,而不需状态上作复杂的位置/状态同步。

20161010-87

从上图的演示中可以看到,两个模拟器进程都在运行1941这个游戏,两边客户端使用了该算法,将逻辑统一在一个整体中。

最后这张图是运行KOF99的效果图,两边完美同步。
最后这张图是运行KOF99的效果图,两边完美同步。

乐观帧锁定

针对传统严格帧锁定算法中网速慢会卡到网速快的问题,实践中线上动作游戏通常用“定时不等待”的乐观方式再每次Interval时钟发生时固定将操作广播给所有用户,不依赖具体每个玩家是否有操作更新:

1. 单个用户当前键盘上下左右攻击跳跃是否按下用一个32位整数描述,服务端描述一局游戏中最多8玩家的键盘操作为:int player_keyboards[8];

2. 服务端每秒钟20-50次向所有客户端发送更新消息(包含所有客户端的操作和递增的帧号):

update=(FrameID,player_keyboards)

3. 客户端就像播放游戏录像一样不停的播放这些包含每帧所有玩家操作的 update消息。

4. 客户端如果没有update数据了,就必须等待,直到有新的数据到来。

5. 客户端如果一下子收到很多连续的update,则快进播放。

6. 客户端只有按键按下或者放开,就会发送消息给服务端(而不是到每帧开始才采集键盘),消息只包含一个整数。服务端收到以后,改写player_keyboards

————-

虽然网速慢的玩家网络一卡,可能就被网速快的玩家给秒了(其他游戏也差不多)。但是网速慢的玩家不会卡到快的玩家,只会感觉自己操作延迟而已。另一个侧面来说,土豪的网宿一般比较快,我们要照顾。

随机数需要服务端提前将种子发给各个客户端,各个客户端算逻辑时用该种子生成随机数,另外该例子以键盘操作为例,实际可以以更高级的操作为例,比如“正走向A点”,“正在攻击”等。该方法目前也成功的被应用到了若干实时动作游戏中。

指令缓存

针对高级别的抽象指令(非前后可以覆盖的键盘操作),比如即时战略游戏中,各种高级操作指令,在“乐观帧锁定”中,客户端任何操作都是可靠消息发送到服务端,服务端缓存在对应玩家的指令队列里面,然后定时向所有人广播所有队列里面的历史操作,广播完成后清空队列,等待新的指令上传。客户端收到后按顺序执行这些指令,为了保证公平性,客户端可以先执轮询行每个用户的第一条指令,执行完以后弹出队列,再进入下一轮,直到没有任何指令。这样在即时战略游戏中,选择 250ms一个同步帧,每秒四次,已经足够了。如果做的好还可以象 AOE一样根据网速调整,比如网速快的时候,进化为每秒10帧,网速慢时退化成每秒4帧,2帧之类的。

————–

PS:可以把整段战斗过程的操作和随机数种子记录下来,不但可以当录像播放,还可以交给另外一台服务端延迟验算,还可以交给其他空闲的客户端验算,将验算结果的 hash值进行比较,如果相同则认可,如果不通则记录或者处理,服务端如果根据游戏当前进程加入一些临时事件(比如天上掉下一个宝箱),可以在广播的时候附带。

(完)

再谈网游同步技术:实时动作游戏同步方式和传输协议选择【转】

原贴:http://www.gameres.com/478430.html

再谈网游同步技术:实时动作游戏同步方式和传输协议选择 ...

GameRes游资网授权发布 文 / 韦易笑

实时动作游戏在近年来得到迅猛的发展。而游戏同步问题,成为大家继续解决的核心问题之一。早在 2004年,国内游戏开发还处于慢节奏 RPG满天飞的情况下,我就开始实时动作游戏研究。分别在 2005-2006期间写了一系列相关文章,被好多网站转载:

帧间同步模式:《帧锁定同步算法》(2007): http://www.skywind.me/blog/archives/131

玩法规避模式:《网络游戏同步法则》(2005): http://www.skywind.me/blog/archives/112

预测插值模式:《影子跟随算法》(2007): http://www.skywind.me/blog/archives/1145

如今十年过去,网上越来越多的人开始讨论游戏同步技术了,然而很多文章往往只针对某种特定的游戏情况,而观点又经常以偏概全。很多人并没有真正开发过实时动作游戏,更别说了解同步技术的前世今生了。转载别人的观点并加上自己理解的人很多,实际动过手的人很少。避免给更多人造成无谓的误导,我今天基于先前的实践和对欧美动作游戏,战网游戏,主机游戏(PSN,XBox Live等)网络技术的了解,来对这个问题做一个简单总结:

网速的变化

开发快速动作游戏,首先要对公网的网络质量数据有详细的了解。这里所说到的网速,是指 RTT,数据往返一周的毫秒时间,而非每秒传送多少 KB/s。我写这篇文章是基于我 2005-2006年开发的东西来说的,当时国内公网质量比国外差很多:

再谈网游同步技术:实时动作游戏同步方式和传输协议选择 ...

上图为 2005-2006年国内的网络环境,某三个省级 IDC的情况采样。当时公网 RTT平均值基本在100ms,120ms左右徘徊。所以我文中引用了很多 100ms。这个情况在2009 年以后已经好了很多(60ms的rtt)。到了2012年以后,公网平均 RTT已经降低到平均 40ms-50ms,省内平均10ms以内了:

再谈网游同步技术:实时动作游戏同步方式和传输协议选择 ...

上图为 2015年某省级 IDC的全国延迟情况,如若全国多布点以及区别电信联通的话,平均延迟能控制在20ms以内,延迟基本接近国外水平(当然带宽还差很多),比我当年文章中提到的网络情况好了不少。

帧间同步法

关于帧间同步的“帧锁定算法”系列的方法有很多类似实现(包括后面提到的帧间无等待改进,包括 LockStep等),但是他们的核心都是一个:保证所有客户端每帧的输入都一样。这样的方式被格斗游戏,RTS和足球(FIFA类)、篮球(NBA)等体育和动作游戏大量使用,比如我们熟悉的各大战网平台游戏(Xbox Live等),还有很多基于模拟器的街机对战平台。以及不少大型多人横版动作游戏。以开发便利,同步逻辑直观而受到大家欢迎。

帧锁定算法多用在 C/S模型中(或者一人做主多人做从的P2P里),它和 LockStep(多用于P2P)共同存在的问题就是 “网速慢的玩家会卡到网速快的玩家”,老式游戏经常一个角色断网,所有人就在那里等待。为此出现了帧锁定的改良版本 “乐观帧锁定”(具体描述见帧锁定文章的下半部分)经过了不少游戏的实践检验。先前还有几款上线的横版格斗页游(如熟知的街机三国)用 Flash 的 TCP without NODELAY 来每秒20个关键帧的模式(特意找该游戏开发者确认了一下)跑该算法(由于近两年国内网速提高,Flash的 Tcp without NODELAY也能做很多事情了),效果还不错。

具体实施时用不着按照文所述每一个步奏都相同,可以有很多变通。比如不一定是有变化的时候才通知服务端,有线上某横版格斗页游就是也可以每秒 20次向服务端直接发送数据(flash时钟不准需要自己独立计时),服务端再每秒 40次更新回所有客户端,看具体情况而定。

也有使用 UDP的端游,客户端每秒钟上传50次键盘信息到服务端,丢了就丢了,后面持续发送过来的键盘数据会覆盖前面的数据,所以丢了没关系,更快捷。当然,UDP也不是必须的,近两年网速提高很快,省内都能做到10ms的 RTT 了,跨省也就 50ms的rtt,不少页游上用该方法上裸的 TCP 照样跑的很顺畅。

而近两年国外动作游戏领域也涌现出其他一些新的改良方法,比如 Time Warp,以客户端先行+逻辑不一致时回滚的方式,带来了更好的同步效果,俗称时间回退法。不果国内暂时没看到有游戏这么尝试,更多的是国外近两年的双人动作游戏比较多,要求游戏每帧状态都可以保存,逻辑上开发会复杂一些。国内大部分是超过两人出去副本的,在3-4人出去 PK的情况下,引入状态回退,会让整个效果大打折扣。不过2人的效果确实有所改进,有兴趣的同学可以搜索 Time Warp相关的论文。

2009年,云游戏(游戏远程渲染)技术得到广泛应用,客户端上传操作,服务端远程渲染,并以低延迟视频编码流的方式传回给客户端,用的就是这样类似的技术。客户端不需要高额的硬件,也不存在盗版问题,其中 Gaikai和 OnLive两家公司做的比较好。

2012年,Sony推出 Playstation Now技术,可以在 PSV和 PS3/PS4上玩云游戏,玩家不需要购买游戏就可以免费体验一定时间。使得 PSV/PS3等低端硬件也可以流畅的跑 PS4游戏。

再谈网游同步技术:实时动作游戏同步方式和传输协议选择 ...

但是目前国外网络环境下跑的还比较流畅,国内的网络环境要低延迟传送 HD画质的视频流还比较困难,视频都是比较费带宽的。但是帧锁定等保证每帧输入一致的算法,在当今的网络质量下传递一下玩家操作,还是没有任何问题的。

状态同步法

对于逻辑不需要精确到帧的游戏类型而言(RPG/ARPG,FPS,赛车),允许每个客户端屏幕上显示的内容不同,只要将他们统一到一个逻辑中即可,这部分见:“网络游戏同步法则”(最好给策划看看这篇,从玩法上规避)。如果是 RPG游戏,其实更多是使用障眼法从玩法和动画效果上减少 “一次性的”,“决定性”的事件即可:

RPG 游戏的移动很简单,只需要“谁在哪里朝着哪里移动”,客户端再做一些简单的平滑处理即可,不需要额外的“时间”参数。比如《魔兽世界》移动时,就是差不多每秒发送一次(坐标,朝向,速度),别的客户端收到以后就会矫正一下,如果矫正错误,比如 A本来往北走突然拐弯向东,这个数据包传到B上,B屏幕上的A可能在拐弯前往北跑了更远,致使拐弯向东时被树卡住,那么B就会看到A被树卡了两秒无法移动,然后突然瞬间移动到新的坐标,继续朝着东跑。

通常 RPG攻击分为“有锁定攻击”和“无锁定攻击”,有锁定攻击意思是,我朝你发射火球,不管你怎么跑,火球都会追踪并射击到你,比如你在我面前横着跑过,我向你发射火球,可以发现火球并不是直线飞行,而是曲线追踪着你就过去了,这叫有锁定攻击。无锁定攻击一般是范围攻击,先播放个动画(比如挥刀),然后将攻击请求提交服务器,服务器结果回来时,动画刚好播放完毕,然后大家一起减血。

而 FPS和 赛车类游戏的同步性要求比 RPG高很多,每秒发包量也会多很多(10-30个),多半采用位置预测及坐标差值的“导航推测算法(DR)”,具体实现见我的:“影子跟随算法”(DR算法的一个改进实现)。

再谈网游同步技术:实时动作游戏同步方式和传输协议选择 ...

这类算法由于位置判定更为精确,所以计算量大,很多没法服务端判断,而是客户端直接判断,比如 FPS射击是否打到别人,客户端先判断,除了狙击这种一枪毙命的射击外基本都是客户端判断的。由于计算更为复杂,每秒同步发包差不多到 30个以上,这样的模式下,每局游戏的人数也不可能很多,一般16人左右。而且很多才用 P2P的方式运行,具体 FPS游戏的实现,及 DR算法的代码编写,见 “影子跟随算法”这篇文章。

其实状态同步是一种乐观的同步方法,认为大家屏幕上的东西不同没关系,只要每次操作的结果相同即可,不需要象“帧间同步”那样保证每帧都一样,因此,对网速的要求也没有 “帧间同步”系列算法那么苛刻,一般100ms-200ms都是能够接受的(DiabloIII里面300ms的延迟照样打),偶尔网络抖一下,出现1秒的延迟,也能掩盖过去。然而比起 “帧间同步”,状态同步方式对玩法有不少要求,诸如 “一次性”,“决定性”的事件要少很多,而且代码编写会复杂一些,不果由于能容忍更坏的网络情况,以及容纳更多同时游戏的人数,在一些玩法确定的游戏中(RPG,FPS,赛车),被广泛使用。

再谈网游同步技术:实时动作游戏同步方式和传输协议选择 ...

而状态同步又分为“DR同步”和“非DR同步”,前者针对 FPS,赛车或者更激烈点的 ARPG,后者针对 RPG和普通 ARPG。他们对网速的要求和错误的容忍度也是不一样,当然,带来的游戏即时感也是不同的。

总得来说,你希望游戏体验更爽快,即时感更强,那么你每秒发包数就越多,每局(副本)支持的人数越少;而你如果追求对网络的容忍,想降低发包数,并且增加同时游戏的人数,那么相应的就需要以降低即时感为代价,其二者不可得兼。然而聪明的策划和程序们总能想出很多好主意,利用障眼法和玩法规避,动作掩盖等方法,在相同的情况下来掩盖延迟,让玩家“看起来”更加“即时”和“爽快”,而这个方法具体该怎么做,并没有统一的做法,就得大家结合自己的游戏和玩法,发挥自己的聪明才智了。

 结果同步法

结果同步往往比较简单,位置即使全部错乱或者延迟很久都没有关系,因为游戏过程完全不在乎位置,只在乎最后的结果,比如《梦幻西游》这样的“回合制 RPG” 游戏,屏幕上的人走到哪里确实无所谓,所有操作都是要点击或者选择菜单来下命令,象这样的游戏背后其实是文字游戏,只是加了一个图形的壳。

游戏表面上看起来是动作/RTS 游戏,但是没有玩家直接协作和对抗,都是单机游戏,并不需要同步什么东西,服务端只要监测下结果不离谱即可,延迟检测都没关系。基本是 PVE,而且无协作。即使是 PVP也就是打一下别人的离线数据,和无同步回合制游戏并无本质上的区别。

传输协议选择

老话题 TCP还是 UDP,答案是大部分时候,TCP打开 NODELAY即可,现在网络情况好了很多,没必要引入新的复杂度。即便是“帧锁定算法”上线的多人实时格斗游戏,也有在用 TCP跑着的。帧间同步如果能够做到更好的架设机房,那么延迟基本能控制在 10ms以内,将游戏玩家按照区域分服务器,让他们选择更快的服务器。

即便是带 DR的状态同步,很多也都是 TCP的,《魔兽世界》和《暗黑破坏神3》都是基于 TCP来实现的,所以我的建议是,先上 TCP,把你的游戏发布出去。

当然,等到你的游戏发布出去了,开始挣钱了,你想改进你的游戏效果,特别是高峰期的卡顿比例(需要收集客户端统计),那么你可以使用 UDP来改进,《街霸4》和《英雄联盟》都是使用 UDP的,比如你可以使用 libenet(英雄联盟用的)。不过 libenet所采用的传输技术,是上世纪的标准 ARQ做法了,《街霸4》所采用的传输技术远远高过 libenet,如果你想采用更为现代的传输技术,赢得更低延迟的话,可以使用我的“快速传输协议-KCP”(http://www.skywind.me/blog/archives/1048),被再若干上线项目和开源项目使用的协议,效果远远 PK libenet。

在使用 KCP时,你可以用在你 TCP的基础上,再登陆时服务端返回 UDP端口和密钥,客户端通过 TCP收到以后,向服务端的 UDP端口每隔一秒重复发送包含握手信息,直到服务端返回成功或者失败。服务端通过 UDP传上来的密钥得知该客户端 sockaddr对应的 TCP连接,这样就建立 TCP连接到 UDP连接的映射关系。为了保持连接和 NAT出口映射,客户端一般需要每 60秒就发送一个 UDP心跳,服务端收到后回复客户端,再在这个 UDP连接的基础上增加调用 KCP的逻辑,实现快速可靠传输,这样一套 TCP/UDP两用的传输系统就建立了。

中国的网络情况比较特殊,会存在有些网络 UDP连接不上的情况,因此都是先连接 TCP,然后试图 UDP,UDP不通的情况下,退回 TCP也能正常游戏,一旦 TCP断开,则认为 UDP也断开了。

不果归根结底,还是先上 TCP,再根据自己游戏的特点和是否出现传输问题,选择 UDP。

话题总结

根据游戏类型,选择恰当的同步方式和传输协议是最基础的问题,很多讲述网络同步的文章一般就是只会强调上述那么多种算法的其中一种方式,好像使用该方式就可以 hold住所有游戏一样的,其实并非如此。技术需要多和策划沟通,别策划一个需求下来,技术就来一句:无法实现,这样的游戏永远没有竞争力。就像国内当时都是慢节奏 RPG,偶尔有点 ARPG的时候,大家觉得《DNF》这样的游戏无法实现,于是韩国实现了,在市场上取得了先机,国内才慢慢跟进,再一看,哇塞,好多坑呢。

然后开发者开始在网上寻找各种同步算法,东一榔头西一棒子,明明是一款需要帧间同步的格斗游戏,结果却上了导航推测,最后发现问题永远解决不了,一堆 BUG这就叫误导。正因为我 2004年就开始弄同步相关的问题,期间也指导过不少游戏设计他们的同步方案,所以这次相当于将以前的观点做一个总结和点评,根据自己的游戏类型选择最适合的同步算法,为玩家提供更好的体验才是关键。

Android Studio2.x中NDK开发支持c++11

Android NDK 最佳实践(0)

翻译自:http://ndkinfo.vleu.net   ps:英语四级没过,基本按大意翻译,尽量不在重要的地方曲解原文的含义,其他形容性的词汇可能带有自己主观理解的色彩,轻喷。如果英文好可以直接去看原文。 也希望发现翻译有问题的同学能告诉我错误所在,多谢。

欢迎

正如大家可能注意到的,native安卓开发不是一件很简单的事。才华横溢的开发者们发布了很多库(libraries),但是这些库都是按照一个整体的方式发布的:为了使用这些库,你必须fork这个开发者的代码仓库,而这个仓库本身又fork了许多其他的项目。

更糟的是:一旦上游添加了对安卓的支持,他们倾向于使用需要硬编码的相对路径,这种不稳定的方式。

这很令人沮丧,尤其是因为NDK本身包含了一种清晰和可靠的方式打包库的特性:requered bricks. 好,在我们再一次结束自动配置(autoconf)的噩梦前,我想要提出一种统一的打包库的方式,以便来简单的编译安卓平台的 FOSS 软件。

从基本上来说,这些简单的集合使用NDK中已经存在的机制来提供功能,就像是Linux系统上的那些pkg-config。

Xcode 编译静态库的陷阱(Xcode7如何生成i386的静态库)

编译静态库时一般需要编译真机和模拟器两个库。XCode7中,默认Debug只编译当前环境的库。导致只会生成x86_64的.a文件,不包含i386(注释:32位)的库。需要调整Xcode的默认设置。 需要调整的设置如图:(如果Debug那里不设成No, 模拟器的release也会套用这个设置,只生成x86_64的库)Xcode setting for static lib