[ 读写人(duxieren.com)文摘] [文章来源： 严杰夫]

文/严杰夫

许多投资者都知道，个体心理会对市场波动产生影响，但像里昂·利维这样，将心理因素视为投资核心因素的投资大师，恐怕就不多见了。

对我国投资者来说，里昂·利维的名气远不如“股神”沃伦·巴菲特、“金融大鳄”乔治·索罗斯及吉姆·罗杰斯。但在华尔街，里昂则是与巴菲特齐名的传奇人物。遗憾的是，里昂在2003年去世后，并未留下太多关于他的投资理念的文字，唯有一部名为《股价为什么会上涨》的自传式作品，成为后来者管窥他投资思想的 “秘籍”。

 

想要了解里昂的投资理念，我们或许该先了解一下他的家庭和出身。1925年，里昂·利维出生在一个犹太人家庭。与许多美籍犹太裔一样，利维家族也是个商人家族。里昂的祖父1865年从波兰移民到美国，成为商贩。刚开始，里昂的祖父专门给特拉华州和哈德逊公司的平底船提供给养品。但在与著名的伊利铁路公司的竞争中，利维祖父的公司倒闭了。此后，他又合伙开办过纺织品批发公司，还有一家批发袜子的企业——利维家族公司。后面这家公司成为利维的家族产业。

里昂的父亲杰罗姆·利维是长子，自然也就成了家族产业的继承人。不过，杰罗姆的兴趣并不在做生意，而是研究经济学。杰罗姆研究的是如何同时实现充分就业与政府、企业的收支平衡——一个典型的政治经济学问题。然而，在研究过程中，杰罗姆学到了预测企业利润的能力，这使得他在投资上获得了不少成绩。当然，归根到底，杰罗姆一生的兴趣还是在经济学而非赚钱。用儿子里昂的话说，投资对杰罗姆来说，“更多的是一种智力体操”。但他确确实实地对里昂的职业生涯产生了潜移默化的影响。

事实上，里昂自己也并不避讳这一点。据他回忆，在他很小的时候，就已成了父亲投资学思想的“学徒”，其中最重要的是，他从父亲那里学会了如何在交易中寻找模型。而这一点在里昂投身于华尔街以后，特别是在成为奥本海默基金公司合伙人之后，便成了他最重要的一项“技能”。凭借这项技能，里昂领悟到了“如何从内部人员股票交易的月度报告中，寻觅公司正在筹谋事项的预警信号”，这也使得他能从各种公开信息中判断出投资机会和投资风险。

一个有意思的故事发生在20世纪60年代末，彼时里昂已是奥本海默基金的合伙人，凭借着“公开信息”，里昂帮助公司成功地躲过了大股东所挖的“陷阱”。20世纪60年代中期，一位名叫伯尼·科恩菲尔德的投机客创建的基金公司购买了奥本海默基金公司的股份，并成了奥本海默的最大股东。但包括里昂在内的合伙人，都十分警惕科恩菲尔德会干预公司对股票的购买选择。这种担心很快变成了现实。有一天，科恩菲尔德想给里昂介绍一位石油大亨，并试图向里昂“推销”这位大亨的油田——这位大亨想向奥本海默出售2万英亩北极油田，而事实上这些油田也由科恩菲尔德的公司控制。更蹊跷的是，这位大亨同意，如果奥本海默愿意以每英亩8美元的价格收购，那么八年之内不需要提供任何资金。

我相信，大部分人在看到大亨提出的交易条件时，一定觉得这是桩只赚不赔的生意。但里昂偏偏留了个心眼。他在会见大亨之前，就咨询了标准石油公司的首席地质学家。这位学者告诉里昂，北极油田的价值应在每英亩大约50美分。事先掌握了这一关键信息，里昂迅速理解了科恩菲尔德和他的大亨朋友的“阴谋”：他们希望借着与奥本海默的交易，将北极油田维持在每英亩8美元的虚高价格上，而这正是科恩菲尔德在购买这些油田时所支付的对价。更进一步，凭着这项交易，科恩菲尔德还能顺便抬高旗下基金公司的估值，以误导投资者!

在里昂超过50年（如从上学时投资铁路债券开始算，则有60年）的投资生涯里，借助公开信息的投资决策，可以说已成了他的“套路”。此外，里昂也十分重视宏观经济和全球格局的变化在投资领域的影响。正如他所说的“投注经济而非股票”。里昂认为，未来最大的行情很可能会诞生于那些有着巨大增长潜力的国家：如印度、中国或俄罗斯。从这一角度来看，经济分析在里昂的投资理念中占据着重要地位。

不过，假如只谈“经济学”，那只算理解了里昂投资理念的一半甚至一小半内容。因为，在里昂的投资世界里，位于核心位置的并非“经济因素”，而是“心理因素”。正是这一点，决定了里昂投资理念的独特性和原创性，而并非简单地继承和复制他父亲的思想。

里昂相信，任何事情的发生都起源于人们的各种决策，而在这背后，起着驱动作用的就是投资者个人的心理。所以，忽视投资市场的心理因素，就像忽略“房间里的大象”一样可笑。里昂坚信，“如果不去探究背后驱使人们付诸行动的心理，即便是大泡沫也不值得去探讨”。在里昂看来，正是投资者个体的心理因素汇聚到一起，才形成了股价的上涨或下跌，甚至催生了股价的持续疯涨，以及随后而来的“泡沫破灭”和金融海啸。

《股价为什么会上涨》的第11章，小标题是“股票为什么会下跌”。从字面上看，这一章的内容似乎与全书主题相悖，但其实股票无论上涨还是下跌，其背后都是市场参与者的心态波动在作祟。因此，这实际上是浓缩了里昂投资理念中最核心一环的章节。

就在这一章节里，里昂大量分析了人们的投资行为背后体现出的投资心理：为何典型的投资者不卖亏损的股票？为何投资者常常会低估所持有的投资组合的下行风险？这些市场上司空见惯的投资行为，背后都有着深刻的心理逻辑。比如，之所以投资者不愿意卖出亏损的股票，是因为出售亏损股票意味着承认自己的错误，同时人们对亏损的厌恶也使得人们扭曲了对事物发生概率的认知。在这样的心态下，自然也就会低估自己的持仓风险。

事实上，这样的心理不仅影响了普通的投资者，同时也在困扰基金经理等专业投资者。这就难怪我们在市场上会常常看到“助涨杀跌”的现象，反倒是所谓理性投资的行为变得极为罕见。投资市场也就此将“羊群效应”演绎得淋漓尽致。

或许，用一个古老的命题来阐释里昂的“投资心理学”再恰当不过：“繁荣滋生松懈，松懈滋生不可信的数据，最终这些不可信的数据又引发时代的衰败”。通俗地讲，当经济繁荣、股价高昂时，监管和会计部门在心理上就容易放松警惕，总是以为人们的债务很容易偿还，财富也会一直增长而会弥补过去的欠缺。在这种全社会心态都放松的背景下，企业就会偷工减料，尽力钻制度的漏洞去套取利润，并形成虚假繁荣的景象。但当其中某个环节（常常是一家或一类企业：1998年是长期资本管理公司，2000年是互联网企业，2008年则是雷曼兄弟）出了麻烦时，所有这一切就像多米诺骨牌那样被推倒，局面立刻变得一发而不可收拾——音乐总有停止的时候，非理性繁荣也终有退潮的那一刻。

“心理因素”和“经济因素”共同构成了里昂的“投资世界”。这两个因素互相作用，也使得投资市场无法成为 “绝对有效的市场”，而只能是 “相对有效市场”。因此，处在这个市场里的人，必须学会在公开信息里判断出其他投资者的心理，推测他们手中的筹码和底牌，并判断出他们下一步的行动以及市场未来的方向。正因此，在里昂看来，投资更像是一门艺术而非精密科学，并且“没有哪一套理论能够完美地阐明市场，未来也从来都不是过去的简单重复”。

在《股价为什么会上涨》里，里昂将投资的要义简明地归纳为两个方面，但我们也会察觉，还有其他因子和观念在影响着他的决策。我们可以看到，他对历史和艺术也有极浓厚的兴趣，在政治和社会领域也有独特的想法。在这一点上，里昂的理念和查理·芒格似乎又有着某种共通之处。查理·芒格将投资的诀窍归结为“lollapalooza”效应——当一个人掌握思维模型的数量到一定程度时，就能产生一种思维上的奇观，届时无论在投资还是其他事业，他都能取得惊人的成果。

当然，最重要的是，无论是里昂还是芒格，他们都在教导我们，投资就是一个漫长的信息积累和分析过程，从来没有什么“悬崖深处的秘籍”能让我们一夜暴富。正如芒格所说：“我们赚钱，靠的是记住浅显的，而不是掌握深奥的。我们从来不试图成为非常聪明的人，而是持续地试图别变成蠢货”。

-------------------------------------------------------------------------------------------------------------------------

如果您喜欢我的文章，请帮忙在“朋友圈”转发，并推荐“严杰夫的约柜”。：）

 

原文链接： http://jeffyanguang.blog.163.com/blog/static/12215523820174375258535
走廊网： 文化频道 | 生活频道 | 创意&视觉频道 | IT频道

2017 年的春季招聘季刚刚过去，在这 2016 资本寒冬年后的第一个招聘旺季，互联网招聘市场正悄然变化。其中最大的一个变化是：招募互联网高端人才的主力，正在从中小型创业公司向中大型公司转移。

100offer汇总了 2017 年第一季度 100offer 上高端互联网人才的面试邀请数据，下面就用八张图，为你展现这个春天里，互联网人才流动的「变」与「不变」。

一、互联网行业薪资波折上升

整体来看，整个行业的薪资依然保持良好的增长率。但在 2017 年的招聘旺季，因供给增加，人才稀缺度减弱，薪资环比下降。

二、现在的互联网人更想去大公司还是小公司？

很显然，小公司的吸引力在削弱，大公司则重拾人才招聘的主动权。造成这种现象的原因，除了寒冬后互联网人心态的变化，还有企业可开出薪资的实力变化。前文提到，高端互联网人薪资在 Q1 同比增长 21%，但是这个涨幅更多由 C 轮以后的，更大规模的公司拉动。

招聘需求也在向大公司集中。前几年，大量获得融资后的初创公司有实力用高薪、期权抢夺人才，但是否有持续的供血能力，才是屹立不倒的关键。

三、这个春天，互联网哪个领域最高薪？

传统强势领域电商、互金、移互依然有不错的薪资增长。数据与信息服务领域涨幅偏低，也许需要警惕所谓的大数据过热。O2O 领域则出现罕见的负增长。

四、哪个职位更受欢迎？

Java、Scala、算法、前端依然是最热岗位。

五、互联网哪个城市更高薪？

那么，在这些城市买一个 80 平的房子，不吃不喝至少攒几年？

去年，在阿里、网易等巨头的拉动下，杭州互联网人薪资一度领先北京。在刚刚过去的 2017 年 Q1，北京薪资又重回首位。但不变的是买房难度，北京互联网人实际生存压力依然高于其他城市。而拥有大公司、高薪资、低房价的杭州，依然是个不错的去处，至少目前是这样。

下载虎嗅APP，第一时间获取深度独到的商业科技资讯，连接更多创新人群与线下活动

原文链接： https://pqpo.me/2017/05/03/learn-messagequeue/

Android 中有两个非常重要的知识点，分别是Binder机制和Handler机制。前者用于跨进程通讯，并且通过 ServiceManager 给上层应用提供了大量的服务，而后者用于进程内部通讯，以消息队列的形式驱动应用的运行。之前的文章已经多次分析了Binder相关的内容，复杂程度远高于Handler，之后还会继续分析Binder。说到Handler，做安卓开发的一定都不会陌生，一般用于切换线程。其涉及到的类还有Looper，MessageQueue，Message 等。其中MessageQueue是事件驱动的基础，本文会重点分析MessageQueue，其他内容会简单带过，可以参考生产者-消费者模式。

从Handler的入口开始分析：

Looper.prepare();
1.创建一个Looper，并且是线程私有的：sThreadLocal.set(new Looper(quitAllowed));
2.初始化Handler：mHandler = new Handler();，在构造函数中会获取线程私有的Looper，如获取不到会报错。
3.开启无限循环：Looper.loop();。
在loop方法中主要代码如下：

for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
msg.target.dispatchMessage(msg);
msg.recycleUnchecked();
}
从MessageQueue中获取待处理的Message（阻塞线程）
交给与之关联的Handler处理
回收Message，供Message.obtain()复用
其中msg中的target是在Handler发送消息的时候赋值的：

public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
MessageQueue queue = mQueue;
if (queue == null) {
RuntimeException e = new RuntimeException this + " sendMessageAtTime() called with no mQueue");
return false;
}
return enqueueMessage(queue, msg, uptimeMillis);
}

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
发送的消息最终入队列到了MessageQueue。
简单总结一下Handler消息机制的工作原理：

创建与线程绑定的Looper，同时会创建一个与之关联的MessageQueue用于存放消息
开启消息循环，从MessageQueue中获取待处理消息，若无消息会阻塞线程
通过Handler发送消息，此时会将Message入队列到MessageQueue中，并且唤醒等待的Looper
Looper获取的消息会投递给对应的Handler处理
可以看到其中与MessageQueue相关的也就两个操作，一个是入队列（MessageQueue是链表结构），一个是出队列，这正是本文介绍的重点。
MessageQueue的创建：

MessageQueue(boolean quitAllowed) {
mQuitAllowed = quitAllowed;
mPtr = nativeInit();
}
nativeInit()方法实现为android_os_MessageQueue_nativeInit()：
[android_os_MessageQueue.cpp]

static jlong android_os_MessageQueue_nativeInit(JNIEnv* env, jclass clazz) {
NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();
if (!nativeMessageQueue) {
jniThrowRuntimeException(env, "Unable to allocate native queue");
return 0;
}
nativeMessageQueue->incStrong(env);
return reinterpret_cast(nativeMessageQueue);
}
这里会创建一个native层的MessageQueue，并且将引用地址返回给Java层保存在mPtr变量中，通过这种方式将Java层的对象与Native层的对象关联在了一起。这种在Java层保存Native层对象引用地址来实现关联的方式，在Android源代码中会经常看到。
然后看一下Native层MessageQueue的构造方法：

NativeMessageQueue::NativeMessageQueue() :
mPollEnv(NULL), mPollObj(NULL), mExceptionObj(NULL) {
mLooper = Looper::getForThread();
if (mLooper == NULL) {
mLooper = new Looper(false);
Looper::setForThread(mLooper);
}
}
也创建了一个Looper，并且也是与线程绑定的，事实上这个Looper与Java层的Looper并没有多大关系，一个是处理Native层时间的，一个是处理Java层事件的。
Java层的Looper会通过调用MessageQueue的next方法获取下一个消息，先看主要部分，后面省略了一部分IdleHandler的处理逻辑，用于空闲的时候处理不紧急事件用的，有兴趣的自行分析：

Message next() {
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// Try to retrieve the next message. Return if found.
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// Stalled by a barrier. Find the next asynchronous message in the queue.
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
// Next message is not ready. Set a timeout to wake up when it is ready.
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// Got a message.
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
return msg;
}
} else {
// No more messages.
nextPollTimeoutMillis = -1;
}
// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
dispose();
return null;
}
}
pendingIdleHandlerCount = 0;
nextPollTimeoutMillis = 0;
}
}
这里有必要提一下MessageQueue的数据结构，是一个单向链表，Message对象有个next字段保存列表中的下一个，MessageQueue中的mMessages保存链表的第一个元素。
循环体内首先调用nativePollOnce(ptr, nextPollTimeoutMillis)，这是一个native方法，实际作用就是通过Native层的MessageQueue阻塞nextPollTimeoutMillis毫秒的时间。
1.如果nextPollTimeoutMillis=-1，一直阻塞不会超时。
2.如果nextPollTimeoutMillis=0，不会阻塞，立即返回。
3.如果nextPollTimeoutMillis>0，最长阻塞nextPollTimeoutMillis毫秒(超时)，如果期间有程序唤醒会立即返回。
暂时知道这些就可以继续向下分析了，native方法后面会讲到。
如果msg.target为null，则找出第一个异步消息，什么时候msg.target是null呢？看下面代码：

private int postSyncBarrier(long when) {
// Enqueue a new sync barrier token.
// We don't need to wake the queue because the purpose of a barrier is to stall it.
synchronized (this) {
final int token = mNextBarrierToken++;
final Message msg = Message.obtain();
msg.markInUse();
msg.when = when;
msg.arg1 = token;

Message prev = null;
Message p = mMessages;
if (when != 0) {
while (p != null && p.when <= when) {
prev = p;
p = p.next;
}
}
if (prev != null) { // invariant: p == prev.next
msg.next = p;
prev.next = msg;
} else {
msg.next = p;
mMessages = msg;
}
return token;
}
}
这个方法直接在MessageQueue中插入了一个Message，并且未设置target。它的作用是插入一个消息屏障，这个屏障之后的所有同步消息都不会被执行，即使时间已经到了也不会执行。
可以通过public void removeSyncBarrier(int token)来移除这个屏障，参数是post方法的返回值。
这些方法是隐藏的或者是私有的，具体应用场景可以查看ViewRootImpl中的void scheduleTraversals()方法，它在绘图之前会插入一个消息屏障，绘制之后移除。
回到之前的next方法，如果发现了一个消息屏障，会循环找出第一个异步消息（如果有异步消息的话），所有同步消息都将忽略（平常发送的一般都是同步消息），可以通过setAsynchronous(boolean async)设置为异步消息。
继续往下，如果有消息需要处理，先判断时间有没有到，如果没到的话设置一下阻塞时间nextPollTimeoutMillis，进入下次循环的时候会调用nativePollOnce(ptr, nextPollTimeoutMillis);阻塞；
否则把消息返回给调用者，并且设置mBlocked = false代表目前没有阻塞。
如果阻塞了有两种方式唤醒，一种是超时了，一种是被主动唤醒了。根据生产消费模式，生产者有产品的时候一般情况下会唤醒消费者。那么MessageQueue入队列的时候应该会去唤醒，下面看一下MessageQueue入队列的方法,截取了主要逻辑:

boolean enqueueMessage(Message msg, long when) {
synchronized (this) {
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
上面的代码主要就是加入链表的时候按时间顺序从小到大排序，然后判断是否需要唤醒，如果需要唤醒则调用nativeWake(mPtr);来唤醒之前等待的线程。
再总结一下MessageQueue获取消息和加入消息的逻辑：
获取消息：
1.首次进入循环nextPollTimeoutMillis=0，阻塞方法nativePollOnce(ptr, nextPollTimeoutMillis)会立即返回
2.读取列表中的消息，如果发现消息屏障，则跳过后面的同步消息，总之会通过当前时间，是否遇到屏障来返回符合条件的待处理消息
3.如果没有符合条件的消息，会处理一些不紧急的任务（IdleHandler），再次进入第一步
加入消息：
1.加入消息比较简单，按时间顺序插入到消息链表中，如果是第一个那么根据mBlocked判断是否需要唤醒线程，如果不是第一个一般情况下不需要唤醒（如果加入的消息是异步的需要另外判断）
到这里其实关于MessageQueue已经分析的差不多了，其中有两个native方法没有涉及到分别是nativePollOnce，nativeWake，其实之前结论已经给出了，两个方法都会传入mPtr,在native层对应的是NativeMessageQueue的引用地址。
感兴趣的可以继续往下看，先看一下nativePollOnce的实现：
[android_os_MessageQueue.cpp]

static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
jlong ptr, jint timeoutMillis) {
NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
nativeMessageQueue->pollOnce(env, obj, timeoutMillis);
}
通过传进来的ptr获取NativeMessageQueue对象的指针，然后调用NativeMessageQueue对象的pollOnce方法：
[android_os_MessageQueue.cpp]

void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {
mPollEnv = env;
mPollObj = pollObj;
mLooper->pollOnce(timeoutMillis);
mPollObj = NULL;
mPollEnv = NULL;
if (mExceptionObj) {
env->Throw(mExceptionObj);
env->DeleteLocalRef(mExceptionObj);
mExceptionObj = NULL;
}
}
调用的是Looper的pollOnce方法，这个Native层的Looper是在初始化NativeMessageQueue的时候创建的。
[Looper.cpp]

int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
int result = 0;
for (;;) {
while (mResponseIndex < mResponses.size()) { const Response& response = mResponses.itemAt(mResponseIndex++); int ident = response.request.ident; if (ident >= 0) {
int fd = response.request.fd;
int events = response.events;
void* data = response.request.data;
if (outFd != NULL) *outFd = fd;
if (outEvents != NULL) *outEvents = events;
if (outData != NULL) *outData = data;
return ident;
}
}
if (result != 0) {
if (outFd != NULL) *outFd = 0;
if (outEvents != NULL) *outEvents = 0;
if (outData != NULL) *outData = NULL;
return result;
}
result = pollInner(timeoutMillis);
}
}
先是处理native层的Response，这个直接跳过，最终调用pollInner

int Looper::pollInner(int timeoutMillis) {
// Adjust the timeout based on when the next message is due.
if (timeoutMillis != 0 && mNextMessageUptime != LLONG_MAX) {
nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
int messageTimeoutMillis = toMillisecondTimeoutDelay(now, mNextMessageUptime);
if (messageTimeoutMillis >= 0
&& (timeoutMillis < 0 || messageTimeoutMillis < timeoutMillis)) {
timeoutMillis = messageTimeoutMillis;
}
}

// Poll.
int result = POLL_WAKE;
mResponses.clear();
mResponseIndex = 0;

// We are about to idle.
mPolling = true;

struct epoll_event eventItems[EPOLL_MAX_EVENTS];
int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);

// No longer idling.
mPolling = false;
// Acquire lock.
mLock.lock();
// Rebuild epoll set if needed.
if (mEpollRebuildRequired) {
mEpollRebuildRequired = false;
rebuildEpollLocked();
goto Done;
}
// Check for poll error.
if (eventCount < 0) {
if (errno == EINTR) {
goto Done;
}
ALOGW("Poll failed with an unexpected error: %s", strerror(errno));
result = POLL_ERROR;
goto Done;
}

// Check for poll timeout.
if (eventCount == 0) {
result = POLL_TIMEOUT;
goto Done;
}
// Handle all events.
for (int i = 0; i < eventCount; i++) { int fd = eventItems[i].data.fd; uint32_t epollEvents = eventItems[i].events; if (fd == mWakeEventFd) { if (epollEvents & EPOLLIN) { awoken(); } else { ALOGW("Ignoring unexpected epoll events 0x%x on wake event fd.", epollEvents); } } else { ssize_t requestIndex = mRequests.indexOfKey(fd); if (requestIndex >= 0) {
int events = 0;
if (epollEvents & EPOLLIN) events |= EVENT_INPUT;
if (epollEvents & EPOLLOUT) events |= EVENT_OUTPUT;
if (epollEvents & EPOLLERR) events |= EVENT_ERROR;
if (epollEvents & EPOLLHUP) events |= EVENT_HANGUP;
pushResponse(events, mRequests.valueAt(requestIndex));
} else {
ALOGW("Ignoring unexpected epoll events 0x%x on fd %d that is "
"no longer registered.", epollEvents, fd);
}
}
}
Done: ;
// Invoke pending message callbacks.
mNextMessageUptime = LLONG_MAX;
while (mMessageEnvelopes.size() != 0) {
nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0);
if (messageEnvelope.uptime <= now) {
{ // obtain handler
sp handler = messageEnvelope.handler;
Message message = messageEnvelope.message;
mMessageEnvelopes.removeAt(0);
mSendingMessage = true;
mLock.unlock();
handler->handleMessage(message);
} // release handler

mLock.lock();
mSendingMessage = false;
result = POLL_CALLBACK;
} else {
mNextMessageUptime = messageEnvelope.uptime;
break;
}
}
// Release lock.
mLock.unlock();
// Invoke all response callbacks.
for (size_t i = 0; i < mResponses.size(); i++) { Response& response = mResponses.editItemAt(i); if (response.request.ident == POLL_CALLBACK) { int fd = response.request.fd; int events = response.events; void* data = response.request.data; int callbackResult = response.request.callback->handleEvent(fd, events, data);
if (callbackResult == 0) {
removeFd(fd, response.request.seq);
}
response.request.callback.clear();
result = POLL_CALLBACK;
}
}
return result;
}
这个方法有点长，首先会根据Native Message的信息计算此次需要等待的时间，再调用

int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
来等待事件发生，其中是epoll是Linux下多路复用IO接口select/poll的增强版本，具体可以自行查阅相关文章，查考：Linux IO模式及 select、poll、epoll详解
如果epoll_wait返回了，那么可能是出错返回，可能是超时返回，可能是有事件返回，如果是前两种情况跳转到Done处。
如果有事件发生，会判断事件是否是mWakeEventFd（唤醒的时候写入的文件）做不同处理。在Done处会处理Native事件，还有Response。
总结一下就是，Java层的阻塞是通过native层的epoll监听文件描述符的写入事件来实现的。
最后看一下nativeWake：

static void android_os_MessageQueue_nativeWake(JNIEnv* env, jclass clazz, jlong ptr) {
NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
nativeMessageQueue->wake();
}
和之前一样，也是通过long类型的ptr获取NativeMessageQueue对象的指针，再调用wake方法：

void NativeMessageQueue::wake() {
mLooper->wake();
}
调用的也是Looper的方法：

void Looper::wake() {
uint64_t inc = 1;
ssize_t nWrite = TEMP_FAILURE_RETRY(write(mWakeEventFd, &inc, sizeof(uint64_t)));
if (nWrite != sizeof(uint64_t)) {
if (errno != EAGAIN) {
ALOGW("Could not write wake signal: %s", strerror(errno));
}
}
}
重点是write(mWakeEventFd, &inc, sizeof(uint64_t)),写入了一个1，这个时候epoll就能监听到事件，也就被唤醒了。

本文是对Google官方文档 Reduce APK Size 的翻译，点击“阅读原文”可以查看英文原文。

译者简介：damonxia(夏正冬)，天天P图Android工程师

用户经常会避免下载看起来体积较大的应用，特别是在不稳定的2G、3G网络或者在以字节付费的网络。这篇文章描述了怎样减少你的APK大小，这会让更多的用户愿意下载你的应用。

理解APK的结构

在讨论怎样减少应用大小之前，先了解APK的结构是有用的。一个APK文件就是ZIP包，其中包含了组成你的应用的所有文件，比如Java类文件，资源文件，和一个包含被编译资源的文件。

一个APK包含了以下目录：

• META-INF/: 包含CERT.SF和CERT.RSA签名文件，也包含了MANIFEST.MF文件。（译注：校验这个APK是否被人改动过）
• assets/: 包含了应用的资源，这些资源能够通过AssetManager对象获得。
• res/: 包含了没被被编译到resources.arsc的资源。
• lib/: 包含了针对处理器层面的被编译的代码。这个目录针对每个平台类型都有一个子目录，比如armeabi, armeabi-v7a, arm64-v8a, x86, x86_64和mips。

一个APK也包含了以下文件，其中只有AndroidManifest.xml是强制的：

• resources.arsc: 包含了被编译的资源。该文件包含了 res/values目录的所有配置的XML内容。打包工具将XML内容编译成二进制形式并压缩。这些内容包含了语言字符串和styles，还包含了那些内容虽然不直接存储在resources.arsc文件中，但是给定了该内容的路径，比如布局文件和图片。
• classes.dex: 包含了能被Dalvik/Art虚拟机理解的DEX文件格式的类。
• AndroidManifest.xml: 包含了主要的Android配置文件。这个文件列出了应用名称、版本、访问权限、引用的库文件。该文件使用二进制XML格式存储。（译注：该文件还能看到应用的minSdkVersion, targetSdkVersion等信息）

译注：使用APK Analyzer能够清晰地看出以上文件的内容，具体请看：使用APK Analyzer分析你的APK。

减少资源个数和尺寸

APK的大小会影响应用加载的速度，使用的内存大小，消耗的电量大小。一个最简单的缩小APK大小的方式是减少资源的个数和大小。特别地，你能移除应用中不再使用的资源，你也能使用可缩放的Drawable对象代替图片文件。这节讨论一些通过减少资源从而减少APK大小的方法。

译注：减少资源个数和缩小资源大小的效果是很显著的，比如有一天发现我组里的项目中还包含了旧版本的引导页视频（1.5M），一下就就减少了1.5M，想想为了减少1.5M你得删多少代码才能办到。

移除不使用的资源

lint是Android Studio中的一个静态代码分析工具，检测在“res/”目录中你的代码没有引用的资源。当lint工具发现了项目中潜在的未使用的资源，它会打印以下类似信息：

res/layout/preferences.xml: Warning: The resource R.layout.preferences appears to be unused [UnusedResources]

注意：lint工具不会扫描“asset/”目录，这个目录是通过反射引用的资源，或者链接到应用中的库文件。还有，lint不会移除资源，只会发出警告。

被引用的库中可能会包含没使用的资源。如果你在build.gradle文件中启用shrinkResources，则Gradle能自动移除这些资源。

为了使用shrinkResources，你必须要启用代码混淆。在构建过程中，首先proguard移除了未使用的代码，然后gradle移除未使用的资源。

译注：lint工具还能够检查出未使用的类、类中未使用的方法或变量。

更多关于通过代码混淆和其他方式减包，请看Shrink Your Code and Resources。

在Gradle插件0.7或更高版本，你能申明应用支持的配置。Gradle通过传递resConfigs和defaultConfig给构建系统，构建系统会防止不支持的配置出现在APK中，从而减少APK大小。更多信息请看Remove unused alternative resources。

译注：在hello world工程里，resConfigs配置为“zh”和不配置resConfigs，resources.arsc文件相差了80K。

最小化第三方库中资源的使用

当开发Android应用时，你经常使用第三方库提升应用的可用性和灵活性。比如，你引用Android Support Library提升旧设备的用户体验，或者使用Google Play服务实现文字自动翻译。

如果一个第三方库原本是为服务器或普通电脑设计，会引入许多不需要的对象和方法。为了只引入应用需要的库中的那部分，你可以编辑库文件（如果库的license允许你这么做）。你也能使用另外的针对手机的实现同样功能的库。

注意：代码混淆能清除库中不被使用的代码，但是他不能移除库的大量内部依赖。

只支持部分屏幕密度

Android支持很多设备集，其中包含了各种不同的屏幕密度。在Android 4.4及更高版本，框架支持不同的密度：ldpi, mdpi, tvdpi, hdpi, xhdpi, xxhdpi和xxxhdpi。尽管Android支持所有这些屏幕密度，但你不需要为每个密度都配置相应的资源。

如果你知道某种特定屏幕密度已经很少有用户使用了，那么你可以考虑是否需要为这个屏幕密度配置资源。如果你不包含针对特定屏幕密度的资源，那么Android会自动缩放原本针对其他密度的已有资源。

如果你的应用只需要缩放的图片，你甚至可以把图片存放在drawable-nodpi目录，从而节省更多空间。我们推荐每个应用都应该至少包含xxhdpi的图片。

更多关于屏幕密度的信息，请看Screen Sizes and Densities。

减少动画帧数

使用帧动画会大大增加APK的大小。图1显示了目录中构成帧动画的多个PNG文件。每个图片都是动画的一帧。

对于加入动画的每帧，你都增加了APK中图片的个数。图1中，帧动画的帧率是30 FPS。如果帧率降到15 FPS，图片数量将减少一半。

图1：帧动画的每一帧图片。

译注：还有一个常见的减包方案是删除帧动画中重复的图片资源，比如第1帧和第3帧的图片一样，那么只保留一个。

使用Drawable对象

一些图片不需要静态的图片资源，框架能在运行时动态地绘制图像。Drawable对象（XML的）只需要占用APK中的一点空间。另外，XML形式的Drawable对象能够产生遵循Material Design设计规范的图像。

重用资源

你能包含一张图片的很多变种，比如染色、阴影、旋转的版本。但是，我们推荐在运行时复用一张图片来定制化他们。

Android提供了很多方式改变资源的颜色。对于Android 5.0及以上，使用android:tint和tintMode属性。对于更低版本，使用ColorFilter类。

你也能够删除那些只是对另一个资源做旋转的资源。下面的代码片段提供了对一个箭头旋转180度。

<?xml version="1.0" encoding="utf-8"?><rotate xmlns:android="http://schemas.android.com/apk/res/android"
    android:drawable="@drawable/ic_arrow_expand"
    android:fromDegrees="180"
    android:pivotX="50%"
    android:pivotY="50%"
    android:toDegrees="180" />

通过代码绘制

你也能通过代码绘制图像，从而减少APK大小。代码方式绘制图像不需要任何空间因为你不再需要在APK中存储图像文件。

压缩PNG文件

AAPT工具能够在构建过程中通过无损压缩优化res/drawable/中的图片资源。比如aapt工具能将需要颜色少于256色的PNG变为8位PNG图，这样能够在保证图片质量的同时减少内存使用。

需要注意aapt有以下局限性：

• aapt工具不会压缩asset目录的PNG文件。
• 通过aapt的优化，图片文件会使用少于256色。
• aapt工具可能会影响已经被压缩过的PNG文件。为了防止这种情况，你可以在gradle文件中设置cruncherEnabled为false禁用aapt对PNG的压缩。

aaptOptions {
    cruncherEnabled = false
}

译注：建议把cruncherEnabled设为false，然后通过tinypng手工压缩PNG图片。

压缩PNG和JPEG文件

你能使用一些工具（比如pngcrush, pngquant, zopflipng）在不降低图像质量的前提下减少PNG文件大小。所有这些工具都能保留图像质量的情况下减少PNG文件大小。

pngcrush工具特别有效：这个工具通过迭代png过滤器和zlib参数，使用每种过滤器和参数的组合压缩图像，并选择最小的那个作为最后的输出。

对于JPEG文件，能使用packJPG压缩JPEG文件。

译注：guetzli是Google最近推出的JPEG编码器，官方宣称相同图片质量时，比libjpeg生成的图片小20–30%。

使用WebP文件格式

你也能使用WebP文件格式存储图片而不是PNG或者JPEG。WebP格式是有损压缩（像JPEG）且有透明通道（像PNG），且压缩率高于JPEG或PNG。

使用WebP文件格式也有一些缺点。第一，低于Android 3.2的版本不支持WebP，第二，WebP的解码时间比PNG长。

注意：Google Play的APK的应用启动图标只能使用PNG格式，而不支持其他格式。

在Android Studio中，能将BMP，JPG,PNG或者静态GIF图片转换成WebP格式。更多信息，请看Create WebP Images Using Android Studio。

使用向量图

你能使用向量图去创建一个分辨率无关的图标。使用向量图能够显著减少APK大小。在Android中向量图是以VectorDrawable对象形式存在的。使用VectorDrawable对象，一个100B的文件能生成一个屏幕大小的清晰图片。

但是，系统需要很长时间渲染VectorDrawable对象，更大的图片需要更长的时间显示在屏幕上。因此只有小图片才考虑使用向量图。

更多关于VectorDrawable对象的信息，请看Working with Drawables。

减少Native和Java代码

有许多方法能够减少Java和Native的代码量。

减少不必要的生成代码

确保理解任何自动生成的代码。比如，许多protocol buffer工具生成了过多的方法和类，这会让你的应用大小翻倍。

移除枚举

一个枚举能让classes.dex文件增加1–1.4K。枚举的加入会快速增加应用体积。我们可以使用@IntDef注解和Proguard代替枚举，它能提供和枚举一样的类型安全转换。

减少Native库的大小

如果你的应用使用了Native代码和Android NDK，你也能通过优化代码减少应用体积，这里介绍的两个技巧是删除调试符号和避免抽取Native库。

移除调试符号

如果应用在开发中并且仍需要调试，那么我们能理解使用调试符号。使用Android NDK提供的arm-eabi-strip工具，能从Native库中删除不必要的调试符号，之后你再编译release包。

避免抽取Native库

在APK中存储未压缩的so文件，并且在Manifest文件的中设置android:extractNativeLibs为false，这会防止在安装时PackageManager将APK中的so文件拷贝到文件系统，避免这种拷贝会让应用在做增量更新时的更新包更小。

维持多个小的APK包

你的APK会包含用户下载了但从未使用的内容，比如地区或语言信息（译注：比如我是中国人，我就不会用到其他语种的资源）。为了给用户创建小的下载包，你能把你的应用拆分成多个APK，这些APK的差别在于一些因素（比如屏幕大小或者GPU纹理支持）。

当一个用户下载了应用，设备根据自身的特性和设置获取正确的APK。这种方式能够让设备不获取设备不需要的资源。比如，如果设备是hdpi的，那么他就不需要xxxhdpi的资源。

更多信息请看Configure APK Splits和Maintaining Multiple APKs。

更多精彩内容欢迎关注 腾讯 Bugly的微信公众账号：

腾讯 Bugly是一款专为移动开发者打造的质量监控工具，帮助开发者快速，便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash根据根因合并分类，每日日报会列出影响用户数最多的崩溃，精准定位功能帮助开发同学定位到出问题的代码行，实时上报可以在发布后快速的了解应用的质量情况，适配最新的 iOS, Android 官方操作系统，鹅厂的工程师都在使用，快来加入我们吧！

Yeoman是Google的团队和外部贡献者团队合作开发的，他的目标是通过Grunt（一个用于开发任务自动化的命令行工具）和Bower（一个HTML、CSS、Javascript和图片等前端资源的包管理器）的包装为开发者创建一个易用的工作流。

Yeoman的目的不仅是要为新项目建立工作流，同时还是为了解决前端开发所面临的诸多严重问题，例如零散的依赖关系。

Yeoman主要有三部分组成：yo（脚手架工具）、grunt（构建工具）、bower（包管理器）。这三个工具是分别独立开发的，但是需要配合使用，来实现我们高效的工作流模式。

下面这幅图很形象的表明了他们三者之间的协作关系。

YOMAN的特性

闪电般的初始化：项目开始阶段，可以基于现有的模板框架（例如：HTML5 Bolierplate、Twitter Bootstrap）进行项目初始化的快速构建。

了不起的构建流程：不仅仅包括JS、CSS代码的压缩、合并，还可以对图片和HTML文件进行优化，同时对CoffeScript和Compass的文件进行编译。

自动编译CoffeScript和Compass：通过LiveReload进程可以对源文件发生的改动自动编译，完成后刷新浏览器。

自动Lint代码：对于JS代码会自动进行JSLint测试，确保代码符合最佳编程实践。

内置的预览服务器：不再需要自己配置服务器了，使用内置的就可以快速预览。

惊人的图片优化：通过使用OptiPNG和JPEGTran来优化图片，减少下载损耗。

杀手级包管理：通过bower search jQuery，可以快速安装和更新相关的文件，不再需要打开浏览器自己搜索了。

PhantomJS单元测试：可以非常方便的使用PhantomJS进行单元测试，一切在项目初始的时候都准备好了。

安装前的准备工作

检查系统中是否安装了：Node.js、Ruby、Compass。

Mac下安装Node.js非常方便，首页提供了一个pkg下载，双击后可以默认安装node、npm到/usr/local/bin下，我们只需要确保/usr/local/bin包含在PATH变量中就可以。

Mac Mountain Lion 下自带了Ruby，所以也就不需要再单独安装了。

Compass安装需要依赖于Ruby Gems，执行下面的步骤：

sudo gem update --system

sudo gem install compass

安装

环境准备好之后，就可以进行安装了，执行：

sudo npm install -g yo grunt-cli bower

安装成功后，会看到下面的提示：

使用

执行 yo webapp 我们就可以快速的创建一个新的Web应用的框架，一个通常的工作流程如下：

项目实践

本篇以一个实际项目为例，通过Yeoman来构建一个简单的Blog页面：

环境准备好之后，我们开始自己的项目开发了，首先为自己的项目准备一个目录，我这里是: rivertown.sinaapp.com。

然后第一步，使用 yo 进行快速的初始化，初始化时会询问我们是否使用Bootstrap和RequireJS框架，我这里都选择了是。完成后一个Web应用的基础框架就建立好了。

初始化的WebApp目录结构如下，app目录是我们项目的主目录，test目录中对应的一些JS的单元测试文件。

注意我们需要安装黄色字体的提示，将npm和bower安装到项目本地。

修改页面文件以及样式。

对页面进行预览和测试。当代码编辑到一定程度，我们就需要对页面进行测试了，这个时候需要Grunt派上用场，执行下面的命令：

很快，浏览器中就可以看到我们的页面了。

更神奇的是，一旦我们编辑了项目源文件之后，切换到Safari窗口，就马上能够看到修改所带来的变化，根本不用手工刷新页面！

如果我们想对JS进行测试，那么必须利用npm将PhantomJS安装到本地，然后执行grunt test。

最后的步骤就是编译生成项目了，执行 grunt 就可以将项目编译生成在 dist 目录下，有可能生成的时候会提示 phantomjs 没有的错误，这个时候执行 grunt --force 强制跳过这一步就可以了。

查看具体的main.css和main.js中的内容，可以发现里面的内容都是经过优化之后的。

使用体验

经过一下午的试用，第一对于有这么一个集成化的构建、开发、编译流程，感觉非常新奇，相比于传统的开发方式。我需要首先确定用哪些框架，然后各个网站收集源代码，进行整合，还要部署一个测试的Web服务器，不管是用（Apache、Nginx还是Xampp），最后还要做代码的优化。而现在使用了Yeoman之后，所有的这些工作都被自动化、流程化了，我只需要按照既定的步骤来做，很多事情Yeoman都帮我做好了，对于前端开发来说，节省了非常多的力气。而且，生成项目的代码质量也都很不错。

遗憾的地方在于目前Yeoman的相关资料还比较少，中文的资料也非常少，对于如何深入的学习和定制化，还需要继续的钻研。

PS：吐槽一下百度，不得不说对于IT工作者来说，百度真的不是一个好的选择，输入Yeoman，除了Infoq的两篇介绍性的内容，其他的内容几乎与我需要的都相隔万里，也许是国内关注Yeoman太少的原因，但愿如此。

如今大多企业员工几乎每天都需要用到移动端的某些应用来完成相关工作，但是一旦恶意攻击者盯上了你手机上的某个应用，那么设备遭受攻击所带来的影响可能就是连锁式的。

一、五大危害企业的移动端威胁

Lookout产品总监David Richardson和他的团队研究总结出五大移动端恶意软件家族，冒充真正的企业应用，引诱员工下载恶意软件。研究显示，这五个活跃的移动恶意软件家族通常通过窃取合法应用的名称和包名称来模拟一些企业应用，例如思科的商务电子邮件应用、ADP、Dropbox、FedEx Mobile、Zendesk、VMware的Horizon Client、Blackboard的Mobile Learn等等。

1. Shuanet

Shuanet能够将其自身自动安装在设备的系统分区上，获得设备root权限，达到进一步安装其它应用的目的。这些应用程序可能是恶意的也可能是良性的，推送至手机，提高恶意软件的下载几率。Shuanet可能也会向设备推送各种小广告。

企业将面临的风险

被root设备的安全状态已经发生改变。很多人会利用root权限对设备进行自定义设置，但是他们往往都不会去做安全性的合理配置，可能也不会进行定期的软件更新。另外，Shuanet这样的恶意软件会在系统分区中自动安装，即使恢复出厂设置也难以去除。最后，安装应用的恶意软件可能会将更多的恶意应用程序植入该设备，使设备及数据暴露在更高的风险中。

受害应用程序举例：ADP Mobile Solutions、CamCard Free、Cisco Business Class Email（BCE）、Duo Mobile、Google Authenticator、VMWare Horizon Client、Zendesk、Okta Verify。

2. AndroRAT

AndroRAT开发初衷是完成一个大学研究项目——创建一个“远程管理工具”，允许第三方控制某设备并从麦克风收集联系人、通话记录、短信、设备位置和音频等信息。但是该工具目前被一些不法份子恶意利用。

企业将面临的风险

隐藏的远程访问软件能够帮助攻击者轻易地从移动设备获取到企业和个人的数据。另外，对某个移动设备的持续性远程访问也会帮助攻击者对感染设备所连接的公司Wi-Fi和VPN展开入侵行动。

受害应用程序 举例：Dropbox、Skype、Business Calendar

3. UnsafeControl

UnsafeControl能够收集联系信息并将其下载到第三方服务器，还能够对联系人列表发送垃圾邮件或向其命令和控制（CNC）服务器指定的电话号码发送短信。消息内容也由CNC控制。

企业将面临的风险

像UnsafeControl这样的恶意软件能够窃取联系人信息，这对很多企业来说都属于敏感信息。比如，销售总裁或副总设备上的联系人信息就是一个公司极大的竞争优势与虚拟财富。

受害应用程序 举例：FedEx Mobile、Google Keep、远程VNC Pro、Sky Drive、PocketCloud、Skype

4. PJApps

PJApps可能会收集并泄露受害者的电话号码、移动设备的唯一标识符（IMEI）及位置。为了扩大非法盈利范围，它也可能会向一些优质的短信号码发送钓鱼信息。另外， PJApps也能够进一步下载应用程序到相应设备。

企业将面临的风险

像PJApps这样的恶意软件通常利用其功能来获取收益，但同时也具有一定技术相关性，例如手机位置信息带来的威胁，尤其是针对高管们的移动设备。这些信息可能关乎企业的商业计划。该恶意软件将其它应用程序下载至设备的功能其实也为新型恶意软件进入设备提供了通关密语。

受害应用程序 举例：CamScanner

5. Ooqqxx

Ooqqxx实际是一个广告网络，将广告推送至通知栏，发送弹窗广告，在主屏幕上创建快捷方式，未经许可下载大型文件。

企业将面临的风险

这些广告会往往会打断员工的正常工作，员工因此可能也会向IT部门提出改进意见，这些行为都在一定程度上影响了公司员工的工作效率。Time is money！

受害应用程序 举例：Mobile从Blackboard、Evernote、PocketCloud、Remote Decktop、Adobe Reader、aCalendar

二、从开发者角度谈移动端威胁的安全防御措施

每个人的手机、iPad等智能设备上大概都有26-55个应用程序，通常包括以下这些类型：娱乐和游戏、银行app、一些社交媒体app、瘦身塑形的软件以及网购应用等。

如果只是普通的游戏软件遭到攻击，你也许不会在意。但事实上，很多应用其实都收集了很多你不想让别人看到的个人信息，比如你的位置、银行卡信息和某些照片。

从开发的角度来看，你必须通过某些协议确保应用程序的代码不被黑客入侵。Codal首席执行官Keval Baxi主要从开发者的角度给出了一些保护手机应用安全的干货建议。

1. 使用基于令牌的身份验证方式访问API

很多移动应用程序都没有设计恰当的身份验证方法，这种行为的本质其实就是数据泄露。“令牌”是指一些本身不带任何意义的数据，但令牌系统准确率高，它是保护移动端应用程序的关键方式。基于令牌的身份验证需要验证每个向服务器发送的API请求的真实性，只有通过验证程序才会对请求作出响应。

2. 使用Android KeyChain和iCloud Keychain存储敏感信息

移动设备上的keychain是一个安全的存储容器，能够保存所有应用程序的登录名、用户名和密码等数据。建议开发人员充分利用操作系统的这一功能进行数据存储，而不是通过p-list文件或NSUserDefaults来存储。使用keychain功能也可以为用户带来便利，不需要每次登录都输入用户名密码。

3. 在本地数据库中保存用户数据时对数据进行加密

加密是将数据和明文转换为“密码”的过程，也就是密文。要想读取密文就必须经过解密或使用密钥的过程，因此加密数据保护最有效的方法之一。

4. 登录应用程序时选择指纹锁而不是用户名和密码

苹果公司研究人员表示，指纹匹配的概率是1：50000，而四位数密码的匹配概率是1：10000。因此指纹登录比使用传统密码的方式更加安全。指纹是每个用户独特的生命体征，而密码不是。在iOS版本8之前，苹果公司为开发人员开通了Touch ID的权限，API能够在SDK（软件开发工具包）中使用。

5. 可疑活动的实时通知

当用户在新的设备或新的未知位置登录某应用程序时，可以通过电子邮件或推送通知向用户发送登录异常的消息，完成验证过程。很少会有应用程序达到这一要求，而Gmail是其中之一。登录验证通知能够让用户获知他的账户是否遭到了非法入侵。

6. 始终使用https（SSL）

将SSL安装到服务器后，开发人员就能够使用HTTPS协议，该协议安全性高，有助于防止入侵者干扰应用程序及其服务器之间的数据传输。

7. 提防逆向工程

开发人员对应用程序进行逆向工程、把数据和源代码移走也不是不可能发生的事。为了防止这种情况的出现，你可以通过更改预处理器中重要类别和方法的名称来迷惑黑客。第二个办法则是在项目完成后对符号表进行拆分。

*参考来源： CSO、 CSO2，FB小编Carrie编译，转载请注明来自FreeBuf（FreeBuf.COM）

Spring boot executable jar/war

spring boot里其实不仅可以直接以 Java -jar demo.jar的方式启动，还可以把jar/war变为一个可以执行的脚本来启动，比如./demo.jar。

把这个executable jar/war 链接到/etc/init.d下面，还可以变为Linux下的一个service。

只要在spring boot maven plugin里配置：

<plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><configuration><executable>true</executable></configuration></plugin>

这样子打包出来的jar/war就是可执行的。更多详细的内容可以参考官方的文档。

http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#deployment-install

zip 格式里的 magic number

生成的jar/war实际上是一个zip格式的文件，这个zip格式文件为什么可以在shell下面直接执行？

研究了下zip文件的格式。zip文件是由entry组成的，而每一个entry开头都有一个4个字节的magic number：

Local file header signature = 0x04034b50 (read as a little-endian number)

即 PK\003\004

参考：https://en.wikipedia.org/wiki/Zip_(file_format)

zip处理软件是读取到magic number才开始处理。所以在linux/unix下面，可以把一个bash文件直接写在一个zip文件的开头，这样子会被认为是一个bash script。 而zip处理软件在读取这个文件时，仍然可以正确地处理。

比如spring boot生成的executable jar/war，的开头是：

#!/bin/bash
#
# . ____ _ __ _ _
# /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
# ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
# \\/ ___)| |_)| | | | | || (_| | ) ) ) )
# ' |____| .__|_| |_|_| |_\__, | / / / /
# =========|_|==============|___/=/_/_/_/
# :: Spring Boot Startup Script ::
#

在script内容结尾，可以看到zip entry的magic number:

exit 0
PK^C^D

spring boot 的 launch.script

实际上spring boot maven plugin是把下面这个script打包到fat jar的最前面部分。

https://github.com/spring-projects/spring-boot/blob/1ca9cdabf71f3f972a9c1fdbfe9a9f5fda561287/spring-boot-tools/spring-boot-loader-tools/src/main/resources/org/springframework/boot/loader/tools/launch.script

这个launch.script 支持很多变量设置。还可以自动识别是处于auto还是service不同mode中。

所谓的auto mode就是指直接运行jar/war：

./demo.jar

而service mode则是由操作系统在启动service的情况：

service demo start/stop/restart/status

所以fat jar可以直接在普通的命令行里执行，./xxx.jar 或者link到/etc/init.d/下，变为一个service。

相关文章

• spring boot executable jar/war 原理
• spring boot应用启动原理分析
• 5种调优Java NIO和NIO.2的方式
• Java垃圾回收精粹 — Part2
• Java常见内存溢出异常分析
• 2014最热门、最具争议的10个Java话题
• 用Java生成字符画（2）
• 在什么情况下Java比C++快？
• 缓存穿透、缓存并发、缓存失效之思路变迁
• Java并发编程（22）：并发新特性—障碍器CyclicBarrier（含代码）

      之前接触过这方面的知识，一直想写一些关于代码的文字，但考虑到浪费时间，又不具备大神的实力，也不想去把别人的代码照搬过来，所以一直都是空白着的，今天敲代码的时候，有了一个比较好的想法，第一，定位在学习这一块，去学习一些领域的新知识，并分享自己每天的学习成果，第二，总结工作中遇到的代码，解决的问题，拿出自己的demo截图，做出一些文字说明解释，相信通过这两个途径，能够让自己取得更大的发展空间。

h5调用本地摄像头

     前端时间使用HTML5做了一个WEB端APP，其中用到了H5页面调用手机摄像头的功能，当时也是花了不少时间去研究。最终是采用了HTML5plus（HTML5+）的方式完成了该功能，现将具体方法简单介绍下，并讲解下使用的注意事项。放在服务器上然后浏览就可以了，只支持Chrome和Safari核的浏览器，QQ浏览器，Chrome，Safari浏览器都可以。在不同的手机和浏览器上面展现的方式不一样。这是html5官方文档地址，里面有关于h5或js调用摄像头的全部方法 http://www.html5plus.org/doc/zh_cn/camera.html    

    本篇文章是个人学习期间整理的文档，涉及到很多方面的链接，在Android开发过程中，有时需要调用手机自身设备的功能，本文侧重摄像头拍照功能的调用。使用权限：调用手机自身设备功能（摄像头拍照功能），应该确保已经在AndroidManifest.xml中正确声明了对摄像头的使用及其它相关的feature。安卓调用手机拍照功能： http://blog.csdn.net/mahoking/article/details/28225907；对一些class类的介绍是非常详细的。

h5调用微信支付

   用户通过微信外浏览器打开商品页面,进行 微信支付购买商品… 第三方手机浏览器 H5支付浏览器打开的移动网页的主页，通常是由后端人员来实现，在混合式开发之中，则是由前端人员来掉开发的接口，移动端手机支付功能体现在前端页面上逐渐成为一个趋势，h5微信开发调用支付接口文档： https://pay.weixin.qq.com/wiki/doc/api/H5.php?chapter=4_2 

    看到这样的一个问题：手机系统自带的浏览器，调用微信支付如何实现（非扫码），翻看了微信支付的api没发现支持h5调支付接口的情况（微信js除外），然后却发现美团的支付成功调用了，这是怎么实现的？H5支付用于非微信浏览器，在IOS上仍体验不佳，具体来讲就是无法自动回调。微信浏览器内的H5支付指公众号支付，微信已将此严格区分;首先要参见官方文档：https://pay.weixin.qq.com/wiki/doc/api/wap.php?chapter=15_1

       刚开始做的时候，需要配置一些东西，当然这都是一些最基本的东西;需要搭建环境来进行测试看到一篇这样的文章，博主对此总结了一些实质性的经验，学习起来事半功倍； 微信支付配置信息，JSAPI接口，H5调用微信js接口支付，微信公众号支付：http://blog.csdn.net/u010248119/article/details/50638529

      对于微信支付如何绕过应用签名这个问题；如果把微信支付的API封装起来导出JAR包给多个应用使用，怎么绕过这个应用签名，如果绕不过，那岂不是每个应用我都要建个APP了吗？题主提到的需求有两种方案： https://www.zhihu.com/question/46841202 

h5网页中使用打电话功能

    如果需要在移动浏览器中实现拨打电话，发送email，调用sns等功能，jquery mobile提供的接口是一个好办法。 采用url链接的方式，实现在safari ios，android 浏览器，webos 浏览器，塞班浏览器，ie，operamini等主流浏览器，进行拨打电话功能。在做一个微信的微网站中的一个便民服务电话功能的应用，用到移动web页面中列出的电话号码，点击需要实现调用通讯录，网页一键拨号的拨打电话功能。微信开发之移动手机WEB页面(HTML5)Javascript实现一键拨号及短信发送功能: http://www.cnblogs.com/skylaugh/p/3277899.html ;一句话总结html5中页面拨打电话的方式.

      在开发过程中，我们难免会遇到这种情况：H5跳转链接，拨号怎么做？在制作H5的过程中，很多时候需要用到事件功能，比如（链接跳转、拨号、翻页等），这里为大家介绍H5中常用的事件设置方式。 http://blog.sina.com.cn/s/blog_12d5cc7a50102wpzb.html 

h5调用扫一扫的功能

    使用H5调用手机摄像头扫描二维码。可以通过微信接口调用，直接用H5调用没弄过，很多人说兼容性不好，很多人觉得尽量集成的微信里面做 ，微信本身就提供了 扫一扫的js ，直接自己在浏览器里h5 做扫一扫 是没必要 的因为没应用场景，在网上看了一位技术大牛亲测有效的案例:web/html5调用摄像头实现二维码扫描,需要有后端代码的支持:http://blog.csdn.net/xuewufeifang/article/details/49756099

        这是一片以讲解的方式，帮助大家来理解微信官方的文档，同时给出调用扫一扫的例子。微信调用jssdk在网页端实现调用扫一扫，java+jsp； http://blog.csdn.net/u011327333/article/details/50439462 ;微信官方技术文档jssdk： http://mp.weixin.qq.com/wiki/7/aaa137b55fb2e0456bf8dd9148dd613f.html 

HTML5网页如何调用浏览器APP的微信分享功能？

    最近有看到新浪的移动端网页，增加了微信分享功能。在浏览器APP（Safari除外）中可以直接调用微信APP，分享至朋友圈或者聊天窗口。并不像很多网站是通过弹出一个图片提示右上角分享。并不是通过微信接口实现的，而是直接调用了浏览器APP自带的微信分享功能。比如我用安卓手机自带webkit内核浏览器（原生浏览器没有微信分享功能），打开新浪文章页，就不会出现这个微信分享的功能按钮。那么,用HTML5写的页面怎么获得微信接口，来实现一键分享的功能?废话就不多说了，直接上代码： HTML5网页如何调用浏览器APP的微信分享功能:http://blog.csdn.net/web_qdkf/article/details/50442938

        其实在移动端html5手机网站调用微信分享包括 ：获取网络类型。调起客户端的图片播放组件。调用微信扫描二维码。判断是否安装对应的应用。发送邮件。分享到微信朋友圈。内容很多，我随意摘取几个，你们感受一下：

        获取“分享给朋友”按钮点击状态及自定义分享内容接口。

       获取“分享到腾讯微博”按钮点击状态及自定义分享内容接口。

别说话，快去手机百度关注199IT百家号

不知道从什么时候开始，国内不少手机厂商或电视厂商就鼓吹着硬件免费，服务收费的模式。当然硬件也并非真的免费，其实也就是把价格打的很低，接近毛利为0甚至亏损一点点进行销售。硬件免费，服务收费这个模式的核心套路是用更低的硬件价格去获取海量的用户，然后通过其上面的互联网服务收费。以手机为例，在用较低的价格获取较高的用户后，一般是通过应用商店，自营APP吸引用户使用，从而通过游戏分成，广告等方式实现服务的收费。

国内企业中，小米和乐视是硬件免费，服务收费最为激进的实践者，正是对后向服务收费的信心，小米把手机价格打的很低，一度获取极高的市场份额；乐视在智能电视上也是非常激进，以至于落得个大亏损。

也许他们是时候向苹果好好学习了。

苹果是硬件和服务两手抓，两手收费

以2Q17苹果的财报收入来看，苹果一共赚了529亿美元，其中硬件收入为458.6亿美元，服务收入为70.4亿美元，其规模的确非常惊人。

​
苹果硬件和服务双丰收并不是靠硬件杀价赢来的。苹果整体的毛利水平接近40%，净利率为21%。说明苹果既能在硬件上赚到钱，也能在服务上赚到钱，核心秘籍是产品好，自带光环，无需杀价。

苹果服务营收规模虽大，但对占比也才刚过10%

苹果一个季度的服务营收就赚到了70多亿美元，相比之下，腾讯去年4季度的营收也才63.6亿美元。苹果靠iOS应用商店，苹果音乐，iCloud等服务的营收就超过了腾讯的规模。

国内前面强调硬件低价免费，重点放在服务收费的企业把自己的品牌拉低不说，对后向服务收费的迷恋也搞得一地鸡毛，用户颇为不满。以某手机厂商在手机和智能电视上过分强调广告变现为例，就已经引发诸多的用户不良反馈和负面。不少所谓买了低价机器的用户一定头痛不已，不知道他们是否已经认识到世上并没有免费的午餐，即便是羊毛出在猪身上，猪也要把你给强奸回来。

而对于国内的互联网硬件厂商而言，重视用户体验和产品品质的苹果才是他们应该效仿的，不管是产品品质还是产品+服务两条腿一起跑的商业模式。

您可能也喜欢的文章：
腾讯：开放平台开发者分成超过20亿	2012年第三季度腾讯和Facebook收入结构对比	腾讯：2016年VR行业生态及风险研究报告	财报显示腾讯越来越像一家游戏公司	Newzoo：2014年科技公司在中国收入排名 苹果营收是腾讯的三倍
无觅

其实问巴菲特如何做尽职调查已经是一件老生常谈的事情了，今天巴菲特的股东大会已经有不下三次回答这个问题。

根据巴菲特自己所说，他的尽职调查主要分为两个部分吧。

第一个部分，他们在投资或者收购一家公司之前，会列出一个清单，然后把需要了解的点都记录在上面，再根据情况去弄明白。

第二个部分，巴菲特认为，他投资的公司或者收购的公司，花了很高的薪水去聘请哪些管理公司的人才，那么就必须对这些人才了解清楚，也就是说，巴菲特的尽职调查重点还是在对管理层人事上的考察。

根据巴菲特自己说的这两点，其实可以看出巴菲特在了解公司真实情况上，并没有像普通投资者想象的那样锱铢必较的去寻找一个公司的漏洞，然后费劲心力的去判断是否真实。按照巴菲特自己所说，不要把手埋进沙子里，而迷失了对于前方的看法，更重要的是对商业模式、企业盈利前景的判断。

巴菲特在过去，曾经总结过自己大概的11点投资原则，分别是

这个商业模式是否简单可以理解？

是否有一个长期可靠的运营历史

是否有一个良好的长期预期

管理层是否可靠？

管理层能否代表股东的权益？

管理层是否能够抵制股东机构的胁迫？

相较于每股盈利，股权回报率如何？

企业产品的毛利润率如何？

留置的每一现金能否创造至少相同价值的市值

这门生意创造的的价值是什么？

现金流折现后的价格是否合适？

可以看到，投资原则中，将可理解的商业模式，可追溯的历史业绩，业绩可靠的管理层摆在前位，这从很大程度上就已经避免了普通投资者担心的那些有问题的公司，业务可理解，业绩增长，挣钱，然后估值足够便宜，虽然这样的公司在普通市场上很难买到，但是巴菲特也常在市场恐慌的时候出手，而且换手率也很低，根据目前伯克希尔哈撒韦年报显示，公司的持仓都是知名企业：

唯一被现在人比较有说辞的，大概就是IBM了吧，巴菲特在公开场合说过两句，减持IBM的原因之一，在于IBM前进的道路上有很强力的竞争对手，虽然 IBM 做的也很不错，但是这个竞争的环境是他之前没有考虑到的，而这也是尽职调查很难弄明白。

看似无限风光的ofo，背后似乎隐忧重重。

继创始团队被资本架空的消息传出之后，ofo内部贪腐的消息也甚嚣尘上。近日，实名社交平台脉脉上，有ofo前员工爆料称：这个公司从高层到基层，贪腐现象严重。

而另外一个现任员工则侧面证实了这个观点，并表示，一个城市经理可以每月可以贪好几万，就连学校运营都可以贪个几万十几万。

从爆料信息来看，ofo内部贪腐的主要方式有两个——“吃空饷”、“吃回扣”。

“吃空饷”现象集中在线下运营业务领域。据悉，ofo运维团队的招聘主要由区域运营专员负责，修车、摆车师傅都是由运营独立负责招聘和结算工资。 根据拉勾网等招聘网站显示，运营师傅的月薪在4000-6000左右，主要工作内容是996的找车搬车（工时朝九晚九，每周工作6天）。

由于区域经理全权负责招聘和发薪，所以想在这一项上贪污的方式很简单，只需要向上级多上报5-6个修车师傅名额即可，每月就可以多拿两三万的费用，且上级不会追查。如果此现象属实，那么ofo目前如此高的损坏率也不足为奇了。

而“吃回扣”的现象则体现在供应链端。尽管ofo的slogan是“不生产单车、只连接单车”，但CEO戴威在此前的采访中也坦陈，来源于C端共享的自行车占比极低，与供应链合作生产的单车仍占绝对主流。

根据内部爆料称 ，ofo某城市的供应链被架空，在采购上做主的是维修仓库主管，因为供应商是自己的好友，就把十年前的旧胎当做新胎采购回来，并直接进行组装。

对于此爆料，ofo资深副总裁南楠也在其后回应：如果你真是一名有正义感的ofo员工，希望联系我，公司会认真处理你反馈的问题。

但随后，“尤二姐”就立即回应南楠，认为ofo实际的贪腐情况比爆料中更为严峻。“（你）不要觉得这是一个城市或者某个城市（的问题），全国每个城市都是这样。还是应该花心思投入安装智能锁，花那么多钱到人上面，终将一层一层被拿掉。”

而作为竞争对手的摩拜，在线下运维上选择了自营模式。 据业内人士透露，摩拜在北京一地招聘的运维团队规模就在80人左右，找车、挪车的师傅属于临时工，尚不计算在其中。

显然，ofo目前正忙于开城市、铺单车、寻找代言人。然而，如果脉脉平台爆料属实，目前ofo的当务之急显然是补全公司的制度漏洞，通过技术的方式来监控车辆情况。全面安装GPS定位和电子锁应该是第一步。

“共享”单车走到今天，赛道中的每个选手都已经难对资本和用户讲出全新的故事。那么用户体验、现金流运转就显得至关重要。对于ofo来说，“攘外必先安内”，想要维持第一梯队的地位，就得立刻处理那些在平台上“薅羊毛”的自家员工。

下载虎嗅APP，第一时间获取深度独到的商业科技资讯，连接更多创新人群与线下活动

阅读目录

一:间接请求转发(Redirect)
二:直接请求转发(Forward)

用户向服务器发送了一次HTTP请求，该请求可能会经过多个信息资源处理以后才返回给用户，各个信息资源使用请求转发机制相互转发请求，但是用户是感觉不到请求转发的。根据转发方式的不同，可以区分为直接请求转发(Forward)和间接请求转发(Redirect)，那么这两种转发方式有何区别呢？本篇在回答该问题的同时全面的讲解两种请求转发方式的原理和区别。

【出现频率】

☆☆☆☆

【关键考点】

• 请求转发的含义；
• Forward转发请求的原理；
• Redirect转发请求的原理。

【考题分析】

Forward和Redirect代表了两种请求转发方式：直接转发和间接转发。

直接转发方式（Forward），客户端和浏览器只发出一次请求，Servlet、HTML、JSP或其它信息资源，由第二个信息资源响应该请求，在请求对象request中，保存的对象对于每个信息资源是共享的。

间接转发方式（Redirect）实际是两次HTTP请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个URL发出请求，从而达到转发的目的。

举个通俗的例子：

　　直接转发就相当于：“A找B借钱，B说没有，B去找C借，借到借不到都会把消息传递给A”；

　　间接转发就相当于：”A找B借钱，B说没有，让A去找C借”。

下面详细阐述一下两者的原理：

一:间接请求转发(Redirect)

间接转发方式，有时也叫重定向，它一般用于避免用户的非正常访问。例如：用户在没有登录的情况下访问后台资源，Servlet可以将该HTTP请求重定向到登录页面，让用户登录以后再访问。在Servlet中，通过调用response对象的SendRedirect()方法，告诉浏览器重定向访问指定的URL，示例代码如下：　

......
//Servlet中处理get请求的方法
public void doGet(HttpServletRequest request,HttpServletResponse response){
//请求重定向到另外的资源
    response.sendRedirect("资源的URL");
}
........

上图所示的间接转发请求的过程如下：

• 浏览器向Servlet1发出访问请求；
• Servlet1调用sendRedirect()方法，将浏览器重定向到Servlet2；
• 浏览器向servlet2发出请求；
• 最终由Servlet2做出响应。

二:直接请求转发(Forward)

直接转发方式用的更多一些，一般说的请求转发指的就是直接转发方式。Web应用程序大多会有一个控制器。由控制器来控制请求应该转发给那个信息资源。然后由这些信息资源处理请求，处理完以后还可能转发给另外的信息资源来返回给用户，这个过程就是经典的MVC模式。

javax.serlvet.RequestDispatcher接口是请求转发器必须实现的接口，由Web容器为Servlet提供实现该接口的对象，通过调用该接口的forward()方法到达请求转发的目的，示例代码如下：

......
    //Servlet里处理get请求的方法
 public void doGet(HttpServletRequest request , HttpServletResponse response){
     //获取请求转发器对象，该转发器的指向通过getRequestDisPatcher()的参数设置
   RequestDispatcher requestDispatcher =request.getRequestDispatcher("资源的URL");
    //调用forward()方法，转发请求      
   requestDispatcher.forward(request,response);    
}
......

上图所示的直接转发请求的过程如下：

• 浏览器向Servlet1发出访问请求；
• Servlet1调用forward()方法，在服务器端将请求转发给Servlet2；
• 最终由Servlet2做出响应。

技巧：其实，通过浏览器就可以观察到服务器端使用了那种请求转发方式，当单击某一个超链接时，浏览器的地址栏会出现当前请求的地址，如果服务器端响应完成以后，发现地址栏的地址变了，则证明是间接的请求转发。相反，如果地址没有发生变化，则代表的是直接请求转发或者没有转发。

问：直接转发和间接转发的原理及区别是什么？

答：Forward和Redirect代表了两种请求转发方式：直接转发和间接转发。对应到代码里，分别是RequestDispatcher类的forward()方法和HttpServletRequest类的sendRedirect()方法。

对于间接方式，服务器端在响应第一次请求的时候，让浏览器再向另外一个URL发出请求，从而达到转发的目的。它本质上是两次HTTP请求，对应两个request对象。

对于直接方式，客户端浏览器只发出一次请求，Servlet把请求转发给Servlet、HTML、JSP或其它信息资源，由第2个信息资源响应该请求，两个信息资源共享同一个request对象。

相关文章

• 关于Java面试，你应该准备这些知识点
• 面试的角度诠释Java工程师（一）
• 面试的角度诠释Java工程师（二）
• 面试心得与总结—BAT、网易、蘑菇街
• 阿里面试回来，想和Java程序员谈一谈
• 面试总结
• Java类的连接与初始化 (及2013阿里初始化笔试题解析)
• 40个Java集合面试问题和答案
• Spring面试问答Top 25
• Java面试参考指南（二）