@Pzdmultiverse #17

第一步，写底层驱动，移植 Android OS，移植 Dalvik 虚拟机，主体就是这三大块。如果你是纯自研 CPU，甚至还要自己写编译器，自己搞工具链，把 Android 底层的 Linux 先移植过去。

第二步，我引用一段内容。

“大部分 Android 应用都使用基于 Dalvik Java 代码开发。理论上，由于 Dalvik 代码在系统的虚拟机中执行，在 x86 的 ATOM 平台上不会有性能损失。但由于虚拟机执行效率的有限，对于一些高性能追求的应用，谷歌允许开发者使用原生的 C 语言代码。而原生代码是针对硬件平台编译，x86，ARM 或是 MIPS 都有其相应的二进制文件。通常来说，针对 ARM 平台编译的二进制代码，x86 的处理器是无法直接运行的。而主流的安卓产品均采用 ARM 处理器，尽管很早之前，Google 的 Android NDK 就引入了 x86 编译的选项，但至今还是有相当一部分应用只针对 ARM 平台进行了编译，这就造成了 x86 安卓平台兼容性问题。” --- https://www.igao7.com/news/201406/x86.html

也只有苹果这种自己开发芯片，自己开发 S，自己做硬件产品的厂家，Mac OS 才能说迁移到 ARM 就迁移到 ARM，甚至即便如此，Apple 也是买了 ARM 的指令集，而没有自己开发一套指令集。

emmm，别人的例子是哪来借鉴的，不能因此对某种事物产生恐惧，因为有个“幸存者效应”

09 年的时候，Intel 想进军手机 Soc，搞了一个 Android_x86，
这个工作和苹果现在搞的 Mac OS on ARM and x86 工作非常类似。

第一步，Intel 就需要配合谷歌把 Android 移植到 x86 服务器上，从底层驱动到移植 Dalvik 虚拟机，工作量还挺大的，

第二步，x86 和 ARM 的指令集不同，有些应用还是不支持运行在 Android_x86 上，为了快速解决这些问题，英特尔试图通过技术去完善，开发了一种转换技术“Houdini”。“Houdini”相当于一个中间层，可以让原本不兼容的应用跑在 X86 上。但这种强行结合的技术运行起来往往效率不高，容易出问题，且会增加 2%左右的耗电。

第三步，为了彻底解决转换层的问题，英特尔就提供了 X86 的 NDK 。开发者只需在应用中支持这个 NDK，应用在提交时会自动生成 2 个 App，设备在下载时会根据自己的架构下载合适的 App 。这种方法并不难，效果也最好，难的是如何让众多开发商甘愿合作。所以英特尔以及手机厂商会去和应用厂商挨个合作，督促其支持 X86 的 NDK 。

第四步，Soc 有了，系统也支持了，没有手机厂商用怎么办，Intel 到处找硬件厂商推销自己的处理器，又是合作又是补贴，联想出了几款，其他厂商也有少量出货，但总体机型并不多。

你看，x86 这种成熟而完善的处理器，已经有完整工具链支持，要想和 ARM 竞争都如此困难，你从无到有设计一个新的指令集，成功的几率有多大？

糖尿病的健康情况，取决于你的血糖控制情况，

对你的饮食，对你的生活习惯，有了更严格的要求，

简单来说就是不能随便不当回事随便造，当然对生活也会带来一些负面影响。

1 、B 站盈利主体是游戏，不是 UGC，不是直播，不是短视频，也不是版权内容，
2 、B 站的 UGC 体验是国内同类产品中最好的，但是离 YouTube 很远，甚至比优腾爱和 Netflix 之间的距离还远，
3 、B 站的后发优势来自于良好的社区运营，有一大批稳定的用户和内容创作者，即使没落了也能活得像豆瓣一样，“粉丝 + UP 主”的组合，既像“微博网红 + 粉丝”模式，又像各种各样的豆瓣小组，真的让我很像请教一下 B 站运营这是怎么做到的。

我的会员续到 22 年了，最早续会员是为了看番剧，后来转移到其他版权内容（如电影）更多，总体时间上 UGC 内容占 6 成多，lv5 用户但大部分时间都是“下次也不一定”。我以前是高清视频爱好者，喜欢收集 4K HEVC 的各种影视内容，现在因为弹幕体验反而回去看那些“1080P 高码率”的内容，如果 B 站能在 4K 内容上继续发力，我的会员会一直续下去。

人终归是死的，这个问题非常虚无。

@ftu #44 事实上是既孤单又庸俗

建个群吧，我是从摇滚史密斯入门的。

@AlkTTT #1 同意 1 楼

我所知道的只有一个心理咨询师，有个证可以考。

我手里只有一块初版的 HK C2000 Pro 和 Intel 600P