知乎 · 热度

一些区别：

Ⅰ.

• 数据冗余量大的话，打包压缩能大幅度降低所需下载流量，单文件模式好些。

Ⅱ.

• 如果程式无需一次加载所有文件的话，多文件模式好些。

Ⅲ.

• 如果某些文件需要部分动态更新的话，多文件模式好些。

Ⅳ.

• 如果没实现「断点续传」的话，多文件模式好些。

Ⅰ. Font Awesome Icons

Ⅱ. Convert Icon Fonts To PNG

Ⅲ. Google Img :)

Ⅳ. Iconfont-阿里巴巴矢量图标库

答这个问题的，看来是挺难找到女朋友了。。

前端负责和用户交互，后端负责和计算机交互

谢邀。

• What Android device should I buy for Android app development?
• https://www.quora.com/What-is-the-best-Android-device-for-developing-apps-in-2015

貌似国际友人都更推荐谷歌亲儿子系列 Nexus (5)，主要原因是它的屏幕大小比较接近目前主流屏幕的平均水平，而且通常 Google 最先对它开放最新的 Android OS。

如果题主只考虑国内机子的话，还是买小米吧。

豆瓣态度也很明确了，这仅仅是个「能用的轮子」，并非代码托管的最佳实践，但它也有一些可取之处：

1. 用 Python 写的；

2. 一些豆瓣本地化的东西。

正好前几天在开发 Intellij IDEA（/Android Studio）的插件，官方教程可参考：

IntelliJ IDEA 15.0 Help :: Plugin Development Guidelines

我是在 Intellij IDEA 的社区版（免费版）上进行开发的，项目在这里：

nekocode/android-parcelable-intellij-plugin-kotlin · GitHub

。开发完的 Plugin 可以上传到 Jetbrains 的 Plugin Repository 上：

JetBrains Plugin Repository

在 Github 上有很多开源的 Intellij 插件，也可以翻看下，有很大的教学作用~

mcharmas/android-parcelable-intellij-plugin · GitHub inmite/android-selector-chapek · GitHub

早期一些 DOS 软件、游戏都是屏幕独占的。

但是从当时一些软体的 UI 就能看出，已经使用矩形来分割功能区。主要原因是：

• 屏幕是矩形的，应用的功能区应该和屏幕形状保持一致。
• 使用矩形能够更好利用有限的屏幕空间。
• 矩形在代码中更适合运算。（交并集运算等）

后期的一些 GUI OS（Windows，Mac，Linux），继承了使用矩形作为窗体的习惯，而且提供了绘制窗体的 GUI API，让平台下的应用也能创建风格一致的窗体。

当然 GUI OS 更重要的是创造了多任务的概念：在 OS 中不再只能运行单任务，多个任务（应用）可以并行处理。也就形成了现在多窗体的 GUI 模式。

同意

@vczh

的回答，在屏幕形状还是矩形的情况下，我觉得目前的 GUI 模式应该就是最终态了。

大多数 3D 游戏中的技能特效都是使用「粒子系统」渲染的。

特效设计师通常对 粒子形状、颜色、数量、运动轨迹这些可编程，可量化的信息比较敏感，通过不断调整粒子渲染的效果，然后多个粒子运动效果整合在一起就形成了单个技能特效。

整个设计流程的话，大概是：特效设计师用 AE，或者粒子模拟器 设计出效果，然后工程师再通过粒子系统模拟出最终效果

题主可以尝试下：

Cocos2dx 在线粒子编辑系统：http://www.effecthub.com/particle2dx

http://drops.wooyun.org/papers/10061

百度这厮也是够狠毒的了，本地开个 http 服务器，随便个网页发个 ajax 请求就能下载打开百度各种全家桶。

http://naotu.baidu.com/

flask + Jinjia2 + react，豆瓣的大神在这样搞

请使用 Android Studio 和 Gradle 来组织开发你的项目，这是官方推荐的工具集（Android Studio 是谷歌基于 IntelliJ IDEA 开发的，可以勉强算得上是官方开发的 IDE，和 Eclipse 的官方只提供插件支持完全不是一个态度）。

另外现在 Github 上大多数 Android 项目也都是用 Android Studio 来开发维护的。个人是国内最早一批从 Eclipse 转到 Android Studio 的开发者，从 0.x 版本到现在 1.x，Android Studio 对于 Android 开发的效率提高和亲和度都是 Eclipse 所无法比拟的。

PS：顺便可以跟上时代的步伐，尝试下同家 JetBrains 发布的 kotlin 语言~

• Getting started with Android and Kotlin
• nekocode/kotlin_android_base_framework · GitHub

5403 74dc ff0c 770b 4f1a 4e0d 4f1a 88ab 5220

crazyma/Android-Gradle-Sample · GitHub

Buck 的侵入性太强了，从 Gradle 切换过去的成本挺高的，现在 Android Studio 2.0 Preview 版已经出了，支持 Instant Run Feature！！！麻麻再也不用担心我的编译速度了。

这样子来修改 View 的属性

textView.text = "修改 textView 的内容"

这样子来处理事件

override fun onTouch(v: View, event: MotionEvent): Boolean {
    when (event.action) {
        MotionEvent.ACTION_DOWN -> showToast("ACTION_DOWN ")
        MotionEvent.ACTION_MOVE -> showToast("ACTION_MOVE ")
    }
    return true
}

这样子来使用 intent

val intent = intentFor<OtherActivity>(
    "model" to Model(5, 0),
    "str" to "xxx"
)
intent.singleTop()
startActivity(intent)

仅仅几行代码就定义了一个拥有单个 Fragment 的 Activity

public class MainActivity : SingleFragmentActivity() {
    override val fragmentClass = TestFragment::class.java

    override val fragmentBundle = {
        null
    }
}

这样子来储存本地数据（持久化）

Storage["test"] = Model(5, 1)

还有很多更多其他优雅的用法！！！请看：『Android 还可以这样开发』

安利完毕，别打我~

我大一的时候还真干过这事。。

不过是在自己电脑上弄的，这样舍友就再没用过我台式机玩游戏了 ：)

nekocode/Taskkiller · GitHub

readme 上对于为什么要使用 DSL 代替 XML 已经讲得非常清楚了（

https://github.com/JetBrains/anko#why-dsl

）

使用 XML 来描述 UI 的缺点：

• It is not typesafe
• It is not null-safe
• It forces you to write almost the same code for every layout you make
• XML is parsed on the device wasting CPU time and battery
• Most of all, it allows no code reuse.

可读性：DSL >= XML > normal code

执行效率：normal code >= DSL > XML

DSL 本身就是为配置而生，既然语言内部支持配置，为何要还要使用外部配置文件（XML）呢？

当然，要和其他应用交互时，也只能用外部文件了~

曾经大学时期写的一个 AVG 引擎：

nekocode/FScript0.15 · GitHub

单个项目的话大概只有接近一万，但是衍生出的其他项目加起来估计就有好几万了，当时的感觉就是 书中看到的东西永远都不如真正实践一次来的实在而且写的是你感兴趣的东西的话，更容易带动你去思考。

顺便提一下，其实大多数对游戏感兴趣的人，在大学阶段都可以去尝试下写些简单的游戏，甚至是 Game Engine ，开发一个 GE 所需要学习的知识太多了，例如 数学知识，三维空间知识，渲染技术，算法，语法解析，GPU 编程 甚至 简单的平面设计等（参考：

游戏开发的编程算不算是 IT 行业中难度最大的？ - 程序员

）

从游戏编程领域转到其他编程领域，很大程度上也会让你看事物的角度也发生改变，特别是转到前端开发上~ 你能理解大致知道程序 UI 是通过哪些步骤最终渲染到屏幕上的，对 Render 这个词也变得有特殊情感了

总而言之，你老师的话 大体上是没有错的，代码写得越多，你与机器就越亲近，越能理解如何通过语言与机器沟通。

去掉 33 岁，或者改成国外的话我觉得是有机会的。

但如果不是的话，不建议。国内内卷程度会让你绝望，就怕你被割几轮韭菜（报培训啥的）后结果还是只能屁颠屁颠的逃离这个行业（狗头

单纯一个 jar 包是不包含依赖信息的哦。可以传到 maven 仓库，然后在 pom 文件中添加依赖的第三方 jar 包。然后其他人通过 maven 依赖你的 jar 包时就会把依赖的其他 jar 包也依赖进去了。

DSL 的存在是必要的，但是是否应该给予普通人创建 DSL 的捷径确实有待商榷，毕竟不是所有人是领域或语言大师，过多的 DSL 只会造成干扰。