鲜为人知的Titanium之线程

以下均为一个小白的见解，如若有误，望指教。。。
本人是一名手机移动应用端的软件开发者，近几个月来，根据公司的开发规划，采用的是Titanium mobile（该死的坑）这种开发环境。关于国内关于它的文章很少，有能力翻墙的同学，能看到它影子的也不多，有时遇到坑也难以解决，故写下这几个月遇到的坑。
关于Titanium的来源，优缺点，还有带来的影响啊什么的，这里不做解释，网上有，今天，我们来讨论的是，Titanium mobile 的android module里的一个坑。
在还没接触handle之前，我总以为，在异步操作中，只要使用handle，就能让我们android的线程操作进入主线程，但在module中，尤其是在Proxy文件里，它的线程操作异于常人。

@Kroll.proxy(creatableInModule=TextModule.class)
        public class ExampleProxy extends TiViewProxy
    {
        private class ExampleView extends TiUIView
    {
        setNativeView(new TiCompositeLayout(proxy.getActivity(), arrangement));
        }
    }

这个是我简化下来的代码片，上面的ExampleProxy是module的一个proxy对象，供Titanium App端调用，里面的ExampleView，是module的UI绘制类，看TiUIView我们就能知道。这里有个坑，我们知道android上的UI操作，都是在UI（主）线程上，但是ExampleProxy这个类，跑的居然不是主线程,而当我们需要在app端操作module的时候，只能通过ExampleProxy这个类才能操作ExampleView，这就导致了一个问题，主线程被其它线程保护了。
这里有两个办法。

1. 简单粗暴的广播
2. 灵活的回调接口
   通过handle是无法拯救世界的，handle并不一定跑在主线程上，这个要取决于所写的handle是谁的，一般我们在android的项目上，handle跑在Activity上，没问题，Activity本身就跑在主线程，但这一套用在Titanium上，是不管用的，handle跑在非主线程上，就注定无法更新UI了。
   回到上面的两个方法，我当时采用了第一这个比较笨的办法，用了广播，广播写在ExampleProxy上，app端一有消息通知，就用广播接收，然后再调用ExampleView的各种方法去更改UI。
   app—->Proxy—->广播—->UI
   通过这种办法，能让操作跑到主线程上。
   第二种方法，采用回调接口，在ExampleProxy定义自定义回调接口并设置app端接收方法，然后在ExampleView上调用自定义的接口，一有数据回调，UI这边就能接收到。
   app—->Proxy—->回调—->UI
   通过以上这两种办法，就能解决掉这一个坑了，同时也能了解到Handle不是万能的。。。。。