知乎 · 热度

碎片化

这是在黑 Kotlin 么。。

Kotlin 过去可不是为了成为 Java8 的取代物而生的（更不是为了 Android 而生，而且要知道 Kotlin 比 Java8 还早出世），它和 Scala，Groovy 等 JVM 语言一样都不是基于 Java 本身语法的拓展，所以它是一门新的语言。它包含了 FP 的思想，支持创建 DSL，有着类 Swift 的安全类型，还有 Extension 等语法糖，更重要的是不用写分号了_(°ω°」 ∠)，这是有历史包袱的 Java，Java8 达不到的。

当然，Java8 肯定也会解救更大一票的 Android 开发者，至少不用再为没法使用 Lambda 而伤心了（手码字，逃

Java 是最贴近 JVM 的语言，只要在对性能还有要求的情况下，Java 依旧是 JVM 上的首选。

事实上在对任何语言进行选择时，都是基于对运行效率和开发效率之间的权衡。所以在我看来 Kotlin 是不可能取代 Java 的（官方也从未立意过要取代），但表达能力更强的 Kotlin 在一些地方肯定会比 Java 更适合，例如一些更高层的逻辑。我觉得就会像 Unity3D 引擎用 C/C++ 来写，但是游戏逻辑会选择用 C# 一样。

谢邀。一个比较不错的解决方案：

chrisjenx/Calligraphy · GitHub

Custom font in Styles

<style name="TextViewCustomFont">
    <item name="fontPath">fonts/RobotoCondensed-Regular.ttf</item>
</style>

Custom font defined in Theme

<style name="AppTheme" parent="android:Theme.Holo.Light.DarkActionBar">
    <item name="android:textViewStyle">@style/AppTheme.Widget.TextView</item>
</style>

<style name="AppTheme.Widget"/>

<style name="AppTheme.Widget.TextView" parent="android:Widget.Holo.Light.TextView">
    <item name="fontPath">fonts/Roboto-ThinItalic.ttf</item>
</style>

上面的 Styles 配置，可以方便地把应用内所有 TextView 的字体配置为「Roboto-ThinItalic」（需要字体文件支持）。但是需要对 Activity 做一些 Wrap：

@Override
protected void attachBaseContext(Context newBase) {
    super.attachBaseContext(CalligraphyContextWrapper.wrap(newBase));
}

大部分答主都讲出原因了。我解释下为什么会要求只在 UI 线程修改 UI：

绝大部分 GUI 系统都是只允许「单个线程对某块区域做绘制操作的」，例如在 Windows 和 Android 系统下都把这块区域叫做 Window。如果允许多个线程对同一块区域做绘制的话，很有可能导致某个线程还没绘制完，另一个线程上一些依赖之前绘制结果的操作出问题，例如 Alpha 混合。除非加锁，然而加锁更慢还不如单线程。

1. 转行做投资人，实现财务自由，找个高层次圈子内的老婆，过美滋滋的生活。

2. 投入大量资本去做「自己想做的产品」，建立下一个能 IPO 的企业。

3. 一觉梦醒。。。继续搬砖去

很小的时候就一直有在接触编程了，但正式开始写第一个意义上的程序，是在读初三的时候。到目前为止，刚好写了有十年。按照时间前后排序，学过的语言有 ActionScript、VB、C++、Lua、Java、Python、Kotlin。感受是，读书时能经常在同学面前显摆，例如给课堂讲座上的电脑写上「病毒」，在同座的文曲星上写游戏解闷，大学时因为写代码厉害泡到了前女友，工作时又因为起步比别人早，拿到了很多便利。

这是个传奇的故事！做过 ACM 的人大概都知道：

Quake-III Arena (雷神之锤3)是90年代的经典游戏之一。该系列的游戏不但画面和内容不错，而且即使计算机配置低，也能极其流畅地运行。这要归功于它3D引擎的开发者约翰-卡马克（John Carmack）。事实上早在90年代初DOS时代，只要能在PC上搞个小动画都能让人惊叹一番的时候，John Carmack就推出了石破天惊的Castle Wolfstein, 然后再接再励，doom, doomII, Quake…每次都把3-D技术推到极致。他的3D引擎代码资极度高效，几乎是在压榨PC机的每条运算指令。当初MS的Direct3D也得听取他的意见，修改了不少API。

最近，QUAKE的开发商ID SOFTWARE 遵守GPL协议，公开了QUAKE-III的原代码，让世人有幸目睹Carmack传奇的3D引擎的原码。这是QUAKE-III原代码的下载地址：
http://www.fileshack.com/file.x?fid=7547

(下面是官方的下载网址，搜索 “quake3-1.32b-source.zip” 可以找到一大堆中文网页的。ftp://ftp.idsoftware.com/idstuff/source/quake3-1.32b-source.zip) )

我们知道，越底层的函数，调用越频繁。3D引擎归根到底还是数学运算。那么找到最底层的数学运算函数（在game/code/q_math.c）， 必然是精心编写的。里面有很多有趣的函数，很多都令人惊奇，估计我们几年时间都学不完。在game/code/q_math.c里发现了这样一段代码。它的作用是将一个数开平方并取倒，经测试这段代码比(float)(1.0/sqrt(x))快4倍：

float Q_rsqrt( float number )
{
	long i;
	float x2, y;
	const float threehalfs = 1.5F;

	x2 = number * 0.5F;
	y   = number;
	i   = * ( long * ) &y;   // evil floating point bit level hacking
	i   = 0x5f3759df - ( i >> 1 ); // what the fuck?
	y   = * ( float * ) &i;
	y   = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
	// y   = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed

	#ifndef Q3_VM
	#ifdef __linux__
		 assert( !isnan(y) ); // bk010122 - FPE?
	#endif
	#endif
	return y;
}  

函数返回1/sqrt(x)，这个函数在图像处理中比sqrt(x)更有用。
注意到这个函数只用了一次叠代！（其实就是根本没用叠代，直接运算）。编译，实验，这个函数不仅工作的很好，而且比标准的sqrt()函数快4倍！要知道，编译器自带的函数，可是经过严格仔细的汇编优化的啊！
这个简洁的函数，最核心，也是最让人费解的，就是标注了“what the fuck?”的一句
i = 0x5f3759df - ( i » 1 );

再加上y = y * ( threehalfs - ( x2 * y * y ) );
两句话就完成了开方运算！而且注意到，核心那句是定点移位运算，速度极快！特别在很多没有乘法指令的RISC结构CPU上，这样做是极其高效的。

算法的原理其实不复杂,就是牛顿迭代法,用x-f(x)/f’(x)来不断的逼近f(x)=a的根。

没错，一般的求平方根都是这么循环迭代算的但是卡马克(quake3作者)真正牛B的地方是他选择了一个神秘的常数0x5f3759df 来计算那个猜测值，就是我们加注释的那一行，那一行算出的值非常接近1/sqrt(n)，这样我们只需要2次牛顿迭代就可以达到我们所需要的精度。好吧如果这个还不算NB,接着看:

普渡大学的数学家Chris Lomont看了以后觉得有趣，决定要研究一下卡马克弄出来的这个猜测值有什么奥秘。Lomont也是个牛人，在精心研究之后从理论上也推导出一个最佳猜测值，和卡马克的数字非常接近, 0x5f37642f。卡马克真牛，他是外星人吗？

传奇并没有在这里结束。Lomont计算出结果以后非常满意，于是拿自己计算出的起始值和卡马克的神秘数字做比赛，看看谁的数字能够更快更精确的求得平方根。结果是卡马克赢了… 谁也不知道卡马克是怎么找到这个数字的。

最后Lomont怒了，采用暴力方法一个数字一个数字试过来，终于找到一个比卡马克数字要好上那么一丁点的数字，虽然实际上这两个数字所产生的结果非常近似，这个暴力得出的数字是0x5f375a86。

Lomont为此写下一篇论文，“Fast Inverse Square Root”。 论文下载地址：
http://www.math.purdue.edu/~clomont/Math/Papers/2003/InvSqrt.pdf
http://www.matrix67.com/data/InvSqrt.pdf

参考：<IEEE Standard 754 for Binary Floating-Point Arithmetic>

最后，给出最精简的1/sqrt()函数：

float InvSqrt(float x)
{
	float xhalf = 0.5f*x;
	int i = *(int*)&x; // get bits for floating VALUE 
	i = 0x5f375a86- (i>>1); // gives initial guess y0
	x = *(float*)&i; // convert bits BACK to float
	x = x*(1.5f-xhalf*x*x); // Newton step, repeating increases accuracy
	return x;
}  

大家可以尝试在PC机、51、AVR、430、ARM、上面编译并实验，惊讶一下它的工作效率。

前两天有一则新闻，大意是说 Ryszard Sommefeldt 很久以前看到这么样的一段 code (可能出自 Quake III 的 source code)：

float InvSqrt (float x) 
{
	float xhalf = 0.5f*x;
	int i = *(int*)&x;
	i = 0x5f3759df - (i>>1);
	x = *(float*)&i;
	x = x*(1.5f - xhalf*x*x);
	return x;
}

他一看之下惊为天人，想要拜见这位前辈高人，但是一路追寻下去却一直找不到人；同时间也有其他人在找，虽然也没找到出处，但是 Chris Lomont 写了一篇论文 (in PDF) 解析这段 code 的算法 (用的是 Newton’s Method，牛顿法；比较重要的是后半段讲到怎么找出神奇的 0x5f3759df 的)。
PS. 这个 function 之所以重要，是因为求 开根号倒数 这个动作在 3D 运算 (向量运算的部份) 里面常常会用到，如果你用最原始的 sqrt() 然后再倒数的话，速度比上面的这个版本大概慢了四倍吧… XD
PS2. 在他们追寻的过程中，有人提到一份叫做 MIT HACKMEM 的文件，这是 1970 年代的 MIT 强者们做的一些笔记 (hack memo)，大部份是 algorithm，有些 code 是 PDP-10 asm 写的，另外有少数是 C code (有人整理了一份列表)

看有人拿 XML 和 JSON 做比较，顺便补一点：

XML 是「文档标记语言」，而 JSON 是「数据交互语言」，XML 比起 JSON 描述能力要强，所以在描述复杂文档的时候会选用 XML（例如 Layout 文件）。但是 JSON 比 XML 更为 Human readable、更易编写，也对机器更为友好，所以用 JSON 来储存一些简单的配置是比 XML 要好用得多的（例如大家都知道的 Shadowsocks 就是使用 JSON 进行应用配置）。但是 JSON 天生描述能力不强，它擅长的是描述数据，而非文档（配置其实也是文档的一种），所以稍微复杂的文档是不会使用 JSON 来描述，这也就是为什么会衍生出 YAML、TOML 一类语言的原因（拒绝拥抱 XML 的后果）。

===

SharedPreferences 是一整套东西啊，PreferencesActivity 也依赖于它。所以对实现 APP 偏好设置来说，它就是「最方便的实现」，你不用关心它底层是用数据结构去储存的，只是 Android 选择用 XML 去描述而已。

而 SQLite 是关系数据库，数据间有较复杂关系的，操作需要用到复杂的增删改查，无疑使用 SQLite 是最好的方案。

而题主说的一些轻量的数据，确实是持久化为文件更方便。如果是储存 用户偏好设置 还是用 SharedPreferences 来解决方便多了，无需接触到数据格式。如果并非面向用户，而是面向应用或面向开发者的话（例如一些 应用配置、常用数据），JSON 是不错的选择，毕竟 JSON 比起 XML 来说更易阅读与调试。

当然 JSON 也不是唯一选择，应用配置的话用 YAML 或 TOML 更好（更强的描述能力，更少冗余），只不过 JSON 应用更广泛罢了。

谢邀。

王の宝库，出来吧：

• RxMarbles: Interactive diagrams of Rx Observables
• ReactiveX文档中文翻译

讲讲第一项。别说，这可真是个宝物，知道在我的收藏夹里面怎么称呼它么？

『RxJava 操作符可视化』

什么概念？

看过官方文档里的观察流示例图片吧？好的，这就是那个的可交互版本哦！能对操作符的作用有更直接的了解。

其实是「在国内 APP 越来越难做」，个人认为有以下几个原因：

• 占大头的 APP 都在往平台级发展，超级 APP 功能越来越发散，逐渐侵蚀其他领域的市场。

• 微信，UC 浏览器此类产品开放 APP 内子产品开发平台，令 APP 开发者左右为难。就拿微信来说，很多时候，开发一款 APP 的产出投入比远远不及做公众号高，于是很大部分开发者会更倾向于开发公众号（微信用户基数大，应用内传播方便，公众号开发成本低）。

• 国内产品乃至创投圈风气不好，都想打擦边球，吃快餐，抄抄抄，塞塞赛，概念满天飞。『站在中国风口上的猪，还真的能飞得起来』。

• 在国内，知识产权就是个屁。没有绝对的技术壁垒和积累，就等着随时被巨头啃掉，所以大多数创业团队都只能跑去做巨头无法触及的领域，乃至于现在提「社交」色变。国外都是收购，并购，国内就是有好的 idea 大家一起抄，抄着抄着巨头不乐意了，也抄了起来，很多时候就变成了一场「能否在巨头之前积累足够资本」的博弈。。最蛋疼的是 idea 很多时候还是来自国外。

• 中国用户对应用忠诚度很低（国内产品的体验差，玩法单一等原因）

相对于美国国外的用户，美国用户对应用的忠诚度更高。在美国，被用户多次打开的应用占比今年上升了1%，至42%。这可能是由于，大量广告吸引用户重新打开已安装的应用。在美国，只被打开过一次的应用占比为19%，与去年持平。然而在美国国外，尤其是中国，应用只被打开一次的概率很高。在中国，有37%的应用只被打开过一次，远高于2014年时的26%。

说到底，是因为

我会跳街舞，Breaking。

算不上什么神技能，但确实可以算隐藏得很深了，谁会想到程序员还会跳街舞呢，而且还是最难最危险的 Breaking。。。说起为什么会学的话要从高中说起，那时和几个死党一起看了个 Breaking 的比赛视屏，看着屏幕里的人做出各种帅爆的动作，瞬间中二魂爆发，我们几个当即就立志要成为 B-boy，想着在毕业前一定要学会几个 Powermove。从此以后，每天下课和每次体育课自由活动时间，我们都到处找干净的空地，然后跟着视屏练习，甚至有几次我们还撬开了学校舞蹈室的门（拧开螺丝就能进去，出来后拧回去就是了）进去对着镜子练，后来被发现后学校换了锁就进不去了。

后来上大学，顺利加入了学院的街舞队，甚至还在学院运动会和联谊晚会上表演过。

我们舞队的照片。

但遗憾的是，大一之后就没有坚持下去了，很大的一个原因是因为大学里真正玩 Breaking 的人并不多，大多数 Dancer 玩的是难度稍低的 Popping，而且关键是再也找不到像高中那几个死党一样对 Breaking 狂热的人和我一起练习了。

把她弄成现在这样不太好吧：

AutumnsWindsGoodBye (Crying) · GitHub

虽然她技术不怎么样，但是之前她还打算建一个 Organization 来做一些国外前端文章翻译的工作，当时我也在她们 Group 里。

少点网络暴力，多点宽容吧。

＝＝＝

问题的 “为什么有人GitHub排行很低，不仅不向排行高的学习，反而去黑排行高的？” 会不会给人一种 排名高就代表技术好的钦定的感觉？

说实话，

@秋风

的技术真不怎么样，用机器人 follow 别人来刷粉的行为也有不妥。不过想想，刷粉的人大有人在，大多数当初反 follow 她的人更可能是因为她是个妹子而且头像美，和她技术没多大关系（逃。。

其实她只是个很会运营（Github，知乎，甚至 QQ 群）的懂点前端的长得还可以的妹子而已。不过想想，你们 follow 她的时候还不都是因为她的（给自己挂的）程序媛标签，现在怎么反过来黑别人的技术了。

首先，题主的出发点是完全错误的。既然题主自认为技术很扎实，那你就不应该一开始就想着如何造假，而应该考虑如何弱化简历上自己短板（项目经验），突出自己的强项，体现自身的价值。其次，没有职业道德的人无论到哪（包括知乎）都是不受欢迎的。你在这提问如何造假，只会成为嘲讽 or 被攻击对象。

自身短板的形成必然是有原因的，把所有原因都归咎到其他事物身上（老东家），这是对自己极其不负责任的表现。公司项目不怎样，但是利用自己空余时间投身到写博客或开源项目中的人也大有人在啊，别人在恶补自己短板的时候题主又在干些什么，。。

让人发现你伪造履历的话，肯定是进企业黑名单的，希望你能慎重考虑下。哪怕你真的造假去面试，但是最后可能会发现其实问题不出在这，你还是只值这个价。至少我们公司是不会请这种人，更别谈值什么价了。

首先， Visual Studio 先用各种领先 IDE 技术吸引大批 Android 开发者。然后，，就可以鼓吹开发者，以低成本将 Android 应用迁移到 Windows Phone 系统上啦。

navie

不显示 UAC 窗口的话（bypass UAC）必须使用 hack 的方法：

nishang/Invoke-PsUACme.ps1· GitHub

或者参考下我写的渗透脚本（bat & ps1）：

nekocode/win_penetration · GitHub

可以绕过 UAC 获取管理员权限。但是里面有很多其他危险操作，不要乱试。

==== 想知道 bypass 原理的话可以评论下，我再补上 ====

如果是简单的数据处理的话，我会用 @justjavac 答案里的做法：直接在 rendering 里处理数据。但是如果是计算密集的处理的话，我建议用 useMemo:

const { data: data1 } = //...

const parsedData1 = useMemo(
  () => data1?.data ? JSON.parse(data1.data) : undefined,
[data1]);

另外，如果答主一定要维护额外的 state 的话（例如在其他地方需要改变 state），那就把你那个大的 useEffect 拆分成四个小的 useEffect 吧。

再假设你想要等四个请求都完成再 setState 的话，可以:

const dataRef = useRef([data1, data2, data3, data3]);
dataRef.current = [data1, data2, data3, data3];

const isDone = data1?.data && data2?.data && data3?.data && data4?.data;
useEffect(() => {
  if (isDone) {
    setState1(dataRef.current[0]);
    setState2(dataRef.current[1]);
    setState3(dataRef.current[2]);
    setState4(dataRef.current[4]);
  }
}, [isDone])

这里只是提供思路，换我的话我是不会用四个 state 来维护状态。

提一个，Android Studio 自带的 Profiler 还不够好用，例如：

• Method Tracing 完之后没法中断 Monitor，导致越来越卡
• 自带打开 Trace 文件的功能，可视化很烂，基本没法用，而且没法用 Profiler 打开
• 感觉 Profiler 的 Method Tracing 这块有些地方做得没之前的 TraceView 好
• 等等

不问是不是，就问为什么。

绝大部分长得丑的人都不自恋，只是长得丑而又自恋的人显得格外突出而已。

流行的有两种方案：

1. 明转义

这是很多 SNS 网站的做法（例如新浪微博、知乎）：

@+用户昵称+空格（也可以为其他用户名称中禁止的字符）

这种方法的局限在于：

• 用户昵称不能含有空格
• 用户昵称必须唯一

2.暗转义

大部分即时聊天工具有这种（例如 QQ、Wechat），它的一个原始形式如下：

转义开始符+UID+转义结束符

经过 UI 层转义后向用户显示的是：

@+用户昵称

这种方法的好处在于：

• 用户昵称可以不唯一
• @ 符号去除了特殊意义（注意这里的 @ 不是转义符号了）

坏处在于实现起来比明转义稍微复杂一些。

应该如何选择？

• @ 的对象没有范围限制的话，选择明转义
• 昵称唯一化，选择明转义
• @ 的对象有范围限制的话（好友，群），可以选择暗转义
• 即时聊天的话，选择暗转义（能明确地指定所 @ 的对象）

个人认为应该尽量使用 useMemo 和 useCallback。

所有 rendering 中创建的 callback 尽量用 useCallback 包起来、对象的创建尽量用 useMemo 包起来。

hooks 具有依赖传递性，这么做主要是为了避免触发可能隐藏在某个子组件里的多余的副作用，以及副作用最终可能造成的 re-render（甚至死循环）。

试想一下你写了个组件，props 里需要传进一个 callback 来响应 dom 事件。一开始不用 useCallback 可能没问题，但是某天当你突然要改成在 useEffect 里去响应这个 callback 的话那就崩了，你不得不把上层所有组件传参时都用 useCallback 包一下，如果你这个组件在很底层，那么扩散范围将特别大，更不说跨 package 这种更糟糕的情况了。

这类情况还是很常见的，为了减少心智成本（对于究竟要不要/能不能用的患得患失）、以及不必要的埋坑，尽量使用 useMemo 和 useCallback 很有必要。

非专业前端工程师，发表些业余看法：

Vue 是传统的在 Html 里写 Js，而 React 则是在 Js 里写 Html。（题外话：作为一个 Android 工程师，感觉这有点像 Databinding 和 Anko 之间的差异）

Vue 的好处是非侵入，不需要重构，在原有的 Html 和 Js 基础上改就行了。React 的话则更可能需要大面积重构整个项目。

论上手简单的话，对于前端工程师应该 Vue 确实会更容易一些吧？毕竟思维上不需要做什么转变。但是对于零基础的人，感觉其实差不多，个人喜欢 React 多些。

Hybrid？效率已经不是问题？

自欺欺人，HTML 实现一个 Android 抽屉就卡出翔来。

HTML5 的优势在于排版，要做出相同效果的 Native 界面排版成本太大，所以内容展示页可以考虑使用 Hybrid 开发。逻辑关系复杂的页面还是老老实实用 Native 开发吧。

React Native？

还早着呢，Virtual DOM 对于需要复杂更新的页面一样显得乏力。这东西确实可以关注，热更新对于 Native APP 来说就是硬伤，React Native 不仅很好地解决了跨平台问题，还解决了热更新问题。

至于纯 HTML5 APP？

个人觉得不是很重度的 APP 都可以用 H5 来做，开发 Android 和 iOS 端的成本太高。现在不是还有 微信，公众号等平台么。

මම ඔබට කියන්න අවශ්ය, මම ඔයාට ආදරෙයි

试试复制第一行的，android 系统下无法正常显示的。

至于为什么无法显示是因为系统没装这种语种的字体文件，无法得知该类字体该如何渲染。打个比方，如果某美国人手机系统的字体库里只安装了英文字体的话，那么他们看中文也会无法正常显示。