界限

阿里影业在"原创与IP相煎何太急"的那番言论配上那个"我不是针对某个人"的表情了.

平心而论,里面的竞争淘汰轮并没有什么太大的偏差.
只是可能字里行间描述不够妥当罢了.

虽然说作为一个文化创意产业,并不是能单纯的从时间人力上堆出质量的,需要讲究天赋和修养.
但跟竞争体系并没有太大的冲突.

毕竟,就像wake up girls里描述的日本偶像产业.
你努力了并不代表就需要为你付出什么.
只要存在比你努力同时更有天赋的,那么没什么理由拒绝接受更好的.

虽然说这样可能在一段时期内,由比较固定的商业化模式.
但长远来看,无论哪个产业,也得在商业化和艺术性上做出一个权衡.

就像当初 叶隐娘 上线造成的赏析纷争一样.
套用和菜头的说法,就是没有这些商业化的成功,哪里能供养出所谓的艺术性.

所以,对于各位编剧们的反应,大抵是一种较为安逸的时代要过去了的最后挣扎反抗吧.
用阿里的话说,就是拥抱变化吧.

另一点是阿里影业关于IP的看法.

IP这个词应该是前几年才开始谈的概念.

其实也不算一个崭新的思路,充其量不过是周边概念的繁华.
本质上有点类似对既有消费群体的消费点做一些类gradient descent的迁移optimization.

具体到中国电影来说,衍生品的聚焦现象也确实存在.
远的诸如 爸爸去哪儿/跑男 之类的综艺到电影,小时代,到稍近一点的琅琊榜的泛娱乐一条线.

抛开影片质量问题,票房上还是说地过去的.
所以,在数据上来说,阿里影业也自然有底气认为剧本并不是一个决定性的影响因素.

而事实上,从消费者的角度来说,也确实可能如此.

就像某些嘲笑直男的段子说的.
去看电影有时候并不不是真地去看电影.
至少不是只是看电影,而是作为一种娱乐候选.

所以就消费结构/行为来说,替换选项很多.
反过来说,促成候选的原因当中,剧情/质量可能只是其中一个决策因素而已.

尤其在现在各种互联网概念横行的当下,部分人选择看电影作为娱乐项目的原因可能只是恰好有补贴/打折.
而这点上,恰恰是作为一个经销平台的阿里所促成影响的.

退一万步来说,如果各互联网公司把电影补贴或者在线购票入口关闭,整个电影行业还能否继续繁荣还是一个问题.

毕竟,行为模式已经被重构,各个决策因素的权重也产生了变化.
选和不选的因素,可能已经不是电影/编剧行业能够左右的了.

某种程度上来说,互联网其实是个挺可怕的行业.

可能在不知不觉中就把其他行业摧毁或者变为其附属.

就影视行业来说.
翻某司财报,电视剧的毛利润在60%-70%左右.
制作大概是4000w左右的投入,100-200人的规模.

考虑如果这4kw是通过娱乐宝或者类似的资金筹集,并锁定一年,之后付10%左右的利息.
算50%的利润,减去10%的利息,还有40%的利差存在.

而传统的制造业也就10%-20%的毛利率.

通过互联网渠道众包筹集差不多就是1200w的空手套白狼的纯利润.

换个角度来说,就传统的电影电视自筹资金的模式来说,可能受实际票房的影响.
而实际票房可能直接有影片质量决定.
所以这个时候各个业务线包括编剧的能力就存在着比较大的价值比重.

但是按互联网的做法,实际上是不承受成本风险的.
所影片质量和实际票房只不过是锦上添花的事情.

利润空间的大小跟实际产品并没有直接关系,而跟筹集面的广度有关.
这也就是为什么阿里影业要强调IP的原因.

作为一个"期货"性质的投资,自然是有一定消费用户基础的东西更容易筹措到资金.
而且通常来说粉丝群的忠诚度还是相对较高的.

从广义上来说,这里的IP其实可以指向任何能够促成交易成立的因素.
而不仅仅是某一个节目品牌或者明星.

比如娱乐包当初就是作为一个比余额宝收益高的品牌"投资品牌"出现.
所以即便说没有合适的具体IP可用,通过互联网的导流思路还是能够解决大部分问题的.

尤其当这种三板斧的行业遇上金融这种专攻杠杆和远期套现的产业,一切可能就更加野蛮和隐蔽了.

某种程度上来说,游戏行业就算是这种结合体的一个超前展现.
用不同的难以让人眼前一亮的模式套上万年不变的变现核心.
尤其一些生命周期模式明显的,只不过在换着不同的方式repeat着.

所以有时候会想,到底是什么原因,让人很难再有那种心动感.

就像一潭死水.
辽阔而单调.

不过也可能只是天花板了.
毕竟,很久以来,确实没有什么新的角度和维度了.
虽然不太想承认.

因为到底,这是很沮丧的认识.
但,大概就是所谓界限问题吧.

人人都可以是产品经理

这两天回老家.
中午吃饭的时候,母亲跟父亲说,
"又不看电视,关了吧"
"这个跟原来的不一样,关了不是马上能开,要等一下"

于是想了想,这里其实有略微妙的变化.

某种程度上来说,现代电视的启动时间作为一个代价项考虑进来的话,改变了某些旧有的决策模式.
从结果上来说,就是增加了某些意义上的在线时间/使用时长.

这跟某些价格策略其实有点相似之处.

本质上来说,是一种压缩效用边际的做法.
只不过"启动时间"是作为一种额外附加的退出成本考虑进来的而已.

用一种简化方式的描述的话,就是
厂商revenue <= 用户utility + premium. 对于厂商来说,maximize revenue的策略自然是尽可能地把效用升水premium接管过来. 即 revenue = baseline + cutted_premium <= utility + premium. ->
baseline = utility + (premium - cutted_premium) = utility + active_premium
其中baseline是提供服务/产品的基础成本,active_premium作为仍可争取的效用溢价.
所以,换个角度,maximum cutted_premium的问题实际上就是minimize active_premium的问题了.

也就是某种形式意义上剩余价值问题.

于是,从压榨的退出成本的角度来说,只要没有达到更换的临界点,那么利润边际就是一直存在的.

也就是说,存在这么一种情况,即即使产品本身并没有任何的改进改善,但只要用户还能容忍,那么就存在着一定的利润增长空间.
而从单纯的定性分析的角度来看的话,存在着一种做改进所带来的ROI不如压榨剩余价值来得高的情况.
就像Braess' paradox,增加节点并不一定能够让网络结构更优.

另一个思路就是.
如果把整个代价决策过程看作一个network structure,或者更直接地,把decision tree当作一个directed acyclic graph考虑的话.
某个成本/支出点的权重变化,带来的就是整个某种shortest path形式的graph结构变动.

所以,如果把开头的案例以另一个角度描述的话.
即,给定一定流量形式的input和一个candidate的revenue output,如果去构建一个系统,使得input和output匹配.

于是,如果假设能考虑到因素都是线性的,或者可线性话的,那么问题的本质就变成简单的neural network的training/regression了.

换个角度,其实就是吧graph的transition pattern以一种近似的压缩方式encode成network的layout matrix了.

反过来说,扩展一点,把deep network的deep借鉴过来的话,其实就是deep graph的概念.
不同层面的平行graph的连接结构之类的,以前大概谈过.

而这个思路的有效也就自然决定于input和output所考虑的维度的覆盖面的问题.

如果考虑的因素无限接近于真实,那么自然拟合能encode的模式信息自然也更多,更容易识别和归类.
反之,便是可能比较具有误导性.

尤其某些系统外未考虑的变量其实更有意义的情况.

比如考虑视频网站的贴片广告.

如果output的index目标是提高使用时长的话,那么策略模型可能提供出一种增加广告时长的做法.
比如一个30s的视频贴上90s的广告,那么这个index的增长率可能突破理论的100%,而达到90s/30s -1 = 200%.

考虑一个稍微复杂一些的情况.

如果把上面的index做个某个deep structure的一部分去做用户价值分类的话,那么由于付费用户没有这种理论外的额外增长率.
所以encode的信息可能是使用市场跟用户价值是negative的.
而在更高层的数据侧面就可能得出短小视频的高价值潜力的结论.

当然,这个只是举例.
具体的decision graph的organize/re-organize是怎样的结果,可能是比较麻烦的数据问题.

当然,抛开具体数据,人人都可以是产品经理.

世界和平

下午吃完饭走回家的路上想到个问题.

现实中像维持一个类似the avengers/天人的非政府反恐/维和组织的可能性有多大呢.

原则上来说,装备水平至少可以和武装组织,佣兵集团上对齐.
也就是技术支持角度来说,应该是至少存在对抗能力的.

然后就是资金渠道.

假设接受各种形式的捐赠/扶持的话,会有什么问题呢?

如果是有代价的资金合约使用,那么必然地就是某种形式的扶植.
这样的话,不管这种资金流向是匿名还是署名的,都多多少少存在一定的倾向性/非中立性.
因为资金的供给会收到出资方的目的性约束.

所以,这种组织如果存在的话,那么必然需要先解决活动的资金性问题.
保证经济上的中立性.

既然不能接受注资的话,那么如何维持运转和开销呢?

考虑到活动的目的是以暴制暴/武装打击.
所以从结果上来说,好的一面是对方失去反抗能力.

而这个能从经济上产生什么效益呢?

由于存在的意义是武力压制,于是职能也仅限于此.
对于战后的恢复重建,以及可能的远期经济收益,这个自然是不在预期内的.

如果参与因压制而带来的分享恢复/重建效益,那么实际上最初的武装干涉就存在一定的直接经济效益考虑.
尽管这可能并不是本意.

但既然存在直接利益产生模式的话,那么就必然存在逐利的风险.

所以资金的来源也不能是直接或者间接的战胜结果所带来.

既然一不能是外界注入,二不能自己产生,那么还有其他方式么?

考虑这笔资金所需要的特质.
中立性,以及必要的持续性和规模.
加上非内生的产生机制,防止规模化/逐利.

一个可能的候选就是某种税制.

持续性和规模不是问题.
中立性也经由人口基数而基本对冲了.
而且税收是一种被动的缴纳/注入机制,现金流能力在一定时期内是可预见/固定的.

可能的问题在于资金管理能力,以及税制的合理性.

前一个问题其实是所有方案/方式的共同点,跟资金来源没有太大的关系.
所以暂且放下.

至于"税制"的合理性就是个比较现实的问题了.

让所有国家,或者说所有人接受这种税收是不现实,也基本是不可能的.
而如果存在非全民投入的税收,那么也就意味着是一部分人出让/"馈赠"了自己的权益给另一部分人.

因为解决冲突的时候,考虑到中立性,并不能有选择性地解决.
而且,实际上,考虑到人群的复杂性,"选择性执法"并不具有现实可行性.
原因在于,某些冲突点可能是两类人群的混居地.

那么,除了税收之外,还有其他解决方案么?

税制缺点的本质在于单向选择性接受带来的某种非强制性,并由此产生的权益分配的不平衡.

也就是说,如果新的解决方案也存在这种权益不公平性的话,跟税收的方案其实没什么太大的后果区别.

考虑下bitcoin.

如果把交易费率看成某种消费税的话,那么bitcoin在多数情况下就可以看成是跟税制类似的体系.

权益平等性的问题实际上是通过"交易费"的会计性质的转变,划归出去.
因为这是一笔本来"存在"/"必须"的费用,机制的介入只是赋予了这比费用新的价值/转变会计类别而已.

当然,这个方案的一个问题在于规模/持续性.

毕竟,bitcoin作为一个"金融产品"存在设计上的缺陷.
跟常规的"货币"产品来说,其具有明显的对市场的被动性/波动性.
而且,约束于交易频度和实际流通量.

但是如果引入类bitcoin作为基本运作机制的话,还有一个额外好处在于block chain.
或者说基于block chain衍生的voting机制.

这是一个技术上可以确保majority的voting system.
对于一个目的求"中立",并有大量可管理资金的组织来说,一个可信任公开透明的机械议事机构其实是必须的.

因为它必须保证决议的无可争论性.

不然存在解释空间的话,就容易是组织形成某种小众驱动的倾向性.

毕竟,大多数时候来说,"中立"这个词指示的其实是大多数人的意见倾向.

一个更为理想的状况是组织的武装执行力量也是机械性的bot.

一来是避免人员投入带来的伤亡和损耗,以及信息管理上的问题.
二来是某种形式的block chain base的majority approved voting system直接应用到bot上面的话,基本上场景就是通过算力进行全网参与的行动投票了.

当然,这种情况下隐含了一个算力歧视.
或者说,由于投票权丧失带来的权益不公平性.

所以,还是世界和平吧.

君子爱财取之有道

以前觉得双十一只是对未来销售的一种透支.
现在想想,可能也不一定.

考虑这么一个情况.

在没有促销机制的情况下,每天的整体人群的购买行为其实是服从某种分布的.
于是,每天的营业额度就是接近与这种分布的期望值.

这个从数据上看,也是不无道理的.

不管是电商还是游戏来说,不做活动,一定时期内每天的销售额度其实是在一个稳定范围内浮动.

如果考虑促销本身只是对这个分布做的一个调整的话,那么实际期望E并不见的就是会小于原有的期望E_0的.
因为考虑把这个概率式展开计算的话,实际上就相当于调整每个参与者的概率系数/权重.

即,对于个体i,其概率为p_i,对于的价格贡献为v_i,
则整体期望E=\sum_i p_i * v_i.
满足\sum p_i = 1.

对于给定的
E_0 = \sum_i p{_0}_{i} * v_i
\sum p{_0}{_i} = 1.
存在
E = \sum_i p_i * v_i >= E_0
\sum p_i = 1.
的.

那么考虑一种情况.

加入不做促销时候的p分布已经是最优的了.
那么,继续做促销是否又not economic的呢?

如果考虑一个比较粗的粒度.
比如以月为单位的,看t周期/月的话.

实际上,对于j月的期望为
E_j = \sum_i p{_j}_{i} * v_i

则整个t周期的期望为
E(j;t) = \sum_j E_j = \sum_j \sum_i p{_j}_{i} * v_i = \sum_i (\sum p{_j}) * v_i
令(\sum p{_j}) = S_i的话,
->
E(j;t) = \sum_i S_i * v_i

也就是说,即使展开到t月来看的话,实际上也不过是权重的重新分布/分配而已.
并不一定会低于不做促销时候的期望.

所以,本质上来说.
这类促销即使说会对未来的销售额度产生影响,但也不一定是消极方面的作用.

实际上,这个至少是一个类似组合重新调整程度策略.

如果考虑实际一点的话,至少在做权重调整的时候需要考虑到t周期内的现金流现值问题.
也就是上面的v需要是对应的计算时应该使用的是现值.

再进一步考虑一些季节性消费.
比如时间周期性明显的羽绒服等强销售周期的,那么在做购买分布概率调整的时候,就有可能从某种程度上避免对后面t月的分布概率产生影响.

当然,前提是这个分布概率跟商品的品类无关.

如果有关,也只是退回到前面比较复杂的展开计算里面而已.

所以,理论上来说,做促销活动,起收益的期望至少不会比当前的差.

换句话来说,就是t周期内的预计现金流情况存在有改善的情况.
从另一个角度来说,如果t周期内的预计现金流存在改善的情况的话,也就是某种程度上的周转周期的缩短.

毕竟,对于最末端的零售商来说,越早的清库存也就意味着流动性越高.
推而往上的话,就是相关产业链的周转的加速和改善.

当然,这只是一个比较理想的情况.

毕竟,这里的一个重要假设是对预期的销售额和购买分布的变动影响有一个比较精确的估计.

而这个实际上多数产品多多少少存在一些困难.
一些产品本身有生命周期,加上次代更迭的问题,可能最多只能有一个基于历史数据的预测估计,存在相对明显的不确定风险.

不像通讯消费行业.
移动网络的消费人群相对固定,并且套餐费用相对固定.
未来现金流可以做到一个比较稳定且明确的估计.
在这种情况下做促销的话,就相对简单一些.

最低限度也可以安全地把未来现金流提前折现,用于基建再投资.
然后通过技术的变革升级来变更未来现金流的预计,固化现有收益.

总得来说,就是这个世界其实存在着一些不靠小聪明的价格游戏就能实现诚实健康盈利的方式.

如何选择不过是个人喜好的问题.

所谓君子爱财取之有道.

写Android的一点事

昨天把Android的VectorDrawable不能rotate 90度的bug给提了issue.
早上起来check邮件的时候已经变为assigned了,大概确实是个bug了.

这个的原因之前也大致提过下.
基本就是算误用了transform Matrix的一些维度吧.

在旋转90度的时候,这个3*3 matrix的MSCALE_X和MSCALE_Y项目会是近似0.
而VectorDrawable的draw实现是直接拿这两个值乘width/height做scaling的.
其结果是算出个零,只是short path return什么都不做了.

于是结果就是rotate 90度的时候,canvas上什么都没有.

看了下注释,提到用这两个值的原因是避免blur.
翻了下commit log,最近的改动的引入也确实是为了解决这个原因.

不过就实际经验来说,抛开90度旋转的问题,这个blur还是存在的.
这个在自己做animation的时候,从0到90度之前的几帧可以看到.

而且翻看了下目前的具体实现,貌似还不是直接走的canvas的通道.
而是draw到一个临时的canvas的bitmap上面,再把这个bitmap draw回提供的canvas上面.

倒是有些不知道当初是如何定位到blur的问题跟这个有关系的.

下午简单地实现了一个半成品的VectorDrawable.
直接是draw到提供的canvas上面,加上animation也没发现有blur的问题.

不过也可能是因为有些功能并没有完全实现的原因.

毕竟,自己写的只取了vector xml定义里的部分值.

一个是vector element的viewportwidth/height.
这个主要是拿来算scale的.

毕竟,虽然说上面提到的Matrix里有两个值有时候能拿来直接动作scale系数.
但终究来说,这个matrix事实上可能是一系列transform的composition而不是单一的scale matrix.
所以直接取值是不可取的.

因此,需要一个svg/vector graph的原始大小定义,然后再通过在canvas上想要paint的bounds的大小一起算scale系数.

另一个是path element的pathData.
这个是类SVG的command string.
也就是实际的SVG/Vector graph的定义.

之前用javascript写的SVG也只用了lineto/moveto/cloase几个command,所以生成的SVG定义也只有这些.
本来想着直接导入的.
但Android的vector resource跟SVG的还不完全一样.

所幸的是这个command序列还是语意相同的.
也少了写麻烦.

所以在写这个的parser的时候,也只支持了这几个命令.

不过看了下,要加其他的话,倒也不难.
毕竟都是直接map到canvas的对应方法上面的.

而且基本上这个的parser也没什么好写的.
本身提供了XmlResourcesParser,自己只要实现个command string的parser就行了.

不过由于这个drawable到底不是原生的drawable,所以要取/构造还是有点不够友善的.

一般来说,都是直接拿context,然后直接通过auto generate的R id去拿drawable.

而现在,这个R id也还是指向原生的VectorDrawable的.

一个思路当然是去hack这个generate的过程,让它指向自己的这个实现.
不过明显的这个成本太高,侵入性太强.
估计至少要动到对应的plugin或者Android Studio.

退一万步说,即使找到了侵入点,那到底也是不兼容的改动,后面纯粹的升级维护纯粹是给自己找麻烦.

所以只能自己直接构造了.

要解决的第一个问题自然是怎么去读vector xml了.

文件路径倒是一目了然.
解析的话,如果不用XmlResourcesParser,随便用sax什么的也OK.

不过这种本身就已经侵入性很强的改动,就没必要添加无谓的不确定/稳定因素了.

翻了下原生实现的locate过程,其实也简单.
拿到AssetManager直接open就行了.

剩下一个就是文件路径的问题.

直接硬编码路径也OK.
但总体来说,不算一个特别优雅的方式.

跟了下相关代码,用R id去locate也不麻烦.
拿到对的Resources直接get value得到的就是了.

这里的问题有两个.
一个是Resources.

本身是有个Resources.getSystem()的.
不过从名字上看就知道是非app specific的.

app specific的也还是只能通过context拿.

另一个问题就是get到的TypedValue.

这里拿到的确实也是路径.
不过需要用value.string这种不太好看的方式来拿.

这里的点子啊与string是个public的field.
虽然说方便,不过看起来终究是有些碍眼.
奈何也没其他稍微顺眼点的方式.

然后既然xml读到了,也parse完了,构造自然是没什么问题了.

剩下的就是一些cache相关的.

原生的drawable一般都会带有个ConstantState,基本上就是对应drawable的实际image数据或者定义.

想想也不难理解.
像image的话,总不能每次都load一次.

所以有个ConstantState的设计,倒也挺符合直觉的.

只是对应的方法倒不是强制overide的,这点有点不太舒服.
毕竟原则上来说可以是abstract强制一下.

不过也无所谓了.

个人喜好问题.

其他的也就没什么了.

说白了就是基本上所有drawble都是到canvas的.
拿到canvas,什么都好说.

不过有一点就是,canvas这个并不是线程安全的.
因为其实也是一个transform的composition,多一个不同batch的modify一起concurrent的话,结果挺难预料的.

有想过看看能不能clone一下,然后parallel batch一下,最后在一个个apply/merge回来.
因为底层估计也是一些matrix的运算,应该可以独立.

不过看到是native的操作,一时也懒得去拉代码看开销,于是就算了.

当初写custom viewgroup的时候就想过.
如果现在的render pipeline对visual region/canvas的invalide能像NUMA一样,分块管理/invalidate的话,估计反而能省一些事.
直接invalidate所属的physical region就好了,交给邮件处理,而不是在拼命算dirty region.

当然,这个也可以软件模拟就是了.
每个visual element assign一个logical region,然后dirty就dirty整个region,然后每个run就batch update/redraw dirty就行了.

之前写custom viewgroup的layout的时候大致也是这个思路.

而且由于采用的取巧的top align的方式,one pass就OK,所以能直接parallel.

如果是像bottom align之类的,可能就不行了.

由于每放置/slice一块区域就可能得重新调整line height.
因为新加的元素的高可能超过了当前的高度,为了对齐得把该行的line height调整到行内最高的元素.
于是,就至少得对之前元素的offset bottom作调整.
无可避免地对整行做重新的layout计算.

所以,这里的一个思路就是,如果现代浏览器做布局的时候基本算法也是如此的话.
那么align-top和提取fix box width/height的话,估计对render性能有点影响.

不过涉及到GUI的,实际开销和代价值不值得,甚至有没必要就是另一回事了.

毕竟,这种有视觉元素的跟纯粹服务端的思路还是很不同的.

后者的哲学在于感觉不到存在.
无论是从性能还是容灾方面来说都是.

而带视觉效果的,评价体系就是相对离散化和多态了.

毕竟,人的视觉系统是一个有着明显边界分段的函数.