注釋表明Stream是個基類，輸入輸出流IStream和OStream都繼承自它。

Stream的成員變量data_是個指針，指向序列化的字節(jié)流開始的位置，它的類型是uint8_t。

在Ubuntu系統(tǒng)中，uint8_t的定義是typedef unsigned char uint8_t;

所以uint8_t就是一個字節(jié)，可以用size_of()函數(shù)檢驗。data_指向的空間就是保存字節(jié)流的。

輸出流類OStream用來序列化一個對象，它引用了serialize函數(shù)，如下。

struct OStream : public Stream
{
  static const StreamType stream_type = stream_types::Output;
  OStream(uint8_t* data, uint32_t count) : Stream(data, count) {}
  /* Serialize an item to this output stream*/
  template<typename T>
  ROS_FORCE_INLINE void next(const T& t)
{
    serialize(*this, t);
  }
  template<typename T>
  ROS_FORCE_INLINE OStream& operator<<(const T& t)
  {
    serialize(*this, t);
    return *this;
  }
};

輸入流類IStream用來反序列化一個字節(jié)流，它引用了deserialize函數(shù)，如下。

struct ROSCPP_SERIALIZATION_DECL IStream : public Stream
{
  static const StreamType stream_type = stream_types::Input;
  IStream(uint8_t* data, uint32_t count) : Stream(data, count) {}
  /* Deserialize an item from this input stream */
  template<typename T>
  ROS_FORCE_INLINE void next(T& t)
{
    deserialize(*this, t);
  }
  template<typename T>
  ROS_FORCE_INLINE IStream& operator>>(T& t)
  {
    deserialize(*this, t);
    return *this;
  }
};

自然，serialize函數(shù)和deserialize函數(shù)就是改變數(shù)據(jù)形式的地方，它們的定義在比較靠前的地方。它們都接收兩個模板，都是內聯(lián)函數(shù)，然后里面沒什么東西，只是又調用了Serializer類的成員函數(shù)write和read。所以，serialize和deserialize函數(shù)就是個二道販子。

// Serialize an object.  Stream here should normally be a ros::serialization::OStream
template<typename T, typename Stream>
inline void serialize(Stream& stream, const T& t)
{
  Serializer

所以，我們來分析Serializer類，如下。我們發(fā)現(xiàn)，write和read函數(shù)又調用了類型里的serialize函數(shù)和deserialize函數(shù)。

頭別暈，這里的serialize和deserialize函數(shù)跟上面的同名函數(shù)不是一回事。

注釋中說：“Specializing the Serializer class is the only thing you need to do to get the ROS serialization system to work with a type”（要想讓ROS的序列化功能適用于其它的某個類型，你唯一需要做的就是特化這個Serializer類）。

這就涉及到的另一個知識點——模板特化（template specialization）。

template<typename T> struct Serializer
{
  // Write an object to the stream.  Normally the stream passed in here will be a ros::serialization::OStream
  template<typename Stream>
  inline static void write(Stream& stream, typename boost::call_traits
{
    t.serialize(stream.getData(), 0);
  }
   // Read an object from the stream.  Normally the stream passed in here will be a ros::serialization::IStream
  template<typename Stream>
  inline static void read(Stream& stream, typename boost::call_traits
{
    t.deserialize(stream.getData());
  }
  // Determine the serialized length of an object.
  inline static uint32_t serializedLength(typename boost::call_traits
{
    return t.serializationLength();
  }
};

接著又定義了一個帶參數(shù)的宏函數(shù)ROS_CREATE_SIMPLE_SERIALIZER(Type)，然后把這個宏作用到了ROS中的10種基本數(shù)據(jù)類型，分別是：uint8_t, int8_t, uint16_t, int16_t, uint32_t, int32_t, uint64_t, int64_t, float, double。

說明這10種數(shù)據(jù)類型的處理方式都是類似的?？吹竭@里大家應該明白了，write和read函數(shù)都使用了memcpy函數(shù)進行數(shù)據(jù)的移動。

注意宏定義中的template<>語句，這正是模板特化的標志，關鍵詞template后面跟一對尖括號。

關于模板特化可以看這里。

#define ROS_CREATE_SIMPLE_SERIALIZER(Type) \\
  template<> struct Serializer \\
  { \\
    template

對于其它類型的數(shù)據(jù)，例如bool、std::string、std::vector、ros::Time、ros::Duration、boost::array等等，它們各自的處理方式有細微的不同，所以不再用上面的宏函數(shù)，而是用模板特化的方式每種單獨定義，這也是為什么serialization.h這個文件這么冗長。

對于int、double這種單個元素的數(shù)據(jù)，直接用上面特化的Serializer類中的memcpy函數(shù)實現(xiàn)序列化。

對于vector、array這種多個元素的數(shù)據(jù)類型怎么辦呢？方法是分成幾種情況，對于固定長度簡單類型的（fixed-size simple types），還是用各自特化的Serializer類中的memcpy函數(shù)實現(xiàn)，沒啥太大區(qū)別。

對于固定但是類型不簡單的（fixed-size non-simple types）或者既不固定也不簡單的（non-fixed-size, non-simple types）或者固定但是不簡單的（fixed-size, non-simple types），用for循環(huán)遍歷，一個元素一個元素的單獨處理。

那怎么判斷一個數(shù)據(jù)是不是固定是不是簡單呢？這是在roscpp_traits文件夾中的message_traits.h完成的。

其中采用了萃取Type Traits，這是相對高級一點的編程技巧了，筆者也不太懂。

對序列化的介紹暫時就到這里了，有一些細節(jié)還沒講，等筆者看懂了再補。

2、消息訂閱發(fā)布

2.1ROS的本質

如果問ROS的本質是什么，或者用一句話概括ROS的核心功能。那么，筆者認為ROS就是個通信庫，讓不同的程序節(jié)點能夠相互對話。

很多文章和書籍在介紹ROS是什么的時候，經(jīng)常使用“ROS是一個通信框架”這種描述。

但是筆者認為這種描述并不是太合適?！翱蚣堋笔莻€對初學者非常不友好的抽象詞匯，用一個更抽象難懂的概念去解釋一個本來就不清楚的概念，對初學者起不到任何幫助。

而且筆者嚴重懷疑絕大多數(shù)作者能對機器人的本質或者軟件框架能有什么太深的理解，他們的見解不會比你我深刻多少。

既然提到本質，那我們就深入到最基本的問題。

在接觸無窮的細節(jié)之前，我們不妨先做一個哲學層面的思考。

那就是，為什么ROS要解決通信問題？

機器人涉及的東西千千萬萬，機械、電子、軟件、人工智能無所不包，為什么底層的設計是一套用來通信的程序而不是別的東西。

到目前為止，我還沒有看到有人討論過這個問題。這要回到機器人或者智能的本質。

當我們在談論機器人的時候，最首要的問題不是硬件設計，而是對信息的處理。一個機器人需要哪些信息，信息從何而來，如何傳遞，又被誰使用，這些才是最重要的問題。

人類飛不鳥，游不過魚，跑不過馬，力不如牛，為什么卻自稱萬物之靈呢。

因為人有大腦，而且人類大腦處理的信息更多更復雜。

拋開物質，從信息的角度看，人與動物、與機器人存在很多相似的地方。

機器人由許多功能模塊組成，它們之間需要協(xié)作才能形成一個有用的整體，機器人與機器人之間也需要協(xié)作才能形成一個有用的系統(tǒng)，要協(xié)作就離不開通信。

需要什么樣的信息以及信息從何而來不是ROS首先關心的，因為這取決于機器人的應用場景。

因此，ROS首先要解決的是通信的問題，即如何建立通信、用什么方式通信、通信的格式是什么等等一系列具體問題。

帶著這些問題，我們看看ROS是如何設計的。

2.2客戶端庫

實現(xiàn)通信的代碼在ros_comm包中，如下。

其中clients文件夾一共有127個文件，看來是最大的包了。

現(xiàn)在我們來到了ROS最核心的地帶。