前端开发IDE、JS神器WebStorm5详细介绍

其不仅能为用户提供输入，还能够根据(用户)执行的动作，提供相应的反馈。

因此，作为开发人员，能够理解UI(用户界面)是如何创建以及跟新的，就显得尤为重要。

ViewTreeView 和 ViewGroup 是Android UI的基本组件， 而ViewGroup作为容器，可以包含一组View， 并且ViewGroup其本身就是View的扩展。

看源码：public abstract class ViewGroup extends View implements ViewParent, ViewManager{} 而各种不同的Widgets 像TextView, Button 等等 也是View的扩展，只不过是放在各种Layout里，比如LinearLayout，RelativeLayout。

而Layout却是ViewGroup的子类。

所以说一个ViewTree只不过是各种Views和ViewGroups放在一个Layout里组成的树形结构。

有例子才有真相。

通过eclipse的Outline窗口，我们可以看下下面这个树状布局。

XML Code： ?xml version="1.0" encoding="utf-8"?>当我们在Activity里，用setContentView()去设置这个view，然后运行，我们可以看到如下图：仔细观察XML文件，以及页面渲染的View，我们会发现：1. ViewTree 是以一种自上而下的方式进行遍历实现。

2. Parent总是最先绘制的，其实才是Children，并且仍然遵循自上而下的方式。

所以在我们的例子中，RelativeLayout是最先绘制，接着是其孩子WhiteView，RedText 等等，直到最终GrayView绘制，并且我们会看到后绘制的覆盖了部分先绘制的。

为了更方便观察这些Views是怎么绘制的，我们把手机屏幕看作下面的X，Y，Z的坐标系。

屏幕的左上角作为[0，0，0]，X轴向右，Y轴向下沿着屏幕的长度，Z轴延伸出屏幕。

所以说，当我们遍历Tree的时候，这些Views基本上就是沿着Z轴排放。

这里需要注意，当View有部分被遮挡时，Android就不会再绘制这被遮挡的部分。

比如上图，灰色遮挡部分红色，Android绘图机制就不会再绘制那部分红色，所以我们看到的是直接遮挡，而不是颜色的混合。

现在我们知道了我们在XML里定义的Views是如何绘制的了，但是这还不够，我们可以借助一个非常有用的工具Heirarchyviewer去更深层细的观察页面布局。

Heirarchyviewer 在文件夹android-sdk/tools下，在命令行下找到这个文件夹，然后执行heirarchyviewer.bat 就可以了。

下图是Hierarchy Viewer的截图：在Hierarchy Viewer里，列代表树的深度，而每一列里行的数量则表示每一层的深度。

从图上我们能注意到RelativeLayout并不是Root级别的，而是id为content的FrameLayout的一个子元素。

而实际山我们调用setContentView(View v)里的View v 就是这个content视图。

现在注意下跟content同级的FrameLayout有个子TextView，实际上它既是Activity的titleBar。

那么我们删除这个TitleBar之后，View Tree又会变成什么样子呢？方法：在manifest文件，然后修改application的主题如下：android:theme="@android:style/Theme.Black.NoTitleBar.Fullscreen"这样再打开Hierarchy Viewer,我们就能看到下图：(注意：本人选用的Android是2.2的，要是用4.1的话，并不能得到下图，中间还会多一个Id为action_menu_bar_stub的ViewStub)这时候我们看到content FrameLayout的父元素是PhoneWindow$DecorView。

DecorView我们知道在Android中抽象类Window定义了最上层窗口的基本外观以及基本行为，她的实例将会被加到WindowManager中，提供一些标准的UI策略，像Background，Titlebar，以及Default key processing等等，当然这些属性是可以通过WindowManager.LayoutParams定制的。

而上面提到的PhoneWindow是Window抽象类的唯一实现，即android.policy.PhoneWindow。

而DecorWindow是PhoneWindow的一个私有内部类，其实就是一个FrameLayout的扩展。

private final class DecorView extends FrameLayout implements RootViewSurfaceTaker {}就是这个类构成了最上层应用程序视图。

根据我们在Manifest中设置的Theme或者在PhoneWindow设置的Flags，来确定DecorView的Layout。

所以在我们的例子中，第一张中我们有个简单的主题(在Manifest中)包含一个titlebar和contentview，于是PhoneWindow就生成了包含Title的LinearLayout，以及放置content的FrameLayout。

而在第二张图中，我们去掉了titlebar主题，所以她就只生成了包含FrameLayout的DecorView了。

结论最后我们来总结下，当一个Activity被启动的时候，这个视图树(View Tree)大体是如何创建的呢：1. PhoneWindow根据Manifest的主题或者是特定的PhoneWindow设置去生成一个DevorView的布局，作为跟视图(Root View)。

2. Activity调用setContentView()方法把用户自定义的Layout XML文件作为内容视图(Content View), 当然其内部是调用PhoneWindow的setContentView()方法。

3. 经过上两步，UI视图就已经形成了，那么当UI每次被刷新的时候，View Tree就会像上面所说的那样被Traverse。

Android,图形,用户界面,开,发之,ViewTree,

游戏服务器开发仍然使用c++ 作为主语言，但是大多结合动态脚本技术，一方面规避了野指针和内存泄露，一方面获得了开发效率和扩展性的红利。

今天主要说说在使用c++过程中，如何避免和解决野指针和内存泄漏问题。

野指针：野指针的出现会导致程序崩溃，这是每个人都不愿意看到的。

Linux会生成coredump文件，可用gdb分析。

Win下可以注册unexception获取调用堆栈，将错误信息写到文件中。

先分析一下通常出现野指针的场景：class monster_t{protected: player_t* m_attack;public: void handle_ai() { if (m_attack) { int x = m_attack->get_x(); } }}问题就在于，m_attack有值，但是对应的对象已经被销毁了。

这是大部分野指针出现原因。

分析类之间关系可知，monster_t 和 player_t是0-1的关系，monster_t引用player_t，但是player_t甚至都不知道有一个（或N个）monster 引用了自己。

所以当player被销毁时，很难做到把所有引用该player_t的地方全部重置。

这种问题其实比较常见，比如player中引用connection，而connection又是被网络层管理生命周期的，也同样容易产生野指针情况。

常见的解决方式是：class monster_t{protected: long m_attack_id;public: void handle_ai() { player_t* attack = obj_mgr.get(m_attack_id); if (attack) { int x = attack->get_x(); } }}另外一种与之相似的方式：class monster_t{protected: player_t* m_attack;public: void handle_ai() { if (obj_mgr.is_exist(m_attack)) { int x = m_attack->get_x(); } else { m_attack = NULL; } }}梳理野指针的产生原因后，我们其实需要的是这样的指针：一种指针，引用了另一个对象的地址（不然就不是指针了），当目标对象销毁时，该指针自然指向null，而不需要目标对象主动通知重置。

幸运的是，这种指针已经有了，就是weak_ptr; 在boost库中，sharedptr,scopedptr,weakptr统称为smartptr。

可以尽量使用智能指针，避免野指针。

本人建议尽量使用shared_ptr结合weak_ptr使用。

Scoped_ptr本人使用的较少，只是在创建线程对象的时候使用，正好符合不能复制的语义。

使用shared_ptr和weak_ptr的示例代码：class monster_t{protected: weak_ptr m_attack; shared_ptr get_attack() { return shared_ptr(m_attack); }public: void handle_ai() { shared_ptr attack = get_attack(); if (attack) { int x = attack->get_x(); } }}有人问monster_t为什么不直接使用shared_ptr，如果使用shared_ptr就不符合现实的模型了，monster_t显然不应该控制player_t的生命周期，如果使用了shared_ptr，那么可能导致player_t被延迟析构，甚至会导致内存暴涨。

这也是shared_ptr的使用误区，所以本人建议尽量shared_ptr和weak_ptr结合用，否则野指针问题解决了，内存泄漏问题又来了。

内存泄漏：野指针问题可以通过采用良好的编程范式，尽量规避，但总计c++规避内存泄漏的方法却很为难，简单而言尽量保证对象的分配和释放（分别）是单个入口的，这样大部分问题都可以拦截在code review阶段。

那么怎么检测内存泄漏呢？首先说明本方法区别于valgrind等工具，该工具是调试期进行的检测，本文探究的是运行期的检测，确切说是运行期定时输出所有对象的数量到日志中。

首先定义分配、释放对象的接口：templateT* new_obj() T* p = new T(); singleton_t >::instance().inc(1); return p;templateT* new_obj(ARG1 arg1) T* p = new T(arg1); singleton_t >::instance().inc(1); return p;templateT* new_obj(ARG1 arg1, ARG2 arg2) T* p = new T(arg1, arg2); singleton_t >::instance().inc(1); return p;templateT* new_array(int n) T* p = new T[n]; singleton_t >::instance().inc(n); return p;}为了节省篇幅，这里只列举了三种构造的代码，当分配对象时，对应的类型数量增加1，obj_counter 使用原子操作为每一种类型记录其数量。

class obj_counter_i{public: obj_counter_i():m_ref_count(0){} virtual ~ obj_counter_i(){} void inc(int n) { (void)__sync_add_and_fetch(&m_ref_count, n); } void dec(int n) { __sync_sub_and_fetch(&m_ref_count, n); } long val() const{ return m_ref_count; } virtual string get_name() { return ""; }protected: volatile long m_ref_count;};templateclass obj_counter_t: public obj_counter_i{ obj_counter_t() { singleton_t >::instance().reg(this); } virtual string get_name() { return TYPE_NAME(T); }};相应的当对象被释放的时候，对应的对象数量减一，示例代码如下：templatevoid del_obj(T* p){ if (p) { delete p; singleton_t >::instance().dec(1); }}这样就做到了所有的对象的数量都被记录了，可以定时的将对象数量输出到文件：class obj_counter_summary_t{public: void reg(obj_counter_i* p) { m_all_counter.push_back(p); } map get_all_obj_num() { map ret; for (list::iterator it = m_all_counter.begin(); it != m_all_counter.end(); ++it) { ret.insert(make_pair((*it)->get_name(), (*it)->val())); } return ret; } void dump(const string& path_) { ofstream tmp_fstream; tmp_fstream.open(path_.c_str()); map ret = get_all_obj_num(); map::iterator it = ret.begin(); time_t timep = time(NULL); struct tm *tmp = localtime( char tmp_buff[256]; sprintf(tmp_buff, "%04d%02d%02d-%02d:%02d:%02d", tmp->tm_year + 1900, tmp->tm_mon + 1, tmp->tm_mday, tmp->tm_hour, tmp->tm_min, tmp->tm_sec); char buff[1024] = {0}; snprintf(buff, sizeof(buff), "obj,num,%s\n", tmp_buff); tmp_fstream first.c_str(), it->second); tmp_fstream m_all_counter;};输出的文件格式为csv格式，方便进一步做数据分析。

可以使用我开发的小工具格式化csv数据。

总结：野指针可以使用shared_ptr和weak_ptr结合使用来尽量规避。

使用shared_ptr要尽量小心，否则可能导致对象无法释放，导致内存泄漏。

可以定时输出当前所有对象的数量，来分析是否有内存泄漏，或者内存泄漏是有哪些对象引起的。

本文介绍了记录所有对象的方法，除了可以分析内存泄漏外，也不失为数据分析的一种方法。

需要注明的是，本方法不能替代valgrind工具，二者作用不同。

c++,开发,如何,避免,和,解决,野,指针,内存,