七龙珠—弗里沙篇战斗力分析_七龙珠吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0可签7级以上的吧50个
本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：588,642贴子：
七龙珠—弗里沙篇战斗力分析
长时间看七龙珠，对这一部分战斗力所作的总结，如果各位有不同意见可以说出来讨论，希望不要骂人~谢谢~
七龙珠能否独立碾压其他...
首先声明，转自布卡漫画...
作为最具人气的动漫之一...
就以神秘悟饭为例，的确...
第一次发的大家不满意，...
我感觉龙珠一个持枪农民...
缺牙要及时修复，揭秘种植牙如何做到几十年不掉？
一、关于1、的效果首先是怎样来提升战斗力，下面的图式悟空第一次提升战斗力。
当悟空意识到打不过的时候，有了第二次提升战斗力
从这两幅图的对比中我们可以知道，“”也就是一倍界王拳，是在原有战斗力的基础上增加一部分战斗力，两倍界王拳则进一步增加战斗力，也就是说，一倍界王拳是有增加战斗力的效果的。
我们假设每倍提升的战斗力是相等的。因为界王拳作用的机理是在原有战斗力基础上增加战斗力，我们可以假设界王拳是提升原有战斗力的一个比例。接下来我们探讨这个比例应该是多少比较合理。最好的战例是悟空第一次对比达的战斗，这次战斗悟空将界王拳从一倍升到四倍，而且其中也有比较清楚的战斗力说明。
2、悟空的初始战斗力从下面的图中我们可以看出，达尔的探测器显示悟空的战斗力在8000以上。我们可以假设此时悟空的战斗力为8500，这个数据应该是比较准确的。
3、使用的情况及提升的战斗力下面这幅图为悟空使用三倍界王拳时用探测器测得的悟空的战斗力的这个探测器是拿迪斯留下的，按照常理一般人的探测器上限值是自己的战斗力，拿迪斯的战斗力只有1400左右，他留下的探测器应该不能显示这么大的数值。我们可以理解为探测器是经过布玛改造的可以显示更高的战斗力，但是更好的解释也许是漫画发展到这里需要显示一下悟空的战斗力，因此就把这个唯一完好的存在于地球的探测器拿了出来。总之，这是一个比较准确的数值，也就是说悟空使用三倍时的战斗力为21000。
4、的战斗力提升效果哪么悟空的三倍所增加的战斗力为=12500，哪么一倍界王拳提升的战斗力为0。我们所探讨的界王拳能够提升基础战斗力的比例为.5。
你先分析分析克林的战斗力吧
二、赛亚人濒死对战斗力提升的效果1、气的说明首先我们有必要对龙珠中战斗力的情况有一个大概的了解，下面的内容都是本人根据长年对七龙珠的了解写出来的，如果大家有不同意的可以指正~
一般说来，人身体应该具有一定量的气，但是这些气具体能发挥出多大的战斗力，那就要看每个人的战斗技巧了，战斗技巧高的人可以发挥出远远大于本身气的战斗力，而战斗技巧差的人只能发挥出本身气量的战斗力。
龙珠中战斗力的增长并非非常依靠于身体素质的提升，这一点我们从小悟空打败后在天庭和的对决可以看出。龙珠中战斗力的提升应该由两方面的组成，一方面是身体素质的提高，另一方面是气的提升和对气的运用。这在悟空的自白中也有体现，下图中悟空这句话其实让我们对龙珠战斗力的组成有一个了解。
插画培训,60天入门到插画高手,推荐工作
战斗力应该是由气决定的，但是一方面，气的总量是一个决定战斗力的重要方面，另一方面，对气的控制也可以使气集中起来发挥出更强的战斗力。
像比达、拿吧这种经常参加实战，但是不雕琢战斗技巧的人，聚气虽然也可以提升一部分战斗力，但是提升幅度有限。而像悟空这种经过天神专门训练的战士对气的控制已经很好了，在对娜迪斯的时候我们已经知道悟空通过聚气可以提升大约一倍的战斗力，然后经过界王传授这种顶级控制气的技巧，可以将战斗力从8500提升到三倍界王拳的效果21000的战斗力。但是，就像界王所说，界王拳的效果还要取决于你的身体状况，身体倍棒的人可能两倍三倍的界王拳都没问题，就像悟空，身体不好的也许一倍都用不了，这也许也是界王不将界王拳传授给悟空以外的人的一个原因。
从漫画中的信息我们可以知道赛亚人在濒死边缘战斗力会有大幅度的提升，那么，这种提升到底能不能量化呢？我们这一部分对这些数据做一些整理
2、的濒死经历濒死对战斗力提升的效果在漫画中有多次提及，我们首先来考察一下的濒死经历从的这句话我们可以知道，他们上一次测试的战斗力应该是1.8w，而比达从地球回来战斗力上升到2.4w，这期间比达有一次在地球的濒死经历。也就是说比达一次濒死经历提升的战斗力至少是原战斗力的三分之一。
此后，先杀邱依，再杀都比较简单，但碰到变身后的却被打了个半死，然后救活，随后杀了萨博，再被力高打个半死~被悟空用仙豆恢复，两次的濒死经历后比达的战斗力应该是2.4w*1.3^2=4.3w。
由于接下来比达的战斗力不再具有主要的参考价值，转向悟空的战斗力发展~
3、悟空的濒死经历悟空在和比达战斗之前战斗力为8500，与比达一战经历濒死状态，复员后马上赶往那美克星，在这期间通过不断修炼达到濒死状态，吃仙豆回复。七颗仙豆，一颗用来回复普通伤势，另外六颗中三颗在修炼中吃掉，三颗留给了克林、午饭和比达，也就是说，悟空在和比达一战之后经历了四次濒死状态，按照从比达那里得到的数据，悟空达到那美克星时的战斗力应该是^4=2.7w。如果算上悟空身体素质提高所带来的战斗力提高，我们可以认为悟空到达那美克星时的战斗力应该是3w。为什么说这个数值比较合理呢？有两个原因：
a、换身体后的战斗力
悟空和杰克换身体后，悟空的身体被测出来的战斗力是2.，也就是意味着悟空的身体气的量仅仅只有2.3w，考虑到杰克不适应这个身体，可能不能控制所有的气，悟空的气量应该大于2.3w，但是不会大太多，所以3w的本身战斗力应该是一个比较合理的数值。
b、就是前面我们关于战斗力提升对于身体素质和气的依赖的说明。也就是说，悟空在飞船中的修行主要还是提升了身体素质，可以更好地发挥的效果。按照悟空3w的战斗力，那么悟空和杰克对战时18w战斗力，应该就是使用了十倍界王拳的情况。这也比较符合战斗力展示时按照最大值展示的普遍现象。
经过和杰克换身体后的悟空，由于再次经受重伤，治疗恢复，按照前文的数据，此时悟空的战斗力应该是4w，发挥十倍应该是24w的水准，而二十倍界王拳是44w的战斗力水准。
三、篇部分战斗力分析首先我们假设，如果你作为一个黑帮老大，你有1000的战斗力，手下最厉害的人战斗力是1，第二厉害的是0.5。我们可以确定一点：这个老大肯定不会对这个手下最厉害的人很客气，因为他是可有可无的，杀了这个战斗力为1的手下，马上可以有0.5的手下来代替他，因为他们的战斗力对于你这个老大来说实在是太微小了！
1和1000正好是大全集中给出的杰克和佛力沙战斗力的比值~
皇牌精英军团初到娜美克星的时候，对皇牌精英军团的态度异常客气，我们可以推测出，杰克的战斗力和弗利沙的差距应该不大。
说他的战斗力是53w，这句话究竟能不能作为依据呢？
我们做个假设，如果你最厉害的时候有1000的战斗力，那么，当你要给一个战斗力100的人炫耀的时候，有必要说自己战斗力是500吗？我觉得是没有必要的，炫耀的话一定会说最大的战斗力数值。所以我们可以相信53w就是小个子弗里沙的战斗力数值。那么，有一个矛盾就产生了。
弗里沙明明在这里说自己有100w的战斗力，为什么先前又说是53w呢？首先，我们要了解这句话是可以有两种理解方式的，一个是我这一状态的战斗力是100w，另一个就是我拥有100w的战斗力，但是用不用发挥出来就要看情况了。至于那一种理解是对的，我们需要从后面的漫画中求证。
从弗里沙的这句话我们可以知道，弗里沙在和悟空战斗时一直是没有用处50%的战斗力的，为什么没有用。结合前面分析此时悟空十倍为24w战斗力，20倍界王拳为44w战斗力，而悟空二十倍界王拳确实对弗里沙最终形态造成了一定伤害，但是却没有重创弗里沙的事实，我们应该可以得出弗里沙最终形态的普通状态应该是略大于44w的战斗力，和弗里沙所说的53w战斗力比较接近。所以我们可以得出结论：弗里沙最终形态的普通状态可以发挥的战斗力为53w，也就是50%的战斗力，而剩余的50%战斗力属于弗里沙也不能很好控制的战斗力
作为一个boss是没有必要对自己的战斗力作隐瞒的，所以说，我们得出的最终结论是：弗里沙的终极形态可控制的战斗力是53w，也就是弗里沙拿出来炫耀的战斗力，另外还有53w属于弗里沙不能很好控制的战斗力，也就是说弗里沙的全力应该是106w的战斗力
这一战斗力也可以很好地解释弗里沙篇的很多战斗，比如弗里沙对合体后的比克，以及弗里沙和比达的几次对战。具体详情不再细说，相信大家可以有一个很清楚的了解了~
结束~有人愿意讨论的话可以说出观点~交流一下~
龙吧没人了吗~
哎~睡觉去~
回复：26楼写的太多了，看了一点就看不下去了……
LZ会被喷......
回复：9楼克林的战斗力对主线影响不大那美克星上克林的战斗力应该是之间
回复：27楼
贴吧热议榜
使用签名档&&
保存至快速回贴bang’s blog
JSPatch 最近新增了扩展 ，解决之前 block 使用上的一些限制：
block 参数个数最多支持6个。
block 参数类型不能是 double / struct / union 类型。
不支持 JS 封装的 block 传到 OC 再传回 JS 去调用。
接入 JPBlock 后，就可以：
block 参数支持任意多个。
block 参数类型可以是除 struct / union 以外的任意类型，包括 double。
支持 JS 封装的 block 传到 OC 再传回 JS 去调用。
这篇文章说说这里的实现原理。
，照例回顾一下这一年。
今年在公司一整年都在做，用户量一直在增长，UGC方面每天都在产生很多不错的书籍想法和书评，整个产品度过了生死期，进入发展期。产品上有不少地方做得不错，一是保持了简洁的调调，这也是微信相关产品应有的模样，不会有什么乱七八糟的东西，也是很多人喜欢这个APP的原因。二是开放了陌生人想法，一开始微信读书只能看到好友写的想法和书评，跟朋友圈一样保持私密，事实证明在读书这个产品上，开放所有内容才是正道。三是做的阅读时长换书币和赠一得一都取得不错的效果，时长换书币让读书形成正循环。四是做了一些不错的小功能，获得了一些好的口碑，像划线想法制作图片分享，购买/赠送书籍的扉页等。
产品上一直在做一些尝试，但都比较谨慎，很多新需求功能都会经过不断讨论去决定要不要做，也有不少本来已经讨论完觉得可以做，但做到一半或做完时觉得还是不行直接砍掉的需求，谨慎导致不够快速，也做了不少无用功，这里也是我们缺乏经验导致，接下来一年会在这方面寻找解决方法，希望能做到快速迭代，减少无用功。
技术上回顾起来还是做了不少事情的，团队开了个，今年写了15篇技术文章，几乎每个成员都有贡献，开源了5个库（////)，在 APP 质量保证和监控方面做了一些事情，在团队博客上都分享了，另外实施了 code review，团队偶尔也会在项目里做一些新尝试，像尝试使用 RAC，尝试用数据不可变的方式开发，尝试用推荐算法去优化书籍的添加率等等，总的来说还算不错吧。接下来在技术上除了继续保证 APP 质量和开发效率，还应该尝试寻找能帮助产品前进的点。
这一年继续在完善，致力于让 JSPatch 变得更好用，优化了，做了一些，填了一些坑，支持了，做了代码自动补全工具
等，改进最多的是 ，从内测到开放注册，添加了灰度下发、条件下发、自定义密钥、在线参数、实时监控、历史补丁、在线编辑、转换器等等功能，已经是一个完善可靠的补丁分发系统，这个以前没有人做过，可以说开拓了在线补丁分发平台这个领域，算是今年主要的作品了，接下来也会继续探索提供更多的服务。
JSPatch 发展到现在已经被很广泛地，没有具体统计过接入的 APP 数，仅接入 JSPatch 平台每天有补丁请求的 APP 就有近3000个，在 iOS hotfix 市场占有率应该在 95% 以上，github star 也达到了 8300+，还算不错。
对于 JSPatch 的发展一直想扩展到覆盖 iOS 动态化的全部需求，包括开发功能，上半年也针对这个目标做了些事情，做了性能上的改进，优化开发体验的 JSPatchX 和 playground 等，有一些效果，但开发体验上还是不够好，下半年考虑过做一个100%准确的转换器，实现直接用原生OC开发，动态下发，进一步提升开发体验，但下半年杂事缠身，没能实施，最近看到滴滴和手Q分别实现了这样的方案，也就没打算再做了，后续再看情况。
今天聊聊 iOS 动态化的故事。
在开发模式上，web 的方式是比较先进的，有各种优点，包括跨平台/UI开发效率高，最重要的是可以时刻保证用户看到的程序是最新的，没有版本概念，整个系统时刻保持在掌握之中，而客户端开发模式相对 web 开发是一种倒退，客户端做不到这样的动态化，无法随时更新，目前一个客户端程序要更新成本是很高的，需要发布版本，也无法保证所有人都能更新到这个版本，这是最大的弱点，也是非常大的一块需求。
为什么会有这种倒退，最主要原因是：苹果引领的体验优先规则。
在 iPhone 出现之前大家并不太在意一个软件的动画体验，一个 web 应用是很少有动画的，点一个按钮，一整块内容直接刷新，再点个链接整个页面变白刷新，PC上网页滚动都是一格格滚动的，而不是现在手机上那种顺滑流畅的滚动，PC客户端软件也一样，大家都觉得没什么问题，用得挺好，但苹果改变了这种情况，iPhone 刚推出时页面间切换的动画，60fps 的丝滑滚动，点击的即时响应，微软的人都惊呼是黑魔法，让人用了就上瘾，再也回不去，而 web 的方式还不足以像原生客户端那样支持这样的流畅性，做不到好的体验，无法被人接受，开发上优势再多也无法干过客户端，参考 facebook 初期用 web 技术构建 app 的惨状，没办法，服了苹果，大家只能按照苹果的方式干，做原生客户端。
当然这里还有手机环境网络不稳定，流量费贵的原因，但这些都可以在技术上通过缓存解决，最主要还是体验问题。
那发展到今天，这个体验问题解决了没有呢？没有，即使发展到今天手机性能已上天，但 web 做出来的东西体验仍然跟客户端有差别，大家也已经习惯了 APP 的方式，也被流畅的 APP 惯坏。现在 APP 里也有不少功能是 web实现，但大家都知道这是牺牲了一些性能体验去换取开发和发布效率，只是一种权衡。
那这个问题怎么解决呢，现在业界有两种方案。
1.优化 web 性能
既然用 web 方式开发的劣势只是性能体验跟不上，那就优化性能吧。web 性能瓶颈在哪里？在那个有悠久历史的 webkit 引擎，它有各种历史问题，要改进它并不容易。我们要的是 web 的开发和发布方式，不需要 web 的全部，那能不能重新实现一个渲染引擎呢，这个引擎可以针对原生客户端优化，不需要兼容繁杂的 web 标准，不跟 web 那些历史问题扯上关系，于是就有了
这种方案，web 的方式开发，原生的方式渲染，拥有 web 优秀的开发和发布方式，又有不错的性能体验，看起来很完美，很有前途的方案。
一个方案能不能推广开让大家都使用，主要看成本和收益。目前 React Native 和 Weex 等这些方案的接入成本是很高的，一是它们本身就是大型框架，学习成本高，后期维护成本以及团队学习成本同样高。二是它们还不够成熟，还在继续填坑中，使用的过程可能要一起去填坑。收益上也不够理想，就目前状况它们能代替的是那些本来用 H5 实现的模块，换成这种方式实现后性能体验会更好，但也不能保证像原生那样好，很多场景需要深入框架进行优化。整个 APP 都使用这种方案构建还不靠谱，部分使用又无法使整个 APP 保持动态化，总体上来说收益也没有达到有绝对优势的程度，成本高收益低，推广起来会比较困难，还需期待其继续发展。
2.原生动态化
另一种是方案是，我可以放弃用 web 的开发方式，放弃 web 跨平台/UI开发简单的优越性，我想继续用原生的方式开发这个APP，但又希望这个 APP 随时可以更新，让程序时刻在自己掌握中，出了问题可以快速修复，还想要可以随时更新版本快速迭代，可以不？完全可以，用动态库就行了。
技术上要在 iOS 上做到原生动态化比 Android 更容易，iOS 开发语言 Objective-C 天生动态，运行时都能随意替换方法，运行时加载动态库又是项很老的技术，只要我把增量的代码和资源打包到一个 framework 里，动态下发运行时加载，修 bug，加功能都不在话下，性能完全无损，这件事就结束了。
但是呢。苹果把加载动态库的功能给封了，动态库必须跟随安装包一起签名才能被加载，无法通过别的途径签名后再下发。
为什么这么做呢，这又涉及到苹果另一个创举：审核模式（苹果的创举之多令人发指）。一个软件，要在一个平台上发布，需要先通过这个平台的人工审核，这个好像在苹果之前没见过有别人这样做过，windows 不用，mac 不用，各种 unix 不用，web 也不用，苹果为了对自己的平台有绝对控制权，搞了这样一个东西，审核模式就跟动态化冲突了，如果我一个 APP 可以不经过审核不断下发 framework 添加修改功能， 还需要苹果审核做什么？
因为这种限制，没法用最方便的方式进行动态更新了，整个 APP 发出去后就不受控制，有什么严重 bug，需要添加什么功能，都乖乖打个包提交给苹果审核，再等用户慢慢更新，对于急性子的中国人来说，这种事难以容忍。
苹果把动态库这扇门关了，我们可以绕个道从另一个门进，动态加功能可以缓缓，大家需求还不那么迫切，但修 bug 的需求就很急，很多公司 APP 的 crash 率是 KPI 来着，看着线上 crash 不断增多又毫无办法是很不爽的事，于是有了
这种方案，曲线救国。
把 OC 手动翻译成 JS，在运行时通过 OC 的动态特性去调用和替换 OC 方法，实时修复 bug。修 bug 这个需求基本是满足了，虽然小绕了下道，但成本还是很低的，引擎本身也很小很轻量，接入对 APP 不会有任何负面影响，在关键时刻又可以帮大忙，成本低收益高，于是很容易推广开。
人欲望是无穷的，技术宅的折腾是无止境的，JSPatch 满足了修 bug 的需求，但还是无法满足动态化的全部需求，最大的缺点在于需要手写 JS，虽然已经有转换器辅助，但还没做到100%准确，用来修 bug 还好，用来添加功能的话学习成本和开发效率还不够。
于是有了滴滴的
这种方案，绕了一个更大的道，从编译阶段入手，通过 clang 把 OC 代码编译成自己定制的 JS 格式，再动态下发去执行，做到原生开发，动态运行，主打动态添加功能，当然顺便把修 bug 也给支持了。手机 QQ 内部也有一个类似的方案，不过更进一步，他们通过 clang 把 OC 代码编译成自己定制的字节码动态下发，然后开发一个虚拟机去执行（惊呆了），同样实现了原生开发，动态运行，都是 NB 得很的方案。只要底层处理做得足够好，也是个成本低收益高的方案，不过目前都还没开源，还没能看到实际效果和 NB 的源码，挺期待。
这种方案有没有什么问题呢，问题在对于苹果审核比较尴尬。这种方案做到极致后(所有OC/C语法都支持)，实际上是绕道实现了动态加载 framework 的全部功能，开发体验还是一致的，如果苹果同意这种方案，那相当于允许加载动态库，那还不如直接把门开了，让大家直接用动态库去做这个事情，用动态库还能在签名时禁止使用私有 API，用这种编译成脚本/字节码下发的方案可就禁止不了了。
这跟 JSPatch 还不太一样，JSPatch 虽然我也想推广动态添加功能的用法，但因为开发体验问题大部分还是用于修 bug，苹果审核对 JSPatch 开始也是有一些拒绝案例，后来估计看到大家只是用它来修 bug 和 crash，提升 APP 的质量，就默许了。但 DynamicCocoa 和手Q的方案一开始目标和效果就是跟加载动态库对齐，大规模推广后苹果会怎么看就不知道了。
我觉得苹果现在的审核方式挺有问题的，有多少APP是审核时用一套，审核通过后又通过后台一些开关把不符合规则的一些功能开放出来？只要能连上网，就有N种方式修改 APP 里的功能，苹果完全拦不住。个人认为审核方式应该改为只在发布新 APP 时审核，发布后允许动态下发代码更新，版本更新也不需要重新审核，而是通过举报和抽查的方式去审核已上线的 APP，这样既能顾及开发效率，方便开发者快速迭代做出更好的 APP，也更能确保审核效果，只是实施起来没有现在简单粗暴。
故事讲到这里已经差不多了，再多说一点，有个让我觉得很奇怪的问题，就是国外开发者只热衷于使用第一种方案解决问题，也就是使用web技术，用 React Native / NativeScript 的方式去做这个事情，对第二种方案很冷淡，包括 iOS Android 都是，原生热更新只在国内火，国外根本不感冒，国外有个
热更新平台也不温不火，为什么呢？是国外用户更守规则，或是用户对线上 bug 容忍度高，开发者对线上 bug 并不那么着急？还是 Android 被 Google Play 卡死断了这念想，iOS JSPatch 之类的方案推广不利？缺少国外一线开发者的支持，让系统原生支持动态化就比较困难了。
个人认为由系统支持动态化（允许加载动态库）在当前环境下是最好的，兼顾开发效率和 APP 体验，虽然不能跨平台，但也还能接受，可惜这个主动权掌握在苹果手上，开发者无能为力，才会出现这么多强行绕道突破的方案。web 的方式可能是未来，但目前适用范围有限，接下来怎么发展，拭目以待吧。
一般一个 iOS APP 做的事就是：请求数据-&保存数据-&展示数据，一般用 Sqlite 作为持久存储层，保存从网络拉取的数据，下次读取可以直接从 Sqlite DB 读取。我们先忽略从网络请求数据这一环节，假设数据已经保存在 DB 里，那我们要做的事就是，ViewController 从 DB 取数据，再传给 view 渲染：
这是最简单的情况，随着程序变复杂，多个 ViewController 都要向 DB 取数据，ViewController本身也会因为数据变化重新去 DB 取数据，会有两个问题：
数据每次有变动，ViewController 都要重新去DB读取，做 IO 操作。
多个 ViewController 之间可能会共用数据，例如同一份数据，本来在 Controller1 已经从 DB 取出来了，在 Controller2 要使用得重新去 DB 读取，浪费 IO。
我一直对汽车不怎么感冒，去年五月因为家庭需要买了丰田雷凌，开得比较少，只有周末和有需要的时候才开下，说说对汽车的一些想法和感受。
在自动挡的汽车里没有了离合，只剩下两个踏板：刹车和油门，本来这两个踏板刚好对应两只脚，左脚刹车右脚油门，但现在还是全部由右脚控制，左脚空闲着，这样有两个优点：
避免刹车和油门同时踩。若两只脚对应两个踏板，慌乱的时候可能会两个踏板同时踩，不过这点很容易从技术上弥补，踩刹车的时候让油门失效就行了。
跟手动挡的车兼容。手动挡左脚是需要踩离合的，右脚就必须兼顾这两个踏板，若自动挡改成两只脚控制，在这两种车间切换的学习成本会变得很高，也会很混乱，估计这是最主要的原因。
同样也有两个缺点：
右脚会很累。特别是在市区拥堵路段，右脚需要不断在刹车和油门之间变换。
从油门到刹车切换需要时间。这时间可能已经够快，但在关键时刻还是浪费了些宝贵的刹车时间。
总的来说这种方案是缺点大于优点的，如果世上没有出现过手动挡汽车，可能还是会设计成左脚踩刹车，右脚踩油门。
还有一个小细节，现在由一只脚控制刹车和油门，那就需要尽力避免右脚混淆这两者，避免把刹车当油门，把油门当刹车的情况。就我的车雷凌来说，做了两点去保证这个区别，一是刹车面积比油门大，误触刹车比误触油门安全得多。二是刹车和油门这两个踏板不在一个平面上，刹车会稍微高点，稍微往前点，让脚放在刹车上跟放在油门上是两种不同的感觉，让脚抬起的度数去感觉现在是踩在刹车上还是油门上，这种身体的记忆是最可靠的，同时刹车高点也会比油门更容易踩。不知是不是所有车都这样。
开车到现在碰到最大的痛点就是空调问题了，夏天只要放在路边，没多久车内温度就会非常高，没法待，这时候通常都是先进去发动汽车开空调，再在车外等车内温度稍微降低后再进去，等待的时间也很长，非常麻烦。怎样解决这个问题呢？
第一个能想到的是加强空调的强度，让汽车快速降温，不知道技术上能不能做到。我对汽车本身不太感冒，宣传的那些参数都看不懂，我觉得应该在那些参数里加一项，可以在多少秒内把车内温度从50读降到25度，这点应该很有参考价值。
第二是支持远程开启汽车空调，一查发现原来已经有不少汽车支持这个功能了，有的是远程开启发动机后供电开启空调，有的是用车内蓄电池供电开启，但远程开启发动机有点危险的感觉，车内普通的蓄电池电力又不足，这个功能应该更适合那种混动或电动汽车。
车上装了个屏幕，是上个时代的产物，虽然有很多功能，什么电台/导航/音视频什么的，但很不好用，屏幕质量也差，非常鸡肋，唯一的作用是倒车时显示后视摄像头，平时其他功能都是直接使用手机，然后我还得买个手机支架挡在汽车空调风口去使用手机。
这里的问题是汽车换新的速度比手机差远了，一般人八年十年才会换一辆车，但一两年就会换一次手机，导致手机屏幕和功能一定秒杀汽车屏幕。另外像特斯拉那种放一个巨大触摸屏在汽车也不是好的方案，调个空调什么的都要通过屏幕，没法通过位置和触感盲按，在驾驶过程中调节麻烦又危险，大屏幕在汽车上并没有什么大用处，而且这块固定的屏幕也很快会过时。手机在未来很长一段时间应该还会继续在屏幕方面处于统治地位，新型汽车应该把本来留给屏幕的位置换成留给手机，做好手机和汽车的连接体验才是正道。
自动驾驶目前在 AI 领域很火热，它带来的好处自然是很吸引人，驾驶的事交给机器，自己在车上就可以看看电影玩玩游戏，取车停车都能交给机器做，相当于每个人都有专属司机，目前号称自动驾驶出事故的概率比人低得多，机器比人更可靠，自动驾驶大规模使用指日可待，但这里感觉有个很大的隐患，就是程序病毒。从概率上说虽然人可靠程度不如机器，但人可不会突然中个病毒，然后在开车的时候乱来，但机器会，无法预测程序中病毒以后的行为，也无法事先感知程序中了病毒，现在在起步阶段，自然不会有这样的问题，等到真正大规模使用了，受到黑客的关注多了，自然攻击会变多，这里有很大的不确定性，把自己的生命交给这样的不确定性恐怕大家难以接受，估计也只敢在停车和取车时空车模式使用。
私家车相对于打车和公共交通有好处也有坏处，好处是干净舒适，无需等待，无需步行到车站，也不用担心没有车，心情好的时候驾驶的感觉很不错。坏处也不少，开车时除了听歌听电台无法做其他事，相对地铁有塞车的烦恼，停车是个巨大的麻烦。另外成本也很高，得交停车费，得保养车，路上擦碰要修理，一不小心还得违个章。这样算起来，在公共交通和优步滴滴这样的出行方案成熟的情况下，开私家车真是挺奢侈的。
参加了内部面委会的一个分享，结合我自己的方式，说说怎样面试一个普通的iOS工程师。
一般我倾向的考察分两个主要的部分，第一是在简历里提到的项目经历中找挖掘点，第二是基础知识考察。另外也会看情况做一些软实力的考察和性格特征的判断。
如果顺利的话这第一步占的比例会很大，因为每个程序员都不会方方面面知识都熟悉，但至少他写在简历上的做过的项目是熟悉的，讲自己熟悉的东西容易让他进入状态，展示好的一面。这里主要考察两方面，一是有没有在某些点上有过深入研究。二是对项目整体了解如何。
在中大型的公司里比较注重工程师有深入研究的能力，如果能把一个功能讲得很清晰是比较好的加分项，这里会问实现的思路，通过追问去了解候选人在这块深入的程度，从思路到方法，从上层API调用到框架流程再到底层实现。如果候选人在讲述时有一条逻辑主线，例如讲述业界普遍是怎么做的，自己在业界方案基础上做了什么改进，怎样做到更好，进一步改进的思路是怎样，这是最好的。如果还能把解决问题的方法归纳起来运用在其他地方，能举一反三，包装成通用解决方案，或者做开源贡献，就更好了。
一般会问候选人哪一个项目技术点最能体现自己的技术，然后不停追问技术细节，例如做了一个相册项目，觉得列表优化是最能体现技术点的，会问这里优化的思路是什么，怎样评估，遇到过什么困难，怎么解决的，如果用到图片缓存开源项目，说说它具体做了什么事，缓存策略是什么，从下载到显示的整个流程是怎样的，还有没有更好的方案，追问到一定程度后也会发散去问跟这个话题相关联的问题，例如如果有部分用户反馈图片显示不了，你会怎样排查问题，排查修复后怎样监控，就会过度到一些网络和运营监控方面的内容，也会顺便问到一些基础知识。
问完自己职责范围内的功能技术点后，还会看看对项目里其他的实现有没有了解，特别是项目的大致架构和核心功能，最好能画出项目大致结构，看情况问问网络层和数据层是怎样实现的，为什么这样实现，项目最核心功能是怎样实现的，例如做读书的至少要知道项目里的排版引擎的大致实现方式，做QQ的要知道消息收发的机制，如果不知道，也可以说说如果自己实现会怎么做。这里主要看看有没有技术好奇心，会不会积极主动了解项目里已有的非职责范围内的技术点，主动和好学这两点是很重要的。
如果项目经历里能问出大部分东西，这部分比例就会比较少了，这是比较好的情况，否则就按套路去多考察一些基础知识，包括iOS开发的基础和计算机基础，像内存/网络/存储/线程等，例如 ARC 是怎样做到自动管理内存的，跟java/js的垃圾回收的区别，网络http协议是怎样的，用过什么数据库框架，db索引是什么，多线程开发要注意什么，跟runloop的关系是什么等等，这类问题在网上都有很多，就不多说了。数据结构和算法在笔试时会涉及，面试会比较少，如果问算法的话只会问问思路，一般我觉得如果项目经历方面不太好，才会考虑考考算法作为辅助判断。
一些通用能力像逻辑思维能力，沟通能力，自我驱动能力等都可以在上面那些问题的交流中表现出来，另外像团队协作能力、抗压能力和性格特征这些也会看情况考察一下，例如问问如果产品让你做个需求，你觉得不靠谱，会怎样做，设计让你做个很难实现的效果，你会怎样评估？或者问个低级问题，故意说个错误的答案，看看他的反应是怎样，是表现出嘲笑和攻击性，还是怀疑自己，还是细心求证。抗压能力的考察有些人比较喜欢，我是觉得面试还是轻松一点好。软实力方面的考察在一面会比较少，或者不会涉及，实际上这方面我也没太多经验，也在摸索中。
作为程序员，如果有 github 开源项目是最好的，直接可以看到代码风格，代码质量，处理 issue 和 PR 的方式，如果有技术博客也是很好的，可以提前看到平时的一些技术积累，省了很多事。但如果 github 内容是培训班的那种仿写APP，博客内容是摘抄文章什么的就是负分了。
以上是正常套路，若候选人有特殊经历或技能，例如牛X大学毕业，ACM冠军，通读linux源码，php源码贡献者之类，会另当别论，针对性进行面试，这不是唯一的标准。另外针对不同的工作年限也有不同的问法和要求，工作年限越高要求越高。
其实面试就是想低成本找到合适在团队里一起工作的人，因为如果通过一起工作一段时间去判断是否合适成本太高。这种低成本的代价就是会误判，有些工程师是理论型，有些是实践型，面试的方式会对实践型的人不利，尽管他们如果招进来会是适合的人，而且人会在不同环境下会有不同的表现，只根据过去的经历去判断有时是不准确的。只能尽量采取一些措施去减少误判的概率，例如提高面试官的判断能力，或多几轮面试。一般如果不是急招，策略都会是宁杀错不放过，所以其实就算面试被否了，也不一定代表能力不行。
另外每个面试官可能都有自己摸索出来的一种判断方式，并随着面试经验的丰富不断改进，达到更准的判断概率，这只是我个人在目前有限的经验里的一点小总结，仅供参考。
分类: Tags:
是 iOS 平台上的一个开源库，只需接入极小的三个引擎文件，即可以用 JS 调用和替换任意 OC 方法，也就是说可以在 APP 上线后通过下发 JS 脚本，实时修改任意 OC 方法的实现，达到修复 bug 或动态运营的目的。目前 JSPatch 被大规模应用于热修复(hotfix)，已有超过
个 APP 接入。
虽然 JSPatch 目前大部分只用于热修复，但因为 JSPatch 可以调用任意 OC 方法，实际上它也可以做热更新的工作，也就是动态为 APP 添加功能模块，并对这些功能模块进行实时更新，可以起到跟
一样的作用。我们从学习成本、接入成本、开发效率、热更新能力和性能体验这几个方面来对比一下使用 React Native 和 JSPatch 做热更新的差异。
React Native 是从 web 前端开发框架 React 延伸出来的解决方案，主要解决的问题是web页面在移动端性能低的问题，React Native 让开发者可以像开发web页面那样用 React 的方式开发功能，同时框架会通过 JS 与 OC 的通信让界面使用原生组件渲染，让开发出来的功能拥有原生APP的性能和体验。
这里会有一个学习成本的问题，大部分 iOS 开发者并不熟悉web前端开发，当他们需要一个动态化的方案去开发一个功能模块时，若使用React Native，就意味着他需要学习web前端的一整套开发技能，学习成本很高，所以目前一些使用 React Native 的团队里，这部分功能的开发是由前端开发者负责，而不是终端开发者负责。
但前端开发者负责这部分功能也会有一些学习成本的问题，因为 React Native 还未达到十分成熟的程度，出了bug或有性能问题需要深入 React Native 客户端代码去排查和优化。也就是说 React-Native 是跨 web 前端开发和终端开发的技术，要求使用者同时有这两方面能力才能使用得当，这不可避免带来学习成本的提高。
而 JSPatch 是从终端开发出发的一种方案，JSPatch 写出来的代码风格与 OC 原生开发一致，使用者不需要有 web 前端的知识和经验，只需要有 iOS 开发经验，再加上一点 JS 语法的了解，就可以很好地使用，对终端开发来说学习成本很低。
可以看一下同样实现一个简单的界面，React Native 和 JSPatch 代码的对比：
class HelloWorld extends Component {
render() {
style={styles.btnArea}&
style={styles.btnWrapper}&
underlayColor="#ED5F37” onPress={this.login}
activeOpacity={0.7}&
&Text style={styles.btn}&登录&/Text&
&/TouchableHighlight&
var styles = StyleSheet.create({
btnArea: {
justifyContent: 'center',
marginLeft: 20,
marginRight: 20,
marginTop: 100,
flexDirection: 'row',
btnWrapper: {
backgroundColor: '#FC6E50',
borderRadius: 5,
paddingTop: 10,
paddingBottom: 10,
color: '#ffffff',
textAlign: 'center',
require('UIColor, UIScreen, UIButton')
defineClass('HelloWord : UIView', {
initWithFrame: function(frame) {
if(self = super.initWithFrame(frame)){
var screenWidth = UIScreen.mainScreen().bounds().width
var loginBtn = UIButton.alloc().initWithFrame({x: 20, y: 50, width: screenWidth - 40, height: 30});
loginBtn.setBackgroundColor(UIColor.greenColor())
loginBtn.setTitle_forState("Login", 0)
loginBtn.layer().setCornerRadius(5)
loginBtn.addTarget_action_forControlEvents(self, 'handleBtn', 1&&6);
self.addSubview(loginBtn);
handleBtn: function() {
接入成本上，React Native 是比较大的框架，据统计目前核心代码里 OC 和 JS 代码加起来有4w行，接入后安装包体积增大 1.8M 左右。而 JSPatch 是微型框架，只有 3 个文件 2k 行代码，接入后增大 100K 左右。另外 React Native 需要搭建一套开发环境，有很多依赖的库，环境的搭建被称为一个痛点。而 JSPatch 无需搭建环境，只需要拖入三个文件到工程中即可使用。
React Native 是大框架，维护起来成本也会增大，在性能调优和 bug 查找时，必须深入了解整个框架的原理和执行流程，此外 React Native 目前还未达到稳定状态，升级时踩坑不可避免。相对来说 JSPatch 接入后的维护成本会低一些，因为 JSPatch 只是作为很薄的一层转接口，没有太多规则和框架，也就没有太多坑，本身代码量小，需要深入了解去调试 bug 或性能调优时成本也低。
在 UI 层上目前 HTML + CSS 的方式开发效率是比手写布局高的，React Native 也是用近似 HTML+CSS 去绘制 UI，这方面开发效率相对 JSPatch 会高一些，但 JSPatch 也可以借助 iOS 一些成熟的库去提高效率，例如使用 Massory，让 UI 的开发效率不会相差太多。逻辑层方面的开发效率双方是一样的。
此外 React Native 在开发效率上的另一个优势是支持跨平台，React Native 本意是复用逻辑层代码，UI 层根据不同平台写不同的代码，但 UI 层目前也可以通过 ReactMix 之类的工具做到跨平台，所以UI层和逻辑层代码都能得到一定程度的复用。而 JSPatch 目前只能用于 iOS 平台，没有跨平台能力。
实际上跨平台有它适用和不适用的场景，跨平台有它的代价，就是需要兼顾每个平台的特性，导致效果不佳。
跨平台典型的适用场景是电商活动页面，以展示为主，重开发效率轻交互体验，但不适用于功能性的模块。对 Android 来说目前热更新方案十分成熟，Android 十分自由，可以直接用原生开发后生成diff包下发运行，这种无论是开发效率和效果都是最好的。所以若是重体验的功能模块，Android使用原生的热更新方案，iOS 使用 JSPatch 开发，会更适合。
JSPatch 也做了一些事情尝试提高开发效率，例如做了 XCode 代码提示插件 ，让用 JS 调用 OC 代码时会出现代码提示，另外跟 React Native 一样有开发时可以实时刷新界面查看修改效果的功能，目前仍在继续做一些措施和工具提高开发效率。
热更新能力
React Native 和 JSPatch 都能对用其开发出来的功能模块进行热更新，这也是这种方案最大的好处。不过 React Native 在热更新时无法使用事先没有做过桥接的原生组件，例如需要加一个发送短信功能，需要用到原生 MessageUI.framework 的接口，若没有在编译时加上提供给 JS 的接口，是无法调用到的。而 JSPatch 可以调用到任意已在项目里的组件，以及任意原生 framework 接口，不需要事先做桥接，在热更新的能力上，相对来说 JSPatch 的能力和自由度会更高一些。
使用 React Native 和 JSPatch 性能上会比原生差点，但都能得到比纯 H5 页面或 hybrid 更好的性能和体验。
JSPatch 的性能问题主要在于 JS 和 OC 的通信，每次调用 OC 方法都要通过 OC runtime 接口，并进行参数转换。runtime 接口调用带来的耗时一般不会成为瓶颈，参数转换则需要注意避免在 JS 和 OC 之间传递大的数据集合对象。JSPatch 在性能方面也针对开发功能做了不少优化，尽力减少了 JS 和 OC 的通信，github 项目主页上有完整的小 App ，目前来看并没有碰到太多性能问题。
React Native 的性能问题会复杂一些，因为框架本身的模块初始化/react组件初始化/JS渲染逻辑等会消耗不少时间和内存，这些地方若使用或优化不当都会对性能和体验造成影响。JS 和 OC 的通信也是一个耗性能的点，不过这点上 React Native 优化得比较好，没有成为主要消耗点。
在性能和体验问题上，两者有不同的性能消耗点，从最终效果来看两者差别不大。
热更新能力
中，不跨平台
React Native
高，跨平台
总的来说，JSPatch在学习成本，接入成本，热更新能力上占优，而 React Native 在开发效率和跨平台能力上占优，大家可以根据需求的不同选用不同的热更新方案。JSPatch 目前仍在不断发展中，后续会致力于提高开发效率，完善周边支持，欢迎参与这个开源项目的开发。
（本文发表于《程序员》2016年8月刊）
JSPatch平台:
分类: Tags:
支持了动态调用 C 函数，无需在编译前桥接每个要调用的 C 函数，只需要在 JS 里调用前声明下这个函数，就可以直接调用：
require('JPEngine').addExtensions(['JPCFunction'])
defineCFunction("malloc", "void *, size_t")
malloc(10)
我们一步步来看看怎样可以做到动态调用 C 函数。
首先若要动态调用 C 函数，第一步就是需要通过传入一个函数名字符串找到这个函数地址，这里一个必要的前提条件就是 C 编译后的可执行文件里必须有原函数名的信息，才有可能做到通过函数名字符串找到函数地址。我们写个简单的程序来看看它编译后可执行文件的内容有没有这个信息：
void test() {
int main() {
编译这个文件，并用otool看下它的汇编：
前几天受邀去北京一个技术分享会
相关内容，记录一下这次旅程。
这次在 GMTC 分享的主题是 JSPatch 成长之路，PPT现在可以在看到，视频等后面出来了再补上。主要分享了 JSPatch 一开始碰到的一个难题，在发展过程中怎样完善补全周边功能，以及下一步计划。这是我第一次对外做分享，作为一个非常容易紧张的人，这第一次上台分享时竟然一点也不紧张，出乎我意料，当时在台下等待时还挺紧张，上了讲台后就很放松了，可能因为准备得比较充分，现场也没出现什么意外，都在把握之中吧，状态很好，分享效果感觉也还不错。
关于线下演讲分享和线上文章分享，我一直觉得技术领域要学东西的话线上文章分享是最好的形式，一是它传播广，触达用户多；二是耗时少，写一篇文章或看一篇文章都比听一个分享花的时间少很多；三是可沉淀，读者可以反复看细节，可以沉淀下来不断被人搜索到。
这次分享后我观点没有太大变化，但我也体会到了线下分享的好处，对分享者来说可以展示个人魅力，提升沟通能力，更有动力去认真准备内容，能比写文章更好地梳理自己的思路。对听众来说可以得到分享者这份精心准备的内容，同时可以面对面沟通交流，得到更多信息。当然更重要的是可以认识多些人。相对来说分享者得到的好处会更多些，我就觉得这次分享我自己收获挺多。不过线下分享无论是分享者和听众，时间成本都很高，而且收益会随着参加次数增多而减少，第一次的收益应该是最高的，后面参加多了可能就没什么帮助了，个人觉得不应该频繁参加。
在台下听了一些分享，印象比较深的是覃超的，讲 Facebook 客户端演进的过程，技术选型犯的错误和原因，反思世上没有能一次性解决所有问题的技术，跨平台是个陷阱，它要付出很多代价，牺牲很多东西，导致效果不佳，效率和效果是一种权衡，应该面向用户开发而不是面向工程师。其他精彩分享篇幅有限这里就不多说了，在都可以看到。
这次顺便也参加了一个iOS开发者沙龙，，跟会议分享不同的是只邀请少数人，鼓励多进行沟通交流，台上演讲分享只是辅助开启话题，这个有点像公司内部分享，还挺不错，跟多人大会比起来各有好坏吧，优点在于这样的交流更有效率，可以交流到更细节的东西，缺点在于分享不会那么精心准备，也就没有前面说的那些好处，另外因为更注重双向交流，效果好不好得看参会的人怎样。
在沙龙同样分享了 JSPatch，交流比较多，大家也提出了很多自己的看法，第二场sunny分享了，阐述一个函数在汇编层面是怎样被调用的，objc_msgSend 的实现，最后还分享了一个 swift 理论上可行的方法替换的实现方式，十分黑魔法，但前提是得越狱，很赞的分享，长了见识。第三场因为有约就提前走了，小有遗憾。
距上次来北京已经时隔五年多了，再次踏入北京的感觉有点亲切和怀旧，感叹时间过得越来越快，现在一回忆起什么事来动不动就是五年前十年前。当时在百度实习三个月，对北京的印象挺好，可能是待的时间短还没来得及看到它不好的地方，没碰到过大雾霾的天气。给我的感受北京跟广州最大的不同是人的多样性，这里汇集了全国各地的人，不同性格不同背景不同经历的人互相交流进步，而且北方人(广东以北的人)大多性格外向豪爽，跟他们聊多了自己也会变开朗些，很有意思。
跟前同事聚了下，五年来大家外貌似乎一点都没变，就是各奔东西了，有的在百度继续发展，有的跳到中小公司，有的创业，境况不一样，有的公司上市了，有的公司下滑严重，北京选择机会多，风险也大，谁能想到如日中天的一家公司说跌落就跌落，看起来一般般的公司说上市就上市，人生啊，不过大家还得工作几十年，机会多得是。
这次过来见到了很多之前只在网上交流过的朋友，有些跟网上交流感觉一致，有些很有气场，有些很有亲和力萌萌的哈哈，也认识了不少新朋友，很感谢这次各路朋友们的热情招待，非常愉快的一次旅程~
对于使用的东西，便捷性是比功能性更重要的，雨伞是最好的例子，下雨拿雨伞下半身还是会被淋一身，功能上并不完整，雨衣在这方面更胜一筹，能保证大部分部位不会被淋到，若再发明一种把脚也包起来的雨衣就更完美了，但这些永远做不到雨伞那样流行，因为雨伞非常方便，大家都宁愿为便捷性牺牲一些功能。
互联网影响了音乐/文学/游戏，音乐免费了，音乐人卖不了唱片，变现的路变长了，还不如搞娱乐八卦拍NC电视剧钱来得快，于是音乐也就没落了。文学上大家被互联网碎片信息冲击，信息爆炸，社会节奏快，也就更少人去买书阅读了，另外网上盗版满天飞，传统作家收入也受限了，远不如写写YY网络小说赚得多，细腻经典的文学也就变少了。游戏上以前单机游戏，追求的就是好玩，好玩就会有很多人买，就会赚到钱，而现在网络游戏，追求的不是好玩而是寻找人性的弱点，对人性把握越到位，就有越多人民币玩家投钱在你游戏里，可参照各种人民币玩家当皇帝的页游卡牌手游。
《龙珠》的超级赛亚人濒死状态疗伤恢复后战斗力会大增，应该是取材自现实，正如尼采说的，“杀不死我的，会让我变得更强大”。在受重大挫折后，只要熬过来了，内心就会变得更强大。
进化论像心灵鸡汤，咋一看很有道理，实际是怎么说都行，经不起推敲。例如人为什么会有害怕和恐惧的情绪，因为在老虎面前你不害怕和恐惧就挂了，那些不会害怕和恐惧的人已经灭绝了，但另一方面，为什么那些一害怕就腿软没有行动能力的人没有灭绝呢？他们理应逃不过虎口。
人们看重天赋>努力>外在条件，学生时期少不了一类学生总是说自己没学习，回到家偷偷学到半夜，考试成绩出来后把成绩归功于自己的天赋而不是努力。但靠努力奋斗获得成功又比靠关系靠是富二代这些外在条件获得成功更受人尊重。
很多人表达观点的时候，都会隐藏对他不利的事实，只说对他的论点有利的事实，如果这时候听者顺着他的思路，不思考提出疑问，就会陷入他构造的逻辑中，觉得很有道理，从而接受了观点，被洗脑。