这个应该是每个人都会遇到的问题，想修改sencha touch的整体效果
但是不可能一个一个css去改
sencha touch提供的是rb + sass的方法
1. 安装ruby 去ruby官方下载安装 ，有win版本安装器
2. 在ruby/bin执行下面命令安装sass 和compass
gem install sass
gem install compass
3. 去sencha 项目resource/sass目录下copy 一份app.scss，然后进行修改
修改的方法看的是http://senchalearn.github.com/Touch-Theming/ 的案例代码
4. 编译
在ruby bin目录下，执行命令：compass compile project/resources/sass
5. 编译后会在project/resources/css目录下自动生成css文件
6. 在index.html中
<script id="microloader" type="text/javascript" src="/blog_article/touch/microloader/development.js"></script>
之后加上你的css文件应用
<link rel="stylesheet" href="/blog_article/resources/css/custom-theme.css" type="text/css" media="screen" title="no title" charset="utf-8">
7 看看成功了吧
手游市场繁荣背后，创业者不能盲目乐观
海豚(手机游戏从业者)
首先写这篇东西，真是抱着十分沉重的心情写的，几年前我针对WEBGAME(网页游戏)市场写了WEBGAME繁荣下的危机，之后之前写的所有东西都被市场一一验证了，同时各种类型的WEBGAME创业者该怎么死的也就怎么死了。现在同样的手机游戏也是开始了一片繁荣景象，满世界的投资资金，满世界的小创业团队，甚至可以说这波手游热潮比WEBGAME有过之而不及。本人希望这次写的东西能让正在满脑梦想的创业者对前路能有些清晰的认识。
这次不写市场分析了，手机游戏市场的火热种种网络上很多，不再多说，这次就说各个层次中的团队的死亡可能情况。
A类团队
已经拿到了千万的资金，这类团队是幸运的，在现有市场初期有了大把的钱可以用，短时间里不用为生存而烦恼，可以很开心的做着自己想做的产品。但是事情往往又不会以我们所想的去发展，这种团队往往大多会死的很突然，完了只有少数的公司能成功，怎么成功不分析了，就分析这类公司会怎么死。
第一种死法 有的只是鸡蛋，不是篮子
A类团队因为有了钱必然会迅速组建团队，同时起N个项目组同步走，从正常的思路来讲爷有钱，我多弄些产品，把鸡蛋多放些篮子里没有错，但恰恰就是这种思路是错的，因为我们的创业者其实没发现他们不是在放多个篮子，而是在多做N个鸡蛋，而他们的手就这么大，最后的结果显而易见，鸡蛋太多了他拿不住全砸了。当然有的会说我们有钱我们砸的起，但实际情况是杂技不是一天练成的，如果你的团队没有练杂技的天份，你有再多的钱也先静下心做好一款产品，当一款产品真真能赚钱了，再练杂技也不迟。
第二种死法 想当年
A类团队能拿到钱往往是有其原因的，大多比较普遍的是以前参与过某款千万级的成功产品，而投资方往往看重的也是这点，但也因为就是这点他们死在了想当年上。实际一款产品要做到千万级是需要一个非常庞大的团队来完成的，而如果人员只是参与过，而不是真真的团队决策者或老板的时候他们所能接触的面往往很局限的，一旦自己操作的时候就会很容易的犯想当然的错，我听的最多的就是我们以前的产品就是砸XXX百万的广告费的，所以我们也得砸，完了把所有的弹药都砸光了，最终鸡蛋成了荷包蛋再也孵不出小鸡了。所以如果你以前参与过成功产品，但绝对不表示你就能做出成功的产品，真正的成功是需要自己摸索出来，有钱了那就一点点摸石头过河，别急着表现自己。
A类团队的死法还有很多，只是上面两种往往是最可惜的，可能这些团队是真心想做事的，只是他们的认知偏差了，所以错过了机会。
B类团队
已经拿到了百万的资金，这类团队同样也是幸运的，在市场初期他们起码不会饿死，B类团队因为资金有限所以不会犯A类团队的错，因为他们的钱有限，所以不会有n个鸡蛋的问题，也不会有满世界砸钱的傻事。同时就个人认为在这波热浪里的确也是B团队是最有概率做出好产品来的。但是同样的这类团队也存在着致命的盲区。
第一种死法 自己把自己坑了
B类团队往往是先做一款产品，我们的创业者产品研发完毕沉浸在兴奋的愉悦中，完了团队的对外部门负责大量的渠道做接入，一切的一切很正常，也很自然的发展，但当团队接了无数的渠道后，突然发现产品怎么也赚不了钱，完了怎么办？产品质量有问题必需改，但同时业务部门不能停还得继续接，大多的决策者在面临这种状况的时候都会这么决策，而恰恰这看似对的决定，却会把大多的团队带进坑里。
现实的状况是渠道因为前期的进入时不够成熟，在同一时期所有的渠道将问题都反馈了回来，完了技术团队玩命似的解决问题，技术团队好的硬接住，技术团队不好的立马就接不住了，很快运营团队就会因技术团队不给力而抱怨，完了运营团队又同时不断的给技术团队大量的产品修改意见，整个团队因为前期的快速发展渠道而进入彻底的混乱，最终进入一个死循环，渠道越多产品团队的工作量越大，而修改内容也越多，最终产品的整改很可能会进入盲目性阶段，这时候团队离死就不远了。
当你的产品还不能真正赚钱的时候，先只做个别渠道，别急于开展业务，你的产品的研发是上线后才真正开始，当产品达到真正能赚钱的时候再全速开展渠道才是最适合的。
第二种死法 渠道太坑爹
B类团队上面的那种死法的很多，那正确的就是先集中在一个渠道上，把自己的产品优化好，完了再迅速扩展出去，这个思路是正确的，但是往往我们的团队还是会死。因为会被渠道坑死，现在稍微大些的渠道都会配备一个运营团队用来审核和评估产品商的产品质量，但有点千万记住，只是审核和评估，不是优化。
我们的创业团队往往会盲从大渠道的运营，这不是说渠道的运营团队不会做运营，不懂得优化产品，只是产品团队不明白渠道商的运营人员每天面对的是海量的产品，他们对一款产品的关注度是有限的，往往渠道的运营是处于好意将自己对产品的感受会告诉产品商，完了产品商就会按渠道商的意见去改产品，但这时候问题就出现了，渠道商实际看的主要数据就是ARPU值和留存率，一个运营在不了解产品本身内部用户行为数据的情况下，给出的产品意见，往往是运营人员本人个体的感受，针对个体感受去改产品可想而知。
最后的结果就是我们的团队不断的按渠道意见改啊改，渠道不断的反馈数据还是不行，完了改个两三轮，产品团队基本也就又一次迷茫了，我们的产品是不是选错了，这时要么团队开始硬铺渠道回到第一种死法，要么团队开始做新产品回到A类产品的多个鸡蛋的死法。
其实团队要优化好自己的产品首先必须有自己的数据分析和挖掘能力，如果没有，那就外部引入资源，但绝对需要保证自己的团队能把产品向正确的方向优化，而不是带进坑里。完了记住一点一款产品优化不能超过3个月，3个月还没优化好，那就不是产品的问题，而是人的问题，在哪个环节一定出错了，迅速找出问题的人，解决了再前进。
B类团队最有可能出精品游戏的层次，因为容易专注，但专注的同时是不是真的够快，够精准了将会决定团队的生死。
C类团队
C类团队是现在市场里最多的，苦逼的创业者，没有大的资金，蜗居在小办公室里，几台电脑，埋头苦干，做着一夜暴富的美梦。这类团队是最有活力的，同时也是死的最快的，但也是市场的砥柱。对于这些团队怎么死就不写了，就写些大多的误区。
第一个误区 有了想法和几个核心团队人员就能找钱了
很多的创业者都以为有了想法和几个一起拼的兄弟就可以找投资了，但事实是人家为什么要为你的想法而买单，这个问题这些创业者都没想过，想法还没成为产品前那只是一个想法，对于投资人而言这个一文不值。当然有人会说人家不是有人拿个想法找到钱了吗，的确这个是有，但那个是可遇不可求的，就投资人的角度而言最好的是风险越低的项目他们越愿意投，而不是想法越新颖他们就越愿意投，因为投资人做的是一门纯粹的生意，生意的基本原则是赚钱，你连自己能不能赚钱都不知道的情况下，一个想法能找到钱的可能几乎和中奖差不多。投资人的钱只是锦上添花，不是雪中送碳。如果你有了想法和团队，尽快把想法变成现实，完了再去找钱会顺利的多。
第二个误区 产品出来了就可以赚钱
很多创业者开发完毕就以为可以赚钱，事实是产品不能让市场认可，那产品出来就是团队的死期了，团队老大必须考虑一个问题，就是如何让自己的团队尽可能的借用外力达到自己产品赚钱的目的。产品的数据挖掘，产品优化，渠道资源如何解决，这些是必须要考虑好的，不然就真的产品出来了，你也就死了。合理利用外部资源让自己活下来很重要。
第三个误区 我产品赚钱了还要找钱干吗
创业者说既然我的产品能赚钱了还要找钱干吗，当然是不能赚钱的时候找钱，但其实他们一样的一个问题，投资人是在做门生意，你的生意不能赚钱那只能求人家，但你的产品能赚钱了，哪怕只是比够养活团队多1块钱，那你的生意就是赚钱的，这时候你去找钱，投资人是会很欢迎的，而不是你去求投资人或说服投资人，另外找投资人的最大目的不是改善团队的现有生存环境，更多的因该是通过投资方资金以外的资源来支持自己的项目这个是重中之重，只能给钱不能给团队别的帮助的投资人，对团队而言是最没价值的。团队需要具有生存能力，当你的生存能力修炼成了，之后你会走的更好。
原文地址
Canvas and Drawables
Android Framework层的API为用户提供了2D 绘画的API，使得用户可以在画布上绘制自定义的图形，或者根据用户自己的审美和感觉进行修改现有的View对象。当想要绘制2D图形的时候，您可能使用以下一两种方式：
A. 在Layout中的View对象时行绘制图形或者动画。使用这种方式绘制，您绘制的图形是由系统绘制view图层来进行绘制的—您只需要简单的在view中绘制图形即可。
B. 直接在画布上绘制图形。使用这种方式，您需要手动的调用响应类的onDraw()方法（将图像传递给Canvas），或者调用Canvas的draw…()方法（比如 drawPicture()）。使用这种方法，你还可以控制任何动画。
方法A，在View对象上绘制，如果您想要绘制简单的图形或者不需要定期变化且不属于密集型游戏，方法A将是最好的选择。比如，假如你想要绘制一个静态的图形或者动画，您应该在View上绘制图形。阅读Drawables部分内容获取更多信息。
方法B，在画布上绘制，当您需要定期重绘的话，这会是更好的选择。比如视频游戏应该在Canvas上绘制。然而，有更多的方法可以完成绘制：
在于UI Activity相同的线程中，当在Layout中创建自定义View的时候，要调用invalidate()方法，并且处理onDraw()方法的回调。
如果是一个单独的线程，管理着SurfaceView对象，并且使用线程来执行把图形绘制到Canvas对象上的任务（不需要请求invalidate()方法）。
Draw with a Canvas当您正在进行专业的绘图或者想要控制图形的动画的时候，您应该在画布上绘制来完成。Canvas作为一个虚拟的绘图接口存在，实际的图像是绘制在Canvas上的，Canvas持有所有的”draw”的方法。通过Canvas，您绘制的图形将会在基本的位图之上展现在窗口上。
在onDraw()回调方法的绘制事件中，会提供一个Canvas对象，并且只需要把要绘制的内容交给Canvas对象就可以了。在处理SurfaceView对象时，还可以从SurfaceHolder.lockCanvas()方法来获取一个Canvas对象。但是，如果需要创建一个新的Canvas对象，那么就必须在实际执行绘制处理的Canvas对象上定义Bitmap对象。对于Canvas对象来说，这个Bitmap对象是始终必须的，应该像以下示例这样建立一个新的Canvas对象：
Bitmap b = Bitmap.createBitmap(100, 100, Bitmap.Config.ARGB_8888); Canvas c = new Canvas(b);
现在您的Canvas对象将会被绘制在已经定义好的Bitmap对象上了。当在Canvas上绘制完毕之后，您可以通过调用Canvas.drawBitmap(Bitmap,…)方法来将这个Bitmap绘制在其他的Canvas对象上。使用通过View.onDraw()方法或者SurfaceHolder.lockCanvas()方法得到的Canvas对象来绘制最终的图形是被推荐的。（也就是用这两个方法参数中传入的Canvas进行绘制）
Canvas类有可以使用的自己的一组绘图方法，如drawBitmap(…)、drawRect(…)、drawText(…)等。还可以使用其他的有draw()方法类。例如，可能想要把某些Drawable对象放到Canvas对象上。Drawable类就有带有Canvas对象作为参数的draw()方法。
On a View
假如您的应用程序中不需要大量的图形处理和很高的帧频率（比如国际象棋，贪吃蛇游戏，或者其他慢动画程序），那么您应该考虑创建自定义View组件，并且通过View.onDraw()方法进行绘制。这种方式最方便的一点在于，android framework层将为您提供预定义的Canvas来让您直接在上边进行绘制。
首先，要继承View类或者View的子类，然后定义onDraw()这个回调方法。这个方法将会被android framework调用来绘制这个View对象本身。这也是通过Canvas对象来执行所有的图形绘制调用的地方，这个Canvas对象是由onDraw()回调方法传入的。
Android framework 只会在必要的时候调用onDraw()方法。每次想要进行绘制的时候，必须要调用View对象的invalidate（）方法来使得这个View对象失效。这表明您骁勇让View通过调用onDraw方法进行绘制（尽管不能保证每次调用invalidate方法后都会瞬间进行回调onDraw方法）。
注意：为了在一个线程中而不是主Activity的线程中发出一个失效请求，必须调用postInvalidate()。
有关继承View类的更多信息，请阅读创建定制化的组件（http://developer.android.com/guide/topics/ui/custom-components.html）
示例程序，请看Snake游戏，它在SDK示例代码文件：<your-sdk-directory>/samples/Snake/.。
On a SurfaceViewSurfaceView对象是一个特殊的View类的子类，它在View层次树内提供了一个专用的图形绘制平面。这个图形绘制表面的主要目的是给应用程序提供一个辅助线程，以便应用程序不需要等待完成对系统的View层次树的绘制。相反，引用SurfaceView对象的辅助线程能够按照自己的节奏，把自己绘制在Canvas对象上。
首先需要创建一个继承SurfaceView类的子类。该子类还应该实现SurfaceHolder.Callback类，它是一个能够通知底层Surface类所发生的信息的接口。如Surface的创建、变化或销毁等。这些事件对于了解什么时候能够开始绘制图形、是否需要基于新的表面属性来进行调整、以及什么时候终止图形绘制和杀死某些任务，是至关重要的。在SurfaceView子类的内部也是定义辅助线程类的好地方，它会执行所有的把图形绘制到Canvas对象上的处理。
不要直接处理Surface对象，应该通过SurfaceHolder对象来处理它。因此，在SurfaceView子类被初始化的时候，要通过调用getHolder()方法来获得SurfaceHolder对象。然后应该通过调用addCallback()方法，来通知SurfaceHolder对象，它所能够接收SurfaceHolder回调对象（SurfaceHolder.Callback），然后再重写SurfaceView子类内部的每个SurfaceHolder.CallBacke方法。
为了能够在辅助线程内把图形绘制到Surface对象的Canvas对象上，必须把SurfaceHondler对象和用lockCanvas()方法获取的Canvas对象传递给辅助线程。现在就能够用给定的SurfaceHolder对象和Canvas对象开始图形绘制工作了，一旦用该Canvas对象完成了图形绘制任务，就要调用unlockCanvasAndPost()方法，把绘图用Canvas对象传递给该方法。现在Surface对象就会离开绘制图形的Canvas对象。每次想要重新绘制图形时，都要执行这个锁定和解锁的过程。
注意：每个通过SurfaceHolder对象获取的Canvas对象，它之前的状态都会被保留。为了正确的处理该图形，必须重新绘制整个Surface对象。例如，能够清除之前用drawColor()方法填充在Canvas对象中的颜色，或者是用drawBitmap()方法设置的背景图片。否则，就会看到之前被执行的图形绘制的轨迹。
示例应用程序，请看Lunar Lander游戏，它在SDK的示例文件夹：<your-sdk-directory>/samples/LunarLander/。