使用 ETC2、ASTC、PVRTC三种纹理压缩技术的区别

发表于2020年5月16日由tsai

ETC2、ASTC 和 PVRTC 三种不同的纹理压缩技术，主要用在移动设备和游戏平台上减少纹理的内存占用和提高性能。

1. ETC2（Ericsson Texture Compression 2）：
ETC2 是一种由 Ericsson 开发的纹理压缩格式，适用于大多数 Android 设备。
它支持不同的压缩质量，包括 ETC2_RGBA8、ETC2_RGB8、ETC2_RGBA1 以及 ETC2_RGB8A1 等。
ETC2 压缩质量较高，可以提供相对较好的画质。

2. ASTC（Adaptive Scalable Texture Compression）：
ASTC 是一种由 ARM 开发的高级纹理压缩格式，支持广泛的质量和压缩率。
ASTC 适用于支持 OpenGL ES 3.0 及更高版本的设备，以及支持 Metal API 的 iOS 设备。
ASTC 提供了更高的灵活性，可以在不同纹理上获得更好的压缩比例和画质。

3. PVRTC（PowerVR Texture Compression）：
PVRTC 是由 Imagination Technologies 开发的纹理压缩格式，主要用于设备采用 PowerVR GPU 的 iOS 设备。
PVRTC 分为 PVRTC1 和 PVRTC2，PVRTC2 在画质和压缩率上都有提升。
PVRTC 对于图像的细节较少的情况下，可以实现较好的压缩效果。但在某些情况下可能会出现一些失真。

区别总结：
ETC2 适用于大多数 Android 设备，提供较高的画质和压缩率。
ASTC 支持广泛的质量和压缩率，适用于 OpenGL ES 3.0 及更高版本的设备，以及支持 Metal API 的 iOS 设备。
PVRTC 主要用于 PowerVR GPU 的 iOS 设备，可以在细节较少的情况下获得较好的压缩效果。

在选择纹理压缩技术时，需要考虑目标平台的支持和性能要求，以及画质需求。

Unity中的C#委托与事件

发表于2020年4月21日由tsai

在Unity开发中，C#的委托（Delegate）和事件（Event）就像一对双胞胎兄弟，曾困惑于它们的本质区别。本文将通过实战案例揭开这对”孪生兄弟”的神秘面纱，了解它们的正确使用姿势。

一、委托：灵活的函数指针

1.1 委托的本质

委托本质上是一个类型安全的函数指针容器，可以存储多个方法引用。我们可以通过+=运算符实现多播委托：

public delegate void HealthHandler(float health);

public class Player {
    public HealthHandler OnHealthChanged;

    public void TakeDamage(float damage) {
        currentHealth -= damage;
        OnHealthChanged?.Invoke(currentHealth);
    }
}

1.2 委托的妙用场景

实现回调系统（如成就解锁）
跨脚本通信（非MonoBehaviour类间通信）
异步操作处理（如资源加载完成回调）

二、事件：安全的委托封装器

2.1 事件的核心特征

事件在委托基础上添加了访问控制层，使用event关键字声明：

public class Achievements {
    public event Action OnAchievementUnlocked;

    private void Unlock(string achievementName) {
        OnAchievementUnlocked?.Invoke(achievementName);
    }
}

2.2 事件的安全机制

封装性：外部类只能订阅/取消订阅（+=/-=）
访问控制：仅声明类可触发事件
线程安全：编译器自动生成线程同步代码

三、关键差异对比表

特性	委托	事件
访问权限	公共可调用	仅声明类可触发
赋值操作	支持=赋值	仅支持+=/-=
多播能力	原生支持	通过委托机制支持
空引用检查	需手动检查	自动生成空检查代码
设计目的	通用回调机制	观察者模式实现
典型应用场景	函数参数、回调列表	UI交互、游戏事件通知

四、Unity实战案例解析

4.1 委托实现技能冷却系统

public class SkillSystem {
    public delegate void CooldownCallback(int skillID);
    public CooldownCallback OnCooldownStart;

    public void CastSkill(int skillID) {
        // 释放技能逻辑
        OnCooldownStart?.Invoke(skillID);
    }
}

// 使用端
skillSystem.OnCooldownStart += id => Debug.Log($"技能{id}开始冷却");

4.2 事件实现成就系统

public class AchievementSystem {
    public event Action<string> OnAchievementCompleted;

    public void CompleteAchievement(string name) {
        OnAchievementCompleted?.Invoke(name);
    }
}

// 订阅端
achievementSystem.OnAchievementCompleted += name => {
    PlayEffect(name);
    UpdateUI(name);
};

五、设计选择指南

✅ 使用委托当：

需要函数作为参数传递时
实现回调函数列表时
需要直接控制调用时

✅ 使用事件当：

构建发布-订阅系统时
需要保护触发权限时
处理UI交互事件时
实现系统解耦时

六、性能优化贴士

避免每帧触发高频事件（如Update中的物理检测）
及时取消订阅防止内存泄漏
对高频事件使用EventManager集中管理
值类型参数优先使用ref传递
使用对象池重用事件参数

结语

理解委托和事件的区别就像掌握魔法世界中的两种咒语：委托是灵活的基础咒语，而事件则是施加了保护咒的强化版本。在Unity开发中，建议80%的场景使用事件，仅在需要完全控制调用时使用原始委托。记住：事件不是委托的替代品，而是其安全封装形态。合理运用这对黄金组合，可以让游戏代码既优雅又高效！

一个根据胜率匹配玩家的算法

发表于2019年9月17日由tsai

根据胜率积分来匹配双方玩家的算法可以使用 “Elo rating”（也称为 Elo 算法）。Elo 算法最初是用于计算棋手之间的等级差异，但它同样适用于其他竞技类游戏，包括电子竞技和体育运动。

以下是基于 Elo 算法的胜率积分匹配算法的步骤：

1. 确定初始积分：为每个玩家设置一个初始积分。通常新玩家初始积分为一个固定值（例如 1000 分）。

2. 预测胜率：对于两个玩家 A 和 B，使用以下公式计算他们之间的预测胜率（通常用 S 表示）：

S = 1 / (1 + 10^((Rb - Ra) / 400))

其中，Ra 是玩家 A 的当前积分，Rb 是玩家 B 的当前积分。

3. 计算积分变化：假设玩家 A 赢得比赛，则他的积分变化（通常用 K 表示）可以根据以下公式计算：

K = K_factor * (1 - S)

其中，K_factor 是一个常数，用于控制积分的波动幅度。通常情况下，新玩家的 K_factor 较大，以使其积分更快地调整。

4. 更新积分：根据比赛结果，更新玩家 A 和 B 的积分。如果玩家 A 赢得比赛，则他的新积分为：

Ra_new = Ra + K
Rb_new = Rb - K

如果玩家 B 赢得比赛，则互换 A 和 B 的公式。

5. 重复过程：根据新的积分，再次预测下一次比赛的胜率，并重复上述步骤。

需要注意的是，K_factor 的值和初始积分是需要根据具体的游戏或竞技体育的情况进行调整的。K_factor 值过大会导致积分波动过大，而过小则调整速度较慢。

使用 Elo 算法进行胜率积分匹配可以使玩家之间的积分更加公平地反映他们的真实水平，并且在比赛胜负时调整积分。

unity帧率优化

发表于2017年6月6日由tsai

在Unity中，帧率（Frame Rate）是指每秒钟渲染的帧数，常用单位为FPS（Frames Per Second）。游戏开发过程中，如果帧率低了，可能就是受到以下因素的影响：

1. 渲染时间：每帧的渲染时间取决于场景中的物体数量、复杂度以及使用的特效和着色器等。渲染时间过长会导致帧率下降。

2. CPU性能：CPU负责执行游戏逻辑、物理模拟、AI计算等任务。如果CPU性能不足，可能无法在每帧的时间限制内完成必要的计算，导致帧率下降。

3. GPU性能：GPU负责处理图形渲染任务。如果GPU性能不足，无法及时处理渲染指令，导致帧率下降。

4. 游戏逻辑复杂度：复杂的游戏逻辑、AI计算、碰撞检测等任务会消耗CPU的计算资源，影响帧率。

帧率对游戏的运行流畅度有重要影响。较高的帧率能够提供更流畅的动画和交互体验，而较低的帧率可能导致卡顿、延迟响应和不流畅的动画效果。

几个可考优化方案：

1. 减少渲染开销：通过减少复杂的特效、减少细节或使用合理的LOD系统来减少渲染负载，从而提高帧率。

2. 优化代码性能：通过优化游戏逻辑、减少资源加载和销毁、使用对象池等技术来减少CPU计算开销。

3. 使用批处理技术：通过合并渲染操作，减少Draw Call的数量，从而提高GPU性能。

4. 适当使用线程：将耗时的计算任务放在单独的线程中执行，避免阻塞主线程，提高CPU利用率。

5. 使用合理的资源管理：合理使用纹理压缩、资源压缩和内存优化技术，减少内存占用和加载时间。

6. 避免过度渲染：根据场景需要，避免无意义的渲染操作，如遮挡物体、避免渲染在屏幕外的物体等。

7. 使用性能分析工具：利用Unity提供的性能分析工具，如Profiler，可以定位性能瓶颈并进行针对性的优化。

u3d的drawcall几个注意的地方

发表于2017年5月19日由tsai

在Unity中，Draw Call是指渲染器在绘制场景中的每个独立物体或图元时发出的绘制命令。Draw Call的生成大致由以下因素决定的：

1. 独立物体：每个独立的物体（GameObject）通常需要一个单独的Draw Call来进行渲染。例如，如果场景中有100个不同的物体，则会生成100个Draw Call。

2. 材质（Material）：每个材质都会产生一个Draw Call。如果多个物体使用相同的材质，则它们可以合并为一个Draw Call。

3. 纹理（Texture）：每个使用不同纹理的物体也会产生额外的Draw Call。如果多个物体使用相同纹理，则它们可以合并为一个Draw Call。

Draw Call数量的增加会对游戏的运行流畅度产生影响，因为每个Draw Call都需要CPU和GPU的处理，过多的Draw Call会增加渲染的开销。较高的Draw Call数量可能导致以下问题：

1. CPU开销：每个Draw Call都需要一定的CPU开销，包括物体和材质的设置、状态切换等。当Draw Call数量过多时，CPU将花费更多的时间来处理渲染命令，可能降低游戏的帧率。

2. GPU开销：在GPU端，每个Draw Call都需要进行渲染资源切换和状态设置。大量的Draw Call会增加GPU的负载，可能导致性能瓶颈，如卡顿和低帧率。

为了优化Draw Call，常见的有以下几个优化方案：

1. 合批（Batching）：尽量减少独立物体和材质的数量，以减少Draw Call的生成。使用相同材质的物体可以合并为一个Draw Call，可以使用静态批处理（Static Batching）或动态批处理（Dynamic Batching）来实现。

2. 材质合并（Material Merging）：如果多个物体使用相似的材质，可以将它们合并为一个材质，以减少Draw Call的数量。

3. 纹理图集（Texture Atlas）：将多个小纹理合并为一个大纹理图集，可以减少纹理切换和Draw Call的数量。

4. GPU Instancing：对于使用相同网格和材质的大量物体，可以使用GPU Instancing来减少Draw Call的数量。GPU Instancing允许多个物体同时渲染，只产生一个Draw Call。

5. 动态LOD（Level of Detail）：根据物体的距离和屏幕尺寸，使用不同级别的细节模型（LOD）来减少多余的绘制。通过动态LOD，可以减少不必要的Draw Call。

6. 静态合并（Static Mesh Combining）：将多个静态网格合并为一个网格，以减少Draw Call的数量。适用于静态不可变的场景元素。

怎样使一个IP手游的第一次CBT拖延3个月

发表于2015年7月3日由tsai

最近，参与的IP手游项目终于第一次CBT结束了。

IP手游真是件累人的事儿，各种监修各种限制，光游戏UI资源就换了至少4个版本，各种比较创新的玩法也被一一砍掉。本来的CBT时间点是在3月份的，然而，现在是7月份了。不得不喷下这大几个月在拥有众多资源的公司中开发IP手游碰到的问题。

前期规划不足

规划的问题，其实是在各种项目中多多少少都会碰到的问题。既然负责客户端这边的开发，就只说说客户端统一性规划。涉及人员当然是策划、美术、程序缺一不可。

项目开发过程中，我们的策划的每一个案子中控件的设置方法、摆放位置（涉及美术），乃至配置表字段的设计都是乱来的，怎么舒服怎么做，导致美术出的效果也不能统一，然后美术的设计风格也是一个界面一风格。如此，直到游戏基本成型后还需要重新大幅调整资源，统一设计风格，然后程序加班加点修改，这上面浪费了大量的时间精力。如果在项目初期就注意这些统一性的把控，游戏开发应该是更顺畅的体验吧？

开发迭代不规范

再者，项目开发过程中，美术、程序的迭代过程不是不断优化的过程，而是不断替换之前成果，更关键是这种替换不是推到重来，而是回到之前的之前版本模式。

糟糕的迭代导致项目资源的严重浪费，我看到程序、美术在不断加班加点做着重复的工作，感觉好痛心。我在考虑一个问题，制作人在这种情况下是不是应该停歇一下，思考下项目为什么会进入这样恶性循环中，而不是任由此类态势发展下去，最终导致项目不断延期。

当然，这种无奈的情况不能排除IP游戏中特有的情况，如若真是如此，是不是负责监修方面的人员应该做的更到位一点？

产品阶段模糊

在我们游戏CBT版本功能还没有定下的时候，就开始接入QA了。然后QA各种测试后，提交了各种bug，程序再修复bug，如此反复一个多月，直到一个多月后，才发现QA测试的很多功能是要砍掉的或是程序、美术要重新修改的功能。

项目开发中也频现类似的情况：策划分配策划案到美术、程序，之后相关创作人员进行功能制作。在程序获得美术资源进行功能开发的时候，美术的第二版、第三版资源就接踵而至，导致程序浪费大量时间在前段ui修改上，而不是代码性能及功能优化上。

诸如以上产品把控的乱入，直接造成项目资源的严重浪费。所以，想拖延项目进程的，照着上面做就行了。

2014->2015

发表于2015年1月1日由tsai

最近跟朋友聊天，总或多或少听到提及时间过得好快啊。。之类的词语，巧的是，本人也有同样的感觉。

即将过去的一年，对于我的关键词简约了好多：生娃、手游。

生娃

我的宝贝女儿终于在这一年健健康康地来了，开始了她的精彩人生，我也算正式加入奶爸大军了。现在每天回家，还是只能跟他大眼瞪小眼，对视地傻笑，不过这样就够了。生之前总有计划着，生完后到现在，执行一片空白，突然发现这真是一种病，得改。

手游

本来想把做手游当成职业爱好，不想竟然真的做了一年多了，而且还真的做出了像样的作品了，而且成绩还算可以（对于处女作来说）。

虫虫消消乐没推广的情况下，在苹果AppStore上卖出了近3万拷贝，算是达到了自己的预期。但是在随后的版本更新中，自己引入了一个悔到肠青的bug，导致用户量和活跃用户急剧下降，希望吃了这一堑得长点智，修改bug，还是得有个完整的测试过程。

在google play上，虫虫消消乐卖了近5000拷贝，成绩不好的主要原因，我就归结为Android版本出得较晚，还有google play在大陆众所周知的处境。因为游戏中有内购功能，国内安卓平台限制个人应用集成内购功能，因此，Android版本没在国内的安卓平台上线，这应该也算Android版本不佳的原因吧。

关于吹过的牛逼

写了几年总结，发现年年都会吹一些牛逼，然后下一年终总有对不起的牛逼。

吹过的牛逼1——业余时间做2-3个手游。我其实业余只做了两个简单手游，一个虫虫消消乐，另一个也是消除类游戏，当然不是虫虫消消乐的玩法。但是，没上线，由于种种原因。。好吧，这是一种病。

吹过的牛逼2——再多看四五本书。其实是很简单的一件事，但是竟然还是没达成。现在想想，我总以太专注写代码来搪塞“为什么没时间看书”这样的理由，这也是加剧拖延症的主要原因之一，得治。

各种年度评选

今年年度人物毫无疑问是我的乖乖女儿——水灵灵的眼睛眨呀眨。

年度产品就将就发给虫虫消消乐吧。

2015

看10本书；
写12篇文章；
努力赚钱，养家糊口；
对得起吹过的牛逼；
与拖延症顽抗到底。

写在201314

发表于2013年12月31日由tsai

照旧，在2013的最后一天是该总结点东西。这个时候，整理那些思绪中混乱的时间碎片，都会感伤时间的飞快。先亮一下现在头壳中的那些标签云吧：游戏、微信、苹果、小米、3d打印、移动开发。这些是我今年在reader中关注比较多的词条。

可能因为有点过分专注于写代码了，这是沉溺在reader、微博、知乎比较少的一年了。简单地结个论，这是属于微信的一年，也是属于小米的一年，同样也是各种移动应用的爆发年，这行的国产企业的雄起，让我不用预测都知道2014它们会更加火热，加上易信、来往，各种支付以及各种手机厂商、各种云的乱入，2014将会上演更加精彩的业内诸企业争霸剧情，都忍不住想看了。

戏是大佬们演的好看，但还是得回到现实演好自己的屌丝泡沫剧。还是评评本屌丝泡沫剧的各种年度最佳抢镜：

年度抢镜关键词

游戏：我有史以来专注在游戏行业上最多的一年，也更多地主动接触横跨端游、页游、手游各种游戏。工作上，负责away3d粒子编辑器编写，参与游戏编辑器的功能开发，这些都让我收获蛮多，业余上，写了个三消游戏，也算学习了手游开发的流程，弥补了自己移动端的不足。

年度抢镜电子产品

今年是最低碳的一年，只添置了Amazon的kindle paperwhite，虽然仍有很多很酷的产品上线，但是貌似没促动我消费神经的产品？好吧，我不会告诉你其实是我没钱。。

mbp：这是前年的东东了，但是其实人家还没过时呢。装上osx10.9，各种崭新如初，写代码什么的各种方便，伦家unix系的就是霸道就是逼格高。额低调下，其实挺卡有时候，有钱了咱也升级。
ipad2：这是去年的，但是人家也没过时呢。升级ios7，依然各种顺畅崭新如初，各种场合看片游戏利器，加之百度网盘乱入，妈妈再也不用担心我看片不方便了。
kindle Paperwhite：其实这是老婆建议买的，但是万万没想到，因为翻页的拖延及闪烁，用惯了ipad的年轻人用起来不习惯，买后几乎是我在用，真是不幸中的万幸。借助它，我算是多看了点书（但是貌似还没把本钱看回来），而且看网页文章各种爽，还是得赞下amazon的send to kindle插件。

年度抢镜互联网产品

本来想分开pc和移动的，但是界限太模糊，不好操作。随着移动互联网的大势入侵，pc互联网很多都加大了移动互联网的打通力度，静候2014各种大战。

微信：这个应该没有争议，因为它和新浪微博在国内大有统治之势头。在得入口者得天下这句话的号召下，如今业内可谓群雄并起，今年的第四季度易信、来往的突袭可见一斑。
支付宝：新推出的余额宝让大佬们看到了网上支付可以这样玩期货，余额宝的成功将挑起更多的网上期货大战，诸如度娘的百度理财，加之微信微支付的乱入。唉，一想到这些战争就开心。
百度网盘：打通web、pc、移动端的类dropbox，提供了2T空间让社会各界宅男乐开了花，有了2T的种子，他们的妈再也不用担心他们了吗？
小米：暂且将小米归到互联网产品吧，因为人家不是说了互联网思维做产品嘛。不说什么，就冲3年弄出个100亿美金的公司，雷牛了。

年度抢镜业余作品

三消游戏：做的一个手游(其实还做了个消消零食，参考消除星星来着)，程序、美工、音效等等都自己包了，好累啊。
微洛克：腾讯微博粉丝管理工具，帮微博运营的同学写的一个小工具。
微信自动回复公共账号：微信号：musictee，叫我爱查歌词，提供歌词查询功能。

年度抢镜旅游

说到旅游，得说今年是悲催的一年，也就省内溜溜。

福鼎太姥山：跟老婆和她得小伙伴们去的，因做为拎包员得以跟随。其实挺漂亮的那景色，要说也不比武夷山差多少，就是开发没跟上。

年度抢镜户外活动

全程马拉松：参加了厦门国际马拉松，具体跑了多少就不说了，反正咱是在7个小时内，拿了牌的呢。好吧，还是说说吧，6个多小时，但是我是有理由的，中途吃了顿肯德基来着，不然，不然，走慢点也是6个多小时。说实话吧，都走那么慢了，脚还是酸了一周多的。

年度抢镜人物

我老婆，还有我们的宝宝，要好好健康成长。
老爸老妈，他们在变老，依旧奋战一线，做为儿子很是惭愧。

展望2014

业余时间做2-3个手游；
再多看四五本书；
用好时间规划软件；
努力赚钱，养家糊口。

读了“湿营销”后

发表于2010年11月17日由tsai

实话说对营销这个东西没有什么概念，也就谈不上什么湿营销了。偶然在豆瓣上看到“湿营销”（作者Tom Hays和Michael S. Malone，曹蔓译，见文章的插图）这本书，读者评价不错，就买了看看，也当做给自己空缺的一大片知识面填补一小块空白吧。基本上书本一半的内容是在上下班的地铁上看完的，所以可能错过细读一些精彩内容，有空继续补之，当然也不知道错过了多少与美女对视的惊险场面，给擦肩而过的美女们造成的不便之处敬请见谅（莫名自恋中。。弱弱地请帅哥们飘过~~）。好了，下面华丽地转正经切入主题。

看这本书是从三个推荐序看起的，看了第一个序“人是湿的”，觉得在瞎扯淡，而且是扯到蛋疼的那种，二序和三序还稍微让我懂了点那个啥湿营销；看完整书后再来看一序，还是觉得大部分在扯淡，但还是赞同了里边的“阴阳”论与“和而不同”论：这里描述的“阴阳”就是道教里阴阳结合，你中有我、我中有你的境界，但是阴和阳又有本质的区别，这样理解的话“阴阳”论也就与“和而不同”一个意思了。

作者从人类学、社会学、心理学的角度描述社会群体中的人的关系是趋向于亲密而自然的，这也是人性深处最本质的需求。人与人无论从思想、行动等等方面是有种种不同的，但又因为这种亲密自然的需求，就有了《周易.系辞》里的“方以类聚，物以群分”的道理。

“群分”不管是在原始社会里的部落还是现代社会的民族概念，或者讲小点到人们自发组成的各种兴趣爱好协会、小组、俱乐部等，这些都说明了人的“群分”本性。作者提到的一个有意思的人类学现象，人类的部落集群是有极限的，当一个组织机构的人数不断膨胀后，组织中人与人之间的直接交流会变得越来越困难，这样导致组织很有效率的交流及工作。

据研究，一个组织的人数一般在150人以内会保持效率及灵活性。这个在原始族群中就有明显的体现，在亚马逊里原始部落里，每个部落有一个萨满管理人们的生、死及族群发展的重大决定，而这个重大决定通常是关于族群的拆分，即把族群一分为二，这就是原始部落的组织拆分以方便首领的直接管理。同时从原始部落的集群还可以得出：一个人可以通过蜂窝式群体组织，让不同区域的人先组成较小的群体，而后较小的群体再组织成一个大圈子。

个人觉得马云的“Small is beautiful”的新型企业观点与以上这种群体的趋小化观点大同小异，只是马云说的是“Small is beautiful for 21st century”而已。这当然仍不能很好地解释SNS疯狂兴起的现象，但是不同的价值观、不同爱好等因素形成了SNS中不同的群体，不同的关注群组，这之中爆发的众多群体引爆了碎片化经济的圈子世界，开启所谓新的“湿营销”时代。

因为这本书主要讲的是湿营销，所以作者偏向的还是湿营销基于的所谓的新的互联网营销模式，而把传统的大众营销方式视为一定会被取代的模式，本人虽然也很不好意思地跟作者的观点类似，但是目前中国的传统的大众营销模式还是占据相当大的一部分市场的，这可能部分取决中国的消费者教育程度，因此在中国要谈新型网络营销完全取代传统营销仍有待时日，只能说前者在灰常迅速地奔跑。而传统大众营销由于一度地强奸用户，无论从电视、报纸、杂志，充满了人们不喜欢的“在广告中插播电视剧、在广告中插入新闻消息”等的硬性强加行为，估计会加速其灭亡。

在这个发展迅猛的碎片化经济时代，新型网络营销人员怎样为自己的产品做广告呢？书中讲的很大一部分也就是怎么融入各个有不同兴趣爱好，思想观点千差万别的群体们中。

作者从人们在社会群体中的极力维护群体观点（不管客观对错），排斥不同群体言论及成员，并竭力争取在群体中的地位以及群体中的个别观点或部分人观点如何通过明星效应等形成信息瀑的病毒式传播等等人类社会学观点，解释了SNS中群体间关系、消息的高速传播及SNS中很明显的明星效应，当然更重要的，所有的这些都是新型网络营销人员面临的挑战和机遇（承认这俩词好用且和谐）。个人觉得这部分精彩、描述的挺在理，毕竟接触的SNS看到的那些灰常厉害的明星效应、很尖锐的不同群体中的言论针锋相对（如twitter上针对那个啥裆的啥啥，有上推的笑而不语~）等等。

对碎片化经济时代的各种圈子现象的一大堆人类学阐述后，作者在后面的三篇分别从SNS用户消费者的思维，如何提供不同群体消费者所需，不冗余、不繁杂、不强硬（不小心搞出个“三不”，请原谅我的有才~）地参与SNS等网络媒介用户群体的讨论，并成为群体认同的成员切入，提出“身份即营销”的强大观点。

在湿营销时代一篇，讲到真实人性的回归，同样包含的人类学、社会学外加少许经济学的元素，讲到了“湿”的深层次含义，讲得我面红耳赤（请排除一切邪念阅读本句）。最后讲到湿营销的信任体系，也是营销人员如何融入立场坚定、极力排外的各种群体中最为基本的要素。

整书下来，人的社会群体生存之道、交流之道占书内容的很大部分，可以说很多观点都是围绕这个展开的，因此，看这本书是有点在学人类学、社会学、心理学的味道。这本书目前我只看了一遍，觉得看起来、理解起来还是通的，遍观现在的忒特、非死不可、新浪围脖等SNS或新型网络群体中的湿营销还是很常见的，说明新的碎片化经济是真的在迅猛发展。所以这书可以稍微关注下。

风牛菜籽

拖延症重症患者

分类目录归档：日志